DataLake | 青训营笔记

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

数据湖概念

数据库是一个集中存储各类结构化和非结构化数据的大型数据仓库，它可以存储来自多个数据源、多种数据类型的原始数据，数据无需经过结构化处理，就能进行存储，处理，分析和传输。

数据库与数据仓库与数据湖

首先，这三者是平行的三个概念，也就是说并不存在(或不一定存在)数据仓库或者数据湖是依赖于数据库的情况。他们各自有各自存储引擎的实现，并且他们面向的业务场景和功能效率都各不相同

数据湖的发展

lv 1

数据湖最开始的概念——分布式存储HDFS使用目录来区分不同的数据集

/douyin /20220623 /20220624/toutiao

好处:

• 同─公司/组织可以使用共享存储动
• 数据访问方便，灵活性高

坏处:

• 没有记录文件的schema(包括列名、列类型)，经常使用Schema on Query的方式
• 难以得知数据集包含了那些文件，是通过什么样的分区组织的
• 如果多个程序都在修改这个数据集（修改数据、修改表结构)，其他程序难以配合做修改(最终形成数据沼泽)

lv 2

数据湖的演进——Hive Metastore

对数据湖中的数据集进行集中“定义”：

• 数据湖中存在了哪些数据集
• 它们都存储在什么目录
• 数据集的schema是什么样子的
• 回数据集有哪些分区，每个分区的目录是什么

hive的架构存在两个重大的问题：

1. 读写同时进行时，会出现脏数据甚至错误
2. hive为了性能等问题，不允许删除某个元数据(可以简单当作在数据库中删除某列)，想要完成该需求，只能读出除开该元数据的其他数据，来然后写到另一张新表中，极大的消耗性能和存储空间

lv 3

湖仓一体（数据湖的现状)︰

• 结合了数据湖和数据仓库的优势

• 将数据仓库中对于数据的严格管理直接实现到了低 成本的分布式存储之上

• Key Features:

  • Transaction ACID
  • Schema管理
  • 的存储计算分离
  • 的支持多种计算引擎和文件格式

业界内三大湖仓一体的框架：

Hudi，Iceberg，Delta Lake

文件结构相关

简单来看他的存储格式与 mongodb 十分相似，这里就不多做赘述，具体聊聊读写相关的问题。

lv 1 - copy on write

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

这种方式的写入和更新会占据很大的空间，即便只修改一条数据，都需要将整个分区重新拷贝更新并储存。

lv 2 - merge on read

这个就是写入发现更新时，就会像日志一样写在另一个文件中，不再是将整个分区拷贝，然后更新存储。这就像是数据库备份的增量备份类似的原理，读的时候会将分区+文件一起读，然后根据优先级进行合并。

这样确实增加了部分读的压力，但是相比于减少的写的压力，就不值一提。

技术选型

短期来看:每个项目都有一些属于自己的功能:

• 心如果强需求Upserts，也许Hudi是最好的选择
• 如果希望可扩展性强，那么设计优良的lceberg是最好的选择
• 如果希望用上Z-Order等优化，那么掏钱买Databricks 的企业版 Delta是不二之选

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

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