这是我参与「第四届青训营 」笔记创作活动的的第3天
以下是课堂上做的笔记：
大数据
特征
value、volumes、velocity、variety
架构
-
Hadoop 分布式、MapReduce、离线计算
-
Spark 批处理、流处理、SQL高阶API（取代MapReduce）、内存迭代计算
-
Flink（云计算） 实时、流批一体、支持SQL
流式计算
大数据计算架构变化：批式计算（离线计算，有限数据集）----->流式计算（实时计算，无线数据集）
几大流式计算框架对比
说明：
- Sparksteaming：将无限流切成无限小的批（mini-batch）
- Storm：可能会被多处理/可能一次都没有处理到 （At Least Once/At Most Once）
Flink
Flink定位
- 分布式
- 状态计算
- 通过底层抽象，无边界、有边界数据集都能处理，因此可以流批一体
Flink社区生态
分层架构
整体架构
-
JobManager(JM)
-
TaskManager(TM) 关系如下：
作业处理流程
如图所示：
并发执行
分布式执行
关于流批一体
为什么？
举例：业务场景：
直播实时统计xx量：Flink流式处理
统计以天为单位的数据：批式处理
传统数据分开处理（实时放Flink，离线放Hive、Spark）的劣势：
- 重复开发
- 重复运行
- 两套数据存在误差
如何做？
Everything is streams.
批式计算可看作流式计算的特例（有界数据集是一种特殊的数据流）
1.12及以前版本的Scheduler层：
- EAGER：集中所有资源（流式）
- LAZY：（批式）
最新版本
Pipeline
BLOCKING、PIPELINED
整体结构
Shuffle简介
-
广义：分布式计算中涉及到上下游衔接的过程
-
实现方式：
- 基于文件( Pull Based Shuffle)
容错性和稳定性强，适合大规模批处理
如：Spark MR
- 基于Pipeline(Push Based Shuffle)
不存储数据，低延迟，高性能
如：Flink，Storm,Presto
-
流和批的Shuffle差异性
- 流和批的Shuffle有共性--->Flink的Shuffle Service框架抽象出公共模块
- Netty Shuffle Service: Flink默认,支持pipeline 和blocking两种
- Remote Shuffle Service:支持pipeline 和blocking两种
电商流批一体实践：
原有架构：
目标架构：
Flink架构优化
流/批/OLAP(交互式）一体化
可行性：批式计算可看作流式计算的特例，OLAP是批式计算的特例
Flink-OLAP架构
-
现状
-
问题
架构上：
- JM与RM在同一进程内，无法对JM水平扩展
- Gateway与Flink Session Cluster互相独立，无法进行统一管理
应用上：
- JM 处理和调度作业时，单作业处理时间长，占用过多内存
- TM 部署计算任务时，初始化耗时严重，消耗大量CPU
- 资源流程链路过长
- 资源管理完全依赖于RM
