SQL on Hadoop在快手大数据平台的实践与优化

当查询完成后，本地会轮询结果文件，一直获取到LIMIT大小，然后返回。这种情况下，当有大量的小文件存在，而大文件在后端的时候，会导致Bad Case，不停与HDFS交互，获取文件信息以及文件数据，大大拉长运行时间。

在Fetch之前，对结果文件的大小进行预排序，可以有数百倍的性能提升。

示例：当前有200个文件。199个小文件一条记录a，1个大文件混合记录a与test共200条，大文件名index在小文件之后。

FetchTask加速：预排序与逻辑优化

Hive中有一个SimpleFetchOptimizer优化器，会直接生成FetchTask，减小资源申请时间与调度时间。但这个优化会出现瓶颈。如果数据量小，但是文件数多，需要返回的条数多， 存在能大量筛掉结果数据的Filter条件。这时候串行读取输入文件，导致查询延迟大，反而没起到加速效果。

在SimpleFetchOptimizer优化器中，新增文件数的判断条件，最后将任务提交到集群环境， 通过提高并发来实现加速。

示例：读取当前500个文件的分区。优化后的文件数阈值为100。

大表Desc Table优化

一个表有大量的子分区，它的DESC过程会与元数据交互，获取所有的分区。但最后返回的结果，只有跟表相关的信息。

与元数据交互的时候，延迟了整个DESC的查询，当元数据压力大的时候甚至无法返回结果。

针对于TABLE的DESC过程，直接去掉了跟元数据交互获取分区的过程，加速时间跟子分区数量成正比。

示例：desc十万分区的大表。

其它改进

• 复用split计算的数据，跳过reduce估算重复统计输入过程。输入数据量大的任务，调度速率提升50%。
• parquetSerde init加速，跳过同一表的重复列剪枝优化，防止map task op init时间超时。
• 新增LazyOutputFormat，有record输出再创建文件，避免空文件的产生，导致下游读取大量空文件消耗时间。
• statsTask支持多线程聚合统计信息，防止中间文件过多导致聚合过慢，增大运行时间。
• AdHoc需要打开并行编译，防止SQL串行编译导致整体延迟时间增大的问题。




SQL on Hadoop平台在使用中遇到的痛点

SQL on Hadoop在快手使用：常见可用性问题

HiveServer2服务启动优化

HS2启动时会对物化视图功能进行初始化，轮询整个元数据库，导致HS2的启动时间非常长，从下线状态到重新上线间隔过大，可用性很差。

将物化视图功能修改为延迟懒加载，单独线程加载，不影响HS2的服务启动。物化视图支持加载中获取已缓存信息，保证功能的可用性。

HS2启动时间从5min+提升至<5s。

HiveServer2配置热加载

HS2本身上下线成本较高，需要保证服务上的任务全部执行完成才能进行操作。配置的修改可作为较高频率的操作，且需要做到热加载。

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!