您的位置 : 首页 >> 电子书推荐分享

大数据与智慧社会:数据驱动变革、构建未来世界

下载方式

本书作者:张克平 (作者, 编者), 陈曙东 (作者, 编者)

本书读后感及个人笔记分享· · · · · ·

流式处理概述
在金融、通信等领域,数据呈现出突发性、实时性等鲜明的流式特征。传统的基于Map Reduce的批处理模式难以满足流式大数据处理对计算实时性的要求。因此,低延迟、高可靠、可扩展的大数据流式计算系统具有重要的理论价值和实践意义。


点赞、分享、投币,素质三连哦

流式大数据是按照时间顺序无限增加的数据序列,也可将其看成历史数据和不断增加的更新数据的合集。与传统的静态数据不同,流式大数据表现出新的特征。

(1)无限性流式数据可以抽象为一个无穷的数据序列,只要数据源处于活动状态,数据就会一直产生和持续增加下去,潜在的数据量是无限的。

(2)无序性数据流中的数据元素随机到来,系统无法控制将要处理的新到达数据元素的顺序。

(3)实时性流式数据的价值会随着时间的流逝不断减少,因此需要不断对数据处理的结果进行实时更新,保证数据实时产生、实时处理,结果及时反馈。

(4)突发性流式数据的产生完全由数据源确定,由于不同的数据源在不同时空范围内的状态不统一且发生动态变化,导致流入系统的数据流速率存在较大的不确定性。而且,数据流中常会混入错误元素。

目前业界主要采用两种模式实现大数据的分析处理:批量处理和流式处理。这两种数据处理模式的主要区别如下。

(1)批量处理采用先存储后处理的模式,即需要首先完成数据累积和落地,然后再对静态数据进行集中计算和价值发现;而流式处理则采用直接处理的模式,当数据流到达后直接在内存中对数据进行计算并及时反馈结果,无需对其先进行存储,从而避免数据堆积和丢失。

(2)批量处理通过调度批量任务来操作静态数据,当任务启动时,一般数据已经到位(如保存在分布式文件系统上);而流式处理则是针对数据流进行操作。流式计算系统在启动时,一般数据并没有完全到位,而是由外部源源不断地流入,数据到达时刻和到达顺序都是未知的,因此很难准确掌握整个数据的全貌。

(3)批量处理注重的是数据处理的吞吐量,同时对数据的全面性和准确性有较高要求,相对而言,对计算延迟要求并不严格;而流式处理更加注重数据处理的速度和实时性,处理响应时间一般在数百毫秒到数秒之间,对计算精确度的要求较为宽松。

4.3.2 Storm简介
Storm是一个开源的分布式实时计算系统,利用Storm可以很容易做到可靠地处理无限的数据流,支持任何编程语言,支持创建拓扑结构来转换没有终点的数据流,转换从不停止。Storm常用在实时分析、在线机器学习、持续计算、分布式远程调用和ETL等领域,部署管理也非常简单。

数据流

数据流(Streams)是Storm中最核心的抽象概念。一个数据流是在分布式环境中并行创建、处理的一组元组(Tuple)的无界序列。数据流可以由一种能够表述数据流中元组的域(Fields)的模式来定义。在默认情况下,元组包含有整型(Integer)数字、长整型(Long)数字、短整型(Short)数字、字节(Byte)、双精度浮点数(Double)、单精度浮点数(Float)、布尔值以及字节数组等基本类型对象。而且,数据流也允许用户自定义元组类型。

数据源

大数据与智慧社会:数据驱动变革、构建未来世界数据源(Spout)是拓扑中数据流的来源。一般数据源会从一个外部的数据源读取元组,然后将它们发送到拓扑中。根据不同的需求,数据源既可以定义为可靠的数据源,也可以定义为不可靠的数据源。一个可靠的数据源能够在它发送的元组处理失败时重新发送该元组,以确保所有元组都能得到正确的处理。相应地,不可靠的数据源在元组发送之后不会对元组进行任何其他处理。

一个数据源可以发送多个数据流。数据源中的关键方法是下一个元组(Next Tuple)。顾名思义,下一个元组要么会向拓扑中发送一个新的元组,要么会在没有可发送的元组时直接返回。

数据流处理组件

拓扑中所有的数据处理均是由组件(Bolt)完成的。通过数据过滤(Filtering)、函数处理(Functions)、聚合(Aggregations)、联结(Joins)、数据库交互等功能,组件几乎能够完成任何一种数据处理需求。复杂的数据流变换通常需要使用多个组件并通过多个步骤完成。与数据源相同,组件也可以输出多个数据流。

数据流分组

为拓扑中每个组件确定输入数据流是定义一个拓扑的重要环节。数据流分组(Stream Groupings)定义了在组件的不同任务中划分数据流的方式。Storm有八种内置的数据流分组方式,分别为随机分组(Shuffle Grouping)、域分组(Fields Grouping)、部分关键字分组(Partial Key Grouping)、全复制分组(All Grouping)、全局分组(Global Grouping)、不分组(None Grouping)、指向型分组(Direct Grouping)、本地或随机分组(Local or Shuffle Grouping);也支持用户通过Custom Stream Grouping接口实现自定义的数据流分组模型。

任务

在Storm集群中,每个数据源和组件都由若干个任务来执行,每个任务都与一个执行线程相对应。用户可以设置数据源和组件的并行度,再由数据流分组决定如何由一组任务向另一组任务发送元组。

可靠性

Storm通过跟踪由数据源发出的每个元组构成的元组树来确保每个发送的元组都能得到正确处理。每个拓扑都有一个“消息延时”参数,如果在延时时间内没有检测到元组是否处理完成,就会将该元组标记为“处理失败”,并在稍后重新发送该元组。

工作进程

拓扑是在一个或多个工作进程(Worker Processes)中运行的。每个工作进程都是一个实际的JVM进程,执行拓扑的一个子集。例如,如果拓扑的并行度定义为300,工作进程数定义为50,那么每个工作进程就会执行6个任务(进程内部的线程)。Storm会在所有的工作进程中分散任务,以便实现集群的负载均衡。

4.3.3 Storm架构
Storm主要通过三个部件来运行拓扑,分别为工作进程(Worker)、执行线程(Executor)及任务(Task)。它们之间的相互关系如图4-7所示。

 

图4-7 Storm拓扑架构

执行器是由工作进程生成的线程。在执行器中可能会有一个或者多个任务,任务是实际执行数据处理的最小工作单元,这些任务都是为同一个组件服务的。

原生的Storm项目是难以与Hadoop相融合的,直到2013年6月Storm on YARN项目的推出,才使Storm融合进Hadoop,增强Hadoop系统的流数据处理能力。

Storm on YARN支持Storm应用利用Hadoop计算节点的计算资源。YARN根据需求启动Storm应用的主节点Nimbus,并支持Nimbus为Storm应用的工作节点(Supervisor)请求资源。此外,Storm on YARN支持Storm应用可以直接访问存储在HDFS和HBase上的Hadoop数据。

4.3.4 Storm与Spark Streaming比较
Spark Streaming是对核心Spark API的一个扩展,能够实现对实时数据流的流式处理,并具有很好的可扩展性、高吞吐量和容错性。它与Storm都是分布式的数据流式实时处理的开源框架,但也有一些很重要的差异。

数据处理模型和数据延迟性

虽然两种框架都提供了系统的可扩展性和可容错性,但它们的数据处理模型是不一样的,而这决定了各自不同的实时性。Storm可以实现真正实时地处理流式数据,延迟在秒级以下,实时性很高。而Spark Streaming的本质是微批量处理,在较短的时间窗口内进行数据实时处理,通常延迟在秒级左右,实时性相对较弱。

数据保护和容错能力

在数据容错能力方面,Spark Streaming做得比Storm好一些,它的容错是通过状态记录去实现的,能够保证每个批处理的所有数据只处理一次,保证数据不会在恢复时错乱。Storm通过标记每一条数据来跟踪数据的处理情况,只能保证每条数据被处理一次,但实际情况是在发生错误时,这条数据是被处理多次的。这意味着更新多次时可能会导致数据不正确。

注:本站不存储任何书籍,PDF电子版收集于网络,仅供学习交流使用,请于24小时后自觉删除。

本文版权归原作者所有,请支持正版。此处仅提供个人读书笔记 https://yigefanyi.com/dashujuyuzhihuishehuishujuqudongbiangegoujianweilaishijie/
返回顶部