• 人民邮电出版社

第一章 为何选择Flink

• 竞品：SparkStreaming/Storm/Samza/Apex

• Lambda架构(不懂为何叫Lambda)
  https://ask.hellobi.com/blog/transwarp/5107

• 在大型分布式系统各种，数据一致性和对事件发生顺序的理解必然都是有限的。

• 来源德语：快速、灵巧

• Flink将批处理（有限的静态数据）视作一种特殊的流处理

  
  image.png

• Flink Runtime是核心引擎，直接基于此的程序冗长编写费力——提供API

  
  20190120113636940.png

第二章 流处理架构

• 传统分布式的问题：
  1. 数据到达分析阶段的流程复杂缓慢
  2. 都需要访问数据库，数据架构单一
  3. 复杂的异常处理，难以保证异常出现后系统的正常运行
  4. 实际数据与状态数据的一致性

image.png

1. 消息传输层（Kafka或者MapR Streams）

• 从生产者采集连续事件产生的数据，并传输给订阅了的app和服务

2. 流处理层

• 持续将数据在app和系统间移动

• 聚合、处理事件

• 在本地维持app的状态

• 兼具高性能和持久性（消息重播，而非到流处理层后就消失了）

• 解耦生产者和消费者（消息立刻到达，但无需立刻处理——支持多、微服务）

第三章 Flink用途

1. 计算用户连续访问时长（解决了刚工作时遇到的一个痛点——用python脚本分析用户在JZB_App上的访问时长。当时问题很多，除了数据处理的缓慢，内存消耗，如何定义连续访问都很麻烦，没法确定哪种是最好的，否则就要每个定义都计算一份数据）

• 如果使用微批处理，可能人工定义的计算窗口与会话窗口不吻合
• Flink可以设置非活动阈值——可以根据真实情况设置计算窗口

2. Flink优势——能够区分这两类时间

• 事件事件——实际发生时间（容易实现计算的正确性）
• 处理时间——开始被程序处理

3. 故障后保持准确

• 检查点checkpoint机制

第四章 对时间的处理

批处理

定期运行批处理作业，实现应用持续性。数据被持续地分割为文件（比如每小时一单位），作业以文件作为输入

• 缺点
  1. 太多独立部分（太多系统——数据分割摄取、计算、调度 依赖混淆，都要需要时间概念；学习成本和bug）
  2. 时间处理方法不明确（比如改为半小时一次）
  3. 预警（需要通过增加Storm实时提供近似计数，这样就变成Lambda了）
  4. 乱序事件流（到达数据中心的顺序和实际发生顺序）
  5. 批处理作业时间界限不清洗（分割点前后的时间，以及要分析时间段聚合结果无法满足）

流处理

柱状为kafka.png

• 流即是流不必人为分割
• 时间定义被写入应用程序代码（时间窗口等），而非牵扯到多个模块

流处理中的批处理

• 批处理只作为提高系统性能的机制。批量越大，系统吞吐量越大
• 为提高性能使用的批处理必须完全独立于定义窗口时用的缓冲，或者为了保证容错性而提交的代码，也不能作为API的一部分。否则系统将受到限制，难以使用且脆弱。
  （有点不好理解）

时间

• 事件时间，带有时间戳的记录
• 处理时间，处理事件的机器测量的时间
• 摄取时间/进入时间，进入流处理框架的时间

时间窗口

支持滚动和滑动

滚动.png

stream.timeWindow(Time.minutes(1))

滑动.png

stream.timeWindow(Time.minutes(1), Time.seconds(30))

计数窗口

采用计数窗口时，分组依据不再是时间戳，而是元素的数量。滚动和滑动的计数窗口分别定义如下。

stream.countWindow(4)
stream.countWindow(4, 2)

假设计数窗口定义的元素数量为 100，而某个 key 对应的元素永远达不到 100 个，那么窗口就永远不会关闭，被该窗口占用的内存也就浪费了。

会话窗口

可方便处理用户连续访问页面时长的问题（通过设定间隔时长）。

stream.window(SessionWindows.withGap(Time.minutes(5))

时空穿梭

image.png

很有用：调试或者重新处理数据。但需要流处理器支持事件时间，否则结果会不同（机器时间不同了）

水印

当计算基于事件时间时，如何判断所有的事件已到达？需要依靠由数据驱动的时钟而非系统时钟。
比如滚动窗口中，计算10:00:00-10:01:00的事件，因为时间戳就是数据，那如何判断是否存在某个10:00:59的元素还没到呢？

Flink 通过水印来推进事件时间。水印是嵌在流中的常规记录，计算程序通过水印获知某个时间点已到。水印使事件时间与处理时间完全无关。

水印由应用程序开发人员生成，需要领域知识。启发式水印可能出错。

第五章 有状态的计算

image.png

一致性

流处理一致性三个级别（对于故障发生后的恢复能力）：

• at-most-once: 计数结果可能丢失，没有能力
• at-least-once: 计数结果>=正确值（Storm/Samza）
• exactly-once: 计数结果=正确值 (Strorm Trident/ Spark Streaming)
  Flink——既保证exactly，也有低延迟高吞吐

检查点

• 保证exactly-once的机制，在出现故障时将系统重置回正确状态。
  总体而言就是在数据流中嵌入检查点，遇到检查点时记录检查点的位置与此时的计数状态，以方便在遇到故障时恢复最近的状态并重跑检查点后的数据。
  详情可见（也是部分图源）：
  http://www.linkedkeeper.com/1415.html