Flink集成AWS Kinesis：云端实时数据处理实战指南

交易员.Coder·2026-08-29·阅读 23 GEO检测（免费）

FlinkAWS Kinesis实时数据处理

|难度：普通|阅读约 47 分钟

Flink与AWS Kinesis集成：云端实时数据处理

做实时数据处理这些年，我陆续接触过不少方案，从自建Kafka集群到各类托管消息队列，再到云厂商的流式服务。如果让我给一个比较省心的组合，Flink加上AWS Kinesis绝对能排进前三。Kinesis把消息接入、临时存储、日志保留这些脏活累活全包了，Flink负责真正的计算逻辑，两边配合起来，一条云端实时数据处理管线基本就是标准答案级别的存在。

这篇文章我会把Flink对接Kinesis的完整链路拆开讲清楚，包括连接器的核心机制、并行度与分片的关系、Checkpoint如何保证精确一次、以及我实际踩过的各种坑。内容侧重实操，适合正在选型、或者已经在云上搞实时计算但被各种问题卡住的朋友。不管是做实时数仓、用户行为分析、还是风控预警，这套组合都能直接复用。

1. 为什么是Kinesis + Flink：架构选型背后的真实考量

1.1 先搞明白Kinesis解决了什么问题

Kinesis是AWS上的托管流式数据服务，核心组件是Kinesis Data Streams（KDS）。你可以把它理解成云上的Kafka，但不需要自己维护Broker、Zookeeper这些基础设施。它的数据模型很简单：一条Stream由若干个Shard组成，数据以Record的形式写入，每个Record带一个Partition Key，Kinesis根据这个Key的哈希值决定数据落到哪个Shard。

Kinesis的好处是运维成本极低。创建一条Stream，指定Shard数量，就能开始读写。数据的保留时间默认24小时，最长可以调到8760小时（一年），这意味着消费端挂了可以慢慢恢复，不用担心数据被Broker清理掉。这个特性在实际生产中非常重要，Flink任务升级、重启、回放数据的时候，Kinesis的数据保留期限给了很大的缓冲空间。

还有一个容易被忽略的点：Kinesis支持通过数据流中的Sequence Number进行精确回放。每个Record在写入时都会被分配一个单调递增的Sequence Number，消费端可以从指定位置重新读取。这一点和Kafka的Offset机制类似，但对于从零开始做流式架构的团队来说，Kinesis的这套模型更直观，不需要理解Topic、Partition、Consumer Group这些概念，学习曲线平滑很多。

1.2 为什么选Flink做处理引擎

如果只说流计算引擎，几个主流的方案各有拥趸，但Flink在几个维度上确实有不可替代的优势。

首先是State管理。实时计算大部分场景都有状态，例如统计过去5分钟的用户点击量、计算去重数、追踪会话Session，这些都离不开状态存储。Flink的State Backend支持RocksDB、内存、以及增量Checkpoint，配合AWS的S3做持久化，理论上可以支撑TB级别的状态规模。这个能力在处理长时间窗口或全局去重时尤其关键——我在实际项目中跑过单任务状态量超过200GB的作业，RocksDB加S3的配合下稳定性依然不错。

其次是精确一次语义。Flink的两阶段提交机制配合Kinesis Sink，可以在端到端层面保证数据不丢不重。很多人在入门阶段觉得精确一次只是个噱头，但在金融交易、库存扣减这类场景里，重复统计一笔订单的后果是致命的。Flink在这一点上做得相当扎实。

再就是生态。Flink的Connector体系非常全，Kinesis、Kafka、JDBC、Elasticsearch、Hudi、Iceberg都有官方或社区维护的连接器。这意味着你可以用Flink作为统一的实时计算引擎，对接不同数据源和数据目的地，而不是每个数据源都写一套独立的消费逻辑。

1.3 和自建Kafka相比，托管流到底划不划算

这个问题我经常被问到。自建Kafka在AWS的EC2上跑，表面上看实例费用不高，但你得算运维成本、监控成本、故障恢复成本。Kafka的运维门槛是出了名的，Broker宕机、分区不均、ISR收缩、磁盘水位、消费者Rebalance抖动，每一个问题都够喝一壶的。对我来说，如果团队里没有一个专职的Kafka运维专家，自建方案的实际成本远高于表面上的硬件开销。

Kinesis的优势在于全托管。你不需要关心Broker健康状态，不需要做磁盘扩容，不需要处理分区迁移，一切由AWS兜底。价格上，Kinesis按Shard小时数和Put/Get请求数计费，对于中小规模的数据量来说成本可控。当数据量增长到每秒数百MB甚至GB级别时，Kinesis的成本优势会下降，这时候才需要认真考虑自建方案。我的建议是：日均数据量在几百GB以内、不想养运维团队的团队，直接用Kinesis，省下来的精力用来做业务，比省那点云费用划算得多。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 核心机制拆解：Kinesis连接器到底怎么工作

2.1 连接器两大组件：Consumer和Sink

Flink与Kinesis的集成主要依赖官方提供的flink-connector-kinesis连接器。这个连接器包含两个核心组件：FlinkKinesisConsumer用于从Kinesis Data Streams读取数据，KinesisStreamsSink用于将计算结果写回Kinesis或Kinesis Data Firehose。

Consumer的设计思路和Kafka Consumer非常类似，每个并行子任务负责消费一个或多个Shard。Flink会在内部维护每个Shard的消费位置（Sequence Number），并定期将其提交到Flink的Checkpoint中。一旦任务失败重启，Flink可以从最近一次Checkpoint记录的Sequence Number开始恢复，保证数据不丢。

Sink侧则利用Kinesis的PutRecords API批量写入，内部会做Buffer缓存、批量聚合和失败重试。这里有一个值得注意的设计：KinesisStreamsSink在写数据时，会先让每个Record分配一个Partition Key，通过Key的哈希决定数据最终进入哪个Shard。如果你不指定Partition Key，默认会使用一个固定的常量Key，导致所有数据都写入同一个Shard，严重浪费其它Shard的吞吐。这个细节我在第三节实操里会详细演示。

2.2 Shard与并行度：理解消费模型的关键

Shard是Kinesis吞吐的最小单位。每个Shard的写入能力是1MB/s或每秒1000条记录（取两者较小值），读取能力是2MB/s，每秒最多5次事务读取。这个数字直接决定了你对Flink并行度的规划。

一个容易被误解的点是：Flink的并行度并不需要等于Shard数量。Flink的每个并行子任务可以消费多个Shard，一个Shard也只会被一个并行子任务消费，不会出现两个子任务同时消费同一个Shard的情况。所以并行度可以大于或小于Shard数量，但小于Shard数量时，单个子任务会串行处理多个Shard，消费速度可能跟不上Shard的写入速度。

我用一个具体的场景来说明。假设业务数据写入速率是2MB/s，创建了4个Shard的数据流，那么每个Shard的写入大约是0.5MB/s。Flink侧如果只设置2个并行度，每个子任务需要消费2个Shard，也就是1MB/s的读取量，CPU和网络开销会比较高。如果设置4个并行度，每个子任务只消费1个Shard，压力就非常均衡。如果设置8个并行度，会有4个子任务空闲，但任务调度依然稳定，不会有问题。

所以我的经验是：并行度和Shard数保持1:1是最舒服的配比，或者让并行度稍大于Shard数，留一点余量应对流量突增。

2.3 Checkpoint与Sequence Number：如何实现精确一次

Flink的精确一次语义，依赖的是Checkpoint机制和各个连接器的配合。对于Kinesis，每个Shard的消费进度用Sequence Number表示。Flink会周期性地对状态做快照，同时把当前消费到的Sequence Number一并记录到Checkpoint中。

当任务故障恢复时，Flink从最近一次成功的Checkpoint恢复，重新拉起所有状态，并且让Consumer从上一次Checkpoint记录的Sequence Number开始重新消费数据。这意味着从Checkpoint之后到故障发生前的数据会被重新读取一遍。如果此时Sink侧不具备幂等性，这些重复数据会造成重复写入。

KinesisStreamsSink本身通过两阶段提交协议实现了精确一次。简单来说，Flink在Checkpoint成功之前，不会对外提交任何未完成的事务；Checkpoint完成后，所有写入数据才真正对外可见。这个机制保证了即使发生故障，外部系统也只会看到完整的、已提交的数据。

需要说明的是，KinesisStreamsSink的两阶段提交依赖于Kinesis本身不支持事务的特性，但Flink通过在Sink端做事务缓冲来实现。实际使用时，需要合理设置Checkpoint间隔。我通常配置为30秒到1分钟，太频繁会加重Kinesis的读压力，太稀则会拉长故障恢复后重复读取的数据量。

2.4 水位线与Event Time：流式时间处理的坑

流式计算中最棘手的问题之一就是“乱序”和“时间”。在Kinesis里，Record自带一个ApproximateArrivalTimestamp，这是数据写入Kinesis时的时间。你也可以在数据内容里自带业务时间，比如用户在前端点击时打的时间戳。

Flink处理时间有三种语义：Processing Time（处理时间）、Event Time（事件时间）、Ingestion Time（摄入时间）。Kinesis场景下，我强烈建议用Event Time，以业务发生的时间为准。如果只用Processing Time，遇到数据积压或者回放，统计结果会完全失真。

使用Event Time就必须有水印（Watermark）机制。水印的本质是告诉Flink：“到目前这个时刻为止，所有时间小于水印的事件都已经到达了，可以开始计算窗口了”。如果没有水印，Flink的窗口永远不会触发，因为永远不知道什么时候该关窗。

Kinesis的Consumer支持配置水印策略。推荐的做法是使用AssignerWithPunctuatedWatermarks或者AssignerWithPeriodicWatermarks，以事件时间减去一个允许的延迟量作为水印。例如，允许数据乱序5秒，那么水印就是当前最大的事件时间减5秒。这样即使数据偶尔乱个几秒，窗口也能等到它们。

2.5 依赖与版本选型

flink-connector-kinesis的版本需要和Flink主版本匹配。例如Flink 1.17对应flink-connector-kinesis-4.2.0-1.17，Flink 1.18对应flink-connector-kinesis-4.3.0-1.18。版本不匹配时，最容易出现的报错是NoClassDefFoundError或者SerializationException，这类问题排查起来非常费劲，建议一开始就锁定版本。

另外要注意AWS SDK的依赖冲突。Kinesis连接器默认会引入aws-java-sdk-kinesis和aws-java-sdk-sts等组件。如果你的项目里还有其它AWS服务的SDK，务必检查依赖版本是否一致。我遇到过因为旧版本的aws-java-sdk-core导致Kinesis客户端无法正常建立连接的问题，后来统一升级SDK版本后解决。

依赖建议使用Gradle或Maven管理，核心依赖如下：

xml复制<dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-connector-kinesis</artifactId>
    <version>4.3.0-1.18</version>
</dependency>
<dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-streaming-java</artifactId>
    <version>1.18.1</version>
</dependency>

如果你是通过Flink SQL来操作的话，还需要引入对应的SQL Connector包。不过说实话，Kinesis在Flink SQL里的支持虽然可用，但配置项相对底层API更受限，如果要做复杂的窗口和状态操作，用DataStream API会更顺手。

3. 实操：从零搭建一条云端实时数据处理管线

3.1 准备工作与环境

在开始写代码之前，需要先准备几件事：

一个AWS账号，并且有权限创建Kinesis Data Streams、IAM角色、S3桶。
本机安装好Java 8或11、Maven或Gradle、Flink开发环境。
如果是部署到AWS的托管环境，比如Amazon Managed Flink，还需要准备好对应的IAM权限策略。

这里有一个经验：本地开发和云端运行的环境尽量保持一致。AWS SDK的凭证加载机制默认会读取环境变量或~/.aws/credentials文件，但Flink集群上不可能存放本机的凭证，所以生产环境推荐用IAM Role绑定EC2或ECS，Flink任务通过Instance Profile自动获取临时凭证，这样既安全又不需要在代码里硬编码密钥。

3.2 创建Kinesis数据流

创建Kinesis Data Stream有两种方式：AWS控制台和AWS CLI。控制台操作简单直观，CLI适合自动化部署。我习惯用CLI，方便写进脚本里：

bash复制aws kinesis create-stream \
    --stream-name user-click-stream \
    --shard-count 4 \
    --region us-east-1

创建完成之后，可以用describe-stream查看状态，等Status变成ACTIVE再开始写入数据。

注意Shard数量的选择。如果前期数据量不确定，我建议先创建4~8个Shard，跑一段时间再根据CloudWatch监控指标动态调整。Kinesis支持手动或自动扩缩容Shard数量，虽然扩容后会有短暂的重新分片过程，但比一开始就浪费大量Shard更划算。

3.3 Flink消费Kinesis的完整代码

下面是一段标准的Flink DataStream代码，从Kinesis读取数据，解析JSON，计算每个用户过去1分钟的点击次数，并输出结果。

java复制import org.apache.flink.api.common.eventtime.WatermarkStrategy;
import org.apache.flink.api.common.serialization.SimpleStringSchema;
import org.apache.flink.streaming.api.datastream.DataStream;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.streaming.connectors.kinesis.FlinkKinesisConsumer;
import org.apache.flink.streaming.connectors.kinesis.config.ConsumerConfigConstants;
import org.apache.flink.streaming.api.windowing.time.Time;
import org.apache.flink.api.common.functions.MapFunction;
import org.apache.flink.api.java.tuple.Tuple2;

import java.util.Properties;

public class KinesisClickAnalysis {

    public static void main(String[] args) throws Exception {
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
        env.enableCheckpointing(30000);
        env.getCheckpointConfig().setMinPauseBetweenCheckpoints(15000);
        env.getCheckpointConfig().setCheckpointTimeout(60000);

        Properties consumerConfig = new Properties();
        consumerConfig.setProperty(ConsumerConfigConstants.AWS_REGION, "us-east-1");
        consumerConfig.setProperty(ConsumerConfigConstants.STREAM_INITIAL_POSITION, "LATEST");

        DataStream<String> stream = env.addSource(
            new FlinkKinesisConsumer<>("user-click-stream",
                new SimpleStringSchema(), consumerConfig)
        );

        stream.map(new MapFunction<String, Tuple2<String, Integer>>() {
            @Override
            public Tuple2<String, Integer> map(String value) {
                // 实际项目中建议用JSON解析库，例如Jackson或Gson
                String userId = value.split(",")[0];
                return new Tuple2<>(userId, 1);
            }
        })
        .keyBy(item -> item.f0)
        .timeWindow(Time.minutes(1))
        .sum(1)
        .print();

        env.execute("kinesis-click-analysis");
    }
}

这段代码有几个关键点需要展开说明。

ConsumerConfigConstants.STREAM_INITIAL_POSITION表示在Kinesis中没有保存消费位置时，从哪里开始读取。可选值有LATEST（只读新数据）、TRIM_HORIZON（从最早数据开始）、AT_TIMESTAMP（从指定时间开始）。开发调试阶段建议用TRIM_HORIZON，这样可以回放历史数据；生产环境则通常用LATEST，避免任务启动瞬间读取大量无用数据。

Checkpoint在这里不只是为了容错，它还承担了进度保存的作用。每30秒做一次Checkpoint，写入一次进度，任务重启后就知道从哪个Sequence Number开始消费。

3.4 写出结果到Kinesis或S3

计算结果落盘是实时管线的最后一环。常见目的地是Kinesis Data Firehose再转存到S3，或者直接用Sink写回Kinesis供下游消费。

这里我演示用KinesisStreamsSink写回Kinesis：

java复制import org.apache.flink.streaming.connectors.kinesis.KinesisStreamsSink;

Properties sinkConfig = new Properties();
sinkConfig.setProperty(AWSConfigConstants.AWS_REGION, "us-east-1");

KinesisStreamsSink<Tuple2<String, Integer>> sink = KinesisStreamsSink.<Tuple2<String, Integer>>builder()
    .setKinesisClientProperties(sinkConfig)
    .setSerializationSchema(new SimpleSerializationSchema())
    .setPartitionKeyGenerator(element -> String.valueOf(element.f0))
    .setStreamName("user-click-result-stream")
    .build();

resultData.sinkTo(sink);

注意setPartitionKeyGenerator这一步。如果你不设置，默认的FixedKinesisPartitionKeyGenerator会把所有数据都放到同一个Shard里，直接造成热点。我习惯用业务主键作为Partition Key，比如这里用userId，这样同一个用户的事件会落在同一个Shard上，对下游按用户聚合的操作非常友好。

如果目标是S3，更简单的做法是直接把数据写到Kinesis Data Firehose，Firehose负责批量打包和压缩，自动写入S3。这样Flink的TaskManager不需要维护S3连接，架构更简洁。

代码里的SimpleSerializationSchema需要你自定义实现，核心逻辑是把Tuple2<String, Integer>转成字节数组。我用最简单的JSON格式：

java复制public class SimpleSerializationSchema implements SerializationSchema<Tuple2<String, Integer>> {
    @Override
    public byte[] serialize(Tuple2<String, Integer> element) {
        return String.format("{\"userId\":\"%s\",\"count\":%d}", element.f0, element.f1).getBytes(StandardCharsets.UTF_8);
    }
}

3.5 提交运行与监控

本地调试时可以直接在IDE里运行main方法，Flink会启动一个LocalEnvironment。生产环境建议打成JAR包，提交到Amazon Managed Flink（原Kinesis Data Analytics）或者自建的Flink集群。

如果使用Amazon Managed Flink，提交方式非常傻瓜：上传JAR包，指定入口类，配置好IAM Role，服务会自动拉起作业并在控制台展示运行状态。后台的Flink Dashboard和CloudWatch指标会帮你监控Checkpoint次数、背压情况、数据延迟。

我自己的习惯是重点关注两个指标：millisBehindLatest和CheckpointDuration。前者表示当前任务消费到的数据距Kinesis最新数据有多远，如果持续变大说明消费速度跟不上，需要扩容Shard或提高并行度；后者如果经常超过Checkpoint间隔，就要考虑优化状态大小或者降低Checkpoint频率。

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

4.1 消费延迟飙升：Shard不够用还是代码有Bug？

消费延迟是实时管线最直观的健康指标。如果millisBehindLatest持续上升，先排除一个最简单的可能性：Flink任务所在机器的网络到Kinesis终端节点的延迟是否正常。然后看任务是不是处于Backpressure状态，TaskManager的CPU和内存是否打满。

如果这两项都正常，那大概率是Shard数量不够。数据写入速率超过Shard能力后，Kinesis会自动限流，消费端拼了命也拉不完。解决办法有两个：扩容Shard，或者提高Flink并行度。但要注意，如果并行度已经大于等于Shard数量，再提并行度也没用。遇到这种情况，我通常会先扩容Shard，再调整并行度。

4.2 Shard Iterator过期与限流异常

Kinesis的Shard Iterator（用于标识读取位置的指针）有时效限制，默认过期时间是5分钟。如果Flink任务因为GC停顿、网络抖动或Checkpoint卡住，导致一个Shard Iterator超过5分钟没有使用，就会抛出ExpiredIteratorException。

Flink的Kinesis连接器内部会自动处理这个异常，重新获取新的Iterator，所以一般不需要人工干预。但如果这个异常频繁出现，说明你的Checkpoint间隔太长了。我遇到过一次，某个任务把Checkpoint间隔设成5分钟，结果每次Checkpoint期间都是一次Shard Iterator大规模过期，表现为消费延迟呈锯齿状波动。把间隔改成30秒后问题消失。

还有一类经典异常是ProvisionedThroughputExceededException，表示读写访问超过了Kinesis的配额。读侧每个Shard每秒允许5次事务，每个事务最多返回2MB数据；写侧每秒最多1000条记录或1MB。如果Flink的消费请求太频繁，也会触发这个异常。解决方法是适当调大ConsumerConfigConstants.SHARD_GETRECORDS_INTERVAL_MILLIS（默认1000毫秒），或者增大SHARD_GETRECORDS_MAX的批量大小，减少请求频率，提高每次拉取的数据量。

4.3 序列化与Schema演化的坑

Kinesis的Record本质上就是字节数组，不关心内容格式。这意味着Flink拿到原始数据后，必须自己决定怎么解析。如果上游改了数据格式，比如在一个JSON里新增了字段，或者把某个字段从String改成了Long，下游Flink任务如果解析不兼容，轻则丢字段，重则整条数据解析失败导致任务重启。

对于这个坑，我的经验是三层防御。第一，所有写入Kinesis的数据统一走Schema Registry（AWS Glue Schema Registry或Confluent Avro Schema Registry都可以），保证Schema版本可控。第二，Flink侧解析JSON时尽量用容错型库，比如Jackson的ObjectMapper开启FAIL_ON_UNKNOWN_PROPERTIES=false，避免上游多塞了个字段就直接解析失败。第三，所有字段保留原始值的同时，尽量用Flink的TypeInformation显示声明类型，不要让Flink自行推断，特别是在使用Pojo时。

另外，如果你用了Flink的Checkpoint，状态的Schema变更也是个大课题——老状态和新代码不兼容时，启动就会报StateMigrationException。这种情况只能在任务不中断的情况下，通过Flink的State Processor API做状态迁移，或者直接放弃旧状态重新启动。所以，上线前必须把Schema评审当作和代码评审一样重要的环节来做。

4.4 Checkpoint失败恢复的排查

Flink任务最常见的失效模式就是Checkpoint连续失败，最终任务自动重启或卡住。Kinesis场景下，Checkpoint失败的原因通常有几个。

任务状态过大时，传给持久化端的文件太大，网络或S3吞吐跟不上。这个在RocksDB State Backend下尤其常见。排查方法是在Flink Web UI上查看Checkpoint的Size和Duration指标，如果Size在几十GB甚至上百GB，就要考虑优化状态结构、开启增量Checkpoint，或者对Key做更细粒度的分区。

另一个原因是依赖外部系统导致Checkpoint卡在等待某一步。比如Sink端写S3时网络异常，或者下游数据库连接池被占满。我的排查套路是：登录TaskManager，抓取线程栈，看看Checkpoint Coordinator和Subtask卡在哪个类的哪个方法上。

这里分享一个调试技巧：在flink-conf.yaml里开启state.backend.local-recovery=true，这样即使Checkpoint失败了，TaskManager本地还能保留一部分状态快照，恢复速度会快很多。这个参数在生产环境很值得开启。

4.5 连接器版本兼容性问题

Kinesis连接器版本兼容性常导致两类问题。第一类是Flink的Scala版本冲突，具体表现是运行时抛出NoSuchMethodError、ClassNotFoundException。第二类是AWS SDK自身的兼容问题，因为flink-connector-kinesis依赖的AWS SDK版本和项目中其它AWS组件的SDK版本不一致，引入新依赖时旧类被覆盖，引发执行异常。

我踩过的最深一次坑，是项目里同时使用了aws-java-sdk-s3和flink-connector-kinesis，Maven仲裁把S3相关的SDK版本降级了，然后Flink任务启动时Kinesis客户端一直报Unable to load AWS credentials，但实际上凭证配置是正确的。后来排查到是SDK版本冲突导致STS客户端的类加载失败。解决方案是用Maven的dependencyManagement锁定AWS SDK版本，并排除多余的间接依赖。

使用mvn dependency:tree查看依赖树是排查这类问题的基础手段，建议所有和Kinesis集成相关的项目都把这步加入上线检查清单。

5. 进阶场景：从流处理到实时数仓

5.1 Flink CDC与Kinesis结合的增量同步

很多团队的实时数仓并非从零开始，而是基于关系型数据库的增量数据同步。Flink CDC是当前最主流的方案之一，它通过解析MySQL、PostgreSQL的BinLog/WAL日志，实时获取数据变更事件，然后可以发到Kinesis作为统一的数据总线。

架构上，Flink CDC能够直接对接Kinesis作为Sink，把数据库的Insert、Update、Delete事件以统一的格式写入Kinesis，下游再用Flink或其它引擎消费，构建实时数仓的ODS层。这样的好处是：CDC任务只负责数据采集，数仓的计算任务独立部署，互不干扰。如果下游计算任务需要改SQL，不用重启CDC任务。

有一点需要注意：Flink CDC在MySQL场景下需要保证BinLog的row格式，以及账号至少拥有SELECT、RELOAD、SHOW DATABASES、REPLICATION SLAVE、REPLICATION CLIENT权限。这些权限在生产环境申请时往往要走流程，建议提前规划好。

5.2 Flink CEP在实时预警中的应用

Flink CEP（Complex Event Processing）是Flink的复杂事件处理库，用来检测数据流中符合特定模式的事件序列。比如在风控场景下，检测“同一用户1分钟内连续登录失败超过5次”，“相同收货地址在10分钟内下单超过3个”，这些用普通流处理很难优雅实现，但CEP的Pattern API做起来就非常直接。

有意思的是，CEP和Kinesis的组合让我觉得比CEP和Kafka的组合更顺手。原因是Kinesis的Partition Key天然可以保证同一个Key的数据进入同一个Shard，而同一个Shard的数据会被Flink的同一个SubTask处理，这样可以避免在CEP中人为做KeyBy重分区。对于依赖全局模式匹配的场景，Kinesis的分区能力减少了很多不必要的shuffle开销。

CEP的使用要注意时间语义。大部分CEP模式都依赖Event Time，因此上游数据必须带上可靠的时间戳。Kinesis的ApproximateArrivalTimestamp可以作为兜底，但如果业务系统有明确的事件发生时间，还是要以业务时间为准。

5.3 数仓分层与存储选型

把Kinesis作为数据总线之后，实时数仓的分层逻辑可以做得非常清晰。第一层ODS，直接对应Kinesis里的原始数据流，Flink CDC或业务系统写入；第二层DWD，由Flink消费ODS层做清洗、去重、维度补充后写回Kinesis或落地到Hudi/Iceberg；第三层ADS，面向具体业务需求做聚合，写入Doris、ClickHouse或Elasticsearch服务查询。

存储选型方面，Flink配合Apache Hudi或Apache Iceberg，可以解决流批一体问题。数据既能实时写入数据湖，后续又可以跑批量补数，两种计算模式共用一份存储。我之前在项目里用Flink + Iceberg + Kinesis做了一套轻量实时数仓，全链路从数据入湖到指标产出延迟在1分钟以内，批量回刷也只需要几个小时。

如果业务对查询并发要求高，ADS层建议用ClickHouse或Doris。Flink有对应的JDBC或Streaming Connector，写入性能合格。查询侧的体验远好于直接查数据湖。

6. 最后附上一些我踩过的“常识”性教训

写到这里，我对这套架构的整体判断是：Flink与Kinesis的集成在云原生实时计算场景下，是一条非常靠谱的技术路线。它把基础设施的复杂度隐藏在托管服务背后，让研发人员把精力聚焦在业务逻辑本身。

最后分享一个踩过的教训：不管Kinesis的保留期有多长，都不要把Kinesis当成数据仓库用。它更像一个实时通道，数据在里面最多留几天，过了保留期数据就永久消失。所以任何有长期留存需求的数据，必须在流处理链路中同步落地到S3或数仓。我见过不止一个团队，因为Kinesis的消费任务挂了几天没注意，保留了7天的数据被覆盖，导致历史数据完全丢失，只能重新从业务库补数，那种痛苦只有亲历过才懂。

如果你正在规划云端实时数据架构，我建议先小规模试水Kinesis + Flink，跑通一条业务链路后再横向扩展。这套技术栈的坑虽然不少，但每一个坑都有迹可循，网上资料也丰富。真正做了几个项目之后，你会像我一样觉得，它确实是把实时计算这件事变简单了。