引言

数据管理向数据湖的转变是不可避免的，也是一次全平台的变革。通过集成 Spark、Trino 或 ClickHouse 等计算引擎，数据湖已演变成数据湖屋，不仅有助于存储海量数据，还可高效处理数据。

Apache Kafka 是一种广泛使用的事件流平台，几乎所有公司都在使用。起初，Kafka 一直被用作数据管道，但随着其持久化能力和可靠性，它也被视为现代数据技术中新兴的数据存储库。许多数据工程师使用 Kafka 保存最近读取的数据（通常持续 7 天到一个月），然后再将这些数据传输到数据湖中。给人的印象是，事件流平台面向实时数据，而数据湖则面向历史数据。随着数据组件的发展，越来越多的迹象表明 Kafka 正在演变成一种新形式的数据湖。

一、为什么说 Kafka 是数据湖？

数据湖是一个集中式存储库，允许您存储任意规模的所有结构化和非结构化数据。与以结构化和有组织的方式存储数据的数据仓库不同，数据湖以原始、本机格式保留数据，通常采用扁平架构。目前流行的数据湖管理框架有三种：Apache Iceberg、Apache Hudi 和 Delta Lake。虽然这些系统都有其独特的功能和优势，但这三个系统都被广泛用于大规模存储和管理历史数据。它们的设计和功能使处理大量数据变得更加容易，并且它们与 Apache Spark、Flink 等流行计算引擎的集成功能使它们适合各种大数据应用程序和分析用例。

Kafka 拥有所有数据湖属性

Kafka 本质上非常适合作为数据湖。在讨论 Kafka 是否是数据湖的新形式之前，我们首先检查一下 Kafka 是否具备成为数据湖所需的所有属性。

ACID 属性

正如 Martin Kleppmann 在 2018 年旧金山 Kafka 峰会主题演讲《Kafka 是数据库吗？》中强调的那样，Kafka 已经发展到包含所有类似数据库的属性，特别是原子性、一致性、隔离性和持久性 (ACID)。虽然许多人使用 Kafka 只存储最近的数据，但 Kafka 实际上具有无限保留性，类似于现代数据湖。这种功能使 Kafka 成为存储海量数据的诱人选择。

分层存储

人们犹豫是否使用 Kafka 存储长期数据的一个关键原因是认为 Kafka 是基于高性能机器的，使用价格昂贵。但这已经是曾经的事实，Kafka 的经典设计需要将数据存储在计算实例中，这可能比对象存储或 HDFS 存储昂贵得多。这种情况已经改变。Confluence 构建的最新版本 Kafka 以及 Redpanda 和 Apache Pulsar 等其他流行的事件流平台都采用了分层存储，将冷数据存储在廉价的对象存储中，从而降低了成本并使得持久数据成为可能。这种新设计使 Kafka 适合以低成本存储大量数据，而无需担心可扩展性。

存储实时数据

虽然许多人使用数据湖来存储历史数据，但现代数据湖正在不断发展并变得越来越实时，例如越来越多的人使用数据湖来支持流批一体的能力。这种演变是自然的，因为现代应用程序和设备可以连续生成大量数据。因此，数据湖正在实施优化以允许实时提取数据。作为一个事件流平台，Kafka 本质上支持实时数据摄取。其架构非常适合存储快速移动的实时数据和缓慢移动的历史数据。

存储不同类型的数据

Kafka 可以处理多种数据类型，从关系数据等结构化数据，到 JSON 和 Avro 等半结构化数据，甚至文本文档、图像和视频等非结构化数据（尽管不常见）。这种多功能性在当今多样化的数据环境中至关重要，它使 Kafka 能够充当组织所有数据的集中存储库，从而降低管理多个存储解决方案的复杂性和开销。

二、Kafka 适合成为新的数据湖吗？

Kafka 拥有数据湖的所有属性，但 Kafka 是否有潜力成为生产中的新数据湖？这里有支持这个观点的理由：

作为数据源

许多业务直接将数据提取到 Kafka 中，然后再将其传输到数据仓库或其他存储系统中。如果 Kafka 可以被视为一个真正的数据湖，那么数据就可以永久存储在 Kafka 中，而无需将其传输到另一个系统。这将简化数据管理流程，并消除在不同系统之间移动数据时可能出现的数据丢失或损坏的风险。

低延迟分析

Kafka 是一种高度可扩展的平台，能够以极低的延迟处理大量数据。这种低延迟的能力使其成为实时分析的理想选择。通过将数据存储在 Kafka 中，组织可以对实时数据进行分析，从而快速响应业务变化并做出明智决策。

流批一体

Kafka 是一个流处理平台，但它还支持批处理。这使组织能够在一个系统中处理流数据和批处理数据，从而简化数据处理流程。组织可以通过减少数据复制并消除在不同系统之间移动数据的需要来节省成本和时间。

结论

Kafka 具有成为新兴数据湖的所有属性和潜力。它可以存储海量数据，支持实时分析，并提供流批一体功能。随着数据管理向数据湖的转变持续进行，Kafka 有望成为企业存储和处理大量数据的主要存储库。

“数据湖三剑客”Hudi、Delta Lake和Iceberg 深度对比

一个热爱生活又放荡不羁的程序猿

本文主要讲解如下内容：

一、数据湖的优点

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

三、三大数据湖组件对比

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

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

Iceberg官网定义：Iceberg是一个通用的表格式（数据组织格式），提供高性能的读写和元数据管理功能。

Iceberg 的 ACID 能力可以简化整个流水线的设计，传统 Hive/Spark 在修正数据时需要将数据读取出来，修改后再写入，有极大的修正成本。

[玫瑰]ACID能力，无缝贴合流批一体数据存储

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

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

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

[玫瑰]统一数据存储，无缝衔接计算引擎和数据存储

Iceberg提供了基于流式的增量计算模型和基于批处理的全量表计算模型。批处理和流任务可以使用相同的存储模型，数据不再孤立；

Iceberg 支持隐藏分区和分区进化，方便业务进行数据分区策略更新。

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

[玫瑰]开放架构设计，开发维护成本相对可控

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

相比于 Hudi、Delta Lake，Iceberg 的架构实现更为优雅，同时对于数据格式、类型系统有完备的定义和可进化的设计；

面向对象存储的优化。Iceberg 在数据组织方式上充分考虑了对象存储的特性，避免耗时的 listing 和 rename 操作，使其在基于对象存储的数据湖架构适配上更有优势。

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

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

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

Hudi支持如下两种表类型：

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

使用列式文件格式（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能支持事务；

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

核心特性

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

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

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

三者均为Data Lake的数据存储中间层，其数据管理的功能均是基于 系列的meta 件。Meta 件的 类似于数据库的catalog，起到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 的定位是流批 体的， 持 update/delete/merge，spark 的所有数据写 式，包括基于dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是 持的。

不强调主键，因此其 update/delete/merge 的实现均是基于 spark 的 join 功能。在数据写 ，Delta 与 Spark 是强绑定的，这 点 Hudi 是不同的：Hudi 的数据写 不绑定 Spark。

在查询 ，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。

Iceberg完美的解耦了计算引擎和底下的存储系统，便于多样化计算引擎和 件格式，很好的完成了数据湖架构中的Table Format这 层的实现，因此也更容易成为Table Format层的开源事实标准。另 ，Apache Iceberg也在朝着流批 体的数据存储层发展，manifest和snapshot的设计，有效地隔离不同transaction的变更， 常 便批处理和增量计算。并且，Apache Flink已经是 个流批 体的计算引擎， 者都可以完美匹配，合 打造流批 体的数据湖架构。

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

AWS正式发布Kafka云服务，不用再为配置复杂操心了

AWS在re:Invent 2018大会上首先发布了托管Apache Kafka消息队列服务（Amazon Managed Streaming for Apache Kafka，MSK）的消息，现在已经从预览成为正式服务。 Apache Kafka是一个分布式的消息队列系统，其使用发布以及订阅的架构，将产生的流数据的应用与利用流数据的角色分离。 Apache Kafka让使用者可以捕捉如消息队列事件、交易、物联网等事件，或是应用与日志等流数据，还能实时进行分析，连续不间断地转换数据，并再将收到的数据经过处理后，分发到其他的数据湖和数据库中。 AWS提到，用户在生产环境中要配置Apache Kafka，需要克服一些障碍，特别是在后续的管理以及规模扩展工作上，而现在AWS正式推出的MSK服务，则由AWS负责管理任务，让用户可以简单地配置使用，而且由于近几个版本的Kafka，都需要与节点协调程序Zookeeper共同使用，因此MSK服务也只要简单地设定，就能让Kafka与ZooKeeper一同运行。 使用MSK服务，用户可以在几分钟内创建集群，并使用AWS身分管理与访问控制IAM管理集群操作，也能通过ACM（AWS Certificate Manager）完全托管的TLS私密凭证颁发机构授权客户端，以TLS加密数据，并使用KMS（AWS Key Management Service）中的密钥加密其他数据。 当服务器发生故障时，MSK还会替换故障机器，自动执行修补，用户可以从Amazon CloudWatch中，监控服务的状态指标。 AWS表示，MSK与Kafka 1.1.1和2.1.0版本完全兼容，因此用户可以在AWS直接执行原本的Kafka应用以及工具，而不需要修改任何的代码，用户能使用开源工具MirrorMaker，将数据从现有的Kafka集群直接迁移到MSK上。 MSK的计价方式是以Kafka Broker以及配置存储每小时计价，MSK的数据传输费用与原本的AWS数据传输相同，而集群所使用的Zookeeper节点，还有区域集群的Broker和Zookeeper节点互传数据是不额外收费的。 现在用户已经可以在大部分的AWS区域使用到MSK服务，包括北美、亚洲与欧洲。