几个人的团队，数百万的投入，搭建起 Spark+Flink+ 各类查询组件的 " 标准 " 大数据平台。
结果呢？同样的开发工作要做三遍，一半以上的时间在做运维，改个需求要动三套系统。这正是当下企业数据架构面临的典型困境。传统 Lambda 架构就像用三套独立系统处理同一批数据——批处理保证完整性、流处理满足实时需求、查询引擎支撑分析。结果却是成本激增、系统复杂度失控、数据一致性难以保证。
云器科技 CTO 关涛认为，问题的根源在于行业一直在用 " 打补丁 " 的思维构建架构。在这次深度对话中，关涛详细阐述了云器提出的 " 通用增量计算（GIC）" 如何成为破解这一困境的关键路径——不是通过增加更多系统组件，而是用一套统一引擎实现全场景覆盖。
让我们深入了解这位在大数据领域深耕多年的技术专家，如何看待这场正在发生的架构范式革命。
深度对话：从 Lambda 到 Kappa 的必然之路
Q：Lambda 架构常通过组合多种数据库技术组件实现多种数据处理任务。云器科技创立之初就选择挑战该架构，背后的核心动机是什么？为何认为增量计算是实现一体化（Kappa 架构）的最佳路径？
关涛：这其实源于我们对技术发展脉络的深刻理解。任何技术领域，通常都会走过三个阶段：先是单点突破，大家各自在批处理、流计算或交互分析这些垂直领域里创新，专攻某个痛点；然后进入组合期，像 Lambda 架构那样，用批处理覆盖全量数据、流计算管实时，再加专用引擎搞即时查询，层层堆叠成解决方案；最后，才到一体化阶段，当核心技术成熟了，系统自然会向集成化演进。
回顾数据库 50 年的历史能看到，当领域进入后期，批处理、流计算这些模式固定下来，架构也就跟着稳定。大数据现在正处在第三阶段，大家追求的不再是某个孤立问题的解法，而是整体提升。
为什么选增量计算这条路？我们有三大理由支持：首先，技术匹配度高。传统批处理如 Spark 是全量范式，流处理如 Flink 着重状态更新，都没真正考虑一体化；其次，增量计算在范式上更有优势，这种方法通过持续处理数据变化，而不是周期性全量重算，自然模糊了流批边界，从架构上简化了技术栈；最后，工程价值大，它让系统能弹性调节——用户调调资源，就能实时平衡延迟和成本，拿到最佳性价比。
Q：开发者了解 " 增量计算 " 这个前沿的技术概念，但对它的应用价值上还挺模糊的，能举例说说它在业务里的关键价值吗？
关涛： 价值主要在三个方面，我们用真实场景来拆解一下。
首先是实时性和灵活调节。现在企业常抱怨全量计算太慢（按天算），实时又太烧钱。以即时零售为例，商品得 30 分钟送达，传统批处理根本跟不上。云器 Lakehouse 用增量计算实现近实时处理，还能动态调参数：白天高实时，快速出结果；晚上切成批模式，省资源。
其次，架构简化加成本优化。从 Lambda 的多套系统（批 + 流 + 交互）变单引擎 Kappa 架构，降本效果是 " 三个 1/3"：架构成本 1/3，因为单引擎替三套；资源成本 1/3，消除数据和计算冗余；存储成本 1/3，避免数据多副本。整体冗余没了，运维也简单多了。
第三，开发效率和口径统一。Lambda 架构下，流批要分开写逻辑，SQL 不能复用，建模各异，统计口径经常对不上。用增量计算引擎，一套代码管实时和离线；建模只开发一次；有实时需求就调运行参数改为实时链路，开发成本降到 1/3。
总之，这种增量计算的方法能转变实时与成本的矛盾，通过单引擎取代复杂组合，解决数据冗余、计算重复、开发低效三大顽疾，为数字化转型铺好高性价比的底座。
Q：能用更生动的案例来说明增量计算在实际中的效果吗？比如前后对比。
关涛：拿长安汽车的 IoT 车联网场景来说吧。随着汽车智能化，每辆车传感器实时上传数据——胎压、发动机状态等——每秒吞吐量百万级 TPS。原先的 Spark+Flink+Doris 组合，时效性差，异常得次日才能警报；全量计算还带来高存储和计算成本。
用上增量计算后，数据平台整体成本直降 75-80%。云器 Lakehouse 单引擎替了三套，资源只剩原先 20%-25%；响应到分钟级，异常 2 分钟内端到端警报（原需 12+ 小时）；还能动态调控，节假日流量爆增 300% 时自动扩容。从三套系统收敛成统一引擎，运维复杂度降 60%，已稳定跑两年。
小红书案例类似，实现了三个 1/3 降本，详情看他们的文章：小红书 × 云器科技｜增量计算 + 实时湖仓构建小红书实验数仓生产新范式。前后对比，能看到巨大的提升。
Q：增量计算价值这么明显，为什么之前没成熟产品突破？
关涛：其本质是数据架构从 Lambda 架构向 Kappa 架构演进的必然挑战。业界早期也有尝试（如 Flink 流批一体）均未完全成功，其核心原因如下：
计算范式冲突：主动计算 vs. 被动计算
· 批处理：基于静态数据的主动计算驱动；
· 流计算：基于动态数据的被动数据驱动。
优化目标矛盾：吞吐量 vs. 实时性
· 批处理：通过调度系统优化吞吐量，目标是以最小资源完成最大任务量；
· 流计算：通过事件触发优化数据新鲜度（Data Freshness），目标是最小化输入到输出的延迟。
当用户既希望有数据的 freshness，又有很好的吞吐，Lambda 架构设计就会产生数据不可能三角。
在云器科技创业初期的技术评估中，我们考量了实现路径，最终确立以增量计算作为核心架构方向。经深入评估发现，传统的批处理、流计算及交互式分析三套独立系统均难以满足新一代架构需求。为此，云器设计了增量计算框架，旨在通过落地实践推动该技术演进，最终实现标准的 Kappa 架构。
Q：云器 Lakehouse 如何实现 " 一套 SQL 统一流批处理 " 的同时保障高性能？具体在哪些层面做了关键优化？
关涛：云器的性能优化体系包含三个核心层面：
增量计算框架支撑：基于增量计算设计框架覆盖流、批及交互式场景的差异化优化需求，从源头保障语义统一性。
高性能自研引擎：采用完全自主开发的 C++ Native 引擎，深度融合硬件指令集优化（如 CPU 向量化指令），其基础性能已对齐甚至超越行业最优水平（SOTA），Bench 测试中多项指标领先。
多目标协同架构：提出创新的 Shared Everything 架构（对比 Snowflake 的 Shared Data），通过解耦数据存储、资源调度、计算引擎、写入系统及压缩模块等组件，使各子系统形成正交关系。这种架构支持根据实时性、吞吐量等不同目标自由组合模块，例如在保障流计算低延迟的同时，复用资源池实现批处理高吞吐，最终达成统一框架下多场景性能最优。
Q：从 Spark 或 Flink 迁移至增量计算架构的改造范围与标准路径是什么？
关涛：在设计云器 Lakehouse 时，我们将 " 平滑迁移 " 作为核心原则之一。我们深知，任何需要大规模改造的新技术都很难被企业接受。云器数据开发语言兼容 Spark 语法和 MySQL 协议，可切换，也支持 Python；保留传统维度建模，如天级分区；SQL 层只需改 CREATE TABLE 为 CREATE DYNAMIC TABLE，就启用增量，无需重写逻辑。
迁移路径：纯 Spark 最低代价，动态表升级成流批一体；Spark+Flink 混合，先改 Spark，合并 Flink 流量，只留秒级场景独立；纯 Flink 复杂度高，因建模和语义差异大。
Q：云器 Lakehouse 是否有实际客户落地案例？预计迁移周期需要多久？
关涛： 目前已有多家客户成功完成迁移。迁移周期因业务复杂度而异（SQL 任务量从几百到几千不等），但云器在设计上保障了端到端迁移的可行性，核心原则为不迁移数据、不修改 SQL 逻辑。标准实施周期通常为 1-2 个月，包含系统部署、双轨并行测试及正式切换环节。以小红书为例，其千亿级超高流量场景从验证到上线耗时约两个月（含 POC 技术验证期及线上观测期）；中小型业务因复杂度较低，迁移周期可进一步缩短。
Q：云器 Lakehouse 选择闭源模式的核心考量是什么？
关涛：基于领域阶段判断，按 Gartner 曲线，大数据已在成熟后期，这个阶段场景固化、头部格局也更明朗。用户要 " 多快好省 " ——功能、性能、易用、成本。开源适合萌芽期如 AI 领域，相对来说场景更模糊、迭代更快，所以需要开源写作推动演进。
关于开源的方式，云器经过对已有客户的调研显示，真正基于企业自身特殊需求而改 Spark/Flink 源码的很少，大家普遍需要的是开箱方案。此外，全球头部的数据平台产品如 Snowflake、Databricks、BigQuery、Redshift、MaxCompute 都是闭源。云器的选择本质是顺应规律：当整个领域迈入成熟阶段，给客户全栈方案比提供基础组件让客户自建平台更有价值。
Q：在 AI 应用爆发的技术浪潮下，增量计算与大模型技术存在何种关联？
关涛： 增量计算与 AI 本质形成正交互补关系：
框架通用性支撑 AI 数据处理：以 Spark 为代表的分布式计算框架已被广泛应用于大模型的数据预处理场景，其能力不仅覆盖结构化数据分析，还可高效处理半非结构化 AI 数据（如文档切块、向量化入库等）。云器增量计算框架延续此通用性，支持通过 SQL/Python 表达，无缝集成至 AI 工作流中。
规避架构分裂风险：传统大数据领域曾因流批计算分离形成复杂的 Lambda 架构。增量计算通过统一处理引擎（避免全量重算、仅计算变化数据）为 AI 数据提供一体化开发范式，防止 AI 时代重蹈 " 流批割裂 " 覆辙。
适配 AI 实时性需求：面对 AI 场景中即时响应的强需求（如实时特征更新、动态模型调优），增量计算通过分钟级延迟与动态资源调度能力，为高迭代频率的 AI 系统提供可持续基础设施支持。
Q：作为资深数据技术专家，您对计算架构未来发展有何展望？
关涛： 数据分析正在技术收敛：
架构范式统一：Lambda 架构向 Kappa 架构的演进将在未来 1-2 年加速，增量计算凭借 " 降本 + 实时化 " 双重驱动成为主流赛道，推动流批交互统一为第四代计算范式。
AI 数据工程爆发：数据基础设施将聚焦 AI Workload 优化，重点解决海量异构数据的 AI-Ready 处理链（数据接入→清洗→向量化→服务层部署），支撑大模型训练与推理需求。
多元化探索期：当前企业在数据供给、模型服务等环节存在显著技术路径分化，需持续关注其演化趋势。
总的来说，当 " 实时化 " 从奢侈品变为必需品，当 AI 应用从实验室走向生产环境，增量计算正在成为连接这两大趋势的关键桥梁。云器科技通过在计算引擎、架构设计、工程实践等多个层面的创新，推动大数据平台向 " 更低成本、更高时效、更简架构 " 的方向演进。在关涛看来，这场架构革命不仅关乎技术升级，更将重塑企业数据价值挖掘的方式——未来除月级数据订正等特殊场景外，" 实时化 " 终将成为数据处理的默认基态。正如他所断言：" 当领域迈入成熟阶段，交付‘多快好省’的全栈解决方案，远比提供基础组件由用户自建更能创造核心价值。"
