数据湖三剑客
湖仓一体
数据仓库
- 数据仓库将数据从数据源提取和转换，加载到目的地
- 数据仓库存储+计算不分离
- 数据仓库严格控制写入数据的schema
湖仓一体
- 结合数据湖和数据仓库的优势
- 将数据仓库中对于数据的严格管理直接实现到了低成本的分布式存储上
- 特点：ACID、Schema管理、存储计算分离、支持多种计算引擎和文件格式
数据湖三剑客特点 Iceberg
传统的分区：数据中包含date列，按照date分区，如果希望按照hour分区，需要新增hour列 数据中包含timestamp列，设置好partition transform方式，iceberg会转换为对应的分区 按需进行partition evolution
Hudi Timeline Service：记录的信息类似于metadate Upsert：update、insert Incremental：某个时间点后新增的数据 Copy on Write 在更新一个分区时，将原来的数据全部读出做加工（更新）再全部写进去 缺陷：有时候只是更新几列数据，但是需要把数据全部读出来
Merge on Read
- 原始数据更新部分写入单独文件，读取时原始文件和小文件都读，以PK做merge
数据湖核心技术 Time Travel 更新数据，新数据和旧数据同时跑一下训练
每次写入都生成一个新的元数据文件，记录变更（以递增版本号命名，记录本次新增/删除的文件） 分区数据在Update时，不删除旧数据，保证新旧共存 元数据中存储具体的文件路径，而不仅仅是分区文件夹 每当产生N个json，做一次聚合，记录完整的分区文件信息 用checkpoint记录上次做聚合的版本号 ACID Transaction 解决多用户的写写冲突、读写冲突
一致性：输入是什么，落盘就是什么（计算引擎保证） 持久性：落完数据后，即便服务器重启结果不变（存储引擎保证） 原子性：本次写入要么对用户可见，要么不可见（需要设计） 写入流程：先写parquet数据文件、写入json文件（hash,rename；rename成功视为commit） 从用户可见性入手确保原子性，解决读写冲突 事务隔离：正确解决读写冲突和写写冲突（需要设计）
同时update/delete和Insert才会产生冲突 Update写入流程： 乐观锁把文件全部落盘，进入写json阶段 版本号未增加，直接写新版本；否则看新版本更新的分区和自己更新的分区是否一样，不一样直接写新版本，否则重新update操作 Schema Evolution 删除列（手机号）
用户并不直接读取parquet文件本身，而是通过数据湖接口读取 数据湖内部会读取应该读的parquet，并在schema上做进一步处理 ID将data和metadata的列名做一一对应 唯一确定的ID，新增列赋予新ID，删列ID不复用 写入数据时，ID也写入数据文件 读取数据时，用ID做映射
