Single Engine + All Data :云器科技推出基于“增量计算”的一体化湖仓平台
导读
本文整理自 云器科技CTO关涛 在2023年7月「Single Engine · All Data」发布会上分享的内容,概述了数据平台技术的整体发展趋势,阐述下一代数据平台的设计目标,并深度解读云器科技基于“增量计算”的一体化数据平台——云器Lakehouse的技术理念。
数据平台领域发展20年,逐渐成为每个企业的基础设施。作为一个进入“普惠期”的领域,当下的架构已经完美了吗,主要问题和挑战是什么?在2023年AI跃变式爆发的大背景下,数据平台又该如何演进,以适应未来的数据使用场景?
本文将从上述问题的出发,盘点和整理技术演进的趋势,并提出一体化架构将是下一代技术趋势的方向。新架构通过创新的“增量计算”范式来统一数据分析中流、批、交互不同的计算形式,通过“湖仓一体”统一存储形态,真正实现一体化Kappa架构。同时,新架构以湖仓存储为基础,具备开放性和扩展性,能够对接支撑AI,具备进一步迭代和扩展能力。
大数据发展20年发展历史概述
大数据是从 2003 年开始发展的,其标志性的开端是《MapReduce: Simplified Data Processing on Large Clusters》、《The Google File System》、《Bigtable: A Distributed Storage System for Structured Data》三篇论文的发表,作为大数据发展的起点,发展至今恰好20年。这20年我们可以将其概括为3 个阶段:孕育期、发展期和普惠期。
第一阶段-孕育期:2003 年~ 2010 年,谷歌为支持搜索业务奠基大数据领域,以论文的形式公开架构和技术细节;Yahoo开源其搜索后端的数据处理技术,并命名为Hadoop。
第二阶段-发展期:2010年~2020 年,两个关键事项有力地推动了大数据的发展:1)以 Hadoop 为核心的开源技术,即开源分布式大数据平台的繁荣发展;2)是云计算技术,极大程度上降低了大数据平台的建设门槛。当下主流的大数据平台大都在 2012 年前后开始发展,比如 AWS Redshift 是云上数仓的典型代表;包括Snowflake的成立,阿里云与飞天大数据平台起步等;
第三阶段-普惠期:从2020年至未来的10年,我们认为是大数据的普惠期。为什么这样讲,普惠期有两个特点,其一是业务进入收获期:我们能看到千帆竞发后,大部分企业被淘汰,少数企业通过竞争最终占领市场,并逐步形成规模,例如Snowflake 2020年上市;其二从技术角度来看,部分成熟场景下技术开始迭代式发展,如“批计算”、“流计算”和部分“交互分析”技术成熟后不断被后来者挑战;同时,场景继续外延不断引入的技术,如 AI 相关的技术由此外延衍生出来,呈现出对其他领域的辐射作用。目前我们能看到这几个特征同时具备。
当下数据平台的典型架构和主要痛点
当前典型的数据平台架构是计算部分采用Lamdba架构,存储层由数据湖或者数据仓库构建。AI等基础设施尚在发展成熟中。
以下通过三个不同场景数据架构的实例,总结当前数据平台的典型架构:
图1 目前典型的大数据系统的流程
自下而上是数据的整个流动过程,从数据采集开始,到多种不同的存储体系,再向上形成了“离线计算”和“实时计算”的两种计算模式,最上层是数据的消费部分,且带有交互分析的场景。
图 2 医疗大数据的数据架构
与前面例子的差异点在于,医疗系统中会存有大量图像与视频数据,因此整个架构的底部会有一层面向非结构化数据存储的存储体系,以及右侧还有面向医疗领域机器学习的智能图片识别能力,这便是在前一个例子数据分析系统的基础上迭代了一些 AI 的能力。
图 3 第三种典型的大数据系统架构
与前者融合的架构不同,Data 和 AI 拆分为二,左侧是大数据处理部分,右侧为AI的部分。AI部分比较完善,从最基础的Model-training,到 Serving,也具有特征工程等等一系列能力。
我们将当前数据平台简化为如下典型架构图,其中“不变”的部分用黑底来表示,“变”的部分用灰底来表示,如图下可见。
图4: 当前数据平台典型架构图(简化版)
数据源
不变的部分(标准场景): 关系型数据库:通过 CDC 等方式采集结构化数据。 操作类日志:通过 APP 或是 Webservice 采集的海量日志。 变化发展中的两类(新场景): IoT、智能设备数据:在物联网普及之前,大多数据都是用人的行为数据。随IoT类技术发展,设备的数据会逐步成为另外一个主要的数据来源。 半结构化和非结构化数据:随着 AI 能力的增强,这部分数据开始被加速地采集上来。
数据处理
不变的部分(标准场景): 数据分析引擎分为“批处理”、“流计算”、“实时分析”,也都有各自比较固定的数据处理和分析的场景,通过组合的方式满足不同业务需求,这个架构通常称之为Lambda架构。 数据存储架构分为“数据仓库”与“数据湖”,二者都不算新概念,使用场景也比较固定,大多数企业选择其一。例如hadoop体系就是一种典型的数据湖架构。 变化发展中的部分(新场景): AI相关的场景和架构还在发展中,场景差异大,尚未标准化。而最近火热发展的LLM又带来额外的变化:部分企业会选择,由一个特征工程开始到 Training 到 Serving 的端到端的 Pipeline;另一部分企业不再做特别多的 AI 训练,而是在 Huggingface 上下载一些已有模型 ,只做基础的 AI 处理。
“典型的/不变的”结构化
数据架构(Lambda)仍然过于复杂
综合上述,总结市面上大部分数据平台通常会选用组装式的Lambda架构,而其需要多个API接口与多种数据组件,数据冗余度高,开发维护复杂度高。面向未来,我们认为结构化数据处理分析的趋势会是,由一个一体化的引擎,统一“流”、“批”和“交互分析”,进而提供统一接口、统一处理逻辑,提供多种优化指标的高覆盖度和灵活调整的能力。
图5: 数据分析架构图,一种典型的Lamdba架构
Lambda组装式架构普遍存在的三点问题:
引擎数据语义均不统一,带来极高的开发和维护人力成本。三种引擎各自独立,查询语言、数据语义均不统一,数据在三种引擎间流转,开发和维护成本高。有统计数据表明用于运维这些系统的人力成本与资源成本相当。 异构存储,多套元数据,带来大量的计算和存储冗余和管理成本。三种引擎各自独立但又相互关联,为了做到局部语义统一,带来大量的显性、隐形的计算冗余。同时三种引擎通常配置各自独立的存储,带来大量的数据冗余和数据同步的成本。湖和仓采用外表关联,缺乏统一管理。统计这些计算和存储冗余带来数倍的成本负担。 缺乏满足业务变化的灵活性。三种引擎开发运维独立,且系统设计的优化方向不同。当用户业务需要调整三个引擎间的配置(重新调整数据新鲜度、性能和成本的平衡点),就需要复杂的修改和重复开发。通常统计当前数据架构一旦固定下来调整的周期在 3 个月以上,难以适应灵活多变的业务发展。
发展中的/变化的” AI 新计算范式,传统
数仓架构不能满足,需要新架构的支持
AI给数据平台带来新的挑战:AI需要更丰富的数据,数据需要更多样的BI+AI应用。Data与AI的关系不再是Data+AI,而是Data*AI ——数据平台不再是一对一的计算和存储架构,而是 m 对 n 关系的架构,这样的架构改变变化下,我们应该思考的问题是,由单点优化思路建设起来的lambda架构,能否迎接AI的挑战,如果不能,改变的方向是什么?
图6: 从1对1的数仓架构,到M对N的多元异构开放架构
关系型数据库自 1970 年诞生,到 2010 年的 40 年时间里,都是采用传统的数仓架构(如上图左侧)面对结构化的数据处理和分析,所以存储系统的优化都是基于结构化数据的存储来进行的,最终迭代出来的标准化SQL引擎,也是为了做结构化数据的分析。
而最近十年,特别是随着深度学习技术的发展,ML/AI 拓宽了数据平台需处理的数据类型,底层引擎模式随之改变:
改变一,引擎以往只能处理结构化数据二维表,现在可以通过 AI 处理包括 test 、json 在内的半结构化数据,以及处理非结构化数据(音视图数据);
改变二,引擎模式的顶层计算架构也在改变,类似生成式AI对文本和数据的直接理解和解读,类似code interpreter通过理解数据语意做大模型的插件式、多语言融合式查询分析,是除SQL的二维关系表达和分析引擎外,将AI的计算能力纳入到引擎。
未来已来,面对AI带来的改变,我们认为数据平台的架构更应有兼具一体化与开放性的设计。开放式湖仓一体架构,是面向Data+AI融合场景的新趋势。
一种面向未来的新数据平台架构概述
如上所述,我们认为能够面向未来的下一代数据平台,是一体化的、开放、支持Data+AI的湖仓平台,架构设计上:
数据存储部分,由湖仓一体架构承接Data+AI的统一数据底盘; 数据引擎部分,打破Lambda架构限制,一个引擎完成多个场景; 面向AI部分,在湖仓一体底盘之上向上迭代,同时与下层存储及数据分析引擎,做融合计算。比如我们可以有SQL和Python的融合计算,通过这种方式实现一个面向未来的存储架构。
图7:新一代数据平台架构,基于统一分析引擎,统一湖仓一体存储
从组装式(Lambda)架构
组装式 Lambda 架构存在的问题是业界普遍有深刻体感的,也有很多技术/产品试图解决Lamdba架构的问题,但都不是很成功,为什么实现“一体化”的架构那么难?这主要有两个原因:批、流、交互计算的计算形态不同,优化方向也不同。
图8: 批、流、交互三种计算形态的差异
一、有不同的计算形态
将数据状态分静态数据与动态数据两类。所谓静态数据就是当 Query 下发的一瞬间,计算是在数据的一个版本(称为 snapshot)上进行;而动态数据是指在持续变化中的数据,由数据主动驱动计算。数据 Query 也可分成静态 Query 和动态 Query 两类。所谓静态 Query 的意思是像天报表或者小时报表一样,我们知道它在某一个时间点上会发生。动态Query是指,用户动态下发的,很难被预测。
由以上两个维度,可以划分出四个象限区间,可以看出批处理、流计算、交互式分析分属不同象限:批处理是典型的静态数据加静态 Query 的流程,通常是一个 Pipeline 过程;交互分析是静态数据加动态Query,高并发低延迟;批处理和交互分析,通常是计算向数据去,是主动计算处理被动数据的过程。流计算是动态数据加静态计算的过程,当 Plan 发起之后,就一直等待数据进入,是一个主动数据驱动被动计算的过程。
二、有不同的优化方向
上图三角为数据平台不可能三角,即一个平台不可能同时实现数据新鲜度、低成本和高性能三个目标。如流计算优化的是数据的新鲜度,引擎等数据,为了使得下一条数据进来时计算的足够快,引擎是一直拉起的状态,Reserve了大量资源。实时数仓系统是面向性能的,也需要等待数据,需要一个非常快的数据。批处理计算面向的是 Throughput ,即 Latency 延迟,能够提供很高的 Throughput,带来很低的 Cost。不同的优化方向使得三个引擎也不同。
Lambda架构流行的核心原因是,流、批和交互计算,刚好覆盖了此三角,三个不同的引擎,每一个引擎的优化方向刚好是在一个角上。通过组合的方式满足不同业务的需求。下图更细节地比较批处理、流计算、交互式的异同。
表1: 批、流、交互三种计算形态的差异
上图从6个不同角度对比,在此仅选两个例子具体展开:
对比流计算和批计算的存储系统:
批处理的存储是通用存储,采用数仓分层建模的方式,数据的中间表格可以被共享,可以被其他查询优化。
而流计算是单独的内置存储,不可被共享,仅面向该计算模式优化;其中流计算两个作业之间的存储也不同,通常用Kafka做,是纯粹增量化的存储,且仅支持某一段时间的查询,不能做全量数据Query。
所以存储模式的不同和计算模式的不同,使得流和批都很难统一彼此。
对比批处理和交互计算的调度模型和资源模型:
批处理通常选择Bulk Synchronous Parallel(BSP)调度模型,是一种逐层调度模式。批处理通常作业下发后,动态向Yarn/Kubernetes申请资源,具有极佳的资源使用效率,能够降低成本。缺点是会造成资源排队。
而交互分析为了更好的性能,通常采用Massive Parallel Processing(MPP)调度模型,资源需要保持预置,数据被静态划分好,面向低延迟和高性能优化,但有很高的成本。
调度/资源模型的不同使得批处理和实时分析引擎也很难统一。
综上可以看出由于流、批、交互三种计算引擎的计算模型、数据驱动方式、存储系统设计、调度系统设计、资源模型等均不相同,都很难覆盖另外两个的场景,他们三者本身难以完成统一计算模式。
“增量计算”
鉴于流、批、交互三种计算模式都不能完成模式的统一,我们提出第四种计算模式:增量计算。
增量计算定义:指的是将所有计算抽象成增量的形态,实现数据的一次计算、累次使用,节省计算资源,同时能提供灵活调整的“增量时间间隔”,达成批处理或者流处理效果。因增量方式显著降低资源使用,也能大幅提升交互分析的性能并降低延迟。
图9:通过增量计算的方式,实现批、流、交互三种计算模式的统一
增量计算的原理:
如左图所示,x轴时间轴代表T0、T1和T2,当Query下发时,T0动态生成Plan,基于当前最优数据和计算情况,在T0数据里得到结果集ResultSet T0;当在T1时间下发同一个Query时,该Query的计算不再从0开始,而是在T0结果集的基础上,结合T0到T1这一阶段的数据,融合起来做增量计算,得到ResultSet T1,同时在为T2计算做状态准备。
针对批处理,可以将其作为当T0为0,从T0到T1的增量计算模式的特例,是一种从头开始的增量计算。在最佳实践里,用户通常不再保持按天的批处理,而是降低调度间隔来达成更好的近实时性。
针对流计算,流计算是天然的增量计算模型,可以通过缩短T0与T1中间间隔的时间来达成。
针对交互分析,与批处理类似,交互分析也可以抽象为增量化形态,并且更简单,因为没有后续,所以不需要再为下一阶段计算做准备。同时,因为部分交互分析的数据是持续写入的,部分之前的计算结果也可以被后来的作业利用,大幅降低计算量。
调度增量计算的时间间隔,是由用户根据需要调整设定的。当把调度时间间隔调整的很短,例如调整为分钟或者秒级,整个计算模式就愈接近流计算,而如果把间隔调整天,计算模式就等同于批处理。也就是说,计算模式的改变,只需要调整调度就能实现!
总结,增量计算模式有几点优势:
第一,统一计算模式,进而能够统一引擎,从根本上解决Lambda的痛点。
第二,每次Query在下发的时候,可以根据T0、T1中间的时间间隔做动态Plan,找到其中最优Plan的调节流程。能够实现数据平台不可能三角的平衡点,基于数据新鲜度、性能、成本的动态平衡,灵活地在三者之间找到多种多样的平衡。
第三,结果集ResultSet均公开可用,能够支持所有其他引擎或者平台使用,更符合数仓建模设计逻辑,也更具开放性。
基于“增量计算”
增量计算可以解决计算模式的统一,即流、批、交互为一体;但对于数据平台整体架构而言,还需要统一存储和面向AI的能力,因此云器科技以增量计算为基础,提出Single-Engine的数据平台设计理念。
图10:基于增量计算实现一体化Lakehouse数据平台
基于增量计算数据计算新范式,云器科技实现了Single-Engine一体化平台,包含如下三部分:
用增量计算模式统一流、批和交互三种计算形态。 用通用增量存储的统一存储形态。在湖仓存储架构的基础上增加了通用增量存储,使得在湖仓之上能够做增量的表达,该存储需要做到以下三点: 实现大通用的存储,是可以适应面向写入Throughput和查询高性能的两个维度进行优化。 数据存储支撑两种更新模型(Copy-on-write 与 Merge-on-read 两种模式),通过 Compaction 达到效率和成本的平衡。 实现数据的开放性,最终把数据的表达变成标准化的开源Iceberg存储格式,使得其它的引擎或者平台可以很方便地对接起来。 Share Everything架构。在ShareData架构基础上增加了新维度,把数据、计算和资源三方拆开,使得批处理和交互分析在资源上可以做灵活调度。
至此,通过统一的计算模式、统一的增量存储,并将数据、计算和资源Share Everything化,最终构成了云器Lakehouse的Single-Engine一体化架构。
云器Lakehouse具备以下关键能力:
统一的接口,统一的语法/语义,统一且开放的数据表达(使得可以被其他引擎/工具消费)。数据与计算隔离,一套存储支撑多种运算模式。 提供面向数据新鲜度、查询性能和资源成本三方面的多种平衡点(而不是面向三个顶点的极致优化)。具备多点优化能力,同时能支持三者之间的灵活调整。 支持在平衡点之间做简单灵活的调节。调整应该是简单的,不需要修改大量代码,不需要重新构建Pipeline。 多种指标达到/超过当前主流产品的水平。通过Single-Engine在流、批、交互这三个场景上都有不逊于现在主流系统和架构的性能,甚至超越它们。
性能指标与能力衡量
云器Lakehouse作为一体化数据平台,横跨实时、离线、交互分析等多个场景,为了客观地衡量数据集在不同场景下的表现,我们用业界标准的测试集在对应场景上,进行性能评估。特别的,云器Lakehouse由于采用了存算分离share-everything的系统架构,会通过限制virtual cluster(虚拟计算集群 abbr. VC)计算资源的规格来保证测试数据与其他产品的规格一致。尽管这样的限制不利于发挥计算资源弹性伸缩的优势,云器Lakehouse仍然在多个场景下同时表现出优异的性能,如图11所示:
图11:云器Lakehouse离线和实时分析场景性能指标
图11-左1:大数据分析场景,TPC-DS 10TB是TPC发布的针对大数据系统的标准测试数据集,适合用于评估大数据处理及ETL处理过程,测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用。以相同规格配置的处理时间评估,云器Lakehouse处理速度比Snowflake快30%,是Spark处理的9倍; 图11-左2: 即时分析场景,TPC-H 100GB是由面向业务的临时查询和并发数据修改组成,适合用于对Ad-hoc临时查询评估。云器Lakehouse不仅在处理速度上达到了Spark 的7倍,且比Snowflake还要快4倍。
图11-右1: 在实时分析场景,SSB-FLAT 100GB是以星型数据结构为主的数据测试集,适用于评估实时查询性能,我们对比了Spark和Clickhouse,Snowflake。由于Spark是对批处理做优化的,实时分析会比较慢。而Clickhouse是专向实时分析优化的,它会更有优势。测试结果显示,云器Lakehouse比Clickhouse的快20%,是Snowflake的3倍。
在流计算领域,我们选取了4个典型场景做性能对比:
Process场景:是单表下,单行的数据处理json展开的场景;
单流join场景:是双表下,左表是一个固定的维表,Join右表是流动的实时表数据,这是一个标准的维表扩展场景;
单表聚合场景:是单表做aggregation,流动数据的聚合分析场景;
双流join场景:是双表流动数据的join场景。
图12:流计算细分场景的资源消耗对比
在每个场景以Apache Flink做参照对比分析,由于Flink是一个“主动数据被动计算”的过程,会有占用资源和实际使用资源的区别。如图12所示,每张图的前两个数据柱状图指标是flink,第一个柱子代表flink的资源占用,第二个代表flink的实际资源使用。而云器使用增量计算的模式,没有资源占用和使用差异。6个深蓝色柱子代表云器Lakehouse在不同的时间间隔的资源使用情况。
在Process场景和单流join场景(图12-左1左2)属于“无状态计算”,云器基于自研的向量化引擎实现,比Flink以行式处理引擎的方式快至少10倍以上,此外可以看到无论调度间隔是10秒或间隔8小时,云器流计算资源消耗差异不大。
单表聚合场景和双流join场景,由于要考虑历史数据/状态,属于“带历史状态计算”,调度间隔时间的调整会很大程度上影响计算资源的消耗,从图12右1右2两张图可见,云器Lakehouse在10秒调度间隔下做到和Flink持平,在30秒或调至1小时的准实时调度间隔,性能的节省可以达到百倍甚至千倍。
上述测试表明,云器Lakehouse在流处理场景上,比Flink有10x-1000x的资源消耗节省。并且,基于增量计算在“流”和“批”两个极端场景中间,让数据新鲜度和处理成本可以被精益平衡;让用户既可以获得“流”的实时性,又可以得到“批”的低成本。
总结
针对当前主流数据架构的痛点和挑战,云器科技提出通过增量计算的方式,统一流、批、交互三种计算模式,实现了Single-Engine的架构,覆盖数据不可能三角,给用户提供灵活的多种性能成本平衡点,并超越当前主流引擎的性能。此外,云器Lakehouse在湖仓架构上做到开放并实现All data技术理念,一体化的湖仓平台能够同时支持BI和AI的Workload。基于一体化架构,云器提出AI4D的新方向,通过AI的方式更好地优化平台效率。(注:AI4D领域另有专题技术白皮书论述)
图13: 总结,云器科技基于增量计算打造一体化平台的最佳实践
关于云器
云器Lakehouse是一款以“Single- Engine”为技术理念的一体化数据平台产品,旨在湖仓架构之上,统一批、流、交互三种计算模式。把数据新鲜度、查询性能、成本之间的平衡控制权交给客户。云器Lakehouse是基于多云、一体化架构设计,做到灵活、开放,资源随需取用。
点击文末“阅读原文”,前往云器官网申请试用,了解更多产品细节!
官网:yunqi.techB 站:云器科技知乎:云器科技
往期推荐