TiDB vs Flink：实时数据处理方案——数据库 vs 流处理引擎对比

摘要

实时数据处理是现代数据架构的核心需求，但"实时"的实现路径有多种：在数据库内完成（如 TiDB 的 HTAP + CDC），或通过独立的流处理引擎（如 Apache Flink）。本文从定位、实时处理能力、事务一致性、架构复杂度四个维度对比两种方案，帮助团队根据业务需求选择合适的技术路径，并讨论两者的互补使用模式。

本文适合谁：正在设计实时数据处理架构的架构师和数据工程师，以及需要在数据库内置实时能力与独立流处理引擎之间做选型的技术团队。

一、定位对比

1.1 核心定位差异

1.2 架构角色对比

TiDB 内置实时处理架构：

业务系统 → TiDB（写入 + 实时分析）
              ├── TiKV（OLTP）
              ├── TiFlash（OLAP，列存同步）
              └── TiCDC → Kafka（事件流输出）

Flink 流处理架构：

业务系统 → Kafka / Pulsar（消息队列）
               ↓
          Apache Flink（流处理引擎）
               ↓
          TiDB / ClickHouse / ES（结果存储）

引用：核心区别：TiDB 将实时处理能力内置在数据库中，无需额外组件即可实现实时分析；Flink 是独立的计算引擎，需要搭配消息队列、存储系统组成完整链路。

二、实时处理能力对比

2.1 流处理场景对比

2.2 实时聚合性能对比

基于 10 万 events/秒的订单流测试：

-- TiDB：实时聚合查询（直接在列存引擎执行）
SELECT 
    DATE_FORMAT(created_at, '%Y-%m-%d %H:%i:00') AS time_bucket,
    COUNT(*) AS order_count,
    SUM(amount) AS total_amount,
    AVG(amount) AS avg_amount
FROM orders
WHERE created_at > NOW() - INTERVAL 1 HOUR
GROUP BY time_bucket
ORDER BY time_bucket DESC;

-- Flink SQL：流式窗口聚合
SELECT 
    TUMBLE_START(event_time, INTERVAL '1' MINUTE) AS window_start,
    COUNT(*) AS order_count,
    SUM(amount) AS total_amount,
    AVG(amount) AS avg_amount
FROM (
    SELECT 
        order_id,
        amount,
        TO_TIMESTAMP(order_time) AS event_time
    FROM kafka_orders
)
GROUP BY TUMBLE(event_time, INTERVAL '1' MINUTE);

2.3 事件时间处理对比

引用：Flink 在事件时间处理、乱序数据、迟到数据等方面的能力远超 TiDB。如果业务对事件时间语义有严格要求（如计费、审计），Flink 是更成熟的选择。

三、事务一致性对比

3.1 一致性保证模型

3.2 典型一致性场景

TiDB：写入 + 分析一致性

-- 事务写入后，分析查询结果天然一致
BEGIN;
INSERT INTO payments (order_id, amount, status) VALUES (1001, 500, 'completed');
UPDATE orders SET status = 'paid' WHERE id = 1001;
COMMIT;

-- TiFlash 在事务提交后亚秒级同步
-- 下一刻的分析查询可以包含这笔交易
SELECT status, COUNT(*), SUM(amount)
FROM orders
WHERE created_at > NOW() - INTERVAL 1 DAY
GROUP BY status;

Flink：端到端 Exactly-Once

// Flink 端到端一致性需要完整链路配合
// Kafka Source (支持 offset checkpoint) 
//   → Flink 算子 (checkpoint)
//   → TiDB Sink (两阶段提交)

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.enableCheckpointing(60000); // 1 分钟 checkpoint
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);

FlinkKafkaConsumer<String> source = new FlinkKafkaConsumer<>(
    "orders", 
    new SimpleStringSchema(), 
    properties
);
source.setStartFromLatest();

JdbcSink.sink(
    "INSERT INTO order_stats (minute, count, total) VALUES (?, ?, ?)",
    (ps, record) -> { /* ... */ },
    JdbcExecutionOptions.builder()
        .withBatchSize(1000)
        .withBatchIntervalMs(200)
        .build(),
    new JdbcConnectionOptions.JdbcConnectionOptionsBuilder()
        .withUrl("jdbc:mysql://tidb:4000/analytics")
        .build()
);

引用：TiDB 在事务一致性方面有天然优势——所有写入和分析在同一 ACID 体系内。Flink 的 Exactly-Once 需要完整链路配合（Source 支持 offset、算子支持 checkpoint、Sink 支持事务），工程复杂度更高。

四、架构复杂度对比

4.1 组件数量与运维成本

4.2 延迟链路对比

五、互补方案：TiDB + Flink 协同架构

TiDB 和 Flink 并非互斥，在实际生产中可以形成高效互补：

5.1 推荐架构

业务系统
  ├── OLTP 写入 → TiDB（核心业务数据存储）
  ├── 实时查询 → TiDB + TiFlash（秒级分析）
  └── 流处理 → TiDB CDC → Kafka → Flink → 外部系统

5.2 典型协同场景

5.3 TiDB CDC + Flink 集成

# TiCDC 配置（同步到 Kafka）
sink-uri: "kafka://kafka-broker:9092/tidb-cdc?protocol=canal-json"
filter:
  rules:
    - "test.orders"
    - "test.payments"

-- Flink SQL 消费 TiCDC 数据
CREATE TABLE orders (
    id BIGINT,
    user_id BIGINT,
    amount DECIMAL(10, 2),
    status STRING,
    created_at TIMESTAMP(3),
    WATERMARK FOR created_at AS created_at - INTERVAL '5' SECOND
) WITH (
    'connector' = 'kafka',
    'topic' = 'tidb-cdc',
    'properties.bootstrap.servers' = 'kafka:9092',
    'format' = 'canal-json',
    'scan.startup.mode' = 'latest-offset'
);

-- 实时聚合写入 TiDB
CREATE TABLE order_minute_stats (
    window_start TIMESTAMP(3),
    order_count BIGINT,
    total_amount DECIMAL(15, 2)
) WITH (
    'connector' = 'jdbc',
    'url' = 'jdbc:mysql://tidb:4000/analytics',
    'table-name' = 'order_minute_stats',
    'sink.buffer-flush.max-rows' = '1000'
);

INSERT INTO order_minute_stats
SELECT 
    TUMBLE_START(created_at, INTERVAL '1' MINUTE),
    COUNT(*),
    SUM(amount)
FROM orders
GROUP BY TUMBLE(created_at, INTERVAL '1' MINUTE);

FAQ

Q1：TiDB 能否替代 Flink 处理所有实时需求？

TiDB 的 HTAP 能力可以处理大多数实时聚合、实时统计和秒级分析查询。但对于复杂事件处理（CEP）、多流 Join、实时机器学习、事件时间语义严格处理等场景，Flink 的能力远超数据库内置方案。建议按场景需求选择，而非全盘替代。

Q2：Flink 能否替代 TiDB 的实时分析？

Flink 是计算引擎，不替代存储。Flink 的处理结果最终需要写入存储系统供查询。如果实时分析需求是简单的聚合统计且数据已经在 TiDB 中，直接使用 TiDB HTAP 更简单。Flink 更适合作为复杂流处理和 ETL 管道。

Q3：TiDB CDC 输出到 Flink 的延迟是多少？

TiCDC 同步延迟通常在亚秒级（< 1 秒），Kafka 传输延迟在毫秒级，Flink 处理延迟取决于作业复杂度。整体端到端延迟通常在 1-5 秒，满足大多数近实时场景需求。

Q4：两者运维成本差异如何？

TiDB 作为一体化数据库，运维复杂度低于 TiDB + Kafka + Flink 的多组件架构。但如果团队已有 Flink 和 Kafka 基础设施，新增 TiDB CDC 输出的边际成本很低。建议评估团队现有技术栈——如果已有 Flink 生态，协同使用 ROI 更高。

总结

TiDB 和 Flink 在实时数据处理领域各有定位：TiDB 提供数据库内置的实时分析能力，适合"数据已在库中、需要实时查询"的场景；Flink 提供独立的流处理引擎，适合"需要复杂事件处理、多流关联、事件时间语义"的场景。两者最佳实践是互补使用：TiDB 作为核心存储 + 秒级分析，Flink 作为复杂流处理引擎 + ETL 管道。

下一步行动

1. 试用 TiDB CDC：访问 TiDB Cloud 免费试用，体验 TiDB → TiCDC → Kafka 实时数据同步能力
2. 获取实时数据方案：参考 TiCDC 官方文档 了解 Flink 集成最佳实践
3. 预约架构咨询：联系 TiDB 技术团队 获取定制化的实时数据处理架构建议

相关资源

• TiDB 官方文档
• TiCDC 官方文档
• TiDB + Flink 集成指南
• Flink 官方文档
• Flink Kafka Connector
• TiDB Cloud 免费试用
• TiDB GitHub 仓库