基于Presto+Alluxio的adhoc查询方案在网易游戏的实践

作者:jcmp      发布时间:2021-05-03      浏览量:0
1. 业务背景数据分析人员通常会经两种途

1. 业务背景

数据分析人员通常会经两种途径来访问这些海量的原始或表格数据:

1. 常规的业务指标会经由成熟的报表系统落到到数仓存储系统;

2. 除此外还存在着另外一种类型的adhoc(即席)报表查询需求,其业务特点为:

目前业界比较常见的adhoc查询方案是SQL on Hadoop。根据这个思路以及内部的组件积累方向,目前在网易游戏平台内部存在大量的基于Hive on MR/Hive on Tez/SparkSQL的查询场景。然而这些方案都存在着一定的问题:

1. Hive on MR方案一般适用于ETL逻辑和离线数据查询场景,其查询速度比较慢。根据业务SQL的复杂度不同,其查询性能一般在分钟到小时级别,达不到adhoc查询性能的要求(平均2-15秒)。

2. 基于DAG的Hive on Tez方案优化了查询引擎,相对于Hive on MR方案,在部分查询场景下速度能达到秒级别返回,但是性能提升不明显(从后续的测试结果来看,速度一般在30秒以上)。

3. 基于内存计算和DAG的SparkSQL的并发查询方案能够一定程度地提升查询速度(从后面的性能测试结果来看,查询时间在10到30秒左右)。但是存在着以下缺点:

在去年(2017年)8月份,业务方给我们提了一个adhoc查询的需求,其大致背景为:

旧的解决方案基于HBase storage+coprocesser,存在一些限制:

在与业务方沟通过后,总结了业务方对后续新方案的述求如下:

1. 优良且稳定的查询性能:该方案的性能需要明显好于旧的解决方案,且查询性能相对波动较小。业务方给的预期查询平均时间为10秒左右。

2. 降低数据转换成本:希望能直接基于Hive表进行查询,减少数据转到其他存储的成本。

3. 能够能有一个能查看adhoc查询进度百分比的接口:在查询时间比较长的情况下,有个进度显示能够很大程度上提高用户体验。

基于以上背景,我们尝试,选择了基于Presto+Alluxio的联合查询方案:

2. 架构方案

我们搭建的Presto+Alluxio框架示意图如下所示:

关于这一架构更多的部署和配属细节说明如下:

1. 为保证查询性能的高效和稳定,Presto+Alluxio服务部署在一个独立的卫星集群之上,与保存和服务全量数据的HDFS的datanode集群是分开部署的。这样从架构上保证查询框架独享隔离的计算资源。而在这一卫星集群里Presto和 Alluxio是混合部署:把Presto的coordinator和Alluxio的master部署于相同的节点上,同理也把Presto和Alluxio的worker部署于相同的节点上。目前最大的集群有100个节点。

2. 介于内存资源的稀缺性,Alluxio的存储并没有完全使用内存作为存储,而是使用了 分级存储 的策略,由内存层(MEM)和硬盘层(HDD)两级组成。我们为每个Alluxio worker配置了10GB的内存和800G的HDD存储,通过Alluxio自带的缓存eviction策略进行缓存清理。

3. 考虑到Hive metastore在离线作业高峰期存在性能波动(在我们的环境中,`get_table` api 99th时延在高峰期的性能是低峰期的10倍以上),我们为Presto的adhoc查询服部署了一个独立的Hive metastore实例。

4. 由于全量数据保存在HDFS当中,在Alluxio当中缓存的数据存在和HDFS中的数据同步的问题。我们框架下的数据逻辑如下:

5. 其他配置和建议:

3. 相关性能测试

非Alluxio缓存场景下各SQL on Hadoop性能对比。

1. 数据量规模为: 1.5亿行,50个字段,46GB

2. sql描述为

查询结果为如下,可以看到,Presto的查询性能相比于前面几种方案存在着有较大的优势。

Presto在有无Alluxio缓存情况下的单并发查询性能对比。

下图中,绿线为Presto+Alluxio的查询性能曲线;红线为Presto + non Alluxio的查询性能曲线。从结果来看,有Alluxio Cache的查询时延有明显的优化,并且多次查询时间非常稳定。

横坐标是查询时间节点,每隔1分钟进行一次查询;纵坐标是查询的时间,单位是ms。

发现的问题

在整个使用过程中,也发现了一些问题,下面是初步整理的一些:

1. Alluxio组件性能相关的metrics没有暴露出来: 目前线上使用的是V1.7.1的版本,目前expose的metrics似乎都是Ops相关的指标,没有一些性能方便的metrics,比如worker thrift server的rpc请求延时,thrift server的线程情况,gc情况等。

2. Alluxio的RPC性能还存在着优化的空间:从后续的一些多并发性能测试来看,偶尔会出现worker timeout的情况,猜测是和线程池配置有一定的关系。在社区规划中, Alluxio 2.0 当中会有较大的升级。

3. Alluxio master元数据的性能问题: 熟悉namenode的同学应该比较清楚,如果单个namenode的blocks和文件数超过一定的阈值的话,会导致系统性能出现下架,以及单点故障影响整体服务的风险。在我们内部,目前还是通过白名单的方式限制加载到alluxio里面的metadata的规模。目前社区规划在Alluxio 2.0会支持到10亿个文件量级的元数据。

未来规划

目前在平台内部,已经有不少的交互式查询业务运行在上述的presto+alluxio框架上,很好地扩充了实时计算,离线计算之外的交互式查询业务场景的需求;

下一步的考虑具体来说:

1. 测试Presto+Alluxio on yarn框架:目前的框架是独立于yarn的集群,由于adhoc业务的特殊性,其并发并不会特别高,所以会造成一定程度地资源浪费。而基于yarn的Presto+Alluxio则可以很好地解决该问题,也给更大范围的推广提供了可能。事实上,目前内部已经有基于yarn的Presto+Alluxio测试环境,正在进行功能和性能测试。

2. 数据入库直接基于Alluxio统一文件入口

3. 和业务方探讨更多适合Alluxio读写的应用场景