Flink整体架构(下)| 青训营笔记

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

Flink做到流批一体

流批一体的重要性

举个例子:

  1. 在抖音中,实时统计一个短视频的播放量、点赞数,也包括抖音直播间的实时观看人数等;
  2. 在抖音中,按天统计创造者的一些数据信息,比如昨天的播放量有多少、评论量多少、广告收入多少;

即如果实时统计则是流式计算处理的场景

按天统计则是批式计算处理的场景

image-20220729152451271

实时数仓——流式

离线数仓——批式

上述架构有一些痛点:

  1. 人力成本比较高:批、流两套系统,相同逻辑需要开发两遍;
  2. 数据链路冗余:本身计算内容是一致的,由于是两套链路,相同逻辑需要运行两遍,产生一定的资源浪费;
  3. 数据口径不一致:两套系统、两套算子、两套UDF,通常会产生不同程度的误差,这些误差会给业务方带来非常大的困扰。

流批一体的挑战

流和批业务场景的特点: image-20220729154035486

批式计算相比于流式计算核心的区别如下表:

image-20220729154110566

Flink做到流批一体

  1. 批式计算是流式计算的特例,Everything is Streams,有界数据集(批式数据)也是一种数据流、——一种特殊的数据流; 因此,理论上我们是可以用一套引擎架构来解决上述两种场景,只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。

  2. image-20220729154647062

    这是归纳的效果图,

    由下往上看,首先Flink是一个流式的引擎,里面有一个最基本的重要就是everything is strean,它有一些自己的特点,比如说它是一个内存的计算,一个that once也是一个框架,基于最基本的抽象是可以认为批示数据也是一种特殊的一种流式计算,special streaming processing的一种计算,因为它的数据是有界的,仅仅是这个差异,

    然后基于这个之上的话,在特性这块,然后Flink又支持了一些比如说更加灵活的一些调度策略,既可以去做一些流的调度,也能做一些批的调度,可以把这两种不同的计算模式的调度模型给统一。

  3. 站在Flink的角度,Everything is Streams,

    无边界数据集是一种数据流,一个无边界的数据流可以按时间切段成一个个有边界的数据集,所以有界数据集(批式数据)也是一种数据流。

    因此,不管是有边界的数据集(批式数据)还是无边界数据集,Flink都可以天然地支持,这是 Flink支持流批一体的基础。并且Flink在流批一体上,从上面的API到底层的处理机制都是统一的,是真正意义上的流批一体。

  4. Apache Flink主要从以下几个模块来做流批一体:

    1. SQL层;
    2. DataStream API层统一,批和流都可以使用DataStream API来开发;3. Scheduler层架构统一,支持流批场景;
    3. Failover Recovery层架构统一,支持流批场景;
    4. Shuffle Service层架构统一,流批场景选择不同的 Shuffle Service;
posted @ 2022-08-01 10:42  Luciferpluto  阅读(1)  评论(0)    收藏  举报  来源