《flink基础教程》读书笔记并附下载链接

因公司发展，需要了解一部分大数据的知识，这周末读了flink基础教程，是阿里专家翻译的，整理了一下自己的读书笔记， 里面Pnumber 是页码。
附上下载链接：
链接: https://pan.baidu.com/s/1YeQ4PKFDEebuJ1j1ySg1Xg 提取码: dwqp

第一章：为何选择flink

1.2 流处理应用：

对数据进行高吞吐、低延迟和准确的处理，比如银行的24小时金融服务，需要及时检测出用户行为异常的应用程序；电信行业，如果不能很好地处理流数据，就不能在某个移动通信基站出现流量高峰前预先将流量分配给其他基站。
除了低延迟和高吞吐，流处理框架还应该有效的处理异常中断，以及对外预警。

1.3 流处理技术演变

• Storm（先锋）很难实现高吞吐。【P18】

• Spark将数据流拆分，如果分割的足够小，计算就能实现真正的流处理。不过间歇性的批处理作业，会导致开发和运维相互交错。完成间歇性的批处理作业所需要的时间和数据达到的时间紧密耦合，任何延迟都可能导致不一致。【P20】

1.4 flink初探

• flink项目理念：为分布式，高性能，随时可用以及准确的流处理应用程序打造的开源刘处理框架。

• 批处理与流处理：flink将批处理（有限的静态数据）视为一种特殊的流处理。

1.5 生产中的flink案例【P25】

第二章：流处理框架

2.1 传统架构与流处理框架

• 依赖数据库作为数据源的架构： 数据到达数据分析所需要的工作流程太复杂、缓慢;

• 数据库是唯一的数据源； 异常问题处理复杂；
  全局状态一致性问题【P29】为什么流处理框架不需要考虑？？？
  流式框架，不存储全局状态数据，每个应用采取本地数据库，或者分布式文件保存自己的数据

2.2 消息传输和流处理层

2.3 消息传输层的理想功能

• 高性能和持久性：持久性可以支持消息重播；

• 生产者和消费者解耦。

2.4 支持微服务架构的流数据

流处理从消息队列中订阅数据并加以处理。处理后的数据可以流向另一个消息队列，其他应用程序可以共享流数据，一些处理后的数据也可以保存在本地数据库中。

2.4.2 流处理架构用例：欺诈检测【P34】

2.5 不限于实时应用【P36】

第三章：flink的用途

3.1 保障不同类型数据的正确性

定义符合自然规律的数据产生窗口：例：追踪网站访问者动态，固定定义数据产生窗口，数据往往是不正确的，利用flink可以设置活动阈值。【P41】
事件时间：flink 可以区分事件产生时间，处理时间等不同类型的时间
发生故障后，仍保持准确：设置检查点，记录中间计算的状态，在故障发生时准确的重置。
及时给出结果：例，计算均值，如果不能及时的算出要求时间内的一段结果，很难说结果是正确的

3.2 分阶段采用flink

第四章： 对时间的处理

流处理和批处理编程，最关键的区别在对于时间的处理。 下面以每小时计数为例。事件流数据（如：微博内容，点击数据、交易数据等）不断产生，
需要用key将数据分组，并每隔一段时间，对一个key事件进行计数。
这是众所周知的“大数据”应用，与mapReduce的词频统计类似。【P46】

4.1 采用批处理架构和Lambda架构计数

批处理架构如下：

• 疑问流式架构与批处理架构完全不一样吗？

该架构问题分析【P47】：

• 太多独立部分：太多系统，系统需要学习和管理成本；

• 对时间处理方式不明确：如果要改为每30min一次，就涉及工作流调度逻辑，使devOps 和业务混淆；

• 预警：除了每小时统计，还应当在数据产生时，及时收到计数预警。为了做到这一点，可以新增一个Storm系统提供近似的计数。这种架构就称之为lambda架构；

• 乱序事件流：事件的实际发生顺序，和数据中心记录的顺序不一样；

• 批处理作业的界限不清晰：在该架构中，“每小时”定义不清晰。如果需要根据产生数据的时间段（如用户的登录到登出）生成聚合结果，就不能满足要求。

4.2 采用流处理架构计数

• 疑问：大量数据在传输系统中，堆积如何解决

流处理与批处理的最主要两点区别：

• 流就是流，不必人为的分割为文件

• 时间的定义，明确的写入应用程序代码，而不是摄取，计算，调度牵扯不清

4.3 时间概念：

• 事件时间：事件发生的时间戳；

• 处理时间：事件被处理的时间；

• 进入时间：事件进入流处理框架的时间

4.4 窗口【P52】

第五章：有状态的计算

5.1 一致性

引入状态，就有一致性问题，在流处理中，一致性分为3个级别：
at-most-once：故障丢失后，计数结果可能丢失；
at-least-once：计数结果可能大于正确值，但不会小于正确值；
exactly-once：故障发生后，计数结果任可以与正确结果一致。
为了保障exactly-once， storm和spark 采用的是同时处理一批记录，保障对一批处理，要么全部成功，要么全部失败。【P62】

5.2 检查点

我的理解：记录下每个检查点的统计数据，异常后， 回滚到上个检查点，并且从保存的计数结果重新开始计数。
会在流数据中间记录下位置， 持久化在存储系统中，确认位置之后，继续处理数据，【P70】异常图。

这边具体的图不放了，大家可以看书。

5.3 保存点：状态版本的控制

检查点是flink自动生成的，
保存点是由用户有意识的创建，类似于快照，用于，系统升级，维护和迁移等。

5.5 flink的性能【P76】

第六章：批处理

批处理是无限流的一种特殊情况