共计 11799 个字符，预计需要花费 30 分钟才能阅读完成。
本文依据作者于 Arctic 开源发布会演讲内容整顿（略有删减），零碎解读 Arctic 我的项目研发初衷、生态定位、外围个性、性能体现及将来布局。首先感激大家参加咱们 Arctic 开源发布会。我是马进，网易数帆实时计算和湖仓一体团队负责人。咱们在 2020 年开始关注数据湖新的技术，并用它来构建流批一体、湖仓一体的架构。最早咱们应用 Flink+Iceberg，然而实际过程中发现这个架构间隔生产场景还有很大的 gap，所以有了 Arctic 我的项目（http://github.com/NetEase/arctic）。
数据湖 Table format 之争先看目前 Apache Hudi、Apache Iceberg、Delta 这几个支流的开源 Table format（表格局）的选型。Table format 这个概念最早由 Iceberg 提出，当初行业对它的了解次要有两点。第一点是 Table format 定义了哪些文件能够形成一张表，这样 Apache Flink、Apache Spark、Trino、Apache Impala 等任何引擎都能够依据 Table format 去查问、检索数据。第二点就是 Table format 标准了数据和文件的散布形式，任何引擎写入数据都要遵循这个规范，通过 format 定义的规范来反对以前 Hive 不反对的 ACID 和模式演进。咱们看到 Iceberg、Delta 和 Hudi 在这些性能上基本上是拉平的，尽管他们在各自实现上有很大不同，但形象他们的共性集体认为是十分有意义的事件。
拿目前支流的数据湖 Table format 和 Hive 进行比照，Hive 简略定义了表和 HDFS 上动态目录的映射关系，它自身是没有 ACID 的保障的，咱们在实在的生产场景中只能单读单写。目前咱们下层的数据中台或者是 DataOps 平台可能通过工作流的形式保障咱们能正确应用 Hive，当然只能用于离线场景。
新的 Iceberg、Delta、Hudi 所主导的 Table format 能力中，减少了一个快照的概念，表的元数据不再是一个简略的表和文件的关系，变成了表和快照以及快照和文件的关系，数据的每次写入会产生新的快照，而这个快照和文件产生一个动静的映射关系，这样它能实现每次写入 ACID 的保障，也能通过快照的隔离实现用户的多读多写。而且基于快照也能给下层提供一些比拟有意思的性能，比如说能够基于快照的增量写入实现增量读，也就是 CDC 的性能，能够通过快照去反对回溯，例如咱们在 time travel 或者数据的 rollback。总结下来 Table format 有四点外围个性。第一，构造自在。像之前的 Hive 只能反对简略的加列操作，而在 Delta、Iceberg 这样的 Table format 之上用户能够自在地更改表的构造，能够加列、减列、改列，而且对数据的迁徙和变更不会有要求。第二，读写自在。因为它通过快照可能保证数据的 ACID，任何实时、离线以及 AI 的需要都能够自在地往这个表外面写数据或者读数据。第三，流批同源。因为 Table format 外围的一个性能是能够很好地反对流场景，咱们的批和流都能够往新的 Table format 去写和读。第四，引擎平权。这点十分重要，它不能只是绑定某一个引擎，比如说像 Delta 在 1.0 时代是 Spark 生态中的一个组件，在一个月之前 Delta2.0 的公布再次向咱们证实了去适配多个引擎的重要性。在 Table format 这些我的项目的官网中，他们会主推一些性能次要蕴含 CDC、SQL 扩大，数据的 Rollback，以及 time travel，模式演进（Schema evolution）以及咱们常常说的流式更新（Upsert）、读时合并（merge-on-read）的性能。CDC 肯定水平上能起到平替音讯队列的作用，比如说在生产场景中，实时计算次要会用 Kafka 或者 Pulsar 做流表的选型。有了 Table format 之后，咱们能够基于数据湖来实现相似于音讯队列的性能，当然它的数据提早会从毫秒或者秒级降级为分钟级别。像 Upsert、读时合并和行业内或者说很多公司去推广数据湖的次要场景，就是拿这个实时更新以及读时合并去平替 Apache Kudu、Doris、Greenplum 这些实时更新的数仓零碎。企业须要怎么的数据湖首先一点是如果咱们只是关注数据湖 Table format 中个别的性能，推广起来是十分艰难的。比如说数据湖的 CDC 性能，的确在某种程度上可能平替音讯队列，然而也会引入一些其余的问题：首先是提早的问题；其次是用数据湖做音讯队列可能会引入很多小文件，这个小文件谁来治理？还有第三个是比拟隐形的问题，以前音讯队列的老本就是挂在业务团队那边，如果咱们当初用一个公共的数据湖底座，这个老本该怎么摊派？在过来两年中，咱们跟行业内很多公司交换，大体上都是在这样一种矛盾之中挣扎，想用数据湖的新技术来代替一些其余计划，对业务的吸引力是十分有余的。咱们的数据湖或者 Lakehouse（湖仓一体）的技术到底能给企业带来怎么的价值？在咱们的生产场景中，咱们的整个数据平台体系在 2020 年遇到最次要的问题，就是流批平台割裂。大家晓得咱们围绕 Hive 这套离线数仓曾经产生了十分丰盛的方法论，从数据模型、数据资产到数据品质，基于数据湖的凋谢架构咱们产生了十分好的一套标准、规范以及治理体系。然而咱们把眼光切换到实时场景下，目前次要用 Flink 做实时计算，用 Kafka 作为流表的选型，当咱们做流表 join 时可能独自须要从数据库那边拉一个实时同步的工作，前面如果咱们做数据分析，须要比拟高的数据新鲜度，须要引入 Kudu 或者 Doris 这些可能准实时或者实时更新的数仓零碎。这套货色和咱们离线整套的技术选型以及工具是十分割裂的，而且没有造成比拟好的标准，次要还是点对点的开发为主。举个例子，如果咱们既要做实时也要做离线，就须要拉两套链路。离线的链路依据咱们整套方法论，依据离线整个流程的工作流，是能比拟容易标准地定义出一套进去。实时场景下咱们更多须要开发者，须要用户本人去理解 Flink 怎么玩儿，Kafka 怎么读，这个过程中序列化、反序列化怎么做，怎么在 Kudu 上建表，这一套标准给用户带来了十分大的累赘。
尤其是 AI 的一些业务，他们要做数据生产，其实更加关注数据训练、样本这些跟 AI 相干的流程自身，对 HBase、KV 这些他们是一律不理解的，所以他们会把需要提到另外一个团队，而另外一个团队只能点对点地去响应。总结一下传统 Lambda 架构给咱们带来哪些弊病。第一是数据孤岛的问题。如果咱们应用 Kudu 或者其余跟数据湖割裂的一套数仓计划，会带来独立的洽购和部署老本，会因为容易存储而节约老本。因为数据之间难以复用和互通，如果咱们在雷同的业务场景下须要一个实时的数仓，可能须要从源头从新拉一份数据进去，导致老本和人效的节约。第二是研发人效低，研发体系割裂，研发标准不通用。这在 AI 特色、举荐的场景比拟典型，须要用户本人去搞定什么时候调用实时的货色，什么时候调用离线的货色，会导致整个业务层非常复杂。最初是指标和语义的二义性问题。比方过来几年咱们次要是应用 Kudu 作为实时数仓计划，用户须要本人在 Kudu 外面建一个数仓表，会有 Kudu 的一套 Schema，在 Hive 这边有一套通过数据模型创立的表，而这两套货色都须要用户本人去保护。当业务逻辑产生变更的时候，用户可能改了 Hive 然而没有改 Kudu 的，短暂下来就会导致指标和语义的二义性问题。而且随着工夫的推移，保护的老本会越来越高。所以业务冀望的是什么呢？其实是咱们在平台层，在整个数据中台层或者在整套数据的方法论这一层，可能用一套标准、一套流程把实时和离线，以及 AI 等更多的场景对立。所以咱们回过头来看 Lakehouse 这个概念发明进去的意义，就是拓展产品的边界，让数据湖能更多地服务于流的场景、AI 的场景。在咱们的生产场景中，Lakehouse 给业务最终带来的该当也是一个体系上的收益，而不在于说某一个性能上用了它。比如说我在 CDC 或者在剖析的场景下用了，然而如果用户只是单纯地去比拟 Kudu 和 Hudi 或者 Iceberg 之间的差别，他可能很难说到底带来什么样的收益；然而如果咱们通知用户说整套平台能够即插即用地把离线和实时全副对立掉，这个收益就很大了。基于这样一个指标，咱们开发了流式湖仓服务 Arctic 这样一套零碎。了解 Arctic 流式湖仓服务 Arctic 是什么呢？简略来说 Arctic 是由网易数帆开源的流式湖仓零碎（Streaming LakeHouse Service），它在 lceberg 和 Hive 之上减少了更多实时场景的能力，所以 Arctic 首先强调的是实时场景的能力，并且面向 DataOps 提供开箱即用的元数据服务，而且让数据湖更加好用和实用。咱们用一句话概括会比拟形象，前面咱们会用更多功能的举例以及咱们一些干货上的分享，让大家深刻了解 Arctic 到底是什么。生态位差别首先咱们通过这张图强调生态位的差别，Arctic 从生态位上在 Table format 之上，所以严格意义上说咱们不应该把 Arctic 当成是另外一套 Iceberg 或者另外一套 Table format。
另外一点，咱们在 Table format 之上，次要思考跟开源的 Table format 做兼容，所以 Arctic 的一个外围指标是帮忙企业用好数据湖的 Table format，以及解决或者拉平在 Table format 以及用户，或者说产品实在的需要之间的 gap。Arctic 自身蕴含两个外围组件，第一个是元数据服务 AMS，它在咱们零碎中定位是下一代 HMS 的角色。第二个，咱们继续自优化的性能，会有整套 optimizer 组件和机制，来实现后盾数据优化。Tablestore 设计与劣势咱们之前和很多用户聊过 Arctic，大部分用户的第一个问题是咱们跟开源的 Iceberg 具体是什么关系。通过这张图我想来阐明这点。首先在 Arctic 中有 Tablestore 这个概念，Tablestore 是一个存储单元的定位，有点相似于传统数据库外面聚簇索引的概念。当流式写入的时候，咱们会用一个 change 的 Tablestore 存储一个 CDC 写入的数据，这个数据有点相似于咱们数据库中的 binlog 或者 relog，前面这个 change table 能够用于 CDC 的回放，也能够当作一个独自的表来拜访。
Hudi、Iceberg 也有 upsert 的性能，但 2020 年咱们开始做这个事件的时候 Iceberg 还没有这个性能，社区出于对 manifest 这层设计的谨严考量在实现上会有一些斗争，所以最终咱们决定了在下层去做这个事，并且会体现咱们的一些劣势。Change 表次要存储的是 CDC 的 change 数据，另外还有一套 Basestore 会存储咱们的存量数据，两个 Tablestore 其实是两张独立的 Iceberg 表。另外咱们还可选的集成 Kafka 的 logstore，也就是说咱们的数据能够双写，一部分先写到 Kafka 外面，再写进数据湖里，这样实现了流表和批表的对立。这样设计有什么样的劣势？首先 change 表里的 CDC 数据能够按程序回放，会解决 Iceberg 原生的 V2 CDC 不太好回放的问题。第二个是 change 表能够凋谢拜访。在很多电商、物流的场景里 change 数据不光是作为一个表内置的数据用，很多时候订单表、物流表的变更数据也会作为独立的数仓表来用，咱们通过这样的设计容许把 change 表独自拎进去用，当然会增加一些写入爱护。如果将来业务有一些定制化需要，比如说在 change 表中额定增加一些字段，增加一些业务本人的 UDF 的计算逻辑，这个设计也具备这样的可能。第三点咱们这套设计理念 change 和 base 之间的转化，这个过程是 optimize。这个概念在 Delta、Iceberg 和 Hudi 中都有介绍过，它的外围是做一些小文件合并，咱们把 change 数据到 base 数据的转换也纳入 optimize 的领域，并且这些过程对用户来说是通明的，如果用户间接用 Iceberg 或者 Delta，所有的 optimize 操作在底层都会有一个快照，这样对用户是不敌对的，咱们在下层把这套货色封装起来了。当用户读一个高新鲜度的数据做剖析时，咱们的引擎端会做一个 change 和 base 的 merge-on-read。Arctic 架构和组件了解了 Tablestore 的概念之后再来看 Arctic 的架构和组件，咱们就会更加容易了解。在数据湖这一层咱们有 change files、base files，别离对应 changestore 和 basestore。Tablestore 的概念不仅能够用于 CDC 的场景，将来对于一些排序，对于 ZOrder 一些具体的需要同样能够采纳下层架设独立的 Tablestore 来解决。
在下层咱们有一个后面介绍过的 AMS（Arctic Meta Service），AMS 是 Arctic 流式湖仓服务中“服务”这一层所重点强调的组件，是面向三元组的元数据中心。三元组是什么呢？就是 catalog.table.db 这样的三元组，大家晓得在 Spark 3.0 和 Flink 1.2 之后，主推的是 multi catalog 这样的性能，它能够适配不同的数据源。目前咱们在支流的大数据实际中更多的是把 HMS 当作元数据中心来应用，HMS 是二元组的构造，如果咱们想扩大，把 HMS 外面依据更多的数据源，须要做很多定制性的工作。比如说网易数帆无数平台其实是在 HMS 之外独自做了一个元数据中心，来治理三元组和数据源的关系，AMS 自身就是面向三元组设计的元数据服务。第二个咱们的 AMS 能够和 HMS 做同步，就是咱们的 Schema 能够存在 HMS 外面，除了 Hive 所可能存储的一些字段信息外，一些额定的组件信息，一些额定的 properties 会存在 AMS 中，这样 AMS 能够和 HMS 一起提供服务，所以业务不必放心在应用 Arctic 的时候肯定要做一个替换，这其实是一个很灰度的过程。第三个是 AMS 会提供事务和抵触解决的 API。在 optimizer 这儿，咱们有一整套残缺的扩大机制和管理机制。首先咱们有一个 optimizer container 的概念，实质上是平台调度工作的组件，咱们整个后盾的 optimize 过程对业务来说是通明的，后盾须要有一套调度服务，可能把 optimize 的过程调度到一个平台中（比方 YARN 上、K8s），这种不同的模式就是 optimizer container 的概念，将来用户也能够通过 container 接口去扩大它的调度框架。optimizer group 是在 container 外部做资源隔离，比如说用户感觉有一些表的 optimize 须要高优先级运行，能够给他抽出一个独立的 optimizer group 执行他的优化工作。第三点在咱们架构中有独自的 Dashboard，也是咱们的一个治理界面，咱们十分重视湖仓自身的治理体验。最初一点也是十分重要的，方才提过咱们有 Table format 齐全兼容的个性。目前提供两种，一个是 Iceberg，因为咱们是基于 Iceberg 来做的，basestore、changestore 都是独立的 Iceberg 表，并且咱们的兼容是随着 Iceberg 的迭代继续推动的，目前曾经兼容 Iceberg V2。另外咱们也有 Hive 兼容的模式，能让业务在不必改代码的前提下，间接应用 Arctic 的一些次要性能，如果用户应用的是 Hive format 兼容，它的 change 数据还是存在 Iceberg 外面的。治理性能之前有提到 Arctic 十分重视治理体验，尤其对于咱们后盾继续优化的治理，有一套性能以及绝对应的度量和标定的能力提供给大家。下图中所展示的，哪些表正在 optimizing 用到的资源、继续的工夫，将来应该怎么做一个更正当的资源调度，通过咱们的治理性能都会给到大家。
咱们的 table service 的性能，对于表有很多元数据的信息，包含每张表动静的变更，一些 DDL 的历史信息，事务的信息，都会在表服务中体现。
并发抵触解决当咱们采纳了 Table format 去解决流批同源场景的时候，举个例子，比方下图上半局部，咱们在做一个数据的 CDC 同步，失常状况下是一个 Flink 工作去做继续的同步，然而如果咱们想做数据回滚或者要做数据更正，比如说增加了一列，这一列有个默认值，须要咱们通过批的形式把数值初始化一下，会起一个 Spark 工作和 Flink 同步去跑。这个时候如果 Saprk 工作和 Flink 工作操作到了同一行数据，这个数据的主键是一样的，就会遇到数据抵触的问题。
当初在 Table format 这一层广泛提供的是乐观并发管制的语义，当咱们呈现抵触的时候首先想到的是让某一个提交失败，换句话说，乐观并发管制的语义外围的一点是不容许并发呈现，那么在咱们这个场景里 Spark 工作可能永远提交不胜利的，因为咱们对它的期待是做全副的数据重写，这样它的数据领域是肯定会和咱们的实时数据抵触的。但业务必定心愿他的数据可能提交胜利，所以咱们提供了并发抵触解决的机制，让这个数据可能提交胜利，并且同时保障它仍然具备事务一致性的语义。下半局部也是相似的，咱们对一个数仓表、湖仓表进行了 ad-hoc 并发的更新 c1 和 c2，c1 在 c2 之后提交，然而 c1 在 c2 之前开始，当它们呈现抵触之后是 c1 笼罩 c2，还是 c2 笼罩 c1？从目前数据湖计划来说，个别是谁后提交以谁为准，然而在更多的生产场景中咱们须要谁先开始以谁为准。这一块工夫关系就不开展，有任何疑难能够在用户群里与咱们深刻交换。Arctic auto bucketing 在性能方面 Arctic 也做了很多工作，咱们目前是基于 Iceberg 的，Iceberg 是非常灵活凋谢的 Table format，它在 partition 之下没有思考我的数据以及我的数据对应的更新，应该怎么更好地做映射来晋升它的性能。在 Iceberg 之上咱们做了 auto bucketing 的性能，这个性能跟 Hudi 中 file_group 的概念有些相似。不同的是咱们没有给用户裸露 file_group 或者 file_index 这样的概念。咱们在文件之上提供了分组的性能，是一种可扩大的形式，通过二叉树的扩大形式让每一个节点的数据量尽可能维持在用户配置的大小。比如说 Iceberg 默认配置 128 兆，咱们通过后盾的一整 optimizing 套机制，会尽可能保护每个 node 的大小向 128 兆聚拢。
当一个 node 数据超过这个领域之后，咱们会尝试把它决裂，之前也提到咱们分了 changestore 和 basestore，它们都是依照同样的形式治理，这样在每一个节点之上能够对应到 change 数据和 base 的数据，就能实现更精密的数据映射，数据分析的性能会有一个十分好的晋升。能够看到在 merge-on-read 的过程也能够用到整套机制。2000 年左右伯克利有一篇论文专门形容这种计划，感兴趣的同学也能够本人去理解。
Arctic 性能测试流式湖仓，或者在数据湖上做实时流式数仓的整套实际，目前还没有十分好的 benchmark 工具来定义它的性能怎么样。对这个问题咱们也做了很多思考和摸索，目前咱们的计划和 HTAP benchmark 采纳的思路是统一的，依据 TiDB 的介绍，找到行业里很早就有的 CHbenchmark 这个概念加以革新。CHbenchmark 反对一个数据库既跑 TPC-C 也跑 TPC-H。从下图右边能够看到，有 6 张表是重合的，既在 TPC-C 中跑也在 TPC-H 中跑，有 3 张表是在 TPC-C 中援用，3 张表只在 TPC-H 中援用。
基于这套计划咱们做了一个革新，首先用 TPC-C 跑数据库，在上面咱们再跑一个 Flink CDC 工作，把数据库实时流式地同步到 Arctic 数据湖中，用 Arctic 数据湖构建一个分钟级别数据新鲜度的流式湖仓，在这之上咱们再跑 CHbenchmark 中 TPC-H 的局部，这样能失去比拟规范的流式湖仓的数据分析的性能。针对 optimize 前后的 Arctic、Iceberg 和 Hudi 测试的后果（Trino 下测试），咱们按阶段做了一个简略的比照，分为 0-30 分钟、30-60、60-90 分钟和 90-120 分钟四组。下图蓝色的局部是没有 optimize 的数据分析的性能，从 0-30 分钟，到最初的 90-120 分钟，提早从 20 秒升高到了 40 多秒，升高了一半多。而黄色局部有继续合并的 Arctic，性能稳固在 20 秒左右。
灰色的是原生的 Iceberg upsert 计划，0-30 分钟是在 30 秒左右，从 30-60 分钟性能是急剧下降的。为什么 Iceberg 呈现了这么大的性能滑坡呢？因为原生 Iceberg 的确没有 insert 数据和 delete 数据的精细化的映射，所以当咱们继续写入流式文件之后，每一个 insert file 都会跟 delete file 产生十分多的关联，从而导致咱们在 Trino 中做 merge-on-read 的性能急剧下降。前面测 60-90 分钟、90-120 分钟就间接 OOM，跑不进去了。黄色局部是 Hudi。目前来看 Arctic 和 Hudi 一样，通过后盾优化可能保障数据分析的性能，维持在一个比拟安稳的数字。目前来看咱们通过下层的优化，比 Hudi 要好一些。后续咱们也会在官网中把咱们整个测试流程和相干配置向大家公开。Arctic 目前看 mor 性能相比 Hudi 有肯定劣势，这里咱们先不强调 Arctic 做得有多好咱们也钻研了 Hudi，它有 RO 和 RT 两种模式，前者是只会读合并数据，RT 模式是 merge-on-read 的一种模式。它的 RO 模式和 RT 模式性能差距十分大，所以将来可能会有很大的优化空间。Arctic roadmap 与总结最初咱们对 Arctic roadmap 以及整个零碎做个简略的总结。Arctic 是一个流式湖仓服务，提供别离对应 streaming、lakehouse、service 的外围个性。streaming 层面咱们提供了主键的高效流式更新，咱们有数据自分桶、构造自由化的能力，Spark、Trino merge-on-read 的性能，提供分钟级别新鲜度的数据分析。在 lakehouse 层面咱们做到格局的兼容，百分之百兼容 lceberg 和 Hive 的表格局语法，如果有一些性能是 Arctic 没有而 Iceberg 有的，用户只须要切换到 Iceberg catalog，就可能把一张 Arctic 表当作 Iceberg 表来应用，并且咱们提供了 base 和 change 两个表的拜访形式。引擎平权反对 Spark 和 Flink 读写数据，反对 Trino 和 Impala 查问数据，目前 Impala 次要是用到 Hive 的兼容个性，能够把 Arctic 表作为一个 Hive 做查问，从而反对 Impala。
在 service 这一块次要强调治理上的性能：第一个是反对将数据湖和音讯队列封装成对立的表，实现流批表的对立，这样用户应用 Arctic 表不必放心从秒级或者毫秒级升高到分钟级别，他仍然能够应用数据湖提供毫秒或者秒级的数据提早的能力。第二点提供流式湖仓标准化度量，dashboard 和相干的管理工具。第三点是解决并发写入抵触，实现事务一致性语义。在治理层面咱们聚焦答复上面这几个问题，这些工作还有很长的路要走。第一个是表的实时性怎么量化，比如说咱们搭建一个流式的湖仓表之后，以后的新鲜度是一分钟、两分钟还是多少，是否达到了用户的预期。第二个怎么在时效性、老本、性能之间给用户提供 trade off 计划。第三个查问性能有多少优化空间，须要投入多大的资源做这样的事件。第四点数据优化的资源该怎么量化，怎么最大化利用这些资源。如果用户深刻理解 Arctic，会发现咱们 optimizing 跟目前 Hudi 其余的有很大不同，首先咱们 optimizing 是在平台层面调度的，不是在每一个写入的工作里做的，这样咱们能够集中化治理这些数据优化的资源，并且能够提供最快的迭代。比方咱们发现通过一些优化可能让合并效率有很大的晋升，就能够很快迭代。最初一点是怎么灵便分配资源，为高优先级来调度资源。在将来 Core feature 维度的工作，首先咱们关注的是不依赖内部 KV 实现 Flink lookup join 性能。咱们之前看到的一个架构里，如果在实时场景下做一个维表 join，可能须要一个内部的 KV 做同步，目前咱们在做这样的计划，就是不须要做内部的同步了，能够间接基于 Arctic 表来做维表 join。第二个是流式更新局部列，当初咱们次要是通过 CDC 来做 streaming upsert，很多场景，比方特色、大宽表，咱们可能须要可能更新局部列。前面是更多的 optimizer container 反对，比如说 K8s；更多 SQL 语法的反对，比如说 merge into—— 目前咱们在 Arctic 层面还没有这样的语法，用户能够把 Arctic 的表当成 Iceberg 表来用，来反对 merge into。将来如果在 Arctic 层面反对了 merge into，它会和 Iceberg 有所不同，因为咱们的变更数据首先会进入到 change 空间。最初一点因为咱们的生态位是在数据湖 Table format 之上，所以将来咱们会做架构的解耦，去扩大到更多的 Table format，比方 Delta、Hudi。最初谈谈咱们开源的初衷。过来咱们做开源可能没有一个十分对立的步调，去年咱们领导层下了一个信心，会依照一种更加专一的形式做开源，以 Arctic 这个我的项目为例，咱们不会做任何的商业暗藏。而且从组织架构而言咱们团队推动开源也是十分独立的过程，如果可能有商业化会由其余的团队推动。咱们会致力于为开发者、用户、成员构建一个公开、自在的数据湖技术交换社区。当然目前咱们次要面向的是国内用户，官网也是以中文为主。心愿更多的开发者参加到咱们这个我的项目中来。这是我明天要分享的全部内容，谢谢大家！Q&A 主持人：有没有关注过对于 Flink Tablestore 的个性，跟 Arctic 又有怎么的区别？马进：有。首先大家做的货色都比拟类似，去年咱们就看到了 Flink 社区外面这样的 proposal。我了解 Flink 肯定会做这样的事件，他们也是心愿能搭建一套本人残缺的生态，就像 Delta 对于 Spark 一样。尽管是类似的，然而大家的指标是不太一样的，Flink 做这个事对流这个场景而言更加原汁原味，然而必定不会像咱们更多思考到怎么在 Spark 上，在其余的引擎上做一些事件，怎么在下层提供更多的治理性能。所以抛开一些性能上的重合，我了解大家的初衷或者最终要解决的问题还是会有差别。主持人：尽管在表现形式上是类似的，然而 Flink tablestore 的这种形式更贴近原生 Flink 的场景，然而咱们除了兼容 Flink 的场景之外还会有更多偏差于 Spark 的场景做兼容和反对。马进：不光是 Spark，咱们还提供了 Hive 兼容。如果是 Hive 用户，怎么能让一些 Hive 表比拟顺滑地降级到咱们湖仓一体新的架构上，这是咱们零碎去考量的一些货色，在这个过程中怎么提供一些便当的治理性能，提供度量指标，这些可能和 Flink Tablestore 思考的点是不一样的。主持人：Arctic 底层方才讲到是基于 Iceberg 实现的，在代码上有强绑定的关系吗？当前会不会思考基于其余的 Table format 做这种转换？马进：咱们也经验过一些变动。当初咱们本人定的规范首先不会侵入到 format 外部的实现，也不会魔改开源的代码。但晚期咱们并没有这样明确的指标，会有一些在 Iceberg 上的更改。当初咱们代码和 Iceberg 相对来说是能够做一个比拟洁净的解耦，然而目前咱们没有做这个事，比如说 Schema 这些定义用的还是 Iceberg 包里的货色，然而这个货色要解耦是很容易的。这外面有个设计上的初衷，产品要去思考怎么把数据湖用起来，会有一些思考，比方 Iceberg 和 Delta 谁更可能成为将来的支流？咱们心愿用户能罢黜这样的懊恼，将来咱们心愿能在下层给用户提供一个对立的他须要的 Lakehouse 计划，上层咱们再做这样的选型。主持人：说白了咱们不帮用户做出最终的决定，而是提供更多的可能性，无论将来是 Iceberg 还是 Delta，咱们都能用一种比拟凋谢的形式兼容。马进：这个是久远的，当初咱们还会和 Iceberg 联合得严密一些。嘉宾简介马进，网易数帆大数据实时计算技术专家、湖仓一体我的项目负责人，负责网易团体分布式数据库，数据传输平台，实时计算平台，实时数据湖等我的项目，长期从事中间件、大数据基础设施方面的钻研和实际，目前率领团队聚焦于流批一体、湖仓一体的平台计划和技术演进，及流式湖仓服务 Arctic 我的项目开源。Arctic 文档：https://arctic.netease.com/ch… 地址：https://github.com/NetEase/ar… 视频观看：https://www.bilibili.com/vide… 交换群：微信增加“kllnn999”为好友，注明“Arctic 交换”理解更多：从 Delta 2.0 开始聊聊咱们须要怎么的数据湖