admin管理员组文章数量:1589236
在聊实时计算之前,先说一下我对离线和批量、实时和流式的一些看法。
我们首先来简单看一下计算任务的大致流程:
首先先说下批量计算和流式计算:
图中显示了一个计算的基本流程,receiver处负责从数据源接收数据,并发送给下游的task,数据由task处理后由sink端输出。
以图为例,批量和流式处理数据粒度不一样,批量每次处理一定大小的数据块(输入一般采用文件系统),一个task处理完一个数据块之后,才将处理好的中间数据发送给下游。流式计算则是以record为单位,task在处理完一条记录之后,立马发送给下游。
假如我们是对一些固定大小的数据做统计,那么采用批量和流式效果基本相同,但是流式有一个好处就是可以实时得到计算中的结果,这对某些应用很有帮助,比如每1分钟统计一下请求server的request次数。
那问题来了,既然流式系统也可以做批量系统的事情,而且还提供了更多的功能,那为什么还需要批量系统呢?因为早期的流式系统并不成熟,存在如下问题:
1.流式系统的吞吐不如批量系统
2.流式系统无法提供精准的计算
后面的介绍Storm、Spark streaming、Flink主要根据这两点来进行介绍。
批量和流式的区别:
1.数据处理单位:
批量计算按数据块来处理数据,每一个task接收一定大小的数据块,比如MR,map任务在处理完一个完整的数据块后(比如128M),然后将中间数据发送给reduce任务。
流式计算的上游算子处理完一条数据后,会立马发送给下游算子,所以一条数据从进入流式系统到输出结果的时间间隔较短(当然有的流式系统为了保证吞吐,也会对数据做buffer)。
这样的结果就是:批量计算往往得等任务全部跑完之后才能得到结果,而流式计算则可以实时获取最新的计算结果。
2.数据源:
批量计算通常处理的是有限数据(bound data),数据源一般采用文件系统,而流式计算通常处理无限数据(unbound data),一般采用消息队列作为数据源。
3.任务类型:
批量计算中的每个任务都是短任务,任务在处理完其负责的数据后关闭,而流式计算往往是长任务,每个work一直运行,持续接受数据源传过来的数据。
离线=批量?实时=流式?
习惯上我们认为离线和批量等价;实时和流式等价,但其实这种观点并不完全正确。
假设一种情况:当我们拥有一个非常强大的硬件系统,可以毫秒级的处理Gb级别的数据,那么批量计算也可以毫秒级得到统计结果(当然这种情况非常极端,目前不可能),那我们还能说它是离线计算吗?
所以说离线和实时应该指的是:数据处理的延迟;批量和流式指的是:数据处理的方式。两者并没有必然的关系。事实上Spark streaming就是采用小批量(batch)的方式来实现实时计算。
可以参考下面链接:https://www.oreilly/ideas/the-world-beyond-batch-streaming-101。
整理了一份适合2018年学习的大数据资料需要的加群QQ群:834325294 注明CSDN既可免费获取作者是Google实时计算的负责人,里面阐述了他对批量和实时的理解,并且作者认为批量计算只是流式计算的子集,一个设计良好的流式系统完全可以替代批量系统。本人也从中受到了很多启发。
介绍完这些概念后,下面我们就来简单看看目前流行的实时计算框架的实现和区别。
Storm
Storm做为最早的一个实时计算框架,早期应用于各大互联网公司,这里我们依然使用work count举例:
spout:负责从数据源接收数据
bolt:负责数据处理,最下游的bolt负责数据输出
spout不断从数据源接收数据,然后按一定规则发送给下游的bolt进行计算,最下游的bolt将最终结果输出到外部系统中(这里假设输出到DB),这样我们在DB中就可以看到最新的数据统计结果。Storm每一层的算子都可以配置多个,这样保证的水平扩展性。因为往往处理的是unbound data,所以storm中的算子都是长任务。
容灾是所有系统都需要考虑的一个问题,考虑一下:假如运行过程中,一个算子(bolt)因某种原因挂了,Storm如何恢复这个任务呢?
版权声明:本文标题:实时计算——聊一聊我所经历的计算框架 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://www.elefans.com/xitong/1728049335a1143493.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论