数据有静态数据和流数据。
静态数据:
很多企业为了支持决策分析而构建的数据仓库系统,其中存放的大量历史数据就是静态数据。技术人员可以利用数据挖掘和OLAP(On-Line Analytical Processing)分析工具从静态数据中找到对企业有价值的信息。
流数据:
近年来,在Web应用、网络监控、传感监测等领域,兴起了一种新的数据密集型应用——流数据,即数据以大量、快速、时变的流形式持续到达。
流数据具有如下特征:
对静态数据和流数据的处理,对应着两种截然不同的计算模式:批量计算和实时计算。
流计算:实时获取来自不同数据源的海量数据,经过实时分析处理,获得有价值的信息。
流计算秉承一个基本理念,即数据的价值随着时间的流逝而降低,如用户点击流。因此,当事件出现时就应该立即进行处理,而不是缓存起来进行批量处理。为了及时处理流数据,就需要一个低延迟、可扩展、高可靠的处理引擎.
对于一个流计算系统来说,它应达到如下需求:
Streaming是基于开源Storm,是一个分布式、实时计算框架。
特点:
传统数据库计算:数据先存储,在查询处理。
Hadoop设计的初衷是面向大规模数据的批量处理。
MapReduce是专门面向静态数据的批量处理的,内部各种实现机制都为批处理做了高度优化,不适合用于处理持续到达的动态数据。
可能会想到一种“变通”的方案来降低批处理的时间延迟——将基于MapReduce的批量处理转为小批量处理,将输入数据切成小的片段,每隔一个周期就启动一次MapReduce作业。但这种方式也无法有效处理流数据。
结论:鱼和熊掌不可兼得,Hadoop擅长批处理,不适合流计算。
Streaming是一个实时分布式的实时计算框架,在实时业务汇总有广泛的应用。
当前业界诞生了许多专门的流数据实时计算系统来满足各自需求。
商业级:IBM InfoSphere Streams和IBM StreamBase。
开源流计算框架
公司为支持自身业务开发的流计算框架:
流计算是针对流数据的实时计算,可以应用在多种场景中。如百度、淘宝等大型网站中,每天都会产生大量流数据,包括用户的搜索内容、用户的浏览记录等数据。采用流计算进行实时数据分析,可以了解每个时刻的流量变化情况,甚至可以分析用户的实时浏览轨迹,从而进行实时个性化内容推荐。但是,并不是每个应用场景都需要用到流计算的。流计算适合于需要处理持续到达的流数据、对数据处理有较高实时性要求的场景。
主要应用于以下几种场景:
传统的数据处理流程,需要先采集数据并存储在关系数据库等数据管理系统中,之后由用户通过查询操作和数据管理系统进行交互。
传统的数据处理流程隐含了两个前提:
流计算的处理流程一般包含三个阶段:数据实时采集、数据实时计算、实时查询服务。
数据实时采集阶段通常采集多个数据源的海量数据,需要保证实时性、低延迟与稳定可靠。
以日志数据为例,由于分布式集群的广泛应用,数据分散存储在不同的机器上,因此需要实时汇总来自不同机器上的日志数据。
目前有许多互联网公司发布的开源分布式日志采集系统均可满足每秒数百MB的数据采集和传输需求,如:
数据采集系统的基本架构一般有以下三个部分:
数据实时计算阶段对采集的数据进行实时的分析和计算,并反馈实时结果。
经流处理系统处理后的数据,可视情况进行存储,以便之后再进行分析计算。在时效性要求较高的场景中,处理之后的数据也可以直接丢弃。
实时查询服务:经由流计算框架得出的结果可供用户进行实时查询、展示或储存。
传统的数据处理流程,用户需要主动发出查询才能获得想要的结果。而在流处理流程中,实时查询服务可以不断更新结果,并将用户所需的结果实时推送给用户。
虽然通过对传统的数据处理系统进行定时查询,也可以实现不断地更新结果和结果推送,但通过这样的方式获取的结果,仍然是根据过去某一时刻的数据得到的结果,与实时结果有着本质的区别。
可见,流处理系统与传统的数据处理系统有如下不同:
Twitter Storm是一个免费、开源的分布式实时计算系统,Storm对于实时计算的意义类似于Hadoop对于批处理的意义,Storm可以简单、高效、可靠地处理流数据,并支持多种编程语言。
Storm框架可以方便地与数据库系统进行整合,从而开发出强大的实时计算系统。
Twitter是全球访问量最大的社交网站之一,Twitter开发Storm流处理框架也是为了应对其不断增长的流数据实时处理需求。
Storm可用于许多领域中,如实时分析、在线机器学习、持续计算、远程RPC、数据提取加载转换等。
Storm具有以下主要特点:
Storm主要术语包括Streams、Spouts、Bolts、Topology和Stream Groupings.
Topology:Streaming中运行的一个实时应用程序。
Nimbus:负责资源分配和任务调度。
Supervisor:负责接收Nimbus分配的任务,启动和停止属于自己管理的worker进程。
Worker:Topology运行时的物理进程。每个Worker是一个JVM进程。
Spout:Storm认为每个Stream都有一个源头,并把这个源头抽象为Spout。
在一个Topology中产生源数据流的组件。
通常Spout会从外部数据源(队列、数据库等)读取数据,然后封装成Tuple形式,发送到Stream中。Spout是一个主动的角色,在接口内部有个nextTuple函数,Storm框架会不停的调用该函数。
Bolt:在一个Topology中接收数据后然后执行处理的组件。
Task:Worker中每一个Spout/Bolt的线程称为一个Task。
Tuple:Streaming的核心数据结构,是消息传递的基本单元,不可变Key-Value对,这些Tuple会以一种分布式的方式进程创建和处理。
Stream:Storm将流数据Stream描述成一个无限的Tuple序列,这些Tuple序列会以分布式的方式并行地创建和处理。即无界的Tuple序列。
Zookeeper:为Streaming服务中各自进程提供分布式的协作服务、主备Nimbus、Supervisor、Worker将自己的信息注册到Zookeeper中,Nimbus据此感知各个角色的监控状态。
Storm将Spouts和Bolts组成的网络抽象成Topology,它可以被提
交到Storm集群执行。Topology可视为流转换图,图中节点是一个Spout或Bolt,边则表示Bolt订阅了哪个Stream。当Spout或者Bolt发送元组时,它会把元组发送到每个订阅了该Stream的Bolt上进行处理。
Topology里面的每个处理组件(Spout或Bolt)都包含处理逻辑, 而组件之间的连接则表示数据流动的方向。
Topology里面的每一个组件都是并行运行的:
在Topology里面可以指定每个组件的并行度,Storm会在集群里面分配那么多的线程来同时计算。
在Topology的具体实现上,Storm中的Topology定义仅仅是一些Thrift结构体(二进制高性能的通信中间件),支持各种编程语言进行定义。
一个Topology是由一组Spout组件(数据源)和Bolt组件(逻辑处理)通过Stream Groupings进行连接的有向无环图(DAG)。
业务处理逻辑被封装进Streaming中的Topology中。
Worker:一个Worker是一个JVM进程,所有的Topology都是在一个或者多个Worker中运行的。Worker启动后是长期运行的,除非人工停止。Worker进程的个数取决于Topology的设置,且无设置上限,具体可获得并调度启动的Worker个数则取决于Supervisor配置的slot个数。
Executor:在一个单独的Worker进程中会运行一个或多个Executor线程。每个Executor只能运Spout或者Bolt中的一个或多个Task实例。
Task:是最终完成数据处理的实体单元。
Topology里面的每一个Component(组件)(Spout/Blot)节点都是并行运行的。在Topology里面,可以指定每个节点的并发度,Streaming则会在集群里分配响应的Task来同时计算,以增强系统的处理能力。
Groupings:Storm中的Stream Groupings用于告知Topology如何在两个组件间(如Spout和Bolt之间,或者不同的Bolt之间)进行Tuple的传送。每一个Spout和Bolt都可以有多个分布式任务,一个任务在什么时候、以什么方式发送Tuple就是由Stream Groupings来决定的。
目前,Storm中的Stream Groupings有如下几种方式:
Storm集群采用“Master—Worker”的节点方式:
Master节点运行名为“Nimbus”的后台程序(类似Hadoop中的“JobTracker”),负责在集群范围内分发代码、为Worker分配任务和监测故障。
Worker节点运行名为“Supervisor”的后台程序,负责监听分配给它所在机器的工作,即根据Nimbus分配的任务来决定启动或停止Worker进程,一个Worker节点上同时运行若干个Worker进程。
Storm使用Zookeeper来作为分布式协调组件,负责Nimbus和多个Supervisor之间的所有协调工作。借助于Zookeeper,若Nimbus进程或Supervisor进程意外终止,重启时也能读取、恢复之前的状态并继续工作,使得Storm极其稳定。
Nimbus并不直接和Supervisor交换,而是通过Zookeeper进行消息的传递。
Storm运行任务的方式与Hadoop类似:Hadoop运行的是MapReduce作业,而Storm运行的是“Topology”。
但两者的任务大不相同,主要的不同是:MapReduce作业最终会完成计算并结束运行,而Topology将持续处理消息(直到人为终止)。
Storm工作流程为:
所有Topology任务的提交必须在Storm客户端节点上进行,提交后,由Nimbus节点分配给其他Supervisor节点进行处理。
Nimbus节点首先将提交的Topology进行分片,分成一个个Task,分配给相应的Supervisor,并将Task和Supervisor相关
的信息提交到Zookeeper集群上。
Supervisor会去Zookeeper集群上认领自己的Task,通知自己的Worker进程进行Task的处理。
REST接口:(Representational State Transfer)表述性状态转移接口。
Thrift接口:由Nimbus提供。Thrift是一个基于静态代码生成的跨语言的RPC协议栈实现,它可以生成包括C++,Java,Python, Ruby , PHP等主流语言的代码实现,这些代码实现了RPC的协议层和传输层功能,从而让用户可以集中精力与服务的调用和实现。
使用Zookeeper分布式锁:
Nimbus HA的实现是使用Zookeeper分布式锁,通过主备间争抢模式完成的Leader选举和主备切换。
主备间元数据同步:
主备Nimbus之间会周期性的同步元数据,保证在发生主备切换后拓扑数据不丢失,业务不受损。
容灾能力:节点失效,自动迁移到正常节点,业务不中断。
整个过程无需人工干预!
在Streaming里面一个Tuple被完全处理的意思是:这个Tuple所派生的所有tuple都被成功处理。如果这个消息在Timeout所指定的时间内没有成功处理,这个tuple就被认为处理失败了。
可靠性级别设置:
如果并不要求每个消息必须被处理(允许在处理过程中丢失一些信息),那么可以关闭消息的可靠性处理机制,从而可以获得较好的性能。关闭消息的可靠性机制一位着系统中的消息数会减半。
有三种方法可以关闭消息的可靠性处理机制:
整合HDFS/HBase等外部组件,将实时结构提供给其他组件,进程离线分析。
Spark Streaming可整合多种输入数据源,如Kafka、Flume、
HDFS,甚至是普通的TCP套接字。经处理后的数据可存储至文件
系统、数据库,或显示在仪表盘里。
Spark Streaming的基本原理是将实时输入数据流以时间片(秒级)为单位进行拆分,然后经Spark引擎以类似批处理的方式处理每个时间片数据。
**Spark Streaming最主要的抽象是DStream(Discretized Stream,离散化数据流),表示连续不断的数据流。**在内部实现上,Spark Streaming的输入数据按照时间片(如1秒)分成一段一段的DStream,每一段数据转换为Spark中的RDD,并且对DStream的操作都最终转变为对相应的RDD的操作。
(1)作业:一个作业(Job)是对一组输入流进行处理转化成输出流的程序。
(2)分区:
(3)任务:
(4)数据流图:
Samza系统架构主要包括:
流处理层和执行层都被设计成可插拔的,开发人员可以使用其他框架来替代YARN和Kafka。
处理分析过程如下:
从编程的灵活性来讲,Storm是比较理想的选择,它使用Apache Thrift,可以用任何编程语言来编写拓扑结构(Topology)。
当需要在一个集群中把流计算和图计算、机器学习、SQL查询分析等进行结合时,可以选择Spark Streaming,因为,在Spark上可以统一部署Spark SQL,Spark Streaming、MLlib,GraphX等组件,提供便捷的一体化编程模型。
当有大量的状态需要处理时,比如每个分区都有数十亿个元组,则可以选择Samza。当应用场景需要毫秒级响应时,可以选择Storm和Samza,因为Spark Streaming无法实现毫秒级的流计算。
以上内容为听华为大数据培训课程和大学MOOC上厦门大学 林子雨的《大数据技术原理与应用》课程而整理的笔记。
大数据技术原理与应用: https://www.icourse163.org/course/XMU-1002335004