只管>
过去两年，咱们团队在新型数据湖技术的钻研、探求和通常上投入了少量精神，只管咱们关键投入的方向是 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 的服务和控制性能，将为用户和下层平台理清这一层三角相关：