这是我参与「第四届青训营 」笔记创作活动的第3天
本次笔记重点内容
-
- Apache Flink 概述
-
- 流批一体的 Apache Flink 架构
-
- Apache Flink 的 OLAP 场景面临的问题及优化思路
-
- Flink 使用案例
什么是大数据？
是在信息化时代背景下，由于信息交互，信息存储，信息处理能力大幅增加而产生的数据，无法在一定时间内通过常规软件工具对其进行获取、存储、管理和处理的数据集合。
数据价值密度低，但是总体价值非常高；每天每个人都在产生数据，大量又迅速。
Flink框架为什么能脱颖而出？
Flink是流式计算框架，符合业内对于实时性的更高需求，且流批一体，都能支持sql的使用。
流式计算框架对比：
- Exactly-Once：精确一次的计算语义
- 状态容错：运行中间出现failed，状态不会丢失，可以重启恢复状态
Apache Flink
Apache Flink是一个框架和分布式处理引擎，用于在无界（有一个开始，但没有定义的结束）和有界（具有定义的开始和结束）数据流上进行有状态计算。
Flink分层架构：
软件开发工具包有三个，支持sql、python环境；执行引擎（runtime）层提供了统一的有向无环图（DAG）来逻辑的描述数据处理业务的工作流，调度层把DAG转化成分布式环境下的各个task，通过Shuffle交互上下游数据，State Backend可以存储算子状态信息，多种环境下的资源管理部署由Resource Manager实现。
- JobManager（JM）负责整个任务的协调工作，包括：调度 task、触发协调 Task 做 Checkpoint、协调容错恢复等
- TaskManager（TM）负责执行一个DataFlow Graph的各个task
作业示例
①从简单的逻辑执行图到并发执行图（假设sink算子并发配置为1，其余为2）：
注意：有keyBy的逻辑时是不知道要“走”哪里的，可能会按哈希值分配，如map()[1]可以走key()[1]/[2]，但Source[1]是固定的语义走map()[1]。
②分布式执行：
每个task可以在一个线程中执行，两个算子当成一个线程处理，减少线程切换和数据的序列化/反序列化，
流批一体
- 批式计算：一批数据到齐才开始处理，按小时/天等周期性计算
- 流式计算：实时对用户产生的数据进行计算，持续运行
为什么需要流批一体？
原来架构的缺点：批、流两套系统，相同逻辑需要开发和运行两遍，产生资源浪费，且算子、UDF也是两套，会产生不同程度的误差，给业务带来困扰。
Flink从哪些模块做流批一体？
- SQL层
- DataStream API层
- Scheduler层
- Failover Recovery层
- Shuffle Service层
On-Line Analytical Processing-OLAP 交互式分析
在线分析处理，是数据仓库系统最主要的应用，专门用于支持复杂的分析操作，可以根据分析人员的要求快速、灵活地进行大数据量的复杂查询处理。
与流批的最大区别：要求高并发查询+极致处理性能
Flink做OLAP的优势
引擎统一，都支持sql接口，降低了用户的学习成本，提高了开发和维护效率，Flink本身的特点和三性的架构与OLAP非常匹配，在生态方面，Flink支持众多搜索引擎，从很多地方可以读取数据。
问题与挑战：
- OLAP会产生大量秒级和毫秒级的小作业，对于流批式的Flink来说要针对这一方面进行特定优化，否则将产生许多资源碎片，造成浪费
- Flink要在Latency和QPS前提下提供较高的并发调度和执行能力
电商流批一体
数据源导入Kafka，先经过Flink预处理，同步到Hive仓库，可走Flink Batch和Stream两条路处理，保证了数据源一致性，同一个Flink引擎减少了开发和运维成本
