网易数帆开源Arctic，lceberg、Hive上增加更多实时场景

湖仓一体，可以提供数据湖的开放格式、低成本存储，以及强大的管理能力。数据分析、机器学习、实时计算、音视频检索等都可以从“湖”里汲取数据，从而让数据治理更加便捷高效。

在传统行业数字化转型过程中，尤其像在金融行业，全域数据统一管理、集中开发和融合共享是必然趋势，这是时下湖仓一体被寄予厚望的重要原因。那么，如何架构经过验证的湖仓一体解决方案，并推动它很好的演进？

近日，网易数帆举办了“企业级流式湖仓服务Arctic开源发布会”。发布会上，详细介绍了网易数帆如何理解湖仓一体、Arctic项目的孵化和成型，这一项目可以解决哪些问题、发挥怎样的能力、能够为大数据从业者带来什么，以及社区的建设和未来的发展。

产品发布：开放式架构下的开源流式数仓平台

在长期服务客户的过程中，网易数帆总结出自己的数据建设方法论：DataOps、DataFusion，以及DataProduct。发布会开始，网易数帆大数据产品线总经理余利华就如何在这一方法论之下架构开源流式数仓平台，以及如何进行Arctic项目孵化进行了深入分享。

在网易数帆的大数据技术体系架构中，最底层是基础设施，即存储计算能力架设；底层之上是数据研发层，提供包括数据传输、实时开发、离线开发、数据测试、任务发布、任务运维等能力，覆盖DataOps整个过程；再往上是数据中台，在这一层，数据研发和治理的一体化、中台架构解决数据孤岛，以及设计基于ROI的数据资产沉淀方法是主要亮点；数据中台再往上是数据产品，可基于无代码的方式建设场景化的数据产品。

首先，在技术架构上，该体系最大的特点是开放式，可让各模块独立成为一个项目：存储单拉出来是HDFS，缓存单拉出来是Alluxio，执行引擎和查询拉出来是Spark、Impala，等等。每个模块独立成一个项目，通过松耦合的方式组装在一起就形成了开放式大数据技术体系。这样的架构好处显而易见，包括能力全面、生命力强，以及建设成本较低。

其次，第二个技术特点是开源，包括采用直接开源的软件，以及在开源软件不能满足的情况下给社区做Patch。这样一来不仅能够被社区评审和检验，公司本身也不用长期维护Patch，降低维护成本。截至目前，网易数帆在Spark领域累计合入提交了近600多个Patch，同时也培养了一位Spark committer。网易数帆在整个大数据发展史上，培养了多位Apache的committer。

此外，如果社区确实无法满足开源需求，才会进行自研开源，比如Kyuubi。这个项目在立项时，开放式架构的其他层有Spark、Impala、Parquet等开源技术可选，但是缺少统一的多租户安全的SQL网关，因此Kyuubi诞生。目前这个项目已进入Apache孵化，并在阿里云、腾讯云、中国移动、小米等公司落地，有17位committer和83位贡献者。

当然，在建设中台的过程中，也面临不小的挑战。首先，是技术不统一，实时技术和离线技术采用两套技术栈，带来的问题是整个系统的运维复杂，同时存储冗余也浪费成本；其次，研发体系的割裂让成本增加。此外，应用开发也十分复杂，将实时表和离线表通过两种存储方式存储，不仅增加了用户理解困难度，冗余数据也带来了数据口径的指标二义性问题。

在余利华看来，以上问题的解决核心在于提供流式数仓平台，把实时表和离线表相结合，一张表既可以支持流式消费、流式写入，也要支持批量查询和更新。

在基于数据湖的开放式架构中，从下到上分别是文件系统层，实现数据的存储和访问；文件格式，定义文件和数据之间的关系；表格式层，定义文件与表之间的逻辑关系；最上层是接口，是以SQL的方式统一访问的入口。

如果要支持流式数仓，需要在表格式层动点“小手术”，引入Iceberg、Delta等新型表格式。新型表格式解决了数据更新、大表访问性能、数据增量消费等问题，但是仍然遗留了不少问题。余利华举了三个例子：第一是小文件问题，频繁数据写入，带来很多小文件，导致查询性能很差，有时候性能会下降一半； 第二是兼容性问题，是否能兼容目前最主流的HIVE格式，简化应用推广，是否能兼容Iceberg/Delta等格式，数据中台还是那个数据中台，我们只是多了选择表格式的自由； 第三是流式更新问题，Iceberg、Delta表格式流式更新能力较弱， 用在数据库到大数据实时同步场景性能有所不足， 短期内需要做一些增强。

为对以上问题进行针对性解决，网易数帆和华泰证券一起研发了企业级的流式湖仓服务Arctic，并将其开源。

Arctic技术架构：实现开箱即用的元数据服务

据网易数帆大数据实时计算技术专家、湖仓一体项目负责人马进介绍，公司自2020年开始关注数据湖新技术便聚焦于构建流批一体和湖仓一体的架构。最初想要采用Flink+Iceberg，但在真实场景应用时发现过多问题，因而进行了自主设计，便是Arctic的雏形。

也是从2020年开始，Hudi和Iceberg进入不少开发者的视野，随着它们从Apache孵化到毕业，Table format的概念逐渐被更多人接受。首先，Table format定义了哪些文件可以构成一张表，像Flink、Spark、Trino、Impala，任何引擎都可以根据Table format去查询检索数据；其次，Table format规范了数据和文件的分布方式，任何引擎写入数据都要遵照这个标准。

事实上，在有了Table format之后，可以基于数据湖来实现类似于消息队列的功能，数据延迟会从毫秒或者秒级降级为分钟级别，像实时更新、读时合并。行业内很多公司推广数据湖的主要场景时，主要以实时更新以及读时合并平替如Kudu、Doris、Greenplum这些支持更新的数仓系统。

进一步，在企业需要怎样的数据湖这个问题上，有三点值得注意：首先，如果只关注数据湖Table Format个别中间功能，推广起来会比较困难；其次，当用数据湖做消息队列时，可能引入很多小文件，小文件的管理需要保持关注；最后，还有一个隐形的问题——成本分摊，以前消息队列的成本由业务团队承担，现在用一个公共的数据湖底座，成本的合理分摊也需要注意。

因为存在以上问题，业内很多公司在是否使用数据库新技术作为替代解决方案这个问题上都比较纠结。那么，Lakehouse技术如何给企业带来更大价值？

在马进看来，应用场景一般期望在数据中台层、方法论层可以使用一套规范或流程把实时和离线，以及更多的AI场景统一起来。而Lakehouse这个概念创造出来的意义，就是拓展产品的边界，让数据湖能更多的服务于流的场景和AI的场景，他表示：“Lakehouse，或者说湖仓一体给业务终端带来的是体系上的收益，而不在于对某个功能的使用。”

为了实现这样的效果，Arctic在lceberg和Hive之上增加了更多实时场景的能力，面向DataOps提供开箱即用的元数据服务，让数据湖更加合用和实用。

具体来说，Arctic包含两个核心组件：元数据服务AMS，在系统中的定位是下一代HMS的角色；以及包含了整套optimizer的组件和机制，可以实现持续的后台数据自优化。

具体到架构和组件的设置，在数据湖层包括change files、base files，分别对应changestore和basestore；上层则设置了一个AMS，是三元组的元数据中心，支持和HMS做同步。同时，AMS会提供事务和冲突解决API；在Optimizer层，有一整套完整的扩展机制和管理机制，包括Optimizer container和Optimize group。此外，在Arctic架构中匹配了单独的管理界面Dashboard，提升湖仓本身的管理体验。而在Table format的兼容性设定上，主要提供两种方案，其一是Iceberg，包括basestore、changestore都是独立的Iceberg表，均可兼容到Iceberg的V2版本；其二是Hive的兼容模式，如果用户使用的是Hive formate兼容，它的change数据还是存在Iceberg里面。

谈及做开源的初衷，马进表示说：“过去我们做开源可能缺少统一的步调，去年领导层也下定决心，明确了未来做开源会以更加专注的方式。以Arctic项目为例，我们不会做任何的商业隐藏。从组织架构上，会以独立的团队推进开源，如果有商业转化会由其他的团队来推进。”

在发布会最后，来自华泰证券的大数据流计算技术专家陈丰进行了关于Arctic在金融数据平台的应用实践案例分享——帮助公司初步建成了数智中台实时湖仓，并在业务支撑中取得了预期的效果。

湖仓一体最大应用难点在选型，好的开源气质是“不隐藏”

1、湖仓一体能解决最核心的问题是什么，是如何解决的？

马进：对湖仓一体的概念理解，在国内可能有一些分歧。这个词最早是阿里提出的，当时提湖仓一体更多是想把MaxCompute和私有化的Hive结合起来，让用户私有化的Hive扩展到云端的MaxCompute中来。但我们如今所说的湖仓一体概念更多是指Databricks提出的Lakehouse这样的概念，它解决的核心问题是基于数据湖的技术，包括云端的对象存储，比如亚马逊的S3，阿里云的OSS，以及在私有化场景中主要是Hadoop，在这些数据湖的生态之上构建BI、AI和流计算，包括各种应用场景中的工具使用。

湖仓一体要做分层，首先要有对基础软件的需求，需要有一套管理系统以及对应的底层技术，能够让数据湖满足我们对各种各样场景的需求，包括对离线的需求、实时的需求，以及机器学习、特征计算这些不同应用的需求。

另外，我们可能需要在产品端，针对Lakehouse湖仓一体的技术做一些适配，让它的整个规范流程能够用这样一个底座实现最简洁的方式。所以回到这个问题，湖仓一体核心的问题其实就是将产品的边界、方法论的边界拓展到实时场景、AI场景，形成完整的、对用户友好和便捷的工具到基础软件的生态。

2、湖仓一体在各产业场景中面临着哪些共通的应用难点，有哪些解决方案？

马进：我觉得湖仓一体最大的应用难点在于选型，我们现在的湖仓一体选型非常多，有Delta、Iceberg、Hudi等。因为不可能让数据分析师、算法工程师、数据科学家们直接操作底层的东西，肯定会有一层产品的包装，以及相应的工具配套。但是这些做工具的人或者做产品的团队很难选型，比如选出什么样的东西对我来说最合理、最好。

所以我们会发现一个现状，虽然这个技术方向很热，但真正把数据湖Format这套技术应用到生产场景中，进而做大规模的推广其实是非常少的，用一句更加通俗的话说，这属于“雷声大雨点小”。所以，最重要的原因是我们现在开源的这些技术功能和产品需求还有很大的距离。

我们推出的开源项目，它的目标或者核心意义在于拉平目前开源Table format与产品之间的距离，我们的定位叫做流式湖仓服务。从概念上就能看出来，并不会基于数据湖重新造一套东西出来。我们更关注怎么能帮助企业和用户把这个东西用起来。在这个过程中，比如说存在管理的问题、适配的问题，都会在这一层基础软件层解决。

3、刚才我们谈到了DataOps，您是怎么看这个技术的？

马进：说起DataOps，很多人会说一长串，不管是流程上还是规范上，说明这个概念还比较抽象，所以需要很多的解释。我个人认为DataOps有点类似于DevOps，更多是给用户提供一套工具集，让用户可以开发数据，同时使用数据的流程变得简单，这个事情是可以体系化的运作的。

比如，我们最早面向数据分析师的数量是几个、几十个，现在大的企业有几百个数据分析师和数据科学家，这就需要多租户的能力。我们通过一套DataOps平台，从数据开发到持续集成，到后续运维，其实有一套方法论。所以，简单来说，我觉得DataOps就是对这套方法论进一步的抽象，它有进化的过程，最原始是数据开发运维平台，到后面有数据中台，可以在平台层沉淀更多的业务能力，在这后面我们强调业务在持续迭代过程中的敏捷性，就到了DataOps。

4、Arctic有持续自优化的能力，具体是怎么实现的？如果已经用了Delta或者Iceberg，迁移到Arctic需要做什么准备工作？有什么需要注意的？

马进：Arctic的持续自优化功能实现涉及两个方面：一是判断湖仓表数据发生了哪些变化，要了解用户新写进来的数据，尤其是小文件，会在引擎的connector中提供对接能力，用户每一次数据提交都会上报到元数据中心，可以实时感知到用户新写入了哪些数据。之后，元数据服务后台会提供一套优化器——optimizer调度服务，可以调度一些持续在进展中的进程做小文件合并，并且我们有整套机制为用户提供一套最佳优化实践。

至于企业已经用了Delta或者Iceberg，迁移到Arctic需要做哪些工作这个问题，首先我们的架构是开放的，从生态位角度来讲可以拥抱Delta，但目前这个工作还没有做，主要还是面向Iceberg。如果企业已经用了Iceberg，把一张表变成Arctic其实非常方便，后续会在社区中提供相应原地升级方案，用户只需要通过一个命令，就能把Iceberg表变成Arctic表，并且它同时依然是一张Iceberg表，可以用之前Iceberg表的所有功能。在使用的时候只需要区分它是用Arctic catalog还是Iceberg Catalog访问，就可以选择用各自的哪些功能，升级的过程是原地升级，而且只是个元数据的变更，会非常快速。

5、您认为好的开源项目是什么样的？Arctic未来会怎么做开源的建设？

马进：一个好的开源项目应该是比较纯粹，符合开源气质的项目。可以拿Delta和Iceberg两个项目来举例，从我的角度讲，Iceberg是非常符合开源气质的项目，因为它本身早期就是从Netflix内部需求孵化出的项目，然后开源出来给更多企业使用，不会说哪个功能是内部使用不对外开放，或者跟自家的某些功能做深度绑定。

Delta是一个非常优秀的项目，它的理念也非常好，自开源伊始它的理念在整个行业都是很超前的。但从当时开源的状态来说，并不是非常纯粹的开源项目，包括有些功能没有放在开源社区里，以及跟Spark深度绑定，有比较强的商业气息。

从我个人视角来看，一个好的开源项目首先应该符合开源气质，不管是团队还是项目本身，不应该有任何隐藏。目标应该通往基金会孵化，贡献给更多的用户和开发者，不只是国内，还有国外的用户。所以，Arctic未来做开源社区建设，我们也会秉承不隐藏的理念，包括和更多的国内外用户沟通，尽可能把项目推向更高的舞台。