从Delta 2.0开始聊聊我们需要怎样的数据湖

盘点行业内近期发生的大事，Delta 2.0 的开源是最让人津津乐道的，尤其在 Databricks 官宣 delta2.0 时抛出了下面这张性能对比，颇有些引战的味道。

虽然 Databricks 的工程师反复强调性能测试来自第三方 Databeans，并且他们没有主动要求 Databeans做这项测试，但如果全程看完 delta2.0 发布会，会发现在 delta2.0 即将开放的 key feature 中，特别列出了 Iceberg 到 Delta 的转换功能，并且官方着重讲到了 Adobe 从 Iceberg 迁移到 Delta2.0 的实践，这就难免让人浮想联翩了。

过去两年，我们团队在新型数据湖技术的研究、探索和实践上投入了大量精力，虽然我们主要投入的方向是 Iceberg，但 delta2.0 的开源，以及 Databricks 自身对 Iceberg 的重视，更加坚定了我们对数据湖，湖仓一体这个方向的信心，开源之争，本质上是标准之争，竞争会加速标准的确认和落地，而所有大数据的从业者都将从中获益。

由于我们的工作更多将 Iceberg 当做一个底层依赖使用，在架构上具备解耦的可能，我们完全可以拥抱 detalake，所以这里我想站在一个第三方立场上讲讲对 Lakehouse 这个方向，以及几个主流开源产品的理解和思考，顺带也会简单讲讲我们的工作，另外希望大家可以和我共同思考和探索下面这个问题：

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

Table format 三强之争

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

Table format 定义了哪些文件构成一张表，这样任何引擎都可以根据 table format 查询和检索数据；
Table format 规范了数据和文件的分布方式，任何引擎写入数据都要遵照这个标准，通过 format 定义的标准支持 ACID，模式演进等高阶功能。

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

1.1 Delta

delta 是 databricks 公司在 2017 年立项、2018 年公布、2019 年开源的数据湖产品，可以看到 delta 立项时 databricks 已成立 4 年，经历过几次融资，并且在有条不紊地布局商业版图，彼时 hadoop 发行版还不是公认难做的生意，delta 的诞生更像是 databricks 根据自身 spark 创始团队的基因打造的核心竞争力，这样也不难理解，为什么 delta 1.0 几乎不向其他引擎开放。

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

按照 Databricks 的构想，delta1.0 作为 lakehouse 解决方案，可以让数据湖更多，更快地作用于实时和 AI 场景，databricks 提出 delta 架构帮助用户从 lambda 架构中解放出来，核心思想是数据湖既可以跑批，也可以跑流，流计算和批计算的流程和代码可以复用，这样用户没有了维护 lambda 架构的负担，当然计算引擎必须是 spark。遗憾的是 spark streaming 和 struct streaming 在国内用户体量很小，绝大部分用户对 delta1.0 是望梅止渴，对 spark 的深度绑定也一定程度上限制了 delta 社区的发展，给 iceberg 的崛起预埋了伏笔，截止 2022 Q1 社区活跃度的一个对比如下：

但另一方面，我们也绝不能忽略 Databricks 作为一家运营多年的商业公司，已有相当体量的付费用户，再加上对 spark 社区的主导权，成熟的营销和渠道能力，也许很容易重新建立开源上的优势。

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 的特性，读数据时不会读到写入的不一致状态。

Data skipping，通过在 table format 这一层 skip 文件，在一些场景下 query 性能有较大提升
Plan 时不像 hive 需要过多地依赖 namenode，对超大集群来说 plan 的性能有巨大提升
设计时更多考虑了 S3 上搭建 table format，让 iceberg 成为数据湖上云的一个很好选型
Schema evolve 和 hidden partition，让表的变更和维护变的更加轻松

创始人非常强调 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 是独树一帜的，未来怎么样值得我们持续观察。

1.3 Hudi

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

Hudi is a rich platform to build streaming data lakes with incremental data pipelines on a self-managing database layer while being optimized for lake engines and regular batch processing.

可以看出 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 发布的内容来看，有兴趣的同学可以去看下 Databricks 官方举办的 Data + AI summit 2022 的相关分享。

发布会重点提及的功能总结如下：

Data skipping via column stats：通过 format 级别的元数据做 data skipping
Optimize ZOrder：这个应该是 delta 一直有的功能，只是在 2.0 中正式开源了
Change data feed：支持 UPDATE/DELETE/MERGE INTO 下的 CDC 功能
Column mapping：delta 也能像 iceberg 一样模式演进了，功能上相差不大
Full ACID guarantees on S3：在提交阶段引入 DynamoDB，在 S3 上也能保障 ACID
Flink、presto、trino connector：重点强调了 flink 和 trino，connector 和 delta 项目分开管理
Delta standalone：我理解是提供了一层 format api，像 iceberg 一样不用通过引擎也可以操作数据

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

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

Adobe 公司从 iceberg 到 delta 的迁移实践，对 iceberg 的重视可谓是写在脸上了
Delta 不只是 databricks 公司贡献，2.0 中也 involve 了来自 flink，trino 社区的开发者，不过引擎开发者贡献的部分单独在一个 connector 项目，与 delta 的主体区分开，未来在引擎平权方面能不能做到或超越 iceberg，还需要观察
引用第三方 Databeans 的测试，delta 2.0 性能比 iceberg 快 1.7 倍，比 hudi 快 4.3 倍

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

Trino 下 delta 和 iceberg 的默认压缩算法不同，trino写入 iceberg 默认的压缩算法是 ZSTD,而写入delta 默认的压缩算法是 SNAPPY，ZSTD 具有比 SNAPPY 更高的压缩比，通过实际观测ZSTD压缩出来的文件大小只有 SNAPPY 大小的 60%，但是在查询时SNAPPY对于CPU更友好，查询效率更高；
Delta 和 iceberg 默认 read-target-size 不同，delta 默认32m，iceberg 默认 128m，plan 阶段组装更小的文件可以在执行计划采用更多并发度，当然这会带来更多资源消耗，从实践上看 32m 的文件大小对响应时间敏感的数据分析而言或许是更好的选择。

将 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 已经形成的标准能力做一个小结：

结构自由，用户可以自由变更表结构，包括加列改列删列，数据无需重写
读写自由，通过 commit 原语保障 ACID，可以并发写入和读取，不会读写到不一致状态
流批同源，除了批读和批写外，通过增量读和流式摄取支持流计算
引擎平权，支持大部分用户会用到的主流计算引擎，包括 flink、spark、trino 等

现在用户使用数据湖，基本是在一个成熟的数据生产力平台中使用，代表有阿里 Dataworks，网易数帆有数平台，借用同事对网易大数据业务过去十年的发展实践，大体分为三个阶段：

大数据平台：能够在 Hadoop 平台上开发工作流，支持基础的数据开发和运维，有一定数据治理能力。
数据中台：将数据业务的更多共性需求抽象到中台层，围绕业务主题域构建指标体系，并打通数据模型、数据开发运维、为业务构建权限和质量评估体系，资产平台为业务提供更高阶的数据治理能力。
3D 平台：我们从数据中台，升级到 Dataops，Datafusion，Dataproduct 的 3D 体系，3D 更加强调体系化和流程标准化，强调 CICD，强调多数据源融合。

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

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

用数据湖 CDC 替代消息队列，理论上能够带来成本收益，但也会引入小文件问题；
数据湖 + 读时合并，在一定程度上对 kudu，clickhouse，doris 等实时数仓方案形成替代方案。

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

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

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

企业需要怎样的数据湖？

这个问题其实 Databricks 已经给了我们答案，Delta 用一套数据湖存储，将批计算和流计算融合，将传统数仓在数据分析上的优势，数据湖在 AI，数据科学上的优势结合起来，基于 Lakehouse 这个存储底座，实现数据业务的全场景覆盖。总结为一点，Delta 给 Databricks 带来的价值是用一套基础数据湖软件，实现全场景覆盖。

那么这套方法论适用于其他企业吗？我认为答案是肯定的，但是要稍作修改，首先 Databricks 公司做这个项目比较早，并且是作为一个战略型项目来做，它的产品，上层建筑一定是同步跟进的，这也让他的整套 platform 受益于 Lakehouse 非常简洁，而大部分企业用户历史负担要重很多，产品适配牵一发动全身。

另一方面，国内基本上实时计算用 Flink，这里不评价 Flink 和 Spark 哪个更好，现实是绝大多数企业不会绑定一个计算引擎，这也是为什么引擎平权对数据湖极为重要，重要到 Delta 也不得不妥协，不同引擎的应用可以吸收各家优势，但会带来产品割裂的问题，主流大数据平台的供应商大多把实时计算作为一个单独的产品入口，当然这背后的原因不光是引擎的问题，最重要的依然是存储方案的不统一。产品割裂在大数据方法论的迭代中被更加放大，比如在数据中台中，指标系统，数据模型，数据质量，数据资产这一套中台模块基本是围绕离线场景打造，而在强调 CICD 的 Dataops 中，流计算的需求和场景因为存储和计算的不统一更加难以被纳入考量。

这个状况的直接结果是实时数仓，流计算对应的场景和需求在大数据平台的方法论迭代中被边缘化，用户无法在实时场景下体验到数据安全，数据质量，数据治理带来的收益，变本加厉的是，很多既需要实时也需要离线的场景下，用户需要维护流表和批表两套模型，两套代码，并且时刻警惕语义和模型的二义性。

了解了 Lakehouse 意义，立足于现实，以网易数帆为例，新的数据湖技术应当帮助 dataops 拓展边界，让数据开发和运维，数据治理的整套体系囊括实时和 AI 的场景，流批一体的数据湖肩负着为业务实现去 lambda 的架构，产品的交互和体验应当更加简洁和高效，让算法分析师，数据科学家，对时效性更加敏感的风控等场景也能按照 Dataops 的标准和规范快速上手，可以用数据治理的方法论优化成本。

聊到这里，可能会觉得越来越抽象，我们来举一个数据分析的 lambda 架构：

场景中用 Hive 做批表，kafka 做流表，整个离线遵循数据中台和 Dataops 的方法论，实时场景下需要用户构建同步到 hbase 的流计算任务，需要用户实现 join hbase 维表的流计算任务，把数据写到支持实时更新的 kudu 中，最后由业务根据实时和离线的需要选择查询 kudu 表还是 hive 表，在此之前，用户需要分别在数据模型中建表，使用 kudu 的工具建表，并且自己处理两个系统的差异。在这个架构中，用户遭受了割裂的体验，并且需要在上层做很多工作。

企业需要的数据湖，应当能够帮助业务解决割裂的问题，用数据湖实现 ETL 、data pipeline 以及 olap 全流程，实现下面的效果：

因为实时和离线使用了一套模型，在理论上已经可以将中台和 dataops 的很多能力应用到实时场景中，比如数据质量，当然这个过程中还需要在细节上做出更多的创新。核心的一点，数据湖技术的应用和推广不应当立足在某个或某些特定功能之上，应当结合数据平台的方法论全局来看，让数据分析、AI、流计算各个场景各个环节都能从中受益。

我们的工作

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

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

其次，我们的目标要将 Dataops 的边界拓展到流计算，所以 Arctic 会为用户提供更加优化的流的能力，包括 stream upsert，CDC，生产可用的读时合并技术，提供分钟级别新鲜度的数据分析能力，用一句话概括，Arctic 是适配多引擎的流式湖仓服务：

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

Arctic 具备持续自优化的能力（self-optimized）
提供 hive 或 iceberg 两种兼容模式，可以把一张 Arctic 表当成开源的 hive 表或 iceberg 表来使用，用户永远不用担心 iceberg 的新功能用不上，也不用担忧老业务的 hive 表不能使用 Arctic 功能
支持多引擎并发写入，并且保障主键场景下的数据一致性，流和批各写各的，arctic 会解决相同主键写入的数据冲突
提供实时数据湖的标准化 metrics 和管理工具，并且向平台提供 thrift API

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：

Arctic 文档地址：https://arctic.netease.com/ch/
Git 地址：https://github.com/NetEase/arctic

总结

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

Lakehouse 给企业带来的价值，应当是用一套数据湖底座，拓展数据平台的边界，改善产品、数据孤岛和流程规范割裂带来的低效和成本浪费，首先要做的，是将围绕传统离线数仓打造的数据中台，或者衍生的 Dataops 方法论，拓展到实时场景，未来的数据产品方法论，在 Lakehouse 以及相关技术的推动下，相信会向流批融合的大方向上大步前进。

但是企业和开发者需要理解，开源的数据湖 Format 不等价于 Lakehouse，包括创造出 Lakehouse 这个概念的 Databricks 自己，也从未将 Delta 与 Lakehouse 划等号，如何帮助企业构建 lakehouse，是我们此次开源 Arctic 项目的意义，Arctic 目前的定位是流式湖仓服务，流式强调向实时能力的拓展，服务则强调管理，标准化度量，以及其他可以抽象到基础软件中的 lakehouse 能力。以 Arctic 持续自优化的功能举例：

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