火花思维起步于2017年，作为中国专注少儿逻辑思维培养的细分头部品牌，其多元化的课程体系、实时互动的教学场景与全球化的服务网络，对平台的海量数据处理与智能化分析能力提出了极高要求。
同时，开源Spark逐渐老旧，离线计算模式和行式Java引擎不再先进，为应对开源Spark引擎性能瓶颈、计算成本高昂及运维投入产出不成正比等挑战，火花思维技术团队引入云器Lakehouse，并制定了分阶段升级策略：第一阶段通过"零迁移、换引擎"快速拿到降本增效成果；第二阶段逐步增量化改造，实现Kappa架构升级；第三阶段面向Data+AI展开应用探索。
目前第一阶段已完成，高消耗任务100%丝滑迁移至云器Lakehouse，不同任务性能有3-10倍不等的提升，因此在将时效性从T+1提升到H+1，计算成本仍然降低60%以上，同时迁移工作量趋近于零。
接下来，本文将详解本次火花思维Lakehouse升级背后的技术思路与落地实践。
现状与痛点：火花大数据平台面临的挑战
架构背景
经过多年的技术积累，我们构建了一套相对成熟的大数据处理体系：
上层：自研大数据平台Athena，承载着集群管理、任务开发、调度编排、运行监控和数据提取等核心功能。这是业务人员日常操作的统一入口，也是我们多年来沉淀的核心技术资产。
底层：最初基于公有云EMR（Elastic MapReduce）构建的Spark/Hive计算集群，后来我们将数据存储于腾讯云对象存储COS；Presto负责联邦查询加速。
从架构图可以清晰看到，平台通过调度模块对接底层的引擎，由Spark/Hive引擎执行计算任务，Presto负责查询加速，所有数据持久化在COS对象存储中。
这套架构在业务早期运行良好，但随着数据规模和任务复杂度的增长，问题开始逐渐暴露。
核心问题
问题一：大规模数据量下的计算和查询性能低
在大规模数据量下（百TB级别），开源Spark和Presto引擎的性能瓶颈日益凸显。相比Databricks等商业化引擎，社区版Spark在向量化执行、查询优化、内存管理等方面存在代际差距，处理同等规模数据所需的时间和资源消耗明显更高。
问题二：大任务计算成本高
火花思维的业务有多种场景的应用，包括离线加工（spark）、查询分析（Presto）、实时加工（Flink）等，即使已经优化了资源的弹性使用，但是大任务成本依然高昂，每个月面临几十万的成本支出。
问题三：AI能力的探索需要从头建设
AI的应用场景中，从非结构化数据的存储管理，到向量化存储及检索，到构建知识库，并基于此实现自然语言问答，或者实现AutoETL等能力，需要从头引入新的产品组件来实现；除了引入新产品组件的工作量之外，依然会导致结构化数据和非结构化数据的天然割裂，一些多模数据的融合场景很难落地。
升级选型逻辑：下一代数据引擎的评估与决策
评估背景
面对性能、成本、运维、AI应用等多重挑战，我们技术团队在2024年下半年启动了系统性的方案评估。评估范围包括其他云厂商的托管Spark服务，以及新一代Lakehouse引擎。
在正式评估之前，团队首先梳理了对下一代数据引擎及平台技术的核心需求。
需求清单：八项关键能力
经过内部讨论，明确了以下几个关键考虑的方向；其中，短期最重要的还是"在不大改现有平台的基础之上，实现引擎性能的大幅度提升"
|-------------|---------------------------------|-------------------------------------------------------------------------------------------------|
| 关键能力分类 | 关键项 | 说明 |
| 已有能力保持及优化 | 支持存算分离 | 数据依然保留在现有的腾讯云COS中，新引擎需要能够对接已有存储和元数据。 |
| 已有能力保持及优化 | Serverless弹性计费 | 业务每天不同时刻都有波动，资源需要能灵活弹缩。 |
| 已有能力保持及优化 | 与自研平台Athena集成 | 数据工厂是核心技术资产，新引擎需要提供标准化的SDK或JDBC接口，支持低侵入式对接，而非要求更换整套平台。 |
| 已有能力保持及优化 | Spark SQL高度兼容 | 现有数千个ETL任务基于Spark SQL开发，新引擎必须实现语法层面的高度兼容，将改造工作量控制在可接受范围内。 |
| 新一代湖仓平台能力建设 | 引擎性能必须有代际提升 | 不是10%、20%的边际改进，而是数倍乃至十倍的性能跨越。只有这样，才能从根本上解决大任务超时等性能问题。 |
| 新一代湖仓平台能力建设 | 具备新一代湖仓演进能力 | 当前目标是解决批处理以及查询性能问题 ，但长期来看，团队希望逐步引入增量计算范式，向准实时数据能力演进，新引擎需要具备这一技术路线图；最终建设成新一代的Kappa架构 |
| 新一代湖仓平台能力建设 | 免运维或极简运维 | 将工程师从集群管理、参数调优等事务中解放出来，专注于业务价值创造。 |
| AI能力建设 | 面向未来，支持Data+ AI 的应用 | 具备Data+AI底座的能力，包括但不限于：多模数据的存储、管理、计算，到向量化存储及检索，到构建知识库，支持MCP Server 接口，并基于这些能力实现自然语言问答，AutoETL等能力 |
方案选择：云器Lakehouse
为满足上述能力，火花思维技术团队在深入评估多种方案后（包括完全开源自建方案等），还是决定引入 云器Lakehouse 作为核心平台，来支撑新一代一体化湖仓平台及Data+AI大数据基础设施平台的建设。
为了能丝滑切入，火花思维技术团队首先选择了云器Lakehouse 外表加速能力，对已有系统入侵极小，保护已有资产的同时实现插件化的加速，快速拿到性能提升和降本的效果，为此我们也做了详细的POC验证，确实拿到效果之后才真正上生产，目前已经稳定运行近一年。
总结下来，云器Lakehouse外表加速方案有以下优势：
|-------------|------------------------------------------------------------------------------------------------------------|
| 需求维度 | 云器Lakehouse 外表加速方案 |
| 引擎性能 | 1. 自研向量化引擎，实测提升3-10倍； 2. 如果未来使用内表模式，性能还可以再提升3倍左右 |
| 存算分离 | 1. 原生存算分离架构 2. 支持外表模式直接读/写已有Hive表、Iceberg表，并具备更高的性能 4. 不需要动已有的数据，以及上下游业务 |
| 计费模式 | 1. 纯Serverless，按需弹性；而且实现秒级弹缩，弹缩性能更极致，收费可以精确到1分钟； 2. 用资源才收费，不用不收费 |
| SQL兼容性 | 1. 兼容Spark SQL 2. 兼容Presto SQL |
| 平台集成 | 1. 提供Python SDK/JDBC，集成Athena简单，1个人一周内就可以完成 |
| 湖仓能力 | 1. 天然湖仓一体架构，一个引擎同时支持离线加工，基于增量计算的实时加工，实时分析等多场景，真正的Kappa架构 2. 有很好的开放性，兼容Iceberg、Parquet、HMS等，可被外部引擎消费 |
| Data+AI基础能力 | 1. 多模数据的存储/管理（元数据和权限）/计算 2. 向量存储和向量检索、倒排索引等能力，支持构建知识库 3. 支持MCP Server，支持AI Function，和多种大模型集成，可快速构建AI Agent |
| 运维负担 | 全托管，零运维 |
实际生产任务基于云器Lakehouse外表性能测试对比结果如下：
-
不同Query基本均有3-10倍的性能表现
-
如果是云器内表，在该性能基础之上可以再快3倍左右
最终，团队选择了基于云器Lakehouse作为新一代引擎，并且分阶段推进的策略，先用云器Lakehouse外表加速能力快速切入，拿到提升性能和降本的效果，后续再逐步实现不同业务场景的建议，以及AI的应用
升级路径：选择Spark平替升级计算方案
团队制定了分阶段的实施计划：第一阶段聚焦不动数据更换引擎；并通过Top 100高消耗任务的迁移验证，跑通技术路径、量化实际收益；第二阶段再根据一期效果，逐步扩大覆盖范围。长期看可以考虑全托管取代。
这种"小步快跑、逐步验证"的方式，既能快速兑现收益，又将变更风险控制在可接受范围内。
第一阶段的核心诉求：三个"必须"
第一，不动数据。
多年积累的业务数据是企业核心资产，"数据不迁移：降低迁移风险。
第二，不换平台。
Athena数据工厂承载了大量的任务定义、调度逻辑和权限配置，更重要的是，业务人员已经形成了稳定的使用习惯。更换平台意味着重新培训、重新开发、重新验证，这不适合一开始就做大幅改变；而相对的第一步只替换引擎，不会对用户体验产生影响。
第三，降本增效。
必须在可量化的周期内，实现计算成本的大幅下降和任务性能的显著提升，否则架构改造就失去了商业意义。
第一阶段解决方案：云器"外表"模式下的计算引擎置换
经过多轮技术调研和POC验证，火花思维第一步选择了采用云器外表模式接入Serverless Lakehouse。
这套方案的核心思路是：替换Spark引擎，提升性能效果。
-
存储层：保持原有腾讯云COS不变，数据零迁移
-
调度层：Athena继续作为统一入口负责任务分发
-
计算层：将原有的Spark/Hive引擎，替换为Serverless架构的新一代计算引擎
从升级后的架构图可以看到，平台通过Python SDK/JDBC接口，将原本发往spark的任务分流到新的Lakehouse引擎。新引擎以"外表模式"直接读写COS中的数据，与原有Spark/Hive形成互补。
这种架构的好处在于：
-
对上层透明：业务人员继续使用Athena平台，操作习惯不变
-
对数据透明：数据仍然存储在COS，没有迁移成本
-
对存量兼容：原有的Spark/Hive任务可以继续运行，新引擎作为增量能力补充
-
弹性计费：Serverless按量付费，彻底消除资源闲置
实际收益：基于生产环境的数据测算
2025年6月，Top 100任务在生产环境稳定运行两周后，我们完成了正式的生产切换。以下是基于实际运行数据的收益测算。
性能提升：3-10倍
实测结果显示：
|-------------|----------|--------------------------------|
| 指标 | 优化前 | 优化后 |
| Top任务平均执行时间 | 约60分钟 | 约6分钟 |
| 数据产出时效 | T+1 | 小时级 |
| 任务稳定性 | 频繁OOM/超时 | 稳定执行： 任务完成生产上线，高效执行下稳定应对 COS限流 |
大任务平均性能提升10倍，数据产出时效从"次日可用"提升至"小时级可用"，业务决策响应速度大幅改善。
成本下降：60%以上
大任务成本优化来自两个维度：
第一，消除闲置成本。
Serverless架构的核心特征是"按需计费"：任务运行时按实际消耗的计算资源（CPU时间、扫描数据量）付费，任务结束后资源立即释放，不产生任何闲置成本。
第二，执行效率提升。
同样的任务，执行时间缩短10倍，意味着消耗的计算资源也相应减少。即使单位算力价格不变，总成本也会显著下降
综合两个因素，一期迁移的大任务计算成本降低60%。
低成本接入
-
兼容性保障 ：TOP 100 大任务兼容性跑通 100%。
-
低迁移成本 ：无需迁移数据、任务及元数据，仅通过引擎切换即可加速（如在 Athena 平台切换执行引擎至 Lakehouse）。
-
灵活集成 ：支持 JDBC、Python SDK 等多方式对接 Athena 平台，实现任务下发、结果回写与状态跟踪等。
总结与展望：从Lambda架构走向 Kappa 架构
回顾这次架构升级，目标是引入最新一代湖仓架构相关技术，为火花思维未来的业务发展打好基础；实现路径是分阶段逐步升级，目前已经完成第一阶段的建设目标，包括以下内容：
-
轻量化实现了最新一代湖仓平台的引入：完成了Athena平台对接，数据和元数据对接，初步完成Data+AI的湖仓平台建设
-
降本增效：已经迁移的业务，性能提升3-10倍，计算成本降低60%以上
-
数据产出时效性提升：从T+1 到小时级
-
运维成本降低：复杂大任务能更好的利用云资源弹性，同时有更好的稳定性
-
为后续业务的逐步迁移打下基础：包括但不限于
- 更多离线任务接入
- Presto查询任务接入
- 基于增量计算的实时任务接入
- Data+AI应用的创新
第一阶段目标落地的核心经验是"换引擎不换车"------准确识别瓶颈（底层计算引擎），精准施策（置换而非重构），最小化变更范围，最大化收益。这种"自研调度 + 托管算力"的组合模式，让我们以最小代价完成了第一步。
但这并非终点。当前我们已验证了增量计算引擎的可靠性和托管模式的可行性，下一步将考虑更彻底的架构演进：
-
全托管的湖仓平台、更大范围采用增量计算范式，并最终向 Kappa 架构迈进
-
"多场景多组件"的方式逐步收敛到"多场景一体化平台"方向演进
-
同时在Data+AI的底座下，探索AI应用的创新