1 大数据概述

1.1 定义

巨量数据集合,指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合,是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

1.2 特征(4V)

  • Volume:数据的超大规模
  • Variety:数据来源多样性与异构性
  • Velocity:数据的高处理速度
  • Value:数据价值密度低

1.3 大数据思维

  • 要相关,不要因果。大数据时代认为没有必要非得知道现象背后的原因,而是要让数据自己“发声”。
  • 要全体,不要抽样。大数据时代认为要分析与某事物相关的所有数据,而非少量的数据样本。
  • 要效率,允许不精确,要注重效率,而不再追求精确。

2 大数据技术体系

图片来源

大数据技术生态体系2

2.1 数据来源

参考文章1
参考文章2

2.1.1 结构化数据

结构化的数据是指可以使用关系型数据库表示和存储,表现为二维形式的数据。一般特点是:数据以行为单位,一行数据表示一个实体的信息,每一行数据的属性是相同的。

结构化数据的存储和排列很有规律,便于查询和修改等操作,但扩展性不高。

2.1.2 半结构化数据

半结构化数据是结构化数据的一种形式,它并不符合关系型数据库或其他数据表的形式关联起来的数据模型结构,但包含相关标记,用来分隔语义元素以及对记录和字段进行分层。因此,它也被称为自描述的结构,扩展性良好。

半结构化数据,属于同一类实体可以有不同的属性,即使他们被组合在一起,这些属性的顺序并不重要

常见的半结构数据有XML、JSON、日志文件、Email等。

2.1.3 非结构化数据

没有固定结构的数据,包括各种文档、图片、视频/音频等。这类数据一般直接整体进行存储,而且一般存储为二进制的数据格式。

2.1.4 概念辨析

  • 结构化、半结构化、非结构化的分类依据是数据格式。

  • 严格来说,结构化与半结构化数据都是有基本固定结构模式的数据

  • 半结构与非结构化数据与大数据之间只是有领域重叠的关系,本质讲两者并无必然联系。

2.2 数据传输

2.2.1 Sqoop

参考文章1
参考文章2
官网
镜像源

Sqoop主要用于在Hadoop与传统的关系型数据库间进行数据的传递,是连接关系型数据库和Hadoop的桥梁,主要有两个方面(导入和导出):

  • 将关系型数据库的数据导入到Hadoop及其相关的系统中,如 Hive和HBase

  • 将数据从Hadoop系统里抽取并导出到关系型数据库

其本质是一个命令行工具,用于迁移数据,工作机制是将导入或导出命令翻译成MapReduce程序来实现的。

2.2.2 Flume

官网
教学视频
参考文章1
参考文章2

Flume是一个分布式的、高可靠的、高可用的将大批量的不同数据源的日志数据收集、聚合、移动到数据中心(HDFS)进行存储的系统,即是日志采集和汇总的工具。Flume支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接收方(可定制)的能力。架构如下:
Flume

  • Source:用于采集收据,Source是产生数据流的地方官,同时Source会将产生的数据流传输到Channel。
  • Channel:用于桥接Source和Sink,类似于一个队列。
  • Sink:从Channel收集数据,将数据写到目标源(可以是下一个source,也可以是HDFS或者HBase)。
  • Event:是Flume数据传输的基本单元,以时间的形式讲过数据从源头传送到目的地。
  • Agent:JVM中一个独立的Flume进程,包含组件Source、Channel、Sink。

2.2.3 Kafka

官方中文文档
教学视频
参考文章
中文教程

Kafka是一个分布式、支持分区的、多副本的、基于ZooKeeper协调的分布式消息系统,主要应用场景是日志收集系统和消息系统。架构如下:

Kafka详细架构

  • Producer:消息生产者,是能够发布消息到Topic的任何对象,向Broker发送消息。
  • Consumer:消息消费者,可以订阅一个或多个话题,并从Broker拉数据,从而消费这些已发布的消息。
  • Broker:一台Kafka服务器就是一个Broker,一个集群由多个Broker组成,一个Broker可以容纳多个Topic。
  • Topic:是特定类型的消息流,生产者和消费者面向的都是一个topic

2.3 数据存储

2.3.1 HDFS

官方文档
参考文章
教学视频1
教学视频2

HDFS(Hadoop Distributed File System)分布式文件系统,是分布式计算中数据存储管理的基础,是Hadoop Core项目的核心子项目。HDFS用于存储文件,通过目录树来定位文件;它是分布式的,由很多服务器联合起来实现其功能,集群中的服务器有各自的角色。HDFS的设计适合一次写入、多次读出的场景,且不支持文件的修改。适合用来做数据分析,并不适合用来做网盘应用。架构如下:

HDFS组成架构

  • Client:客户端,负责上传文件时的切分,与NameNode交互以获取文件的位置信息,与DataNode交互以读取或者写入数据,并提供一些命令来管理HDFS或访问HDFS。
  • NameNode:作为一个管理者管理HDFS的名称空间、数据块(Block)映射信息,配置副本策略并处理客户端读写请求。
  • DataNode:在NameNode下达命令后执行实际的操作,存储了实际的数据块并执行数据块的读/写操作。
  • Secondary NameNode:定期合并主Namenode的namespace image和edit log, 避免edit log过大。它会维护一个合并后的namespace image副本, 可用于在Namenode完全崩溃时恢复数据。

2.3.2 HBase

官网
参考文章1
参考文章2
教学视频
中文教程

HBase是一个分布式的、可扩展、支持海量存储的面向列的开源NoSQL数据库。HBase不同于一般的关系型数据库,它是一个适合于非结构化数据存储的数据库。HBase基于Google BigTable模型开发的,构建在HDFS上,利用MapReduce来处理海量数据,作为一个典型的key/value系统,是Apache Hadoop生态系统中的重要一员。架构如下:

HBase架构

  • ZooKeeper:HBase通过ZooKeeper来做Master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。
  • Master:为RegionServer分配Region、维护整个集群的负载均衡、维护集群的元数据信息、发现失效的Region,并将失效的Region分配到正常的RegionServer上、当RegionSever失效的时候,协调对应Hlog的拆分。
  • RegionServer:直接对接用户的读写请求,管理Master为其分配的Region、处理来自客户端的读写请求、负责和底层HDFS的交互,存储数据到HDFS、负责Region变大以后的拆分、负责Storefile的合并工作。

2.4 资源管理

2.4.1 YARN

官方文档
参考文章1
参考文章2

YARN(Yet Another Resource Negotiator,另一种资源协调者)是一种新的Hadoop资源管理器,它是一个通用资源管理系统和调度平台,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。目前可以支持多种计算框架运行在YARN上,比如MapReduce,Strom,Spark,Flink等。与MapReduce的关系可以理解为,MapReduce只是运行在YARN上的一个应用程序,如果把YARN看作Android,则MapReduce只是一个App。架构如下:

  • ResourceManager:负责所有应用程序之间资源分配。
  • NodeManager:负责Containers,监视其资源使用情况(CPU,内存,磁盘,网络)并将其报告给 ResourceManager。
  • ApplicationMaster:负责协调来自ResourceManager的资源,并与NodeManager一起执行和监视任务。

2.5 数据计算

2.5.1 MapReduce

论文原文
官方文档
参考文章1
参考文章2
参考文章3

MapReduce是一个分布式的离线计算框架,用于海量数据的并行运算,是Hadoop数据分析的核心,仅适用于离线数据处理或批处理。MapReduce的处理过程分为两个步骤:Map和Reduce。Map阶段对输入的数据进行并行处理,处理结果传给Reduce完成最后的汇总。MapReduce框架使得编程人员在不会分布式并行编程的情况下,将编写的业务逻辑代码运行在分布式系统上,开发人员可以将绝大部分的工作集中于业务逻辑上的开发,具体的计算只需要交给框架即可。

mapreduce

2.5.2 Spark

官网
参考文章1
参考文章2
教学视频
中文教程

Spark是基于MapReduce算法实现的分布式计算,拥有MapReduce所具有的优点,但不同于MR的是,Job中间输出和结果可以保存在内存中,从而不再需要读写 HDFS,因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的算法中,高效地支持更多计算模式,包括交互式查询和流处理。 Spark是MapReduce的替代方案,是对Hadoop的补充,而且兼容HDFS、Hive,可融入Hadoop的生态系统,以弥补MapReduce的不足。以下为Spark的生态系统组成:

Spark组成

  • Spark Core:Spark Core包含Spark的基本功能,如内存计算、任务调度、部署模式、故障恢复、存储管理等。Spark建立在统一的抽象RDD(弹性分布式数据集,是分布式内存的一个抽象概念,提供了一种高度受限的共享内存模型)之上,使其可以以基本一致的方式应对不同的大数据处理场景。
  • Spark SQL:Spark SQL允许开发人员直接处理RDD,同时也可查询Hive、HBase等外部数据源。Spark SQL的一个重要特点是其能够统一处理关系表和RDD,使得开发人员可以轻松地使用SQL命令进行查询,并进行更复杂的数据分析。
  • Spark Streaming:支持高吞吐量、可容错处理的实时流数据处理,其核心思路是将流式计算分解成一系列短小的批处理作业。
  • MLlib:MLlib提供了常用机器学习算法的实现,包括聚类、分类、回归、协同过滤等。
  • GraphX:GraphX是Spark中用于图计算的API。

2.5.3 Storm

官网
中文教程
参考博客
参考文章

Storm是一个免费开源、分布式、高容错的实时计算系统,令持续不断的流计算变得容易,弥补了Hadoop批处理所不能满足的实时要求。分布式实时计算强调实时性,常用于实时性要求较高的地方,提供了大吞吐量的实时计算能力。通过数据入口获取每条到来的数据,在一条数据到达系统的时候,立即会在内存中进行相应的计算;Storm适合要求实时性较高的数据分析场景。架构如下:

  • Nimbus:负责在集群分发任务(Topology)的代码以及监控等。
  • Supervisor:并不是自己直接执行任务。在接受到一个任务的时候,会启动一个或多个进程来处理任务。
  • ZooKeeper:Storm主要使用ZooKeeper来协调一个集群中的状态信息,比如任务的分配情况,worker的状态,supervisor之间的nimbus的拓扑度量。nimbus和supervisor节点之间的通信主要是结合 ZooKeeper 的状态变更通知和监控通知来处理的。

2.5.4 Hive

官方文档
教学视频
参考文章
中文教程

Hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供简单的SQL查询功能,可以将SQL语句转换为MapReduce任务进行运行。 其优点是学习成本低,可以通过类SQL语句快速实现简单的MapReduce统计,不必开发专门的MapReduce应用,十分适合数据仓库的统计分析。
Hive依赖于HDFS存储数据,将HQL转换成MapReduce执行,所以说Hive是基于Hadoop的一个数据仓库工具,实质就是一款基于HDFS的MapReduce计算框架,对存储在HDFS中的数据进行分析和管理。架构如下:
Hive

2.5.5 Mahout

官网
参考文章1
参考文章2

Mahout是一个算法库,集成了很多算法。Apache Mahout提供一些可扩展的机器学习领域经典算法的实现,旨在帮助开发人员更加方便快捷地创建智能应用程序。通过使用Apache Hadoop库,Mahout可以有效地扩展到Hadoop集群。最大的优点就是基于Hadoop实现,把很多以前运行于单机上的算法转化为了MapReduce模式,这样大大提升了算法可处理的数据量和处理性能。当前Mahout支持主要的4个用例:

  • 推荐挖掘:搜集用户动作并以此给用户推荐可能喜欢的事物。
  • 聚集:收集文件并进行相关文件分组。
  • 分类:从现有的分类文档中学习,寻找文档中的相似特征,并为无标签的文档进行正确的归类。
  • 频繁项集挖掘:将一组项分组,并识别哪些个别项会经常一起出现。

2.6 数据平台协调与调度

2.6.1 ZooKeeper

官网
参考文章

ZooKeeper是一个开源的分布式的、为分布式应用提供协调服务的Apache子项目,是一个分布式服务框架,是Hadoop、HBase和其他分布式框架使用的有组织服务的标准。主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。简单来说ZooKeeper=文件系统+监听通知机制。ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。

3 大数据生态圈

3.1 生态圈解析

图片来源&参考文章

蓝色部分是Hadoop生态系统组件,黄色部分是Spark生态组件,虽然他们是两种不同的大数据处理框架,但它们不是互斥的,Spark与Hadoop中的MapReduce是一种相互共生的关系。Hadoop提供了Spark许多没有的功能,比如分布式文件系统,而Spark提供了实时内存计算,速度非常快。

3.2 技术发展趋势

  • Spark在崛起,Hadoop和Storm中的一些组件在消退。
  • HQL未来可能会被Spark SQL替代,现在很多企业都是HQL和Spark SQL两种工具共存,当Spark SQL逐步成熟的时候,就有可能替换HQL。
  • MapReduce也有可能被Spark替换,但目前Spark还不够成熟稳定。
  • Hadoop中的算法库Mahout正被Spark中的算法库MLib所替代。
  • 由于Spark和Hadoop天衣无缝的结合,Spark在逐步的走向成熟和稳定,其生态组件也在逐步地完善,因此Storm出于不是Hadoop生态中的一员,会逐步被挤压而走向衰退。