可靠查询执行

概述

当集群中的节点因网络、硬件或软件问题发生故障时，在故障节点上运行任务的所有查询都将丢失。这可能会严重影响集群生产力并造成资源浪费，尤其对于长时间运行的查询。

解决这一问题的一种方法是自动重新运行受影响的查询。这减少了人工干预的需要，并提高了容错性，但同时会延长总执行时间。

为了保持执行可靠性同时实现更好的性能，openLooKeng中的分布式快照机制定期保存查询执行的完整状态的快照。发生错误时，查询可以从上一个成功的快照恢复执行。该实现基于标准Chandy-Lamport算法。

自版本1.2.0起，openLooKeng支持恢复任务和工作节点故障。

分布式快照适用于长时间运行的查询任务。该功能默认为禁用状态，可以通过会话属性snapshot_enabled启用或禁用。建议仅在对可靠性要求高的复杂查询场景下启用该功能。

要从之前保存的快照恢复执行，必须有足够数量的可用工作节点，以便恢复所有任务。要对查询启用分布式快照，有以下要求：

至少2个工作节点
至少之前80%的可用工作节点(向下舍入)仍处于活动状态，以便恢复成功。如果没有足够的工作节点可用, 查询将不能使用任何之前成功的快照进行恢复，查询将从头重新运行。

支持的语句：仅支持INSERT和CREATE TABLE AS SELECT类型的语句
- 不包括类似INSERT INTO CUBE的语句。
源表：只能从Hive目录中的表读取。
目标表：只能写入Hive目录中的表，格式为ORC。
与其他功能的交互：分布式快照目前无法与以下功能一起使用：
- 重用交换，即optimizer.reuse-table-scan
- 重用公用表表达式（CTE），即optimizer.cte-reuse-enabled

在启用分布式快照的情况下提交不满足上述要求的查询时，查询按未启用分布式快照功能的场景执行。

协调节点与远程任务之间的通信长时间失败时，将触发错误恢复，由query.remote-task.max-error-duration配置控制。

从保存的快照恢复查询执行时，任务可能会在与保存快照时不同的工作节点上调度。这意味着所有工作节点都必须能够访问保存的快照数据。

快照数据存储在使用hetu.experimental.snapshot.profile属性指定的文件系统中。

快照文件存储在文件系统的/tmp/hetu/snapshot/文件夹下。必须授权所有工作节点读取和写入此文件夹。

快照反映查询执行中的状态，可能会变得非常大，并且因查询而异。例如，需要缓冲大量数据的查询（通常涉及排序、窗口、连接、聚合等操作）可能会产生包含整个表数据的快照。执行前请确保共享文件系统有足够的可用空间来保存这些快照。

每次查询执行都可能生成多个快照。快照的内容可能会重叠。目前，快照以单独文件的形式存储。未来可能会引入“增量快照”功能，以节省存储空间。

从错误和快照中恢复需要成本。捕获快照需要时间，时间长短取决于复杂性。因此，需要在性能和可靠性之间进行权衡。

建议仅在必要时启用分布式快照，如运行时间较长的查询任务。对于这些类型的工作负载，捕获快照的开销可以忽略不计。

与分布式快照功能相关的配置可参见属性参考。