Flink技术源码解析（一）：源码研读准备

Flink技术源码解析（一）：源码研读准备

简介： 一、前言 Apache Flink作为一款高吞吐量、低延迟的针对流数据和批数据的分布式实时处理引擎，是当前实时处理领域的一颗炙手可热的新星。关于Flink与其它主流实时大数据处理引擎Storm、Spark Streaming的不同与优势。
一、前言
Apache Flink作为一款高吞吐量、低延迟的针对流数据和批数据的分布式实时处理引擎，是当前实时处理领域的一颗炙手可热的新星。关于Flink与其它主流实时大数据处理引擎Storm、Spark Streaming的不同与优势。

出于技术人对技术本能的好奇与冲动，遂利用业余时间对Flink进行学习研究。Flink源码很庞大，要梳理明白需要投入的时间心力巨大，所以笔者只是针对自己所感兴趣的若干话题展开研究，水平有限如有错误请指正。

二、Flink概述提要
2.1 主要特性与组成
Flink是一个用于流处理和批处理的开源分布式平台，它的核心是流处理引擎（streaming dataflow engine）。

batch dataset可以视作streaming dataset的一种特例，所以Flink可通过流处理引擎同时处理batch、streaming两种类型的数据。这和spark streaming刚好相反，spark streaming是通过micro batch实现对streaming处理的支持。

Flink的功能特性：

可提供准确的结果产出，即使遇到乱序数据、迟到数据；
有状态可容错（轻量级），可以无感知地从失败中恢复并保持exactly-once的语义（也可以降级为at-least-once进一步降低消息处理延时）；
可以大规模地运行在成千上万个节点上并保持高吞吐、低延迟，可以standalone模式运行，也可以在YARN和Mesos等资源管理平台上运行；
灵活地支持多种基于时间、数量、会话的窗口；
savepoint提供了状态管理机制；

Flink自下而上的全局组成结构图：

2.2 编程模型
2.2.1 Flink提供的API

Flink提供了不同层次的API用于streaming/batch应用的开发，如下图所示：

最底层的抽象仅提供状态流（stateful streaming），它通过处理函数嵌入到DataStream API中。
实践中用Core API比较多，这些流式的API提供了通用的构建入口用于数据处理，像各种用户自定义的transformation、join、aggregation、window、state等。
Table API是以表为中心的声明式DSL（领域特定语言），当这些Table表示的是stream时，Table是动态变化的。Table API遵循扩展的关系模型，提供了包括select、project、join、group-by、aggregate等操作。
Flink提供的最高层级的API是SQL，它在语义和表达能力上与Table API是类似的。
2.2.2 Flink程序与Streaming Dataflow

Flink程序的基本元素包括：

stream：由连续不断的data record组成的数据流。
transformation：是一种转换操作，作用在一个或多个stream上，输出一个或多个stream。
每个Flink程序可以映射为一个streaming dataflow，这个dataflow由stream和transformation operator组成。每个dataflow是一个DAG，从一个或多个source开始，结束于一个或多个sink。

Flink程序/Streaming dataflow的结构如下图所示：

一个标准Flink程序的组成：

获取一个执行环境（StreamExecutionEnvironment用于流处理，ExecutionEnvironment用于批处理），执行环境可以决定将下面的计算放在本地jvm运行还是提交到Flink集群中运行；
加载初始数据；
在数据上指定需要执行的transformation；
指定将计算结果写到哪里；
触发程序执行；

2.2.3 并行的dataflow

Flink程序在实际运行中是并行的、分布式的：

一个stream会被拆分为一个或多个stream partitions。
一个transformation operator可以拆分为一个或多个operator subtask（subtask的数量称为这个operator的并行度）。每个operator subtask和其它的operator subtask相互独立，并运行在不同的线程中（甚至在不同的机器上）Flink程序中的source、sink也都属于transformation operator。
一个transformation operator中的operator subtask个数就是这个operator的并行度；一个stream的并行度为对应的producing operator（从数据源读数据的operator）的个数。一个程序中的不同operator可能会有不同的并行度。

一个dataflow的运行结构如下图所示：

流中的数据在不同operator之间的传递方式有两种：

one-to-one：像上图的Source[1] -> map[1]。
redistributing：像上图的map[1] -> keyBy()/window()/apply() [1]和[2]。
2.2.4 Window

在streams上对event进行聚合（如count、sum）与批处理不同，需要通过window限定聚合的event范围，如统计最近5分钟的event数量。stream上的window可以是时间驱动（如每30秒），也可以是数据驱动（如每100个元素）。

window类型的典型划分：

tumbling windows：不同window之间的元素不重叠。
sliding window：不同window之间的元素可重叠。
session window：即通过会话来区分window。
一个stream上可以同时有多个window：