这是我参与「第四届青训营 」笔记创作活动的第2天。

1、为什么需要流批一体

1）业务场景

①实时场景：在抖音中，需要实时统计一个短视频的播放量、点赞数，或是统计抖音直播间的实时观看人数，亦或是统计新春红包发放、领取情况。

②非实时场景：对于抖音创作者来说，需要按天统计创作者的一些数据信息，比如昨天的播放量、评论量、广告收入有多少。

2）传统解决方案

①数据源：可理解为APP使用过程中的各种行为数据

②实时数仓：针对实时场景的解决方案，使用Flink进行流式处理。将原始数据导入Kafka（常用的流式存储系统）里，Flink再对Kafka里的数据进行清洗、统计（比如视频点赞、播放量），再将处理后的结果导入服务层，通过服务层向抖音业务提供数据展示。

③离线数仓：针对非实时场景的解决方案。原始数据导入到Kafka后，通过Kafka落入hive中，按天数统计创作者数据，最后通过服务层向用户提供数据查询。

3）传统架构的痛点

①人力成本高：流是一套系统（Flink），批是另一套系统（Spark/hive）。有些场景下的逻辑可能是一样的，但是由于框架不同，一些限制也会不同，需要依照相同的逻辑开发两遍。比如在Flink中开发的UDF（自定义函数）代码，需要在Spark中再开发一遍。

②浪费计算资源：逻辑一致、计算内容一致，但由于是两套链路，需要计算两遍，造成资源浪费。

③数据口径不一致：两套系统、两套算子、两套UDF，通常会产生不同程度的数据误差，给业务方带来很大的困扰。

4）流/批计算的区别

①业务场景区别

②核心区别

流式计算数据集是无限数据集，所以流式计算是7*24h不间断执行；批式计算是有限数据集，算完这一个小时的数据，任务就结束了，等到下个小时的数据到齐后，再开启计算任务。

流式计算在任何一个时间点出现延迟，业务端都会有感知；批式计算实时性要求不高，比如24号的数据，业务方只要求在25号中午12：00更新，因此可以根据资源情况调整计算任务的调度时间，保证结果按时产出即可。

2、如何做到流批一体

1）理论支持

批式计算可以理解为流式计算的特例，有界数据集可以理解为一种特殊的数据流。

因此，理论上可以用一套引擎架构来解决不同的业务场景，只不过需要对不同的业务场景支持相应的扩展性，并允许做不同的优化策略。

2）Flink如何做到流批一体

在Stream Engine层，它认为everything is stream，无边界数据集是一种数据流，一个无边界的数据流可以按时间段切成一个个有边界的数据集，所以有界数据集也是一种数据流。同时，在内存计算中，Stream Engine能保证每个任务只执行一次。

在Batch Engine层，它认为批是一种特殊的流。支持了更丰富的调度策略，既能做流的调度，也能做批的调度，把两种不同计算模式的调度给统一了。可插拔的shuffle service ，允许不同场景走不同的shuffle service 去计算，流走一种shuffle service，批走另一种shuffle service。

Flink在流批一体上，从上面的API到底层的处理机制都是统一的，是真正意义上的流批一体。

3、个人总结

重点在于了解流式计算、批式计算的区别，以及为什么能够做到流批一体。