共计 4290 个字符，预计需要花费 11 分钟才能阅读完成。
在字节跳动外部，Presto 次要撑持了 Ad-hoc 查问、BI 可视化剖析、近实时查问剖析等场景，日查问量靠近 100 万条。本文是字节跳动数据平台 Presto 团队 - 软件工程师常鹏飞在 PrestoCon 2021 大会上的分享整顿。
在字节跳动外部，Presto 次要撑持了 Ad-hoc 查问、BI 可视化剖析、近实时查问剖析等场景，日查问量靠近 100 万条。
• 功能性方面：齐全兼容 SparkSQL 语法，能够实现用户从 SparkSQL 到 Presto 的无感迁徙；
• 性能方面：实现 Join Reorder，Runtime Filter 等优化，在 TPCDS1T 数据集上性能绝对社区版本晋升 80.5%；
• 稳定性方面：首先，实现了多 Coordinator 架构，解决了 Presto 集群单 Coordinator 没有容灾能力的问题，将容灾复原工夫管制在 3s 以内；其次实现了基于 histogram 的动态规定和基于运行时状态的动静规定，能够无效进行集群的路由和限流；
• 可运维性方面：实现了 History Server 性能，能够反对实时追踪单个 Query 的执行状况，总体察看集群的运行状况。
字节跳动 OLAP 数据引擎平台 Presto 部署应用状况
过来几年，字节跳动的 OLAP 数据引擎经验了百花齐放到逐步收敛，再到畛域细分精细化经营优化的过程。
存储方面离线数据次要存储在 HDFS，业务数据以及线上日志类数据存储在 MQ 和 Kafka。
计算引擎依据业务类型不同，Presto 撑持了 Ad-hoc 查问、局部 BI 报表类查问，SparkSQL 负责超大体量简单剖析及离线 ETL、Flink 负责流式数据荡涤与导入。
为了解决日益增长的 Ad-hoc 查问需要，在 2020 年，字节跳动数据平台引入 Presto 来反对该类场景。
目前，整个 Presto 集群规模在几万 core，撑持了每天约 100 万次的查问申请，笼罩了绝大部分的 Ad-hoc 查问场景以及局部 BI 查问剖析场景。
图注：字节跳动外部 Presto 集群部署架构图
上图是字节跳动外部 Presto 集群部署的架构，针对不同的业务需要拆分为了多个互相隔离的集群，每个集群部署多个 Coordinator，负责调度对应集群的 Worker。
接入层提供了对立的 Gateway，用以负责用户申请的路由与限流。同时还提供了 History Server，Monitor System 等从属组件来减少集群的可运维性与稳定性。
Presto 集群稳定性和性能晋升
针对不同的业务场景以及查问性能要求，咱们将计算资源拆分为了互相独立的 Presto 集群。
Gateway 负责解决用户申请的路由，这部分性能次要通过动态的路由规定来实现，路由规定次要包含容许用户提交的集群以及降级容灾的集群等。
为了更好的均衡不同集群之间的负载状况，充沛无效的利用计算资源，前期又引入了动静的路由分流策略。该策略在做路由抉择的过程中会调用各个集群 Coordinator 的 Restful API 获取各个集群的负载状况，抉择最优的集群进行路由调度。
通过动态规定与动静策略相结合的形式，Gateway 在为用户提供对立接入接口的状况下，也保障了集群之间工作负载的均衡。
Coordinator 节点是单个 Presto 集群的外围节点，负责整个集群查问的接入与散发，因而它的稳定性间接影响到整个集群的稳定性。
在最后的部署中，每个 Presto 集群只能部署一个 Coordinator，当该节点解体的时候，整个集群大略会耗费几分钟的不可用工夫来期待该节点的主动拉起。
为了解决这个问题，咱们开发了多 Coordinator 的性能。该性能反对在同一个 Presto 集群中部署多个 Coordinator 节点，这些节点相互之间处于 active-active 备份的状态。
次要实现思路是将 Coordinator 和 Worker 的服务发现应用 Zookeeper 来进行革新。
Worker 会从 Zookeeper 获取到现存的 Coordinator 并随机选取一个进行心跳上报，同时每个 Coordinator 也能够从 Zookeeper 感知到其余 Coordinator 的存在。
每个 Coordinator 负责存储以后连贯到的 Worker 的工作负载状况以及由它调度的查问执行状况，同时以 Restful API 的模式将这些信息裸露进来；其余 Coordinator 在做任务调度的时候会通过这些 Restful API 获取到整个集群的资源应用状况进行相应的任务调度。
目前多 Coordinator 机制曾经在集群中上线应用了半年，将集群的不可用工夫从几分钟升高到 3s 以内。
另一个影响 Presto 集群稳定性的重要因素是超大规模的查问。
在 Ad-hoc 场景下，这种查问是无奈防止的，并且因为这种查问会扫描十分多的数据或者生成微小的中间状态，从而长期占用集群的计算资源，导致整个集群性能降落。
为了解决这个问题，咱们首先引入了基于规定以及代价的查问工夫预测。
基于规定的查问工夫预测次要会统计查问波及到的输出数据量以及查问的复杂程度来进行预测。
基于代价的查问工夫预测次要是通过收集在 Catalog 中的 Histogram 数据来对查问的代价进行预测。
上述预测可能解决局部问题，然而还是会存在一些预估不准的状况，为了进一步解决这些状况，咱们引入了 Adaptive Cancel 性能。
该性能次要是在查问开始执行后，周期性的统计查问预计读取的数据量以及已实现的工作执行工夫来预测查问整体的执行工夫，对于预测超过阈值的查问提前进行勾销，从而防止计算资源节约，晋升集群稳定性。
另外，Presto 自身提供的 UI 界面能够很好地对查问执行状况进行剖析，然而因为这部分信息是存储在 Coordinator 内存当中，因而会随着查问数量的累积而逐渐革除，从而导致历史查问状况无奈获取。
为了解决这个问题，咱们开发了 History Server 的性能。
Coordinator 在查问执行实现之后会将查问的执行状况存储到一个长久化存储当中，History Server 会从长久化存储当中加载历史的查问执行状况并提供与 Presto UI 完全相同的剖析体验，同时基于这部分长久化的信息，也能够建设相应的监控看板来观测集群的服务状况。
三个场景优化的实际分享
Ad-hoc 查问剖析场景
2020 年之前，大数据场景下的 Ad-hoc 查问次要由 Hive/SparkSQL 来撑持。为了进一步优化查问性能，进步资源应用效率，从 2020 年开始，咱们在生产环境大规模应用 Presto。
• 与 SparkSQL 相比，Presto 是一个常驻的 MPP 架构的 SQL 查问引擎，防止了 Spark Context 启动以及资源申请的开销，端到端提早较低。
• 与 Hive/Spark Thrift Server 相比，Presto Coordinator 更加成熟，轻量，稳固，同时 Presto 基于全内存的 Shuffle 模型能够无效的升高查问提早。
为了做到用户查问无感迁徙到 Presto，咱们做了大量的工作使得 Presto 在语法和语义层面兼容 SparkSQL。
• 在接入层方面：提供了 SQL 标准化改写性能。该性能能够将用户的 SQL 改写成 Presto 能够反对的 SQL 语法进行执行，做到了底层引擎对用户通明。
• 在函数反对方面：在 Presto 中反对了 Hive UDF 的执行，使得之前数据分析师积攒下来的大量 UDF 能够在 Presto 中执行。该性能次要反对了在解析阶段能够加载 Hive UDF 和 UDAF，并进行类型转换使其适配 Presto 类型体系，最终封装成 Presto 内置函数的模式进行执行。目前该性能局部曾经奉献回了 Presto 社区。社区地址
BI 可视化剖析场景
Presto 在字节跳动利用的另一个比拟重要的场景是 BI 可视化剖析。
BI 可视化剖析提供了可视化交互的性能来进行数据分析，数据分析能够直观疾速的进行数据分析并生成相应的剖析图表，这给查问引擎提出了更高的要求。在这一场景下，不仅，QPS 大幅提高，同时还要求查问引擎能给出比拟低的查问提早。
为了应答这些挑战，咱们做了一个比拟重要的工作——在 Presto 中引入了物化视图。
这种场景下，查问 SQL 往往都是由 BI 可视化平台依据固定的模版主动生成的，用户的可视化操作往往限于对查问过滤条件，聚合维度以及聚合指标的扭转，适宜物化视图的利用。
在物化视图性能中，咱们借鉴了很多传统数据库的教训，工作次要波及三方面的工作：
• 物化视图的主动开掘——次要依据用户查问的历史记录进行剖析，统计不同数据的查问频率进行物化视图的主动举荐与创立。
• 物化视图的生命周期治理——次要保护分区级别物化视图的自动更新，删除。
• 物化视图的重写性能——基于已有的物化视图，对用户的 query 进行重写以缩小查问执行的复杂度。
近实时场景的查问剖析
这是往年开始摸索的一个场景，次要是为了升高数据链路的提早，晋升查问剖析的时效性。
传统的基于 ETL 的数据链路中，业务数据和日志数据经由 Kafka 定期 dump 到 HDFS，而后会有多个 ETL 工作对数据进行加工清理造成不同层级的 Hive 表用来进行查问剖析。
这个链路中往往须要进行表数据的全量更新，工作比拟重，与线上数据存在 1 天以上的数据提早。
为了升高数据提早，咱们引入了 Hudi 来进行数据的增量更新。
在这个链路中，业务数据和日志数据经由 Spark/Flink Streaming 工作增量写入到 Hudi 表中，数据分析师能够间接查问这部分数据。目前，该链路能够做到分钟级别的数据提早。
咱们在 Presto 的优化工作次要是将 Hudi 表读取的性能从 Hive Connector 中提取进去成为了一个独自的 Hudi Connector。
• 首先，Hudi Connector 针对 Hudi 表的构造特点更好地反对了基于不同策略的分片调度算法，保障任务分配的合理性。
• 同时，Hudi Connector 优化了 Hudi MOR 表读取过程中的内存治理，防止了 Worker 节点 OOM，晋升了集群稳定性。
• 最初，Hudi Connector 的引入升高了 Hudi 版本升级带来的工作量，能够更好的集成 Hudi 社区最新的性能。这部分性能咱们将会逐渐奉献回社区。社区地址
本文中介绍的字节跳动外部 Presto 性能优化，目前已通过火山引擎数据产品“湖仓一体剖析服务”向内部企业输入。 湖仓一体剖析服务 LAS（Lakehouse Analytics Service） 是面向湖仓一体架构的 Serverless 数据处理剖析服务，提供一站式的海量数据存储计算和交互剖析能力，齐全兼容 Spark、Presto、Flink 生态，帮忙企业轻松实现数据价值洞察。
欢送大家关注字节跳动数据平台同名公众号
