1. Flink初识：流处理与批处理对比、核心特性、应用场景与架构概览
大家好，我是你们这门课的老朋友。做数据同步这些年，我踩过不少坑，也积累了一些心得。今天咱们就从最基础的地方聊起——Flink到底是什么？它凭什么能加速数据同步？
说实话，我第一次接触Flink是在2016年。那时候公司要做实时数仓，选型时在Spark Streaming和Flink之间纠结了很久。后来我选了Flink，原因很简单——它天生就是为流处理设计的。你想想看，数据在现实中本来就是源源不断流过来的，为什么我们要把它切成一个个小批次来处理呢？
1.1 流处理与批处理：两种思维模式
先看一个最直观的对比。批处理就像是你去食堂打饭——等所有人都到齐了，一起开饭。流处理呢？就像吃自助餐——来一个人吃一个人，随时来随时吃。
| 维度 | 批处理（如MapReduce、Spark Batch） | 流处理（如Flink） |
|---|---|---|
| 数据到达 | 数据先存起来，等到固定时间或数据量触发 | 数据一到就处理，无需等待 |
| 延迟 | 分钟级到小时级 | 毫秒级到秒级 |
| 计算模型 | 一次性处理全部数据 | 持续处理无界数据流 |
| 容错机制 | 任务失败后重新运行 | 基于检查点（Checkpoint）的精确一次语义 |
| 典型场景 | 离线报表、历史数据回溯 | 实时监控、数据同步、实时数仓 |
我在项目中遇到过这样一个场景：业务方要求把MySQL的订单变更实时同步到Elasticsearch，延迟不能超过3秒。如果用批处理，每5分钟跑一次Sqoop，延迟根本扛不住。换成Flink CDC（Change Data Capture）后，延迟直接降到秒级以内。说白了，选流处理还是批处理，核心就看你对延迟的容忍度。
核心观点：Flink的流处理不是批处理的替代品，而是互补品。批处理适合处理有界数据，流处理擅长处理无界数据。但在Flink中，批处理被看作"有界流"——这是它最巧妙的设计之一。
1.2 Flink核心特性：为什么它这么能打？
Flink能成为流处理领域的标杆，靠的是几个硬核特性。我挑三个最关键的说说。
1.2.1 真正的流处理引擎
很多流处理框架其实是"微批处理"——把流切成小批次再处理。Flink不一样，它每条数据到了就处理，不攒批。这意味着什么？延迟更低，实时性更强。我记得有一次做压测，Flink在每秒百万条数据量下，延迟依然稳定在几十毫秒。嗯，这个表现让我当时就决定用它了。
1.2.2 精确一次语义（Exactly-Once）
做数据同步最怕什么？数据重复或丢失。Flink通过分布式快照（Checkpoint）机制，保证了即使任务失败重启，每条数据也只会被处理一次。我曾经在线上遇到过Kafka集群宕机，Flink任务自动恢复后，目标数据库的数据一条没多、一条没少。这个能力，在金融、电商场景下特别重要。
1.2.3 事件时间处理
数据到达的时间和事件实际发生的时间往往不一致。比如用户下单是10:00，但网络延迟导致数据11:00才到。Flink支持基于事件时间（Event Time）做计算，配合水位线（Watermark）机制，能准确处理乱序数据。这个特性在数据同步中非常实用——你同步的是"业务发生时的数据"，而不是"数据到达时的数据"。
个人建议：刚开始学Flink时，先把"事件时间"和"处理时间"这两个概念搞清楚。我见过不少新手在这上面栽跟头——明明数据对不上，查了半天才发现是时间语义用错了。
1.3 Flink应用场景：实时数仓与数据同步
Flink的应用场景很广，但咱们这门课聚焦两个方向：实时数仓和数据同步。为什么选这两个？因为它们是Flink最能发挥价值的地方。
1.3.1 实时数仓
传统数仓是T+1的——今天的数据明天才能看。实时数仓呢？数据产生后秒级就能进入数仓，支持实时OLAP分析。Flink在实时数仓中扮演的角色是"数据管道"——从业务库（MySQL、Oracle）或消息队列（Kafka）读取数据，经过清洗、关联、聚合后，写入ClickHouse、Doris等OLAP引擎。
我参与过的一个项目，用Flink把上百张业务表实时同步到ClickHouse，实现了秒级OLAP查询。业务方再也不用等第二天看报表了，实时大屏直接展示当前销售额。那种感觉，确实挺爽的。
1.3.2 数据同步
数据同步是实时数仓的基础。Flink CDC技术可以实时捕获数据库的变更（插入、更新、删除），然后同步到目标系统。相比传统方案（如Canal + Kafka + 自研消费者），Flink CDC的优势在于：
- 开箱即用：一行配置就能监听MySQL Binlog
- 断点续传：基于Checkpoint，任务重启后从断点继续同步
- 全量+增量一体化：先做全量快照，再无缝切换到增量同步
避坑提醒：我曾经在同步大表（几亿行）时，没注意Flink CDC的并发配置，导致全量阶段读取太慢。后来调整了并行度和分片策略，速度提升了10倍。这个坑后面章节会详细讲。
1.4 Flink架构概览：一张图看懂
下面这张图是我自己画的Flink运行时架构。你不需要记住所有细节，先有个整体印象就行。
简单解释一下这张图：
- Client：你写的Flink程序，通过Client提交到集群
- JobManager：集群的"大脑"，负责任务调度、资源分配、Checkpoint协调
- TaskManager：真正干活的"工人"，每个TaskManager有多个Slot（可以理解为线程槽位）
- Source / Sink：数据从哪里来（Kafka、MySQL），到哪里去（ES、ClickHouse）
你可能会问：这么多组件，我该怎么部署？别急，后面章节会手把手教你搭建Flink集群。现在你只需要记住：Flink是一个主从架构的分布式系统，JobManager是主节点，TaskManager是从节点。
关键理解：Flink的并行度由TaskManager的数量和每个TaskManager的Slot数量共同决定。比如3个TaskManager，每个2个Slot，最大并行度就是6。我在调优时，一般会根据数据量和资源情况，把并行度设置在8-32之间。
本章小结
好了，第一章的内容就到这里。我们聊了流处理和批处理的区别，Flink的三个核心特性（真正流处理、精确一次、事件时间），以及它在实时数仓和数据同步中的应用。最后用一张架构图帮你建立了Flink的整体认知。