盘点行业内近期发生的大事，Delta 2.0 的开源是最让人津津乐道的，尤其在>

虽然>

过去两年，我们团队在新型数据湖技术的研究、探索和实践上投入了大量精力，虽然我们主要投入的方向是 Iceberg，但 delta2.0 的开源，以及> 由于我们的工作更多将 Iceberg 当做一个底层依赖使用，在架构上具备解耦的可能，我们完全可以拥抱 Delta，所以这里我想站在一个第三方立场上讲讲对 Lakehouse 这个方向，以及几个主流开源产品的理解和思考，顺带也会简单讲讲我们的工作，另外希望大家可以和我共同思考和探索下面这个问题：

企业究竟需要怎样的数据湖？

Table format 三强之争

Table format 最早由 Iceberg 提出，目前已经成为行业共识的概念， table format 是什么？简单概括的话：

目前国内外同行将 delta、iceberg 和 hudi 作为数据湖 table format 的对标方案，我们先来聊聊 delta，iceberg，hudi 这三个开源数据湖的背景。

delta 是> delta 的推出是为了解决传统数据湖在事务处理，流计算，BI 分析上的不足，Databricks 用极强的讲故事能力为 delta 打造了一个 lakehouse 的概念，时至今日，lakehouse 和湖仓一体的概念已经深入人心，甚至老对手 snowflake 也采纳了这个概念，并且在官网中给出了更贴合自家产品的定义。在 2021 Gartener 数据库领导力象限中，Databricks 和 snowflake 一起晋升第一象限，lakehouse 也首次进入 hype cycle for>

按照>

但另一方面，我们也绝不能忽略> Delta 是 Lakehouse 的解决方案，Databricks 也被当做 lakehouse 的代表，但是 delta 这个项目自身的定义却经历了一些变化，我关注到去年某个时间点之前， delta 定义为 open format，引擎中可以直接用 delta 替换 parquet。

Format 的定义与 iceberg 的 table format 的定义非常相似，但在目前官网中，以及各种相关的分享和博客中，再也见不到此类描述，目前 delta 被官方定义为 lakehouse storage framework，当然，无论 format 还是 framework，汤还是那个汤，只是菜谱更加丰满了。

1.2 Iceberg

Iceberg 是由 Netflix 团队研发并开源的数据湖 table format，创始人 Ryan Blue 是 spark，parquet，avro 的 PMC，在数据分析领域有非常丰富的经验和人脉，co-fonder 中还有一位来自 Cloudera 的资深工程师，从时间线上看，iceberg 2018年进入 apache 孵化，2020 年毕业，考虑到项目本身的研发周期，很难评判它和 delta 的时间先后，再加上创始人本身是活跃的 spark 贡献者，两个项目从一开始就高度相似。

从功能上看，套用知乎上的一句话：不能说非常相似，只能说一模一样。从发展上看，iceberg 更加符合一个开源项目的气质，早期这个项目更多是为了应对 Netflix 对大体量数据分析的需求，重点强调了以下的特性：

ACID 和 MVCC 的特性，读数据时不会读到写入的不一致状态

创始人非常强调 iceberg 之于 hive 的优势，并且切实戳中了开发者，尤其有上云需求的用户痛点，很多圈内人提出 iceberg 会成为下一代的 hive，iceberg 引擎平权的特性，进一步促进了外围厂商的认同，目前公开信息可以了解到 Cloudera 主推 iceberg；snowflake 上支持 iceberg 外表；starrocks 支持 iceberg 外表；Amazon Athena 可以使用 iceberg 表，与 delta 相比，iceberg 的出身更加纯粹，被各家追捧也不奇怪，虽然 delta 2.0 也开始吸引 spark 之外的引擎开发者参与，但追赶目前 iceberg 的外围生态还需要一定的时间。

我本人是在 2020 年接触 iceberg，当时在为 flink 寻找比 hive 更好的数据湖方案，以解决 upsert, 以及批流场景开发和运维割裂的问题，当时 iceberg 和 hudi 都在孵化，delta 依然是 spark 的 delta，而 hudi 当时也是一个 spark lib，只有 iceberg 让人眼前一亮，iceberg 也是最早支持 flink connector。

Iceberg 社区对 roadmap 一直很克制，任何对底层表格式的修改都慎之又慎，保障了对任何引擎都足够友好，操作的可扩展性和 row-level api 则给开发者留足了想象空间，在引擎平权方面，iceberg 是独树一帜的，未来怎么样值得我们持续观察。

Hudi 开源和孵化的时间线与 iceberg 比较相近，回溯开源之初，hudi 的全称是 hadoop upsert and incremental，核心功能是在 hadoop 上支持 upsert 和 incremental process，发展至今，hudi 已经不再局限于 hadoop 以及名字上的两个功能，hudi 不强调自己的数据 format，经过几次大的迭代，对自己的定义变地有些复杂，打开官网我们会看到这样的描述：

可以看出 hudi 想干很多事，并且给自己建立了像数据库一样的目标，这个目标的达成有很长的路要走。Hudi 在三个项目中最早提供 stream upsert 能力 ，如果不做二次开发，hudi 是开箱即用的数据湖 upsert 方案，并且 hudi 社区对开发者非常开放，和 iceberg 专注又谨慎的调性可谓两个极端，但 hudi 大版本之间的变化很大，这个方面先压下不表，有机会专门开个文章聊聊。

最早的时候 hudi 只有 spark 下的实现，为了支持 flink 在重构方面社区下了很大的功夫（delta类似），这也是 2020 年没有选择 hudi 的最重要原因，在 hudi 的核心团队创业成立 Onehouse 之后，hudi 的定位明显和其他两家产生了较大的分化，databricks 作为一家商业公司，delta 是他吸引流量的重要手段，商业化上再通过上层的数据开发，治理和 AI platform 变现，同理从公开信息看， Ryan Blue 成立的 Tabular 也是在 iceberg 之上构建 platform，和 table format 泾渭分明。而 hudi 自身已经将自己拔到 platform 的高度，虽然功能上还距离很远，但可以预见长期的 roadmap 会产生较大不同。

出于竞争的考虑，delta 和 iceberg 有的，hudi 可能都会跟进，所以 hudi 也可以作为 table format 来使用。当我们为企业做技术选型时，需要考虑是选择一个纯净的 table format 整合到自己的 platform 中，还是选择一个新的 platform 或者将 platform 融合。

Iceberg 背刺与 delta2.0 的反击

如果一定要对比，我更加喜欢对比 delta 和 iceberg，因为 hudi 的愿景和前两个有较大的不同，换句话说，就 table format 而言，delta 和 iceberg 可能更懂要做什么，就懂的层面两讲，iceberg 我认为更胜一筹。拿最近 delta 2.0 发布的内容来看，有兴趣的同学可以去看下> 发布会重点提及的功能总结如下：

对 Iceberg 不太了解的同学，可以去看下 iceberg 官网，引用上文中的一句话，不能说非常相似，只能说一模一样，而且大部分功能在 2 年前的 iceberg 中已经相当成熟了。

在发布会后段，Databricks 工程师重点介绍了：

我们团队也用 benchmark 工具对 delta2.0 和 iceberg 进行了对比，测试方案是在 trino 下测试 100 个 warehouse 的 tpch（测试工具实际是为测 stream lakehouse 量身定制的 chbenchmark，下文也有提及），当我们采用 delta 和 iceberg 开源版本默认的参数，对比下来 delta 确实惊艳，平均响应时间 delta 比 iceberg 快 1.4 倍左右，但我们注意到默认参数中有两个重要的区别：

将 delta 和 iceberg 的压缩算法设置相同，read-target-size 设置为 32m，实测下来 tpch 平均响应时间不再有差别，从原理上看，排除占比极低的元数据读取和 plan 时间，在相同的配置下，benchmark 测试的主要是 parquet 这类文件格式的 IO 性能，没有差异是比较合理的。后续 Onehouse 在性能测试上给出的 回击 也佐证这一点：

作为一名相关从业者，Delta2.0 的完全开源是一件振奋人心的事，几乎可以下结论，delta2.0 和 iceberg 重叠的功能，会成为数据湖 table format 的事实标准，在这个方向上提前投资的产品和开发者有可能更快地收获果实。

至于谁更优秀？iceberg 的开放，专注和执行力让人叹服，delta 的影响力，商业资源和成熟度不可忽略。从功能和外围生态看，iceberg 依然有至少 1-2 年的先发优势，但是生长在 iceberg 上原汁原味的 Tablur 还没影，delta 的平台背书本就超强，再向其他引擎开放了 connector 和 API 之后，相信开源的贡献者和影响力也会同步跟进，期待 delta 社区在活跃度上可以迎头赶上。

新技术推广的困局

作为一名基础软件工程师，自底向上倒逼需求是非常艰难的，想要业务团队切换基础软件可能同时需要天时地利人和，而研究数据湖的同学相信在过去两年推动业务时多少会遇到力不从心的局面，这里我来分享一些我的理解。

我们将目前数据湖 Format 已经形成的标准能力做一个小结：

现在用户使用数据湖，基本是在一个成熟的数据生产力平台中使用，代表有阿里>

在市面上除了阿里，数据生产力平台基本还是围绕 Hadoop，Hive 的数据湖体系，或者云端的对象存储来构建，相比于 Delta，Iceberg 这类数据湖 Format，Hive 和对象存储的结构不自由，读写不自由的问题基本已通过流程规范和上层规避克服掉了。在新数据湖技术兴起阶段，大家津津乐道的模式演进， ACID，对一个成熟的数据生产力平台以及它所面向的平台运维，数据消费者，分析师基本无感，而引擎平权的特性，hive 自己已经做到了最佳。

至于流批同源，在实践中归纳起来有以下两点：

总体来说，以上两点是行业内讨论最多的数据湖实践，但这套技术在实践上客观说还不够成熟，比如说用数据湖 CDC 替代 kafka，延迟降低到分钟级别，先不说产品的适配成本，业务接受这种能力降级往往需要比成本优化更充分的理由，而且数据湖 CDC 还会引入小文件问题。对读时合并这点，我们测试下来，用流式摄取方式往 iceberg 表写入两个小时，AP 的性能下降至少一半。当然 delta/iceberg 带来的新功能不止于此，比如模式演进对特征的场景非常有用，MERGE INTO 的语法对补数的场景非常有用，UPDETE/DELETE SQL 对国外 GDPR/CPAA 的执行是强需求，但这些特性比较细，往往只是对特定场景有吸引。

两年来我们跟不少同行做实践上的交流，大家大体上遇到的都是这样的问题：业务吸引不够，相比替代方案好像没有带来质的提升；产品适配意愿不强，三个项目都很牛，但似乎看不到能给产品带来什么实质的好处，又怕站错边选错路；叠加经济形势下行，业务风险偏好降低，对新技术也没那么上心了。

所以当我们真正把新的数据湖技术应用到产品和实践中，不妨先自顶向下地思考这个问题： 企业究竟需要怎样的数据湖？ ​

企业需要怎样的数据湖？

这个问题其实>

那么这套方法论适用于其他企业吗？我认为答案是肯定的，但是要稍作修改，首先> 另一方面，国内基本上实时计算用 Flink，这里不评价 Flink 和 Spark 哪个更好，现实是绝大多数企业不会绑定一个计算引擎，这也是为什么引擎平权对数据湖极为重要，重要到 Delta 也不得不妥协，不同引擎的应用可以吸收各家优势，但会带来产品割裂的问题，主流大数据平台的供应商大多把实时计算作为一个单独的产品入口，当然这背后的原因不光是引擎的问题 ，最重要的依然是存储方案的不统一。产品割裂在大数据方法论的迭代中被更加放大，比如在数据中台中，指标系统，数据模型，数据质量，数据资产这一套中台模块基本是围绕离线场景打造，而在强调 CICD 的> 这个状况的直接结果是实时数仓，流计算对应的场景和需求在大数据平台的方法论迭代中被边缘化，用户无法在实时场景下体验到数据安全，数据质量，数据治理带来的收益，变本加厉的是，很多既需要实时也需要离线的场景下，用户需要维护流表和批表两套模型，两套代码，并且时刻警惕语义和模型的二义性。

了解了 Lakehouse 意义，立足于现实，以网易数帆为例，新的数据湖技术应当帮助> 聊到这里，可能会觉得越来越抽象，我们来举一个数据分析的 lambda 架构：

场景中用 Hive 做批表，kafka 做流表，整个离线遵循数据中台和> 企业需要的数据湖，应当能够帮助业务解决割裂的问题，用数据湖实现 ETL 、data pipeline 以及 olap 全流程，实现下面的效果：

因为实时和离线使用了一套模型，在理论上已经可以将中台和> 我们的工作

在这样的目标驱动下，过去两年我们团队开发了 Arctic 这个项目，并且在 7 月底默默开源了。

首先，我们的工作不是另起炉灶，做一个跟 delta/iceberg 竞争的产品，这不符合企业的需求，Arctic 是立足于开源数据湖 Format 之上的服务，如前文所说，目前我们基于 iceberg。

其次，我们的目标要将>

通过 Arctic 的几个核心特性可以看出我们是怎么聚焦于拓展大数据平台的边界。

Arctic 作为服务可以去适配不同的数据湖 Format，这样产品无需担心数据湖技术的选型问题，持续自优化的能力让数据分析即插即用，平替实时数仓，兼容模式则可以让产品在选型上更加没有后顾之忧，实践中可以针对性的设计升级和灰度方案，并发冲突解决和一致性让数据流管理变的简单。

性能也是 Arctic 非常关注的点，尤其在读时合并方面，我们做了大量工作，面向流式湖仓性能测试工具我们做出了针对性的方案，这块的工作今年晚些时候我们也会向大家开放，简单来说，我们使用 HTAP 的 chbenchmark 思路，tpcc 持续写入的数据通过 FlinkCDC 流式写入 arctic 和 hudi，benchmark 的测试结果用 tpch 来衡量，测试的对象是 olap 场景下的读时合并性能，arctic 和 hudi 的数据新鲜度都设置为 1 分钟，目前 arctic 开源版本测试结果如下（数值越小性能越好）：

测试方案、环境和配置会在 Arctic 的官网中公开，同时我们将在8月11号的分享中公布更多benchmark 的细节，感兴趣的同学，或者对测试结果有疑问，欢迎参加我们的发布会了解更多信息。

虽然我们在 table format 之上，引擎之下做了很多优化工作，但 Arctic 不会魔改 format 的内部实现， Arctic 依赖的都是社区发布的 release 包，未来 Arctic 也将坚持这一点，并通过 format 兼容的特性为用户带来最佳的方案。

我们即将在 2022 年 8 月 11 日在线上举办一个简单的发布会，我会花 30 分钟左右的时间来讲讲 Arctic 的目标、特性、规划，以及可以给开源用户带来的价值。从调性上看，Arctic 作为基础软件会是一个完全开源的项目，相关商业化（如果有）会由另外的团队推进，未来条件允许的情况下我们也会积极推动项目向基金会的孵化，从这篇文章中可以看到 ​ ​ 网易数帆领导层对开源的态度 ​ ​

如果你对 Arctic 的定位、功能，或者任何与他相关的部分感兴趣，欢迎观看我们的直播或录播，或者通过下面的链接了解 arctic：

总结

Delta2.0 的发布，标志着数据湖 table format 标准开始走向明确，delta、iceberg 和 hudi 的竞争变得白热化的同时，企业以及相关的供应商应当开始认真考虑怎样引入数据湖 table format 技术，给平台用户带来 Lakehouse 的最佳实践。

Lakehouse 给企业带来的价值，应当是用一套数据湖底座，拓展数据平台的边界，改善产品、数据孤岛和流程规范割裂带来的低效和成本浪费，首先要做的，是将围绕传统离线数仓打造的数据中台，或者衍生的> 但是企业和开发者需要理解，开源的数据湖 Format 不等价于 Lakehouse，包括创造出 Lakehouse 这个概念的>

Arctic 为管理员和开发者提供了持续优化的度量和管理工具，以帮助用户实现时效性，存储和计算成本的测量，标定和规划。进一步说，在以数据湖构建的离线场景中，成本和性能呈非常线性的关系，当性能或容量不足时，SRE 只需要考虑加多少机器。而当我们将数据湖的能力拓展到实时场景，成本，性能和数据新鲜度的关系将呈现更为复杂和微妙的状态，Arcitic 的服务和管理功能，将为用户和上层平台理清这一层三角关系：