轻量级实时数仓架构选型指南

300G数据、250张表、OSS降本与自动生命周期：轻量级实时数仓架构选型指南

背景

随着业务发展，我们的实时同步场景变得更加具体且极具代表性：

规模增长 ：数据量上升至 300GB ，表数量增至 ~250张。
冷热分明 ：
- 10张大表：全量保留，持续增长，数据价值高。
- 200+张流水表 ：包括日志、临时记录等，仅需保留 最近14天 数据（TTL），过期清理。
高频变更：上游业务频繁 Upsert/Delete。
Schema 易变：自动处理新增列、新增表。
成本控制 ：明确要求使用 OSS (对象存储) 降低存储成本。

面对这个需求，业界通常有两种声音：一种是拥抱流原生存储（Flink + Fluss ），另一种是坚持实时 OLAP 数据库（Apache Doris）。本文将从实施难度、性价比、功能匹配度三个维度进行深入剖析，并给出最终方案。

方案对比：Flink + Fluss vs Apache Doris

1. 自动 TTL（数据生命周期管理）

Apache Doris:
- 方案：动态分区 (Dynamic Partition)。
- 原理：Doris 可以按天自动创建分区。对于那 200 张流水表，只需在建表时设置 replication_num 和 dynamic_partition.buckets，并指定保留时间（TTL）为 14 天。系统会自动删除 14 天前的分区，完全无需人工介入。
- 评价：配置极其简单，SQL 原生支持。
Flink + Fluss:
- 方案：Partition Expiration。
- 原理：Fluss 支持配置分区过期策略，通过 Flink 作业定期清理过期文件。
- 评价：可行，但需要在 Table Config 中配置，且对数仓分析人员来说，不如 DB 的分区管理直观。

2. OSS 存储整合 (降本核心)

Apache Doris:
- 方案：冷热分层 (Tiered Storage)。
- 原理：
  - 200+张流水表：由于只存 14 天，且查询频繁，建议直接存本地 SSD/HDD，因为 300G 总量不大，放本地性能最好。
  - 10张大表：可以将"热数据"（如最近7天）存本地，超过7天的"冷数据"自动下沉到 OSS。Doris 对上层查询透明，用户无感。
- 评价：完美平衡了性能（热数据快）和成本（冷数据便宜）。
Flink + Fluss:
- 方案：Remote Storage (Tiered)。
- 原理：Fluss 架构设计上就是 Local Log (本地盘) + Remote Log (OSS/HDFS)。它可以将 Log 和 KV Snapshot 都推到 OSS 上。
- 评价：架构先进，天然适配云存储。但如果不配合 Flink 进行计算，仅仅作为存储查看数据并不方便。

3. 实施难度与 Schema 演进

Apache Doris:
- 难度：低。
- Schema ：配合 Flink CDC 3.0，支持整库同步。针对新增表，Doris 需要根据模板建表（需配置动态分区模板）；针对新增列，支持 Light Schema Change。
Flink + Fluss:
- 难度：中。需要维护 Flink 集群和 Fluss 服务。
- Schema：原生集成 Flink Catalog，Schema 变更传递非常顺滑。

核心方案推荐：Flink CDC 3.0 + Apache Doris (冷热分层版)

为什么要放弃 Fluss？

虽然 Fluss 在流式读写上很强，但针对 14天 TTL 清理 和 大表历史数据查询 这两个需求，Doris 的 SQL 表达能力和分区管理能力具有压倒性优势。300G 数据对于 Doris 来说极小，硬件成本极低。

架构图

MySQL Cluster -> Flink CDC 3.0 Pipeline -> Apache Doris (Local SSD + OSS)

实施细节指南

第一步：配置 Doris 连接 OSS (冷热分层资源准备)

我们需要告诉 Doris 怎么连你的 OSS。

sql 复制代码

-- 在 Doris 中创建 Storage Policy
CREATE RESOURCE "remote_oss"
PROPERTIES
(
    "type" = "s3",
    "s3.endpoint" = "oss-cn-hangzhou.aliyuncs.com",
    "s3.region" = "cn-hangzhou",
    "s3.bucket" = "your-bucket",
    "s3.access_key" = "ak",
    "s3.secret_key" = "sk"
);

CREATE STORAGE POLICY "policy_10_large_tables"
PROPERTIES(
    "storage_resource" = "remote_oss",
    "cooldown_ttl" = "7d"  -- 数据写入7天后，自动移动到 OSS
);

第二步：配置 Flink CDC Pipeline (整库同步核心)

这是实现 250张表自动同步 + 自动Schema变更 的关键。我们需要定义两个 Route（路由）策略，分别处理那 200 张小表和 10 张大表，因为它们的建表属性不一样（TTL 不同）。

pipeline.yaml 配置示例：

yaml 复制代码

source:
  type: mysql
  hostname: 192.168.1.100
  port: 3306
  username: root
  password: pwd
  tables: "scm_db.\.*" # 匹配库下所有表
  server-id: 5400-5405

sink:
  type: doris
  fenodes: "10.0.0.1:8030"
  username: root
  password: pwd
  sink.enable-delete: "true"
  
  # 【通用配置】自动Schema变更
  table.schema-change-mode: "evolve"

pipeline:
  name: "Sync-MySQL-To-Doris-Tiered"
  parallelism: 2

# 【关键路由策略】利用 Table Route 区分大表和小表
route:
  # 策略1：针对200张流水表（假设表名前缀是 log_ 或 tmp_，或者枚举）
  # 目标：只保留14天，不做冷热分离（毕竟14天就删了，没必要搬去OSS）
  - source-table: "scm_db.log_.*"
    sink-table: "doris_db.log_.*"
    description: "Flow tables with 14d TTL"
    # 注意：Flink CDC 目前自动建表通常使用默认模板
    # 要实现高级分区，建议先在 Doris 建好这250张表的 Template，
    # 或者修改 Flink CDC 源码/配置来注入 create table properties。
    # 也可以让 Flink CDC 自动建表后，手动在该表执行 ALTER TABLE 修改分区策略。

  # 策略2：针对10张大表
  # 目标：永久保留，7天后下沉 OSS
  - source-table: "scm_db.order_main|scm_db.order_detail"
    sink-table: "doris_db.\1" # 保持原名
    description: "Large tables with OSS Tiered Storage"

注：Flink CDC 自动建表（Auto Create Table）对于复杂的 Partition/OSS Policy 支持有限。最佳实践是：利用脚本在 Doris 侧批量预创建这 250 张表（带上 TTL 和 OSS 策略），然后让 Flink CDC 这里做数据同步和后续的加列操作。

Doris 侧流水表建表模板（含 14天 TTL）：

sql 复制代码

CREATE TABLE log_table_001 (
    id BIGINT,
    ...
) 
UNIQUE KEY(id)
PARTITION BY RANGE(dt) ()
DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES (
    "dynamic_partition.enable" = "true",
    "dynamic_partition.time_unit" = "DAY",
    "dynamic_partition.end" = "3",
    "dynamic_partition.prefix" = "p",
    "dynamic_partition.buckets" = "1",
    "replication_num" = "1",
    -- 核心：超过14天自动删除分区
    "dynamic_partition.start" = "-14" 
);

Doris 侧大表建表模板（含 OSS 下沉）：

sql 复制代码

CREATE TABLE order_main (
    order_id BIGINT,
    ...
)
UNIQUE KEY(order_id)
PARTITION BY RANGE(create_time) ()
DISTRIBUTED BY HASH(order_id) BUCKETS 10
PROPERTIES (
    "dynamic_partition.enable" = "true",
    "dynamic_partition.time_unit" = "DAY",
    -- 引用第一步定义的 OSS 策略
    "storage_policy" = "policy_10_large_tables",
    "replication_num" = "1"
);

方案性价比与资源预估

针对 300GB 数据量：

1. 资源需求

计算 (Doris): 3台 8C 32G 的虚拟机（甚至 1台 16C 64G 开发机都行）。Doris 对小数据量极其省资源。
存储 :
- Local SSD: 只需要给大家伙（10张表）预留最近7的数据空间 + 200张流水表 14天的数据空间。估计 150GB 左右 SSD 即可。
- OSS: 承载 10张大表的历史数据。按量付费，极其便宜。
中间件: Flink 只需要 2-4 个 TaskManager Slot。

2. 实施难度打分

环境部署: ★☆☆☆☆ (Doris 部署极快)
数据链路: ★★☆☆☆ (Flink CDC 配置 YAML 即可)
生命周期: ★☆☆☆☆ (Doris 动态分区全自动)
Schema变更: ★☆☆☆☆ (全自动)

3. Flink + Fluss 为什么稍逊一筹？

如果用 Fluss，你要处理 200 张表的过期。虽然 Fluss 支持，但你需要确保本地磁盘空间回收及时。如果要把数据存入 OSS，Fluss 也可以，但在进行数据 Ad-hoc 查询（比如运营突然要查某张流水表某条异常数据）时，Doris 可以毫秒级返回，而 Fluss 需要启动 Flink SQL 任务去扫描，查询体验和并发能力不在一个量级。

总结

对于 300G数据、250表、高频变更、自动TTL 这个特定场景：

请坚定选择 Apache Doris + Flink CDC 3.0。

省心：200张流水表自动过期，不用写 CRON 脚本去删数据。
省钱：10张大表历史数据进 OSS，存储成本几乎忽略不计。
全能：既能满足同步，又能直接提供极其强悍的 SQL 分析能力。

行动建议：不要把这个场景复杂化为"大数据"工程，这实际上是一个"大数据库"工程。用 Doris (MoW模型) 替换掉传统的 MySQL 分库分表 + T+1 同步方案，是目前 ROI 最高的选择。