大数据篇:如何区分流处理和批处理

大数据篇:如何区分流处理和批处理

今天我们来讲讲大数据的处理模式:批处理(Batching Processing)和流处理(Streaming Processing)。

这几年大规模的物联网(IoT)数据监控系统和视频流系统等的大数据系统出现,已经是必然现象了,我相信在5G的推动下,这类些系统会越来越多。

在我们开发过程中也会时常的跟这些数据打交道,所以明白其处理方式也是必要的。

这些数据被抽象成两种数据,分别是有边界数据(Bounded Data)和无边界数据(UnBounded Data)

有边界数据和无边界数据

无边界数据

无边界数据,其实就是一种可增长,无限的数据集。

我们无法判断他到底会在什么时候结束。例如:我们生活中的支付宝中的交易数据,每时每刻都会有数据产生,无法判断它什么时候会停止发送。

在这里插入图片描述

我们也可以称他为”流数据(Streaming Data)“。

有边界数据

有边界数据,其实就是一种保存好了的数据,例如数据库中的数据或者csv中的数据等

拿我们之前的交易数据来说,如果按照一定的时间窗口,拿取一小部分数据,那么提取出来的数据也是有边界数据了。例如我提取2019年08月19日这天地数据来做处理,我们提取出来地这份数据就是有边界数据。

这里说到了时间窗口,那么我们下面就介绍下两个关于时间的时域吧,他们分别是事件时间处理时间

事件时间和处理时间

事件时间(Event Time)指的是一个数据实际产生的时间,处理时间(Precessing Time)指的是这条数据实际被处理数据的系统接收的时间。

下面我们通过一个例子更了解事件时间和处理时间。

例如:我打开淘宝准备购物,在12点05分下了单,由于进入车库没信号,导致这个订单一直在重试支付,直到我离开车库,提示支付成功,这时的时间是12点08分。这里的12点05分就是事件时间,而12点08分就是处理时间,这样你是否明白了呢?

下面我们就进入主题批处理流处理

批处理和流处理

批处理

数据的批处理,可以理解为一系列相关的任务按顺序或并行的,一个接一个地执行。批处理地输入是在一段时间内收集好地数据。每次批处理地输出都可以是下次批处理地输入。

大部分情况下,批处理地输入数据和输出数据都是有边界数据。所以在批处理中,我们更关注地事件事件。

举个例子,你在年初的时候,很多“大厂”都会对你这一年所做的事情做一次分析,得到一些有趣的事情。下面我们以网易云音乐为例子:

在这里插入图片描述

每年的网易云音乐都会将我们过去一年中听取的歌曲记录存储起来,作为批处理的数据来源,经过一系列的分析计算得到一份有趣的数据作为数据输出。

在大部分情况,批处理任务会被安排,并在预先设定好的事件间隔来执行。例如:一年、一个月、一天的特定时间。

网易云音乐的日推也是根据批处理系统,以预先设定好的一天的时间间隔运行,而产生出来的。

批处理的系统架构通常会被设计在以下这些应用场景中:

  • 日志分析:日志系统是在一定时间段内收集的。而日志系统的数据处理分析是在不同的时间内执行的,以得到系统的关键性指标(例如之前说的准确性和系统容量等)。
  • 计费的应用程序:计费应用程序会计算出一段时间内一项服务的使用程度,并生成计费信息,例如支付宝花呗的还款账单。
  • 数据仓库:数据仓库的主要目标是根据收集好的数据事件时间,将数据信息合并为静态快照(static snapshot),并将它们聚合为每周、每月、每季度的报告等。

像现在的Apache Hadoop或者是Apache Spark等开源框架都是支持这种大数据批处理架构的。

由于批处理一般都具有高延迟性,有可能计算需要几小时、几天甚至是几周的时间。所以对实时性比较有要求,那么应该考虑使用流处理的方式处理数据。

流处理

数据的流处理可以理解为系统需要接收并处理一系列连续不断变化的数据。例如,音视频的实时推荐、周边推荐等。

流处理的输入基本都是无边界数据。而流处理系统中是关心事件时间还是处理时间一般是随应用场景而定的。

例如,像网页监控系统这样的流处理系统要计算网站的QPS,它关心的更多是处理时间,也就是网页请求数据被监控系统接收到的时间,而计算QPS。而在一些医疗护理监控系统的流处理系统中,他们则关心数据的事件时间,这种系统不会因为网络延迟而忽略系统原本产生的时间。

流处理的特点应该是足够快、低延迟、以及来自各种数据源的大规模数据。流处理所需的响应时间更应该以毫秒(或秒)来进行计算。向我们平时用到的搜索引擎,系统必须在用户输入关键字后以毫秒级的延时返回搜索结果给用户。

流处理快的原因,是因为他是在数据未达到磁盘时计算的,也就是在内存中计算的。

当流处理架构拥有一定时间间隔(毫秒)内产生逻辑上正确的结果,这种架构可以被定义为实时处理(Real-time Processing)。

当一个系统可以接收以分钟为单位的数据处理时间延时,我们可以把它定义为准实时处理(Near Real-time Processing)。

还记得我们说过批处理架构的不足之处吗?没错,那就是高延迟性。而我们的流处理架构恰恰拥有低延迟和高吞吐等特点。

下面介绍几个流处理的应用场景:

  • 实时监控:捕获和分析各种来源发布的数据,入传感器,新闻源,点击网页等。
  • 实时商业只能:智能汽车,智能家居,智能病人护理等。
  • 销售终端(POS)系统:像是股票价格的更新,允许用户实时完成付款的系统。

如今开源的生态圈中,入Apache Kafka、Apache Storm、Apache Flink、Apache Samza等都是流行的流处理架构平台。

经过介绍你不难发现,无论是批处理模式还是流处理模式,在现实中都是广泛的被使用,而采用哪种处理模式,则应当由使用场景决定。

总结

像是对不需要实时分析结果的情况下,其实批处理是一个很好的选择。特别是业务逻辑十分复杂,数据量大的时候,更容易从数据中挖掘到有用的信息。

而对应用的实时分析处理有要求的情况下,或者数据传输的结束时间、数据量无法确定的情况下,就可以采用流处理的处理架构来完成这件事情

名言:难走的路,从不拥挤

下一章:Workflow设计模式

  • 12
    点赞
  • 67
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值