这是我参与「第四届青训营 」笔记创作活动的第2天
大数据（Big Data）：指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合。
流式计算与批式计算
- 流式计算：需要在1s之内计算出结果，常用于广告推荐或者金融风控这些对数据的实时性要求较高的场景当中
- 批式计算：处理时间在分钟~天级别，因此采用离线计算，常用于搜索引擎构建索引、视频播放量等更新周期长的场景中
为什么需要流式计算
大数据的实时性带来价值更大，比如：
- 监控场景：如果能实时发现业务系统的健康状态，就能提前避免业务故障
- 金融风控：如果实时监测出异常交易的行为，就能及时阻断风险的发生
- 实时推荐：比如在抖音，如果可以根据用户的行为数据发掘用户的兴趣、偏好，就能向用户推荐更感兴趣的内容
为什么需要流批一体
在app等情景中，有时需要实时统计信息，比如当前视频的观看人数、点赞量、评论数，这些数据需要快速的计算出来。而有些数据，并不需要快速的计算出来，比如视频当天的播放次数或者当天的收入，这时，快速的计算反而会加重计算的负担。
传统架构存在如下痛点:
- 人力成本比较高:流、批两套系统，相同逻辑需要开发两遍；
- 数据链路冗余:本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费；
- 数据口径不一致:两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。
计算架构发展史
发展过程：Hadoop --> Spark --> Flink 传统：单机模式、黑箱使用。
- Hadoop：分布式、离线计算、Map-Reduce。
- Spark：批处理、流处理、内存迭代计算，相较于Hadoop有更高阶的SQL API，逐渐取代了Map-Reduce。
- Flink：流计算、实时、流批一体。由于实际业务对计算实时性要求变高，因此流处理框架Flink逐渐变为主流。
Flink的分层架构
- SDK层：主要有三类：SQL/Table、DataStream、Python
- 执行引擎层（Runtime 层）：提供统一的DAG，描述数据处理的Pipeline
- 状态存储层：存储算子的状态信息
- 资源调度层：将DAG转换成分布式环境下的Task，Task间通过Shuffle传输数据
Flink的整体架构
一个Flink集群,主要包含以下两个核心组件:
- JobManager(JM):负责整个任务的协调工作,包括:调度task、触发协调Task做Checkpoint、协调容错恢复等。
- TaskManager(TM):负责执行一个DataFlowGraph的各个task以及data streams的buffer和数据交换。
在执行过程中，Client端会将Program code中用户的代码经过处理会转换一个抽象的逻辑执行图(DAG图)并提交给JM，JM将其转化为具体的物理执行图，此外，JM还会根据物理执行图对应的任务调度把对应的task交给TM的Task Slot中去执行。 每个TM是一个进程，每个TM中用户可以定义若干个Task Slot，每个Task Slot就相当于一个线程，在TM里每个Slot中的cpu、内存等资源没有严格的隔离。
Flink如何做到流批一体
对于Flink,Everything is Streams,批式计算和流式计算都是数据流，理论上可以采用一套引擎架构解决不同场景中遇到的问题。Flink在流批一体上，从上面的API到底层的处理机制都是统一的，支持EAGER和LAZY两种调度模式。
OLAP介绍
OLAP计算是一种特殊的批式计算，对并发式和实时性要求更高，其他情况与普通批式作业没有特别大区别，可以与流式计算和批式计算采用一套引擎架构。
Flink做OLAP的优势和挑战
- 优势：引擎统一、生态支持、既有优势
- 挑战：作业频繁启停、资源碎片、秒级及毫秒级的小作业、Latency+QPS的要求
