这是我参与「第四届青训营」笔记创作活动的的第11天，以下是我的课堂笔记。本次课程主要分为四个大板块：
1.发展历史
2.核心技术
3.各有所长
4.总结场景

1.发展历史

1.1数据湖发展阶段-Hadoop

数据湖最开始的概念——分布式存储HDFS
使用目录来区分不同的数据集
好处:
同一公司/组织可以使用共享存储
数据访问方便，灵活性高动坏处:
1.没有记录文件的schema(包括列名、列类型)，经常使用Schema on Query的方式
2.难以得知数据集包含了那些文件，是通过什么样的分区组织的
3.如果多个程序都在修改这个数据集（修改数据、修改表结构)，其他程序难以配合做修改

1.2数据湖发展阶段2- Hive

数据湖的演进——Hive Metastore
对数据湖中的数据集进行集中“定义”
的数据湖中存在了哪些数据集它们都存储在什么目录
数据集的schema是什么样子的
的数据集有哪些分区，每个分区的目录是什么

1.3数据湖发展阶段3-湖仓一体

题外话——数据仓库
动什么是数据仓库?
数据仓库将数据从数据源提取
和转换，加载到目的地动数据仓库存储+计算不分离
数据仓库严格控制写入数据的 schema

1.4业界三大数据湖

公司简介:
国外版滴滴，打车软件
在行程规划、拼车、顺风车等业务上数据量都很大数据写入面临挑战

项目简介:
项目名称:Hudi
最初希望解决的问题:使数据写入能够更低延迟
开源时间:2016年
官网: hudi.apache.org/
Github: github.com/apache/hudi

公司简介:流媒体
《纸牌屋》、《鱿鱼游戏》、《怪奇物语》
开发工作:存储用户观看数据，推荐剧集

项目简介:
名称:lceberg开源时间:2018
最初希望解决的问题:拜托Hive架构带来的问题
官网: iceberg.apache.org/
Github: github.com/apache/iceb…

公司简介:
的起源于UCB，参与Spark的制作
超级独角兽
主打湖仓一体

项目简介:
动项目名称: Delta Lake
开源时间:2019(开源了，但没完全开源)
官网: delta.io/
Github: github.com/delta-io/de…

1.5 关于“数据湖”

数据相关概念比较新，一直处在演进当中
一开始是HDFS，裸pb、txt日志等等，叫数据湖(管不动了就叫数据沼泽)
后来出现了了lceberg、Hudi、Delta Lake了，数据湖概念就基本等于这些产品了
也更贴近于Lakehouse的概念\

2. 核心技术

2.1文件结构

写入数据湖时
1．按照每条数据的date进行分区
2．额外使用metadata文件记录表信息，如下图所示

2.2 Time travel

要点:
1.每次写入都生成一个新的元数据文件，记录变更
2.分区数据在Update时，不要删除旧数据，保证新旧共存
3．元数据中存储具体的文件路径，而不仅仅是分区文件夹\

2.3 Transaction

ACID，是指数据库在写入或更新资料的过程中，为保证事务是正确可靠的,所必须具备的四个特性。以A给B转账10元为例:

Atomicity: 原子性——要么A-10 B+10，要么都不变2. Consistency:一致性——不可以A-10 B+5
lsolation:事务隔离——A和C同时给B转10，B最终结果应是+204. Durability:持久性——转账服务器重启，结果不变

数据湖中的ACID:

Atomicity: 原子性–本次写入要么对用户可见，要么不可见(需要设计)
Consistency:一致性–输入是什么，落盘的就是什么(由计算引擎保证)
Isolation:事务隔离–正确解决读写冲突和写写冲突(需要设计)\
Durability:持久性–落完数据后，即便服务器重启结果不变(由存储引擎保证)

2.4 Schema Evolution

Add/Drop/Rename
重要:
√用户并不直接读取parquet文件本身，而是通过数据湖接口读取，如Dataset ds = simpleDataLake.read(mytable).option(date=2020-01-01)
√数据湖内部会读取应该读的parquet，并在schema上做进一步处理\

3. 各有所长

3.1 Iceberg工作重点

用户体验

Schema evolution
Partition evolution
Hidden partition
Time Travel
Version Rollback

性能
1．快速file plan
2．更多的filter方式
可靠性

ACID Transaction

完全开源，由Apache孵化开发

3.2 Hudi

Hadoop Upsert Delete and Incremental
Hudi工作重点:

Timeline service: Hudi 管理transaction的方式
Hudi Table Type: Copy on Write / Merge on Read 3．高效的Upserts: update or insert 4.索引表:快速定位一条数据的位置
Streaming Ingestion Service6.完全开源，由Apache孵化

3.3 Delta Lake工作重点

ACID Transaction
Schema校验(不是evolution)
流批一体
Time Travel
Upsert/Delete
Z-Order优化
只开源了一部分，由Databricks自己主导开发，Z-order等优化的实现未开源

4. 总结场景

4.1回顾:三个数据湖的异同

4.2三个数据湖的热度

4.3技术选型

短期来看:每个项目都有一些属于自己的功能:
如果强需求Upserts，也许Hudi是最好的选择
如果希望可扩展性强，那么设计优良的lceberg是最好的选择
的如果希望用上Z-Order等优化，那么掏钱买Databricks的企业版 Delta是不二之选

长期来看:数据湖取代Hive，成为HDFS上的表格式标准是必然的，在选择之前问自己四个问题:

我需要的feature在哪个数据湖上是最稳定的
哪一个数据湖能够用最简单的接入方式(SQL)用上最完善的功能
哪一个数据湖有计算引擎侧的支持和社区的支持
哪一个数据湖的版本管理做的最好，最鲁棒

4.4 字节跳动数据湖场景举例

批流一体:近实时的数据写入与数据就绪(Readiness)

例子:消息队列直接入湖、流式 Upsert
应用:能同时训最新(流式)和历史(批式)

更强的算力:要求更快的读数据
1.例子:分布式任务扫描、向量化读与读时合并、统一内存格式(Apache Arrow) 2．应用:数据读取不应成为训练瓶颈

数据湖三剑客: Delta Lake、 Hudilceberg详解 | 青训营笔记