- 人民邮电出版社
第一章 为何选择Flink
-
竞品：SparkStreaming/Storm/Samza/Apex
-
Lambda架构(不懂为何叫Lambda)
https://ask.hellobi.com/blog/transwarp/5107 -
在大型分布式系统各种，数据一致性和对事件发生顺序的理解必然都是有限的。
-
来源德语：快速、灵巧
-
Flink将批处理（有限的静态数据）视作一种特殊的流处理
image.png
-
Flink Runtime是核心引擎，直接基于此的程序冗长编写费力——提供API
20190120113636940.png
第二章 流处理架构
- 传统分布式的问题：
- 数据到达分析阶段的流程复杂缓慢
- 都需要访问数据库，数据架构单一
- 复杂的异常处理，难以保证异常出现后系统的正常运行
- 实际数据与状态数据的一致性
image.png
- 消息传输层（Kafka或者MapR Streams）
- 从生产者采集连续事件产生的数据，并传输给订阅了的app和服务
- 流处理层
-
持续将数据在app和系统间移动
-
聚合、处理事件
-
在本地维持app的状态
-
兼具高性能和持久性（消息重播，而非到流处理层后就消失了）
-
解耦生产者和消费者（消息立刻到达，但无需立刻处理——支持多、微服务）
第三章 Flink用途
- 计算用户连续访问时长（解决了刚工作时遇到的一个痛点——用python脚本分析用户在JZB_App上的访问时长。当时问题很多，除了数据处理的缓慢，内存消耗，如何定义连续访问都很麻烦，没法确定哪种是最好的，否则就要每个定义都计算一份数据）
- 如果使用微批处理，可能人工定义的计算窗口与会话窗口不吻合
- Flink可以设置非活动阈值——可以根据真实情况设置计算窗口
- Flink优势——能够区分这两类时间
- 事件事件——实际发生时间（容易实现计算的正确性）
- 处理时间——开始被程序处理
- 故障后保持准确
- 检查点checkpoint机制
第四章 对时间的处理
批处理
定期运行批处理作业，实现应用持续性。数据被持续地分割为文件（比如每小时一单位），作业以文件作为输入
- 缺点
- 太多独立部分（太多系统——数据分割摄取、计算、调度 依赖混淆，都要需要时间概念；学习成本和bug）
- 时间处理方法不明确（比如改为半小时一次）
- 预警（需要通过增加Storm实时提供近似计数，这样就变成Lambda了）
- 乱序事件流（到达数据中心的顺序和实际发生顺序）
- 批处理作业时间界限不清洗（分割点前后的时间，以及要分析时间段聚合结果无法满足）
流处理
柱状为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
网友评论