摘要
数据分析架构正从传统的 T+1 批处理走向实时化,NewSQL 和 MPP 数据库成为企业级分析引擎的两个主流方向。TiDB(NewSQL 代表)通过 HTAP 架构同时支撑事务和分析,ClickHouse/Doris(MPP 代表)则专注大规模 OLAP 场景。本文从 OLTP/OLAP 能力、数据实时性、架构复杂度等维度系统对比,帮助企业选择最适合的分析架构。
本文适合谁:正在设计数据平台架构的技术负责人、需要评估 HTAP 或 MPP 方案的数据工程师,以及希望统一 OLTP 和 OLAP 技术栈的 CTO。
一、NewSQL 与 MPP 的定位差异
1.1 什么是 NewSQL
NewSQL 是一类既保留传统关系型数据库的事务能力(ACID),又具备水平扩展能力的数据库。核心特征是"一个系统同时支持 OLTP 和 OLAP"。
| 代表产品 | 定位 | 核心架构 |
|---|---|---|
| TiDB | 分布式 HTAP | TiDB + TiKV(行存)+ TiFlash(列存) |
| OceanBase | 企业级 HTAP | 单机 + 分布式,原生分区 |
| CockroachDB | 分布式 SQL | 分布式 KV + SQL 层 |
| YugaByteDB | 分布式 SQL | DocDB + QL 层 |
1.2 什么是 MPP
MPP(Massively Parallel Processing)数据库通过将查询分发到多个计算节点并行执行,实现大规模数据的快速分析。
| 代表产品 | 定位 | 核心架构 |
|---|---|---|
| ClickHouse | 实时分析 | 向量化执行 + 列存 |
| Apache Doris | 统一分析 | FE + BE,MPP + 存储计算分离 |
| StarRocks | 实时分析 | FE + BE,向量化 + CBO |
| Trino/Presto | 查询引擎 | 纯计算,无存储 |
1.3 核心定位差异
NewSQL(TiDB)定位:
"一个系统搞定 OLTP + OLAP"
→ 适合业务系统与分析统一
MPP(ClickHouse/Doris)定位:
"极致的分析性能"
→ 适合独立的分析数据仓库
| 维度 | NewSQL(TiDB) | MPP(ClickHouse/Doris) |
|---|---|---|
| 核心能力 | OLTP + OLAP 一体化 | 纯 OLAP,极致性能 |
| 数据新鲜度 | 毫秒级(实时) | 秒到分钟级(近实时) |
| 查询复杂度 | 标准 SQL,支持事务 | 标准 SQL,复杂分析优化 |
| 数据规模 | TB 到 PB 级 | TB 到 PB 级 |
| 扩展能力 | 存储计算分离扩展 | 计算节点独立扩展 |
二、OLTP + OLAP 能力对比
2.1 OLTP 事务能力
| 能力 | TiDB | ClickHouse | Doris |
|---|---|---|---|
| ACID 事务 | 完整支持(分布式) | 不支持 | 仅单表事务 |
| 行级更新 | 支持且高效 | 不支持(需整批替换) | 有限支持 |
| 高并发写入 | 85K+ QPS | 写入性能高但无事务 | 写入性能高但无事务 |
| 唯一约束 | 支持 | 不支持 | 不支持 |
| 外键 | 支持 | 不支持 | 不支持 |
-- TiDB:标准的 OLTP 事务
BEGIN;
UPDATE account SET balance = balance - 1000 WHERE id = 1;
UPDATE account SET balance = balance + 1000 WHERE id = 2;
INSERT INTO transfer_log (from_id, to_id, amount) VALUES (1, 2, 1000);
COMMIT;
-- ClickHouse:不支持事务,需应用层保证
-- UPDATE 操作是变异操作(mutation),异步执行
ALTER TABLE account UPDATE balance = balance - 1000 WHERE id = 1;
ALTER TABLE account UPDATE balance = balance + 1000 WHERE id = 2;
-- 两步操作之间没有原子性保证
2.2 OLAP 分析能力
基于 1TB TPC-H 标准测试集的对比:
| 查询类型 | TiDB | ClickHouse | Doris |
|---|---|---|---|
| 简单聚合(SUM/AVG) | 0.8s | 0.3s | 0.5s |
| 多表 JOIN(3-5 表) | 2.1s | 1.5s | 1.8s |
| 窗口函数 | 3.5s | 1.2s | 2.0s |
| 复杂子查询 | 5.0s | 2.0s | 3.5s |
| 大规模 GROUP BY | 1.5s | 0.4s | 0.6s |
| 实时 Dashboard 刷新 | < 3s | < 1s | < 2s |
-- 典型分析查询:用户行为漏斗分析
-- TiDB HTAP(TiFlash 列存加速)
SELECT
date_trunc('day', event_time) AS day,
funnel_step,
COUNT(DISTINCT user_id) AS users,
ROUND(COUNT(DISTINCT user_id) * 100.0 /
MAX(COUNT(DISTINCT user_id)) OVER (PARTITION BY date_trunc('day', event_time)), 2) AS conversion_rate
FROM user_events
WHERE event_time > NOW() - INTERVAL 7 DAY
GROUP BY date_trunc('day', event_time), funnel_step
ORDER BY day, funnel_step;
-- ClickHouse
SELECT
toStartOfDay(event_time) AS day,
funnel_step,
uniqExact(user_id) AS users,
round(uniqExact(user_id) * 100.0 /
maxIf(uniqExact(user_id), funnel_step = 'view'), 2) AS conversion_rate
FROM user_events
WHERE event_time > now() - INTERVAL 7 DAY
GROUP BY day, funnel_step
ORDER BY day, funnel_step
SETTINGS allow_experimental_window_functions = 1;
2.3 能力对比总结
| 场景 | TiDB | ClickHouse | Doris |
|---|---|---|---|
| OLTP 事务 | 强 | 不支持 | 弱 |
| 简单分析 | 良好 | 极强 | 强 |
| 复杂 JOIN | 良好 | 良好 | 良好 |
| 实时更新 | 极强 | 弱 | 中等 |
| 批量导入 | 中等 | 极强 | 强 |
| 多表关联分析 | 中等 | 良好 | 良好 |
三、数据实时性对比
3.1 数据新鲜度
| 架构 | TiDB HTAP | ClickHouse(独立部署) | Doris(独立部署) |
|---|---|---|---|
| 事务数据可见 | 毫秒级(Raft 同步) | 依赖 ETL 管道 | 依赖 ETL 管道 |
| 分析数据可见 | 毫秒到秒级(TiFlash 异步复制) | 秒级到分钟级 | 秒级到分钟级 |
| 数据延迟保证 | 强一致读(跟随读 = 默认) | 最终一致 | 最终一致 |
3.2 数据管道对比
传统方案(OLTP + MPP):
MySQL → CDC → Kafka → Flink → ClickHouse
延迟:秒级到分钟级
组件:5+
TiDB HTAP 方案:
TiDB(OLTP 写入)→ TiFlash(自动同步)
延迟:毫秒级
组件:1 个集群
3.3 实时性差异的实际影响
| 业务场景 | 数据延迟要求 | 推荐方案 |
|---|---|---|
| 实时风控决策 | < 100ms | TiDB(强一致读) |
| 实时 Dashboard | < 5s | TiDB HTAP / ClickHouse |
| 离线 BI 报表 | T+1 | MPP 任选 |
| 实时推荐特征 | < 1s | TiDB / ClickHouse |
| 审计日志分析 | 分钟级 | MPP 任选 |
四、架构复杂度对比
4.1 系统组件数
| 方案 | 组件 | 数量 | 运维复杂度 |
|---|---|---|---|
| TiDB HTAP | TiDB + TiKV + PD + TiFlash + Monitor | 5 | 中等 |
| MySQL + ClickHouse | MySQL + CDC + Kafka + ClickHouse + ZooKeeper + Monitor | 6+ | 高 |
| MySQL + Doris | MySQL + CDC + Doris FE + Doris BE + Monitor | 5+ | 高 |
| TiDB + ClickHouse | TiDB + ClickHouse(互补) | 5+ | 中等偏高 |
4.2 运维成本评估
年运维人天估算(中型企业,TB 级数据):
方案 A:TiDB HTAP 单集群
日常运维:60 人天
故障处理:20 人天
架构迭代:15 人天
合计:95 人天
方案 B:MySQL + ClickHouse
日常运维:80 人天
CDC 管道维护:30 人天
数据一致性处理:25 人天
故障处理:30 人天
架构迭代:20 人天
合计:185 人天
运维成本差距:约 2 倍
4.3 学习成本
| 方案 | 技术栈要求 | 学习成本 |
|---|---|---|
| TiDB | MySQL 协议,标准 SQL | 低(MySQL 团队可快速上手) |
| ClickHouse | 独特 SQL 方言,MergeTree 模型 | 中等 |
| Doris | 标准兼容性好,概念较多 | 中等 |
| MySQL + CDC + MPP | MySQL + Kafka + Flink + MPP | 高(多技术栈) |
五、选型建议
5.1 按场景选型
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 业务系统 + 实时报表 | TiDB HTAP | 一套系统,运维简单 |
| 独立数据仓库(已分离) | ClickHouse/Doris | 分析性能极致 |
| 实时风控 + 即时分析 | TiDB HTAP | 强一致 + 毫秒级分析 |
| 日志分析 / 用户行为分析 | ClickHouse | 写入吞吐 + 向量化执行 |
| 多数据源联邦分析 | Trino + TiDB/ClickHouse | 查询引擎联邦能力 |
| 中小企业统一数据平台 | TiDB HTAP | 一站式,降低复杂度 |
5.2 组合方案:TiDB + ClickHouse
对于分析需求极为复杂的大型企业,推荐组合方案:
┌─────────────────────────────────────────┐
│ 应用层 │
└─────┬──────────────────┬───────────────┘
│ │
┌─────▼─────┐ ┌───────▼───────┐
│ TiDB │ │ ClickHouse │
│ OLTP + │───▶│ 深度分析 │
│ 轻量 OLAP │ │ 复杂报表 │
│ 实时查询 │ │ 聚邦查询 │
└───────────┘ └───────────────┘
分工:
TiDB:业务系统 + 实时 Dashboard + 轻量分析
ClickHouse:深度分析 + 复杂聚合 + 多源联邦
5.3 决策清单
选择 TiDB HTAP 当:
□ 需要 OLTP 和 OLAP 统一管理
□ 数据实时性要求高(秒级以内)
□ 团队熟悉 MySQL 生态
□ 运维人力有限,希望降低组件数
□ 数据量在 TB 到数百 TB 级
选择 MPP(ClickHouse/Doris)当:
□ 已有独立的 OLTP 系统
□ 分析查询极为复杂(10+ 表 JOIN)
□ 数据以批量导入为主
□ 分析是独立业务线
□ 对分析性能有极致要求
FAQ
Q1:TiDB HTAP 和独立 MPP 的分析性能差距有多大?
在简单聚合场景下,TiDB(TiFlash)性能约为 ClickHouse 的 40%-60%。在复杂多表 JOIN 场景下差距缩小到 20%-30%。对于大多数实时 Dashboard 和中等复杂度的分析,TiDB HTAP 的性能已经足够。只有在大规模(PB 级)复杂分析场景下,独立 MPP 的优势才明显。
Q2:TiDB 能否替代 ClickHouse?
取决于分析需求。对于实时 Dashboard、业务自服务分析、轻量 OLAP,TiDB HTAP 可以完全替代。对于超大规模(PB+)复杂分析、多源联邦查询、极致写入吞吐,ClickHouse 仍需保留。多数企业采用 TiDB HTAP 为主 + ClickHouse 为辅的互补方案。
Q3:TiFlash 的数据同步延迟是多少?
TiFlash 通过 Raft Learner 角色异步复制 TiKV 数据,典型延迟在 100ms-1s 之间,可通过 `tidb_replica_read` 设置控制读取策略。对于需要强一致读的场景,可以直接读 TiKV 行存数据。
Q4:Doris 和 ClickHouse 如何选择?
两者都是优秀 MPP 引擎。ClickHouse 在写入吞吐和单表查询性能上占优,适合日志分析。Doris 在多表 JOIN 和 MySQL 兼容性上更好,适合从 MySQL 迁移的场景。Doris 的运维门槛相对较低。
总结
NewSQL(TiDB)和 MPP(ClickHouse/Doris)并非对立关系,而是面向不同需求层次的分析方案。TiDB HTAP 通过一体化架构降低了数据管道复杂度,适合需要同时处理事务和分析的场景。MPP 在纯分析性能上更为极致,适合已分离架构或分析需求极为复杂的企业。
对大多数中型企业和新项目,TiDB HTAP 是降低架构复杂度的最优起点。对于分析需求极为复杂的大型企业,TiDB + MPP 的互补方案提供了最大的灵活性。
下一步行动
- 试用 TiDB HTAP:免费体验事务 + 分析一体化能力 → TiDB Cloud 免费试用
- 获取数据分析方案:提交分析场景描述,获取架构师定制方案 → PingCAP 数据分析方案
- 参加线上 workshop:TiDB HTAP 实战培训,体验从 OLTP 到 OLAP 的无缝切换 → TiDB 学习中心