Hadoop不适合处理实时数据的原因剖析

1.概述 

  Hadoop已被公认为大数据分析领域无可争辩的王者,它专注与批处理。这种模型对许多情形(比如:为网页建立索引)已经足够,但还存在其他一些使用模型,它们需要来自高度动态的来源的实时信息。为了解决这个问题,就得借助Twitter推出得Storm。Storm不处理静态数据,但它处理预计会连续的流数据。考虑到Twitter用户每天生成1.4亿条推文,那么就很容易看到此技术的巨大用途。

  但Storm不只是一个传统的大数据分析系统:它是复杂事件处理(CEP)系统的一个示例。CEP系统通常分类为计算和面向检测,其中每个系统都是通过用户定义的算法在Storm中实现。举例而言,CEP可用于识别事件洪流中有意义的事件,然后实时的处理这些事件。

2.为什么Hadoop不适合实时计算

  这里说的不适合,是一个相对的概念。如果业务对时延要求较低,那么这个 问题就不存在了;但事实上企业中的有些业务要求是对时延有高要求的。下面我 就来说说:

2.1时延

  Storm 的网络直传与内存计算,其时延必然比 Hadoop 的 HDFS 传输低得多;当计算模型比较适合流式时,Storm 的流试处理,省去了批处理的收集数据的时 间;因为 Storm 是服务型的作业,也省去了作业调度的时延。所以从时延的角 度来看,Storm 要快于 Hadoop,因而 Storm 更适合做实时流水数据处理。下面用一个业务场景来描述这个时延问题。

2.1.1业务场景

  几千个日志生产方产生日志文件,需要对这些日志文件进行一些 ETL 操作存 入数据库。

  我分别用 Hadoop 和 Storm 来分析下这个业务场景。假设我们用 Hadoop 来 处理这个业务流程,则需要先存入 HDFS,按每一分钟(达不到秒级别,分钟是最小纬度)切一个文件的粒度来计算。这个粒度已经极端的细了,再小的话 HDFS 上会一堆小文件。接着 Hadoop 开始计算时,一分钟已经过去了,然后再开始 调度任务又花了一分钟,然后作业运行起来,假设集群比较大,几秒钟就计算完 成了,然后写数据库假设也花了很少时间(理想状况下);这样,从数据产生到 最后可以使用已经过去了至少两分多钟。

  而我们来看看流式计算则是数据产生时,则有一个程序一直监控日志的产生, 产生一行就通过一个传输系统发给流式计算系统,然后流式计算系统直接处理, 处理完之后直接写入数据库,每条数据从产生到写入数据库,在资源充足(集群 较大)时可以在毫秒级别完成。

2.1.2吞吐

  在吞吐量方面,Hadoop 却是比 Storm 有优势;由于 Hadoop 是一个批处理计算,相比 Storm 的流式处理计算,Hadoop 的吞吐量高于 Storm。

2.2应用领域

  Hadoop 是基于 MapReduce 模型的,处理海量数据的离线分析工具,而 Storm是分布式的,实时数据流分析工具,数据是源源不断产生的,比如:Twitter 的 Timeline。另外,M/R 模型在实时领域很难有所发挥,它自身的设计特点决定了 数据源必须是静态的。

2.3硬件

  Hadoop 是磁盘级计算,进行计算时,数据在磁盘上,需要读写磁盘;Storm是内存级计算,数据直接通过网络导入内存。读写内存比读写磁盘速度快 N 个 数量级。根据行业结论,磁盘访问延迟约为内存访问延迟的 7.5w 倍,所以从这 个方面也可以看出,Storm 从速度上更快。

3.详细分析

  在分析之前,我们先看看两种计算框架的模型,首先我们看下MapReduce的模型,以WordCount为例,如下图所示:

  阅读过Hadoop源码下的hadoop-mapreduce-project工程中的代码应该对这个流程会熟悉,我这里就不赘述这个流程了。

  接着我们在来看下Storm的模型,如下图所示:

  然后下面我们就会涉及到2个指标问题:延时和吞吐。

  • 延时:指数据从产生到运算产生结果的时间。与“速度”息息相关。
  • 吞吐:指系统单位时间处理的数据量。

  另外,在资源相同的情况下;一般 Storm 的延时要低于 MapReduce,但是

  吞吐吞吐也要低于 MapReduce,下面我描述下流计算和批处理计算的流程。 整个数据处理流程来说大致可以分为三个阶段:

  1. 数据采集阶段
  2. 数据计算(涉及计算中的中间存储)

  3. 数据结果展现(反馈)

3.1.1数据采集阶段

  目前典型的处理策略:数据的产生系统一般出自 Web 日志和解析 DB 的 Log,流计算数据采集是获取的消息队列(如:Kafka,RabbitMQ)等。批处理系统一 般将数据采集到分布式文件系统(如:HDFS),当然也有使用消息队列的。我们 暂且把消息队列和文件系统称为预处理存储。二者在这个阶段的延时和吞吐上没 太大的区别,接下来从这个预处理存储到数据计算阶段有很大的区别。流计算一 般在实时的读取消息队列进入流计算系统(Storm)的数据进行运算,批处理系 统一般回累计大批数据后,批量导入到计算系统(Hadoop),这里就有了延时的 区别。

3.1.2数据计算阶段

  流计算系统(Storm)的延时主要有以下几个方面:

  • Storm 进程是常驻的,有数据就可以进行实时的处理。MapReduce 数据累 计一批后由作业管理系统启动任务,Jobtracker 计算任务分配,Tasktacker 启动相关的运算进程。
  • Storm 每个计算单元之间数据通过网络(ZeroMQ)直接传输。MapReduce Map 任务运算的结果要写入到 HDFS,在 Reduce 任务通过网络拖过去运算。 相对来说多了磁盘读写,比较慢。
  • 对于复杂运算,Storm的运算模型直接支持DAG(有向无环图,多个应用程 序存在依赖关系,后一个应用程序的 输入为前一个的输出),MapReduce 需 要多个 MR 过程组成,而且有些 Map 操作没有意义。

3.1.3数据展现

  流计算一般运算结果直接反馈到最终结果集中(展示页面,数据库,搜索引擎的索引)。而 MapReduce 一般需要整个运算结束后将结果批量导入到结果集中。

4.总结

  Storm 可以方便的在一个计算机集群中编写与扩展复杂的实时计算,Storm 之于实时,就好比 Hadoop 之于批处理。Storm 保证每个消息都会得到处理,而 且速度很快,在一个小集群中,每秒可以处理数以百万计的消息。

Storm 的主要特点如下:

  • 简单的编程模型。类似于MR降低了并行批处理的复杂行,Storm降低了实时处理的复杂行。
  • 可以使用各种编程语言。只要遵守实现Storm的通信协议即可。
  • 容错性。Storm会管理工作进程和节点故障。
  • 水平扩展。计算是在多个线程,进程和服务器之间并行进行的。
  • 可靠的消息处理。Storm保证每个消息至少能得到处理一次完整的处理,使用 MQ 作为其底层消息队列。
  • 本地模式。Storm 有一个“本地模式”,可以在处理过程中完全模拟Storm集群。这让你可以快速进行开发和单元测试。

  最后总结出:Hadoop 的 MR 基于 HDFS,需要切分输入数据,产生中间数据文件,排序,数据压缩,多分复制等,效率地下。而 Storm 基于 ZeroMQ 这个高
性能的消息通讯库,不能持久化数据。这篇文章就分享到这里,若有疑问,可以加入QQ群或发送邮件给我,我会尽我所能给予帮助,与君共勉!

时间: 2024-11-02 16:41:41

Hadoop不适合处理实时数据的原因剖析的相关文章

数道云大数据平台解决方案,Hadoop + HDFS+Hive+Hbase大数据开发整体架构设计

波若大数据平台(BR-odp)Hadoop + HDFS+Hive+Hbase大数据开发工具剖析: HDFS:分布式.高度容错性文件系统,能提供高吞吐量的数据访问,非常适合大规模数据集上的应用,大规模的波若大数据平台(BR-odp)用户部署上1000台的HDFS集群.数据规模高达50PB以上 HDFS和MR共同组成Hadoop分布式系统体系结构的核心.HDFS在集群上实现了分布式文件系统,MR在集群上实现了分布式计算和任务处理.HDFS在MR任务处理过程中提供了文件操作和存储等支持,MR在HDF

Hadoop生态系统简介及大数据相关技术

1.Hadoop 是一个能够对大量数据进行分布式处理的软件框架.具有可靠.高效.可伸缩的特点.Hadoop的核心是HDFS和Mapreduce,hadoop2.0还包括YARN. 2.HDFS Hadoop的分布式文件系统.是Hadoop体系中数据存储管理的基础.它是一个高度容错的系统,能检测和应对硬件故障,用于在低成本的通用硬件上运行.HDFS简化了文件的一致性模型,通过流式数据访问,提供高吞吐量应用程序数据访问功能,适合带有大型数据集的应用程序. 3.MapReduce(分布式计算框架) M

一个轻客户端,多语言支持,去中心化,自动负载,可扩展的实时数据写服务的实现方案讨论

背景 背景是设计一个实时数据接入的模块,负责接收客户端的实时数据写入(如日志流,点击流),数据支持直接下沉到HBase上(后续提供HBase上的查询),或先持久化到Kafka里,方便后续进行一些计算和处理,再下沉到文件系统或做别的输出. 在设计中,对于客户端和服务端有这么些目标. 客户端需要支持多语言(Java,C++),做得尽量轻量级,只要连上服务端的ip:port,以RPC的形式调用简单的write就可以把数据写出去.客户端不承担任何逻辑的处理,服务端的负载均衡对客户端是透明的. 服务端想要

【微信分享】王团结:如何用Hadoop/Spark构建七牛数据平台

摘要:7月30日,七牛数据平台工程师王团结就七牛内部使用的数据平台,深入分享了该团队在Flume.Kafka.Spark以及Streaming上的实践经验,并讲解了各个工具使用的注意点. 继" YARN or Mesos?Spark痛点探讨"." Mesos资源调度与管理的深入分享与交流".及" 主流SQL on Hadoop框架选择"之后,CSDN Spark微信用户群邀请了王团结为大家分享Hadoop/Spark在七牛数据平台的实战. 王团结

<颠覆大数据分析 基于StormSpark等Hadoop替代技术的实时应用>

为什么要超越Hadoop MapReduce Hadoop的适用范围 Hadoop缺乏对象数据库连接(ODBC) Hadoop不适合所有类型的应用程序 hadoop不适合分片数据 Hadoop不适合迭代式计算 海量数据分析所需的计算范式分类(7大任务) 基础分析 线性代数计算 广义的多体问题 图论问题 优化 积分 比对问题 Hadoop非常适合第一类基础分析,对于其他问题,较简单或者小型的任务都是Hadoop可解的. 于是有了Spark,spark可以看做是大数据领域下一个数据处理的Hadoop

【教程分享】基于Greenplum Hadoop分布式平台的大数据解决方案及商业应用案例剖析

基于Greenplum Hadoop分布式平台的大数据解决方案及商业应用案例剖析 课程讲师:迪伦 课程分类:Java 适合人群:高级 课时数量:96课时 用到技术:MapReduce.HDFS.Map-Reduce.Hive.Sqoop 涉及项目:Greenplum Hadoop大数据分析平台 更新程度:完毕 对这个课程有兴趣的朋友可以加我的QQ2059055336和我联系 下载地址:链接:   pan.baidu.com/s/1nthYpKH 密码: niyi 随着云计算.大数据迅速发展,亟需

Hadoop分布式平台的大数据解决方案

讲师:迪伦 对这个课程有兴趣的可以加我qq2059055336联系我 1 课程背景 GREENPLUM适用场景 Greenplum的架构采用了MPP(大规模并行处理).在 MPP 系统中,每个 SMP 节点也可以运行自己的操作系统.数据库等,它的特点主要就是查询速度快,数据装载速度快,批量DML处理快.而且性能可以随着硬件的添加,呈线性增加,拥有非常良好的可扩展性.因此,它主要适用于面向分析的应用.比如构建企业级ODS/EDW,或者数据集市等等. GREENPLUM运行的平台 GREENPLUM

基于Greenplum Hadoop分布式平台的大数据解决方案及商业应用案例剖析

随着云计算.大数据迅速发展,亟需用hadoop解决大数据量高并发访问的瓶颈.谷歌.淘宝.百度.京东等底层都应用hadoop.越来越多的企 业急需引入hadoop技术人才.由于掌握Hadoop技术的开发人员并不多,直接导致了这几年hadoop技术的薪水远高于JavaEE及 Android程序员. Hadoop入门薪资已经达到了 8K 以上,工作1年可达到 1.2W 以上,具有2-3年工作经验的hadoop人才年薪可以达到 30万—50万 . 一般需要大数据处理的公司基本上都是大公司,所以学习had

实时数据集成

企业应用集成 面向服务的体系结构 (SOA) 目前应该是一个很受欢迎的名词,中间件技术人员几乎到了言必称SOA的程度,数据集成当然也不例外,在Oracle openworld2008大会上,就推出了一堆数据集成的专场演讲,其中和SOA结合最紧密的就是实时数据集成 real time data integration.我总结了一下,实时数据集成一般分为两个处理过程:一是对数据按照SOA架构的需要进行整合加工形成可用的信息,二是将信息以符 合SOA规范的方式发布出去.具体的实时数据集成模式可以按照对