作者 | 关涛 云器科技CTO
数据平台领域发展 20 年，逐渐成为每个企业的基础设施。作为一个进入“普惠期”的领域，当下的架构已经完美了吗，主要问题和挑战是什么？在 2023 年 AI 跃变式爆发的大背景下，数据平台又该如何演进，以适应未来的数据使用场景？
本文将从上述问题的出发，盘点和整理技术演进的趋势，并提出一体化架构将是下一代技术趋势的方向。新架构通过创新的“通用增量计算”范式来统一数据分析中流、批、交互不同的计算形式，通过“湖仓一体”统一存储形态，真正实现一体化 Kappa 架构。同时，新架构以湖仓存储为基础，具备开放性和扩展性，能够对接支撑 AI，具备进一步迭代和扩展能力。
1 当下数据平台的典型架构和主要痛点
大数据领域发展20年，不同的典型场景均沉淀出针对性的引擎或者平台。国内市场，当前主流的数据平台架构是：计算部分采用Lamdba架构，存储层由数据湖或者数据仓库构建。AI等基础设施尚在发展成熟中。
以下通过三个不同场景数据架构的实例，总结当前数据平台的典型架构：
图1 目前典型的大数据系统的流程
自下而上是数据的整个流动过程，从数据采集开始，到多种不同的存储体系，再向上形成了“离线计算”和“实时计算”的两种计算模式，最上层是数据的消费部分，且带有交互分析的场景。
图2 医疗大数据的数据架构
与前面例子的差异点在于，医疗系统中会存有大量图像与视频数据，因此整个架构的底部会有一层面向非结构化数据存储的存储体系，以及右侧还有面向医疗领域机器学习的智能图片识别能力，这便是在前一个例子数据分析系统的基础上迭代了一些 AI 的能力。
图 3 第三种典型的大数据系统架构
与前者融合的架构不同，Data 和 AI 拆分为二，左侧是大数据处理部分，右侧为 AI 的部分。AI 部分比较完善，从最基础的 Model-training，到 Serving，也具有特征工程等等一系列能力。
More →
我们将当前数据平台简化为如下典型架构图，其中“不变”的部分用黑底来表示，“变”的部分用灰底来表示，如图下可见。
图 4: 当前数据平台典型架构图（简化版）
数据源
标准场景：
关系型数据库：通过 CDC 等方式采集结构化数据。
操作类日志：通过 APP 或是 Webservice 采集的海量日志。
新场景：
IoT、智能设备数据：在物联网普及之前，大多数据都是用人的行为数据。随 IoT 类技术发展，设备的数据会逐步成为另外一个主要的数据来源。
半结构化和非结构化数据：随着 AI 能力的增强，这部分数据开始被加速地采集上来。
数据处理
标准场景：
数据分析引擎分为“批处理”、“流计算”、“实时分析”，也都有各自比较固定的数据处理和分析的场景，通过组合的方式满足不同业务需求，这个架构通常称之为 Lambda 架构。
数据存储架构分为“数据仓库”与“数据湖”，二者都不算新概念，使用场景也比较固定，大多数企业选择其一。例如 hadoop 体系就是一种典型的数据湖架构。
新场景：
AI 相关的场景和架构还在发展中，场景差异大，尚未标准化。而最近火热发展的 LLM 又带来额外的变化：部分企业会选择，由一个特征工程开始到 Training 到 Serving 的端到端的 Pipeline；另一部分企业不再做特别多的 AI 训练，而是在 Huggingface 上下载一些已有模型 ，只做基础的 AI 处理。
2 Lambda数据架构的主要问题
综合上述，总结市面上大部分数据平台通常会选用组装式的 Lambda 架构，而其需要多个 API 接口与多种数据组件，数据冗余度高，开发维护复杂度高。面向未来，我们认为结构化数据处理分析的趋势会是，由一个一体化的引擎，统一“流”、“批”和“交互分析”，进而提供统一接口、统一处理逻辑，提供多种优化指标的高覆盖度和灵活调整的能力。
图 5: 数据分析架构图，一种典型的 Lamdba 架构
Lambda 组装式架构普遍存在的三点问题：
引擎数据语义均不统一，带来极高的开发和维护人力成本。三种引擎各自独立，查询语言、数据语义均不统一，数据在三种引擎间流转，开发和维护成本高。有统计数据表明用于运维这些系统的人力成本与资源成本相当。
异构存储，多套元数据，带来大量的计算和存储冗余和管理成本。三种引擎各自独立但又相互关联，为了做到局部语义统一，带来大量的显性、隐形的计算冗余。同时三种引擎通常配置各自独立的存储，带来大量的数据冗余和数据同步的成本。湖和仓采用外表关联，缺乏统一管理。统计这些计算和存储冗余带来数倍的成本负担。
缺乏满足业务变化的灵活性。三种引擎开发运维独立，且系统设计的优化方向不同。当用户业务需要调整三个引擎间的配置（重新调整数据新鲜度、性能和成本的平衡点），就需要复杂的修改和重复开发。通常统计当前数据架构一旦固定下来调整的周期在 3 个月以上，难以适应灵活多变的业务发展。
但要解决这些问题，统一成一体化架构，并非数据架构师们不想，而是确有几处难点，后文有详细论述。
3 从组装式（Lambda）架构到一体化引架构难点在哪里？
组装式 Lambda 架构存在的问题是业界普遍有深刻体感的，也有很多技术 / 产品试图解决 Lambda 架构的问题，但都不是很成功，为什么实现“一体化”的架构（也称Kappa架构）那么难？这主要有两个原因：批、流、交互计算的计算形态不同，优化方向也不同。
图 6: 批、流、交互三种计算形态的差异
一、有不同的计算形态
将数据状态分静态数据与动态数据两类。所谓静态数据就是当 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）调度模型，资源需要保持预置，数据被静态划分好，面向低延迟和高性能优化，但有很高的成本。
调度 / 资源模型的不同使得批处理和实时分析引擎也很难统一。
综上可以看出由于流、批、交互三种计算引擎的计算模型、数据驱动方式、存储系统设计、调度系统设计、资源模型等均不相同，都很难覆盖另外两个的场景，他们三者本身难以完成统一计算模式。
4 新“通用增量计算”模式统一批、流、交互三种计算模式
鉴于流、批、交互三种计算模式都不能完成模式的统一，我们提出第四种计算模式：增量计算。
增量计算定义：指的是将所有计算抽象成增量的形态，实现数据的一次计算、累次使用，节省计算资源，同时能提供灵活调整的“增量时间间隔”，达成批处理或者流处理效果。因增量方式显著降低资源使用，也能大幅提升交互分析的性能并降低延迟。
图 7：通过增量计算的方式，实现批、流、交互三种计算模式的统一
通用增量计算的原理：
如左图所示，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 均公开可用，能够支持所有其他引擎或者平台使用，更符合数仓建模设计逻辑，也更具开放性。
5 基于“增量计算”实现一体化 Lakehouse 数据平台
云器科技是“通用增量计算”提出者，也是最早的践行者。因此云器科技以增量计算为基础，进一步提出Single-Engine的数据平台设计理念。并将Single-Engine能力产品化形成云器Lakehouse服务。
图 8：基于增量计算实现一体化 Lakehouse 数据平台
基于增量计算数据计算新范式，云器科技实现了 Single-Engine 一体化平台，包含如下三部分：
用增量计算模式统一流、批和交互三种计算形态。
用通用增量存储的统一存储形态。在湖仓存储架构的基础上增加了通用增量存储，使得在湖仓之上能够做增量的表达，该存储需要做到以下三点：
实现大通用的存储，是可以适应面向写入 Throughput 和查询高性能的两个维度进行优化。
数据存储支撑两种更新模型（Copy-on-write 与 Merge-on-read 两种模式），通过 Compaction 达到效率和成本的平衡。
实现数据的开放性，最终把数据的表达变成标准化的开源 Iceberg 存储格式，使得其它的引擎或者平台可以很方便地对接起来。
Share Everything 架构。在 ShareData 架构基础上增加了新维度，把数据、计算和资源三方拆开，使得批处理和交互分析在资源上可以做灵活调度。
至此，通过统一的计算模式、统一的增量存储，并将数据、计算和资源 Share Everything 化，最终构成了云器 Lakehouse 的 Single-Engine 一体化架构。
云器 Lakehouse 具备以下关键能力：
统一的接口，统一的语法 / 语义，统一且开放的数据表达（使得可以被其他引擎 / 工具消费）。数据与计算隔离，一套存储支撑多种运算模式。
提供面向数据新鲜度、查询性能和资源成本三方面的多种平衡点（而不是面向三个顶点的极致优化）。具备多点优化能力，同时能支持三者之间的灵活调整。
支持在平衡点之间做简单灵活的调节。调整应该是简单的，不需要修改大量代码，不需要重新构建 Pipeline。
多种指标达到 / 超过当前主流产品的水平。通过 Single-Engine 在流、批、交互这三个场景上都有不逊于现在主流系统和架构的性能，甚至超越它们。
6 云器实践并验证了一体化引擎的性能指标超过国际顶级水平
云器 Lakehouse 作为一体化数据平台，横跨实时、离线、交互分析等多个场景，为了客观地衡量数据集在不同场景下的表现，我们用业界标准的测试集在对应场景上，进行性能评估。特别的，云器 Lakehouse 由于采用了存算分离 share-everything 的系统架构，会通过限制 virtual cluster（虚拟计算集群 abbr. VC）计算资源的规格来保证测试数据与其他产品的规格一致。尽管这样的限制不利于发挥计算资源弹性伸缩的优势，云器 Lakehouse 仍然在多个场景下同时表现出优异的性能，如图 11 所示：
图 9: 云器 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 场景。
图 10: 流计算细分场景的资源消耗对比
在每个场景以某流引擎做参照对比分析，由于其是一个“主动数据被动计算”的过程，会有占用资源和实际使用资源的区别。如图12所示，每张图的前两个数据柱状图指标是参照流引擎，第一个柱子代表其资源占用，第二个代表实际资源使用。而云器使用增量计算的模式，没有资源占用和使用差异。6个深蓝色柱子代表云器Lakehouse在不同的时间间隔的资源使用情况。
在Process场景和单流join场景（图12-左1左2）属于“无状态计算”，云器基于自研的向量化引擎实现，比行式处理引擎的方式快至少10倍以上，此外可以看到无论调度间隔是10秒或间隔8小时，云器流计算资源消耗差异不大。
单表聚合场景和双流join场景，由于要考虑历史数据/状态，属于“带历史状态计算”，调度间隔时间的调整会很大程度上影响计算资源的消耗，从图12右1右2两张图可见，云器Lakehouse在10秒调度间隔下做到持平，在30秒或调至1小时的准实时调度间隔，性能的节省可以达到百倍甚至千倍。
上述测试表明，云器Lakehouse在流处理场景上，比常规流式引擎有10x-1000x的资源消耗节省。并且，基于增量计算在“流”和“批”两个极端场景中间，让数据新鲜度和处理成本可以被精益平衡；让用户既可以获得“流”的实时性，又可以得到“批”的低成本。
7 总结
基于增量计算的新计算范式表现出卓越的性能，云器科技基于此提出统一流、批、交互三种计算模式，实现 Single-Engine 的架构，覆盖数据不可能三角，将为企业带来数据平台领域的新一轮技术红利——为用户提供灵活的多种性能成本平衡点。
此外，新架构平台与 AI 更好结合，无论是 All data 开放数据的技术理念和实现——可以更好支持 BI 和 AI 的 Workload；还是 AI4D 的新能力——通过 AI 的方式更好地优化平台效率。随着 AI 时代的到来，数据平台领域的变革者 / 挑战者时刻已悄然临近。
