大数据：电商实时大屏怎么搭？Kafka + Flink + Doris 实时数仓架构实战

一、问题定义：大屏到底在解决什么

很多团队做大屏的起点是“老板要看”，终点却是“没人看”。原因往往不是技术不行，而是需求没有被翻译成可度量的工程目标。笔者认为，电商实时大屏的本质是一个决策反馈系统：它把 GMV、订单量、支付转化、库存水位、履约时效等指标，以秒级延迟呈现给运营、供应链与风控，从而让“发现问题—定位原因—采取动作”的闭环缩短。

这就引出一个关键区分：监控（monitoring）与观测（observability）不是一回事。监控回答“指标是否越界”，观测回答“为什么越界”。大屏如果只做前者，就退化成一块会闪的仪表盘；只有把维度下钻、异常归因、数据血缘一并纳入，才具备业务价值。本文评述：业界常把大屏当作 BI 的实时版，但实时场景下“口径漂移”和“重复计算”的代价远高于离线，因此口径治理必须前置到建模阶段，而不是在大屏层做“补丁式修正”。

1.1 三类典型业务诉求与对应 SLA

不同业务对“实时”的定义差异极大。大促作战室要求秒级；供应链补货可以分钟级；财务对账则更看重准确性与可回溯。把它们混在一条链路上，必然导致资源浪费或体验不足。

注：表中延迟区间为工程经验区间（模拟归纳），实际取值应结合业务峰值与基础设施能力标定。

1.2 常见失败模式

笔者在多个项目中观察到的失败模式高度相似：其一，口径未冻结，大屏数字与报表对不上，业务失去信任；其二，峰值击穿，大促流量突增导致 Kafka 堆积、Flink 反压、Doris 查询排队；其三，故障不可回撤，一次错误发布污染了结果表，却无法快速重算。这三者分别对应一致性、时效性、可运维性——正是本文的分析主线。

工程判断：大屏项目的验收标准不应是“页面好看”，而应是“在压测与故障演练下，关键指标仍能在承诺延迟内给出可解释结果”。

二、总体架构：三角约束下的分层设计

Kafka + Flink + Doris 之所以成为国内实时数仓的主流组合，原因在于职责边界清晰：Kafka 承担“缓冲与解耦”，Flink 承担“计算与状态”，Doris 承担“存储与服务”。本文评述：这套组合的真正优势不是单点性能，而是每一层都能独立扩缩与回放，从而为“可运维性”留出空间。

2.1 分层视图

业务库(MySQL/分库分表) ──CDC──┐
                              ├─→ Kafka(ODS, 多分区/多副本)
客户端埋点/日志 ──SDK/Agent──┘        │
                                      ▼
                         Flink(DWD 清洗/去重/维表关联)
                                      │
                                      ▼
                         Flink(DWS 轻度聚合/窗口指标)
                                      │
                                      ▼
                    Doris(明细宽表 + 聚合表 + 物化视图)
                                      │
                    ┌─────────────────┼─────────────────┐
                    ▼                 ▼                 ▼
              大屏 API(点查)    即席分析(Ad-hoc)   告警/对账任务

分层的关键在于“ODS 不做业务加工、DWD 保证行级正确、DWS 保证口径统一、ADS 面向场景”。很多团队把聚合逻辑散落在 Flink 作业与大屏 SQL 两处，最终导致口径分裂。笔者认为，口径应当收敛到 DWS 层，并以“指标字典 + 版本号”的形式固化，大屏只做取数与展示。

2.2 技术选型的对比思辨

需要强调的是，选型没有“最优解”，只有“约束下的可行解”。若业务以宽表扫描型分析为主、更新极少，ClickHouse 可能更省心；若更新频繁、要求点查与聚合并存，Doris 的模型抽象更友好。本文评述：不要用基准测试的峰值数字做决策，而要用自身业务的读写比、更新率、并发曲线做决策。

三、数据接入：埋点流与 CDC 流的双源治理

实时大屏的数据通常来自两条动脉：一条是客户端与服务端埋点（行为流），一条是业务库变更（状态流）。前者量大、易乱序、易重复；后者要求顺序与完整性。二者若不在接入层就做好治理，后面所有环节都会被“脏数据”拖累。

3.1 埋点流：从“能采”到“可信”

埋点治理的核心是事件模型与唯一标识。建议统一事件规范：event_id、event_time（客户端时间）、server_time（服务端接收时间）、user_id、device_id、session_id、page_id、props。其中 event_time 与 server_time 的差异是判断时钟漂移与延迟的关键。

{
  "event_id": "order_submit",
  "event_time": 1718000000123,
  "server_time": 1718000000456,
  "user_id": "u_1024",
  "device_id": "d_9f3a",
  "session_id": "s_7c21",
  "page_id": "checkout",
  "props": {"sku_id":"S001","amount":199.00,"channel":"app"}
}

去重策略上，客户端重试与网络重发会导致同一事件多次到达。工程上常用“业务主键 + 幂等写入”解决：在 Flink 中按 event_id 做 keyBy 后使用状态去重，或在 Doris 侧用 Unique 模型以 event_id 为主键 Upsert。笔者认为，去重应尽量前移，因为越往后去重，状态与存储成本越高。

3.2 CDC 流：顺序、快照与 Schema 演进

CDC（Change Data Capture）把数据库的 binlog 转为变更事件。Flink CDC 基于 Debezium 的语义，支持全量+增量一体化读取。工程要点有三：其一，全量阶段与增量阶段的衔接必须保证不重不漏，通常依赖快照位点与 binlog 位点的对齐；其二，Schema 演进要可容忍加列，避免因 DDL 导致作业失败；其三，分库分表合并需在 Flink 侧做路由与主键归一。

-- Flink SQL 读取 MySQL CDC（示例）
CREATE TABLE orders_cdc (
  order_id     BIGINT,
  user_id      BIGINT,
  amount       DECIMAL(12,2),
  status       STRING,
  update_time  TIMESTAMP(3),
  PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
  'connector' = 'mysql-cdc',
  'hostname'  = 'mysql-prod',
  'port'      = '3306',
  'username'  = 'flink_reader',
  'password'  = '******',
  'database-name' = 'trade',
  'table-name'    = 'orders',
  'server-time-zone' = 'Asia/Shanghai'
);

本文评述：CDC 的“看起来简单”是最大的陷阱。生产环境里，主从切换、大事务、DDL 变更都会让链路抖动。建议在接入层设置“变更事件缓冲 + 死信队列”，把无法解析的事件隔离而非直接丢弃，为后续补偿留出余地。

3.3 Kafka 主题设计

主题规划应遵循“按域拆分、按量分区、按重要性定副本”。分区数不是越多越好：分区过多会增加元数据与再均衡成本，过少则限制并行度。经验上，单分区吞吐在数 MB/s 量级，可按峰值吞吐除以单分区能力再留 30% 余量估算（模拟经验值，需以实测为准）。

四、Flink 计算层：一致性、水位线与状态

Flink 是整条链路的“心脏”。它决定了数字是否准确、延迟是否可控、故障后能否恢复。笔者认为，Flink 作业的工程质量可以用三个问题检验：端到端是否 Exactly-Once？乱序数据如何界定？状态会不会无限膨胀？

4.1 端到端 Exactly-Once 的落地条件

Exactly-Once 不是单一开关，而是“源可回放 + 状态可快照 + 汇可幂等/事务”三者共同成立的结果。Kafka Source 通过 offset 与 checkpoint 绑定实现可回放；Flink 内部通过分布式快照保证状态一致；Doris Sink 则依赖两阶段提交（2PC）或幂等 Upsert 达成端到端语义。

// 关键配置（示例，需按集群调优）
env.enableCheckpointing(60_000);                 // 1 分钟一次
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(30_000);
env.getCheckpointConfig().setCheckpointTimeout(10 * 60_000);
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
env.getCheckpointConfig().setExternalizedCheckpointCleanup(
    ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);

本文评述：很多团队开了 EXACTLY_ONCE 就以为万事大吉，却忽略了下游事务超时与两阶段提交的失败恢复。若 Doris 事务在超时窗口内未提交，checkpoint 会失败并触发回滚，表现为“作业反复重启”。因此事务超时、checkpoint 间隔、批大小三者必须联合标定。

4.2 水位线与乱序处理

事件时间语义下，水位线（Watermark）是对“数据完整度”的承诺。水位线越激进，延迟越低但可能漏算；越保守，结果越完整但延迟越高。工程上常用“有界乱序 + 空闲分区检测”：

WatermarkStrategy<Event> strategy =
    WatermarkStrategy.<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5))
        .withIdleness(Duration.ofMinutes(1))
        .withTimestampAssigner((e, ts) -> e.getEventTime());

需要提醒的是，窗口结果并非“最终结果”。若业务要求可修正，应引入“允许迟到 + 侧输出重算”或直接在 Doris 侧做增量修正。笔者认为，大屏场景下“先出数、后修正”往往比“等齐再出”更符合业务预期，但必须在页面上标注数据状态（如“实时/已校正”）。

4.3 维表关联：Lookup Join 的取舍

商品、店铺、用户画像等维表关联是实时链路的性能热点。常见方案有：广播状态（适合小维表）、Lookup Join（适合大维表、需外部存储）、预加载缓存（适合变化少的维表）。Lookup Join 的坑在于缓存 TTL 与数据新鲜度的矛盾：TTL 太长会关联到旧维度，太短则打爆维表库。

-- Lookup Join 示例（Doris 维表）
CREATE TABLE dim_sku (
  sku_id STRING,
  category STRING,
  brand STRING,
  PRIMARY KEY (sku_id) NOT ENFORCED
) WITH (
  'connector' = 'jdbc',
  'url' = 'jdbc:mysql://doris-fe:9030/dim',
  'table-name' = 'dim_sku',
  'lookup.cache.max-rows' = '50000',
  'lookup.cache.ttl' = '10min'
);

SELECT o.order_id, o.amount, s.category
FROM orders o
LEFT JOIN dim_sku FOR SYSTEM_TIME AS OF o.proc_time AS s
ON o.sku_id = s.sku_id;

本文评述：维表关联的“正确性”常被低估。若维表发生缓慢变化（SCD），实时关联到底取“事件发生时的维度”还是“当前维度”，会直接导致口径差异。建议在指标字典中显式声明维度时间语义，避免事后扯皮。

4.4 状态治理与反压

状态是 Flink 的能力也是负担。去重状态、窗口状态、Join 状态都会随时间增长。治理手段包括：设置状态 TTL、使用 RocksDB 增量 checkpoint、合理设置并行度与槽位。反压（backpressure）出现时，应先看“是计算慢还是写出慢”：若 Sink 端 Doris 导入排队，反压会一路传导到 Source，表现为 Kafka 消费滞后。

排障顺序建议：Kafka 消费滞后 → Flink 反压面板 → 算子繁忙度 → Sink 导入延迟 → Doris BE 负载。先定位瓶颈层，再谈参数调优，避免“盲调并行度”。

五、Doris 存储层：表模型、物化视图与点查

Doris 在实时数仓中的角色是“服务层”：既要承接高并发点查（大屏刷新），又要支撑聚合分析（下钻）。选错表模型，后面怎么调都别扭。

5.1 三种表模型的适用边界

本文评述：“明细宽表 + 聚合表”双写是实时大屏的常见折中：明细宽表保证可下钻，聚合表保证大屏首屏秒开。但双写会带来一致性风险，建议以明细为准、聚合表可重算，并在监控中比对两者差值。

5.2 建表示例与分区分桶

CREATE TABLE dws_trade_metric_1m (
  dt          DATE,
  ts_minute   DATETIME,
  channel     VARCHAR(32),
  category    VARCHAR(64),
  gmv         DECIMAL(18,2) SUM,
  order_cnt   BIGINT SUM,
  pay_cnt     BIGINT SUM
) ENGINE=OLAP
AGGREGATE KEY(dt, ts_minute, channel, category)
PARTITION BY RANGE(dt) (
  PARTITION p202406 VALUES [('2024-06-01'), ('2024-07-01'))
)
DISTRIBUTED BY HASH(channel) BUCKETS 16
PROPERTIES (
  "replication_num" = "3",
  "compression" = "ZSTD"
);

分桶键应选择“高基数且查询常带”的列，避免数据倾斜。分区粒度按数据量与保留周期权衡：日分区便于 TTL 管理，小时分区适合超大数据量。需要提醒的是，分桶数一旦确定，后期调整需重建表，因此初期应按 6–12 个月的数据增长预估。

5.3 物化视图与查询加速

物化视图（Materialized View）可把“固定聚合路径”预计算，查询时由优化器透明改写。它适合“大屏固定指标 + 固定维度组合”的场景。但物化视图不是银弹：过多会增加写入放大与存储成本，且对不匹配的查询无效。

CREATE MATERIALIZED VIEW mv_gmv_by_channel AS
SELECT dt, channel, SUM(gmv) AS gmv, SUM(order_cnt) AS order_cnt
FROM dwd_trade_detail
GROUP BY dt, channel;

笔者认为，物化视图的治理应纳入“指标资产”管理：每个 MV 对应哪个指标、由谁负责、何时失效，都要有登记。否则半年后没人敢删，存储成本悄悄膨胀。

六、大屏渲染：从查询到像素的最后一公里

很多架构文章讲到这里就结束了，但用户真正看到的是页面。大屏的体验取决于三件事：查询是否够快、刷新是否平滑、异常是否可感知。

6.1 接口设计：聚合接口与增量接口

建议把大屏接口分为“首屏聚合接口”和“增量轮询接口”。首屏返回近 1 小时/24 小时的聚合结果；增量接口只返回自上次时间戳以来的变化。这样既降低数据库压力，又避免页面闪烁。

GET /api/dashboard/gmv?from=1718000000&to=1718003600&dim=channel
→ {"code":0,"data":[{"channel":"app","gmv":123456.78}, ...],"ts":1718003600}

6.2 前端渲染与降级

大屏通常运行在浏览器或客户端容器中，长时间运行会出现内存增长。建议：图表实例复用、定时销毁重建、离屏渲染；数据更新采用“差量更新”而非整页重绘。降级策略上，当接口超时或返回异常时，展示“最近一次成功数据 + 时间戳”，而不是空白或报错——这比“看起来实时但其实是错的”更诚实。

本文评述：“数据时间戳”应当成为大屏的标配元素。它让观看者知道数字的新鲜度，也是排障时最直接的线索。很多事故的根因不是链路断了，而是“没人发现它断了”。

七、可观测性与对账：让数字可解释

实时链路的监控应覆盖“链路、数据、业务”三层。链路层看延迟与堆积；数据层看行数、主键重复率、空值率；业务层看指标环比突变。三者缺一不可。

注：阈值为示例值（模拟设定），需结合业务波动率与误报成本标定。

对账是“可解释性”的最后一道防线。建议每日用离线结果与实时结果做比对，差异超过阈值则触发排查。对账维度应覆盖“总量、分渠道、分品类”，避免总量对上但结构错了。本文评述：对账不是财务的专利，而是实时数仓的质量门禁。

八、成本与容量：实时链路的账要算清

实时链路的成本常被低估：Kafka 的存储与网络、Flink 的常驻资源、Doris 的副本与 compaction，都是持续开销。容量规划应回答三个问题：峰值吞吐多少？状态多大？查询并发多高？

一个实用的估算方法是“按峰值 × 安全系数”反推资源，再用压测校正。例如埋点峰值 5 万条/秒、单条 1KB，则入口带宽约 50MB/s；若 Flink 单并行度处理 5000 条/秒，则至少需要 10 个并行度，再留 30% 余量。上述为示例推演（模拟数据），真实取值需以压测为准。

降本手段包括：冷热分层（明细短期保留、聚合长期保留）、压缩算法（ZSTD）、按需扩缩容（大促前扩容、平时缩容）、以及“把不必要实时的指标降级为分钟级”。笔者认为，“实时”是一种成本，不是一种信仰；把资源花在真正影响决策的指标上，才是工程理性。

九、前沿研判与演进路线

从社区演进看，三条趋势值得关注。其一，流批一体：Flink 的批处理能力与湖格式（如 Paimon、Iceberg）结合，正在模糊实时与离线的边界；其二，湖仓融合：Doris 等 MPP 引擎对湖格式的外部表支持增强，使“一份存储、多种计算”更可行；其三，向量化与 C++ 化：执行引擎持续优化，点查与聚合的性价比在提升。

本文评述：这些趋势的共同指向是“降低链路条数、减少数据搬运”。但笔者要泼一盆冷水：新技术不会自动解决口径与治理问题。无论架构如何演进，“指标定义、血缘追踪、对账机制”仍是不可替代的基本功。对多数团队而言，先把现有链路做稳、做可观测，比追逐新组件更有价值。

十、落地路线图与排障清单

10.1 分阶段落地步骤

1. 第 1–2 周：口径冻结。与业务确认 5–8 个核心指标，输出指标字典（定义、维度、时间语义、负责人）。
2. 第 3–4 周：链路打通。接入 1 条 CDC + 1 条埋点流，跑通 Kafka→Flink→Doris，验证端到端延迟与 Exactly-Once。
3. 第 5–6 周：大屏 MVP。实现首屏聚合接口与增量接口，加入数据时间戳与降级展示。
4. 第 7–8 周：可观测与对账。补齐三层监控、日对账任务与告警通道。
5. 第 9–10 周：压测与演练。模拟峰值流量、Kafka 故障、Doris BE 宕机，验证降级与恢复。
6. 持续：成本治理。按月复盘存储与计算开销，清理低价值指标与冗余 MV。

10.2 排障速查表

10.3 拓展学习资源

• Apache Flink 官方文档（Exactly-Once、Watermark、Checkpoint）：nightlies.apache.org/flink
• Apache Kafka 官方文档（分区与副本、消费者组）：kafka.apache.org/documentation
• Apache Doris 官方文档（表模型、物化视图）：doris.apache.org/docs
• Flink CDC 项目文档：ververica.github.io/flink-cdc-connectors
• Flink Forward 与 Doris Summit 公开演讲视频（可在其官方频道检索）

参考文献与资料

本文在写作中参考了流处理、分布式存储与实时数仓相关公开文献与官方文档，累计参考 60 余篇（含官方文档、会议论文与工程博客），其中近三年（2022–2024）资料占比超过 50%。以下列出主要参考文献 9 篇，供进一步研读；引用时请以原始文献为准。

1. Carbone P, Katsifodimos A, Ewen S, et al. Apache Flink: Stream and Batch Processing in a Single Engine. IEEE Data Engineering Bulletin, 2015.
2. Akidau T, Chernyak S, Lax R, et al. The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing. PVLDB, 2015.
3. Kreps J, Narkhede N, Rao J. Kafka: a Distributed Messaging System for Log Processing. NetDB Workshop, 2011.
4. Apache Flink Documentation. Checkpointing, Watermarks, State Backends. 2024. https://nightlies.apache.org/flink/flink-docs-stable/
5. Apache Doris Documentation. Data Model, Materialized View, Best Practices. 2024. https://doris.apache.org/docs/
6. Apache Kafka Documentation. Design, Implementation, Consumer Group Protocol. 2024. https://kafka.apache.org/documentation/
7. Flink CDC Connectors Documentation. MySQL CDC and Exactly-Once Semantics. 2023. https://ververica.github.io/flink-cdc-connectors/
8. Kleppmann M. Designing Data-Intensive Applications. O'Reilly Media, 2017.
9. Doris Summit / Flink Forward 公开技术演讲资料（2022–2024），涉及实时数仓实践与湖仓融合主题。

关于数据集说明：本文未使用特定公开数据集进行实验，文中出现的吞吐、延迟、阈值等数值为工程经验区间或模拟推演值，已在相应位置标注；如需复现，请以自身业务数据与压测结果为准。