📚 课程目录第3章 Flink基础与环境搭建

3. Flink基础与环境搭建：从发展到上手

做反欺诈风控，说白了就是在跟时间赛跑。一笔交易从发生到判定欺诈，留给我们的窗口往往只有几十毫秒。Flink 能成为实时风控领域的主流选择，不是没有原因的。今天我们就从头捋一捋 Flink 的发展，然后手搭环境，最后用一段简单的代码来感受一下它的核心 API。

3.1 Flink 的发展史：从学术项目到工业标配

Flink 的起源其实挺有学术范儿的。它最早是柏林工业大学的一个研究项目，2014 年才成为 Apache 顶级项目。我记得那会儿国内用 Storm 的还不少，但 Storm 在处理复杂事件时的短板太明显了——状态管理基本靠手写，时间语义也不够精细。

Flink 真正火起来，是在 2019 年前后。为什么？因为它在流处理上的「状态一致性」和「精确一次语义」，正好切中了金融、支付行业的核心痛点。你想想看，一笔欺诈交易被漏掉或者重复计算，后果可不止是数据准确性的问题。

版本	里程碑	我关注的点
0.9 - 0.10	正式进入大众视野，支持 DataStream API	状态后端的概念刚出来，还不太成熟
1.0 - 1.2	引入 Table & SQL API，批流一体雏形	在项目里试过 Flink SQL，语法抽象得不错
1.6 - 1.9	状态处理器、CEP 库成熟	我就是在 1.9 开始大规模把 CEP 用到反欺诈里的
1.12+	批流一体最终落地，Kubernetes 原生支持	现在新项目我基本直接上 K8s 部署了

  我的观点： Flink 的迭代速度一直很快。如果你还在用 1.13 以下的版本，我真的建议你升级一下——尤其是 CEP 模块的性能优化和 SQL 兼容性，差别非常大。

3.2 安装部署：本地快速启动

学习阶段，别去折腾 YARN 或者 K8s。一台笔记本就够了。我们直接跑 Standalone 模式，先感受一下 Flink 怎么「转」起来的。

我通常用本地模式做开发验证。步骤如下：

下载：去 Apache Flink 官网挑一个稳定版本（我推荐 1.15 或 1.16）。
解压：tar -xzf flink-1.16.2-bin-scala_2.12.tgz
启动：进入解压目录，运行 ./bin/start-cluster.sh
验证：浏览器打开 http://localhost:8081，看到页面就说明好了

避坑： 我曾经在 Windows 环境下吃过亏——Flink 的本地启动脚本依赖 bash，Windows 必须用 WSL 或者 Cygwin，否则直接报错。嗯，这里要注意：生产环境我不建议用 Standalone 模式，单点故障扛不住。

启动成功后，用 jps 命令能看到两个进程：StandaloneSessionClusterEntrypoint 和 TaskManagerRunner。这就是 Flink 的「脑袋」（JobManager）和「手脚」（TaskManager）。

3.3 集群模式：一张图讲清楚

Flink 的集群模式其实不复杂。核心就三种：Standalone、YARN、Kubernetes。我现在画张图帮你串一下。

从图上你能看出，不管哪种模式，都有 Client、JobManager 和 TaskManager。区别在于资源怎么分配、谁来管理 TaskManager 的生命周期。

模式	适用场景	我踩过的坑
Standalone	入门测试、小规模集群	TaskManager 挂了不会自动恢复，早期项目吃过这个亏
YARN	已有 Hadoop 生态的大数据团队	依赖 YARN 版本，差点被集群版本兼容性坑死
Kubernetes	云原生、弹性伸缩要求高	网络配置稍微复杂，但值得投入

3.4 Flink SQL vs DataStream API：初探

说到写 Flink 程序，最常见的两种姿势就是 Flink SQL 和 DataStream API。它们的关系不复杂，我经常跟团队说：SQL 是声明式的，API 是过程式的。

3.4.1 DataStream API 初体验

用 Java 写一段简单的流处理代码，感受一下。下面这段代码，就是从 Kafka 读取数据，然后过滤出金额大于 10000 的交易。

// Maven 依赖：flink-streaming-java, flink-clients, flink-connector-kafka
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

DataStream<String> source = env.addSource(
    new FlinkKafkaConsumer<>("transaction_topic",
        new SimpleStringSchema(),
        properties)
);

DataStream<String> highValue = source
    .filter(line -> {
        // 注意：这里只是演示，实际要解析 JSON
        return line.contains("amount\":10000");
    });

highValue.print();
env.execute("Flink Fraud Detection - DataStream API");

个人习惯： 在反欺诈场景里，我会优先用 DataStream API 做算子层面的精细控制。因为 CEP 的匹配逻辑、状态的清理策略，用底层 API 调起来更顺手。

3.4.2 Flink SQL 初体验

同样的逻辑，用 SQL 写出来就是个样子：

// 在 Flink CLI 或 SQL-Client 中执行
CREATE TABLE transactions (
    trans_id STRING,
    amount DOUBLE,
    event_time TIMESTAMP(3),
    WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND
) WITH (
    'connector' = 'kafka',
    'topic' = 'transaction_topic',
    'properties.bootstrap.servers' = 'localhost:9092',
    'format' = 'json'
);

SELECT * FROM transactions WHERE amount > 10000;

有没有觉得 SQL 更直观？但它的局限性也很明显——复杂的 CEP 模式、自定义状态清理、分布式锁之类的逻辑，用 SQL 就很难表述了。所以我通常的策略是：简单聚合、过滤用 SQL；复杂事件匹配用 DataStream + CEP 库。

  说白了： SQL 降低上手门槛，DataStream 保证灵活度。一个团队里，让不同角色用不同的工具，这才是效率最高的方式。

3.5 本章小结

好，我们简单收一下。这章我们从 Flink 的成长讲起，聊了它的架构、部署模式，也上手写了两段代码。

Flink 的版本迭代很快，建议直接上 1.15+
本地测试用 Standalone，生产环境优先考虑 K8s 或 YARN
Flink SQL 和 DataStream API 各有所长，按场景选型才是关键