Apache Iceberg：湖屋和数据流的开源表格格式

教程
Apache Kafka

每个数据驱动型组织都有运营和分析工作负载。各种数据平台（包括数据流、数据湖、数据仓库和湖仓解决方案以及云服务）中，最佳品种方法脱颖而出。在企业架构中，像Apache Iceberg这样的开放表格式框架对于确保可靠的数据管理和共享、无缝模式演进、高效处理大规模数据集以及提供成本效益的存储至关重要，同时为ACID事务和时间旅行查询提供强大支持。

本文探讨了市场趋势；Iceberg、Hudi、Paimon、Delta Lake和XTable等表格式框架的采用情况；以及Snowflake、Databricks（Apache Spark）、Confluent（Apache Kafka/Flink）、Amazon Athena和Google BigQuery等数据平台领先供应商的产品策略。

数据平台的开表格式是什么？

一个开放表格式有助于保持数据完整性，优化查询性能，并确保对平台内存储数据的清晰理解。

数据平台的开表格式通常包括一个明确定义的结构，具有确保数据组织有序、可访问和易于查询的特定组件。一个典型的表格式包含表名、列名、数据类型、主键和外键、索引以及约束。

这不是一个新概念。你最喜欢的几十年前的数据库——比如Oracle、IBM DB2（甚至是在主机上）或PostgreSQL——使用的都是同样的原理。然而，对于云数据仓库、数据湖和数据湖屋来说，关于可扩展性、性能和查询能力方面的需求和挑战有所改变。

“湖屋表格式”的好处，如Apache Iceberg

组织的每个部分都变得以数据为驱动。结果是广泛的数据集，跨业务单元与数据产品共享数据，以及对近乎实时处理数据的新要求。

Apache Iceberg为企业架构提供了许多好处：

  • 单一存储：数据只存储一次（来自各种数据源），这降低了成本和复杂性
  • 互操作性：无需整合努力即可从任何分析引擎访问
  • 所有数据：统一运营和分析工作负载（事务系统、大数据日志/IoT/点击流、移动API、第三方B2B接口等）
  • 供应商独立：与任何喜欢的分析引擎一起工作（无论它是近实时、批量还是基于API的）

Apache Hudi和Delta Lake提供了相同的特性。尽管如此，Delta Lake主要是由Databricks作为单一供应商推动的。

表格式和目录接口

了解关于Apache Iceberg或类似表格式框架的讨论包括两个概念：表格式和目录接口！ 作为该技术的终端用户，你需要这两者！

Apache Iceberg项目实现了该格式，但仅提供了目录的规范（而非实现）：

  • 表格式定义了数据在表内的组织、存储和管理方式。
  • 目录接口管理表的元数据，并为在数据湖中访问表提供了一个抽象层。

Apache Iceberg文档根据以下图表详细探讨了这些概念：

Source: Apache Iceberg documentation

组织使用各种实现来处理Iceberg的目录接口。每一种都与不同的元数据存储和服务集成。关键的实现包括：

  • Hadopp目录：使用Hadoop分布式文件系统（HDFS）或其他兼容的文件系统存储元数据。适用于已经使用Hadoop的环境。
  • Hive目录：与Apache Hive Metastore集成来管理表元数据。非常适合使用Hive进行元数据管理的用户。
  • AWS Glue目录：使用AWS Glue Data Catalog存储元数据。为在AWS生态系统中操作的用户设计。
  • REST目录：通过HTTP提供目录操作的RESTful接口。支持与自定义或第三方元数据服务的集成。
  • Nessie目录：使用Project Nessie，为数据管理提供类似Git的体验。

Apache Iceberg的势头和日益增长的采用率激励了许多数据平台供应商实现他们自己的Iceberg目录。我在下面的部分讨论了一些关于数据平台和云供应商策略的策略，包括Snowflake的Polaris、Databricks的Unity和Confluent的Tableflow。

一级Iceberg支持与Iceberg连接器

请注意，支持Apache Iceberg（或Hudi/Delta Lake）远不止提供连接器和通过API与表格式集成。供应商和云服务通过高级功能如数据格式之间的自动映射、关键的SLA、时间回溯、直观的用户界面等进行区分。

让我们来看一个例子：Apache Kafka与Iceberg的集成。已经实现了各种Kafka Connect连接器。然而，以下使用一级Iceberg集成（例如Confluent的Tableflow）与仅使用Kafka Connect连接器相比的好处：

  • 无需连接器配置
  • 无需通过连接器进行消费
  • 内置维护（压缩、垃圾收集、快照管理）
  • 自动模式演进
  • 外部目录服务同步
  • 更简单的操作（在完全托管的SaaS解决方案中，它是无服务器的，用户无需进行任何扩展或操作）

类似的好处也适用于其他数据平台，以及与提供简单连接器相比的潜在一等集成。

使用Apache Iceberg、Apache Hudi和Delta Lake的开放表格式数据湖/湖仓

Apache Iceberg、Apache Hudi和Delta Lake等表格式框架的通用目标是提高数据湖的功能性和可靠性，解决管理大规模数据时面临的常见挑战。这些框架有助于：

  1. 改进数据管理
    • 简化数据湖中的数据摄取、存储和检索处理。
    • 支持高效的数据组织和存储，以实现更好的性能和可扩展性。
  2. 确保数据一致性
    • 提供ACID事务机制，确保即使在并发读写操作期间，数据也能保持一致性和可靠性。
    • 支持快照隔离，使用户在任何时间点都能查看数据的一致性状态。
  3. 支持模式演进
    • 允许在不中断现有数据或需要复杂迁移的情况下更改数据模式（例如添加、重命名或删除列）。
  4. 优化查询性能
    • 实施高级索引和分区策略，以提高数据查询的速度和效率。
    • 启用高效元数据管理，以有效处理大量数据集和复杂查询。
  5. 增强数据治理
    • 提供更好的跟踪和管理数据血缘、版本控制和审计的工具，这对于保持数据质量和合规性至关重要。

通过解决这些目标，像Apache Iceberg、Apache Hudi和Delta Lake这样的表格式框架帮助组织构建更健壮、可扩展、可靠的数据湖和数据湖屋。数据工程师、数据科学家和业务分析师利用表格式之上的分析、AI/ML或报告/可视化工具来管理和分析大量数据。

Apache Iceberg、Hudi、Paimon和Delta Lake的比较

在这里我不会对Apache Iceberg、Apache Hudi、Apache Paimon和Delta Lake这些表格式框架进行比较。已经有很多专家撰写了相关内容。每个表格式框架都有其独特的优势和好处。但由于快速的发展和创新，每月都需要更新，在这些框架中添加新的改进和能力。

以下是我从关于这四个选项的各种博客文章中看到的内容总结：

  • Apache Iceberg：在模式和时间演化、高效元数据管理和与各种数据处理引擎的广泛兼容性方面表现出色。
  • Apache Hudi：非常适合实时数据摄入和更新操作，具有强大的变更数据捕获能力和数据版本控制。
  • Apache Paimon：一种湖格式，支持使用Flink和Spark构建实时湖屋架构，适用于流处理和批处理操作。
  • Delta Lake：提供健壮的ACID事务、模式强制和时间旅行功能，非常适合维护数据质量和完整性。

一个关键的决策点可能是Delta Lake并非像Iceberg和Hudi那样由一个广泛的社区驱动，而是主要由Databricks作为背后的单一供应商推动。

Apache XTable作为支持Iceberg、Hudi和Delta Lake的可互操作跨表框架

用户有很多选择。 XTable，曾称为OneTable，是Apache开源许可下孵化的另一个表框架，旨在实现Apache Hudi、Delta Lake和Apache Iceberg之间的无缝跨表互操作。

Apache XTable：

  • 提供跨表全方位互操作性，适用于数据湖仓表格式。
  • 是不是一个新的或独立的格式。Apache XTable为转换数据湖仓表格式元数据提供了抽象和工具。

也许Apache XTable就是提供特定数据平台和云供应商选项的同时，仍然提供简单集成和互操作性的答案。

但是要小心：不同技术之上的封装并不是万能的解决方案。几年前当Apache Beam出现时我们就看到了这一点。Apache Beam是一个开源的统一模型和一组特定语言的SDK，用于定义和执行数据摄取和数据处理工作流。它支持多种流处理引擎，如Flink、Spark和Samza。Apache Beam背后的主要推动力是谷歌，它允许在Google Cloud Dataflow中迁移工作流。然而，这种封装的局限性很大，因为它需要找到支持的特性的最小公倍数。而且大多数框架的主要优势是那20%不符合这种封装的部分。因此，例如，Kafka Streams故意不支持Apache Beam，因为它会带来太多的设计限制。

表格格式框架的市场采用

首先，我们仍然处于早期阶段。从Gartner炒作周期来看，我们仍然处于创新触发的阶段，正朝着预期顶峰迈进。大多数组织仍在评估这些表格格式，但还没有在整个组织中投入生产。

回顾：Kubernetes与Mesosphere和Cloud Foundry的容器之战

Apache Iceberg的争论让我想起了几年前容器之战。术语“容器之战”指的是软件开发和IT基础设施领域中不同容器化技术和平台之间的竞争和对抗。

竞争的三种技术是Kubernetes、Mesosphere和Cloud Foundry。以下是其发展过程：

Cloud Foundry 和 Mesosphere 较早出现，但 Kubernetes 还是赢得了这场战斗。为什么？我从未完全理解所有的技术细节和差异。最终，如果这三个框架非常相似，那就都是关于：

  • 社区采纳
  • 特性发布的时间点恰到好处
  • 良好的市场营销
  • 运气
  • 以及一些其他因素

但对软件行业来说，有一个领先的开源框架来构建解决方案和商业模式，而不是三个相互竞争的框架，这是好事。

现状：Apache Iceberg 与 Hudi 和 Delta Lake 的表格式战争

显然，Google Trends 并非统计证据或高级研究。但我在过去经常使用它作为一个直观、简单、免费的工具来分析市场趋势。因此，我还用这个工具来看看 Google 搜索是否与我个人对 Apache Iceberg、Hudi 和 Delta Lake（Apache XTable 目前还太小，尚未加入）的市场采纳经验重叠：

我们显然看到了与几年前容器战争相似的模式。我不知道这将走向何方。如果某项技术获胜，或者这些框架有足够的差异化来证明没有万能钥匙，未来将会告诉我们。

我的个人观点？我认为Apache Iceberg将会赢得这场比赛。为什么？我无法用任何技术理由来争辩。我只是看到各行各业越来越多的客户越来越多地谈论它。而且越来越多的供应商开始支持它。但我们将看到。实际上我不关心谁会赢。然而，类似于容器之战，我认为有一个统一的标准，供应商围绕其功能进行区分是件好事，就像Kubernetes一样。

但考虑到这一点，让我们探讨一下当前领先的数据平台和云服务提供商在他们的平台和云服务中对表格式支持的战略。

Apache Iceberg的数据平台和云供应商战略

在本节中，我不会进行任何推测。表格式框架的演变迅速，供应商的战略也变化迅速。请参考供应商的网站以获取最新信息。但以下是对数据平台和云供应商关于支持与集成Apache Iceberg的战略的现状。

  • Snoflake：
    • 已经支持Apache Iceberg一段时间
    • 定期添加更好的集成和新功能
    • 内部和外部存储选项（有取舍），如Snowflake的存储或亚马逊S3
    • 宣布了Polaris，一个为Iceberg的开源目录实现，承诺支持社区驱动的、供应商无关的双向集成
  • databricks ：
    • 专注于Delta Lake作为表格式和（现已开源的）Unity作为目录
    • 收购了Tabular，Apache Iceberg背后的领先公司
    • 支持开源Iceberg接口（双向）的未来策略尚不明确，或者仅限于将数据喂入其lakehouse平台和技术，如Delta Lake和Unity Catalog
  • Confluent：
    • 将Apache Iceberg作为一流公民嵌入其数据流平台（该产品称为Tableflow）
    • 将Kafka主题及相关模式元数据（即数据合同）转换为Iceberg表
    • 操作和分析工作负载之间的双向集成
    • 使用嵌入的无服务器Flink及其统一的批处理和流API进行分析，或与第三方分析引擎如Snowflake、Databricks或Amazon Athena共享数据
  • 更多数据平台和开源分析引擎：
    • 支持Iceberg的技术和云服务列表每月都在增长
    • 一些例子：Apache Spark、Apache Flink、ClickHouse、Dremio、使用Trino（以前称为PrestoSQL）的Starburst、使用Impala的Cloudera、使用Apache Druid的Imply、Fivetran
  • 云服务提供商（AWS、Azure、Google Cloud、Alibaba）：
    • 不同的策略和集成方式，但所有云服务提供商现在都在增加其服务对Iceberg的支持，例如：
      • 对象存储：Amazon S3、Azure Data Lake Storage (ALDS)、Google Cloud Storage 
      • 目录：特定于云的如AWS Glue Catalog或供应商无关的如Project Nessie或Hive Catalog
      • 分析：Amazon Athena、Azure Synapse Analytics、Microsoft Fabric、Google BigQuery

利用Kafka、Flink和Iceberg统一操作和分析工作负载的左移架构

左移架构将数据处理更靠近数据源，利用实时数据流技术如Apache Kafka和Flink，在数据被摄取后直接处理数据流。这种方法减少了延迟，提高了数据一致性和数据质量。

与ETL和ELT不同，它们涉及对静止存储的数据进行批处理，左移架构使得能够实时捕获和转换数据。它与零ETL概念保持一致，使数据立即可用。但与零ETL相比，将数据处理向企业架构的左侧移动避免了一个复杂、难以维护的意大利面条式架构，这种架构有很多点对点的连接。

Shift left架构还通过确保数据在实时中对操作和分析系统都具有可操作性 ，减少了反向ETL的需求。总体而言，这种架构增强了数据的实时性，降低了成本，并加快了数据驱动应用上市的时间。在我的博客文章”Shift Left架构“中了解更多关于这个概念。

Apache Iceberg作为开放的表格式和目录，实现了跨分析引擎的无缝数据共享

开放的表格式和目录为企业架构带来了巨大的好处：

  • 互操作性
  • 分析引擎选择的自由
  • 更快的上市时间
  • 降低成本

Apache Iceberg似乎已成为跨供应商和云服务提供商的事实标准。然而，它仍处于早期阶段，与Apache Hudi、Apache Paimon、Delta Lake和Apache XTable等竞争和包装技术也在试图获得发展势头。

冰山和其他开放表格式不仅对于单一存储以及与Snowflake、Databricks、Google BigQuery等众多分析/数据/AI/ML平台的集成有着巨大的优势，而且还能通过使用Apache Kafka和Flink等数据流技术实现统一 操作和分析工作负载。左移架构可以显著减少工作努力，提高数据质量和一致性，并实现实时而非批量应用和洞察。

最后，如果你仍然好奇数据流和湖仓差异 （以及它们如何相互补充），请观看这个十分钟的视频：

 

你的表格式策略是什么？你连接了哪些技术和云服务？让我们在LinkedIn上连接并讨论这个问题！

Source:
https://dzone.com/articles/apache-iceberg-open-table-format-lakehouses-data-streaming