流数据,即数据以大量、快速、时变的流形式持续到达。
流数据具有如下特征:
数据的价值随着时间的流失而降低
对于一个流计算系统来说,它应达到如下需求:
Hadoop 设计的初衷是面向大规模数据的批量处理,在使用MapReduce处理大规模文件时,一个大文件会被分解成许多个块分发到不同的机器上,每台机器并行运行MapReduce任务,最后对结果进行汇总输出。有时候,完成一个任务甚至要经过多轮的迭代。很显然,这种批量任务处理方式在时间延迟方面是无法满足流计算的实时响应需求的。
不可行。
总之,流数据处理和批量数据处理是两种截然不同的数据处理模式,MapReduce是专门面向静态数据的批量处理的,内部各种实现机制都为批处理做了高度优化,不适合用于处理持续到达的动态数据。正所谓“鱼和熊掌不可兼”,想设计一个既适合流计算又适合批处理的通用平台,虽然想法很好,但是实际上是很难实现的。因此,当前业界诞生了许多专门的流数据实时计算系统来满足各自需求。
目前有三类常见的流计算框架和平台:商业级的流计算平台、开源流计算框架、公司为支持自身业务开发的流计算框架
流计算的处理流程一般包含三个阶段:数据实时采集、数据实时计算、实时查询服务
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-otoO8mv7-1631693777310)(C:\Users\张昊\AppData\Roaming\Typora\typora-user-images\image-20201118190758916.png)]
传统的数据处理流程如下图所示,需要先采集数据并存储在关系数据库等数据管理系统中,之后用户便可以通过查询操作和数据管理系统进行交互,最终得到查询结果。但是,这样一个流程隐含了两个前提。
流计算的处理流程如上题图所示,一般包含3个阶段:数据实时采集、数据实时计算、实时查询服务。
数据采集系统的基本架构一般有3个部分。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ycdf85MG-1631693777312)(C:\Users\张昊\AppData\Roaming\Typora\typora-user-images\image-20201118191321823.png)]
对于流计算,一般在Store 部分不进行数据的存储,而是将采集的数据直接发送给流计算平台进行实时计算。传统的数据处理系统采集到数据以后会存储到数据库中后续进行处理。
流计算适合于需要处理持续到达的流数据、对数据处理有较高实时性要求的场景。
随着分析业务对实时性要求的提升,离线分析模式已不适合用于流数据的分析,也不适合用于要求实时响应的互联网应用场景。通过流计算,能在秒级别内得到实时的分析结果,有利于根据当前得到的分析结果及时地作出决策。例如,购物网站的广告推荐、社交网站的个性化推荐等,都是基于对用户行为的分析来实现的,基于实时分析,推荐的效果将得到有效提升。
金融行业。
S4系统和Storm框架的开源也改变了开发人员开发实时应用的方式。以往开发人员在开发一个实时应用的时候,除了要关注处理逻辑,还要为实时数据的获取、传输、存储大伤脑筋,但是现在情况却大为不同。开发人员可以基于开源流处理框架Storm, 快速地搭建一套健壮、易用的实时流处理系统,并配合Hadoop等平台,就可以低成本地做出很多以前很难想象的实时产品。
以往除了要关注处理逻辑,还要为实时数据的 获取、传输、存储大伤脑筋,但是现在开发人员基于开源流处理框架Storm,可以快速搭建一套健壮、易用的实时流处理系统。
实时系统和 批处理系统组成的分层数据处理架构。
实时分析、在线机器学习、持续计算、远程RPC等。
Tuple即元组,是元素的有序列表。
Spouts和Bolts。
通过Grouping()系列方法定义了Tuple的发送方式。
ShuffleGropuing、FieldsGrouping、AllGrouping、GlobalGrouping、NonGrouping、DirectGrouping。
在Haoop上运行的是MapReduce作业,而在Storm上运行的是“Topology”。但两者的任务大不相同,其中主要的不同是一个MapReduce作业最终会完成计算并结束运行,而一个Topology将持续处理信息。
master运行Nimbus,worker运行Supervisor
Nimbus:负责在集群范围内分发代码、为Worker分配任务和检测障碍。
Supervisor:负责监听分配给它所在机器的工作。
Storm使用Zookeeper来作为分布式协调组件,负责Nimbus和多个Supervisor之间的所有协调工作。借助于Zookeeper,若Nimbus进程或Supervisor进程意外终止,重启时也能读取、恢复之前的状态并继续工作,使得Storm极其稳定。
一旦重启,两个进程借助Zookeeper将状态信息存放在Zookeeper中或本地磁盘中进行恢复并继续工作。
这样做使Storm很稳定。
能,因为有Zookeeper,一旦重启,两个进程借助Zookeeper将状态信息存放在Zookeeper中或本地磁盘中进行恢复并继续工作。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vkmHsGN4-1631693777314)(C:\Users\张昊\AppData\Roaming\Typora\typora-user-images\image-20201118192419205.png)]
从Spout中发送Stream;
用于分割单词的Bolts将接受的句子分解为独立的单词,将单词作为Tuple的字段名发送出去;
用于计数的Bolts接受表示单词的Tuple,并对其进行统计;
输出每个单词以及单词出现过的次数。
MapReduce使用的是Map和Reduce的抽象,而Storm使用的是Spout和Bolts的抽象。
TopologyBuilder builder = new TopologyBuilder() ;
builder . setSpout (“sentences”, new RandomSentenceSpout(), 5);
builder. setBolt (“split”, new SplitSentence(), 8).shuffleGrouping (“sentences”) ;
builder.setBolt (“count”, new WoraCount(), 12).fieldsGrouping(“split”,new Fields (“word”));
在该Topology中,首先新建了一个Topology Builder,接着通过builder.setSpout0方法对Spout数据源进行定义,该方法中有3个参数:第1个参数表示Stream的名称;第2个参数表示Stream的具体处理函数;第3个参数则表示并发数,即同时运行多少个任务来处理Stream。Topology中包含了两个Bolt处理器,使用了builder.setBolt()方 法进行定义,该方法的参数含义与builder.setSpout0方法相似。同时,每个Bolt使用了Groupings()系列方法定义了Tuple的发送方式。通过这两个Bolt的定义我们可以看出:
通过fieldsGroupings()方法,在“word"上具有相同字段值的所有Tuple (在本例中即单词相同的Tuple )将发送到同一个任务中进行统计,从而保证了统计的准确性。