Arctic:网易数帆开放式流批一体表服务 | BDTC 精彩回顾
在近日举办的 BDTC 2021 中国大数据技术大会上,网易副总裁、网易杭州研究院执行院长、网易数帆总经理汪源在主题演讲中介绍了有数数据生产力平台的底层核心技术——开放式流批一体架构,重点分享了 Arctic 流批一体表服务的设计特点和实现原理。以下为演讲内容整理。
流批割裂的问题
我们目前在开发过程中会遇到一个很头疼的问题,我们称之为流批割裂的问题,也就是说我们的数据因为当前技术体系的限制,离线数据和实时数据是要走两条链路的,离线数据我们通常通过 Hive 和 Spark 去做处理,实时链路我们主要通过 HBase、Kafka、Kudu 的技术去处理。
这两套技术割裂就会导致我们的技术体系不统一,我们的研发体系也割裂,我们需要在两个地方重复开发同样的逻辑,而且我们在应用层还是要去手工做数据的合并,这对我们的应用开发也带来了很大的成本。
有数开放式流批一体架构
怎么去解决这个问题,在业界内有很多不同的解决手段,我们追求的是一个开放式架构下的解决方案。目前我们基于行业里面开源的技术,已经形成了一个基于数据湖的开放架构,在这个架构里面整个技术栈分成了五个层面,最底层的是文件系统,第二层是文件格式,第三层是表格式,第四层是表服务,最后一层是 SQL 层,以 SQL 的方式来提供统一的入口。
在这个架构里面,每一层的技术都是开放的,开源的技术,我们在做技术方案设计的时候,会始终追求我们的技术能够很好地跟开放性的技术无缝融合,因为这样才能够满足企业客户的需求。
我们基于这个开放式的架构进行增强和升级,提出了 Arctic 这样的一种表服务,也引入了另外一个开源的产品,叫 Iceberg 来作为一个流批一体的表格式。 这样我们就形成了一个开放式的流批一体架构,它能够解决流计算和批计算存储层割裂的问题。
Arctic 主要特征
简要介绍一下 Arctic 作为一个流批一体表服务主要的特征,以及它的实现原理。它的主要的特色之一,是我们实现了实时场景的支持:我们支持基于主键的更新,相当于可以把它视作一个 KV 数据库,我们还提供了流表的实时订阅的功能,也能够支持实时的维表 join。
在引擎方面的,Arctic 实现了多引擎的支持:它支持像 Flink、Spark 等主流的计算引擎,也支持像 Presto 和 Impala 等主流的分析引擎,并且多个引擎之间可以进行并发读写,我们也能够保障整个系统的 ACID 的限制。
Arctic 作为一个表服务,其实主要做的是三方面的事情,第一个是数据的写入,实时的数据写入到了 Change 数据里面,批量的数据写入到 Base 数据。第二个是数据的读取,我们实现了 Merge-on-Read,也就是在读的时候把 Base 数据和 Change 数据进行合并。第三个我们要做数据的整理,在需要的时候我们要进行 Compaction 或者是 Split,或者是通过 Key 去做排序,这样能够维持整个系统的高性能的状态。
Arctic 核心原理
Arctic 实现的核心原理是一个多层次的 Arctic Tree 数据组织的结构。如图所示,树上的 B011 和 B111 是两个 Base 数据,我们的 Change 数据可以在这棵树上处在更高的层面,就是图中的 C11。在这个结构里面,Change 数据所对应的 Base 数据不只是一个,而是两个。当然这只是一个图示,但我们的 Change 数据有可能对应任意多个更低层面的 Base 数据。这样的数据组织原理,是我们跟其它的类似开源项目最大的区别。使用这样的组织原理有什么好处呢?我通过一些过程来向大家解释。
第一个是我们能够很好地去做 Compaction 或者是 Split。举一个例子,比如说我们如果发现 B011 这个文件比较大,超过了 100MB,我们的 Change 数据也比较大了,这个时候我们就可以把 Change 数据进行合并,同时把 B011 这个数据 Split 成 B0011 和 B1011 两个 Base 数据,这个时候 C11 还是可以停留在这棵树的上一层——我们的 Base 数据虽然发生了变化,但并一定不需要把 Change 数据和 Base 数据做 merge,这可以根据性能的需求自由地决定。
第二个,我们可以做 Merge-on-Read。这边也举了一个例子,我们把 B0011、B1011 和 C11 之间做一层一层的合并,这是我们做 Merge-on-Read 的实现的原理和方式。
Arctic 技术特点
这样的实现原理和方式,它能够带来什么样的优点呢?我们总结下来有三个方面。
第一个,我们在这个过程中不需要引入一个索引结构,这样我们就可以不依赖于一些比较复杂的索引系统,不像有的类似项目依赖于 HBase 这样的外部系统做一个索引的结构,这个设计使得我们的写入性能会更快。
第二个,我们可以实现 Base 数据和 Change 数据之间多对多的灵活映射,这对我们在系统实现上提供了一个非常好的灵活性。
第三个,我们可以通过动态的分区去控制文件的大小,我们既可以避免文件过大,也可以避免产生大量的小文件。
这样的核心原理,最终就使得我们具备了写入快,读取快,写放大降低这三个特点。
小结
最后我们小结一下,Arctic 解决了传统的技术在流和批之间割裂的问题,实现了流批一体的架构。同时我们是在一个开放式的架构体系下实现的,跟现有的 Hadoop 整个开源大数据技术体系是完全无缝融合的。第三点,Arctic 是一个高性能的表服务。
InfoQ 相关专访:网易数帆实时数据湖 Arctic 的探索和实践
版权声明: 本文为 InfoQ 作者【网易数帆】的原创文章。
原文链接:【http://xie.infoq.cn/article/ca26202497d1ed3c8f88ea3bc】。文章转载请联系作者。
评论