数据湖三剑客：Delta Lake、Hudi 与 Iceberg 详解|青训营笔记

脑袋困掉
299 阅读3分钟

这是我参与「第四届青训营」笔记创作活动的的第14天！

前言

内容包括 数据湖基本概念和发展历史、数据湖核心技术、数据湖三剑客特点。

数据湖基本概念和发展历史

Hadoop

数据湖最开始的概念---分布式存储HDFS

好处：同一公司/组织可以使用共享存储；数据访问方便，灵活性高

坏处：没有记录文件的schema、难以得知数据集包含哪些文件，是通过什么样的分区组织的、如果多个程序都在修改这个数据集，其他程序难以配合做修改

Hive

数据湖的演进---Hive Metastore（元数据存入mysql中）

对数据湖中的数据集进行集中定义

问题： 静态表------读取方便，有写操作，不同用户读取的文件可能不同(读写冲突、写写冲突) 对于schema数据，只能在尾列后面增加列而不能删除或修改列------------重写一张表（支持更多样的schema变更）

湖仓一体

数据仓库

数据仓库将数据从数据源提取和转换，加载到目的地 数据仓库存储+计算不分离 数据仓库严格控制写入数据的schema 3. 湖仓一体

  1. 结合数据湖和数据仓库的优势
  2. 将数据仓库中对于数据的严格管理直接实现到了低成本的分布式存储上
  3. 特点：ACID、Schema管理、存储计算分离、支持多种计算引擎和文件格式

数据湖核心技术

Time Travel

更新数据，新数据和旧数据同时跑一下训练

  1. 每次写入都生成一个新的元数据文件，记录变更（以递增版本号命名，记录本次新增/删除的文件）
  2. 分区数据在Update时，不删除旧数据，保证新旧共存
  3. 元数据中存储具体的文件路径，而不仅仅是分区文件夹
  4. 每当产生N个json，做一次聚合，记录完整的分区文件信息
  5. 用checkpoint记录上次做聚合的版本号

ACID Transaction

解决多用户的写写冲突、读写冲突

  1. 一致性：输入是什么，落盘就是什么（计算引擎保证）
  2. 持久性：落完数据后，即便服务器重启结果不变（存储引擎保证）
  3. 原子性：本次写入要么对用户可见，要么不可见（需要设计）
  1. 写入流程：先写parquet数据文件、写入json文件（hash,rename；rename成功视为commit）
  2. 从用户可见性入手确保原子性，解决读写冲突
  1. 事务隔离：正确解决读写冲突和写写冲突（需要设计）
  1. 同时update/delete和Insert才会产生冲突
  2. Update写入流程：
  3. 乐观锁把文件全部落盘，进入写json阶段
  4. 版本号未增加，直接写新版本；否则看新版本更新的分区和自己更新的分区是否一样，不一样直接写新版本，否则重新update操作

Schema Evolution

删除列（手机号）

  1. 用户并不直接读取parquet文件本身，而是通过数据湖接口读取
  2. 数据湖内部会读取应该读的parquet，并在schema上做进一步处理
  3. ID将data和metadata的列名做一一对应
  4. 唯一确定的ID，新增列赋予新ID，删列ID不复用
  5. 写入数据时，ID也写入数据文件
  6. 读取数据时，用ID做映射
  1. Data中没有，metadata中有：ADD
  2. Data中有，metadata中没有：DROP
  3. Data和metadata中都有同一ID，但是name不同：RENAME
  4. 如果都有同一列名，而ID不同：先删后加

总结

数据湖是一个不断更新的概念，最新发展状态是湖仓一体，重点了解目前业界三大数据湖的特点和代表性技术。

avatar
文章
阅读
粉丝