盘点行业内近期产生的小事，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 当做一个底层依赖应用，在架构上具备解耦的可能，咱们齐全能够拥抱 Delta，所以这里我想站在一个第三方立场上讲讲对 Lakehouse 这个方向，以及几个支流开源产品的了解和思考，顺带也会简略讲讲咱们的工作，另外心愿大家能够和我独特思考和摸索上面这个问题：企业到底须要怎么的数据湖？
1 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 交融。
2 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 社区在活跃度上能够迎头赶上。
3 新技术推广的困局
作为一名根底软件工程师，自底向上倒逼需要是十分艰巨的，想要业务团队切换根底软件可能同时须要天时地利人和，而钻研数据湖的同学置信在过来两年推动业务时多少会遇到力不从心的场面，这里我来分享一些我的了解。
咱们将目前数据湖 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 的执行是强需要，但这些个性比拟细，往往只是对特定场景有吸引。
两年来咱们跟不少同行做实际上的交换，大家大体上遇到的都是这样的问题：业务吸引不够，相比代替计划如同没有带来质的晋升；产品适配志愿不强，三个我的项目都很牛，但仿佛看不到能给产品带来什么本质的益处，又怕站错边选错路；叠加经济局势上行，业务危险偏好升高，对新技术也没那么上心了。
所以当咱们真正把新的数据湖技术利用到产品和实际中，无妨先自顶向下地思考这个问题：企业到底须要怎么的数据湖？
4 企业须要怎么的数据湖？
这个问题其实 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、流计算各个场景各个环节都能从中受害。
5 咱们的工作
在这样的指标驱动下，过来两年咱们团队开发了 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 日在线上举办一个简略的发布会（点击即可观看 Arctic 开源发布会），我花 30 分钟左右的工夫来讲讲 Arctic 的指标、个性、布局，以及能够给开源用户带来的价值。从调性上看，Arctic 作为根底软件会是一个齐全开源的我的项目，相干商业化（如果有）会由另外的团队推动，将来条件容许的状况下咱们也会踊跃推动我的项目向基金会的孵化。
如果你对 Arctic 的定位、性能，或者任何与他相干的局部感兴趣，欢送观看咱们的直播或录播。6 总结
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 的服务和治理性能，将为用户和下层平台理清这一层三角关系：
作者简介
马进，网易数帆大数据实时计算技术专家、湖仓一体我的项目负责人，负责网易团体分布式数据库，数据传输平台，实时计算平台，实时数据湖等我的项目，长期从事中间件、大数据基础设施方面的钻研和实际，目前率领团队聚焦于流批一体、湖仓一体的平台计划和技术演进，及流式湖仓服务 Arctic 我的项目开源。
【关注我，理解更少数帆常识】