【Hudi】数据湖Hudi核心概念与架构设计总结

Hudi是现在非常热门的数据湖开源方案，非常适合于搭建一个数据湖平台。

有些人认为数据湖肯定与大数据技术体系完全不一样，是两个东西，甚至认为他俩没关系。

但是，你知道Hudi的全称叫啥么？就是“Hadoop Updates and Incrementals”

简单来说，就是基于Hadoop生态，支持HDFS的数据删除和增量更新的技术框架。

所以，Apache Hudi其实本就是从Hadoop生态里来的，依赖 HDFS 做底层的存储，所以可以支撑非常大规模的数据存储。同时基于update和Incrementals两个原语解决流批一体的存储问题：

• Update/Delete 记录：Hudi 支持更新/删除记录，使用文件/记录级别索引，同时对写操作提供事务保证。查询可获取最新提交的快照来产生结果。

• 变更流：支持增量获取表中所有更新/插入/删除的记录，从指定时间点开始进行增量查询，可以实现类似 Kafka 的增量消费机制。

Hudi设计原则

流式读/写：Hudi借鉴了数据库设计的原理，从零设计，应用于大型数据集记录流的输入和输出。为此，Hudi提供了索引实现，可以将记录的键快速映射到其所在的文件位置。同样，对于流式输出数据，Hudi通过其特殊列添加并跟踪记录级的元数据，从而可以提供所有发生变更的精确增量流。

自管理：Hudi注意到用户可能对数据新鲜度（写友好）与查询性能（读/查询友好）有不同的期望，它支持了三种查询类型，这些类型提供实时快照，增量流以及稍早的纯列数据。在每一步，Hudi都努力做到自我管理（例如自动优化编写程序的并行性，保持文件大小）和自我修复（例如：自动回滚失败的提交），即使这样做会稍微增加运行时成本（例如：在内存中缓存输入数据已分析工作负载）。如果没有这些内置的操作杠杆/自我管理功能，这些大型流水线的运营成本通常会翻倍。

万物皆日志：Hudi还具有 append only、云数据友好的设计，该设计实现了日志结构化存储系统的原理，可以无缝管理所有云提供商的数据。

键-值数据模型：在写方面，Hudi表被建模为键值对数据集，其中每条记录都有一个唯一的记录键。此外，一个记录键还可以包括分区路径，在该路径下，可以对记录进行分区和存储。这通常有助于减少索引查询的搜索空间。

Hudi表设计

Hudi表的三个主要组件：

1. 有序的时间轴元数据:类似于数据库事务日志。

2. 分层布局的数据文件:实际写入表中的数据。

3. 索引(多种实现方式):映射包含指定记录的数据集。

另外，针对数据的写入和查询，Hudi提供一些非常重要的功能例如upsert、mvvc等。

时间轴TimeLine

Timeline 是 HUDI 用来管理提交（commit）的抽象，每个 commit 都绑定一个固定时间戳，分散到时间线上。在 Timeline 上，每个 commit 被抽象为一个 HoodieInstant，一个 instant 记录了一次提交 (commit) 的行为、时间戳、和状态。HUDI 的读写 API 通过 Timeline 的接口可以方便的在 commits 上进行条件筛选，对 history 和 on-going 的 commit