编者按：在本文中，来自腾讯平台与内容事业部（PCG）数据服务中心的田红瀚将介绍他们的工程师是如何基于Alluxio优化分析性能并最小化构建腾讯灯塔产品的运维成本的。腾讯灯塔（Beacon，参加链接1）是一个实时的数据分析平台。具体地，通过使用Alluxio作为一个分布式缓存层，Impala SQL查询中的HDFS扫描的性能在不经进一步优化的情况下就提升了2倍。

腾讯大数据分析应用场景

腾讯灯塔（Beacon）是一个为分析师提供用户行为实时洞察的数据分析平台。灯塔包含自带的和定制化的分析模型，例如RETENT, FUNNEL, PATH等。通过将A/B测试功能和用户画像相结合，开发者可以更加容易地选择营销方案。

在平台底层，灯台由一系列开源技术组成的软件栈支撑。特别地，在本文介绍的范围内，我们主要的场景是使用Impala查询HDFS中Parquet格式的数据。为了让读者对系统有个更好的理解，以下对当前灯塔中的部署的软件栈进行概览。

系统存在的挑战

我们在腾讯构建的系统需要处理互联网级别规模的数据。例如，一个典型查询的数据扫描范围包含百亿行并且有上百个并发访问。为了加速查询，我们采用了例如Parquet文件内部页索引等优化（参见链接2）来减少扫描操作的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最有价值的一个功能就是统一命名空间（见链接3）。该功能有助于跨集群间的命名空间共享，使Impala更便捷的访问多个HDFS集群的数据资源。

以下表格式一些数据对比结果：

后续计划：本地性群组

在腾讯PCG 部门，我们还有一些正在进行的项目并规划与Alluxio对接。

首先，我们计划通过将一个大型的Alluxio集群的worker进程横跨部署到多个Impala集群上，从而进一步降低运维工作。换言之，Alluxio与Impala进程将会同置在相同的服务器上以减少网络流量。我们当前还遇到一些问题（参见链接4），并正在与Alluxio核心团队一起工作解决它们。

第二，我们希望利用Alluxio的层次化本地性群组（tiered locality group，参见链接5）特性进一步提升Impala的性能，并消除通过优化后的数据本地性消除Alluxio的远程读操作。具体地，通过部署一个但更大的Alluxio集群，我们会将Alluxio woker节点分成不同的本地性群组（locality groups）。这会使得当查询从不同HDFS集群读数据的时候，数据将会被缓存到最近的本地性存储中以减少I/O开销。这个特性与Clickhouse中的“layer” configuration”（参见链接6）很类似。

第三，一旦上述的本地性群组的效果达到了，就可以实现Impala计算分组（local部署）依据不同业务的impala计算集群，来弹性扩缩容impala的计算资源。

结 论

在腾讯灯台项目中，我们部署了Alluxio将I/O密集型的Impala查询性能提升了2.44倍，将全部查询性能提升了1.2倍。因为超时导致的查询失败率也降低了29%。在未来，我们可以预见到这项技术能够将我们规划的弹性Impala计算的磁盘利用率降低超过20%。

参考链接：

链接1：

链接2：

链接3：

链接4：

链接5：

链接6：