​

引言

在数据库和数据湖系统中，为了保证极致且稳定的查询性能，数据需要以指定方式进行组织（Data Layout）并存储，如分区分桶、排序、索引等。而在实际生产环境中，数据往往在不同时间、以各种的方式持续进入系统，打破已有数据组织的平衡，导致查询性能衰减。因此，数据库和数据湖系统需要有数据再组织能力，在数据不断流入的同时，持续优化 Data Layout，提供一致且可预期的高效性能。

本期，我们邀请质变科技AI-ready数据云团队布道师万确、胡一刀为大家分享话题《Auto Table Service》。

在 Relyt AI-ready Data Cloud 中，数据存储组织优化的能力由 Table Service 模块提供。同时，该模块全面负责数据维护，处理如数据生命周期、数据清理、统计信息收集等任务。Table Service 可由用户手动触发，也可由系统后台（AutoTableService）自适应触发。

本文将从整体架构、Data Layout 优化策略、Conflict-Free 事务模型三方面，介绍 Relyt Table Service 模块。

架构

Relyt 将 Table Service 中的各项任务抽象为独立 Task，并进行统一编排调度。例如，数据再组织任务由 PLAN Task 和 MERGE Task 两个独立 Task 来实现。其中，PLAN Task 根据数据元信息和策略配置，决定哪部分数据文件的 Data Layout 需要进行优化。MERGE Task 根据 PLAN Task 执行结果，真正执行数据重写，并切换数据版本。除了 PLAN / MERGE Task，Relyt 还实现了若干其他 Task，例如：

• GC Task：旧版本（元）数据回收

• STATS Task：统计信息收集

• INDEX Task：索引构建

​

细粒度的任务划分，不仅有助于简洁清晰的调度逻辑，同时支撑了弹性的任务分发与执行。下图为 Relyt Table Service 调度的示意图，Master 上的 Table Service Scheduler 负责整体调度，根据任务特点和集群负载情况，分发 Task 至 Hybrid DPS（HDPS）或 Extreme DPS（EDPS）执行：

• HDPS（常驻资源）：适合执行轻量任务，如 PLAN/GC Task 等；

• EDPS（弹性资源）：适合执行重 IO / 重 CPU 任务，如 MERGE/INDEX Task 等。

​

其中，EDPS 资源弹性拉起，隔离执行 Table Service Task，不影响用户线上查询。并在执行完成后，自主秒级回收，实现按需按量支撑 Table Service 执行。

 Data Layout 优化策略

PLAN Task 以最优化查询性能为最终目标，根据数据文件当前的状态，按照若干既定的策略生成 MERGE Task，来改善优化 Data Layout。

小文件策略

小文件直接影响查询性能与元数据负担。该策略检查表当前的小文件个数，当达到阈值时，生成 MERGE Task 对其进行合并。

Cluster Key 策略

数据存储的有序性直接影响查询裁剪效率，进而影响查询性能。Relyt 在元数据中存储了表 Cluster Key 列的 min/max，并用于查询裁剪加速。依据该元数据，PLAN Task 可计算出表在 Cluster Key 列上的重叠度（Overlap Depth），判断数据整体的有序性。如下图中，数据文件在 id 列上的 Max Overlap Depth 为 3。

​

Cluster Key 策略针对 Overlap Depth 超过阈值的场景，生成 MERGE Task 对相关文件（如图中的 File 0、File 1、File 2）进行合并，降低重叠度，提高数据整体有序性，提升查询裁剪的过滤度。

Deleted Tuple 策略

Relyt 中对数据的删除不会即刻反映在数据文件中，而是通过标记删除的方式，在读时进行过滤。因此，当数据文件中被删除的行过多时，会影响查询性能。Deleted Tuple 策略会监控删除行占比，当占比达到阈值时生成 MERGE Task 对该文件进行重写，真正抹除被删除的数据。

其他策略和约束

• Task IO 限制

  约束 MERGE Task 重写数据文件的整体 IO 量，控制单个任务执行的最大耗时。以“小步快跑”的方式，渐进式优化表的 Data Layout 至最优。

• 时间因子

  对各个策略中使用到的阈值，增加时间因子。例如，在 Deleted Tuple 策略中，针对老数据文件（如 7 天前生成的数据文件），使用更严格的阈值（如 5%）进行判定，以保证随着时间流逝，表中的所有标记删除行都能够被清理。

• 调度权重

  依据理论的查询耗时模型，计算 MERGE Task 执行前后对相同数据的查询耗时，并将查询耗时提升量归一化后作为任务分数。该分数将用于全局 MERGE Task 调度权重，确保更有价值的 MERGE Task 被优先调度执行。

• 策略组合

  工程实现上，PLAN Task 支持对各个策略进行组合并同时生效，新策略也可以根据业务场景进行定制化开发，并插件化安装生效。

 Conflict-Free 事务模型

Relyt 支持 ACID 事务特性，保证大规模并发场景下的数据一致性、完整性与可靠性，正确处理并发写入、删除等场景。Table Service 作为后台任务，逻辑上不会修改用户数据，仅对数据做搬迁、重写等。但当用户 SQL 与后台 Table Service Task 并发时，可能存在如下场景：

• File 1 和 File 2 正在被 MERGE Task 重写至新文件 Target File

• 用户 Delete SQL 并发删除 File 1 与 File 2 中的部分行

​

若不处理该并发场景，则会导致用户 Delete 结果丢失：MERGE Task 执行完成后，新旧版本数据切换（Target File 替代 File 1 & File 2），但应该被删除的数据（红色行）仍然被保留在数据文件中。

针对这种场景，普通的解法包括：

• 让其中一个事务 Abort，例如后提交的事务检查修改集，如发现冲突则 Abort；

• Table Service Task 检测并发用户 SQL，并尝试等待用户 SQL 结束后再提交。

但这两种解法存在一定缺陷：前者会影响用户体验，后者会导致 Task Starving，即一直在等待无法完成。

Relyt 针对该场景设计了补偿机制，实现 TableService 与用户事务 Conflict-Free，做到二者完全并行互不冲突。

补偿的核心逻辑是让后提交的事务 Replay Delete，将删除行应用到最新版本的文件上。如下图所示，Case 1 中 Delete Commit 时会将本事务删除的行，在 MERGE Task 产生的 Target File 中找到并进行删除。Case 2 中 MERGE Task Commit 时会将本事务执行过程中，并发事务对输入文件（File 1&File 2）的删除应用到 Target File。

直观上，Reply Delete 是一个重 IO 执行逻辑，会阻塞事务 Commit。但依靠 Relyt 元数据设计与标记删除机制，Reply Delete 在实现上是一个相对轻量的元数据操作。同时，MERGE Task 在生成时附加有 IO 限制，故与并发事务的冲突概率及冲突行数有上限。在实际生产中，依靠补偿机制能够实现 Table Service 对用户完全无感。

 结语

在现代数据库和数据湖系统中，Data Layout 和数据再组织是确保数据高效管理和查询性能的核心要素。Table Service 能力的深化也是目前市场上各产品的发力点之一，如 Snowflake micro-partition, DeltaLake Liquid Clustering 等。

Relyt AI-ready Data Cloud​​​​​​​的 Table Service 模块通过细致的任务划分和优化策略，渐进式地动态调整数据布局，确保系统始终保持高效的查询性能。此外，补偿机制有效解决了 Table Service 与用户事务的冲突，实现了无感知的后台数据维护。这种设计不仅提升了系统的稳定性和性能，还为用户提供了更流畅的使用体验。

​