Apache Iceberg：现代数据栈中的“新一代Hadoop”？

在2010年代初，Apache Hadoop 在大数据领域中占据主导地位。各组织纷纷采用它，视其为可扩展、分布式存储和处理的基石。如今，Apache Iceberg 正成为现代数据栈中数据湖和湖仓的基石。

对于经历过“大数据时代”的人来说，然而，仔细一看，会发现冰山的发展历程与Hadoop的发展历程之间有着惊人的相似之处。

让我们探索这些平行之处及其对未来数据工程意味着什么。

嘿，看！那不是冰山吗？

Hadoop的崛起是由分布式文件存储和处理的迫切需求推动的，解决了“大数据的洪流”这一问题。同样地，Iceberg解决了数据湖中的一个核心问题：管理大规模的、不断演变的数据集，确保ACID（原子性、一致性、隔离性、持久性）一致性以及模式演变。

然而，技术采用往往像是一个钟摆——解决重大痛点的承诺推动了快速采用，即使运营准备不足。Hadoop 的迅猛崛起导致许多组织在不了解其复杂性的情况下就实施了它，结果常常是集群利用率低下或架构设计过于复杂。Iceberg 正在沿着类似的路径前进。统一批处理和实时处理工作负载的能力，加上模式演变等特性，使其成为一个极具吸引力的选择。然而，Iceberg 的采用速度往往超过了组织有效运营它的水平。

这里的经验教训是永恒的：采用应与组织成熟度相匹配。没有明确的数据策略就盲目跟风“冰山项目”可能会导致技术债务并使预期落空。例如，一家金融科技公司可能会为了在欺诈检测流程中实现ACID特性而采用冰山平台，但因为流处理产生太多小文件，他们难以处理文件合并策略。

成功的冰山（Iceberg）技术采用需要像对待Hadoop一样，注重技能培养、工作负载的合理匹配和逐步整合的过程。

Hadoop 最为人所诟病的问题之一是“小文件问题”。HDFS 并未被设计成能高效处理大量小文件，导致出现性能瓶颈和下降。组织常常不得不依靠夜间数据合并任务或复杂的 ETL 流程来整合数据。

冰山也无法避免这个问题。虽然它已经抽象了存储层的很多方面，但小文件仍然是一个持久存在的问题。例如，流数据管道和频繁的增量写入会导致性能下降，因为元数据开销过大。常用的与冰山配合使用的工具，如 Apache Spark 和 Flink，如果不仔细调整，这些问题可能会被进一步放大。

然而，问题不仅如此；小文件问题显著增加了对象存储的成本（比如对S3的请求次数），压缩计算需求呈指数增长，等等类似的问题。

比如，一家零售公司可能会捕获点击流数据。如果 Flink 作业配置不当的话，将数据写入 Iceberg 表，默认的文件大小是 10 MB。长时间下来，这些小文件会越积越多，这会使元数据目录变得臃肿并减慢查询速度。定期进行文件合并作业并同时调整 Flink 的文件大小阈值，可以缓解这个问题。

举个例子来说，Estuary Flow 使用了一些技巧来高效地将流数据写入底层的 Parquet 文件中。它还允许用户在流环境中分阶段物化数据，与压缩时间表保持一致。

调整文件大小和写入策略至关重要。可以使用如 Apache Spark 的自适应查询执行功能等工具来优化分区，或者利用 Iceberg 自带的合并功能定期合并小文件。忽视这些操作会使有前景的 Iceberg 部署变成性能上的瓶颈。

出处：https://mad.firstmark.com/——

Hadoop从来就不是一个独立的产品。它需要一系列的工具——HBase用于实时读操作，Hive用于SQL查询，Spark用于高级数据分析。管理这种复杂性需要专门的技能和复杂的编排，来协调这一切的复杂性。

尽管冰山经过简化，它与其他系统没有太大的不同。它的力量在于其生态系统：查询处理器（Trino、Spark、Flink）、存储层（S3、GCS、HDFS）以及元数据存储（Hive、Glue、Nessie、Polaris、Unity、REST目录，可能还有更多）。配置选项可能会让人觉得眼花缭乱。例如，分区策略可能显著影响查询性能，而错误的选择可能会影响系统的扩展能力。

这种复杂性凸显了一个更广泛的真理：没有工具是独立存在的。Iceberg的成功不仅仅依赖于其功能，还依赖于其周围的生态系统。那些在使用Iceberg方面表现出色的公司通常采用“平台化的思维方式”，构建内部工具和自动化系统来管理和优化元数据、监控性能以及编排工作负载。

Hadoop的NameNode瓶颈说明了元数据管理可能会影响性能。Iceberg通过其基于分布式快照的元数据模型解决了这个问题，但同时也引入了自己的挑战。随着表的规模增大，快照和清单文件也随之增加，使得元数据存储变得臃肿。

一家媒体公司使用Iceberg管理海量的视频分析数据。随着时间的推移，他们的快照历史不断增长，导致查询计划时间增加。通过实施定期快照过期和清单压缩，他们保持了查询性能的稳定，同时控制了元数据的膨胀。

我的小建议是：给予元数据同等重视。自动化快照的修剪和压缩，并投资于能在早期发现元数据瓶颈的监控工具。

Hadoop早期的日子需要组织一切从零开始构建。像Cloudera和AWS EMR这样的托管服务最终简化了使用流程，但也带来了成本和灵活性之间的权衡。

冰山用户也面临着类似的决策。自行托管提供了最大的控制权，但这需要具备扩展和调优的专业知识。像 Snowflake 的 Iceberg 表或 Starburst Galaxy 这样的托管解决方案可以减少运营负担，虽然可以减少运营负担，但可能会限制灵活性并导致供应商锁定。

最终决定取决于你组织的核心竞争力。如果你的团队在 DevOps 方面很擅长，那么自托管可能提供最佳的 ROI（即投资回报率）。相比之下，较小的团队或刚开始使用 Iceberg 项目的团队可能从托管服务中受益，快速上手。

来源: 在过去两年里，我大部分的Apache Iceberg活动都在这里分享。https://www.linkedin.com/posts/ydolan_in-the-last-2-years-most-of-my-apache-iceberg-activity-7256666018935173121-ofqB/

Hadoop 在开源协作中得到了蓬勃发展，但它的碎片化——比如 Spark 和 MapReduce 以及 Hive 和 Impala 之间的竞争——常常造成困惑。Iceberg 得益于一个充满活力的开源社区。然而，类似 Delta Lake 和 Hudi 这样的竞争性表格式同样反映了这种碎片化。

竞争虽然能推动创新，但也可能阻碍采纳。标准化的努力——例如更深入地将Iceberg与查询引擎集成在一起——对其长期成功至关重要。类似于“Hive Metastore”时代的互操作性层的出现，可能定义Iceberg的下一个阶段。

尽管与 Hadoop 有相似之处，Iceberg 却受益于后见之明。数据社区已经学会重视简单性、可扩展性以及云原生设计。以下是一些值得关注的趋势：

就像Spark在Hadoop生态系统中成为主要引擎一样，在Iceberg时代也可能出现一个主导的表格格式和目录。这种整合会推动标准化，无论是Iceberg本身，还是未来可能出现的新事物。

例如，类似于Apache XTable这样的项目正致力于让不同表格格式之间的互操作变得超级简单。

下一个冰山工具的下一波浪潮将专注于简化运营流程。管理服务和编排框架已经开始崭露头角，紧随着 Databricks 和 Snowflake 的步伐。

亚马逊最近宣布的S3 Tables这一点是一个很好的例子。它简化了维护Iceberg表的复杂过程，并提供了一个内置目录功能，但这也带来了一个副作用，即与其他生态系统组件的兼容性有所降低。

冰山对流式处理和事务处理的支持使其不仅仅是一个分析工具。想象用冰山来驱动事件驱动系统或实时机器学习流水线——这些场景超越了传统批处理的限制。

Estuary Flow的Iceberg连接器 是一个很好的例子，展示了这种表格格式可以集成在实时流处理项目中。

冰山来了，并且会一直在这里

Apache Iceberg无疑像十年前的Hadoop一样具有变革性。但就像任何工具一样，强大的力量伴随着复杂的使用。就像现代数据栈中的任何工具一样，成功在于将技术与组织的准备情况、技能和战略目标相匹配。

虽然与 Hadoop 的相似之处非常显著，我们也有了避免其陷阱的机会。通过学习过去，我们可以确保 Iceberg 不再是现代数据堆栈中的 Hadoop，而是我们期待已久的进步。