这是我参与「第四届青训营」笔记创作活动的第11天
写在开头的一点听课感想
本节课的讲师的授课风格给我印象很深刻。尤其是讲核心设计思想那里，用一个自己设计数据湖的场景作为引入，以解决业务需求为导向，告诉我们会存在什么问题，解决问题的可行思路有哪些。还有最后的交流答疑环节，临场发挥其实非常考验知识功底。
数据湖发展阶段
Hadoop
缺点:数据沼泽
- 难以直观得知数据集包含的文件及分区组织方式
- 并发处理问题
Hive Metastore
改进:支持数据集定义，说明目录、schema 、分区 缺点: 并发处理问题 改进:引进数据库的ACID 缺点：Hive只支持在表末尾增列，不支持删列（需要改表时只能重新建，耗费资源）
湖仓一体
湖和仓在成本、存储计算分离和ACID上相互补充。
现状
- 将数据仓库中对于数据的严格管理直接实现到低成本的分布式存储之上
- 关键特性
- 事务ACID
- Schema 管理
- 存储计算分离
- 支持多种计算引擎和文件格式
业界三大数据湖
- Hudi(数据写入低延迟）
- iceberg(摆脱hive架构问题）
- Delta Lake（！暂时不完全开源）
如何通俗理解数据湖
核心技术————场景模拟：设计一个简单的数据湖
需求1：分区要求、能更新数据
解决方案：
- 按date进行分区
- 额外使用如图所示的metadata记录数据
需求2：新旧并存
解决方案：
- 每次写入都生成一个新的metadata文件，并记录具体的文件路径
- 不删除旧数据 具体实现：
需求3：解决多人协作时的读写冲突
解决方案：事务ACID问题，其中C和D分别由计算引擎和存储引擎保证
- 如何保证原子性？
- 如何保证隔离性？
需求4：可轻松删除某一列
明确：
- 用户不直接读取parquet文件本身，而是通过数据湖接口读取。
- 数据湖内部会读相应parquet，并在schema上作进一步处理。 解决方案：用id将data和metadata的列名一一对应 应用举例：
- add：data无，metadata有
- drop：data无，metadata有
- rename:data和metadata中的id同，但名字不同
- 两者id不同，但名字同：先drop后add，虽然名字同，但已经不是同一个了
iceberg详细介绍
关于partition: 传统分区是希望按xx分区，如果没有xx，就只能自己新建一个。 iceberg是利用timestamp，有分区转换机制，你想要什么分区，就帮你转化为什么分区。
关于Hudi
名字释义：Hadoop Upsert(update、insert) Delete andIncremental
三个数据库的性能对比及选型考虑
性能对比
目前看来似乎iceberg最好
发展趋势
但事实上Hudi热度最高，发展势头最猛
选型考虑
- upsert:Hudi是强项
- 可扩展性（高度可定制）：iceberg
- 有z-order等功能：企业版lake delta
从长远来看，还要考虑以下几个因素：
