Presto 在腾讯的应用

本次分享主要有以下几个内容：

•Presto 在腾讯的使用状况•可用性扩展•稳定性改善•性能优化•未来工作

Presto 在腾讯的使用状况

可用性扩展

我们知道，原生的 Presto 配置 Catalog 是需要重启集群的。而腾讯对这个进行了改造，使得 Presto 支持动态 Catalog 配置，动态 Catalog 信息是保存到 Catalog Store（猜想应该是元数据等服务）。对 Catalog 的增删操作都是发到 Coordinator，然后再由 Coordinator 同步到 Worker。

Presto 的 Iceberg 数据源的社区进行了一些功能提升，腾讯 Presto 团队将一些有用的 Patch Merge 到自己分支。

稳定性改善

稳定性建设之一是 JVM 调优。主要包括 JDK 由8升级到11.  -XX:GCLockerRetryAllocationCount 增加到 100。

腾讯 Presto 团队弄了一个新的策略：在 Full GC 之后，如果 workers 还出现 OOM 的问题，就会 kill 掉 workers 上使用内存多的查询。

 ORC 文件如果有很多 stripes 的话，很容易导致 Worker 出现 OOM，对于这个问题主要有以下两个解决办法：

• 将大的 ORC 文件拆分成 stripe 比较合适的小文件，但是这个需要修改用户的数据。

• 优化 Presto ORC Reader，不需要在不同的 splits 中读取相同 ORC文件的重复 StripeStatistics。

其他扩展性提升：

• 对重要业务的不同类型工作负载使用独立集群处理；

• 限制查询的 split 数，避免大查询以及处理许多小文件的查询；

• 转发到 Presto 的查询失败时会通过 SuperSQL 自动转发到 Hive/Spark，这个操作对用户是无感知的。

• 减少 hive.dfs-timeout 来避免从 HDFS DataNode 读取数据时等待过长的时间。

性能优化

引入了 Presto on Alluxio，目前 Alluxio 节点和 Presto 是混部的，Presto Alluxio Local Cache 正在测试中。

• 对不同的数据源使用不同的路由策略。

• 当路由的时候，会检查 Alluxio 集群的健康，如果 Alluxio 路径不可访问时自动使用 HDFS 路径；

• 热数据范围是由用户在白名单中指定的，其可以支持多个 Alluxio 集群；

• 次读取数据时，把数据缓存到 Alluxio 中。数据的过期和 evict 都是自动的。

上面是 Presto on Alluxio 的性能测试，主要选取了8中类型的 SQL 进行了测试。（过往记忆大数据备注：性能提升看起来不明显啊？）

目前，腾讯的 Presto 是部署在 K8S 上的。

 支持通过节点的 CPU 和 内存的使用情况自动扩缩容。

 对 distinct Count 查询进行了重写，将其转换成 grouping sets，从而通过部分聚合消除数据倾斜。同样场景下的用户场景性能提升了2-3倍。

未来工作