这是我参与「第四届青训营 」笔记创作活动的第11天
1. 数据湖发展阶段
1.1 Hadoop：HDFS 使用不同的目录来区分数据集
优点
- 同一公司/组织可以使用共享存储
- 数据访问方便，灵活性高
缺点
- 没有记录文件的schema（包括列名、列类型），经常使用Schema on Query的方式
- 难以得知数据集包含了哪些文件，是通过什么样的分区组织的
- 如果多个程序都在修改这个数据集（修改数据、修改表结构），其他程序难以配合做修改
1.2 Hive：对数据湖的演进 - Hive Metastore
优点
- 对数据湖中的数据集进行集中“定义”，包括数据湖中有哪些数据集；存储在什么目录；数据集的schema 是怎样的；数据集有哪些分区，分区目录是什么。
缺点
- 仍存在读写冲突
- Hive 不支持删列，只能重建新表。
1.3 湖仓一体
- 湖仓一体是一种结合了数据湖和数据仓库优势的新范式，在用于数据湖的低成本存储上，实现与数据仓库中类似的数据结构和数据管理功能。
- 湖仓一体是一种更开放的新型架构，有人把它做了一个比喻，就类似于在湖边搭建了很多小房子，有的负责数据分析，有的运转机器学习，有的来检索音视频等，至于那些数据源流，都可以从数据湖里轻松获取。
2.核心技术
2.1 Time travel
- 每次写入都生成-一个新的元数据文件，记录变更
- 分区数据在Update时，不要删除旧数据，保证新旧共存
- 元数据中存储具体的文件路径，而不仅仅是分区文件夹
2.2 Transaction：事务性，数据湖的 ACID
- 原子性：写入要么可见要么不可见，先写入 parquet 文件，以 Hash.parquet 文件存储，写完后写 Hash.json，写完后尝试重命名为版本号.json，如果失败就无法 commit，新写入在没有 commit 前用户无法读取（用户只读当前 最大版本号.json）
- 一致性：计算引擎保证
- 事务隔离：读写和写写冲突，由于新写入不替换原数据，故读写冲突已解决。Update 时采用乐观锁，先全写文件，进入写 json，看版本号有无变化，若变化，查看新增版本是否更新我要更新的分区，没有则写新版本，有则重新 update。
- 持久性：存储引擎保证
2.3 Schema Evolutio
-
用户不直接读 parquet 文件，通过数据湖接口读取分区 parquet，数据湖读取时在 schema 上处理。
-
ID 将 data 和 metadata 的列名一一对应，删除 ID 不会复用，写入数据时，ID 写入数据文件，读取时：
- Data 没有 metadata 有：ADD
- Data 有 metadata 无：DROP（读取时不读）
- Data 有 metadata 有但名字不同：RENAME
- 新增列赋予新ID，删除过的ID不再用
- 将ID写入数据，用于判断数据版本
- Data 是 parquet数据文件 —— 先写入
- Metadata 是 Json 元数据文件 —— 后写入
2.4 经典的数据湖
Hudi（Uber 开发，数据写入低延迟）、Iceberg（Netflix 开发，摆脱 Hive 架构的问题）、Delta Lake（databricks 开发，主打湖仓一体）
3. 设计一个简单的数据湖
3.1 文件结构
写入数据湖时:
- 按照每条数据的date进行分区
- 额外使用metadata文件记录表信息
3.2 Time travel
- 每一次写入操作，创建一个新的json文件，以递增版本号命名，记录本次新增/删除的文件
- 每当产生N个json，做一次聚合，记录完整的分区文件信息
- 用checkpoint记录上次做聚合的版本号
要点:
- 每次写入都生成一个新的元数据文件，记录变更
- 分区数据在Update时，不要删除旧数据，保证新旧共享
- 元数据中存储具体的文件路径，而不仅仅是分区文件
3.3 Transaction
ACID：是指数据库在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特性。
以A给B转账10元为例：
- Atomicity:原子性--要么A-10 B+10,要么都不变
- Consistency:一致性--不可以A-10 B+5
- Isolation：事务隔离--A和C同时给B转10，B最终结果应是+20
- Durability：持久性--转账服务器重启，结果不变
数据湖中的ACID:
- Atomicity:原子性--本次写入要么对用户可见，要么不可见(需要设计)
- Consistency:一致性--输入是什么，落盘的就是什么(由计算引擎保证)
- Isolation:事务隔离--正确解决读写冲突和写写冲突(需要设计)
- Durability:持久性--落完数据后，即便服务器重启结果不变（由存储引擎保证)
3.4 选型标准
- 项目功能
- 如果强需求Upserts，Hudi更适合
- 如果希望可扩展性强，Iceberg更适合
- 如果希望用上Z-Order等优化，Databricks 的企业版Delta更适合
数据湖取代Hive，成为HDFS上的表格式标准是必然的，在选择之前问自己四个问题:
- 需要的feature在哪个数据湖上是最稳定的
- 哪个数据湖能够用最简单的接入方式( SQL )用上最完善的功能
- 哪一个数据湖有计算引擎和社区的支持
- 哪一个数据湖的版本管理做的最好
总结
- 数据湖的最新发展状态是湖仓一体
- 数据湖以低存储成本提供了ACID Transaction. Schema evolution. Time travel等高级功能
