这是我参与「第四届青训营 」笔记创作活动的第5天。
1、流/批/OLAP对比
1）业务场景对比
①Stream：在抖音中，实时统计一个短视频的播放量、点赞数，以及直播间的实时观看人数。
②Batch：在抖音中，按天统计创作者的播放量、评论量、广告收入。
③OLAP（交互式分析） ：在抖音的一些推广活动中，运营需要对一些实时产出的结果数据做一些实时多维分析，来帮助后面活动的决策。比如春节当天有5波红包雨，根据第1波红包雨的数据，调整第2波红包雨的运营策略。
2）特性对比
批式计算一天只要请求一次；流式计算请求一次之后一直在运行，不需要那么高的并发去提交作业；OLAP则需要同时并行处理很多请求（高并发是OLAP的特点）
3）OLAP是特殊的批式计算
OLAP对并发和实时性要求更高，其他情况与普通的批式作业没有特别大区别，因此OLAP是特殊的批式计算。
而批式计算又是特殊的流式计算，因此可以用一套引擎解决流/批/OLAP这三种场景。
OLAP通常面临的是秒级、毫秒级的小作业，1s就能执行完作业，但这一秒可能要同时执行二三十个作业，并且接下来会不断创建新作业。作业频繁启停，会产生资源碎片，增加资源开销。
因此需要对OLAP场景支持相应的扩展性和优化策略。
2、流/批/OLAP一体
1）Flink OLAP 架构现状
Client：提交SQL Query。
（Flink SQL）Gatetay：接收Client提交的SQL Query，对SQL进行语法解析和查询优化，生成Flink作业执行计划，提交给Session集群。类似于流计算中的Client能够对代码进行优化，并转化为DAG提交给JM。
Session Cluster：执行作业调度及计算，并返回结果。正常的一个Flink流作业，JM起来后去申请资源，如果作业Q掉了，整个集群的资源就销毁了，可以认为这一个集群，就只有这一个Flink Job。而Flink还有一种作业模式，叫Session Cluster，先把集群给创建出来，比如一台机器作为JM，十台机器作为TM，这样作业提交过来之后，无需等待资源申请，JM（已经有了十台机器的资源）可以直接执行作业调度，节约了性能，非常适合OLAP场景。
2）Flink OLAP架构的问题与设想
①架构与功能模块
JobManager与ResourceManager在一个进程内启动，无法对JM进行水平扩展。JM是负责维护作业提交和分发的工作，RM是负责资源申请的工作，而OLAP需要提升高并发的能力，希望能对JM进行水平扩展。比如3个JM共用1个RM，但当前架构并不支持。
Gateway与Session Cluster互相独立，无法进行统一管理，增加额外的管理工作。
②作业管理及部署模块
JM处理和调度作业时，负责的功能比较多，导致单作业处理时间长、占用过多内存，影响高并发场景下的性能。比如JM在解析完作业的DAG之后会生成物理执行计划，物理执行计划的最小单位为计算任务，JM管理了所有的计算任务，包括每个TM之间的连接关系。
TM部署计算任务时，任务初始化部分耗时严重，消耗大量CPU。流/批只要初始化一次，但是OLAP高并发场景需要频繁初始化，因此对初始化部分的耗时很看重。
③资源管理及计算任务调度
资源申请及资源释放流程链路过长。JM→RM→TM→RM→JM才能做资源调度。TM中的slot作为资源管理单元，但JM看不到TM维度的资源分布，使得资源管理完全依赖于RM，因此在JM端很难做复杂优化。
④其他
作业心跳与Failover机制，并不适合AP（OLAP）这种秒级或毫秒级计算场景。
AP目前使用Batch算子进行计算，这些算子初始化比较耗时。
个人总结
本文对比了流/批/OLAP的业务场景和特性，并指明OLAP计算是特殊的批式计算。介绍了Flink OLAP 架构的现状，并提出Flink OLAP架构的问题与设想。
