万物皆为流——有状态的流flink

万物皆为流——有状态的流

状态化流

回顾过去，数据和数据处理在行业无处不在，也推出了太多种基础架构来管理数据；这里面主要分为两种，事务型处理和分析型处理；

事务型处理

这幅图主要描述的场景是，大多数的服务都会处理用户，订单，包括一些客户端(或web)应用传入的数据。期间每处理一个事件，服务都会读取远程的数据系统完成一系列操作。多个应用会共享同一个数据库系统，有时候还会访问相同的数据库或者表。

在这种紧耦合的情况下，一旦多个而应用基于相同的数据表示或共享架构，那么更改表模式或对数据库系统进行扩缩容必将劳心费力。

微服务可以解决这类问题，这里不发散（微服务由很多微型、完备、独立的应用组成：应用遵守专注做好一件事。）

分析型处理

如果能将不同事务型数据库的内容进行联合查询，能为企业提供更加全面的分析见解。然而事务型数据库之间通常相互隔离，难以联合分析，因此将其全部导入一个数据仓库中，就可以进行联合查询，创造更高价值。

数据通过 ETL（提取转换加载器） 进入数仓，然后提供报告以及分析性查询。

状态化流处理

几乎所有数据都是以连续事件流的形式产生。

请思考下，我们app 的所有数据的产生，是不是本质上都是事件流。

事实上,现实世界中很难找到那种瞬间就生成完整数据集的例子。作为一类面向无限事件流的应用设计模式,状态化流处理适用于很多应用场景。

状态：能够存储和访问中间结果。任何一个处理事件流的应用，如果要支持跨多条记录的转换操作，都必须是有状态的。

Flink会将应用状态存储在本地内存或嵌入式数据库中。由于采用的是分布式架构，Flink需要对本地状态予以保护。以避免因应用或机器故障导致数据丢失。Flink会定期将应用状态的一致性检查点（checkpoint）写入远程持久化存储。因此当我们有任务停掉，再重新打开，是可以从停掉的那个时刻进行恢复的。

状态流处理能干啥

事件驱动型应用

事件驱动型应用是一类通过接收事件流触发特定应用业务逻辑的有状态的流式应用。根据业务逻辑不同，这类应用，可以接收事件处理操作，同时也可以将事件写到输出流，以供其他同类应用消费使用。

典型的场景：

• 实时推荐(例如在客户浏览商家页面的同时进行产品推荐)。

• 用户画像更新

事件驱动型应用利用事件日志进行通信

优点：

• 访问本地状态的性能比读写远程数据存储系统更好 也就是说，其数据存储在本地（通过checkpoint和远程同步），对某些事件的反应时不需要访问远程数据库，从而速度快很多。

• 伸缩和容错交由流引擎完成

• 以事件日志作为应用的输入，完整可靠，还支持精准的数据重放

Flink 完美支持

数据管道

数据存在多个副本，这些数据存储系统之间需要保持同步。

定时ETL更新，延迟会高。

投放数据小时数据更新，多份数据源，进行聚合后更新。

Flink 完美支持

流式分析

实时看板的构建，低粒度的聚合。

Flink 完美支持

流处理架构的演进

初代流引擎

典型代表就是Storm，并未针对流式应用的结果的准确性和一致性提供内置保障，结果完全取决于事件到达的时间和顺序。 此外，虽然数据在出错时不会丢失，但可能被处理多次。和批处理相比，第一代开源流处理引擎通过牺牲结果的准确度来换取低延迟。

Lambda架构

lambda架构在传统周期性批处理架构的基础上添加了一个由低延迟流处理引擎所驱动的提速层。在该架构中,到来的数据会同时发往流处理引擎和写入批量存储。流处理引擎会近乎实时地计算出近似结果,并将其写入提速表中。批处理引擎周期性地处理批量存储的数据,将精确结果写入批处理表,随后将提速表中对应的非精确结果删除。为了获取最终结果,应用需要将提速表中的近似结果和批处理表中的精确结果合并。

问题：

• 两套api，两套处理，工作量大

• 流处理结果只是近似的

• 更高的吞吐和更完善的故障处理保障 是要以增加处理延迟为代价的。

• 处理结果依旧是依据的时间到来的时间和顺序。

新一代流处理引擎

解决了结果对事件到来时间及顺序的依赖问题。结合精确一次故障恢复语义,这一代系统才称得上第一批能够计算精确一致结果的开源流处理引擎。由于只需依靠实际数据计算结果,此类系统可以将历史数据当做“实时”数据进行处理。它的另一项改进是无需让用户在延迟和吞吐之间做出困难的抉择。前几代的流处理引擎只能在高吞吐和低延迟之间二选其一,而第三代的系统可以兼顾两者,这使得lambda架构彻底沦为历史。

Flink快览

• 同时支持事件时间和处理时间语义。事件时间语义能够针对无序事件提供一致、精确的结果;处理时间语义能够用在具有极低延迟需求的应用中。

• 提供精确一次的状态一致性保障。

• 在每秒处理数百万条事件的同时保持毫秒级延迟。基于flink的应用可以扩展到数千核心之上。

• 层次化的AP I 在表达能力和易用性方面各有权衡。

• 同时也是一个成熟的批处理引擎

• 。。。。

流处理的简析

俯瞰flink

Flink 的组件交互过程

Dataflow 模型

Dataflow 程序描述了数据如何在不同操作之间流动。这是一切的基础。

逻辑图

物理图

这里的逻辑图是站在更高的视角上去看待我们执行的逻辑。为了执行dataflow 程序，需要将逻辑图转化成物理图，后者指定程序执行的细节。

并行的概念。

JobGraph& ExecutionGraph

在flink中，程序直接映射成逻辑图,到具体执行环节时，我们还要考虑并行子任务的分配、数据在任务间的传输，以及合并算子链的优化。为了说明最终应该怎样执行一个流处理程序，Flink 需要将逻辑流图进行解析，转换为物理数据流图.在这个转换过程中，有几个不同的阶段，会生成不同层级的图，其中最重要的就是作业图（JobGraph）和执行图（ExecutionGraph）。Flink 中任务调度执行的图，按照生成顺序可以分成四层：

逻辑流图（StreamGraph）→ 作业图（JobGraph）→ 执行图（ExecutionGraph）→ 物理图（Physical Graph）。

作业图（JobGraph）

StreamGraph 经过优化后生成的就是作业图（JobGraph），这是提交给 JobManager 的数据结构，确定了当前作业中所有任务的划分。主要的优化为: 将多个符合条件的节点链接在一起合并成一个任务节点，形成算子链，这样可以减少数据交换的消耗。JobGraph 一般也是在客户端生成的，在作业提交时传递给 JobMaster。

执行图（ExecutionGraph）

JobMaster 收到JobGraph 后，会根据它来生成执行图（ExecutionGraph）。ExecutionGraph是 JobGraph 的并行化版本,也就是我们的物理图，是调度层最核心的数据结构。

数据流上的操作

对数据流的各种操作，获取、转换,以及输出，这些算子，最后组成的dataflow 图。

• 无状态的操作：处理事件时无需依赖己处理过的事件。事件处理互不影响且与事件到来的时间无关

• 有状态的操作：需要维护之前接收的事件信息。所以需要对状态进行高效划分,并且在出错时需进行可靠的故障恢复。

转换操作

转换操作是一类“只过一次”的操作,它们会分别处理每个事件。这些操作逐个读取事件,对其应用某些转换并产生一条新的输出流。典型的就是flatmap 操作。

数据流既可以一分多，同时也可以多合一来改变我们的dataflow 结构。

滚动聚合

如求和、求最小值和求最大值。聚合操作都是有状态的,它们通过将新到来的事件合并到已有状态来生成更新后的聚合值。

窗口操作

窗口操作，就是将无界的数据流转化成有界的数据流在进行处理操作。

会话窗口，滚动窗口，滑动窗口；

简单举例。。。

窗口的思考

窗口的操作和流处理的两个核心概念存在着密切的关系。一个是时间，另外一个是状态；

时间在流处理的概念中应该是最重要的一个方向，低延迟可以打败很多对手，但流处理的真正价值远不止提供快速分析，如何处理数据的乱序以及延迟到达是一个非常重要的操作。而且流处理应该要支持可以事件重放也非常重要。同时，窗口的操作，毫无疑问，都需要在生成结果数据前缓存数据的。实际上如果想要在流式应用上，做哪那么做任何一个简单的操作，都是需要维护好状态，才能保证出错的时候，进行可靠的恢复的。所以无法做到状态的维护，一切都是没有意义的。

时间

当无界的数据流出现的时候，时间的概念就显的尤为重要了，我们需要下一分钟的指标，那么下一分钟在流式应用的概念是什么呢？

处理时间

处理时间是当前流处理算子所在机器上的本地时钟时间。

事件时间

事件时间是数据流中事件实际发生的时间,它以附加在数据流中事件的时间戳为依据。

水位线

如果按照事件处理作为参考标准，在数据传输中，受到网络延迟、背压等多种因素影响造成数据乱序。在进行窗口处理时，不可能无限期的等待延迟数据到达。

watermark本质上是一个时间戳，且是动态变化的，会根据当前最大事件时间产生。watermarks具体计算为：

watermark = 进入 Flink 窗口的最大的事件时间(maxEventTime)—指定的延迟时间(t)

可以提问：考虑完窗口，时间和水位线后，处理时间的窗口还有有用吗？

状态

大部分的流式应用都是有状态的。很多算子都会不断地读取并更新某些状态。通常意义上,函数里所有需要任务去维护并用来计算结果的数据都属于任务的状态。可以把状态想象成任务的业务逻辑所需要访问的本地或实例变量。

我们的算子需要注册我们的状态；

检查点&故障恢复

Flink是通过数据流的重放和Checkpoint机制来实现容错。

一个checkpoint记录着数据流中某个时刻所有算子对应的状态。Flink的容错机制会对分布式的数据流连续的绘制快照，并将状态进行存储，当因为机器、网络或软件故障等原因导致Flink应用程序失败的时候，数据流可以从最近一次成功的Checkpoint进行恢复，同时通过恢复算子的状态并从checkpoint的那个点重放记录来保持数据处理的一致性（精确一次的处理）。

总结

全文其实没有提到flink 是做什么的。