数据湖三剑客：Delta Lake、Hudi 与 Iceberg 详解

看不懂的猫头
582 阅读17分钟

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

概述

2022の夏天，半壶水响叮当的我决定充实一下自我

回顾

image.png

一、内容介绍

    青训营

导读

来自36氪

  • 数据库行业正走向分水岭。
  • 过去几年，全球数据库行业发展迅猛。2020年，Gartner首次把数据库领域的魔力象限重新定义为Cloud DBMS，把云数据库作为唯一的评价方向；2021年，Gartner魔力象限又发生了两个关键的变化：1、Snowflake和Databricks两个云端数据仓库进入领导者象限；2、放开了魔力象限的收入门槛限制，SingleStore、Exasol、MariaDB、Couchbase等数据库新势力首次进入榜单。
  • 某种程度上，这种变化的背后，暗示着全球数据库已经进入发展的黄金时代，也是一众新兴势力的加速崛起之年。其中，最为典型的例子是Snowflake和Databricks经常隔空喊话，前者是云端数仓的代表玩家，去年继续保持了1倍以上的业务增长；后者因推出“湖仓一体”，估值一路飙升至360亿美金，两者之争，其实是数据库新旧架构之争。

  • 随着企业数字化驶入深水区，对于数据使用场景也呈现多元化的趋势，过去容易被企业忽略的数据，开始从幕后走到台前，如何为众多场景选择一款合适的数据库产品，已经成了很多CIO和管理者的一道必答题。但有一点可以确定的是，过去的数据库已难以匹配眼下日益增长的数据复杂度需求，基于扩展性和可用性划分，分布式架构突破单机、共享、集群架构下的数据库局限，近些年发展态势迅猛。为此，这篇文章我们将主要分析：

    • 数据仓、数据湖、湖仓一体究竟是什么？
    • 架构演进，为什么说湖仓一体代表了未来？
    • 现在是布局湖仓一体的好时机吗？

  • 01：数据湖+数据仓≠湖仓一体

  • 在湖仓一体出现之前，数据仓库和数据湖是被人们讨论最多的话题。
  • 正式切入主题前，先跟大家科普一个概念，即大数据的工作流程是怎样的？这里就要涉及到两个相对陌生的名词：数据的结构化程度和数据的信息密度。前者描述的是数据本身的规范性，后者描述的是单位存储体积内、包含信息量的大小。
  • 一般来说，人们获取到的原始数据大多是非结构化的，且信息密度比较低，通过对数据进行清洗、分析、挖掘等操作，可以排除无用数据、找到数据中的关联性，在这个过程中，数据的结构化程度、信息密度也随之提升，最后一步，就是把优化过后的数据加以利用，变成真正的生产资料。
  • 简而言之，大数据处理的过程其实是一个提升数据结构化程度和信息密度的过程。在这个过程中，数据的特征一直在发生变化，不同的数据，适合的存储介质也有所不同，所以才有了一度火热的数据仓库和数据湖之争。
  • 我们先来聊聊数据仓库，它诞生于1990年，是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，主要用于支持管理决策和信息的全局共享。简单点说，数据仓库就像是一个大型图书馆，里面的数据需要按照规范放好，你可以按照类别找到想要的信息。
  • 就目前来说，对数据仓库的主流定义是位于多个数据库上的大容量存储库，它的作用在于存储大量的结构化数据，为管理分析和业务决策提供统一的数据支持，虽然存取过程相对比较繁琐，对于数据类型有一定限制，但在那个年代，数据仓库的功能性已经够用了，所以在2011年前后，市场还是数据仓库的天下。
  • 到了互联网时代，数据量呈现“井喷式”爆发，数据类型也变得异构化。受数据规模和数据类型的限制，传统数据仓库无法支撑起互联网时代的商业智能，随着Hadoop与对象存储的技术成熟，数据湖的概念应用而生，在2011年由James Dixon提出。
  • 相比于数据仓库，数据湖是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施。它就像一个大型仓库，可以存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据，数据湖通常更大，存储成本也更为廉价。但它的问题也很明显，数据湖缺乏结构性，一旦没有被治理好，就会变成数据沼泽。
  • 从产品形态上来说，数据仓库一般是独立标准化产品，数据湖更像是一种架构指导，需要配合着系列周边工具，来实现业务需要。换句话说，数据湖的灵活性，对于前期开发和前期部署是友好的；数据仓库的规范性，对于大数据后期运行和公司长期发展是友好的，那么，有没有那么一种可能，有没有一种新架构，能兼具数据仓库和数据湖的优点呢？
  • 于是，湖仓一体诞生了。依据DataBricks公司对Lakehouse 的定义，湖仓一体是一种结合了数据湖和数据仓库优势的新范式，在用于数据湖的低成本存储上，实现与数据仓库中类似的数据结构和数据管理功能。湖仓一体是一种更开放的新型架构，有人把它做了一个比喻，就类似于在湖边搭建了很多小房子，有的负责数据分析，有的运转机器学习，有的来检索音视频等，至于那些数据源流，都可以从数据湖里轻松获取。
  • 就湖仓一体发展轨迹来看，早期的湖仓一体，更多是一种处理思想，处理上将数据湖和数据仓库互相打通，现在的湖仓一体，虽然仍处于发展的初期阶段，但它已经不只是一个纯粹的技术概念，而是被赋予了更多与厂商产品层面相关的含义和价值。
  • 这里需要注意的是，“湖仓一体”并不等同于“数据湖”+“数据仓”，这是一个极大的误区，现在很多公司经常会同时搭建数仓、数据湖两种存储架构，一个大的数仓拖着多个小的数据湖，这并不意味着这家公司拥有了湖仓一体的能力，湖仓一体绝不等同于数据湖和数据仓简单打通，反而数据在这两种存储中会有极大冗余度。
  • 02：为什么说湖仓一体是未来？
  • 回归开篇的核心问题：湖仓一体凭什么能代表未来？
  • 关于这个问题，我们其实可以换一个问法，即在数据智能时代，湖仓一体会不会成为企业构建大数据栈的必选项？就技术维度和应用趋势来看，这个问题的答案几乎是肯定的，对于高速增长的企业来说，选择湖仓一体架构来替代传统的独立仓和独立湖，已经成为不可逆转的趋势。
  • 一个具有说服力的例证是，现阶段，国内外各大云厂商均陆续推出了自己的“湖仓一体”技术方案，比如亚马逊云科技的Redshift Spectrum、微软的Azure Databricks、华为云的Fusion Insight、滴普科技的FastData等，这些玩家有云计算的老牌龙头，也有数据智能领域的新势力。
  • 事实上，架构的演进是由业务直接驱动的，如果业务侧提出了更高的性能要求，那么在大数据架构建设的过程中，就需要数据库架构建设上进行技术升级。以国内数字化企业服务领域成长最快的独角兽滴普科技为例，依托新一代湖仓一体、流批一体的数据分析基础平台FastData，基于对先进制造、生物医药、消费流通等行业的深度洞察，滴普科技从实际场景切入，为客户提供了一站式的数字化解决方案。
  • 滴普方面认为，“在数据分析领域，湖仓一体是未来。它可以更好地应对AI时代数据分析的需求，在存储形态、计算引擎、数据处理和分析、开放性以及面向AI的演进等方面，要领先于过去的分析型数据库。”以AI应用层面为例，湖仓一体架构天然适合AI类的分析（包括音视频非结构化数据存储，兼容AI计算框架，具有模型开发和机器学习全生命周期的平台化能力），也更适合大规模机器学习时代。

  • 这一点，和趋势不谋而合。就在前不久，Gartner发布了湖仓一体的未来应用场景预测：湖仓一体架构需要支持三类实时场景，第一类是实时持续智能；第二类是实时按需智能；第三类是离线按需智能，这三类场景将可以通过快照视图、实时视图以及实时批视图提供给数据消费者，这同样是未来湖仓一体架构需要持续演进的方向。
  • 03：现在是布局湖仓一体的好时机吗？
  • 从市场发展走向来看，“湖仓一体”架构是基于技术发展进程的必经之路。
  • 但由于这个新型开放架构仍处于发展早期，国内外企业数字化水平和市场认知的不同，造成了解决方案也存在着较大的差异。在业内投资人看来，“虽然美国的企业服务市场比我们成熟的多，也有很多路径可以参考，但中国市场却有着很多中国特色。以对标Databricks的滴普科技为例，美国企业服务市场往往卖产品就可以了，但中国大客户群体需要更与客户资深场景深度融合的解决方案，解决方案需要兼顾通用性和定制化。”
  • 在此前与滴普科技的合作中，百丽国际就已经完成了统一数仓的搭建，实现了多个业务线的数据采集和各个业务域的数据建设。在保证前端数据正常运行、“热切换”底层应用的前提下，滴普科技和百丽国际紧密协作，在短短几个月时间里将多个数仓整合为统一数仓，有效统一了业务口径，大幅缩减了开发运维工作量，整个业务价值链也形成了闭环。

  • 这也是“湖仓一体”的能力价值所在：随着数据结构的逐渐多样性，3D图纸、直播视频、会议视频、音频等数据资料越来越多，为深度挖掘数据价值，依托于领先的湖仓一体技术架构，百丽国际可先将海量的多模数据存储入湖，在未来算力允许时，及挖掘深度的业务分析场景后，从数据湖中抓取数据分析。
  • 举个简单的例子，某个设计师想要设计一款鞋子，一般会从历史数据中找有效信息参考，设计师也许只需要一张货品照片，就能像浏览电影般，了解到该商品多年来全生命周期的销售业绩、品牌故事、竞品分析等数据，赋能生产及业务决策，实现数据价值的最大化。
  • 一般来说，大体量的企业想要保持持续增长，往往需要依靠大量、有效的数据输出，进而实现智慧决策。很多企业出于 IT 建设能力的限制，导致很多事情没法做，但通过湖仓一体架构，让之前被限制的数据价值得以充分发挥，如果企业能够在注重数据价值的同时，并有意识地把它保存下来，企业就完成了数字化转型的重要命题之一。
  • 我们也有理由相信，随着企业数字化转型加速，湖仓一体架构也会有更为广阔的发展空间。

习题

  1. 阅读Delta Lake开源代码github.com/delta-io/de…

    1. Delta对于底层存储系统有什么要求
    2. Delta的Transaction是乐观锁还是悲观锁
    3. 如下代码实现了什么功能，如何做到的
    4. import org.apache.spark.sql.Column;
import org.apache.spark.sql.functions;

deltaTable.update(
    new HashMap<String, Column>() {{
        put("data", functions.col("data").plus(1));
    }}
);
复制代码

  1. 阅读Delta Lake论文，简述一下其几个use cases

    论文链接：bytedance.feishu.cn/file/boxcnr…

二、发展历史

数据湖三阶段:Hadoop、Hive、湖仓─体

2.1 数据湖发展阶段1-Hadoop

image.png

坏处:

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

2.2 数据湖发展阶段2- Hive

image.png

image.png

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

image.png

image.png

image.png

2.4 业界三大数据湖

image.png

image.png

image.png

2.5 关于“数据湖”

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

三、核心技术

湖仓—体项目解决的关键问题: Transaction/事务 、 Schema变更/模式变更 、冲突解决

3.1 文件结构

设计一个简单的数据湖 image.png 简单

image.png

3.2 Time travel/时间旅行

设计一个简单的数据湖 image.png 可以

要点：

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

image.png

3.3 Transaction/事务

设计一个简单的数据湖 image.png 不会

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

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

数据湖中的ACID:

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

3.3.1 Atomicity/原子性

image.png

3.3.2 lsolation/事务隔离

image.png

3.4 Schema Evolution/图式演化

设计一个简单的数据湖 image.png 支持

Add/Drop/Rename（添加/删除/重命名）
重要：

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

ID将data 和metadata的列名做一一对应!
  1. 唯一确定的ID。新增列赋予新ID。删列ID不复用
  2. 写入数据时，ID也写入数据文件
  3. 读取数据时，用ID做映射，如果
    1. Data中没有，metadata中有:ADD（nan空）
    2. Data中有，metadata中没有:DROP
    3. Data和metadata中都有同一ID，但是name不同: RENAME
    4. 如果都有同一列名，而ID不同?：先DROP后ADD
    5. ID面向数据，列名面向用户

四、各有所长

不同湖仓─体项目的独到之处

4.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/ACID(缩写)交易

完全开源，由Apache孵化开发

4.1.1 Well-designed Metadata Layer/设计良好的元数据层

  • matadata layer:对应json文件，读入最新版本，版本递增，写满改名转可视/递增版本

  • data layer:对应parquet文件，新写入不可读文件，写满转json

image.png

4.1.2 Data File Filter/数据文件过滤器

  • 分区范围：时间 image.png

4.1.3 Hidden Partition/隐分区

image.png

4.2. Hudi

Hadoop Upsert Delete and lncremental/向上插入删除和增加
简称Hudi

Hudi工作重点:

  1. Timeline service/时间线服务: Hudi管理 transaction/事务 的方式
  2. Hudi Table Type: Copy on Write /Merge on Read
  3. 高效的Upserts: update or insert
  4. 索引表:快速定位一条数据的位置
  5. Streaming Ingestion Service/流吞食服务
  6. 完全开源，由Apache孵化

4.2.1 Timeline Serivce & Upsert & Incremental/增量

  • Timeline Service:记录写入时间
  • Incremental:增量读取，从某时后时间读入数据，查Timeline image.png

4.2.2 Copy on Write/写入拷贝

  • 对不同分区filed拷贝，问题是读取数据过大 image.png

4.2.3 Merge On Read/读时合并

  • 解决不必要的数据读，以含pk（最新数据），需更新数据为两区，同时读出（选列），两列写入小文件，与大文件用pk作jion，选小文件数据胜出
  • base filed与update filed
  • 以pk为merge，可合并两分区 image.png

4.3 Delta Lake/三角洲湖 工作重点

  1. ACID Transaction/事务
  2. Schema/模式 校验(不是 evolution/演变)
  3. 流批一体
  4. Time Travel/时间旅行
  5. Upsert/Delete(上插/删除)
  6. Z-Order优化
  7. 只开源了一部分，由 Databricks/数据库 自己主导开发，Z-order等优化的实现未开源

4.3.1流批一体

image.png

五、总结场景

三个湖仓─体项目的对比，数据湖在字节跳动中的应用

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

image.png

5.2 三个数据湖的热度

image (99).png

image (100).png

5.3 技术选型

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

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

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

5.3.1 字节跳动数据湖场景举例- Feature Store/特性存储

image.png

image.png

批流一体:近实时的数据写入与数据就绪(Readiness/准备状态)

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

更强的算力:要求更快的读数据

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

5.4课程总结

  1. 数据湖的最新发展状态是湖仓─体
  2. 数据湖以低存储成本提供了ACID Transaction/事务 、Schema evolution/模式演化 、Time travel/时程 等高级功能

晚安玛卡巴卡

快乐暑假

avatar
文章
阅读
粉丝