浅谈一下流式处理平台(Flink)
大数据框架听过很多,比如 Hadoop,HDFS...不过自己的项目都没有上过
为什么突然提到 Flink,因为最近一个项目需要用到,所以学习最好的方式就是项目驱动
以前总觉得自己要学会了某样东西再去做,等学会了,也许又用不上,久而久之,又忘了
下面我结合项目,浅谈一下 Flink
01、Flink 入门
百度一下:Flink 是什么?
上面的介绍我们每个字都看得懂,但连在一起就看不懂了。
不管怎么样,至少我们知道了:Flink 是一个分布式的计算处理引擎。
- 分布式:它的存储或计算交由多台服务器完成,最后汇总起来达到最终的效果。
- 实时:处理速度是毫秒或者秒级的。
- 计算:可以简单理解为是对数据进行处理。
什么是有边界和无边界?
Apache Flink 是一个框架和分布式处理引擎,用于在*无边界和有边界*数据流上进行有状态的计算。
官网其实也有介绍,但对初学者来说不太好理解,我来幼儿园化一下。
大家应该都用过消息队列吧,Producer 生产数据,发给 Broker,Consumer 消费,完事。
在消费的时候,我们需要知道 Producer 发了多少条消息吗?什么时候发的吗?不需要吧。反正你来一条,我就处理一条,没毛病吧。
这种没有做任何处理的消息,默认就是无边界的。
那有边界就很好理解了嘛:无边界的基础上加上条件,那就是有边界的。
加什么条件呢?比如我要加个时间:我要从3月22号到3月23号的数据,那就是有边界的。
什么时候用有边界,什么时候用无边界?那也很好理解,
我做数据清洗:来一条,我处理一条,这种无边界就好了。
我要做数据统计:每小时的pv
(page view)是多少,那我就设置1小时的边界,攒够1小时我再来处理。
在Flink上,设置“边界”这种操作叫做开窗口(window
),窗口可以简单分为两种类型:
-
时间窗口(
TimeWindow
):按照时间窗口对数据进行聚合,比如上面说的1小时一次。 -
计数窗口(CountWindow):按照指定的条数来做聚合,比如攒够10条数据处理一次。
听着就很人性化(妈妈再也不用担心我需要聚合了)
不仅如此,在Flink
使用窗口聚合的时候,还考虑到了数据的准确性问题。
比如:我在 11:06分
产生了5
条数据,在11:07
产生了4
条数据,我现在是按时间窗口每分钟来做聚合的。
理论上来讲:Flink
应该在 11:06分
聚合了5条
数据,在11:07
聚合了4条
数据。
但是,可能由于网络的延迟性原因,导致11:06分
有3条
数据在11:07
才接收到,如果不做处理,就造成了 06分
处理3条
,07分
处理7条
。
这个结果对于需要准确性的场景来说,就太不合理了。所以Flink
可以给我们指定时间语义
,不指定默认是数据到Flink的时候(Process Time
)来进行处理。我们可以指定聚合时间为事件发生的时间(Event Time)来进行处理。
事件发生时间就是:日志真正记录的时间。
2020-11-22 00:00:02.552 INFO [http-nio-7001-exec-28] c.m.t.rye.admin.web.aop.LogAspect
虽然指定了聚合时间为事件发生的时间(Event Time),但还是没解决数据乱序的问题(06分产生了5条数据,实际上06分只收到了3条,而剩下的两条在07分才收到,那此时怎么办呢?在06分时该不该聚合,07分收到的两条06分数据怎么办?)
Flink
又给我们设置了水位线(waterMarks)
Flink
的意思就是:存在网络延迟等情况导致数据接受不是有序,这种情况我能理解,那你设置一个延迟时间吧,等延迟时间到了,我再做统一聚合。
比如我设置延迟时间为1分钟
,等到07分
的时候,我再对 06分
的窗口做聚合处理。
什么叫有状态?
Apache Flink 是一个框架和分布式处理引擎,用于在无边界和有边界数据流上进行有状态的计算。
无状态我们可以理解为:每次的执行都不会依赖以前的执行结果,每次的执行都是独立的。
有状态就很好理解了:每次的执行都依赖上一次的执行结果。
举个栗子:我们现在要统计文章的阅读pv
(page view),现在只要有一个点击了文章,在kakfa
中就会有一条消息。现在我要在流式处理平台上进行统计,那此时是有状态还是无状态的?
比如说:我用Redis
对结果进行存储,来一条数据,我就先查一下Redis
目前的值是多少,然后在当前值的基础上累加一下就完事了。
假设用Flink
做,Flink
本身就提供了这种功能给我们使用,我们可以依赖Flink
的“存储”,将每次的处理结果交给Flink
处理。
可以简单的认为:Flink
本身就给我们提供了“存储”的功能,我们的每次执行是可以依赖Flink
的“存储”的,所以它是有状态的。
那Flink
是把这些有状态的数据存储在哪的呢?
主要有三个地方:
- 内存
- 文件系统(HDFS)
- 本地数据库
如果Flink
挂了,可能内存的数据没了,磁盘可能存储了部分的数据,那再重启的时候,就不怕数据丢失吗?
看到这里,你可能会在别的地方看过Flink
的另外一个比较出名的特性:精确一次性(exactly once)
什么是精确一次性(exactly once)?
众所周知,流的语义性有三种:
- 精确一次性(exactly once):有且只有一条,不多不少
- 至少一次(at least once):至少有一条,只多不少
- 最多一次(at most once):最多有一条,可能没有
Flink
的精确一次性指的是:状态(这个状态指上面提到的有状态)只持久化一次到最终介质中(本地数据库/HDFS...)
以上图为例:假设我的 source
有以下数字21,13,8,5,3,2,1,1
,然后在Flink
中做一个累加操作。
现在已经处理完2,1,1
了,所以累加的 sum = 4
,现在Flink
把状态 sum 已经存储到最终介质中去了
然后开始处理5,3
,得到的 sum = 12,但是 Flink
还没来得及把 12
存储到最终介质中 就挂了。
Flink
重启后会重新把系统恢复到 sum = 4
的状态,所以5,3
得继续计算一遍。
所以 Flink
的精确一次性指的就是:状态只持久化一次到最终介质中(本地数据库/HDFS...)
至于Flink
是在多长时间存储一次,是我们自己手动配置的。
根据上面的代码,我们可以发现,设置存储的时间在Flink
中叫做 CheckPoint
。
所谓的 CheckPoint
就是 Flink
会在指定的时间段上保存状态的信息,如果Flink
挂了,可以直接将上一次保存的状态信息捞出来,继续执行计算,最终实现(exactly once
)。
那CheckPoint
是怎么实现的呢?
想想我们使用 kafka 在业务上的至少一次是怎么实现的:我们从 kafka 上面拉取数据,处理完业务后,手动提交 offset
(告诉kafka
我已经处理完了)
我们是做完了业务后才将offset
进行 commit
的, checkpoint
其实也是一样的(等拉下来的数据全部处理完,才进行真正的 checkpoint
)
那Flink
是怎么知道拉下来的数据已经走完了呢?
Flink在流处理过程中插入了 barrier,每个环节处理到 barrier 都会上报给 sink,等所有的 barrier 都上报了,说明这次的 checkpoint
已经走完了
02、什么是流式处理平台
举个例子,比如商家要在平台上投放广告,我们要给商家看到广告带来的效果,最核心的就是 「曝光量」「点击量」「订单量」
下面来聊一下这个「发展历程」,看完这个过程或许可以更好的了解为什么需要流式处理平台
1、PHP阶段:在最初时,业务以及系统结构都比较简单,直接把「曝光量」「点击量」「订单量」存入数据库,再一把梭通过定时任务进行全量聚合,得到最终的效果数据。
在这个阶段里,由于数据量不大,通过定时任务全量来做聚合数据也不算不可以,那时候商家都能接受业务的延迟性,大概5min出数据。
2、Java阶段:随着业务发展,数据量日益提升,站内中间件服务平台也发展起来了。通过中间件团队提供的消费 binlog框架,从架构上改变聚合模式。这个阶段可以更快的给商家展示效果数据,大概1min出数据。
3、流式处理平台阶段:流式处理平台是对「计算」或者说是处理数据时的抽象,在这抽象基础上,它更能充分利用系统的资源(一个大的任务拆分成多个小任务,分发到不同的机器上执行),大概秒级出数据。
02、项目哪些地方用到了 Flink
我所做的项目是一个消息发送系统,Flink 用于对「消息发送者」「模板消息」等维度作聚合处理,得到的数据再给到接口去展示或者排查问题使用,能大大提高排查方和业务方的使用效率
最后,给大家安利一个公众号:Java3y,备注【项目】,进群一起跟着 3y 做项目,项目就是当前的消息发送系统,公众号上还有很多面试资料,快冲啊。