文章目录

  • Apache Flink 核心概念和原理
  • 1. 流处理特性
  • 2. Flink架构
  • 3. 窗口
  • 3.1 按窗口触发条件划分
  • 3.2 按窗口移动方式划分
  • 3.3 按窗口计算并行度划分
  • 4. 时间概念与watermark
  • 4.1 Flink时间概念
  • 4.2 watermark
  • 5. Flink状态管理与容错
  • 5.1 State
  • 5.2 Checkpoints


Apache Flink 核心概念和原理

1. 流处理特性

需要每条数据都被计算在内，且需要精准的只有一次的语言。并且能够在很低的延迟下完成大量数据的计算，面对实际中各种可能的失败，也能保证稳定性和准确性。

  • Exactly once
    数据可能会被计算多次，因此只需要保证处理的最终结果只会持久的再后端状态存储中体现一次。
  • 低延迟
    流数据能够在不完整的数据上进行计算，当数据一边到来，能一边计算，使得能提供非常低的延迟。
  • 高吞吐
  • 容错
    状态一致性 + checkpoint
  • 统一引擎，流处理/批处理
    spark将流/批处理统一为批处理，flink统一为流处理。

2. Flink架构

Flink架构也遵循Master-slave架构设计原则。

flink 实战架构 flink架构原理_flink

  • Client
    客户端Client负责将任务提交到集群，与JM构建Akka连接，然后将任务提交到JM，通过和JM交互获取任务状态。
  • JobManager
    JobManager负责整个flink集群任务的调度以及资源管理，从客户端获取提交的应用，然后根据集群中TM中TaskSlot的使用情况，为提交的应用分配资源。整个集群中只有一个活跃的JM节点。TM和TM通过Actor System通信。
  • TaskManager
    TM负责具体任务执行和对应任务在每个节点上资源的申请与管理。各TaskSlot之间共享系统资源。

3. 窗口

flink 实战架构 flink架构原理_Flink_02

3.1 按窗口触发条件划分

  • Session window
    会话窗口：通过活动会话分配组元素，在一段时间内没有元素时，即当发生不活动的间隙时关闭。应用：统计分析用户活跃时行为。
  • Count window
    计数窗口，按固定数据个数触发窗口计算
  • Time window
    时间窗口，按固定时间片触发窗口计算。

3.2 按窗口移动方式划分

  • Tumbling window
    翻滚窗口，数据不会被重复计算。
  • Sliding window
    滑动窗口，数据可能会被计算多次，当滑动速度与窗口长度一致，即等价为翻滚窗口。

3.3 按窗口计算并行度划分

  • Keyed窗口
    在窗口分配之前进行keyBy分流。
  • Non-Keyed窗口
    WindowAll。并行度只能设置为1

4. 时间概念与watermark

flink 实战架构 flink架构原理_flink_03

4.1 Flink时间概念

  • 处理时间 Processing Time
    执行相应操作系统机器的系统时间（如sparkstreaming只支持处理时间）。Sparkstreaming只支持处理时间为处理顺序。
  • 事件时间 Event Time
    每个独立事件在它生产设备上产生的时间，如日志时间。
  • 提取时间 Ingestion Time
    指事件进入flink的时间。

4.2 watermark

告知operator后面不会再有小于水位线时间戳的事件接入，满足条件即可触发相应窗口计算。watermark为保证事件时间的机制。

  • 理想状态下：数据都是按顺序产生达到。如果数据都是顺序到达，使用watermark机制会延迟数据处理时间。
  • 实际：由于传输等因素，数据乱序，使用eventtime和watermark处理乱序数据。

5. Flink状态管理与容错

  • 有状态计算：flink程序内部存储计算产生的中间结果，并提供给后续使用。
    状态可以维系在本地存储中，存储可以是堆内存，或者是堆外堆存，也可以借助第三方存储介质。如RocksDB。

5.1 State

  • keyed State, Operator State(Non-keyed State)
    根据数据集是否根据key分区划分。
    Operator state只和并行算子绑定，每个算子实例中持有所有数据元素的一部分数据。
  • Managed State, Raw State
    根据使用flink原生状态管理或自定义生成state划分。
    一种托管状态：由flink runtime控制管理状态，并将数据转存为内存hashtable或rocksDB存储，然后将这些状态通过内部接口持久化到checkpoints中，用于异常恢复。
    另一种原生状态，由算子自己管理数据结构，触发checkpoint过程中，flink并不知道数据内部结构，只是将数据存储到checkpoints中。当从ck中恢复时，算子再反序列化出状态数据。

5.2 Checkpoints

  • Checkpoints机制：异步轻量级分布式快照提供checkpoint容错机制。Flink通过barrier将间隔时间内设置的数据划分到相应checkpoint中，出现异常即从上次一快照中恢复所有算子状态，从而保证数据一致性。