这是我参与「第四届青训营 」笔记创作活动的的第11天。
本节课程主要分为 4 个方面：
1.发展历史
2.核心技术
3.各有所长
4.总结场景
一.发展历史
1.1.数据湖发展阶段-Hadoop
▲ 数据湖最开始的概念--分布式存储HDFS
▲ 使用目录来区分不同的数据集
○/douyin
●/20220623
○/toutiao
▲好处：
○ 同一个公司/组织可以使用共享存储；
○ 数据访问方便，灵活性高。
▲坏处：
○ 没有记录文件的schema(包括列名、列类型)，经常使用Schema on Query的方式；
○ 难以得知数据集包含了哪些文件，是通过什么样的分区组织的；
○ 如果多个程序都在修改这个数据集(修改数据、修改表结构)，其他程序难以配合做修改。
1.2.数据湖发展阶段2-Hive
▶ 数据湖的演进--Hive Metastore
▶对数据湖中的数据集进行集中"定义"
● 数据湖中存在了哪些数据集
● 它们都存储在什么目录
● 数据集的schema是什么样子的
● 数据集有哪些分区，每个分区的目录是什么
1.3.数据湖发展阶段3-湖仓一体
▼ 什么是数据仓库？
◎ 数据仓库将数据源提取和转换，加载到目的地；
◎ 数据仓库存储 + 计算不分离；
◎ 数据仓库严格控制写入数据的schema。
▼ 湖仓一体(数据湖的现状)
◎ 结合了数据湖和数据仓库的优势
◎ 将数据仓库中对于数据的严格管理直接实现到了低成本的分布式存储之上
◎ Key Features：
▫ Transaction ACID
▫ Schema管理
▫ 存储计算分离
▫ 支持多种计算引擎和文件格式
1.4.业界三大数据湖
▼ Hudi
▼ Iceberg
▼ Delta Lake
1.5.关于"数据湖"
◀ 数据相关概念比较新，一直处在演进当中
◀ 一开始是HDFS，裸pb、txt日志等等，教数据湖(管不动了就叫数据沼泽)
◀ 后来出现了Delta Lake、Hudi、Iceberg了，数据湖概念就基本等于这些产品了
◀ 也更贴近于Lakehouse的概念
二.核心技术
2.1.文件结构
写入数据湖时：
■ 按照每条数据的data进行分区
■ 额外使用metadata文件记录表信息
2.2.Time travel
□ 每一次写入操作，创建一个新的json文件，以递增版本号命名，记录本次新增/删除的文件；
□ 每当产生N个json，做一次聚合，记录完整的分区文件信息；
□ 用checkpoint记录上次做聚合的版本号。
2.3.Transaction
ACID：是指数据库在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特性。
△ Atomicity：原子性
△ Consistency：一致性
△ Isolation：事务隔离
△ Durability：持久性
2.3.1.原子性
◆ 写入流程：
◌ 写入parquet数据文件
◌ 写入json元数据文件
◆读写冲突已经被解决：
◌ 新的写入除非已经commit，否则用户读不到
◌ 用户正在读的分区，被另一个写入进行了更新，数据不会进行替换，而是共存。
2.3.2.事务隔离 1).从最新的版本中，获取需要update的分区；
2).乐观锁先把该写入的文件全落盘，然后进入写json阶段；
3).分几种情况
▷ 发现版本号和一开始没区别，直接写新的版本。
▷发现版本号增加了，看看新增的这些版本有没有更新我要更新的分区
◇ 没有，直接写新的版本。
◇ 有，两者都更新了同一分区，得重新update了。
2.4.Schema Evolution
ID将data 和 metadata的列名做一一对应。
▷ 唯一确定的ID，新增列赋予新ID，删列ID不复用；
▷ 写入数据时，ID也写入数据文件；
▷ 读取数据时，用ID做映射，如果：
◌ Data中没有，metadata中有：ADD
◌ Data中有，metadata中没有：DROP
◌ Data和metadata中都有同一ID，但是name不同：RENAME
◌ 如果都有同一列名，而ID不同？
三.各有所长
3.1.Iceberg工作重点
◉ 用户体验：
1.Schema evolution
2.Partition evolution
3.Hidden partition
4.Time Travel
5.Version Rollback
◉ 性能：1.快速file plan
2.更多的filter方式
◉ 可靠性：1.ACID Transaction
◉ 完全开源，由Apache孵化开发
3.1.1.Well-designed Metadata Layer
○ Metadata files定义了表结构，存储了snapshot信息，分区列信息等；
○ Manifest lists存储了一个snapshot中所有manifest的信息；
○ Manifests存储了一些data files的信息；
○ Data files就是具体的数据文件。
3.1.2.Data File Filter
○ Manifests files记录了每个data file的分区范围；
○ Manifest lists记录了每个manifest file的分区范围分区可以快速定位！可以做manifest list级别裁剪；
○ Manifests files记录了每个data file每一列的最大值，最小值可以通过其他的列(Useld)做data file级别裁剪。
3.1.3.Hidden Partition
▶ 传统的分区方式
▪ 数据中包含了date列，则按照date分区；如果希望按照hour分区。则需要新增hour列。
▶ IceBerg的分区方式
▪ 数据中包含timestamp列，设置好partition transform方式
◎ 设置为date时，iceberg帮你转化为date分区
◎ 设置为hour时，iceberg帮你转化为hour分区
▪ Iceberg记录了这层转化关系，并且按你的需求进行partition evolution
3.2.Hudi 工作重点：
▲ Timeline service：Huid管理transaction的方式
▲ Huid Table Type：Copy on Write/Merge On Read
▲ 高效的Upsets：update or insert
▲ 索引表：快速定位一条数据的位置
▲ Streaming Ingestion Service
▲完全开源，由Apache孵化
3.2.1.Timeline Serivce & Upsert & Incremental
✔ Timeline Serivce：记录的信息类似于metadata
✔ Upsert：每一条样本都有一个主键PK，当U配色让它一条数据时，如果现有的数据中有这个PK，则update这条数据。否则直接insert这条数据。
✔ Incremental：某个时间后新增
3.2.2.Copy on Write
3.2.3.Merge On Read
3.3.Dalta Lake工作重点
● ACID Transaction
● Schema校验(不是evolution)
● 流批一体 ● Time Travel
● Upsert/Delete
● Z-Order优化
● 只开源了一部分，由Databricks自己主导开发，Z-order等优化的实现为开源
3.3.1.流批一体
四.总结场景
4.1.回顾：三个数据湖的异同
4.2.三个数据湖的热度
4.3.技术选型
▶ 短期来看：每个项目都有一些属于自己的功能
▶ 长期来看：数据湖取代Hive，成为HDFS上的表格式标准是必然的，在选择之前问自己四个问题
4.3.1.字节跳动数据湖场景举例-Feature Store
□ 初心：
◎ instead pb样本读放大、不能列裁剪=>很难落许多特征进样本
◎ instead pb样本写放大、copy-on-write=>很难做特征回溯
□ 收益：
◎ 支持落原始特征做特征调研
◎ 解决读放大、支持列裁剪
◎ 解决写放大、支持merge-on-read
◎ 支持特征schema校验
◎ 列式存储优化存储空间
◎ Arrow格式优化序列开销
□ Feature Store及其平台
◎ 基于Apache Iceberg做了大量定制与优化
◎ 站内存储约220PB训练样本：
✔ 最大单表30PB，15K个特征
✔ 相比instance pb样本能节省约30% ~ 50%空间
◎ 平台端到端体验完整、用户使用成本低：
✔ 控制面板,特征监控,数据维护(样本回溯,TTL,脏数据处理等)
◎ 对特征回溯及特征调研场景做了专门强化
✔ 支持Update语义操作和数据分支
