几个人的团队，数百万的投入，搭建起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应用从实验室走向生产环境，增量计算正在成为连接这两大趋势的关键桥梁。云器科技通过在计算引擎、架构设计、工程实践等多个层面的创新，推动大数据平台向"更低成本、更高时效、更简架构"的方向演进。在关涛看来，这场架构革命不仅关乎技术升级，更将重塑企业数据价值挖掘的方式——未来除月级数据订正等特殊场景外，“实时化”终将成为数据处理的默认基态。正如他所断言：“当领域迈入成熟阶段，交付‘多快好省’的全栈解决方案，远比提供基础组件由用户自建更能创造核心价值。”
