网易数帆实时数据湖 Arctic 的摸索和实际
作者 | 蔡芳芳
采访嘉宾 | 马进 网易数帆平台开发专家
数据中台也要从离线为主走向实时化，湖仓一体是第一步。
数据从离线到实时是以后一个很大的趋势，但要建设实时数据、利用实时数据还面临两个难题。首先是实时和离线的技术栈不对立，导致系统和研发反复投入，在这之上的数据模型、代码也不能对立；其次是短少数据治理，实时数据通常没有纳入数据中台治理，没有建模标准、数据品质差。针对这两个问题，网易数帆近日推出了实时数据湖引擎 Arctic。据介绍，Arctic 具备实时数据更新和导入的能力，可能无缝对接数据中台，将数据治理带入实时畛域，同时反对批量查问和增量生产，能够做到流表和批表的一体。
这是作为网易公司根底软件团队的网易数帆首次对外公布在湖仓一体方向的停顿，同时发表的还有网易数帆无数实时数据中台策略。为了深刻理解网易数帆在湖仓一体方向的摸索和思考，以及实时数据湖引擎 Arctic 的设计思路和产品定位，InfoQ 采访了网易数帆平台开发专家马进，围绕以上问题逐个开展探讨。
网易数帆要做什么样的湖仓一体？
湖仓一体（Lakehouse）最后指的是数据湖和数据仓库交融、兼具两者长处的新兴数据架构，但现在它曾经不只是一个纯正的技术概念，而是被赋予了更多与厂商产品层面相干的含意。在湖仓一体越来越火的同时，不同厂商也为它做出了各自的解读。在进一步探讨网易的湖仓一体实际之前，咱们有必要先理解一下网易数帆是怎么了解“湖仓一体”的。
网易数帆团队发展湖仓一体工作次要源于事实利用场景中的一个痛点，即在大数据场景下的实时数据和离线数据的解决链路是割裂开的，而且实时数据和离线数据的存储也别离采纳了两套不同的存储计划。一方面，反复建设和保护的老本比拟大，另一方面，单方的研究成果也没有失去很好的复用。所以，团队一开始的指标其实是为了实现流批一体，也就是将实时数据和离线数据的解决和存储对立起来。
那为什么前面演变成湖仓一体呢？马进将流批一体划分为三个档次，别离是存储流批一体、开发流批一体和工具流批一体，并给出了这样一个等式：
“存储流批一体 = 湖仓一体 = 基于数据湖实现所有数仓性能”
离线数仓存储从实质上来讲，对应的就是数据湖技术，比方 Hadoop 生态的 Hive；相应的，实时数仓对应的就是传统数仓所具备的技术能力，像 Greenplum、Teradata、Oracle 这样的商用数据库，其实都具备流式更新和 ACID 的能力，能够实现一些实时报表的工作。网易数帆团队心愿让基于数据湖概念的离线数仓技术具备实时计算的能力以及 ACID 的保障，也就是具备传统数仓的能力，因而，数据湖和传统数仓各项能力的联合，就是网易数帆团队要做的湖仓一体。基于这个指标，网易数帆打造了实时数据湖引擎 Arctic。
从实现门路来看，Arctic 的原始需要是基于数据湖解决“仓”的问题，团队对它的布局是先要具备“仓”的性能，“仓”的相干工作做好后，再去延展实现“湖”的性能。
逻辑数据湖和湖仓一体，同一场景的两种解法
除了湖仓一体，InfoQ 留神到，此前网易数帆还屡次在公开场合提到另一个概念，即逻辑数据湖。网易数据迷信核心总监、网易数帆无数产品总经理余利华曾在承受 InfoQ 采访时示意，逻辑数据湖是一种性价比更高的形式。这也给咱们带来了一些纳闷：逻辑数据湖这个概念因什么而呈现？它和湖仓一体、数据中台之间的关系要怎么了解？
马进示意，逻辑数据湖与湖仓一体是同一场景下的两个解决方案，实质上来说都是为中台服务的。逻辑数据湖是“物理扩散、逻辑对立”，而湖仓一体是“物理对立”，二者是同一问题下的两个分支。
数据中台提供的是一套数据治理和数据研发的方法论，次要面向业务，其中的数据建模、数据研发包含数据运维，它们的治理体系是一套。然而从中台模块产品往下看，就会有不同计划的拆分。
其中，逻辑数据湖比拟尊重业务以往的历史累赘，比方之前用了 Greenplum、Oracle 这种数据仓库，心愿数据中台可能间接基于这些数据仓库建设，不做数据迁徙。从业务方来看，数据建模、数据开发与中台的治理体系是一套，但底层的数据存储能够不同。逻辑数据湖尝试用技术把一个个数据孤岛买通，比方对不同的数据仓库做联邦 Join，能够认为它是为了解决这种不对立的一个计划。“物理扩散”，即底层的存储能够离开，但“逻辑对立”，下层的中台逻辑是对立的。
据理解，逻辑数据湖计划次要是为了满足网易数帆局部企业客户的需要，网易团体外部其实没有太多这样的累赘，甚至能够说这种累赘简直没有，因为网易外部一开始就是基于 Hadoop 自建数据湖去实现的。但对很多企业客户来说，他们以前洽购了不同的数据库，起初要构建本人的数据湖和数据中台体系，网易数帆就给他们提供了逻辑数据湖的计划，客户能够持续应用原有计划，同时网易数帆给他们提供一个整套的中台入口，对立治理不同的数据孤岛。这是逻辑数据湖次要实用的场景。
相比拟之下，湖仓一体的解决方案更加彻底。对于没有历史累赘的业务场景或企业客户，他们所有新建业务都能够基于湖仓一体的计划来建设。基于湖仓一体计划，底层存储在物理上就是对立的，都基于数据湖，下层也必然是对立的。
能够认为，这两个计划都是服务于整个中台，去构建一个对立的数据中台的治理逻辑。马进解释道，两种计划的收益不同，逻辑数据湖能够让用户疾速上手，更好地笼罩企业的历史累赘；而湖仓一体能够用更低的老本去解决业务上的痛点，如果把工夫线拉长，将来当云计算更大范畴遍及之后，基于云端对象存储建设数据湖，跟应用传统商用数据库或商用数仓相比，节俭的老本可能高达几十倍甚至几百倍。
实时数据湖 Arctic 的设计思路和定位
网易数帆建设湖仓一体的核心技术原理与 Hive 离线数仓计划最大的不同是对数据的治理粒度更加细化，Hive 的治理粒度在 Partition 级别，而网易数帆湖仓一体计划的治理粒度细化到文件。因为下层承接数据中台体系，湖仓一体须要为下层提供体系化的文件治理计划，涵盖文件治理和文件合并等性能，因而具备细粒度的文件治理能力是首要需要。
通过调研，团队最终抉择应用 Apache Iceberg，次要思考是因为 Iceberg 自身的元数据管理是面向文件的，有十分全的 manifest 机制，能够把表中的所有文件治理起来，Iceberg 作为底座提供了 ACID 的事务保障以及 MVCC 性能，能够保证数据的一致性，同时又具备可扩展性。
在 Iceberg 的根底上，团队又自研了实时摄取、文件索引、数据合并，以及一整套元数据管理服务。
技术选型
据马进介绍，在最早做技术选型的时候，团队也调研过与 Iceberg 同类型的开源我的项目 Apache Hudi 和 Delta Lake，但最终都因为一些起因而放弃选用。在做调研时，Hudi 还是绝对比拟关闭的状态（它对本人的定位是 Spark 的一个 Lib，去年年底到往年才开始真正把反对 Flink 作为优先级比拟高的工作），而网易数帆须要一个凋谢的解决方案来适配高度定制化需要。
除此之外，也有一些技术细节的考量。比方数据格式方面的问题，Hudi 的文件索引采纳的是 Bloomfilter 以及 HBase 的机制，这两种机制都不是特地现实，HBase 须要引入第三方 KV 数据库，对商业输入不利，而 Bloomfilter 比拟重，会让实时性大打折扣，因而都不太适宜网易数帆的技术选型。网易数帆对 Arctic 外围性能的想法和设计，也跟 Hudi 有出入。
而没选 Delta Lake 则是因为它对实时性并不是看得很重，马进团队通过钻研相干论文发现，Delta Lake 更多还是把 Spark 的生态作为第一优先级，这与团队做湖仓一体的指标还是有一些区别。
相比之下，Iceberg 绝对更凋谢，对计算引擎的集成、对下层元数据的集成、对不同零碎的集成都做得比拟好，能够满足团队高度定制化的需要。因而团队最终抉择了 Iceberg，能更好地落实本人的想法，并做出网易数帆独有的性能特色。
基于 Iceberg，但不局限于 Iceberg
尽管 Arctic 以 Iceberg 为底座，但马进认为，从社区定位来看，Hudi 才是跟 Arctic 最像的。数据湖仓有一个十分重要的性能，即可能基于主键进行行级更新，Hudi 在性能上与 Arctic 比拟匹配，只是在外围设计上二者存在一致，在实时入湖这一方面 Hudi 也最具备代表性。所以 Arctic 在做性能比照测试的时候，也是拿 Hudi 来比照，而不是 Iceberg。
实际上，网易数帆团队在一开始做 Arctic 这个产品时，并不打算绑定任何一个开源的数据湖计划，包含 Iceberg。
最后团队更心愿基于数据湖做一个流批一体的湖仓，通过制订一个治理 Base 数据（即存量数据）和 Change 数据（即增量数据或实时数据）的计划，做到对两种数据的解耦，不论底层应用什么数据湖技术，无论 Iceberg 还是 Delta Lake，对外裸露的都是同一套湖仓一体计划。这是 Arctic 最后的定位，即不跟任何一家数据湖基座做高度绑定，但要做到这一点须要极高的研发投入，很难一步到位。因而后期团队对于 Arctic 的定位首先是满足网易湖仓一体的业务指标，把下层实时入湖性能波及的读合并、异步合并、元数据服务、小文件治理等等在一个数据湖基座上治理起来，有了数据湖的基座，就能够基于此再去做下层的服务，而后再思考减少在不同数据湖上构建湖仓一体的能力。
这看起来仿佛又在曾经相当简单的数据系统中减少了一个服务层，不过马进示意并非如此。首先做数据中台，自身就是在 Hive 之上加了一层；其次减少的这些性能实际上是引擎端的适配，会有一个独自的治理服务，而这个治理服务是偏中台的模块，能够认为是整套数据中台体系中的一部分。这个治理服务可能把湖仓的元数据管理起来，相似 Hive 中的 HMS，同时也能够做一些数据合并的布局，还能对接不同的计算引擎，比方 Presto、Impala、Spark SQL 以及 Flink。
据马进走漏，团队预计会在明年 Q2 将 Arctic 开源进来。其实团队始终有在思考如何将自研的货色奉献回开源社区。从去年开始，网易数帆团队就尝试跟一些头部互联网公司共建 Iceberg 社区，心愿能疏导社区往湖仓一体的方向去倒退。但社区自身对倒退方向有本人的布局，包含社区创始人前不久也曾经从 Netflix 到职本人进去守业、围绕 Iceberg 成立了商业公司，想要推动社区往肯定的方向走老本很高，进度也会比较慢。
因而网易数帆团队目前更心愿先把所有的想法在 Arctic 上落实好，让整个湖仓一体计划运行起来，而后将做进去的成绩凋谢进去，再进一步跟社区沟通，看哪些货色能够奉献回社区。马进认为，最重要的是心愿 Arctic 至多可能在网易长期经营起来。
落地状况和挑战
目前网易数帆曾经有局部客户在应用 Arctic，团体外部也有不少业务接入了 Arctic。马进走漏，依据前段时间中期汇报的统计数据，网易团体外部曾经有大概 600TB 规模的数据在应用 Arctic，并且陆续有新的业务开始尝试。
依照数据起源，马进将 Arctic 的用户场景分为两大类，不同应用场景采纳的数据架构不同，引入 Arctic 时应用的革新计划也有所不同。
第一类场景的数据次要来源于日志，比方网易云音乐、网易传媒，还有电商的局部数仓零碎，他们的数据都以日志为主。对于日志数据，业务线在几年前曾经构建了十分健全的 T+1 数据处理解决方案，当初他们心愿将原有的 T+1 的离线业务革新成实时业务。然而革新成实时链路后，又放心数据的准确性，因为日志数据比拟容易呈现数据乱序和反复。针对这种日志型数据的场景，更多应用的是 Lambda 架构，Arctic 针对 Hive 提供了原地降级的计划，行将 Hive 的离线数仓表通过特定形式降级为 Arctic 表，降级后就能够通过实时计算引擎进行数据写入，而离线数仓还放弃了批量写入的能力。Arctic 表会主动依据场景做实时和离线的切换来面对不同的业务场景。网易团体外部主推 Lambda 架构，因为团体外部日志型数据场景更多一些。
Kappa 架构则更多面向企业用户，像金融、制造业、物流等传统行业，他们的数据不论是实时数据还是全量数据，次要起源是数据库。数据库里存储的数据很少呈现乱序反复的问题，绝对比拟精确，也有残缺的机制保证数据一致性。这种状况通常不须要用离线链路来兜底，日常用一个实时链路就能够。但有时候也会呈现数据库表变更的状况，比方减少一列或缩小一列数据、数据表构造发生变化，或者一些数据呈现了谬误，须要大规模修改，这时就须要对原始数据进行批量计算回补，同时须要离线链路去发挥作用。
综上，网易团体外部次要进行 Lambda 架构的革新，而针对企业客户，次要的实际是 Kappa 架构。网易团体外部的互联网业务和传统企业客户的业务，数据处理的场景和形式不一样，不过两者没有相对的界线，网易团体外部也有一些潜在的应用 Kappa 架构的场景，比方严选电商就有很多实时数据来自数据库的场景。
对于湖仓一体计划的施行和落地，Kappa 架构是最现实的计划，因为人造具备实时性，也没有历史累赘，建设湖仓一体的成本低；而对于 Lambda 架构来说，就可能面临已有离线链路、但离线做的不够标准，自身就须要肯定的革新，这种状况降级革新的老本会比拟高，技术实现上也须要更多磨合。以后团队推动湖仓一体计划落地更多会抉择一些基于 Kappa 架构的场景，Lambda 架构次要与团体外部大的业务共建，过程绝对比拟迟缓。
除了后面所说的历史累赘问题，企业尝试采纳湖仓一体技术还面临另一个挑战，就是组织上的问题。在马进看来，目前数据中台整个计划“离线”的基因很重，实时相对来说是一个比拟独立的分支，而且实时计算不光用在大数据场景，在线场景也常常波及。如果心愿通过实时给整个数据中台赋能，就须要侵入到数据中台的架构体系外面去。这就波及不同团队的磨合以及指标对立的问题，在推动上有肯定的艰难。这与前两年企业推广数据中台策略面临的挑战是相似的。
马进坦言，去年筹备做湖仓一体的时候，就面临比拟大的阻力，因为数据中台团队也有本人的布局，比方后面提到的逻辑数据湖，而湖仓一体是从另外一个角度去解决问题。这就须要公司的决策层在这件事件上有十分精准的判断并制订相应的战略目标。往年在网易数字 + 大会上正式发表将实时数据中台作为策略来推动，是网易数帆在推动湖仓一体过程中有劣势的一点。
流批一体的最终目标还有多远？
对于网易数帆来说，湖仓一体（即存储的流批一体）是最终实现流批一体必经的一步，最终愿景是用一个逻辑一套代码去笼罩离线和实时两个场景。如果实时和离线是两套存储、用到两张表，就不可能用一套代码解决，因而要优先解决存储的流批一体，而后再基于此做开发的流批一体。把工具和团队对立之后，中台的模块如数据模型、数据资产、数据品质等等也都能够做流批一体了，从原先只有离线的性能，到具备实时性能，这被称为工具流批一体，更确切的说法是中台模块的流批一体，最终给前端业务出现的就是实时数据中台。
流批一体是网易数帆团队始终以来的战术方向，即做到大数据平台的实时化，而不是将实时计算独立进去做。前述流批一体的三个档次都是网易大数据平台将来的重点改良方向。
针对存储的流批一体，当初曾经有实时数据湖引擎 Arctic，后续团队的工作重点次要包含性能优化和自研特色性能，比方实时数据摄取、数据合并、元数据管理服务等，整体有一个长期的钻研布局。将来 Arctic 也将适配更多计算引擎，除了曾经适配的 Flink、Spark，Impala 的适配工作也在进行中，明年 Arctic 开源的时候，也会做好 Presto 的适配。
同时，开发流批一体和工具流批一体方面的工作也在紧锣密鼓地开展。
开发的流批一体次要是负责 Flink 的小团队在跟进，目前次要在实际阶段。马进示意，计算流批一体的社区成熟度要比存储流批一体好很多，网易更多是在业务侧实际，争取明年能够推出开发流批一体的工具和平台。工具流批一体则是整个数据中台团队在推动，整体进度曾经实现了 20%~30%，不过临时还没有对外公布。
在马进看来，将来实时和离线技术必然会收敛到一起，从技术实现来看绝对乐观，目前网易数帆也曾经有绝对应的解决方案，但大规模的业务落地须要更多工夫。至多还须要两年工夫，才会有更多业务把流批一体和湖仓一体作为一个比拟规范的计划，过程的快慢与每个业务本身对存算拆散的诉求的急切水平无关。
主观来说，现阶段湖仓一体技术在开源技术里还不是很成熟。马进示意，企业须要对大方向放弃关注，但到底要不要采纳，还得看企业的倒退状况。如果企业的自研能力绝对不足，能够持续张望，期待更加成熟的解决方案呈现。在他看来，当初的解决方案大多数都还处在体验尝鲜的阶段，远没有达到广泛应用的阶段。对于有肯定技术实力的企业，能够先基于团体外部场景推广应用，这也是很多头部企业的做法，比方阿里、腾讯以及字节，网易也是先基于团体外部场景孵化一些解决方案。
不过网易数帆的工作重点是给企业做私有化解决方案，相比之下，阿里和腾讯的工作重点是私有云，更心愿能将客户的解决方案垄断在本人的生态之中，而网易数帆则更偏向于背靠开源，而后强于开源，做技术的破壁者。
过来一年，围绕湖仓一体和流批一体话题，InfoQ 采访了数位大数据平台领域专家，尽管每家公司的解读和实现门路各有不同，但对于湖仓一体和流批一体将来长期的发展趋势根本可能达成统一。
从久远来看，不论是阿里云、腾讯云还是 Databricks，将来的湖仓一体发展趋势都是趋同的，即基于便宜的存储设施，把数仓的能力建设好，短期内可能因为公司倒退策略及本身定位的差别，钻研方向存在肯定差别。
尽管如此，技术更迭的过程仍免不了波折。对于很多企业来说，之前曾经做了实时计算并构建出一套比拟独立的架构，并没有很强的能源去做架构降级和更新。这有点相似于过来数据库畛域经常提到的“本人革本人命”，数据中台也面临这样的困扰。但以倒退的眼光来看，这样的冲破十分有必要。如果进行了反动，最终实时和离线对立到一起，将来大数据平台会更加简略简练，工具的业余门槛会越来越高，但应用老本会越来越低，用户应用工具的投入走向收敛。
大数据平台以及数据业务全面的实时化，必然会对以后的生产关系以及组织架构带来肯定的调整诉求。这是一个自我改革的驱动，须要企业有肯定的气魄。
采访嘉宾介绍：
马进，网易数帆平台开发专家，网易数据迷信核心在线数据和实时计算团队负责人，负责网易团体分布式数据库，数据传输平台，实时计算平台，实时数据湖等我的项目，长期从事中间件、大数据基础设施方面的钻研和实际，目前率领团队聚焦在流批一体、湖仓一体的平台计划和技术演进上。