文章目录
-
-
- 12.Flink
-
- [12.1 Flink简介](#12.1 Flink简介)
- [12.2 为什么要选择Flink](#12.2 为什么要选择Flink)
- [12.3 Flink应用场景](#12.3 Flink应用场景)
- [12.4 Flink技术栈、体系架构和编程模型](#12.4 Flink技术栈、体系架构和编程模型)
- [12.5 Flink的安装和编程实战](#12.5 Flink的安装和编程实战)
-
12.Flink
12.1 Flink简介
-
企业的处理架构已经由传统数据处理架构和大数据Lamda架构向流处理架构演变
-
Flink实现了Goole Dataflow模型，具有高吞吐，高性能，低延迟的特点
- 同时支持批处理和流处理
-
Flink的主要特征：
- 批流一体化
- 精密的状态管理
- 事件时间支持
- 精确一次的状态一致性保障
-
Flink不仅支持在YARN、Mesos、Kubernetes多种资源管理框架之上，也支持在裸机集群上独立部署
-
再启用高可用选项后，它不存在单点失效问题
-
Flink可以扩展到数千核心，状态可以达到TB级别，仍然能够达到高吞吐、低延迟的特性
12.2 为什么要选择Flink
-
传统的数据处理架构
-
传统的数据处理架构的特点：使用中心化数据库系统来存储事务性数据
-
-
大数据Lambda架构
-
随着企业数据量的不断增长，关系型数据库已经无法满足海量数据的存储需求
-
越来越多企业借助Hadoop、MapReduce、Spark等来处理分析数据仓库中的数据【仓库中的数据是采用周期性加载的方式】
-
Lambda架构方案：处理不同类型的数据；以满足企业不用应用的需求
Lambda架构需要同时管理两套系统：可能会导致复杂度过高、运维成本高的问题
-
流处理架构
-
让数据记录持续的从数据源流向应用数据，并在各个应用程序之间持续流动
-
流处理架构分为消息传输层和流处理层
-
消息传输层：从各种数据源采集连续事件产生的数据，并传输订阅给这些数据的应用程序
-
流处理层：持续地将数据在应用程序和系统间移动，聚合并处理事件，并在本地维持应用程序的状态；
-
应用程序的状态指的是流数据产生的中间计算结果
-
流处理架构的核心：是使得各种应用程序互联在一起的消息队列
流数据处理架构正在取代传统的数据处理架构和Lamda架构，成为大数据处理架构的新趋势
*- 流处理计算框架丢弃了大型集中式数据库，避免了数据库不堪重负
- 将批处理看成流处理的子集，这样可以使用流处理框架解决批处理问题
- 因此流处理框架就同时集成了流计算和批量计算
-
-
-
-
Flink是理想的流计算框架
-
Flink的高级特性
- 提供有状态的计算
- 支持状态管理
- 支持强一致性的语义
- 支持对消息乱序的处理
-
Flink的优势
-
同时支持高吞吐、低延迟、高性能
-
同时支持流处理和批处理
-
高度灵活的流式窗口
-
一个窗口是若干元素的集合，流计算以窗口为基本单位进行数据处理
-
可分为时间驱动的Time Window【每隔相同时间】
-
或者数据驱动的Count Window【相同数据量】
-
窗口可以分为：翻滚窗口（Tumbling Window,无重叠）；滚动窗口（Sliding Window,有重叠）;以及会话窗口（Session Window）
-
-
-
支持有状态计算
-
无状态计算
-
有状态计算：需要基于多个事件来输出结果
-
-
具有良好的容错性
- 容错机制：通过创建分布式数据流快照：即轻量、高频率、性能影响小
-
具有独立的内存管理
-
Flink独立管理JVM内存，获得C一样的性能、避免内存溢出的发生
-
Flink使用序列化和反序列化将所有数据对象转化为二进制在内存中存储，其有效的降低数据存储空间，有效利用内存空间，降低了垃圾回收机制造成的性能下降和任务异常
-
-
支持迭代和增量迭代
-
对于迭代来说，有时并不是单次迭代产生的结果都需要进入下一个迭代
-
如果只需要重新计算部分数据，选择性地更新解集，就是增量迭代
-
增量迭代可以使一些算法执行的更高效
-
可以使得算法专注于"热点"数据部分，使得大部分数据冷却的非常快，数据规模将大幅度减小
-
-
-
-
Flink设计思想
12.3 Flink应用场景
-
Flink常见场景
- 事件驱动型应用
- 数据分析应用
- 数据流水线应用
-
事件驱动型应用：具有状态的应用
-
从一个或者多个事件数据流中读取数据，并根据到来的数据作出反应，如触发计算、状态更新、其他外部动作
-
事件驱动型应用：从传统的应用设计进化而来
-
传统的应用设计：包括独立的计算和数据存储层，应用会从远程事务数据库中读取数据
-
事务驱动型应用：是建立在有状态流处理应用之上，数据和计算不相互独立，应用放在本地的磁盘，就可以获取数据
-
-
传统应用和事件驱动型应用架构的区别
-
典型的事件驱动型应用
-
事件驱动型应用的优势
- 只访问本地数据，不需要查询远程数据库，无论是在吞吐量还是延迟方面，都能获得更好的性能
- 向一个远程的持久化存储周期性地写入检查点，可以采用异步或者增量的方式，因此检查点对于常规的事件处理影响是很小的
- 它不仅局限于本地数据访问，而是适合远程访问
-
事件驱动型应用：Flink的优势
-
Flink支持丰富的状态操作原语
-
管理大量的数据（可以达到TB级别）
-
确保"精确一次"的一致性
-
支持事件时间、高度可定制的窗口逻辑和细粒度的时间控制
以帮助实现高级的商业逻辑
-
-
-
Flink有复杂时间处理（CEP）类库，可以检测数据流模式
-
Flink作为事件驱动型的突出特性：
-
保存点（savepoint）:它是一个一致性的状态镜像，相互兼容应用的初始化点；给定一个保存点之后可以放心对应用进行升级和扩容
还可以启动多个应用，以完成A/B测试
-
-
数据分析应用
-
分析应用会从原始数据中提取信息，得到富有洞见的观察
-
传统的数据分析：会先进行事件数据记录，然后在有界的数据集上进行数据分析
-
若需要将最新的查询应用到数据分析中，需要将最新的数据添加到查询集，然后重新运行查询，查询结果会被写入到存储系统中，或者形成报表
-
-
对于高级流处理引擎，需要进行实时数据分析：它读取实时事件流，连续产生和更新查询结果
这些结果或者被保存在外部数据库中，或者作为内部数据被维护，若需要查询结果
-
Flink同时支持批量分析和流式分析
-
典型的数据分析应用
-
连续流式分析的优势
-
消除了周期性的导入和查询，从事件中获取洞察结果的延迟会更低
-
流式查询不需要处理输入数据中人为产生的边界
-
流式分析具有更加简单的应用架构
-
一个批量分析的流水线会有独立组件，来周期性调度数据提取、查询执行，其操作起来复杂
一个组件失败就会直接影响到流水线中的其他步骤
-
运行在高级流处理器上的流式分析应用（如Flink）:会将数据提取到连续结果的所有步骤整合起来，可以依赖底层引擎提供的故障恢复机制
-
-
-
Flink如何支持数据分析应用
因此不管应用在静态数据集和实时数据流上运行SQL查询，都能得到相同的结果
-
Flink可以自定义处理逻辑：通过DataStream API和DataSet API
-
Flink的Gelly库：为批量数据集的大规模高性能图分析提供了算法和构建模块
-
-
-
数据流水线应用
-
ETL（Extract-transform-load）:存储系统之间转换和移动数据的常见方法
-
数据流水线：转换、清洗、转移数据，但是采用的是连续流模式，而不是周期性的触发
-
数据流水线工作方式
或：
-
典型的数据流水线应用
-
数据流水线的优势
- 减少了数据转移过程中的延迟
- 持续消费和发送数据，因此用途更广，支持用例也更多
-
Flink如何支持数据流水线的应用
-
Flink可以解决许多常见的数据转换问题
-
大量连接器，连接不同类型的数据存储系统
-
Flink提供了连续型数据源，用于监控目录变化
-
Flink提供数据槽sink,以时间分区的方式写入文件
-
-
12.4 Flink技术栈、体系架构和编程模型
-
Flink核心组件栈
-
物理部署层（底层）
- 可以采用Local模式运行，启动单个JVM
- 或者可以采用Standalone的集群模式运行，或者YARN的集群模式运行
- 还可以运行在GCE(谷歌云服务)、EC2(亚马逊云服务)
-
Runtime核心层（核心实现层）：对上层不同接口提供基础服务
- 其提供了两套API:DataStream API用户流处理，DataSet API用于批处理
-
APIs&Libraries层
- 其除了两套接口之外，还抽象出不同类型的组件库
- CEP:基于流处理的复杂事件处理库
- SQL&Table库：既可以支持流处理，又可以支持批处理
- FlinkML:基于批处理的机器学习库
- Gelly:基于批处理的图计算库
-
-
Flink的体系架构
-
执行Flink程序
-
JobClient将作业提交给JobManager
-
JobManager需要负责资源分配和作业执行，首先进行资源分配，分配完成之后，任务将提交给相应的TaskManager
-
TaskManager启动线程开始执行
-
TaskManager执行过程中会向bManager报告状态更改，如开始执行、进行中、完成等
-
JobManager的作业执行完成之后，结果将返回给客户端
-
-
-
Flink 编程模型
-
最低级的接口：状态化的数据流接口，这个接口通过过程函数集合和DataStream API中
该接口允许用户自由处理多个流中的事件
并使用一致的容错状态
用户也可以通过注册事件时间和处理回调函数来执行复杂的计算
-
大部分应用不需要底层抽象，而是针对核心API进行编程
- DataStream API：针对有界或者无界的流数据
- DataSet API：针对有界数据集
这些API为数据处理提供了大量、通用的模块，如：转换、窗口、连接、聚合等
DataStream API ：集成底层的处理函数 对一些处理操作提供更低层次的抽象
DataSet API: 对有界数据集提供格外的支持 如循环和迭代
-
Table API：以表为中心，能够动态修改表；是一个扩展的关系模型
表是二维数据结构，类似关系数据库中的表
API提供了可比较的操作，如：select、project、join、group-by、aggregate等
Table API程序定义的是应该执行什么样的逻辑操作，而不是直接准确地制定程序代码的运行步骤
尽管Table API可以通过用户自定义函数（UDF）进行扩展，它在表达能力上还是不如核心API，但是其使用起来更加简洁（代码量更少）Table API设置了内置优化器进行优化，用户可以在表和DataStream、DataSet之间进行无缝切换
且允许核心API和TableAPI的混合使用
-
最高级接口：SQL
-
其在语法和表达能力上与Table API类似，唯一的区别是通过SQL查询语言实现程序
-
SQL API可以直接在Table API上定义的表上执行
-
-