关于数据湖:最新大厂数据湖面试题知识点总结

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

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

本文首发于公众号【五分钟学大数据】，点击获取：数仓建设保姆级教程

数据湖是一种一直演进中、可扩大的大数据存储、解决、剖析的基础设施；以数据为导向，实现任意起源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式解决与全生命周期治理；并通过与各类内部异构数据源的交互集成，反对各类企业级利用。

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

ODS（operational data store, staging area）存储来自各业务零碎（生产零碎）的原始数据，即为数据湖。
CDM 为通过整合、荡涤的数据。其中的 DWS 汇总层，为面向主题的数据仓库（广义），用于 BI 报表出数。

简略来说，数据湖的定义就是原始数据保留区. 尽管这个概念国内谈的少，但绝大部分互联网公司都曾经有了。国内个别把整个 HDFS 叫做数仓（狭义），即寄存所有数据的中央。

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

为什么不是数据河？

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

为什么不是数据池？

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

为什么不是数据海？

因为，企业的数据要有边界，能够流通和替换，但更重视隐衷和平安，“海到无际天作岸”，那可不行。

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

同时湖水人造会进行分层，满足不同的生态系统要求，这与企业建设对立数据中心，寄存治理数据的需要是统一的。热数据在下层不便流通利用，温数据、冷数据位于数据中心的不同存储介质之中，达到数据存储容量与老本的均衡。

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

轻松地收集数据：数据湖与数据仓库的一大区别就是，Schema On Read，即在应用数据时才须要 Schema 信息；而数据仓库是 Schema On Write，即在存储数据时就须要设计好 Schema。这样，因为对数据写入没有限度，数据湖能够更容易的收集数据。
从数据中挖掘更多价值：数据仓库和数据市场因为只应用数据中的局部属性，所以只能答复一些当时定义好的问题；而数据湖存储所有最原始、最细节的数据，所以能够答复更多的问题。并且数据湖容许组织中的各种角色通过自助剖析工具，对数据进行剖析，以及利用 AI、机器学习的技术，从数据中挖掘更多的价值。
打消数据孤岛：数据湖中会集了来自各个系统中的数据，这就打消了数据孤岛问题。
具备更好的扩展性和敏捷性：数据湖能够利用分布式文件系统来存储数据，因而具备很高的扩大能力。开源技术的应用还升高了存储老本。数据湖的构造没那么严格，因而天生具备更高的灵活性，从而进步了敏捷性。

数据集成能力：

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

数据治理能力：

治理能力的外围是保护好数据的元数据（metadata）。强制要求所有进入数据湖的数据必须提供相干元数据，应该作为最低限度的治理管控。没有元数据，数据湖就面临成为数据沼泽的危险。更丰盛的性能还包含：

主动提取元元数据，并依据元数据对数据进行分类，造成数据目录。
主动对数据目录进行剖析，能够基于 AI 和机器学习的办法，发现数据之间的关系。
主动建设数据之间血缘关系图。
跟踪数据的应用状况，以便将数据作为产品，造成数据资产。

数据搜寻和发现能力：

如果把整个互联网设想成一个微小的数据湖。那么，之所以人们能够这么无效的利用这个湖中的数据，就是因为有了 Google 这样的搜索引擎。人们能够通过搜寻，不便地找到他们想要的数据，进而进行剖析。搜寻能力是数据湖的非常重要的能力。

数据安全管控能力：

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

数据质量检验能力：

数据品质是剖析正确的要害。因而必须对进入数据湖中的数据的品质状况进行测验。及时发现数据湖中数据品质的问题。为无效的数据摸索提供保障。

自助数据摸索能力：

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

反对对流、NoSQL、图等多种存储库的联结剖析能力
反对交互式的大数据 SQL 剖析
反对 AI、机器学习剖析
反对相似 OLAP 的 BI 剖析
反对报表的生成

数据湖刚提出来时，只是一个奢侈的理念。而从理念变成一个能够落地的零碎，就面临着许多不得不思考的事实问题：

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

其次，数据湖中寄存这各类最原始的明细数据，包含交易数据、用户数据等敏感数据，这些数据的平安怎么保障？用户拜访的权限如何管制？

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

数据湖的理念很好，然而它当初还不足像数据仓库那样，有一整套方法论为根底，有一系列具备可操作性的工具和生态为撑持。正因如此，目前把 Hadoop 用来对特定的、高价值的数据进行解决，构建数据仓库的模式，获得了较多的胜利；而用来落实数据湖理念的模式，遭逢了一系列的失败。这里，总结一些典型的数据湖失败的起因：

数据沼泽：当越来越多的数据接入到数据湖中，然而却没有无效的办法跟踪这些数据，数据沼泽就产生了。在这种失败中，人们把所有货色都放在 HDFS 中，冀望当前能够挖掘些什么，可没多久他们就忘那里有什么。
数据泥团：各种各样的新数据接入进数据湖中，它们的组织模式、品质都不一样。因为不足用于查看，清理和重组数据的自助服务工具，使得这些数据很难发明价值。
不足自助剖析工具：因为不足好用的自助剖析工具，间接对数据湖中的数据分析很艰难。个别都是数据工程师或开发人员创立一个整顿后的小局部数据集，把这些数据集交付给更宽泛的用户，以便他们应用相熟的工具进行数据分析。这限度了更宽泛的人参加到摸索大数据中，升高了数据湖的价值。
不足建模的方法论和工具：在数据湖中，仿佛每一项工作都得从头开始，因为以前的我的项目产生的数据简直没有方法重用。其实，咱们骂数据仓库很难变动以适应新需要，这其中有个起因就是它花很多工夫来对数据进行建模，而正是有了这些建模，使得数据能够共享和重用。数据湖也须要为数据建模，不然每次分析师都得从头开始。
短少数据安全治理：通常的想法是每个人都能够拜访所有数据，但这是行不通的。企业对本人的数据是有爱护本能的，最终肯定是须要数据安全治理的。
一个数据湖搞定所有：大家都对能在一个库中存储所有数据的想法很兴奋。然而，数据湖之外总会有新的存储库，很难把他们全都毁灭掉。其实，大多数公司所需的，是能够对多种存储库联结拜访性能。是不是在一个中央存储，并不是那么重要。

数据仓库 ，精确说，是面向 历史数据积淀和剖析应用的，有三大特点：

其一是 集成性，因为数据起源泛滥，因此须要技术和标准来对立存储形式；
其二是 非易失和随工夫变动，数据仓库存储了过来每一天的快照且通常不更新，使用者能够在任一天向前或者向后比照数据的变动；
其三是 面向主题，依据业务对数据进行无效的编码，让实践最佳值在利用中落地。

数据湖 ，精确说，其出发点是 补全数据仓库实时处理能力、交互式剖析能力 等新技术缺失的状况。其最重要的特点，就是丰盛的计算引擎：批处理、流式、交互式、机器学习，该有的，包罗万象，企业须要什么，就用什么。数据湖也有三个特色：

其一是 灵活性，默认业务的不确定性是常态的，在无奈预期将来变动时，技术设施根底，就要具备“按需”贴合业务的能力；
其二是 管理性，数据湖须要保留原始信息和解决后的信息，在数据源、数据格式、数据周期等维度上，可能追溯数据的接入、存储、剖析和应用等流动过程；
其三是 多态性，自身的引擎须要进可能的丰盛，因为业务场景不固定，而多态的引擎反对、扩大能力，可能较好的适应业务的疾速变动。

数据湖和数仓，就是原始数据和数仓模型的区别。因为数仓（广义）中的表，次要是事实表 - 维度表，次要用于 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 所具备的批改、删除能力可能无效地升高开销，晋升效率。

ACID 能力，无缝贴合流批一体数据存储最初一块幅员

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

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

Iceberg 提供了 upsert、merge into 能力，能够极大地放大数据入库提早；

对立数据存储，无缝连接计算引擎和数据存储

Iceberg 提供了基于流式的增量计算模型和基于批处理的全量表计算模型。批处理和流工作能够应用雷同的存储模型，数据不再孤立；Iceberg 反对暗藏分区和分区进化，不便业务进行数据分区策略更新。

Iceberg 屏蔽了底层数据存储格局的差别，提供对于 Parquet，ORC 和 Avro 格局的反对。Iceberg 起到了两头桥梁的能力，将下层引擎的能力传导到上层的存储格局。

凋谢架构设计，开发保护老本绝对可控

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

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

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

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 的增量数据写⼊。

数仓建设保姆级教程
最强最全面的数仓建设标准指南
最强最全面的大数据 SQL 经典面试题
美团数据平台及数仓建设实际，超十万字总结

关于数据湖:最新大厂数据湖面试题知识点总结

一、什么是数据湖

二、数据湖的倒退

三、数据湖有哪些劣势

四、数据湖应该具备哪些能力

五、数据湖的实现遇到了哪些问题

六、数据湖与数据仓库的区别

七、为什么要做数据湖？区别在于？

八、数据湖挑战

九、湖仓一体

1) 目前数据存储的计划

2) Data Lakehouse（湖仓一体）

十、目前有哪些开源数据湖组件

1) Hudi

2) Delta Lake

3) IceBerg

十一、三大数据湖组件比照

1) 概览

2) 共同点

3) 对于 Hudi

4) 对于 Iceberg

5) 对于 Delta

6) 总结

参考链接