大数据平台降本增效实践：四大典型场景的成本优化之路

推荐语

云器 Lakehouse 以统一架构和增量计算技术，破解大数据平台成本困局，让企业资源回归业务增长本质。

核心内容：
1. 大数据平台TCO构成分析：硬件成本仅占30%，软件/人力/治理等隐性成本占比惊人
2. 四大优化场景实践：增量计算、Kappa架构、资源管理新模式与高性能引擎技术突破
3. 架构演进趋势：从"组装式"Lambda架构到统一Lakehouse的技术跃迁路径

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

01

降本增效问题的根源分析

1. 复杂度困局：TCO 远超硬件成本

即使在 AI 如此火爆的今天，"降本增效"依然是所有客户交流中最普遍的关切之一。但大家往往容易将成本等同于硬件成本或资源成本。根据我们在众多真实客户场景中的分析，得出一个结论：

一个大数据平台的整体拥有成本（TCO）通常是硬件成本的三倍以上。

总拥有成本（TCO）的真实构成：

• 硬件成本：物理资源投入

• 软件成本：基于众多开源组件的自建成本

• 开发人员成本：数据开发和管理的隐性成本

• 维护人力成本：运维支撑团队的持续投入

• 治理优化成本：数据质量、安全、血缘管理等成本

在一个真实的客户案例中，一个百台规模的平台，其物理硬件成本可能只占总成本的不到 30%。而基于众多开源组件（如 HDFS、Spark、Flink、Hive 等）进行自建和的运维支撑所投入的成本，加起来远远超过了硬件本身。

2. 根本原因：平台能力落后于业务创新速度

成本高企、效率低下的主要原因在于平台能力的发展落后于业务创新的速度。一开始成本问题不凸显，但随着业务发展、数据量增大、业务场景增多，大家不断地在原有架构上"堆积木"或"堆组件"，这些非最优解最终导致成本问题愈发突出。

（1）Lambda 架构的三大结构性问题：

• 存储层：数据湖和数据仓库尚未真正统一，造成数据冗余

• 计算层：离线计算的时效性低，而实时计算的成本又过高，两者间的矛盾非常突出

• 架构层：这种"组装式"架构非常复杂，异构存储和多套元数据导致数据和计算资源冗余度很高

（2）开源组件的优化天花板

很多团队依然使用基于开源数据平台的多组件组装模式。当他们尝试进行性能优化时，很快会碰到"天花板"。一个端到端的链路可能涉及五个组件，其整体性能受限于木桶效应，即最差的那个组件。包括数据在不同组件间的导入导出环节，都极难优化。

这导致了：

• 端到端的性能极难优化，需要优化链路上的每一个环节，并且上限明显

• 数据分散且冗余，成本高昂，同时数据一致性难保证

• 元数据分散，出问题后定位困难，运维效率低

• 开发链路复杂，一个新业务可能涉及 3-5 个组件、3 种 SQL 方言和 Java

• 组装式架构缺乏灵活性，难以快速响应业务变化

02

四大典型场景与技术突破

我们总结了 Lambda 架构暴露出的"高成本、低效率"四大典型场景，并针对每个场景提供了基于统一架构和通用增量计算的创新解法。

• 场景一：实时加工成本高（成本相关）

• 场景二：资源割裂，数据冗余（成本相关）

• 场景三：多场景、多组件带来的开发效率低下（效率相关）

• 场景四：引擎性能低，算不出来（效率相关）

1. 场景一：实时加工成本高——用通用增量计算重写成本结构

（1）问题根源：Flink 架构的四大成本困境

以主流的 Flink 实时数仓架构为例，其高成本主要源于：

• 资源常驻，缺乏弹性：任务 7x24 小时运行，即使在业务低谷，资源也无法释放；

• 按峰配置，利用率低：必须按最高峰值配置资源，导致大部分平峰时段资源利用率极低；

• 状态复杂，内存消耗大：维护窗口聚合、维表关联等状态需要消耗大量内存；

• 运维复杂，成本转移：庞大的状态数据使得任务重启、扩缩容和数据恢复变得异常复杂。

（2）传统解法的妥协困局

为了控制成本，业界的短期解法通常是"妥协"：

• 牺牲指标：100 个指标中只选取 10 个最关键的指标做实时计算

• 牺牲精度：业务逻辑本需要 2 小时的窗口，为了防止内存爆炸，强行缩减到 30 分钟

• 引入外部 K/V：引入 Redis 等系统来管理复杂的状态或维表

这些妥协牺牲了业务精度，但状态管理和资源浪费问题并未根本解决。

（3）云器方案：通用增量计算（GIC）重写成本公式

云器科技的答案是通用增量计算（Generic Incremental Compute, GIC）。GIC 的核心思想是：

用一套标准的、类似离线的 SQL 代码，通过动态调控计算周期（例如从天级调整到分钟级），灵活地在成本和新鲜度之间找到最佳平衡，同时解放开发效率。

通用增量计算（GIC）的本质，是将近实时的流式计算，转变为"主动计算"模式，使其在开发和管理上无限趋近于离线批处理，但又能达到分钟级的实时性。

通用增量计算（GIC）关键技术：

• 增量数据的获取 (增删改)： 基于 MVCC（多版本并发控制），快速获得两个版本间的 Delta 数据（增、删、改）。

• 完整的增量语法语义支持： 这是“通用”二字的核心。必须支持所有 SQL 算子（如 Filter, Aggregate, 各种 Join, 窗口函数, UDF）的增量计算，如果覆盖度不全，将很难在真实生产中大规模落地。

• 增量数据写入： 高效地将计算出的增量结果写入目标表。

通用增量计算（GIC）GIC的黄金标准：SPOT

• S (Standard SQL)：支持标准、统一、完整的 SQL 语法、语义及 UDF

• P (Performance)：显著提升性能、降低成本。在同等新鲜度下（如 5 分钟），成本应成倍低于流计算

• O (Open Format)：数据采用开放格式（如 Iceberg+Parquet），可被其他引擎直读

• T (Trade-off)：可通过参数动态调整调度周期，无缝在 T+0 和 T+1 间权衡

（4）客户案例：某生活方式平台

业务特征：超大规模流量日志实时接入、多源维表更新、多表关联计算、数据新鲜度要求 5 分钟以内，且加工结果数据直接支持在线分析。

解决方案：

通过使用通用增量计算（GIC），用 CREATE DYNAMIC TABLE ... AS SELECT ... 语句来定义动态表。AS SELECT 之后的部分，完全就是用户 T+1 的离线 SQL 代码，可能只需改几个参数。

创建后，用户只需通过调度系统（例如每5分钟）执行一次 REFRESH DYNAMIC TABLE ...，系统便会自动获取这 5 分钟的增量数据，执行增量计算。

实施效果：

• 业务提升：指标从原先受限于成本只能做的十几个，扩展到了上百个

• 架构简化：替代了原有的 Flink + Spark + Doris 等多组件方案

• 成本降低：实现了 1/3 的总成本（TCO）

  资源成本 1/3：降低了 70% 的整体资源消耗

  开发成本 1/3：统一增量链路，无需维护两套代码

  架构成本 1/3：Kappa 架构一体化引擎替换了 3 个引擎的组合

2. 场景二：资源割裂、数据冗余——用统一架构消除结构性浪费

（1）问题根源："1+N"平台体系

这是一个非常典型的架构："1 个离线数仓 + N 个 OLAP 孤岛"。不同业务线为了避免互相干扰，各自部署一套 OLAP 实例（如 ClickHouse、Doris 等）。

这导致：

• 资源孤岛：实例间资源无法共享，利用率低下（整体利用率不足 30%）

• 成本高昂：每个实例都需按峰值配置，弹性不足

• 数据冗余：同一份数据被导入到 N 个实例中

• 稳定性差：单个实例内的一个大查询能打满该集群资源，影响其他关键查询

（2）传统解决方案：

常见的做法是在引擎层设置超时，如 60 秒。更高级的会在 BI 平台支持自动回退机制，即 OLAP 查询失败后自动回退到 Spark 上执行。但这依然会在 60 秒内影响业务，且资源割裂问题依旧存在。

核心追问：

• 能否实现底层一套资源池，上层按业务划分集群（负载隔离），同时做到资源灵活复用？

• 能否在任务运行前就自动判断其为“大任务”，并将其自动路由到其他集群执行？

（3）云器方案：Virtual Cluster + 智能路由

①Virtual Cluster（VC）资源管理模式

基于存算分离和计算资源容器化，可以在一套物理资源池之上，按需创建虚拟集群。

• 弹性伸缩：VC 支持垂直/水平的毫秒级拉起与销毁，实现基于负载的自动弹缩

• 负载隔离：不同 VC 间实现计算资源隔离

• 资源复用：底层资源池是共享的，可以灵活调度，实现"忙时多用，闲时少用"，大幅提升整体资源利用率（如从 30% 提升到 60%）

②基于作业大小的智能路由机制

将 VC 上的大作业自动转移到另一个 VC 上（例如一个降级的 VC）。

• 按执行时长路由： 设置阈值（如 60 秒），执行超过该时间自动路由。但这 60 秒内依然会影响集群。

• 按预估时长路由：这才是更优解。在任务尚未开始执行、生成执行计划的编译优化阶段，就预估其执行时长。如果超过阈值，则直接路由到其他 VC 执行，完全不影响当前集群的稳定性。

关键技术：

• 平台需支持多集群弹性资源管理 (VC)。

• 在编译优化阶段实现作业预估。

• 作业调度能按用户定义的规则（通过 SQL 透出）进行路由。

3. 场景三：多场景、多组件——用统一引擎提升开发效率

（1）问题根源：Lambda 架构的"搭积木"模式

Lambda 架构下，一个新场景引入一个新组件。离线链路用 Hadoop/Spark，实时链路用 Flink，即席查询用 Presto，OLAP 用 Doris...

这导致了多开发语言、各种数据导出任务、血缘割裂、数据一致性难保证、治理困难等一系列问题。

核心追问：能否做到单引擎支持多场景？并且是基于一套存储、一套元数据、一种开发语言来支持？

（2）云器方案：从 Lambda 到 Kappa 架构的演进

基于通用增量计算（GIC）理论，构建全链路的实时化能力，形成统一、开放的实时湖仓（Real-time Lakehouse）架构。对比之前的 Lambda 架构，Kappa 架构实现了：

• 存储统一：Lakehouse 作为统一的数据底座

• 计算统一：Single Engine 支持结构化处理、分析、AI 等全场景

• 元数据统一：一套元数据管理所有数据

（3）客户实践效果

在多个实际客户案例中，我们实现了：

• 平台简化：将原有的 5 个产品组件（Flink/Presto/Spark/Hive/Doris）简化为 1 个组件

• 效率提升：开发链路从离线+实时的 10 步简化到 3 步；开发语言从 Java + 3 种 SQL 方言简化为 1 种标准 SQL

• 成本降低：减少 3 倍数据冗余，运维成本降低 80% 以上

4. 场景四：引擎性能低——用高性能引擎消除计算瓶颈

（1）典型场景：JSON 数据查询

单表有数百 TB 的 JSON 数据，JSON 中的 Key 有上千个且经常变动。业务人员需要对原始明细数据进行即席分析和抽样。

传统解决方案：

• Spark 直接查原始数据，性能太低，不满足业务需求。

• 平台人员被迫将数据提取到 ClickHouse 中。但所有 Key 都展开成大宽表，成本过高。

• 最终只能按业务线拆分数据，放到不同的 CK 实例中，并且只针对特定列展开。

• 当业务人员需要一个新的 Key 时，平台人员必须重新提取一次数据，效率极低。

核心追问：

能否做到不拆分、不预处理数据，直接在原始的半结构化明 S 细数据上实现毫秒/秒级的高性能查询？

（2）云器方案：JSON 查询加速技术

通过 JSON 类型 + 生成列（Generated Column）+ 建索引的组合：

• 使用 JSON 原生数据类型优化存储和查询

• 使用生成列将常用的 Key 虚拟化为列（不占存储），并通过 DDL/Alter 灵活增删

• 对"生成列"建立索引（如倒排索引）

通过这套技术，实现了在数百 TB 的原始 JSON 明细数据上进行毫秒到秒级的查询。

（3）性能优化是永无止境的旅程

云器科技的引擎在标准 TPC-H 测试上能做到比开源 Spark快 10倍。这不是单一技术实现的，而是多个优化项的乘积效应：

2（高级查询优化器）× 3（C++向量化引擎）× 1.3（直连调度优化）× 1.3（自适应缓存）≈ 10.14

这背后是基于 JVM 的 Spark 引擎与 C++ 原生向量化引擎在设计上的根本差异。

（4）客户案例

• 舆情风控企业：实现了数百 TB 级原始明细 JSON 数据的毫秒~秒级即席查询，解放了平台人员

• B2B SaaS 企业： 

  在离线全量场景，资源消耗降低 10 倍以上

  将其改造为全域增量计算，实现了全业务的实时化（5 分钟一次），而总成本基本与原来 T+1 的离线成本持平

03

大数据平台架构演进总结

我们回顾一下“高成本、低效率”的四大场景和新解法：

下一代数据平台的演进之路

最后，总结一下大数据平台架构的演进之路：

• 1.0 架构 (Pure Offline)： 纯离线批处理 (T+1)。

• 2.0 架构 (Lambda)： 离线 + 实时，两套链路。

• 3.0 架构 (Kappa)： 端到端的实时流处理，基于增量计算的实时湖仓。

总结：

• 数据平台新架构的业务需求特征是：全量的数据、实时的数据、更优的成本结构。

• 成本与效率的提升，是一个系统工程。它不只是资源成本，还包括管理、人力、运维等综合成本，而平台的优化是核心。

• 根据前述案例分析，我们认为：基于通用增量计算（GIC）技术的新一代 Kappa 架构，是实现低成本、全域实时湖仓的演进方向。

以上就是本次分享的内容，谢谢大家。

点个在看你最好看

SPRING HAS ARRIVED