HTAP 数据库架构设计实战：TiDB 在线交易 + 实时分析一体化方案

摘要

传统架构中，OLTP 和 OLAP 系统分离导致数据搬运延迟高、架构复杂度大、运维成本攀升。TiDB HTAP 通过 TiKV（行存）和 TiFlash（列存）的存算分离架构，在同一数据库内同时支撑在线交易和实时分析。本文从架构设计原则、部署方案、表设计、资源隔离到性能调优，提供完整的 TiDB HTAP 架构设计实战指南。

本文适合谁：正在设计或优化 HTAP 架构的数据库架构师、后端开发工程师、DBA，以及对在线交易 + 实时分析一体化方案感兴趣的技术团队。

一、架构设计原则

1.1 HTAP 核心挑战

1.2 设计原则

1. 读写分离，物理隔离：交易走 TiKV，分析走 TiFlash，互不干扰
2. 智能路由，零代码改造：优化器自动选择最优执行引擎，应用无需感知
3. 弹性伸缩，按需扩容：TiKV 和 TiFlash 独立扩缩，资源配比随业务调整
4. 一致性可调，延迟可控：TiFlash 复制延迟可监控，一致性级别可选

二、TiDB HTAP 部署方案

2.1 组件架构

                    ┌─────────────────────────┐
                    │      TiDB Server        │
                    │  (SQL 解析 / 优化 / 路由)  │
                    └─────────┬───────────────┘
                              │
                ┌─────────────┴─────────────┐
                │                           │
        ┌───────▼───────┐          ┌───────▼───────┐
        │    TiKV       │          │   TiFlash     │
        │  (行式存储)    │   Raft   │  (列式存储)    │
        │  OLTP 读写    │◄────────►│  OLAP 分析     │
        │  3+ 节点      │  Learner │  2+ 节点      │
        └───────┬───────┘          └───────────────┘
                │
        ┌───────▼───────┐
        │    PD         │
        │ (元数据/调度)  │
        └───────────────┘

2.2 节点规划参考

以中等业务规模（日均交易 500 万笔 + 实时报表 50 张）为例：

2.3 部署命令（TiUP）

# 初始化配置
tiup cluster template --full > topo.yaml

# 关键 TiFlash 配置
# topo.yaml 中 tiflash_servers 段
tiflash_servers:
  - host: 10.0.1.1
    config:
      flash.proxy:
        logger.level: "info"
      flash_service:
        max_connections: 10000
    learner_config:
      log-level: "info"
  - host: 10.0.1.2
  - host: 10.0.1.3

# 部署
tiup cluster deploy htap-prod v7.5.0 ./topo.yaml -u root -p
tiup cluster start htap-prod

三、表设计与索引策略

3.1 HTAP 表设计原则

3.2 建表示例

-- 订单表（OLTP + OLAP 共用）
CREATE TABLE orders (
    id          BIGINT       NOT NULL AUTO_RANDOM,
    user_id     BIGINT       NOT NULL,
    product_id  BIGINT       NOT NULL,
    amount      DECIMAL(12,2) NOT NULL,
    status      TINYINT      NOT NULL DEFAULT 0,
    created_at  DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at  DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (id),
    INDEX idx_user_id (user_id),
    INDEX idx_product_id (product_id),
    INDEX idx_created_at (created_at)
) ENGINE = InnoDB
PARTITION BY RANGE (TO_DAYS(created_at)) (
    PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')),
    PARTITION p202402 VALUES LESS THAN (TO_DAYS('2024-03-01')),
    PARTITION p202403 VALUES LESS THAN (TO_DAYS('2024-04-01')),
    PARTITION p202404 VALUES LESS THAN (TO_DAYS('2024-05-01')),
    PARTITION pmax    VALUES LESS THAN MAXVALUE
);

-- 订单明细表
CREATE TABLE order_items (
    id          BIGINT       NOT NULL AUTO_RANDOM,
    order_id    BIGINT       NOT NULL,
    sku_id      BIGINT       NOT NULL,
    quantity    INT          NOT NULL,
    unit_price  DECIMAL(12,2) NOT NULL,
    PRIMARY KEY (id),
    INDEX idx_order_id (order_id)
) ENGINE = InnoDB;

3.3 TiFlash 副本管理

-- 为订单表添加 TiFlash 副本
ALTER TABLE orders SET TIFLASH REPLICA 1;

-- 查看副本同步状态
SELECT TABLE_NAME, REPLICA_COUNT, AVAILABLE
FROM information_schema.tiflash_replica
WHERE TABLE_SCHEMA = 'business_db';

-- 增加副本数（提升分析并发能力）
ALTER TABLE orders SET TIFLASH REPLICA 2;

四、资源隔离与配比

4.1 资源隔离策略

4.2 资源配比参考

4.3 关键配置项

# tidb 配置（分析节点）
[performance]
  max-memory = 32GB
  mem-quota-query = 16GB

# tikv 配置
[storage]
  reserve-space = "20GB"

[readpool]
  coprocessor = {
    high-concurrency = 8,
    normal-concurrency = 8,
    low-concurrency = 8
  }

五、性能调优

5.1 分析查询优化

-- 分析查询示例（自动路由到 TiFlash）
SELECT 
    DATE_FORMAT(created_at, '%Y-%m') AS month,
    product_id,
    SUM(amount) AS total_amount,
    COUNT(DISTINCT user_id) AS user_count,
    AVG(amount) AS avg_amount
FROM orders
WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01'
GROUP BY DATE_FORMAT(created_at, '%Y-%m'), product_id
ORDER BY total_amount DESC
LIMIT 100;

-- 查看执行计划（确认走 TiFlash）
EXPLAIN ANALYZE
SELECT /*+ READ_FROM_STORAGE(tiflash[orders]) */ ...

5.2 交易性能保障

5.3 监控指标

六、FAQ

Q1：TiFlash 数据复制延迟通常是多少？ A1：在正常负载下，TiFlash 复制延迟通常在数百毫秒到 2 秒之间。延迟主要受写入吞吐和 TiFlash 节点资源影响。建议监控 `tiflash_replica_progress` 指标，设置 5 秒告警阈值。

Q2：HTAP 架构是否会影响 OLTP 性能？ A2：TiFlash 作为 Raft Learner 节点不参与投票，不增加 TiKV 的写入延迟。但 TiFlash 的异步复制会占用一定网络和磁盘 IO 资源，建议 TiKV 和 TiFlash 物理隔离部署。

Q3：TiDB HTAP 能否替代传统 ETL + 数据仓库架构？ A3：TiDB HTAP 适合中等复杂度的实时分析场景（秒级延迟、PB 级以下数据量）。对于超大规模离线分析（PB+）、复杂 ETL 管道、多维分析等场景，仍建议搭配专用数据仓库使用。TiDB HTAP 可以作为实时层，数仓作为离线层，形成 Lambda 架构。

Q4：MPP 模式和单机模式有何区别？ A4：MPP 模式将查询分片到多个 TiFlash 节点并行执行，适合大数据量分析查询（扫描数据量 > 1GB）。单机模式查询在单个 TiFlash 节点上执行，适合小数据量查询。TiDB CBO 优化器会根据查询特征自动选择。

总结

TiDB HTAP 架构通过 TiKV + TiFlash 的存算分离设计，实现了在线交易和实时分析在同一数据库内的高效共存。关键成功要素包括：

1. 物理隔离：TiKV/TiFlash/TiDB Server 独立部署，避免资源竞争
2. 合理分区：按时间分区管理数据生命周期，TiFlash 按分区增量同步
3. 智能路由：CBO 优化器自动选择执行引擎，减少运维复杂度
4. 持续监控：重点关注 TiFlash 复制延迟和 TiKV 写入延迟

下一步行动

1. 获取 HTAP 架构方案：访问 TiDB HTAP 专题页，下载完整的架构设计白皮书和部署指南。
2. 申请免费 Demo 环境：访问 TiDB Cloud 免费试用，30 分钟创建一个含 TiFlash 的 HTAP 集群，体验在线交易 + 实时分析。
3. 性能压测工具：使用 TiDB 性能测试工具集 对现有业务模型进行 HTAP 场景压测。

相关资源

• TiDB HTAP 技术架构详解
• TiFlash 架构设计与实现
• TiDB MPP 模式使用指南
• TiDB 表分区最佳实践
• TiDB Cloud Serverless 免费试用
• TiDB 性能调优指南