最新大厂数据湖面试题，知识点总结

本文是一篇数据湖的面试题，同时也是数据湖知识点的讲解

目录：
一、什么是数据湖
二、数据湖的发展
三、数据湖有哪些优势
四、数据湖应该具备哪些能力
五、数据湖的实现遇到了哪些问题
六、数据湖与数据仓库的区别
七、为什么要做数据湖？区别在于？
八、数据湖挑战
九、湖仓一体
十、目前有哪些开源数据湖组件
十一、三大数据湖组件对比

数据湖是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施；以数据为导向，实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理；并通过与各类外部异构数据源的交互集成，支持各类企业级应用。

用架构图能很快说明白，用阿里的数据架构图来说:

• ODS（operational data store, staging area）存储来自各业务系统（生产系统）的原始数据，即为数据湖。

• CDM为经过整合、清洗的数据。其中的DWS汇总层，为面向主题的数据仓库（狭义），用于BI报表出数。

简单来说，数据湖的定义就是原始数据保存区. 虽然这个概念国内谈的少，但绝大部分互联网公司都已经有了。国内一般把整个HDFS叫做数仓（广义），即存放所有数据的地方。

数据湖最早是2011年由Pentaho的首席技术官James Dixon提出的一个概念，他认为诸如数据集市，数据仓库由于其有序性的特点，势必会带来数据孤岛效应，而数据湖可以由于其开放性的特点可以解决数据孤岛问题。

为什么不是数据河？

因为，数据要能存，而不是一江春水向东流。

为什么不是数据池？

因为，要足够大，大数据太大，一池存不下。

为什么不是数据海？

因为，企业的数据要有边界，可以流通和交换，但更注重隐私和安全，“海到无边天作岸”，那可不行。

所以数据要能“存”，数据要够“存”，数据要有边界地“存”。企业级的数据是需要长期积淀的，因此是“数据湖”。

同时湖水天然会进行分层，满足不同的生态系统要求，这与企业建设统一数据中心，存放管理数据的需求是一致的。热数据在上层方便流通应用，温数据、冷数据位于数据中心的不同存储介质之中，达到数据存储容量与成本的平衡。

但随着数据湖在各类企业的应用，大家都觉得：嗯，这个数据有用，我要放进去；那个数据也有用，我也要放进去；于是把所有的数据不假思索地扔进基于数据湖的相关技术或工具中，没有规则不成方圆，当我们认为所有数据都有用时，那么所有的数据都是垃圾，数据湖也变成了造成企业成本高企的数据沼泽。

• 轻松地收集数据：数据湖与数据仓库的一大区别就是，Schema On Read，即在使用数据时才需要Schema信息；而数据仓库是Schema On Write，即在存储数据时就需要设计好Schema。这样，由于对数据写入没有限制，数据湖可以更容易的收集数据。

• 从数据中发掘更多价值：数据仓库和数据市场由于只使用数据中的部分属性，所以只能回答一些事先定义好的问题；而数据湖存储所有最原始、最细节的数据，所以可以回答更多的问题。并且数据湖允许组织中的各种角色通过自助分析工具，对数据进行分析，以及利用AI、机器学习的技术，从数据中发掘更多的价值。

• 消除数据孤岛：数据湖中汇集了来自各个系统中的数据，这就消除了数据孤岛问题。

• 具有更好的扩展性和敏捷性：数据湖可以利用分布式文件系统来存储数据，因此具有很高的扩展能力。开源技术的使用还降低了存储成本。数据湖的结构没那么严格，因此天生具有更高的灵活性，从而提高了敏捷性。

1. 数据集成能力：

需要具备把各种数据源接入集成到数据湖中的能力。数据湖的存储也应该是多样的，比如HDFS、HIVE、HBASE等等。

2. 数据治理能力：

治理能力的核心是维护好数据的元数据（metadata）。强制要求所有进入数据湖的数据必须提供相关元数据，应该作为最低限度的治理管控。没有元数据，数据湖就面临成为数据沼泽的风险。更丰富的功能还包括：

• 自动提取元元数据，并根据元数据对数据进行分类，形成数据目录。
• 自动对数据目录进行分析，可以基于AI和机器学习的方法，发现数据之间的关系。
• 自动建立数据之间血缘关系图。
• 跟踪数据的使用情况，以便将数据作为产品，形成数据资产。

3. 数据搜索和发现能力：

如果把整个互联网想象成一个巨大的数据湖。那么，之所以人们可以这么有效的利用这个湖中的数据，就是因为有了Google这样的搜索引擎。人们可以通过搜索，方便地找到他们想要的数据，进而进行分析。搜索能力是数据湖的十分重要的能力。

4. 数据安全管控能力：

对数据的使用权限进行管控，对敏感数据进行脱敏或加密处理，也是数据湖能商用所必须具备的能力。

5. 数据质量检验能力：

数据质量是分析正确的关键。因此必须对进入数据湖中的数据的质量情况进行检验。及时发现数据湖中数据质量的问题。为有效的数据探索提供保障。

6. 自助数据探索能力：

应该具备一系列好用的数据分析工具，以便各类用户可以对数据湖中的数据进行自助探索。包括：

• 支持对流、NoSQL、图等多种存储库的联合分析能力
• 支持交互式的大数据SQL分析
• 支持AI、机器学习分析
• 支持类似OLAP的BI分析
• 支持报表的生成

数据湖刚提出来时，只是一个朴素的理念。而从理念变成一个可以落地的系统，就面临着许多不得不考虑的现实问题：

首先，把所有原始数据都存储下来的想法，要基于一个前提，就是存储成本很低。而今数据产生的速度越来越快、产生的量越来越大的情况下，把所有原始数据，不分价值大小，都存储下来，这个成本在经济上能不能接受，可能需要打一个问号。

其次，数据湖中存放这各类最原始的明细数据，包括交易数据、用户数据等敏感数据，这些数据的安全怎么保证？用户访问的权限如何控制？

再次，湖中的数据怎么治理？谁对数据的质量、数据的定义、数据的变更负责？如何确保数据的定义、业务规则的一致性？

数据湖的理念很好，但是它现在还缺乏像数据仓库那样，有一整套方法论为基础，有一系列具有可操作性的工具和生态为支撑。正因如此，目前把Hadoop用来对特定的、高价值的数据进行处理，构建数据仓库的模式，取得了较多的成功；而用来落实数据湖理念的模式，遭遇了一系列的失败。这里，总结一些典型的数据湖失败的原因：

1. 数据沼泽：当越来越多的数据接入到数据湖中，但是却没有有效的方法跟踪这些数据，数据沼泽就发生了。在这种失败中，人们把所有东西都放在HDFS中，期望以后可以发掘些什么，可没多久他们就忘那里有什么。

2. 数据泥团：各种各样的新数据接入进数据湖中，它们的组织形式、质量都不一样。 由于缺乏用于检查，清理和重组数据的自助服务工具，使得这些数据很难创造价值。

3. 缺乏自助分析工具：由于缺乏好用的自助分析工具，直接对数据湖中的数据分析很困难。一般都是数据工程师或开发人员创建一个整理后的小部分数据集，把这些数据集交付给更广泛的用户，以便他们使用熟悉的工具进行数据分析。这限制了更广泛的人参与到探索大数据中，降低了数据湖的价值。

4. 缺乏建模的方法论和工具：在数据湖中，似乎每一项工作都得从头开始，因为以前的项目产生的数据几乎没有办法重用。 其实，我们骂数据仓库很难变化以适应新需求，这其中有个原因就是它花很多时间来对数据进行建模，而正是有了这些建模，使得数据可以共享和重用。数据湖也需要为数据建模，不然每次分析师都得从头开始。

5. 缺少数据安全管理：通常的想法是每个人都可以访问所有数据，但这是行不通的。企业对自己的数据是有保护本能的，最终一定是需要数据安全管理的。

6. 一个数据湖搞定一切：大家都对能在一个库中存储所有数据的想法很兴奋。然而，数据湖之外总会有新的存储库，很难把他们全都消灭掉。 其实，大多数公司所需的，是可以对多种存储库联合访问功能。是不是在一个地方存储，并不是那么重要。

数据仓库，准确说，是面向历史数据沉淀和分析使用的，有三大特点：

• 其一是集成性，由于数据来源众多，因而需要技术和规范来统一存储方式；
• 其二是非易失和随时间变化，数据仓库存储了过去每一天的快照且通常不更新，使用者可以在任一天向前或者向后对比数据的变化；
• 其三是面向主题，根据业务对数据进行有效的编码，让理论最佳值在应用中落地。

数据湖，准确说，其出发点是补全数据仓库实时处理能力、交互式分析能力等新技术缺失的情况。其最重要的特点，就是丰富的计算引擎：批处理、流式、交互式、机器学习，该有的，应有尽有，企业需要什么，就用什么。数据湖也有三个特征：

• 其一是灵活性，默认业务的不确定性是常态的，在无法预期未来变化时，技术设施基础，就要具备“按需”贴合业务的能力；
• 其二是管理性，数据湖需要保存原始信息和处理后的信息，在数据源、数据格式、数据周期等维度上，能够追溯数据的接入、存储、分析和使用等流动过程；
• 其三是多态性，本身的引擎需要进可能的丰富，因为业务场景不固定，而多态的引擎支持、扩展能力，能够较好的适应业务的快速变化。

数据湖和数仓，就是原始数据和数仓模型的区别。因为数仓（狭义）中的表，主要是事实表-维度表，主要用于BI、出报表，和原始数据是不一样的。

为什么要强调数据湖呢？

真正的原因在于，data science和machine learning进入主流了，需要用原始数据做分析，而数仓的维度模型则通常用于聚合。

另一方面，机器学习用到的数据，也不止于结构化数据。用户的评论、图像这些非结构化数据，也都可以应用到机器学习中。

但数据湖背后其实还有更大的区别：

• 传统数仓的工作方式是集中式的：业务人员给需求到数据团队，数据团队根据要求加工、开发成维度表，供业务团队通过BI报表工具查询。

• 数据湖是开放、自助式的（self-service）：开放数据给所有人使用，数据团队更多是提供工具、环境供各业务团队使用（不过集中式的维度表建设还是需要的），业务团队进行开发、分析。

也就是组织架构和分工的差别 —— 传统企业的数据团队可能被当做IT，整天要求提数，而在新型的互联网/科技团队，数据团队负责提供简单易用的工具，业务部门直接进行数据的使用。

从传统集中式的数仓转为开放式的数据湖，并不简单，会碰到许多问题

• 数据发现：如何帮助用户发现数据、了解有哪些数据？

• 数据安全：如果管理数据的权限和安全？因为一些数据是敏感的、或者不应直接开放给所有人的（比如电话号码、地址等）

• 数据管理：多个团队使用数据，如何共享数据成果（比如画像、特征、指标），避免重复开发

这也是目前各大互联网公司都在改进的方向！

2020年，大数据DataBricks公司首次提出了湖仓一体（Data Lakehouse）概念，希望将数据湖和数据仓库技术合而为一，此概念一出各路云厂商纷纷跟进。

Data Lakehouse（湖仓一体）是新出现的一种数据架构，它同时吸收了数据仓库和数据湖的优势，数据分析师和数据科学家可以在同一个数据存储中对数据进行操作，同时它也能为公司进行数据治理带来更多的便利性。

一直以来，我们都在使用两种数据存储方式来架构数据：

• 数据仓库：主要存储的是以关系型数据库组织起来的结构化数据。数据通过转换、整合以及清理，并导入到目标表中。在数仓中，数据存储的结构与其定义的schema是强匹配的。

• 数据湖：存储任何类型的数据，包括像图片、文档这样的非结构化数据。数据湖通常更大，其存储成本也更为廉价。存储其中的数据不需要满足特定的schema，数据湖也不会尝试去将特定的schema施行其上。相反的是，数据的拥有者通常会在读取数据的时候解析schema（schema-on-read），当处理相应的数据时，将转换施加其上。

现在许多的公司往往同时会搭建数仓、数据湖这两种存储架构，一个大的数仓和多个小的数据湖。这样，数据在这两种存储中就会有一定的冗余。

Data Lakehouse的出现试图去融合数仓和数据湖这两者之间的差异，通过将数仓构建在数据湖上，使得存储变得更为廉价和弹性，同时lakehouse能够有效地提升数据质量，减小数据冗余。在lakehouse的构建中，ETL起了非常重要的作用，它能够将未经规整的数据湖层数据转换成数仓层结构化的数据。

下面详细解释下：

湖仓一体（Data Lakehouse）：

依据DataBricks公司对Lakehouse 的定义：一种结合了数据湖和数据仓库优势的新范式，解决了数据湖的局限性。Lakehouse 使用新的系统设计：直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。

解释拓展：

湖仓一体，简单理解就是把面向企业的数据仓库技术与数据湖存储技术相结合，为企业提供一个统一的、可共享的数据底座。

避免传统的数据湖、数据仓库之间的数据移动，将原始数据、加工清洗数据、模型化数据，共同存储于一体化的“湖仓”中，既能面向业务实现高并发、精准化、高性能的历史数据、实时数据的查询服务，又能承载分析报表、批处理、数据挖掘等分析型业务。

湖仓一体方案的出现，帮助企业构建起全新的、融合的数据平台。通过对机器学习和AI算法的支持，实现数据湖+数据仓库的闭环，提升业务的效率。数据湖和数据仓库的能力充分结合，形成互补，同时对接上层多样化的计算生态。

目前开源的数据湖有江湖人称“数据湖三剑客”的Hudi、Delta Lake和IceBerg。

Apache Hudi是一种数据湖的存储格式，在Hadoop文件系统之上提供了更新数据和删除数据的能力以及消费变化数据的能力。

Hudi支持如下两种表类型：

• Copy On Write

使用Parquet格式存储数据。Copy On Write表的更新操作需要通过重写实现。

• Merge On Read

使用列式文件格式（Parquet）和行式文件格式（Avro）混合的方式来存储数据。Merge On Read使用列式格式存放Base数据，同时使用行式格式存放增量数据。最新写入的增量数据存放至行式文件中，根据可配置的策略执行COMPACTION操作合并增量数据至列式文件中。

应用场景

• 近实时数据摄取

Hudi支持插入、更新和删除数据的能力。可以实时摄取消息队列（Kafka）和日志服务SLS等日志数据至Hudi中，同时也支持实时同步数据库Binlog产生的变更数据。

Hudi优化了数据写入过程中产生的小文件。因此，相比其他传统的文件格式，Hudi对HDFS文件系统更加的友好。

• 近实时数据分析

Hudi支持多种数据分析引擎，包括Hive、Spark、Presto和Impala。Hudi作为一种文件格式，不需要依赖额外的服务进程，在使用上也更加的轻量化。

• 增量数据处理

Hudi支持Incremental Query查询类型，可以通过Spark Streaming查询给定COMMIT后发生变更的数据。Hudi提供了一种消费HDFS变化数据的能力，可以用来优化现有的系统架构。

Delta Lake是Spark计算框架和存储系统之间带有Schema信息数据的存储中间层。它给Spark带来了三个最主要的功能：

第一，Delta Lake使得Spark能支持数据更新和删除功能；

第二，Delta Lake使得Spark能支持事务；

第三，支持数据版本管理，运行用户查询历史数据快照。

核心特性

• ACID事务：为数据湖提供ACID事务，确保在多个数据管道并发读写数据时，数据能保持完整性。

• 数据版本管理和时间旅行：提供了数据快照，使开发人员能够访问和还原早期版本的数据以进行审核、回滚或重现实验

• 可伸缩的元数据管理：存储表或者文件的元数据信息，并且把元数据也作为数据处理，元数据与数据的对应关系存放在事务日志中；

• 流和批统一处理：Delta中的表既有批量的，也有流式和sink的；

• 数据操作审计：事务日志记录对数据所做的每个更改的详细信息，提供对更改的完整审计跟踪；

• Schema管理功能：提供自动验证写入数据的Schema与表的Schema是否兼容的能力，并提供显示增加列和自动更新Schema的能力；

• 数据表操作(类似于传统数据库的SQL)：合并、更新和删除等，提供完全兼容Spark的Java/scala API；

• 统一格式：Delta中所有的数据和元数据都存储为Apache Parquet。

Iceberg官网定义：Iceberg是一个通用的表格式（数据组织格式），它可以适配Presto，Spark等引擎提供高性能的读写和元数据管理功能。

数据湖相比传统数仓而言，最明显的便是优秀的T+0能力，这个解决了Hadoop时代数据分析的顽疾。传统的数据处理流程从数据入库到数据处理通常需要一个较长的环节、涉及许多复杂的逻辑来保证数据的一致性，由于架构的复杂性使得整个流水线具有明显的延迟。

Iceberg 的 ACID 能力可以简化整个流水线的设计，降低整个流水线的延迟。降低数据修正的成本。传统 Hive/Spark 在修正数据时需要将数据读取出来，修改后再写入，有极大的修正成本。Iceberg 所具有的修改、删除能力能够有效地降低开销，提升效率。

1. ACID能力，无缝贴合流批一体数据存储最后一块版图

随着flink等技术的不断发展，流批一体生态不断完善，但在流批一体数据存储方面一直是个空白，直到Iceberg等数据湖技术的出现，这片空白被慢慢填补。

Iceberg 提供 ACID 事务能力，上游数据写入即可见，不影响当前数据处理任务，这大大简化了 ETL；

Iceberg 提供了 upsert、merge into 能力，可以极大地缩小数据入库延迟；

2. 统一数据存储，无缝衔接计算引擎和数据存储

Iceberg提供了基于流式的增量计算模型和基于批处理的全量表计算模型。批处理和流任务可以使用相同的存储模型，数据不再孤立；Iceberg 支持隐藏分区和分区进化，方便业务进行数据分区策略更新。

Iceberg屏蔽了底层数据存储格式的差异，提供对于Parquet，ORC和Avro格式的支持。Iceberg起到了中间桥梁的能力，将上层引擎的能力传导到下层的存储格式。

3. 开放架构设计，开发维护成本相对可控

Iceberg 的架构和实现并未绑定于某一特定引擎，它实现了通用的数据组织格式，利用此格式可以方便地与不同引擎对接，目前 Iceberg 支持的计算引擎有 Spark、Flink、Presto 以及 Hive。

相比于 Hudi、Delta Lake，Iceberg 的架构实现更为优雅，同时对于数据格式、类型系统有完备的定义和可进化的设计；面向对象存储的优化。Iceberg 在数据组织方式上充分考虑了对象存储的特性，避免耗时的 listing 和 rename 操作，使其在基于对象存储的数据湖架构适配上更有优势。

4. 增量数据读取，实时计算的一把利剑

Iceberg 支持通过流式方式读取增量数据，支持 Structed Streaming 以及 Flink table Source。

Delta lake

由于Apache Spark在商业化上取得巨⼤成功，所以由其背后商业公司Databricks推出的Delta lake也显得格外亮眼。在没有delta数据湖之前，Databricks的客户⼀般会采⽤经典的lambda架构来构建他们的流批处理场景。

Hudi

Apache Hudi是由Uber的⼯程师为满⾜其内部数据分析的需求⽽设计的数据湖项⽬，它提供的fast upsert/delete以及compaction等功能可以说是精准命中⼴⼤⼈民群众的痛点，加上项⽬各成员积极地社区建设，包括技术细节分享、国内社区推⼴等等，也在逐步地吸引潜在⽤户的⽬光。

Iceberg

Netflix的数据湖原先是借助Hive来构建，但发现Hive在设计上的诸多缺陷之后，开始转为⾃研Iceberg，并最终演化成Apache下⼀个⾼度抽象通⽤的开源数据湖⽅案。

Apache Iceberg⽬前看则会显得相对平庸⼀些，简单说社区关注度暂时⽐不上delta，功能也不如Hudi丰富，但却是⼀个野⼼勃勃的项⽬，因为它具有⾼度抽象和⾮常优雅的设计，为成为⼀个通⽤的数据湖⽅案奠定了良好基础。

三者均为Data Lake的数据存储中间层，其数据管理的功能均是基于⼀系列的meta⽂件。Meta⽂件的⾓⾊类似于数据库的catalog\wal，起到schema管理、事务管理和数据管理的功能。与数据库不同的是，这些meta⽂件是与数据⽂件⼀起存放在存储引擎中的，⽤户可以直接看到。这个做法直接继承了⼤数据分析中数据对⽤户可见的传统，但是⽆形中也增加了数据被不⼩⼼破坏的风险。⼀旦删了meta⽬录，表就被破坏了，恢复难度很⼤。

Meta包含有表的schema信息。因此系统可以⾃⼰掌握schema的变动，提供schema演化的⽀持。Meta⽂件也有transaction log的功能（需要⽂件系统有原⼦性和⼀致性的⽀持）。所有对表的变更都会⽣成⼀份新的meta⽂件，于是系统就有了ACID和多版本的⽀持，同时可以提供访问历史的功能。在这些⽅⾯，三者是相同的。

Hudi 的设计⽬标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），强调了其主要⽀持Upserts、Deletes 和 Incremental 数据处理，其主要提供的写⼊⼯具是 Spark HudiDataSource API 和⾃⾝提供的 HoodieDeltaStreamer，均⽀持三种数据写⼊⽅式：UPSERT，INSERT 和 BULK_INSERT。其对 Delete 的⽀持也是通过写⼊时指定⼀定的选项⽀持的，并不⽀持纯粹的 delete 接⼝。

在查询⽅⾯，Hudi ⽀持 Hive、Spark、Presto。

在性能⽅⾯，Hudi 设计了 HoodieKey ，⼀个类似于主键的东西。对于查询性能，⼀般需求是根据查询谓词⽣成过滤条件下推⾄datasource。Hudi 这⽅⾯没怎么做⼯作，其性能完全基于引擎⾃带的谓词下推和 partition prune 功能。

Hudi 的另⼀⼤特⾊是⽀持 Copy On Write 和 Merge On Read。前者在写⼊时做数据的 merge，写⼊性能略差，但是读性能更⾼⼀些。后者读的时候做 merge，读性能差，但是写⼊数据会⽐较及时，因⽽后者可以提供近实时的数据分析能⼒。最后，Hudi 提供了⼀个名为run_sync_tool 的脚本同步数据的 schema 到 Hive 表。Hudi 还提供了⼀个命令⾏⼯具⽤于管理 Hudi 表。

Iceberg 没有类似的 HoodieKey 设计，其不强调主键。没有主键，做 update/delete/merge 等操作就要通过 Join 来实现，⽽ Join 需要有⼀个类似 SQL 的执⾏引擎。

Iceberg 在查询性能⽅⾯做了⼤量的⼯作。值得⼀提的是它的 hidden partition 功能。Hidden partition 意思是说，对于⽤户输⼊的数据，⽤户可以选取其中某些列做适当的变换（Transform）形成⼀个新的列作为 partition 列。这个 partition 列仅仅为了将数据进⾏分区，并不直接体现在表的 schema中。

Delta 的定位是流批⼀体的 Data Lake 存储层，⽀持 update/delete/merge。由于出⾃ Databricks，spark 的所有数据写⼊⽅式，包括基于dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是⽀持的（开源的 SQL 写暂不⽀持，EMR 做了⽀持）。不强调主键，因此其 update/delete/merge 的实现均是基于 spark 的 join 功能。在数据写⼊⽅⾯，Delta 与 Spark 是强绑定的，这⼀点 Hudi 是不同的：Hudi 的数据写⼊不绑定 Spark（可以⽤ Spark，也可以使⽤ Hudi ⾃⼰的写⼊⼯具写⼊）。

在查询⽅⾯，开源 Delta ⽬前⽀持 Spark 与 Presto，但是，Spark 是不可或缺的，因为 delta log 的处理需要⽤到 Spark。这意味着如果要⽤ Presto 查询 Delta，查询时还要跑⼀个 Spark 作业。更为难受的是，Presto 查询是基于 SymlinkTextInputFormat 。在查询之前，要运⾏ Spark 作业⽣成这么个 Symlink ⽂件。如果表数据是实时更新的，意味着每次在查询之前先要跑⼀个 SparkSQL，再跑 Presto。为此，EMR 在这⽅⾯做了改进可以不必事先启动⼀个 Spark 任务。

在查询性能⽅⾯，开源的 Delta ⼏乎没有任何优化。

Delta 在数据 merge ⽅⾯性能不如 Hudi，在查询⽅⾯性能不如 Iceberg，是不是意味着 Delta ⼀⽆是处了呢？其实不然。Delta 的⼀⼤优点就是与 Spark 的整合能⼒，尤其是其流批⼀体的设计，配合 multi-hop 的 data pipeline，可以⽀持分析、Machine learning、CDC 等多种场景。使⽤灵活、场景⽀持完善是它相⽐ Hudi 和 Iceberg 的最⼤优点。另外，Delta 号称是 Lambda 架构、Kappa 架构的改进版，⽆需关⼼流批，⽆需关⼼架构。这⼀点上 Hudi 和 Iceberg 是⼒所不及的。

三个引擎的初衷场景并不完全相同，Hudi 为了 incremental 的 upserts，Iceberg 定位于⾼性能的分析与可靠的数据管理，Delta 定位于流批⼀体的数据处理。这种场景的不同也造成了三者在设计上的差别。尤其是 Hudi，其设计与另外两个相⽐差别更为明显。因此后⾯是趋同还筑起各⾃专长优势壁垒未可知。

Delta、Hudi、Iceberg三个开源项⽬中，Delta和Hudi跟Spark的代码深度绑定，尤其是写⼊路径。这两个项⽬设计之初，都基本上把Spark作为他们的默认计算引擎了。⽽Apache Iceberg的⽅向⾮常坚定，宗旨就是要做⼀个通⽤化设计的Table Format。

它完美的解耦了计算引擎和底下的存储系统，便于多样化计算引擎和⽂件格式，很好的完成了数据湖架构中的Table Format这⼀层的实现，因此也更容易成为Table Format层的开源事实标准。

另⼀⽅⾯，Apache Iceberg也在朝着流批⼀体的数据存储层发展，manifest和snapshot的设计，有效地隔离不同transaction的变更，⾮常⽅便批处理和增量计算。并且，Apache Flink已经是⼀个流批⼀体的计算引擎，⼆者都可以完美匹配，合⼒打造流批⼀体的数据湖架构。

Apache Iceberg这个项⽬背后的社区资源⾮常丰富。在国外，Netflix、Apple、Linkedin、Adobe等公司都有PB级别的⽣产数据运⾏在Apache Iceberg上；在国内，腾讯这样的巨头也有⾮常庞⼤的数据跑在Apache Iceberg之上，最⼤的业务每天有⼏⼗T的增量数据写⼊。

1. 数仓建设保姆级教程PDF文档

2. 最强最全面的大数据SQL经典面试题

3. 美团数据平台及数仓建设实践，超十万字总结