SparkStreaming和Storm

SparkStreaming和Storm

Storm和Spark Streaming都是分布式流处理的开源框架,但是它们之间还是有一些区别的,这里将进行比较并指出它们的重要的区别。

处理模型以及延迟

虽然这两个框架都提供可扩展性(Scalability)和可容错性(Fault Tolerance),但是它们的处理模型从根本上说是不一样的。Storm处理的是每次传入的一个事件,而Spark Streaming是处理某个时间段窗口内的事件流。因此,Storm处理一个事件可以达到亚秒级的延迟,而Spark Streaming则有秒级的延迟。

容错和数据保证

在容错数据保证方面的权衡方面,Spark Streaming提供了更好的支持容错状态计算。在Storm中,当每条单独的记录通过系统时必须被跟踪,所以Storm能够至少保证每条记录将被处理一次,但是在从错误中恢复过来时候允许出现重复记录,这意味着可变状态可能不正确地被更新两次。而Spark Streaming只需要在批处理级别对记录进行跟踪处理,因此可以有效地保证每条记录将完全被处理一次,即便一个节点发生故障。虽然Storm的 Trident library库也提供了完全一次处理的功能。但是它依赖于事务更新状态,而这个过程是很慢的,并且通常必须由用户实现。

简而言之,如果你需要亚秒级的延迟,Storm是一个不错的选择,而且没有数据丢失。如果你需要有状态的计算,而且要完全保证每个事件只被处理一次,Spark Streaming则更好。Spark Streaming编程逻辑也可能更容易,因为它类似于批处理程序,特别是在你使用批次(尽管是很小的)时。

实现和编程API

Storm主要是由Clojure语言实现,SparkStreaming是由Scala实现。如果你想看看这两个框架是如何实现的或者你想自定义一些东西你就得记住这一点。Storm是由BackType和Twitter开发,而Spark Streaming是在UC Berkeley开发的。

Storm提供了Java API,同时也支持其他语言的API。SparkStreaming支持Scala和Java语言(其实也支持Python)。另外SparkStreaming的一个很棒的特性就是它是在Spark框架上运行的。这样你就可以想使用其他批处理代码一样来写SparkStreaming程序,或者是在Spark中交互查询。这就减少了单独编写流批量处理程序和历史数据处理程序。

生产支持

Storm已经出现好多年了,而且自从2011年开始就在Twitter内部生产环境中使用,还有其他一些公司。而Spark Streaming是一个新的项目,并且在2013年仅仅被Sharethrough使用(据作者了解)。

Storm是 Hortonworks Hadoop数据平台中流处理的解决方案,而Spark Streaming出现在 MapR的分布式平台和Cloudera的企业数据平台中。除此之外,Databricks是为Spark提供技术支持的公司,包括了Spark Streaming。

集群管理集成

尽管两个系统都运行在它们自己的集群上,Storm也能运行在Mesos,而SparkStreaming能运行在YARN 和 Mesos上。

大数据

数据中台和数据仓库、数据平台的关键区别?

概括地说,三者的关键区别有以下几方面:

数据中台是企业级的逻辑概念,体现企业 D2V(Data to Value)的能力,为业务提供服务的主要方式是数据 API;

数据仓库是一个相对具体的功能概念,是存储和管理一个或多个主题数据的集合,为业务提供服务的方式主要是分析报表;

数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台,为业务提供服务的方式主要是直接提供数据集;

数据中台距离业务更近,为业务提供速度更快的服务;

数据仓库是为了支持管理决策分析,而数据中台则是将数据服务化之后提供给业务系统,不仅限于分析型场景,也适用于交易型场景;

数据中台可以建立在数据仓库和数据平台之上,是加速企业从数据到业务价值的过程的中间层。

数据仓库具有历史性,其中存储的数据大多是结构化数据,这些数据并非企业全量数据,而是根据需求针对性抽取的,

因此数据仓库对于业务的价值是各种各样的报表,但这些报表又无法实时产生。数据仓库报表虽然能够提供部分业务价值,但不能直接影响业务。

数据平台的出现是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题,所以先撇开业务需求、把企业所有的数据都抽取出来放到一起,成为一个大的数据集,其中有结构化数据、非结构化数据等。

当业务方有需求的时候,再把他们需要的若干个小数据集单独提取出来,以数据集的形式提供给数据应用。

而数据中台是在数据仓库和数据平台的基础上,将数据生产为为一个个数据 API 服务,以更高效的方式提供给业务。

Hadoop Hive Hbase 简单区别及应用场景

Hadoop Hive Hbase 简单区别及应用场景

Hadoop

它是一个分布式计算+分布式文件系统,前者其实就是MapReduce,后者是HDFS。后者可以独立运行,前者可以选择性使用,也可以不使用。

Hive

通俗的说是一个数据仓库,仓库中的数据是被HDFS管理的数据文件,它支持类似sql语句的功能,
你可以通过该语句完成分布式环境下的计算功能,Hive会把语句转换成MapReduce,然后交给Hadoop执行。
这里的计算,仅限于查找和分析,而不是更新、增加和删除。它的优势是对历史数据进行处理,
用时下流行的说法是离线计算,因为它的底层是MapReduce,MapReduce在实时计算上性能很差。
它的做法是把数据文件加载进来作为一个Hive表(或者外部表),让你觉得你的sql操作的是传统的表。

HBase

通俗的说,HBase的作用类似于数据库,传统数据库管理的是集中的本地数据文件,
而HBase基于Hdfs实现对分布式数据文件的管理,比如增删改查。也就是说,HBase只是利用Hadoop的Hdfs帮助其管理数据的持久化文件(HFile),它跟MapReduce没任何关系。HBase的优势在于实时计算,所有实时数据都直接存入Hbase中,客户端通过API直接访问Hbase,实现实时计算。由于它使用的是nosql,或者说是列式结构,从而提高了查找性能,使其能运用于大数据场景,这是它跟MapReduce的区别。

总结:

  1. Hadoop是Hive和HBase的基础,Hive依赖Hadoop
  2. HBase仅依赖Hadoop的Hdfs模块。
  3. Hive适用于离线数据的分析,操作的是通用格式的(如通用的日志文件)、被Hadoop管理的数据文件,它支持类sql,
    比编写MapReduce的java代码来的更加方便,它的定位是数据仓库,存储和分析历史数据
  4. Hbase适用于实时计算,采用列式结构的nosql,操作的是自己生成的特殊格式的HFile、被hadoop管理的数据文件,
    它的定位是数据库,或者叫DBMS

最后补充一下:Hive可以直接操作Hdfs中的文件作为它的表的数据,也可以使HBase数据库作为它的表

Hadoop概念

Hadoop是一个开源的框架,可编写和运行分布式应用处理大规模数据,是专为离线和大规模数据分析而设计的,并不适合那种对几个记录随机读写的在线事务处理模式。

Hadoop

概念

  • Hadoop是一个开源的框架,可编写和运行分布式应用处理大规模数据,是专为离线和大规模数据分析而设计的,并不适合那种对几个记录随机读写的在线事务处理模式。 ==不是为了大数据而大数据==
  • Hadoop 是以一种可靠、高效、可伸缩的方式进行处理的。Hadoop 是可靠的,因为它假设计算元素和存储会失败,因此它维护多个工作数据副本,确保能够针对失败的节点重新分布处理。Hadoop 是高效的,因为它以并行的方式工作,通过并行处理加快处理速度。Hadoop 还是可伸缩的,能够处理 PB 级数据。

核心

Hadoop的核心就是==HDFS==和==MapReduce===,Hadoop旗下有很多经典子项目,比如HBase、Hive等,这些都是基于HDFS和MapReduce发展出来的。要想了解Hadoop,就必须知道HDFS和MapReduce是什么。

HDFS

Hadoop Distributed File System,Hadoop 分布式文件系统
高度容错性的系统,适合部署在廉价的机器上,HDFS能提供高吞吐量的数据访问,
适合那些有着超大数据集(large data set)的应用程序。

MapReduce

Mapreduce是一个计算框架,一个处理分布式海量数据的软件框架及计算集群。

用处

  • 搜索引擎 - 设计Hadoop的初衷,为了针对大规模的网页快速建立索引)
  • 大数据存储 - 利用Hadoop的分布式存储能力,例如数据备份、数据仓库等。
  • 大数据处理 - 利用Hadoop的分布式处理能力,例如数据挖掘、数据分析等。
  • 科学研究 - Hadoop是一种分布式的开源框架,对于分布式计算有很大程度地参考价值。

优缺点

优点

==高可靠性==
Hadoop按位存储和处理数据的能力值得信赖。

==高扩展性==
Hadoop是在可用的计算机集簇间分配数据并完成计算任务的,这些集簇可以方便地扩展到数以千计的节点中。

==高效性==
Hadoop能够在节点之间动态地移动数据,并保证各个节点的动态平衡,因此处理速度非常快。

==高容错性==
Hadoop能够自动保存数据的多个副本,并且能够自动将失败的任务重新分配。

==低成本==
与一体机、商用数据仓库以及QlikView、Yonghong Z-Suite等数据集市相比,hadoop是开源的,
项目的软件成本因此会大大降低。

Hadoop设计对硬件需求比较低,只须运行在低廉的商用硬件集群上,而无需昂贵的高可用性机器上。
廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性,
安全性及高可用性。

缺点

==不适合低延迟数据访问==

如果要处理一些用户要求时间比较短的低延迟应用请求,则HDFS不适合。HDFS是为了处理大型数据集分析任务的,主要是为达到高的数据吞吐量而设计的,这就可能要求以高延迟作为代价。

改进策略:对于那些有低延时要求的应用程序,HBase是一个更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的提升,它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力,以减少延时。还有就是对HDFS系统内部的修改,这就得权衡大吞吐量与低延时了,HDFS不是万能的银弹。

==无法高效存储大量小文件==

因为Namenode把文件系统的元数据放置在内存中,所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说,每一个文件、文件夹和Block需要占据150字节左右的空间,所以,如果你有100万个文件,每一个占据一个Block,你就至少需要300MB内存。当前来说,数百万的文件还是可行的,当扩展到数十亿时,对于当前的硬件水平来说就没法实现了。还有一个问题就是,因为Maptask的数量是由splits来决定的,所以用MR处理大量的小文件时,就会产生过多的Maptask,线程管理开销将会增加作业时间。举个例子,处理10000M的文件,若每个split为1M,那就会有10000个Maptasks,会有很大的线程开销;若每个split为100M,则只有100个Maptasks,每个Maptask将会有更多的事情做,而线程的管理开销将减小很多。

==不支持多用户写入及任意修改文件==

在HDFS的一个文件中只有一个写入者,而且写操作只能在文件末尾完成,即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作,以及在文件任意位置进行修改。

大数据

大数据生命周期

  • 基础设施层,涵盖计算资源、内存与存储和网络互联,具体表现为计算节点、集群、机柜和数据中心。
  • 数据存储和管理层,包括文件系统、数据库和类似YARN的资源管理系统。
  • 计算处理层,如hadoop、MapReduce和Spark
  • 在此之上的各种不同计算范式,如批处理、流处理和图计算等,包括衍生出编程模型的计算模型,如BSP、GAS等

数据分析和可视化基于计算处理层。分析包括简单的查询分析、流分析以及更复杂的分析(如机器学习、图计算等)。查询分析多基于表结构和关系函数,流分析基于数据、事件流以及简单的统计分析,而复杂分析则基于更复杂的数据结构与方法,如图、矩阵、迭代计算和线性代数。一般意义的可视化是对分析结果的展示。但是通过交互式可视化,还可以探索性地提问,使分析获得新的线索,形成迭代的分析和可视化。基于大规模数据的实时交互可视化分析以及在这个过程中引入自动化的因素是目前研究的热点。

大数据技术生态

大数据的基本处理流程与传统数据处理流程并无太大差异,主要区别在于:由于大数据要处理大量、非结构化的数据,所以在各处理环节中都可以采用并行处理。目前,Hadoop、MapReduce和Spark等分布式处理方式已经成为大数据处理各环节的通用处理方法。

大数据采集与预处理

  • 存储层
  • 预处理层
  • 采集层

在大数据的生命周期中,数据采集处于第一个环节。根据MapReduce产生数据的应用系统分类,大数据的采集主要有4种来源:管理信息系统、Web信息系统、物理信息系统、科学实验系统。对于不同的数据集,可能存在不同的结构和模式,如文件、XML树、关系表等,表现为数据的异构性。对多个异构的数据集,需要做进一步集成处理或整合处理,将来自不同数据集的数据收集、整理、清洗、转换后,生成到一个新的数据集,为后续查询和分析处理提供统一的数据视图。针对管理信息系统中异构数据库集成技术、Web信息系统中的实体识别技术和DeepWeb集成技术、传感器网络数据融合技术已经有很多研究工作,取得了较大的进展,已经推出了多种数据清洗和质量控制工具。

大数据的存储和管理

按数据类型的不同,大数据的存储和管理采用不同的技术路线,大致可以分为3类。

第1类

主要面对的是大规模的结构化数据。针对这类大数据,通常采用新型数据库集群。它们通过列存储或行列混合存储以及粗粒度索引等技术,结合MPP(MassiveParallelProcessing)架构高效的分布式计算模式,实现对PB量级数据的存储和管理。这类集群具有高性能和高扩展性特点,在企业分析类应用领域已获得广泛应用;

第2类

主要面对的是半结构化和非结构化数据。应对这类应用场景,基于Hadoop开源体系的系统平台更为擅长。它们通过对Hadoop生态体系的技术扩展和封装,实现对半结构化和非结构化数据的存储和管理;

第3类

面对的是结构化和非结构化混合的大数据,因此采用MPP并行数据库集群与Hadoop集群的混合来实现对百PB量级、EB量级数据的存储和管理。一方面,用MPP来管理计算高质量的结构化数据,提供强大的SQL和OLTP型服务;另一方面,用Hadoop实现对半结构化和非结构化数据的处理,以支持诸如内容检索、深度挖掘与综合分析等新型应用。这类混合模式将是大数据存储和管理未来发展的趋势。

Hadoop技术体系

Hadoop 里面包括几个组件HDFSMapReduceYARNZooKeeper等一系列技术,HDFS是存储数据的地方就像我们电脑的硬盘一样文件都存储在这个上面,MapReduce是对数据进行处理计算的,YARN是体现Hadoop平台概念的重要组件,有了它大数据生态体系的其它软件就能在hadoop上运行了,这样能更好的利用HDFS大存储的优势和节省更多的资源比如我们就不用再单独建一个spark的集群了,让它直接跑在现有的hadoop yarn上面就可以了。ZooKeeper本身是一个非常牢靠的记事本,用于记录一些概要信息。Hadoop依靠这个记事本来记录当前哪些节点正在用,哪些已掉线,哪些是备用等,以此来管理机群。

Hadoop技术体系

Hadoop

Hadoop 里面包括几个组件HDFSMapReduceYARNZooKeeper等一系列技术,HDFS是存储数据的地方就像我们电脑的硬盘一样文件都存储在这个上面,MapReduce是对数据进行处理计算的,YARN是体现Hadoop平台概念的重要组件,有了它大数据生态体系的其它软件就能在hadoop上运行了,这样能更好的利用HDFS大存储的优势和节省更多的资源比如我们就不用再单独建一个spark的集群了,让它直接跑在现有的hadoop yarn上面就可以了。ZooKeeper本身是一个非常牢靠的记事本,用于记录一些概要信息。Hadoop依靠这个记事本来记录当前哪些节点正在用,哪些已掉线,哪些是备用等,以此来管理机群。

HDFS

Hadoop Distributed File System,Hadoop 分布式文件系统
高度容错性的系统,适合部署在廉价的机器上,HDFS能提供高吞吐量的数据访问,适合那些有着超大数据集(large data set)的应用程序。

MapReduce

Mapreduce是一个计算框架,一个处理分布式海量数据的软件框架及计算集群。

Map (映射) Reduce (简化)
举个例子:假设你的手机通话信息保存在一个HDFS的文件callList.txt中,你想找到你与同事A的所有通话记录并排序。因为HDFS会把callLst.txt分成几块分别存,比如说5块,那么对应的Map过程就是找到这5块所在的5个节点,让它们分别找自己存的那块中关于同事A的通话记录,对应的Reduce过程就是把5个节点过滤后的通话记录合并在一块并按时间排序。MapReduce的计算模型通常把HDFS作为数据来源,很少会用到其它数据来源比如HBase。

Hbase

这是Hadoop生态体系中的NOSQL数据库,他的数据是按照key和value的形式存储的并且key是唯一的,所以它能用来做数据的排重,它与MYSQL相比能存储的数据量大很多。所以他常被用于大数据处理完成之后的存储目的地。

HDFS和HBase是依靠外存(即硬盘)的分布式文件存储实现和分布式表存储实现。HDFS是一个分布式的“云存储”文件系统,它会把一个文件分块并分别保存,取用时分别再取出、合并。重要的是,这些分块通常会在3个节点(即集群内的服务器)上各有1个备份,因此即使出现少数节点的失效(如硬盘损坏、掉电等),文件也不会失效。如果说HDFS是文件级别的存储,那HBase则是表级别的存储。HBase是表模型,但比SQL数据库的表要简单的多,没有连接、聚集等功能。HBase的表是物理存储到HDFS的,比如把一个表分成4个HDFS文件并存储。由于HDFS级会做备份,所以HBase级不再备份。MapReduce则是一个计算模型,而不是存储模型;MapReduce通常与HDFS紧密配合。

Hive

Hive 是一种底层封装了Hadoop 的数据仓库处理工具,使用类SQL的HiveQL语言实现数据查询,所有Hive 的数据都存储在Hadoop 兼容的文件系统(如HDFS)中。Hive在加载数据过程中不会对数据进行任何的修改,只是将数据移动到HDFS中Hive设定的目录下,++因此,Hive不支持对数据的改写和添加,所有的数据都是在加载的时候确定的++。对于会SQL语法的来说就是神器,它能让你处理大数据变的很简单,不会再费劲的编写MapReduce程序。

Spark

它是用来弥补基于MapReduce处理数据速度上的缺点,它的特点是把数据装载到内存中计算而不是去读慢的要死进化还特别慢的硬盘。特别适合做迭代运算,所以算法流们特别稀饭它。它是用scala编写的。Java语言或者Scala都可以操作它,因为它们都是用JVM的。

其他相关技术

Sqoop

这个是用于把Mysql里的数据导入到Hadoop里的。当然你也可以不用这个,直接把Mysql数据表导出成文件再放到HDFS上也是一样的,当然生产环境中使用要注意Mysql的压力。

Flume

apache Flume 是一个从可以收集例如日志,事件等数据资源,并将这些数量庞大的数据从各项数据资源中集中起来存储的工具/服务,或者数集中机制。flume具有高可用,分布式,配置工具,其设计的原理也是基于数据流,如日志数据从各种网站服务器上汇集起来存储到HDFS,HBase等集中存储器中。

一般实时系统,所选用组件如下

  • 数据采集 :负责从各节点上实时采集数据,选用Flume来实现
  • 数据接入 :由于采集数据的速度和数据处理的速度不一定同步,因此添加一个消息中间件来作为缓冲,选用apache的kafka
  • 流式计算 :对采集到的数据进行实时分析,选用apache的storm
  • 数据输出 :对分析后的结果持久化,暂定用mysql,另一方面是模块化之后,假如当Storm挂掉了之后,数据采集和数据接入还是继续在跑着,数据不会丢失,storm起来之后可以继续进行流式计算;

Kafka

Kafka的整体架构非常简单,是显式分布式架构,producer、broker(kafka)和consumer都可以有多个。Producer,consumer实现Kafka注册的接口,数据从producer发送到broker,broker承担一个中间缓存和分发的作用。broker分发注册到系统中的consumer。broker的作用类似于缓存,即活跃的数据和离线处理系统之间的缓存。客户端和服务器端的通信,是基于简单,高性能,且与编程语言无关的TCP协议。

Kafka是一种分布式的、基于发布/订阅的消息系统。在流式计算中,Kafka一般用来缓存数据,Storm通过消费Kafka的数据进行计算(KAFKA+STORM+REDIS)。

特点:

  • 消息持久化:通过O(1)的磁盘数据结构提供数据的持久化
  • 高吞吐量:每秒百万级的消息读写
  • 分布式:扩展能力强
  • 多客户端支持:java、php、python、c++ ……
  • 实时性:生产者生产的message立即被消费者可见
  • Kafka是一个分布式消息队列:生产者、消费者的功能。它提供了类似于JMS的特性,但是在设计实 现上完全不同,此外它并不是JMS规范的实现。
  • Kafka对消息保存时根据Topic进行归类,发送消息者称为Producer,消息接受者称为Consumer
  • 无论是kafka集群,还是producer和consumer都依赖于zookeeper集群保存一些meta信息,来保证系统可用性

流处理、批处理、交互式查询

我们将大数据处理按处理时间的跨度要求分为以下几类

基于实时数据流的处理,通常的时间跨度在数百毫秒到数秒之间

基于历史数据的交互式查询,通常时间跨度在数十秒到数分钟之间

复杂的批量数据处理,通常的时间跨度在几分钟到数小时之间