对于Hudi数据湖源端集成
- 将企业数据湖中以Hudi格式存储的数据集作为Kylin的源端输入
对于Kylin cube重新构建&合并优化
- 支持Kylin的Cuboid使用Hudi格式存储
- 使用Hudi的增量查询视图加速和优化Kylin cube重新构建过程,仅解析上次cube构建后变更的数据
- 使用Hudi的Compaction功能加速和优化Kylin Cube合并过程(针对增量cuboid文件),或者使用Hudi的Upsert功能来合并多个cuboid文件,类似Upsert到MOR表,并支持Select查询
- 不支持Hudi的其他类型的数据源(例如Kafka)不在此范围内
- 流式CubeEnginer不在此范围内
- 当前无论输入格式是否为Hudi,Kylin都使用Beeline JDBC机制直接连接到Hive源
- 当前的实现无法利用Hudi的原生和高级功能(例如增量查询、读优化视图查询等),Kylin可以从较小的增量cuboid合并和更快的源数据提取中受益
对于Hudi Source集成
新的方法
- 使用Hudi的原生优化视图查询和MOR表来加速Kylin的cube构建过程
为什么会成功
- Hudi已在大数据领取和技术栈中发布并成熟,许多公司已经在Data Lake/Raw/Curated数据层中使用了Hudi
- Hudi lib已经与Spark DF/Spark SQL集成,可以使用Kylin的Spark Engine查询Hudi数据源
- Hudi的Parquet基础文件和Avro日志以及索引元数据等都可以通过Hive的外部表和输入格式定义进行连接,Kylin可以利用它们进行提取
Hudi作为Cuboid存储
新的方法
- 使用Hudi的原生增量视图查询优化Kylin的cube重建过程,以仅捕获变更的数据并仅重新计算和更新必要的cuboid文件
- 使用Hudi的upsert功能来操作cuboid文件,以优化Kylin的cube合并过程;而不是以前的join和shuffle方式
为什么会成功
- Hudi根据记录的PK支持upsert,每个cuboid的维度key-id都可以视为PK
- 这样当进行重建和合并操作时,它可以直接更新以前的cuboid文件,或基于PK合并多个cuboid文件并将它们压缩为Parquet文件
- 如果在Kylin中启用了新的集成功能,从事数据挖掘/探索/报告等工作的数据科学家将有更快的cube集构建时间
- 正在开发DW/DM层数据建模的数据工程师将最大程度地减少cube上的单元测试/性能测试的实现和交付工作
没有其他风险,因为它只是配置Hudi源类型的替代选择,其他Kylin的组件和管道也不会受到影响
N/A
总体架构设计的逻辑图如下:
Hudi framework: https://hudi.apache.org/docs/
hive/spark integration support for Hudi: https://hudi.apache.org/docs/querying_data.html
原文:https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=KYLIN&title=KIP-5+Integration+with+Hudi