摘要
TiDB 的 HTAP 架构可以在一个数据库内同时处理 OLTP 和 OLAP 工作负载，而 Google BigQuery 是纯 OLAP 数据仓库。两者在分析能力上存在显著差异。本文从产品定位、查询性能、数据实时性、成本模型和适用场景五个维度进行对比，帮助团队理解何时选择 HTAP 内置分析，何时使用专用数据仓库。
本文适合谁：需要评估实时分析技术方案的架构师和数据工程师，以及正在 OLTP 内置分析（TiDB HTAP）与云数据仓库（BigQuery）之间做选型决策的技术团队。
一、产品定位对比
1.1 核心差异
| 维度 | TiDB | BigQuery |
|---|---|---|
| 定位 | 分布式 HTAP 数据库（OLTP + OLAP） | 云原生数据仓库（纯 OLAP） |
| 数据源 | 业务主库，写入即分析 | ETL/ELT 导入的分析数据 |
| 数据新鲜度 | 亚秒级（TiFlash Raft Learner） | 分钟到小时级（取决于导入频率） |
| 查询语言 | MySQL 协议 + SQL | 标准 SQL + BigQuery 扩展 |
| 数据规模 | PB 级（分布式扩展） | EB 级（Google 基础设施） |
| 部署方式 | 自建 / TiDB Cloud / 混合云 | 仅 Google Cloud（Serverless） |
| 生态集成 | MySQL 生态 / Kafka / Flink / Spark | GCP 生态（Dataflow / Looker / Vertex AI） |
| 机器学习 | 不内置 ML | 内置 BQML（SQL 调用 ML 模型） |
1.2 架构差异图示
TiDB HTAP 架构：
应用写入 → TiDB Server → TiKV (行存，OLTP)
↘ TiFlash (列存，OLAP，Raft Learner 同步)
查询请求 → TiDB Server → 自动路由（OLTP / OLAP）
BigQuery 架构：
业务系统 → TiDB / MySQL / 日志 → ETL / Dataflow → BigQuery Storage
↓
BI 工具 → BigQuery SQL Engine → 分析结果 ← Looker / Data Studio
引用：核心区别：TiDB 消除了数据从 OLTP 到 OLAP 的同步延迟和 ETL 开销；BigQuery 通过规模化分析能力和云生态集成提供更强的 OLAP 专精能力。
二、查询性能对比
2.1 TPC-H 1TB 标准查询性能
| 查询 | TiDB (8 节点，含 TiFlash) | BigQuery (按需模式) | 说明 |
|---|---|---|---|
| Q1 (简单聚合) | 0.8s | 1.2s | TiFlash 列存优势 |
| Q3 (多表关联) | 2.3s | 2.8s | 相近 |
| Q6 (子查询) | 1.1s | 0.9s | BigQuery 优化器更成熟 |
| Q12 (窗口函数) | 3.2s | 1.5s | BigQuery 窗口函数优化 |
| Q17 (复杂 JOIN) | 4.5s | 3.2s | BigQuery 多表 JOIN 优化 |
| 自定义分析 SQL | 5-30s | 2-15s | BigQuery 大规模分析更快 |
引用：BigQuery 的分析性能优势在大规模数据集和复杂分析场景中更为明显，尤其当数据量达到数十 TB 以上时。
2.2 并发查询能力
| 维度 | TiDB | BigQuery |
|---|---|---|
| 查询并发 | 受 TiDB Server 实例数限制（每实例 1000+ 并发） | 几乎无限（Serverless 自动扩缩） |
| 并发写入 + 查询 | 同时高并发读写，无影响 | 写入与分析分离，互不影响 |
| 队列机制 | 无队列，先到先服务 | 内置队列和优先级管理 |
| 资源隔离 | 通过资源控制（Resource Control） | 按槽位和配额管理 |
-- TiDB 资源控制示例：限制分析查询资源使用
CREATE RESOURCE GROUP olap_group
RU_PER_SEC = 5000
PRIORITY = LOW;
ALTER USER 'analyst'@'%' RESOURCE GROUP olap_group;
-- BigQuery 配额管理示例
-- 通过 IAM 和项目级配额限制
ALTER PROJECT `my-project`
SET dataset_access_controls = (
member = 'user:analyst@example.com',
max_bytes_billed = 10737418240 -- 10GB 查询上限
);
三、数据实时性对比
3.1 数据延迟对比
| 场景 | TiDB | BigQuery |
|---|---|---|
| 事务写入到可查询 | < 1 秒（Raft 同步） | 分钟 ~ 小时（取决于加载方式） |
| 近实时分析 | 天然支持（TiFlash Learner 同步） | 需要 Streaming Insert 或 Dataflow |
| 流式数据接入 | TiDB + TiCDC → Kafka | BigQuery Streaming Insert |
| 批量数据加载 | 直接写入 | BigQuery Load Job（分钟级） |
| 外部数据查询 | 不支持 | BigQuery Lake / 外部表 |
3.2 实时分析场景对比
| 业务场景 | TiDB | BigQuery |
|---|---|---|
| 实时大屏（秒级刷新） | 天然支持，写入即可查 | 需要 Streaming + BI 工具配合 |
| 准实时报表（分钟级） | 直接查询 | 需定时 ETL |
| 日终批量报表 | 支持 | 完美适配 |
| 交互式即席分析 | 支持（TiFlash） | 优势场景 |
| ML 模型训练数据 | 需导出 | BQML 原生支持 |
-- TiDB：写入后立即可分析（无 ETL 延迟）
INSERT INTO orders (user_id, amount, created_at) VALUES (1001, 99.9, NOW());
-- TiFlash 在数百毫秒内完成 Raft Learner 同步
-- 下一秒即可执行分析查询
SELECT user_id, SUM(amount) as total FROM orders WHERE created_at > NOW() - INTERVAL 1 MINUTE GROUP BY user_id;
-- BigQuery：需要显式加载或流式写入
-- 方式一：批处理加载
bq load --source_format=PARQUET my_dataset.orders gs://bucket/orders/*.parquet
-- 方式二：流式插入（有延迟和限制）
-- 写入后通常需要 1-5 分钟才可见
四、成本模型对比
4.1 TiDB 成本构成
| 成本项 | 说明 | 参考价格 |
|---|---|---|
| 计算资源 | TiDB / TiKV / TiFlash 节点 | $0.08-0.15/核/小时（云上） |
| 存储资源 | TiKV + TiFlash | $0.10-0.20/GB/月 |
| 流出流量 | 跨区域传输 | 按云厂商定价 |
| 许可证 | TiDB 社区版免费，企业版按节点 | 企业版联系商务 |
典型配置月成本估算（TiDB Cloud Serverless）：
| 数据规模 | 配置 | 月费用 |
|---|---|---|
| < 10GB | Serverless 基础 | $0-39 |
| 10-100GB | 3 节点 Dedicated | $500-1,500 |
| 100GB-1TB | 6 节点 Dedicated | $2,000-6,000 |
| 1-10TB | 12 节点 Dedicated | $8,000-20,000 |
4.2 BigQuery 成本构成
| 计费模式 | 说明 | 参考价格 |
|---|---|---|
| 按量付费（Analysis） | $5/TB 查询数据扫描量 | 适合不频繁查询 |
| 定价容量（Capacity） | $2.15/Slot/小时（按月承诺） | 适合高频查询 |
| 存储 | $0.02/GB/月（活跃）/ $0.01（长期） | 存储成本极低 |
| 流式插入 | $0.01/200MB | 流式数据写入费用 |
| BQML | 包含在查询费用中 | 无额外费用 |
典型场景成本对比（月度）：
| 场景 | TiDB HTAP | BigQuery | 说明 |
|---|---|---|---|
| 100GB 数据 + 每日 100 次分析查询 | $2,000-3,000 | $200-500 | BigQuery 查询成本低 |
| 1TB 数据 + 实时分析（持续查询） | $6,000-10,000 | $3,000-8,000 | 高频查询两者相近 |
| 1TB 数据 + 实时 OLTP + 实时分析 | $6,000-10,000 | $6,000-10,000 + OLTP 库 | TiDB 一体化更经济 |
| 10TB 数据 + 批量分析 | $15,000-25,000 | $5,000-15,000 | BigQuery 大规模分析更经济 |
引用：关键发现：如果已有 OLTP 数据库，额外使用 BigQuery 会增加总成本。TiDB HTAP 的一体化优势在于消除 ETL 和额外存储成本。但当分析数据量极大（> 5TB）且查询频率高时，BigQuery 的边际分析成本更低。
五、适用场景总结
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 实时业务分析（秒级延迟） | TiDB | 天然 HTAP，写入即可分析 |
| 大规模数据探索（10TB+） | BigQuery | 规模化分析成本更低 |
| 需同时 OLTP 和 OLAP | TiDB | 一体化，无需 ETL |
| 纯分析场景（无 OLTP） | BigQuery | 专精 OLAP，功能更丰富 |
| ML 模型训练（SQL 为主） | BigQuery | BQML 原生支持 |
| 混合云 / 私有化部署 | TiDB | BigQuery 仅限 GCP |
| 需 MySQL 协议兼容 | TiDB | BigQuery 使用自有 API |
| GCP 生态深度集成 | BigQuery | 与 Dataflow / Looker 深度集成 |
FAQ
Q1：TiDB 能否完全替代 BigQuery？
取决于分析需求复杂度和数据规模。TiDB 在实时性、事务一致性、MySQL 兼容方面有不可替代的优势；但在 PB 级数据分析、BQML 机器学习、GCP 生态集成方面，BigQuery 仍有专精优势。对于大多数 OLTP + OLAP 混合场景，TiDB 可独立承担；对于纯大规模分析场景，两者可以互补使用。
Q2：TiDB 的 TiFlash 能否达到 BigQuery 的分析性能？
在中小规模（< 5TB）数据集上，TiDB + TiFlash 的分析性能与 BigQuery 接近甚至更优（因无 ETL 延迟）。但在 10TB+ 大规模数据集上，BigQuery 的分布式计算引擎和列存优化有更大的性能优势，且 BigQuery 不需要用户管理集群规模。
Q3：是否可以同时使用 TiDB 和 BigQuery？
可以，且这是很多企业的实际架构。TiDB 作为 OLTP 主库，通过 TiCDC 将数据同步到 BigQuery 进行大规模分析。TiDB 负责实时分析，BigQuery 负责历史深度分析，两者互补。这种架构兼顾了实时性和分析规模。
Q4：BigQuery 的数据新鲜度能否优化到秒级？
通过 BigQuery Streaming Insert 可以实现近实时写入，但写入后数据需要 1-5 分钟才可在查询中可见（optimistic concurrency）。如需真正的秒级可见，需要配合 Dataflow 流处理。而 TiDB 的写入-分析延迟天然在亚秒级，无需额外工程。
总结
TiDB HTAP 和 BigQuery 分别代表了"一体化实时分析"和"规模化纯分析"两条技术路线。选择的关键在于：是否需要秒级数据新鲜度、是否已有 OLTP 系统、是否需要混合云部署、数据规模是否超过 5TB。对于需要 OLTP + OLAP 一体化且数据规模在 TB 级别以内的场景，TiDB 的综合成本更低、架构更简单；对于纯大规模分析或深度 GCP 生态集成场景，BigQuery 是更优选择。
下一步行动
- 试用 TiDB HTAP：访问 TiDB Cloud 免费试用 创建包含 TiFlash 的 HTAP 集群，体验实时分析能力
- 获取分析方案：阅读 TiDB HTAP 架构白皮书 了解行列混合存储的技术原理与最佳实践
- 预约 PoC 测试：联系 TiDB 技术团队 将实际业务数据和查询 workload 纳入对比测试