Flink基础教程
2019-12-16 11:05:36 0 举报AI智能生成
Flink基础教程中文版全章节脑图
作者其他创作
大纲/内容
1. 为何选择Flink
1.1 流处理欠佳的后果
1.2 连续事件处理的目标
1. 可以容错，而且能保证exactly once
2. 没有数据错误的时候不产生太大开销
3. 系统容易操作和维护
4. 系统生成的结果需要和事件实际发生的顺序一致
5. 能够准确的替换流数据
1.3 流处理技术的演变
1.4 初探Flink
Flink是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架
同时支持exactly once 语义和高吞吐的实时计算，还能提供批处理
流处理的DataStreamAPI和批处理的DataSetAPI
1.5 生产环境中的Flink
1.6 Flink的适用场景
2. 流处理架构
2.1 传统架构与流处理架构
传统架构：采用存储事务性数据的中心化数据库系统
问题1：大型分布式系统的计算复杂度不断上升，该架构已不堪重负
问题2：需要通过在大型系统中不断的更新来维持一致的全局状态
流处理架构：以流为基础的架构设计让数据记录持续的从数据源流向应用程序，并在应用程序间持续流动
没有一个数据库来集中存储全局状态数据，取而代之的是共享且永不停止的流数据
每个应用程序都有自己的数据，这些数据采用本地数据库或分布式文件进行存储
2.2 消息传输层和流处理层
消息传输层
从各种数据源（生产者）采集连续事件产生的数据，并传输给订阅了这些数据的应用程序和服务（消费者）
Kafka和MapR Streams
流处理层
用途1：持续的将数据在应用程序和系统间移动
用途2：聚合并处理事件
用途3：在本地维持应用程序的状态
Flink、SparkSteaming、Storm、Samza、Apex
2.3 消息传输层的理想功能
2.3.1 兼具高性能和持久性
持久性使得消息可以重播，从而让Flink这样的处理器能对事件流中的某一部分进行重播和再计算
2.3.2 将生产者和消费者解耦
消息传输系统Kafka、MapR Streams
2.4 支持微服务架构的流数据
2.4.1 数据流作为中心数据源
流处理架构不需要集中式数据库，取而代之的是消息队列，它作为共享数据，服务于不同的消费者
2.4.2 欺诈检测：流处理架构用例
以欺诈检测为例，消息队列中的刷卡行为数据可以分别被更新器、刷卡行为分析器和其他消费者分别使用，互不影响
2.4.3 给开发人员带来的灵活性
2.5 不限于实时应用程序
实时更新仪表盘
使用消息队列中的数据更新本地数据库或者搜索文件
消息队列中的数据往往必须被流处理器聚合或者分析并转换后才输出到数据库中
2.6 流的跨地域复制
跨数据中心的流复制能力扩展了流数据和流处理的用途
3. Flink的用途
3.1 不同类型的正确性
3.1.1 符合产生数据的自然规律
计算窗口的定义符合数据产生的自然规律
Flink可以根据真实情况设置计算窗口
3.1.2 事件时间
为了获得最佳计算结果，系统需要能够通过数据找到事件发生时间，而不是只采用处理时间
Flink能区分不同类型的时间是跟其他流处理系统相比的一个优势
3.1.3 发生故障后仍保持准确
检查点（check point）是Flink能够按需重新处理数据的关键
故障恢复
运行新模型
修复bug
Flink的检查点特性在流处理器中是独一无二的，它使得Flink可以准确的维持状态，并且高效的重新处理数据
3.1.4 及时给出所需结果
在某些应用场景下，低延迟也属于正确性的一种。如手机导航
3.1.5 使开发和运维更轻松
完备的语义简化了开发工作，进而降低了出错率
Flink还承担了跟踪计算状态的任务，从而减轻了开发人员负担，简化了编程工作，提高了应用程序的成功率
用同一种技术来实现流处理和批处理，大大的简化了开发和运维工作
3.2 分阶段采用Flink
先实现简单的应用程序，熟悉后再在公司内推广
4. 对时间的处理
4.1 采用批处理架构和Lambda架构计数
批处理架构的问题
为了计算数据中的事件数，用了太多独立的系统，学习和管理成本很高，易错
对时间的处理方式不明确
无法及时预警
无法处理乱序事件流
现实中事件流大都是乱序的，即事件的实际发生顺序可能和数据中心所记录的顺序不一样，这意味着原本属于上一批的事件可能会被错误的归入当前一批
批处理作业界限不清晰
分割时间点原则上应该取决于各系统之间的交互，而批处理只能做到大约每小时分割一次
Lambda架构
用定期运行的批处理作业来实现应用程序的持续性，并通过流处理器获得预警，流处理器提供实时近似计算结果，批处理最终对近似结果进行纠正
本质上仍为批处理架构，存在批处理架构的多个缺点
4.2 采用流处理架构计数
消息传输系统为流处理器提供流数据，产生的结果既是实时的，也是正确的
Flink作业的速度减慢或者吞吐量激增只会导致事件在消息传输系统中堆积
以时间为单位把事件分割为一批批任务的逻辑完全嵌入在Flink程序的应用逻辑中
预警由同一个程序产生，乱序事件由Flink自行处理
要从以固定时间分组改为根据产生数据的时间段分组，只需在Flink程序中修改相应的时间窗口即可
与批处理的区别：1. 流即是流，不必人为的将它分割为文件 2. 时间的定义被明确的写入程序代码，而不是与摄取、计算、调度等过程牵扯不清
4.3 时间概念
事件时间
事件实际发生的时间
处理时间
事件被处理的时间
摄取时间/进入时间
事件进入流处理框架的时间
乱序
现实世界中，许多因素（如连接中断、网络延迟、分布式系统中时钟不同步、数据速率陡增、物理原因等）使得事件时间和处理时间存在偏差（即事件时间偏差）。事件时间顺序和处理时间顺序通常不一致，这意味着事件以乱序到达流处理器
Flink允许用户根据所需语义和对准确性的要求选择采用事件时间、处理时间或摄取时间定义窗口
4.4 窗口
4.4.1 时间窗口
最有用的一种窗口，支持滚动和滑动
4.4.2 计数窗口
依据元素数量定义，也支持滚动和滑动
4.4.3 会话窗口
会话指的是活动阶段，其前后都是非活动阶段。
Flink中会话窗口由超时时间设定
4.4.4 触发器
触发器控制生成结果的时间，即何时聚合窗口内容并将结果返回给用户
每一个默认窗口都有一个触发器。例如，采集事件时间的窗口将在收到水印时触发。用户可以自定义触发器
4.4.5 窗口的实现
开窗机制与检查点机制完全分离
高级用户可以直接用基本的开窗机制定义更复杂的窗口形式。如：某种时间窗口，它可以基于计数结果或某一条记录的值生成的中间结果
4.5 时空穿梭
流处理架构拥有时空穿梭的能力。因为支持事件时间，这意味着将数据流“倒带”，用同一组数据重新运行同样的程序，会得到相同的结果
4.6 水印
为了追踪事件时间，需要依靠由数据驱动的时钟，而不是系统时间
Flink通过水印来推进事件时间，水印是嵌在流中的常规记录，计算程序通过水印获知某个时间点已到
水印如何生成
4.7 真是案例：爱立信公司的Kappa架构
5. 有状态计算
5.1 一致性
一致性的三个级别
at-most-once
at-least-once
exactly-once
最先保证exactly once 的流处理框架（Storm Trident和Spark Streaming）在性能和表现力两个方面付出了很大代价。而Flink既保证了exactly once，也具有低延迟和高吞吐的处理能力
5.2 检查点：保证exactly once
当Flink数据源遇到检查点屏障时，它会将其在输入流中的位置保存到稳定存储中。这让Flink可以根据该位置重启输入
Flink检查点的正式名称是异步屏障快照，该算法大致基于Chandy-Lamport分布式快照算法
5.3 保存点：状态版本控制
用户可以基于保存点有意识的管理状态版本。
保存点与检查点的工作方式完全相同，只不过其由用户通过Flink命令或Web控制台手动触发，而不是由Flink自动触发
保存点应用
应用程序代码升级
如修复bug
Flink版本更新
从保存点处用新版本的Flink重启任务
维护和迁移
使用保存点轻松的暂停和恢复应用程序，方便集群维护和迁移
有利于开发、测试、调试，因为不需要重播整个事件流
假设模拟与恢复
A/B测试
5.4 端到端的一致性和作为数据库的流处理器
Flink的可查询状态特性，可以简化应用程序架构，对于状态本身就是所需信息的查询来说，直接查询状态可以提升性能
5.5 Flink的性能
通过避免流处理瓶颈，同事利用Flink的有状态流处理能力，吞吐量可以达到Strom的30倍，同时还能保证exactly once和高可用性。大致来说，Flink的硬件成本或云计算成本仅为Storm的1/30, 同样的硬件能处理的数据量是Storm的30倍
6. 批处理：一种特殊的流处理
6.1 批处理技术
Flink通过一个底层引擎同时支持流处理和批处理
Flink通过在流处理器中整合高效、大规模的批处理所需的大部分优化方案来提高效率
6.2 案例研究：Flink作为批处理器
Flink的执行过程是基于流的，意味着各个处理阶段有更多的重叠，并且混洗操作时流水线式的，因此磁盘访问操作更少。测试显示，在使用Flink时系统空闲时间和磁盘访问操作更少
职业：工程师
0 条评论
下一页
