本文适合谁： 正在比较 HTAP 与 Lambda 架构、希望降低实时数仓复杂度的数据平台团队和架构师。
摘要
企业在构建实时数据平台时，面临两种主流技术路线：Lambda 架构（OLTP + ETL + OLAP 分层）和 HTAP 架构（事务与分析一体化）。Lambda 架构是过去十年的主流选择，但存在数据延迟、架构复杂、运维成本高等问题。HTAP 架构以 TiDB 为代表，通过行列混存和智能路由，在一套系统中消除数据孤岛，实现秒级数据洞察。本文对比两种架构的设计理念、技术实现、成本模型和适用场景，帮助企业做出技术选型决策。
Lambda 架构：传统实时数据平台
架构图
数据源（MySQL/Oracle/PgSQL）
↓ CDC/ETL
批处理层（Hadoop/Spark） ← T+1 离线计算
↓
速度层（Kafka/Flink） ← 近实时计算
↓
服务层（ClickHouse/ES） ← 查询服务
↓
数据应用（报表/看板/API）
核心设计理念
- 批处理层：全量数据离线计算，保证数据准确性
- 速度层：实时增量数据处理，弥补批处理延迟
- 服务层：合并批处理和速度层结果对外提供查询
Lambda 架构的优劣势
| 优势 | 劣势 |
|---|---|
| 成熟方案，社区资源丰富 | 系统数量多（3-5 套），运维复杂 |
| 大数据量离线分析成熟 | 数据延迟 T+1，实时性差 |
| 各层可独立选型 | 同一逻辑需实现两版代码（批+流） |
| 容错性好（批处理可重算） | 数据一致性问题（多系统间） |
| 存储冗余（数据存 3 份以上） | |
| 人员要求高（需懂多个技术栈） |
Kappa 架构：简化版 Lambda
Kappa 架构移除批处理层，所有计算通过流处理完成：
数据源 → Kafka → Flink/Spark Streaming → 查询服务
优势：架构简化、实时性好 局限：复杂查询能力弱、历史数据回溯困难、流处理资源消耗大
HTAP 架构：事务分析一体化
架构图
TiDB（统一入口，MySQL 协议）
↓ 智能路由
TiKV（行存，OLTP） ←→ TiFlash（列存，OLAP）
↑ 自动同步（Raft Learner，延迟 < 1s）
数据应用（业务系统 + 报表/看板/API）
核心设计理念
- 一个系统：OLTP 和 OLAP 共享同一份数据源，无需 ETL
- 自动同步：TiFlash 自动从 TiKV 同步数据，无需外部工具
- 智能路由：优化器自动判断查询走行存还是列存
- 资源隔离：事务和分析使用独立资源，互不影响
HTAP 架构的优劣势
| 优势 | 劣势 |
|---|---|
| 一套系统替代 3-5 套 | PB 级离线分析能力弱于专用 OLAP |
| 数据延迟 < 1 秒 | 对运维团队有分布式系统要求 |
| 存储冗余少（行列各一份） | 超大规模数据需要合理规划集群 |
| SQL 统一（MySQL 语法） | |
| 运维简单（单一监控体系） | |
| 成本可控（存算分离） |
五个维度深度对比
1. 数据实时性
| 维度 | Lambda | HTAP |
|---|---|---|
| OLTP 数据到 OLAP | T+1（ETL 调度） | <1s（自动同步） |
| 实时报表 | 需要速度层（Flink） | 直接查 TiFlash |
| 数据新鲜度 | 昨天的数据 | 刚刚写入的数据 |
关键差异：Lambda 架构的实时性受 ETL 调度频率限制（通常每天一次），HTAP 架构数据写入即可分析。
2. 架构复杂度
| 维度 | Lambda | HTAP |
|---|---|---|
| 系统数量 | 3-5 套 | 1 套 |
| 组件数量 | 10+ | 4（TiDB/PD/TiKV/TiFlash） |
| 数据流 | 多段（CDC→消息→处理→存储→查询） | 端到端（写入→自动同步→查询） |
| 故障排查 | 跨系统链路追踪 | 单一系统日志 |
| 人员要求 | 需懂 Hadoop/Flink/Kafka/ClickHouse 等 | 需懂 TiDB（MySQL 生态） |
3. 存储与成本
| 维度 | Lambda | HTAP |
|---|---|---|
| 数据存储份数 | 3-5 份 | 1.5 份（行+列） |
| 硬件要求 | 多套不同配置集群 | 统一 x86/ARM 集群 |
| 3 年 TCO | 基准 | 降低 40-60% |
| 弹性伸缩 | 各层独立扩展 | 按需扩容 TiDB/TiKV/TiFlash |
4. 数据一致性
| 维度 | Lambda | HTAP |
|---|---|---|
| OLTP/OLAP 一致性 | 最终一致（T+1） | 强一致（可配置） |
| 数据校验 | 需要定期对账 | 自动保证（同一系统） |
| 事务支持 | OLAP 不支持事务 | 完整 ACID 事务 |
5. 开发效率
| 维度 | Lambda | HTAP |
|---|---|---|
| SQL 方言 | MySQL/Hive SQL/ClickHouse SQL 等 | 统一 MySQL SQL |
| ETL 开发 | 需要编写和维护 ETL 任务 | 无需 ETL |
| 报表开发 | 需理解 OLAP 系统特点 | 直接写 SQL，自动优化 |
| 双写问题 | 需要处理 OLTP/OLAP 双写 | 无双写，自动同步 |
选型决策矩阵
| 场景 | 推荐 Lambda | 推荐 HTAP |
|---|---|---|
| 数据量 | PB 级离线分析 | TB-百 TB 级 |
| 实时性要求 | T+1 可接受 | 秒级必需 |
| 团队规模 | 大型数据团队（10+人） | 中小团队（3-5人） |
| 运维能力 | 有大数据平台运维经验 | 有 MySQL 运维经验 |
| 数据一致性 | 最终一致可接受 | 强一致要求 |
| 成本预算 | 充裕 | 精打细算 |
| 技术栈 | 已有 Hadoop/Flink 投资 | MySQL 生态为主 |
迁移路径
从 Lambda 架构迁移到 HTAP 的典型步骤：
- 评估：识别哪些 OLAP 查询可以由 HTAP 承担
- 试点：选择一个业务场景（如实时报表）迁移到 TiDB HTAP
- 并轨：逐步将更多分析查询迁移到 TiDB，减少对 OLAP 系统的依赖
- 收编：最终用 TiDB 完全替代 OLTP + ETL + OLAP 架构
FAQ
Q：我们已经有 ClickHouse 做 OLAP，还需要 HTAP 吗？
A：取决于实时性需求。如果 T+1 数据满足业务需求，现有架构可以保留。如果需要秒级实时分析（如实时风控、实时推荐），HTAP 能显著简化架构。
Q：HTAP 能完全替代数据湖吗？
A：不能。数据湖（Hadoop/S3）适合 PB 级离线分析、机器学习训练、非结构化数据处理。HTAP 更适合 TB-百 TB 级的实时分析场景。两者互补。
Q：TiDB HTAP 的分析性能和 ClickHouse 比怎么样？
A：单表聚合查询，ClickHouse 通常更快（列存专用优化）。但 HTAP 优势在于：不需要 ETL 数据同步、支持事务和分析联合查询、架构简洁。对于大多数中等复杂度的分析场景，TiDB HTAP 性能足够。
总结
Lambda 架构在过去十年是大数据平台的主流选择，但随着 HTAP 技术的成熟，越来越多的企业开始向 HTAP 迁移。TiDB HTAP 的核心价值是用一套系统替代多套系统，消除数据孤岛，实现真正的实时数据洞察。对于数据量在 TB-百 TB 级、实时性要求高、团队规模有限的企业，HTAP 是比 Lambda 更优的技术选择。
下一步行动
- 方案咨询：申请 TiDB HTAP 方案咨询 — 评估从 Lambda 架构到 HTAP 的升级路径
- 产品体验：TiDB Cloud 免费试用 — 体验交易与分析一体化能力