Hudi 的格式支持开发工作

Hudi 的格式支持开发工作主要对 FE/BE 在外表上的对应功能来针对性实现和优化。

FE 端改造：

1. 在外部表的元信息方面，增加存储 Hudi 特有的元信息：

表类型，用来存储 Hudi 表类型。取值为 COW 或 MOR；

Input Format，用来区分 MOR 的查询类型。Hudi 的 MOR 表在写入端（如 Spark）建表时，会额外生成

_rt 和 _ro 两张表，分别对应同一张 MOR 表的 Snapshot 查询表和 Read Optimized 查询表。Snapshot 查询表的 Input Format 信息取值为 org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat，Read Optimized 查询的 Input Format 信息取值为 org.apache.hudi.hadoop.HoodieParquetInputFormat；

数据文件元信息方面，增加 Optional 的 Delta Logs 文件列表字段，用来存储 Hudi MOR 表 Base 数据文件相对应的 Logs 更新文件信息。

2. 将 Hudi 元信息采集模块集成到全新 Catalog 框架内，只需要创建一次 Hudi Catalog，后续便可以直接查询该 Catalog 下的所有 Hudi 表，不再需要以前的手工创建外部表的繁琐过程。

(https://docs.starrocks.io/zh-cn/latest/data_source/catalog/hudi_catalog）

全新 Catalog 框架结构：

3. CBO 优化器和执行计划优化：

通过 Hive Metastore 读取和缓存 Hudi 分区信息，应用到分区数据裁剪优化规则里；

通过 Hive Metastore 读取和缓存 Hudi 表的相关统计信息，应用到 Join Reorder 等 CBO 优化规则里。

4. 表结构解析完成 Hudi 表字段类型映射：

通过读取 Hudi 表的 Avro Schema，在各个字段上完成 Hudi Type 到 StarRocks Type 映射，具体如下：

备注：即将发布的 StarRocks 2.5.0 版本会支持 Struct、Map 数据类型的读取，Hudi COW 表也会同步支持。

5. 平衡 IO 请求优化：

StarRocks 查询传统的 Hive 表的时候，若单个数据文件的大小过大，会对这个文件进行 File Split 均匀拆分，形成多个 Scan Range。但在 Hudi 表的实现里，我们直接对 Base file 和对应 Delta Logs（即 File Slice）形成一个 Scan Range，除了有潜在的 Merge 逻辑数据问题之外，还有 IO 效率取舍，即使做了 File Split 拆分，比如拆成 3 份，其对应的 Delta Logs 就需要跟着拆分后的 File Slice 重复读取 3 次，这很可能会加剧存储系统的压力。在工程实现上，我们在 Scan Range 里添加了 useJNIReader 的标识字段，用来指示 BE 侧执行选择 Native Reader 还是 JNI reader，这两个 Reader 的具体用途见下文 BE 端改造部分。

6. 元数据请求优化：

通过批量以及异步的方式访问 Hive Metastore 获取 Hudi 表分区统计信息，在 FE 对其进行缓存并计算表级别统计信息用于查询优化，同时缓存 Scan 节点所要扫描的文件元数据信息来减少 Namenode 的压力并提升查询速度。用户可通过查询来触发元数据的异步加载，使得用户无需手动刷新元数据即可访问最新数据文件。