企业官网建设流程全解析

上一篇把离线链路和数仓分层整体讲了：从业务库同步到ODS、离线清洗到DWD、再聚合到DWS和ADS，最后落到报表和BI。这一篇我会把实时链路单独拎出来展开，重点讲Flink在电商实时数仓里怎么落地，包括分层设计、核心SQL写法和生产环境里的踩坑经验。内容是围绕一套模拟电商项目X的实时链路来写的，数据量级在日均订单2500万、峰值QPS约8000的规模。

如果你正在做实时数仓相关的项目，或者正在准备大数据方向的工程面试，想把Flink这部分聊得不像背八股，那这篇会比较适合你。我会尽量把“为什么这么设计”也讲透，而不只是贴一堆配置。

1. 实时数仓的整体链路设计：业务需求、技术选型与分层边界

先说结论：实时数仓不是把离线数仓的SQL直接跑在Flink上就完了。离线链路可以容忍小时级的延迟，但实时链路从数据接入的第一秒开始，每个环节都在影响最终指标的质量。电商场景下，业务方要的不是“你今天卖了多少钱”，而是“现在这一刻卖了多少钱、哪个商品正在爆、库存还能撑多久”。

1.1 业务需求怎么翻译成实时链路

电商的实时需求通常可以归成四类：

• 大促实时盯盘：GMV、订单量、支付金额，按分钟刷新，大屏展示
• 实时转化漏斗：曝光→点击→加购→下单→支付，每一层的转化率
• 实时风控与业务预警：退款率异常、库存超卖、物流积压等
• 实时用户画像：用户正在看什么、加购了什么、离下单还差几步

这四类需求对延迟的敏感度不一样。大屏可以容忍1分钟延迟，但转化漏斗最好30秒内看到结果，风控预警则需要秒级响应。很多项目犯的第一个错误，就是试图用一套实时Pipeline把全部需求都包进来，最后导致链路重量级、延迟反而下不去。

我比较推荐的做法是按指标倒推链路，先把指标对延迟和数据来源的要求列清楚，再决定哪些走实时计算，哪些保留离线计算。下面是我在模拟项目X中整理的对照表，也可以当成一个通用的需求拆分起点：

实际执行的时候，我把实时需求收敛成两条主链路：一条是订单交易链路（订单→支付→退款），一条是用户行为链路（曝光→点击→加购→下单）。两条链路在DWD层按主键关联成宽表，再往上走各自的聚合逻辑。这样既不至于把Flink作业做成一个巨型拓扑，也能保证每条链路清晰可排查。

1.2 各层职责与批流一体取舍

实时数仓的分层逻辑和离线一致，都是ODS→DWD→DWS→ADS，但每一层在实时链路里的具体职责并不一样。

• ODS层：在Flink里一般直接消费Kafka的原始Topic。我建议这一层不要做任何解析清洗，统一以原始JSON字符串落Kafka，最多加一个“到达时间”的系统字段。原因有两个：一是解析逻辑可能随时变更（比如新加字段、字段类型变化），放太早会导致历史数据无法回溯；二是ODS层需要承担一定的缓冲作用，如果DWD层逻辑出Bug，ODS还能保留原始事件用于排查和回放。
• DWD层：实时明细层，做数据的清理、维表补全、双流Join和主键去重。这是Flink作业里最复杂的一层，也是状态最大的地方。订单流要和支付流做Interval Join，行为日志要和商品维表做Lookup Join，还要保证同一个订单只输出一条明细。
• DWS层：按业务主题做轻度聚合，比如订单主题按“订单维度”汇总下单金额，支付主题按“支付维度”汇总支付金额，行为主题按“用户+商品”维度汇总点击次数。DWS的核心目标是为上层提供可复用的中间聚合结果，避免上层每个指标都从头跑一遍明细。
• ADS层：直接面向业务应用，比如大屏指标服务、BI报表接口、实时预警规则引擎。这一层一般通过Flink把结果写入Doris或StarRocks这类OLAP引擎，用SQL查最终结果。

批流一体的取舍值得专门说一句。很多公司会用一套Flink SQL同时跑批和流，但我建议实时链路的SQL单独维护，不要去硬凑“同一套SQL”的理想化目标。因为离线批处理可以对任意时间范围做回溯，而实时流处理只能基于当前状态和窗口计算，两者的Watermark、去重和维表关联策略差异很大。硬凑只会让逻辑变复杂，反而丢掉了流处理本身“实时、低延迟”的优势。

2. Flink SQL核心业务的落地细节：从ODS接入到指标产出

模拟项目X里，实时数仓的SQL 90%用的是Flink SQL，只有少量需要精确状态管理的逻辑用了DataStream API。Flink SQL的优点是上手快、维护成本低、和离线SQL的表达习惯接近，团队容易衔接。但SQL写起来简单不代表没有坑，这一章讲落地的核心细节。

2.1 建表与Kafka接入的坑：物理分区、Schema演进、事件时间

先看ODS层建表：

CREATE TABLE kafka_order_ods ( `event_time` TIMESTAMP(3) METADATA FROM 'timestamp', `order_id` BIGINT, `user_id` BIGINT, `item_id` BIGINT, `amount` DECIMAL(10, 2), `status` STRING, `pt` AS PROCTIME(), `et` AS TO_TIMESTAMP(FROM_UNIXTIME(event_time)), WATERMARK FOR et AS et - INTERVAL '5' SECOND ) WITH ( 'connector' = 'kafka', 'topic' = 'ods_order_event', 'properties.bootstrap.servers' = 'kafka-1:9092,kafka-2:9092', 'properties.group.id' = 'dwd_order_group', 'format' = 'json', 'scan.startup.mode' = 'group-offsets' );

ODS阶段只做最原始的字段映射，不解析嵌套JSON，不拆宽表。我见过很多团队在这里一开始就做复杂解析，结果上游埋点加了一个字段，Flink作业就反序列化报错，整条链路重启。正确做法是先把原始消息完整保存，解析放到DWD层。

Kafka接入需要重点确认三个点：

1. 物理分区数决定Source并行度上限。Kafka Source并行度超过分区数没有意义，多余的并发只会空转。模拟项目X里订单Topic分区数设置为24，Source并行度就是24。
2. Schema演进要预留余地。上游新增字段时，Flink SQL表定义必须同步新增字段。我建议在ODS表里额外加一个raw_data STRING字段保存原始报文，即使某些字段解析失败也能从raw_data回补。
3. WATERMARK声明要依赖Kafka消息自带的时间戳，不要用处理时间。用处理时间做窗口会导致上游网络抖动时窗口数据大面积漂移，大促高峰期尤其明显。模拟项目X里的WATERMARK是et - INTERVAL '5' SECOND，容忍5秒乱序，实际效果比较稳定。

关于接入这批事件，还有一点要注意：group-offsets启动模式。作业第一次启动时，如果Kafka Topic里已经有积压数据，默认会从最新的offset开始消费，导致丢数据。正确的启动方式分场景：如果是首次上线，建议用scan.startup.mode' = 'earliest-offset'从最早开始；如果是重启恢复，用group-offsets配合Checkpoint状态恢复。

2.2 DWD层实时明细宽表：维表关联与Interval Join

DWD层是实时数仓里最典型的“状态密集型”场景。模拟项目X里有两个核心宽表：订单支付宽表和用户行为宽表。订单支付宽表把订单流和支付流关联成一条完整交易链路，行为宽表把埋点日志补上商品维度信息。

先看维表Lookup Join的写法：

CREATE TABLE dim_item ( item_id BIGINT PRIMARY KEY NOT ENFORCED, item_name STRING, category_id BIGINT, category_name STRING, price DECIMAL(10, 2), status STRING ) WITH ( 'connector' = 'jdbc', 'url' = 'jdbc:mysql://dim-server:3306/dim_db', 'table-name' = 'dim_item', 'lookup.cache.max-rows' = '20000', 'lookup.cache.ttl' = '1h', 'lookup.max-retries' = '3' ); CREATE VIEW dwd_order_detail AS SELECT o.order_id, o.user_id, o.item_id, i.item_name, i.category_name, o.amount, o.status, p.pay_time, p.pay_amount FROM kafka_order_ods AS o LEFT JOIN dim_item FOR SYSTEM_TIME AS OF o.et AS i ON o.item_id = i.item_id LEFT JOIN kafka_pay_ods FOR SYSTEM_TIME AS OF o.et AS p ON o.order_id = p.order_id AND p.et BETWEEN o.et - INTERVAL '15' MINUTE AND o.et + INTERVAL '5' SECOND;

这两个细节是实践中最容易出问题的：

维表缓存的坑。Lookup Join不加缓存时，每条订单都要实时去查一次MySQL，高峰期会把维表库的连接打满。加了lookup.cache.max-rows和lookup.cache.ttl后，热数据直接走本地缓存，维表库压力大幅下降。但缓存也意味着维表数据更新不会立刻反映到实时结果里，如果商品价格改了，最长要等一个TTL周期才能生效。电商场景里价格变动很敏感，我最终把TTL调成了5到10分钟，扛住了峰值QPS，同时又能接受价格延迟。

Interval Join时间窗口的语义。订单流和支付流的关联窗口设置为15分钟，是因为电商的支付通常在下单后15分钟内完成，超过这个时间的订单需要转到离线链路兜底。窗口太小会丢数据，窗口太大会让状态无限膨胀。所以定窗口之前一定要拉着业务方确认“支付超过XX分钟就不算实时关联”。另外，BETWEEN ... AND ...里的时间边界直接影响乱序数据的容忍度，右边界取正值相当于允许支付流稍早于订单流到达，这在多系统业务里很常见。

再说行为宽表的主键去重。用户点击事件可能因为埋点重试、网络抖动等原因重复上报，DWD层需要按“用户+行为类型+目标ID+事件时间”做去重：

CREATE VIEW dwd_user_behavior AS SELECT user_id, item_id, behavior_type, et, ROW_NUMBER() OVER (PARTITIONED BY user_id, item_id, behavior_type, et) AS rn FROM kafka_behavior_ods;

实际实现一般用ROW_NUMBER() OVER (PARTITION BY ... ORDER BY et)配合WHERE rn = 1来实现保留第一条。在Flink SQL里这需要维护一个状态来记录已见过的KEY，如果不去重，后续DWS层做PV计算会整体偏大。模拟项目X中行为去重状态是按天设置TTL的，避免用户行为数据长期累积撑爆RocksDB。

2.3 DWS层聚合与去重：从ETL聚合到分钟级窗口

DWS层主要做两类操作：窗口聚合和UV去重。

窗口聚合的典型写法：

CREATE TABLE dws_gmv_1min ( window_start TIMESTAMP(3), window_end TIMESTAMP(3), gmv_amount DECIMAL(14, 2), order_cnt BIGINT, PRIMARY KEY (window_start, window_end) NOT ENFORCED ) WITH ( 'connector' = 'doris', 'fenodes' = 'doris-fe:8030', 'table.identifier' = 'dws.dws_gmv_1min', 'sink.label-prefix' = 'dws_gmv_1min', 'sink.properties.format' = 'json', 'sink.properties.read_json_by_line' = 'true' ); INSERT INTO dws_gmv_1min SELECT TUMBLE_START(et, INTERVAL '1' MINUTE) AS window_start, TUMBLE_END(et, INTERVAL '1' MINUTE) AS window_end, SUM(pay_amount) AS gmv_amount, COUNT(DISTINCT order_id) AS order_cnt FROM dwd_order_detail WHERE status = 'PAID' GROUP BY TUMBLE(et, INTERVAL '1' MINUTE);

这里必须提醒一个新手常犯的错误：不要把窗口结果直接留给下游自己算去重，而是要把窗口的start和end字段明确物化。如果不物化窗口边界，Doris里的数据只有聚合值，一旦要回溯“10点到11点之间的GMV变化”，就只能靠多表拼接，非常痛苦。

UV去重是DWS层的另一个难点。电商的指标里，UV天然要求精确去重，但精确去重在流式场景里开销很大。Flink SQL实现精确UV常用COUNT(DISTINCT user_id)，在数据量不大时可接受；一旦user_id基数超过千万级，状态会变得非常大，Checkpoint时间也会跟着恶化。

模拟项目X的处理策略分了两档：

• 离线报表口径：精确UV，由离线链路用Bitmap算好，实时链路不碰
• 实时大屏口径：分钟级聚合用近似去重APPROX_COUNT_DISTINCT(user_id)，允许误差在2%以内，但性能高一个数量级

约定好口径之后，实时和离线对不上账的问题就减少了大部分。业务方如果发现大屏跟日报对不上，多半是UV口径差异造成的，不需要改代码，直接对齐口径就行。

3. 一致性、状态与恢复：实时链路的生产命门

很多Flink项目死在“SQL写好了，一上生产就各种状态异常”。实时链路最怕的不是慢，而是状态丢、数据重、恢复不了。这一章重点讲Checkpoint、状态后端和重启策略，这些配置看起来不起眼，却决定了链路到底能不能24小时稳定跑。

3.1 Checkpoint与状态后端选型

模拟项目X的状态后端用的是RocksDB，不是Heap状态后端。原因很直接：DWD层要维护订单、支付、行为去重三种大状态，加入维表缓存之后单TaskManager的堆内存根本放不下。RocksDB把状态落在磁盘，通过内存做Block Cache，虽然单次访问比堆内对象稍慢，但容量上限高很多，GC压力也小。

配套的Checkpoint配置如下：

execution.checkpointing.interval: 60000ms execution.checkpointing.timeout: 300000ms execution.checkpointing.min-pause: 30000ms execution.checkpointing.externalized-checkpoint-retention: RETAIN_ON_CANCELLATION state.backend.type: rocksdb state.backend.incremental: true

几个参数的经验值说明一下：

• checkpoint.interval设为60秒，是流式作业里比较平衡的选择。太频繁会导致状态后端频繁刷盘、影响吞吐；太稀疏则最多可能丢60秒的数据，实时指标延迟变高。
• min-pause设成30秒，保证两次Checkpoint之间至少有30秒的间隔，避免上一个Checkpoint还没完成，下一个又启动，导致资源竞争。
• RETAIN_ON_CANCELLATION是必须开的。这样即使作业因为业务变更被手动停止，Checkpoint也会保留，后续可以从停止点恢复，不用全量重跑。

3.2 重启策略与数据不丢不重

重启策略是实时链路稳定性的另一根支柱。Flink默认无限重启会把问题作业卡死在重启循环里，所以模拟项目X采用的是“固定延迟+最大尝试次数”：

restart-strategy.type: fixed-delay restart-strategy.attempts: 10 restart-strategy.delay: 10s

配合EXACTLY_ONCE的端到端一致性设置，数据可达“不丢不重”。Flink作业内部的精确一次需要以下条件同时满足：

• Source端使用Kafka的transactional.id机制（Flink SQL的Kafka连接器默认支持）
• 使用pipeline.end-to-end.consistent语义
• Sink端支持事务（Kafka Sink、Doris Stream Load配合label机制）

但有一点必须讲清楚：业务真正要求的“准确一次”往往不取决于Flink，而取决于下游的幂等能力。如果Sink只写了UPSERT没有唯一键，Flink重启后补发数据就会产生重复行。模拟项目X里Doris表都设置了唯一键（如order_id或window_start + window_end），这样Flink重放数据时，下游直接覆盖旧值，而不是新增一行。先把下游幂等这件事情做到，再谈EXACTLY_ONCE才有意义。

有一种业务场景可以接受 AT_LEAST_ONCE：指标看板类的数据，因为上游去重逻辑本身会处理重复，或者指标本身允许短时波动。这种时候没必要为了“精确一次”的合规性把整个链路的性能拖下来。

3.3 Savepoint恢复与版本升级

实时数仓没有不出问题的作业。模拟项目X上线三个月内，DWD层升级过两次SQL逻辑，都依赖Savepoint做平滑恢复。

升级流程我一般这样走：

1. 先停止作业，触发一次最终Checkpoint，并记录Checkpoint路径
2. 修改SQL并重新提交，指定-s参数指向保存的Checkpoint
3. 作业恢复后，用对比工具核对Kafka某个窗口内的输出结果是否和预期一致

这里最常见的坑是：修改了SQL逻辑后，状态结构对不上，导致恢复失败。比如原来用ROW_NUMBER去重，后来改成COUNT(DISTINCT)，状态里的Key结构完全不同，恢复时就会报“state migration failure”。所以任何涉及状态结构的变更，都需要评估是否需要丢状态全量重建。模拟项目X给了个缓冲方案：升级期间让离线链路同步补数，实时链路重建状态期间，大屏切到离线数据源，等Flink追平后再切回实时。

4. 性能调优与资源预估：并发度、反压与参数治理

状态和恢复解决了“链路活着”的问题，性能调优解决的是“链路跑得动”的问题。电商大促的流量是日常的5到10倍，如果不在平时就把调优参数踩实，大促时只会一崩再崩。

4.1 并发度推导与Kafka分区对齐

作业的并发度不能拍脑袋定。模拟项目X里订单Topic是24个分区，所以Source并行度定为24，其他算子的并行度通过统计上游QPS和单并行度处理能力来推算。

可以参考这个简单的推导过程：

• 订单流峰值QPS约8000，单并行度的Flink SQL窗口聚合实测能处理1500~2000条/秒
• 所以DWS层聚合并行度至少需要 8000 / 1500 ≈ 6，考虑高峰余量直接给到8
• 维表Lookup Join因为有缓存，单并行度能处理3000条/秒，给4并行度足够
• 最终作业并行度组合：Source 24、DWD 12、DWS 8、Sink 8

并行度确定后，还要检查Keyed By的分区是否均匀。如果订单ID的哈希分布本身就倾斜（比如某个商品大促爆量），那么无论怎么调并行度，那个Key所在的Task依然会成为瓶颈。模拟项目X里遇到过爆款商品订单集中在同一个用户分区的情况，解决方案是拆分粒度：订单维度聚合用order_id做Key，用户维度聚合用user_id做Key，避免所有聚合都挤在同一个Key上。

4.2 定位反压并解决

反压是实时链路最常见的性能问题，表现为：Source端数据积压、Kafka Lag上升、大屏指标分钟级延迟。定位反压的方法就三个字：看UI。

Flink Web UI的每个Task都有一个“BackPressure”状态，如果某个算子持续处于HIGH状态，说明它处理不过来。在模拟项目X里，我遇到过两次典型反压：

第一次是DWD层的维表关联。订单详情的维表缓存没有生效，每条订单都实时访问MySQL，导致Task线程大量阻塞在等待IO上。解决方法是加大lookup.cache.max-rows并设置合理TTL，把维表查询从“每次网络IO”降为“内存查缓存”，处理能力立刻翻倍。

第二次是Doris Sink的写入瓶颈。Flink的结果批次太大了，Doris Stream Load压力过高，导致Sink端频繁重试。解决办法是把Sink端并发从8降到4，同时调整sink.buffer-count和sink.buffer-size参数，让批量的“攒批”更平滑，高峰期不再冲垮Doris。

4.3 内存参数与状态清理

Flink的内存参数属于“平时不调没事，一调就是大事”。模拟项目X里经验比较实用的几个参数：

taskmanager.memory.process.size: 4096m taskmanager.memory.managed.fraction: 0.4 state.ttl: 1d table.exec.state.ttl: 1h

taskmanager.memory.managed.fraction=0.4表示RocksDB可以使用的堆内托管内存占比40%，其余留给网络缓冲和用户代码。这个值太高会让JVM堆紧张，太低会让RocksDB频繁刷磁盘，这两个方向都会拖垮性能。

状态TTL是最容易被忽视的调优点。如果订单支付关联只关心15分钟内的流，那状态里就不该保留24小时前的数据。给状态设置合适的TTL，可以让RocksDB的存储量保持在一个稳定水平，Checkpoint时间也会显著下降。table.exec.state.ttl是Flink SQL里统一的表状态保留时间，和创建Table时的WITH参数配合使用。注意设置TTL不等于数据立即删除，Flink是惰性清理，所以预留一天左右的时间缓冲是合理的。

5. 实时链路踩坑实录：几个值得复盘的生产问题

这里把模拟项目X上线到稳定运行过程中，最值得记录的四个问题整理出来。每个问题都按“现象→定位→修复”的链路写，看的时候可以把自己代入现场，真实排查时思路会更快。

5.1 维表关联缓存失效：一次参数引发的“事故”

这个案例值得单独展开。当时的现象是：链路正常跑了两周，突然某天下午DWD层反压，Kafka Lag持续上涨。刚开始我以为是流量高峰，但过了半小时还没恢复，才决定认真排查。

Flink UI里Lookup Join算子的反压状态是HIGH。我盯着算子的“Records In”和“Records Out”对比，发现输入和输出量差距很大，说明大量消息阻塞在关联逻辑里。进一步看Task线程栈，几乎全部卡在MySQL JDBC查询上。

定位到原因后，发现是维表缓存的TTL参数配得太短（只有10秒）。平时流量低影响不大，但那天某个商品突然上了活动页，订单量暴涨，10秒短TTL导致缓存命中率骤降，大量请求穿透到MySQL，把维表库连接打满了。

修复方案就是把TTL调成10分钟，并把lookup.max-retries调到3，保证偶发查询失败时不会直接丢消息。调整之后当天晚上链路就恢复正常。

这个案例的启示是：维表缓存参数要结合上游的峰值QPS和维表更新频率一起设计，不能只看MySQL本身能不能扛住，还要算一个“缓存命中率”的账。如果高峰期命中率低于90%，链路迟早出问题。

5.2 水位线设计不当：大屏数据“漂移”的教训

水位线问题是实时计算里最难排查的一类Bug，因为现象很隐蔽：窗口不会立刻不工作，而是偶尔出现几分钟没数据，然后又突然涌入大量数据。

模拟项目X里大屏GMV对账时发现，10点整到10点01分这个窗口只算了5秒的数据。原因是Watermark设置过小，上游Kafka里消息自带的时间戳偶尔出现明显延迟（个别消息晚到30秒以上），窗口提前触发了，后面到达的迟到数据被丢掉。

这类问题的标准解法有三个阶段：

• 第一阶段：把Watermark的乱序容忍时间从固定的5秒改成INTERVAL '15' SECOND，保证大多数迟到数据能落入正确窗口
• 第二阶段：开启ALLOWED LATENESS，让窗口在触发后保留一段时间的迟到数据修正窗口结果
• 第三阶段：在结果表设置唯一键，让修正后的窗口重新写入覆盖旧值

Flink SQL里WATERMARK是窗口触发的重要依据，真正合适的乱序容忍值需要根据历史数据算出99%分位的迟到时间。模拟项目X是在跑了两周后，用Kafka消息的时间戳分布算出来的——99%的消息在10秒内到达，所以容忍10秒是性价比最高的选择，既不会过于延迟窗口触发，也不会大量丢失迟到数据。

5.3 大促扩容前必须做的三件事

大促前扩容是实时链路运营里最有仪式感的事，但也最容易踩雷。模拟项目X在第一次大促前做过一次扩容，结果流量上来之后反而更卡了，后来复盘才知道问题出在三个细节：

1. 增加并行度不是越多越好，要同步确认Kafka分区数。Source并行度如果超过分区数，多余的Task什么也不干，白白浪费资源。大促前如果要扩Source，先把Topic分区数扩上去。
2. Sink端也要一起扩，不然上游处理快了，结果全堵在Sink层。
3. Checkpoint间隔在大促期间要适当拉长，从60秒调整到120秒，降低状态后端的刷盘频次。大促本身数据量大，状态变化快，频繁Checkpoint会让吞吐量折损20%以上。

这个思路后来被我整理成了一张大促前的检查清单，每次大促前过一遍，基本能避免七成以上的实时链路事故。

5.4 实时链路的延迟监控：谁的味道最准

最后分享一个运维层面容易被忽略的点：实时链路的“健康度”不是说作业运行不报错就是健康。Flink作业哪怕在正常RUNNING状态，也可能存在OOM隐患、状态无限膨胀、维表缓存失效等各种问题。

模拟项目X上线后，我加了一层“指标自监控”：

• 用Flink作业输出自己的当前Kafka Lag到监控系统
• 用累计值对比每个窗口的输出量，如果某个窗口没数据或者数据量异常，立即触发告警
• 每个小时跑一次结果表的行数统计，和离线链路的对账结果做对比，差异超过阈值就标记为“数据质量异常”

这套自监控上线后，至少提前发现过两次数据漂移问题：一次是维表价格缓存过期导致GMV少算，一次是Windows窗口时间边界写错导致部分订单没进窗口。实时链路的稳定性不是靠“祈祷不出事”换来的，而是靠监控指标把每个异常都暴露在明面上。

写在最后

如果你现在也准备搭一套实时数仓，我的建议是先从最核心的一条链路开始，比如订单支付链路，别一上来就把用户行为、营销、库存全接进来。链路越短，排查问题越简单，等你在一条链路上把Checkpoint、状态、维表关联、Sink幂等这些基本功打磨透了，再复制到其他链路上会顺手很多。

模拟项目X实时链路我前前后后改了大概三轮，第一轮把所有业务需求都塞进一张超宽表，第二轮拆成订单和行为两条链路，第三轮才真正把状态治理和性能调优做完整。回头看，最值的投入反而是那些看起来不讨好的基础设施配置——状态TTL、Checkpoint策略、Sink幂等键、监控告警，它们不会在演示Demo里闪光，但在生产环境的每一个深夜，都是救命的东西。

后续如果要扩展，可以从两个方向入手：一是把DataStream API用的场景再拆细一点，比如精准的UV去重和复杂的CEP风控规则用DataStream会更顺手；二是把实时数仓和数据湖打通，用Flink把明细数据持续写入湖存储，让实时和离线共用一套底层数据。这些我后面找时间再单独写。