本文分享自华为云社区《走向批处理-交互式分析一体化： Trino容错模式深度测评与思考》，作者：HetuEngine 九级代言 。

本文系华为云大数据研发团队原创，原创作者：文博，梦月

1 Trino 简介

2020 年 12 月 27 日，Presto 社区大佬们——Martin Traverso、 Dain Sundstrom 以及 David Phillips 宣布将开源项目 PrestoSQL 的名字更名为 TrinoDB（本文简称 Trino）。

Trino 是一款开源的高性能、分布式 SQL 查询引擎，专门用于对各种异构数据源运行交互式分析查询，支持从 GB 到 PB 的数据量范围。Trino 专门为交互式分析而设计，可以对来自不同数据源的数据（包括：Hive、AWS S3、Alluxio、MySQL、Kafka、ES 等等）进行合并查询，并提供良好的自定义连接器编程扩展框架。适用于期望响应时间从亚秒到数分钟不等的分析师场景。

在诞生之初，Trino 是为了填补当时 Facebook 内部实时查询和 ETL 处理之间的空白。Trino 的核心目标就是提供交互式查询，也就是我们常说的 Ad-Hoc Query，很多公司都使用它作为 OLAP 计算引擎。近年来业务场景越来越复杂，除了交互式查询场景，很多公司也需要兼顾批处理作业，技术大佬们开始思考如何用 Trino 来进行大数据集的批加工处理。

2 传统 Trino 架构的局限性

在传统 Trino 运行架构中，Trino 预先规划了处理特定查询的所有 task 。这些 task 彼此关联，一项 task 的结果是下一项 task 的输入。对于 MPP 引擎来说，这种相互依赖是必要的。一旦任何任务在此过程中失败，就会破坏整个任务链条，导致整个 SQL 执行退出。

Trino 执行 SQL 任务过程如下图（来自 Trino 官网）：

优点：

数据通过 task 进行流式传输，没有中间检查点，高吞吐低延迟

不足：

• 缺乏细粒度的故障回复，出现问题只能从头运行整个 Query

• 完全依赖内存资源进行数据装载和交换

• 执行规划一旦确定就无法根据实际执行进展灵活调整

3 Trino 容错执行架构（FTE）

Trino 开源社区设计了一种新的容错执行架构（fault-tolerant execution architecture），它允许我们实现具有细粒度重试的高级资源感知调度（advanced resource-aware scheduling）。该项目代号为“Tardigrade”。

Tardigrade 项目旨在打破原有的全有或全无的执行障碍。它为资源管理、自适应查询优化和故障恢复带来了许多新的机会。该项目以水熊虫命名 ，水熊虫是世界上最坚不可摧的生物，类似于 FTE 为 Trino 带来的鲁棒性。

以下是 Tardigrade 项目带来的一些直观效果：

• 当长时间运行的 SQL Query 遇到故障时，不必从头开始运行；

• 当 Query 需要的内存超过集群中当前可用的内存时，仍然能够运行成功；

• 当多个 Query 同时提交时，它们能够以公平的方式共享资源，并稳步运行

从代码实现角度看， Trino 直接在内核中实现了 task 级容错、自动重试、shuffle 等核心功能。如下图所示（来自 Trino 官网）：

Trino 会将一个 Query 执行分成多个 stage。在容错模式下，上游 stage 的 shuffle 数据会进行落盘（支持写到 AWS S3、HDFS 及本地存储）。下游 stage 从中间存储里读取所需要的数据，并在该过程中对后续 task 任务进行重新优化与分配。

带来的改进：

• 适应性规划：可以在缓冲数据时，动态调整查询计划

• 资源管理：在查询运行时调整资源分配。当集群空闲时，我们可以允许单个查询利用集群上的所有可用资源。当更多工作负载开始时，可​​以逐渐减少初始查询的资源分配。

• 细粒度的故障恢复：允许透明地重启失败的任务，使得 ETL 完成时间更可预测。

接下来，本文将带各位深入体验 Trino 容错执行模式。

4 基础性能测试

首先在计算资源充足的场景下进行基础性能测试。选取 1TB 数据量的 TPCDS，计算资源规格为 2CN+16Worker 136GB/进程，测试开启容错前后，执行 TPCDS99，耗时统计如下：

测试写入性能选择 TPCDS 表中最大的表 catalog_sales 测试写入性能，SQL 为：

--- create table catalog_sales_copy as select * from catalog_sales;

测试数据如下：

小结：

• 开启 Task 容错会进行中间交换区结果落盘，存在性能损耗，执行耗时约为之前的 2 倍；

• Query 容错没有落盘的过程，与不开启容错性能持平。

• 1TB 数据集时，Task 容错写入性能也会有 8%-10%损耗，但在 10TB 数据集时反而有性能提升，待深入分析；

5 大数据量场景的稳定性测试

本节将在计算资源严重不足的场景下进行 TPCDS 压力测试。测试结果如下：

小结：

• 内存不足情况下使用 Task 容错，能够大幅度提高 SQL 执行成功率。与 spill to disk 特性结合使用能带来更好的容错效果；

• 在 50TB 数据集时，Task 容错仍然能够提高执行成功率，但某些复杂 SQL 可能会存在单点瓶颈。目前观察到主要是单点聚合瓶颈。

6 高并发场景测试

6.1 1TB TPCD 标准数据集

计算资源规格：1CN+8Worker，136GB/进程

测试 SQL 用例： Q01（多事实表关联查询，即 TPCDS99 中的 Q29）

测试结果如下表所示：

6.2 10TB TPCD 标准数据集

计算资源规格：1CN+8Worker，136GB/进程

测试 SQL 用例：

单表多列聚合排序查询 Q02：

select

• ws_item_sk,

• ws_web_site_sk,

• sum(ws_sales_price) total

from

• web_sales

where

• ws_sold_date_sk >= 2450815

• and ws_sold_date_sk <= 2451179

group by

• ws_item_sk,

• ws_web_site_sk

having

• sum(ws_sales_price) > 0

order by

• total desc

limit 100;

开启 TASK 容错全部能够执行成功。测结果如下表所示：

小结：

Task 容错能够提升 Trino 引擎的并发上限，很大程度上减少诸如“Encountered too many errors talking to a worker node.”报错的产生。

7 多个引擎横向对比测试

首先从 TPCDS99 中挑选出计算资源受限前提下，Trino 不开启容错 100%会跑失败的 SQL 用例，包括：

Q04，Q11，Q23，Q38，Q64，Q65，Q67，Q74，Q75，Q78，Q80，Q81，Q85，Q87，Q93，Q95，Q97

基于相同计算资源（内存、CPU、Container 个数），横向对比 Trino、Spark、Hive(TEZ) 的性能表现。

注：测试 Trino 时实际采用的是华为云 HetuEngine 2.0 的内核版本。

7.1 1TB TPCD 标准数据集

可看出，在 1TB 数据量、使用相同资源情况下，开启 Task 容错，Trino 能够将原先跑失败的 SQL 执行成功，且性能约为 Spark 的 3 倍左右，是 Hive(TEZ)的数十倍。

7.2 10TB TPCDS 标准数据集

针对 10TB TPCDS 标准数据集，进行对比测试：

可看出，在 10TB 数据量、使用相同资源情况下，开启 Task 容错，Trino 能够将原先跑失败的 SQL 执行成功，且性能约为 Spark 的 3 倍左右。

8 综合评价

综上，基于测试数据总结归纳如下——

单并发基础性能

1. 内存资源充足：不开启容错 = Query 容错 > Task 容错

2. 内存资源不足：Task 容错可以跑过，不开启容错/Query 容错跑不出结果

大数据量场景的稳定性

Task 容错 + spill to disk > Task 容错 > 不开启容错

• 1-10TB 数据集：Task 容错的表现很稳定，通过率 100%

• 50TB 数据集： 结合使用 Task 容错、spill to disk 相比单独用 Task 容错表现更好(少失败 1 个用例)

并发场景的稳定性

Task 容错 > 不开启容错

多个引擎横向性能对比

• 1TB TPCDS 数据集：Trino(Task 容错) > Spark > Hive(TEZ)

• 10TB TPCDS 数据集：Trino (Task 容错) > Spark

总体而言，Trino 的 FTE 功能在性能、稳定性维度的测试表现超出了预期。随着该能力的逐步演进与完善，相信 Trino 将在一站式数据加工与分析场景发挥出更大的价值。

9 思考与改进

在拥有了第一手的测试数据与分析结论后，接下来我们将思考如何利用好 Trino 容错模式，最大化的发挥其价值，同时要提前识别可能存在的问题，探索解决之道。

9.1 容错模式启用决策

从前面的测试数据可以看出，开启容错模式对于短查询性能存在一定的影响（对大查询性能反而存在优化的可能）。因此需要思考何时、何种方式来开启容错模式。

有如下思路可供选择——

• 用户自主择机启用

最简单的办法就是让业务用户自主择机选择启用或者关闭容错模式。通常情况下，有经验的用户知道哪些查询可能是计算量大或者运行时间久的查询。他们可以通过改变 JDBC 连接的 session 参数来实现在“交互式模式”和“容错模式”之间灵活切换；

• 基于代价决策

可以基于 SQL 执行的预测代价来决定是否开启“容错模式”。一般来说，这个技术需要依赖实现统计获得的列级别统计信息。然而，列级别统计信息有时候是不可用的，而且基于代价估算的预测精度往往不够理想；

• 自适应选择技术

默认情况下，查询可以“交互式模式”启动，然后在运行 N 分钟后，经过一段时间学习后，由引擎内核根据可用资源情况、业务特点等维度信息，自主决策启动或关闭“容错模式”。这个思路需要将 Trino 引擎与机器学习、AI 技术结合起来，践行数智融合路线；

• 基于历史信息决策

针对特定数据源的某些类型的查询，可以预先收集历史运行记录并进行分析建模。基于事先学习掌握的先验知识模型，在 SQL 执行前选择最优的执行模式。

9.2 水平扩展规模应用

Trino 具备了容错执行模式，测试数据显示效果不错，那么接下来大家就会思考：是否可以基于该能力提供更大规模的分析查询加速服务呢？

实际业务场景中，企业可能需要按需进行任务提交与弹性资源调度，尤其是在大规模、云原生环境中，即使开启容错模式，对于单个 Trino 集群，其协调节点（Coordinator）依然可能存在并发能力的瓶颈。此外，从软件架构角度看，单一 Trino 集群的可用性也存在一定的风险，影响云服务环境下的 SLA 目标达成。

针对上述问题，华为云交互式分析引擎 HetuEngine 提供了三层分布式架构，通过统一的 SQL 访问入口——HSFabric 来向业务提供全局唯一的 JDBC 服务地址。

通过 HSFabric 统一 SQL 访问入口，HetuEngine 实现了将业务层逻辑与某个特定的计算实例解耦，单个资源租户内部可以横向扩展多个计算实例，同一个租户内部的 SQL 任务可以在不同计算实例间灵活分配。

无论从多租户还是单一租户角度看，HetuEngine 的并发容量可水平扩展，同时也提升了服务可用性和资源利用率。

基于上述架构，HetuEngine 支持服务管理员自由决定是否开启/关闭单个租户的容错执行模式，以便更好的满足不同场景的业务诉求。

9.3 故障处理与恢复

在 Trino 容错执行过程中，Stage 间的 Shuffle 数据会大量落入到分布式文件系统上。这里以 HDFS 为例进行讨论可能存在问题。

假设——1 个大 SQL 在执行过程中，Trino 正在往 HDFS 上写 shuffle 数据，突然 Trino 所在物理机节点发生意外（比如，停电、断网、操作系统崩溃等），或者 Trino 本身出现故障停止工作（比如，过载等）。这可能会导致整个 Trino 集群都彻底停止工作。此时，需要管理员人工介入才能重新恢复 Trino 集群的正常工作状态。

显而易见，对 Trino 来说，至少存在 2 个问题需要思考和解决：

• 如何实现 Trino 集群的应急快速恢复

• 确保 HDFS 上的残留文件及时被清理，避免存储空间耗尽

华为云交互式分析引擎 HetuEngine 基于三层服务化+容器化架构，可有效应对上述挑战：

针对问题 1：

借助于全容器化的部署架构，HetuEngine 的任一计算实例（对应于 1 个分布式 Trino 集群）中的任一软件进程在发生故障/意外时，均可由 Service 层快速自动拉起新的容器进程来接管和补齐服务缺失，在人工介入前快速完成故障自愈。

在可用资源可能存在不足时，HetuEngine 支持计算实例在线弹性伸缩，通过自动调整 Worker 数量来动态平衡资源利用率，快速补充因故障而丢失的 Worker 节点资源。

在 Coordinator 节点发生故障时，HetuEngine 从三方面入手进行应对——

1. 同一计算实例中的 Worker 节点立即与备 Coordinator 进行组网；

2. 备 Coordinator 升为新的主 Coordinator；

3. 统一 SQL 入口立即将新的 SQL 请求引流到新的主 Coordinator

针对问题 2：

HetuEngine 的 Service 层全天 24 小时不间断监控，跟踪并及时发现、清理各层级作业残留（包括：数据、文件、目录、元数据等）。

同时针对历史任务进行多维度地深入洞察，生成高价值 SQL 运维图表和决策推荐信息，最终呈现在控制台页面。

Service 层提供的全方位贴心服务，极大降低了对数据分析平台管理员的专业知识要求，解决管理员对于长期运营的后顾之忧。

9.4 大数据平台业务无损的弹性扩缩容

通常来说，大数据平台的弹性伸缩方案只会涵盖 Hive、Spark 这类批处理引擎。因 Hive、Spark 本身具备了容错执行能力，即使因为大数据平台的管控面下发指令强制缩容一个正在运行 Hive/Spark 作业的物理节点，也不会影响相关作业的最终执行成功，最多只是引发了局部 task 的重试，增加了执行时长。因此，面向 Hive、Spark 引擎的大数据平台弹性伸缩方案相对来说比较容易，只需要关注资源层面的管理操作即可。

但对 Trino 这类 MPP 架构引擎来说，上述大数据平台的弹性伸缩管理模式就可能会面临如下几个方面的挑战：

• MPP 架构的 SQL 引擎一般都是常驻形态，在缩容过程中任何一个节点被强杀都可能导致该节点上正在运行中的 SQL 任务失败；

• Trino 的协调节点 Coordinator 默认为 1 个，在缩容过程中，强杀 Coordinator 所在的节点会导致整个 Trino 集群不可用，运行中的所有 SQL 任务失败；

• Trino 集群的扩容，需要平台管理面深入理解 Trino 集群的内部服务发现与工作机制，针对具体集群的 IP 和端口号定制配置，才能顺利的将新节点加入到一个已经存在的 Trino 集群中。

综上，要想在大数据平台服务上实现对 Trino 生态引擎的弹性伸缩，且做到业务无损，需要在大数据平台服务层和 Trino 内核层之间抽象出一个面向多资源租户+多个计算实例（Trino 集群）的资源管理 &业务接入 service 层。

HetuEngine 的 service 层对大数据平台服务层屏蔽底层 Trino 内核细节，对上提供 Rest API 调用，并将大数据平台服务层的管理运维诉求转换为对具体 Trino 集群的实际变更。同时要做到对多个 Trino 集群的日常状态监控与自维护。

在上述架构基础之上，可以基于 Trino 容错执行的能力，在开启弹性伸缩时，进一步降低大数据平台层面弹性伸缩的等待时间。

一种可行的思路大致是——大数据平台服务层向 HetuEngine 的 service 层下发缩容指令，service 确定即将被缩容的节点上正在运行的计算实例，并将其动态切换到容错模式。在通常情况下，service 层可以快速向上层服务层答复缩容操作准备继续，不用等待 SQL 任务执行完。

9.5 小结

基于上述架构与思路，华为云 HetuEngine 能很好地应对容错执行模式可能引入的新问题，显著提升生产环境实际运维效率，助力用户很方便地享受容错执行的新红利。

接下来， HetuEngine 将逐步引入和完善在两个不同执行模式间的智能切换能力，进一步完善对大数据云服务弹性伸缩的场景适配，在数据湖内一站式 SQL 分析领域持续创新、长期演进。

10 HetuEngine 2.0 版本预告

预计 2023 年 9 月 30 日，HetuEngine 2.0 将随华为云 MRS 3.3.0-LTS 正式发布。在该版本中，可以看到一系列的新能力，例如——

• 基于 Java17 运行全新内核，基础性能、稳定性再上一个新台阶，TPCDS 提速 30%

• 大 SQL 主动防御：事前提示/拦截，事中熔断，事后统计

• 支持容错执行模式：适用范围更广泛，使能一站式 SQL 加工 & 分析

• 租户内多计算实例架构：自动负载均衡、针对单个业务的并发能力可水平扩展

• 新增数据源类型：Hudi，MySQL

• 新增支持新建 Hudi 表、Insert 数据

• 新增支持 Hue 对接 HetuEngine，提供可视化 SQL 编辑页面

• 新增支持代理用户模式，支持对客户的自有用户体系的代理鉴权及审计

相关链接：https://support.huaweicloud.com/intl/zh-cn/cmpntguide-lts-mrs/mrs_01_1711.html

点击关注，第一时间了解华为云新鲜技术~