编者按:在本文中,来自腾讯平台与内容事业部(PCG)数据服务中心的田红瀚将介绍他们的工程师是如何基于Alluxio优化分析性能并最小化构建腾讯灯塔产品的运维成本的。腾讯灯塔(Beacon)是一个实时的数据分析平台。具体地,通过使用Alluxio作为一个分布式缓存层,Impala SQL查询中的HDFS扫描的性能在不经进一步优化的情况下就提升了2倍。
腾讯大数据分析应用场景
腾讯灯塔(Beacon)是一个为分析师提供用户行为实时洞察的数据分析平台。灯塔包含自带的和定制化的分析模型,例如RETENT, FUNNEL, PATH等。通过将A/B测试功能和用户画像相结合,开发者可以更加容易地选择营销方案。
在平台底层,灯台由一系列开源技术组成的软件栈支撑。特别地,在本文介绍的范围内,我们主要的场景是使用Impala查询HDFS中Parquet格式的数据。为了让读者对系统有个更好的理解,以下对当前灯塔中的部署的软件栈进行概览。
系统存在的挑战
我们在腾讯构建的系统需要处理互联网级别规模的数据。例如,一个典型查询的数据扫描范围包含百亿行并且有上百个并发访问。为了加速查询,我们采用了例如Parquet文件内部页索引等优化(https://issues.apache.org/jira/browse/IMPALA-5843)来减少扫描操作的I/O开销。在实践中,我们还是观察到了一些总结如下的问题:
- 高并发下的I/O瓶颈: 我们观察到并发查询数量达到100+,会造成HDFS的IO数据扫描瓶颈,热盘利用率一直在100%。
- 昂贵的写操作: 例如“SORT BY” 的插入操作在建表过的中非常慢,原因需要在合并文件过程中进行hdfs-parquet
sort。注意,在我们的应场景中, “SORT BY” 有助于达到查询SLAs而无需过于对表格进行划分。
为什么使用Alluxio
基于上述的观察,我们决定利用SSD设备构建一个缓存层。然而,HDFS并不是为利用异构存储而设计的。我们采用Alluxio来综合利用SSD的速度优势以及HDD的空间优势。全新的架构如下图所示:
通过将Alluxio集成至腾讯灯塔基础架构,我们看到一些变化和提升,具体如下:
- 更好的资源利用率:HDFS的平均负载范围显著地从80% ~ 100%降到了50% ~ 70%。I/O的时间也降低了50%或更多.
- 更高的查询性能: 随着更快的数据获取,I/O密集型的查询速度提升了244%,所有查询提升的中位数水平是121%。
- 更高的集群稳定性: Alluxio极大地减少了热点数据以及大规模查询对整个集群的I/O使用量,将所有的查询失败率降低了超过5%。
- 减少了超时错误率: 更快的执行同时还减少了查询在队列等待时间,并取得了查询超时失败错误率降低29%的效果。
在我们案例中,我们认为Alluxio最有价值的一个功能就是统一命名空间。该功能有助于跨集群间的命名空间共享,使Impala更便捷的访问多个HDFS集群的数据资源。
以下表格式一些数据对比结果:
后续计划: 本地性群组
在腾讯PCG 部门,我们还有一些正在进行的项目并规划与Alluxio对接。
首先,我们计划通过将一个大型的Alluxio集群的worker进程横跨部署到多个Impala集群上,从而进一步降低运维工作。换言之, Alluxio与Impala进程将会同置在相同的服务器上以减少网络流量。我们当前还遇到一些问题,并正在与Alluxio核心团队一起工作解决它们。
第二,我们希望利用Alluxio的层次化本地性群组(tiered locality group)特性进一步提升Impala的性能,并消除通过优化后的数据本地性消除Alluxio的远程读操作。具体地,通过部署一个但更大的Alluxio集群,我们会将Alluxio woker节点分成不同的本地性群组(locality groups)。这会使得当查询从不同HDFS集群读数据的时候,数据将会被缓存到最近的本地性存储中以减少I/O开销。这个特性与Clickhouse中的“layer” configuration” 很类似。
第三,一旦上述的本地性群组的效果达到了,就可以实现Impala计算分组(local部署)依据不同业务的impala计算集群,来弹性扩缩容impala的计算资源。
结论
在腾讯灯台项目中,我们部署了Alluxio将I/O密集型的Impala查询性能提升了2.44倍,将全部查询性能提升了1.2倍。因为超时导致的查询失败率也降低了29%。在未来,我们可以预见到这项技术能够将我们规划的弹性Impala计算的磁盘利用率降低超过20%。