流/批/OLAP 一体的 Flink 引擎介绍|青训营笔记

这是我参与「第四届青训营 -大数据场」笔记创作活动的的第1篇笔记

1.1.Hadoop成功的原因

1. 时机：Web2.0时代的到来
2. 开源：互联网时代下，开发者已被开源社区完全洗脑，开源的Hadoop的影响力显著
3. 商业：Hadoop找到了合适的盈利模式

2.2.Flink的分层架构

1. SDK层：主要包括3类：SQL、DataStream、Python
2. Runtime层：提供统一的DAG，描述数据处理的Pipeline
3. 状态存储层：存储算子的状态信息
4. 资源调度层：将DAG转换成分布式环境下的Task，Task间通过Shuffle传输数据

1.3.Flink的整体架构

1. JobManager(JM)
2. TaskManager(TM)

2.1.为什么需要流批一体

在app等情景中，有时需要实时统计信息，比如当前视频的观看人数、点赞量、评论数，这些数据需要快速的计算出来。 而有些数据，并不需要快速的计算出来，比如视频当天的播放次数或者当天的收入，这时，快速的计算反而会加重计算的负担。

2.2.流、批业务场景的特点

流式计算：需要在1s之内计算出结果(acmer直呼内行)，常用于广告推荐或者金融风控这些对数据的实时性要求较高的场景当中 批式计算：处理时间在分钟~天级别，因此采用离线计算，常用于搜索引擎构建索引、视频播放量等更新周期长的场景中

2.3.Flink如何做到流批一体

对于Flink,Everything is Streams,批式计算和流式计算都是数据流，理论上可以采用一套引擎架构解决不同场景中遇到的问题 Flink在流批一体上，从上面的API到底层的处理机制都是统一的 支持EAGER和LAZY两种调度模式

3.1.OLAP对Flink的架构优化

OLAP计算是一种特殊的批式计算，对并发式和实时性要求更高，也可以与流式计算和批式计算采用一套引擎架构

3.2.Flink做OLAP的优势和挑战

优势：引擎统一、生态支持、既有优势 挑战：作业频繁启停、资源碎片、秒级及毫秒级的小作业、Latency+QPS的要求