Flink流批一体实战：从架构设计到SQL开发与运维踩坑全记录

先聊点实在的。这两年数据架构圈里，“流批一体”这四个字基本成了必聊话题，而聊到落地，绕不开的就是Flink。我自己从最早的Spark Streaming加Hive数仓两套链路并行，到后来逐步把核心业务切到Flink这套统一引擎上，最大的感受是：流批一体不是把两套系统放在一个平台上跑，而是让一套API、一套SQL、一套元数据同时覆盖实时和离线场景，真正减少重复开发和数据口径不一致的问题。这篇文章不会跟你扯太深的理论，我会从实际落地角度，把流批一体的设计思路、Flink核心选型理由、环境搭建、SQL实战、CDC接入、性能调优和踩坑记录一次讲清楚，适合正在规划实时数仓或准备统一批流链路的同学参考。

1. 流批一体的核心逻辑：为什么要统一数据处理流程

1.1 批流分离的老路，到底痛在哪里

早些年做数据平台，主流做法是批流分离：离线走Hive或者Spark批处理，实时走Spark Streaming或者Storm，两边各建各的任务、各写各的逻辑。表面上各干各的互不打扰，真正跑起来全是问题。

首先是重复开发。同一个统计指标，比如“今日成交额”，离线要写一遍SQL跑T+1，实时要用DataStream写一套窗口聚合逻辑，两套代码逻辑完全不一样，数据口径稍微没对齐，早上实时大屏说成交额是1.2亿，下午离线报表出的是1.15亿，业务侧直接来质问数据到底准不准。这种口径对不齐的问题，在批流分离时代几乎是每天的日常。

其次是运维成本翻倍。两套引擎意味着两套集群、两套监控、两套调度，资源利用率还不一定高。实时任务高峰期忙死，离线任务凌晨忙死，但彼此没法互相借资源。加上两套技术栈对团队要求也不一样，会Spark的不一定会Structured Streaming的状态管理，会实时的不一定懂离线分区表的生命周期管理，团队协同效率很低。

最后是数据链路易碎。一条数据从业务库到Kafka，再进实时计算做指标，随后落到Hive做离线分析，中间每一步都要单独开发和维护。如果实时链路挂了，影响的是当天实时报表；离线链路挂了，影响的是次日数据产出。出问题的粒度是任务级别，没法做到统一治理。

1.2 Flink统一流批的技术底气在哪里

那为什么大家最终把目光聚焦在Flink上？简单说，Flink从架构上就为解决批流一体设计的，而不是事后打补丁。

第一，Flink把批处理看作流处理的特殊情况。传统观点认为批和流是两种完全不同的处理模式，Flink换了思路：既然有界数据集本质上就是一种“有限流”，那为什么不用同一套引擎来处理？它底层用同一个Runtime（分布式流处理引擎）来调度和执行任务，只是批作业在输入结束时自动触发全量结果的生成，而流作业是持续输出增量结果。这样，执行引擎是同一套，状态管理、容错机制、资源调度的底层逻辑完全一致。

第二，Flink提供了统一的API体系。早期Flink只支持DataStream API，后来推出Table API和Flink SQL，再往后Flink 1.12版本开始在SQL层面真正实现了流批一体。同一个CREATE TABLE语法，既可以声明一个Kafka主题作为流式Source，也可以声明一个Hive表作为批式Source，底层的连接器自动感知数据是有界还是无界，你写的SELECT查询大部分场景下不需要区分流和批。

第三，Flink的容错机制天然统一。流处理依赖Checkpoint做状态快照和故障恢复，批处理也能用同样的Checkpoint机制，跑批中间节点挂掉了不能从零开始，而是从最近一次Checkpoint恢复，这比传统离线任务宕机重新跑全量要高效得多。这也是我觉得Flink能统一批流最关键的技术细节。

2. 流批一体架构设计与Flink选型解析

2.1 整体架构蓝图：一套引擎如何衔接数仓全链路

我这里画的架构不是凭空设计，而是来源于一套已经稳定运行了一年多的实时数仓项目。整体分五层：

存储与采集层：业务数据通过Flink CDC实时捕获MySQL或PostgreSQL的变更记录，发给Kafka。离线部分的数据仍然保留在Hive或数据湖（Iceberg）中，但这种保留不是再开发一套离线加工逻辑，而是用同一份Flink SQL作业，切换Source类型去读Hive表，输出结果写回Hive表。

计算层：核心计算引擎就是Flink，部署模式用的是Flink on YARN，通过一个统一的SQL任务平台提交作业。流作业和批作业都提交到同一套Flink集群，但要给流作业和批作业划分不同的资源队列，避免相互影响。

存储服务层：结果数据写到多种目标端，实时指标写Elasticsearch供大屏或搜索查询，明细数据写Kafka供下游系统消费，聚合结果再同步写一份到Hive或Iceberg落地。

服务层：统一通过Flink SQL Gateway或REST API对外提供数据服务，业务方提交一份SQL，把数据从ODS层清洗到DWD层，再从DWD层聚合到ADS层，链路是全透明的。

统一运维层：元数据统一挂在Hive Metastore上，Flink的TableEnvironment统一在这些元数据之上创建表和视图，无论流批作业看到的表结构、字段类型、分区规则都是同一套标准。

这套架构跑起来之后，最大的变化是开发提效。以前实时指标和离线指标要分两个项目维护，现在团队写SQL的时候，参数里指定一下执行模式（流式执行还是批式执行），其余逻辑不用改，少了一大半重复劳动。

2.2 为什么选择Flink而不是Spark Structured Streaming或Kafka Streams

这是必须正面回答的问题，因为不少人一开始会纠结。就我个人的使用体会：

Spark Structured Streaming的流批一体思路和Flink很接近，都用SQL抽象的DataSource和DataSink，但Spark本质上还是微批模型，延迟受批次间隔限制，做不到真正的事件级低延迟。Flink是原生的流处理引擎，严格逐条处理，延迟可以压到毫秒级，而且状态管理、事件时间处理、Watermark机制做得更深。如果你的核心场景是实时风控、实时反欺诈这种吞吐和延迟双敏感场景，Flink的优势非常明显。

Kafka Streams则是主打轻量级流处理，适合处理Kafka内的数据转换和简单聚合，但它没有真正意义上的批处理能力，做不了对Hive表离线离线扫描关联这种活。流批一体场景，Kafka Streams很难担当重任。

Flink胜在“既能流又能批，且共用一套底层”。它既有强大的流处理Runtime，又有完善的Batch执行优化（比如谓词下推、分区裁剪这些批优化器特性），还能对接数据湖体系做流式读写Iceberg，生态里从SQL到Connector再到状态管理都成熟得多。所以从长远平台化角度，我坚定选Flink。

2.3 集群搭建与部署要点：别在第一步留隐患

集群搭建是入门者最容易踩坑的地方，我见到太多同学在本地Standalone模式跑通后就以为万事大吉，到了生产环境立刻暴露问题。这里按我的实践经验整理关键点。

先明确部署模式。生产环境强烈推荐Flink on YARN，因为可以复用已有的Hadoop资源，由YARN统一调度和资源隔离。如果是从零搭建，硬件方面至少准备3台以上节点，8核16G以上配置起步，磁盘最好用SSD，因为Flink在做Checkpoint和状态后端的RocksDB读写时，磁盘性能影响很明显。

版本选择上，除非有特殊原因，尽量选择当前社区稳定且长期维护的版本，比如Flink 1.17或1.18系列。老版本像1.9、1.10虽然网上资料多，但流批一体SQL能力那时还不成熟，很多特性需要自己踩坑，不建议新项目选。同时要注意Flink版本和Hadoop、Hive、Kafka客户端版本的兼容性，官方有兼容性矩阵，提前查好能省很多事。

配置文件里最容易被忽略的是这几个参数：

yaml复制jobmanager.memory.process.size: 2048m
taskmanager.memory.process.size: 4096m
taskmanager.numberOfTaskSlots: 4
parallelism.default: 2
state.backend: rocksdb
state.checkpoints.dir: hdfs:///flink/checkpoints
state.savepoints.dir: hdfs:///flink/savepoints

state.backend用RocksDB是必选项，尤其当状态数据量超过内存可承受范围时，RocksDB可以把状态溢写到磁盘，配合增量Checkpoint机制，是实现大状态稳定运行的关键。Checkpoint目录放HDFS而不是本地磁盘，是为了任务迁移和故障恢复时能够跨节点，因为你永远不知道TaskManager什么时候会挂掉，状态在HDFS上换个节点依然能恢复。

提交一个流批一体SQL测试作业，命令行大致是这样：

bash复制flink run -m yarn-cluster \
  -ys 4 \
  -yjm 2048m \
  -ytm 4096m \
  -d \
  -c org.apache.flink.table.client.SqlClient \
  /opt/flink/lib/flink-sql-client-1.17.2.jar \
  -f /data/sql/test_stream_batch.sql

集群起来之后，我建议先跑一个双Source的验证作业：一个Source读Kafka实时数据，另一个Source读Hive离线表，在同一个SQL里做关联查询，确认两边的数据都能正常读写，再开展后续业务逻辑开发。

3. 核心实操：用Flink SQL统一处理流批数据

3.1 准备一套元数据：让流和批共用同一张表定义

流批一体最核心的工程实现，是让流表、批表共用同一套逻辑表结构。这里强烈建议统一使用Hive Metastore作为元数据中心，Flink在Hive Catalog下创建的所有表，流作业能读，批作业也能读。

我在项目中的典型做法是先在Hive中建好ODS层基础表，然后在Flink里挂载Hive Catalog，接着通过SQL创建Kafka虚拟表，保持字段名、字段类型、分区规则与Hive表完全一致。这段话写出来很简单，实际价值极高：下游做统一加工时，根本不用关心数据是从Kafka流进来的还是从Hive批扫描进来的，Writer的SQL完全可以复用。

建表示例：

sql复制CREATE CATALOG hive_catalog WITH (
  'type' = 'hive',
  'default-database' = 'default',
  'hive-conf-dir' = '/etc/hive/conf'
);

USE CATALOG hive_catalog;

-- 创建一个映射Kafka的实时表
CREATE TABLE kafka_orders (
  order_id BIGINT,
  user_id BIGINT,
  amount DECIMAL(10, 2),
  status STRING,
  ts TIMESTAMP(3),
  WATERMARK FOR ts AS ts - INTERVAL '5' SECOND
) WITH (
  'connector' = 'kafka',
  'topic' = 'ods_orders',
  'properties.bootstrap.servers' = 'kafka-1:9092,kafka-2:9092',
  'properties.group.id' = 'flink-cdc-group',
  'scan.startup.mode' = 'earliest-offset',
  'format' = 'debezium-json'
);

注意Watermark的定义对实时流处理来说不可或缺。上游数据可能会乱序或者延迟到达，有了Watermark，Flink的窗口聚合才能正确等待迟到数据，然后再触发计算，这是实时指标准确性的基础。而如果这张表只是供批作业扫描，Watermark会被忽略，不影响离线读取语义，同一个逻辑表两种执行模式无缝切换，这才叫流批一体。

3.2 实时链路最佳实践：Flink消费Kafka写入Elasticsearch

这是网上被问得最多的场景之一：Kafka进、Flink算、ES出。原因也好理解，大屏展示和搜索类业务都依赖ES的高性能检索能力，而数据变更源头大多在Kafka中流转。

整个SQL实现非常简单，但你需要注意几个连接器参数的坑。以ES连接器为例：

sql复制CREATE TABLE es_sale_stats (
  stat_date STRING,
  category STRING,
  gmv DECIMAL(14, 2),
  cnt BIGINT,
  PRIMARY KEY (stat_date, category) NOT ENFORCED
) WITH (
  'connector' = 'elasticsearch-7',
  'index' = 'sale_stats',
  'hosts' = 'http://es-1:9200,http://es-2:9200',
  'sink.format' = 'json',
  'sink.bulk-flush.max-actions' = '1000',
  'sink.bulk-flush.max-size' = '5mb',
  'sink.bulk-flush.interval' = '2s'
);

ES连接器本身没有事务保证，如果任务失败，可能会存在部分重复写入。当业务对数据准确性要求很高时，我的做法是在写入ES前先在Flink内部做一次基于事件时间的窗口聚合，并开启Checkpoint，配合ES的幂等写入（通过主键ID更新doc）来减轻重复影响，但不能完全消除。想彻底解决，一般是在目标端再做一层根据主键去重的读取逻辑，这在时效性和一致性之间是一个值得权衡的点。

Kafka的消费参数建议把scan.startup.mode设成earliest-offset，尤其是首次同步场景，能从头把历史数据吃完再进实时。如果设成latest-offset，新任务启动瞬间会跳过之前积压的消息，导致指标出现断档，这种线上事故我见过不止一次。

3.3 离线链路统一写法：Flink SQL读Hive再写Hive

离线这块传统上用Hive脚本或者Spark作业来做，现在我们直接用Flink SQL跑批。需要强调的是，Flink批模式下对Hive的读取走的是真正的Batch执行路径，能利用Hive的分区裁剪和谓词下推，不会傻乎乎全表扫描。

一个典型的离线汇总作业，前一天的全量订单在Hive表中按日期分区存储，每天凌晨跑作业统计各品类销售额：

sql复制SET execution.runtime-mode = batch;

INSERT OVERWRITE TABLE hive_catalog.dws.sale_stats_daily
SELECT
  dt,
  category,
  SUM(amount) AS gmv,
  COUNT(1) AS cnt
FROM hive_catalog.dwd.orders_merged
WHERE dt = DATE_FORMAT(CURRENT_TIMESTAMP - INTERVAL '1' DAY, 'yyyy-MM-dd')
GROUP BY dt, category;

CURRENT_TIMESTAMP - INTERVAL '1' DAY这个写法是在调度时间上自动推一天，避免手动传参出错。调度框架到了凌晨自动触发这个SQL作业，输出结果覆盖写入Hive结果表，下游的报表、推荐、数仓应用直接读取这份结果。

批模式下建议把并行度调高，因为离线数据量大，扫描阶段比较吃并行度。但同时要注意目标表的分区数量，如果并行度远大于分区数，会导致小文件碎片化，反而拖慢后续的查询性能。我通常的做法是并行度控制在目标分区数的1到2倍之间，或者直接开启Flink的Hive动态分区写入，让框架自动平衡。

3.4 流批关联的实际场景：实时流与离线维表如何合并

流批一体真正精彩的部分，不是单独跑实时或单独跑批，而是两条链路的交叉使用。比如实时订单流需要带上商品类目的维度信息，类目信息是每天更新的离线表，那就可以在Flink SQL里直接做一个流表关联Hive维表的查询。

早期做法是每次来一条订单都要查一次Hive表，性能极差。后来社区推出了Hive维表关联的优化方案，实际上是把维表加载到Flink的缓存中，本地查询，定期刷新，兼顾实时性和性能。

SQL写法参考：

sql复制CREATE TEMPORARY VIEW order_with_category AS
SELECT
  o.order_id,
  o.user_id,
  o.amount,
  c.category_name
FROM kafka_orders AS o
LEFT JOIN hive_catalog.dim.product_category
  FOR SYSTEM_TIME AS OF o.ts AS c
ON o.product_id = c.product_id;

FOR SYSTEM_TIME AS OF是时态表关联的语法，意思是“在数据事件发生的那个时间点，去关联当时有效的维度记录”。实际用起来，我强烈建议给维表设置lookup缓存，代码实现时就是在维表的WITH参数里加上：

yaml复制'lookup.cache' = 'PARTIAL',
'lookup.max-retries' = '3',
'lookup.partial-cache.max-rows' = '500000',
'lookup.partial-cache.expire-after-access' = '2h'

缓存配置能显著降低访问热点的压力，但注意维度更新后缓存不会立刻感知，会有最多2小时的延迟。如果业务对维度时效性要求是分钟级，就要结合定时刷新或直接把维表数据也走Kafka实时同步，方案需要根据业务自己权衡。

4. Flink CDC实时同步与数据一致性保障

4.1 基于CDAS的思想用CDC打通业务库与数仓管道

Flink CDC是流批一体架构里非常关键的一个组件。它的作用是把数据库的Binlog或WAL日志解析成标准的变更数据流，发送给Flink做实时计算或直接同步到目标端。网上搜“flink cdc”的热度一直很高，原因就是它解决了实时数仓“数据从哪来”的第一公里问题。

我建议CDC的部署思路不要贪图写太多自定义逻辑，而是尽量用SQL方式声明一个Source表，让Flink直接捕获变更记录。比如要同步MySQL的订单表到Kafka中，SQL大致如下：

sql复制CREATE TABLE mysql_orders (
  order_id BIGINT PRIMARY KEY NOT ENFORCED,
  user_id BIGINT,
  amount DECIMAL(10, 2),
  status STRING,
  op_ts TIMESTAMP_LTZ(3) METADATA FROM 'value.source.timestamp'
) WITH (
  'connector' = 'mysql-cdc',
  'hostname' = 'mysql-master',
  'port' = '3306',
  'username' = 'flink_cdc_user',
  'password' = '******',
  'database-name' = 'trade_db',
  'table-name' = 'orders',
  'scan.startup.mode' = 'initial'
);

scan.startup.mode = initial是CDC的经典参数：任务第一次启动时，先把表中的历史全量数据读一遍，然后无缝切入增量Binlog，不需要你手工做历史数据迁移。这个特性特别适合老表数据量大、又不想停业务同步的场景。生产环境要注意，如果业务库本身主从延迟大，Binlog的保留时长短，要提前和DBA对齐，避免全量同步期间Binlog被清理导致增量丢失。

4.2 CDC链路中的数据一致性和幂等性问题

CDC链路里最怕的是数据不丢不重不好控制。Flink通过Checkpoint机制可以做到精确一次（Exactly-once）的状态一致性，但前提是Source端和Sink端都要支持。

以MySQL CDC + Kafka为例，Flink在Checkpoint时会保存当前Binlog的读取位点，任务重启后从这个位点继续消费，这样就保证了数据不丢。但如果Sink端写的目标系统不提供幂等保障，比如直接写普通MySQL表，重复执行时可能出现重复数据。常见的解决方案有两个：

一种是把Sink端改成支持幂等写入的存储，例如Kafka本身按offset记录，天然幂等，可以参考延展的标志：只要消息重复写，下游消费端按主键去重即可。

另一种是Flink提供的两阶段提交（TwoPhaseCommitSinkFunction），典型的像FlinkKafkaProducer，可以做到Kafka到Kafka的精确一次。但两阶段提交对下游支持要求高，不是所有系统都支持，所以架构设计时就要先定义好一致性级别，到底是At-least-once还是Exactly-once，不要把需求搞复杂，没必要的精确一次会引入很大性能开销。

5. 常见问题与排查技巧实录

5.1 Flink JDBC连接器异常排查

网上频繁搜到“flink的jdbc连接器异常”，我这边也在生产里踩过类似问题。最常见的现象是作业偶发失败，日志里出现Communications link failure或者Connection is not available, request timed out。排查思路分三步：

先确认数据库的连接数上限。Flink作业并行度设置太高时，每个子任务都会建独立的JDBC连接，数据库的连接池被瞬间打满，新的连接请求就会超时。这时最简单直接的方法是把并行度降下来，或者在JDBC Sink的WITH参数里显式设置连接池大小：

yaml复制'sink.max-retries' = '3'

再看是否是空闲连接被数据库回收。MySQL默认的wait_timeout通常是8小时，长时间空闲的连接会被服务端断开，但连接池不知道，拿到旧连接时就会报错。解决方案是在Flink的JDBC连接串上加autoReconnect=true和空闲连接校验参数。

最后排查网络问题，确认Flink TaskManager所在的节点到数据库端口的连通性和防火墙规则。这个问题最容易被忽略，因为本地测试正常，一到集群就跑不通，多半就是网络策略没放通。

5.2 Kafka消费与写入ES的稳定性问题

Kafka写入ES这个链路里，最常见的问题是连接器反压和集群OOM。症状表现为作业背压指标持续为红色，Kafka lag不断上涨。用背压监控页面观察，如果某个TaskManager长时间处于High状态，基本可以判断是ES写入性能跟不上。

处理办法我从实践角度排个优先级：先调节ES连接器的批量刷新参数，把bulk-flush.max-actions调大，同时增加flush间隔，让单批次的数据更厚，减少网络往返。其次增加并发，通过调整Sink并行度把写入压力分散。最后检查ES集群自身的分片数量和负载，堆文档写入可能触及ES的写入瓶颈，这时要优化ES索引的mapping和分片策略，比如去掉不需要的索引字段、调整刷新间隔。

还有一个容易被忽略的点：ES的id冲突策略。如果指定的PRIMARY KEY字段没有合理设计，同一主键的多条更新被写入时，ES会反复更新同一文档导致大量IO。建议主键选稳定且唯一的字段组合，不要选会变化的字段。

5.3 状态与Checkpoint异常的处理心态和方法

状态后端用RocksDB之后，常见异常是Checkpoint超时或失败。一开始遇到会慌，觉得任务要挂了。其实Checkpoint失败只要没有超过阈值，Flink不会自动failover任务，只是当前这次快照没成功，下次会继续尝试。

但如果是持续失败，就需要认真排查。我遇到最多的原因是RocksDB的状态目录所在磁盘空间不足。因为状态除了内存，还会在本地磁盘生成SST文件，节点磁盘被打满，状态写入直接失败。排查时先看监控里的本地磁盘使用率，也可以登录节点用df -h确认。

还有一类是Checkpoint大小增长过快导致的超时。这通常意味着状态没有合理清理。写SQL时用了无上限的累积状态，例如不停追加ListAgg或没有设置TTL的聚合，状态就会被无限撑大。解决办法是显式设置State TTL，或者在SQL设计上尽量用窗口限制作用范围。检查日志时如果看到Exception in checkpoint or recovery，先别急着重启，把最近几分钟的Checkpoint历史看一遍，定位状态持续膨胀的算子，再有针对性地调优。

6. 工程化落地与性能优化经验

6.1 工程化代码的组织方式不只是能跑

网上很多人搜“工程化的flink代码”，我的体会是：能跑和能交付之间差着一整套规范。不要上来就写一个大大的DataStream代码嵌几百行逻辑，而要从项目结构上做好拆分。

我的标准做法是采用Maven多模块结构：

• flink-common：存放公共工具类、常量定义、统一异常处理
• flink-sql：存放所有SQL作业脚本，一个业务一个文件，文件头写清楚责任人、业务线、调度周期
• flink-etl：存放需要自定义实现的UDF和连接器逻辑
• flink-job：存放统一作业启动类，通过传入的SQL文件路径驱动不同作业

SQL文件建议用版本控制，配合统一的SQL校验流程。有人会问，Flink SQL写起来太灵活，怎么保证规范？我的答案是建立一套SQL Review规则，比如禁止生产环境使用SELECT *、所有表必须有注释、所有Kafka表必须指定scan.startup.mode、关键指标必须有数据质量校验任务。维护这种规范刚开始会费点时间，但后期维护成本大幅下降。

6.2 常见性能问题与参数调优实测

流批一体项目里，最容易出现性能问题的几个点，我整理成一张表，方便你直接对照排查。

还有一点是我踩坑后总结的：并行度不是越大越好。并行度增加会带来网络Shuffle开销、状态存储开销、检查点体积膨胀，有时候并行度翻倍性能反而下降。最优并行度要靠压测来确定，我一般从默认并行度出发，逐步增加观察吞吐和延迟曲线，取拐点作为推荐值。

6.3 Flink面试中流批一体常问的几个点

写这一节的原因是很多读者反馈，学了流批一体之后找工作面试经常被问这块。我把高频问题整理一下，既是知识梳理，也是帮你验证自己是不是真的理解了这个架构。

第一个问题：Flink的流批一体和Spark的Structured Streaming有什么区别？回答要点是从架构模型、延迟、状态管理、批优化能力几个维度对比，重点是Flink原生流处理Runtime，而不是微批模拟。

第二个问题：Flink SQL如何判断一个作业是流作业还是批作业？回答要点是execution.runtime-mode参数，streaming模式或batch模式，底层通过Source是否有限流自动切换。

第三个问题：解释一下Watermark在事件时间处理中的作用。回答要落在乱序处理和迟到数据触发上，说明Watermark是衡量事件时间推进的机制，而不是简单的延迟时间。

第四个问题：CDC同步过程中如何处理DDL变更？这个问题比较深，需要说明Flink CDC会捕获结构变更事件，常见做法是通过schema evolution机制处理，或者通过重启任务重新拉取最新schema。这块没有标准答案，但能体现你处理实际问题的思路。

最后分享一点个人体会

如果让我给一个正在准备做流批一体的团队一句忠告，我想说：别执着于一上来就把所有场景切到Flink，而是挑一两个口径冲突最严重、开发重复度最高的链路去做示范改造。我们当时选了“交易订单实时/离线指标统一”这条链作为切入，从需求梳理、元数据统一到SQL开发上线，前后将近一个月跑通，证明方案可行后，再把其他业务线逐步迁过来，节奏反而比大干快上要稳得多。另外，流批一体不是说完全不要数仓分层了，恰恰相反，ODS、DWD、DWS、ADS这套分层在流批一体里依然成立，只是它不再分实时和离线两套体系，而是在一层之内由Flink统一加工。想清楚这一点，你后续的建模和开发会顺畅很多。