深入浅出：探索Hadoop生态系统的核心组件与技术架构

前言

HDFS

Yarn

Hive

HBase

Spark及Spark Streaming

书本与课程推荐

关于作者：

推荐理由：

作者直播推荐：

前言

进入大数据阶段就意味着进入NoSQL阶段，更多的是面向OLAP场景，即数据仓库、BI应用等。

大数据技术的发展并不是偶然的，它的背后是对于成本的考量。集中式数据库或者基于MPP架构的分布数据库往往采用的都是性能稳定但价格较为昂贵的小型机、一体机或者PC服务器等，扩展性相对较差；而大数据计算框架可以基于价格低廉的普通的硬件服务器构建，并且理论上支持无限扩展以支撑应用服务。

在大数据领域中最有名的就是 Hadoop 生态，总体来看，它主要由三部分构成： 底层文件存储系统 HDFS （Hadoop Distributed File System，Hadoop 分布式文件系统）、 资源调度计算框架 Yarn （Yet Another Resource Negotiator，又一个资源协调者）以及基于 HDFS 与 Yarn的上层应用组件，例如 H Base、Hive 等。一个典型的基于 Hadoop 的应用如下图所示。

HDFS

HDFS 被设计成适合运行在通用硬件（Commodity Hardware）上的分布式文件系统。它和现有的分布式文件系统有很多共同点，例如典型的 Master-Slave 架构（这里不准备展开介绍），也有不同点， HDFS 是一个具有高度容错性的系统，适合部署在廉价的机器上。 关于HDFS 这里主要想说两点，默认副本数的设置以及机架感知（Rack Awareness）。

HDFS 默认副本数是 3，这是因为 Hadoop 有着高度的容错性，从数据冗余以及分布的角度来看，需要在同一机房不同机柜以及跨数据中心进行数据存储以保证数据最大可用。因此，为了达到上述目的，数据块需要至少存放在同一机房的不同机架（2 份）以及跨数据中心的某一机架（1 份）中，共 3 份数据。

机架感知的目的是在计算中尽量让不同节点之间的通信能够发生在同一个机架之内，而不是跨机架，进而减少分布式计算中数据在不同的网络之间的传输，减少网络带宽资源的消耗。例如当集群发生数据读取的时候，客户端按照由近到远的优先次序决定哪个数据节点向客户端发送数据，因为在分布式框架中，网络 I/O 已经成为主要的性能瓶颈。

只有深刻理解了这两点，才能理解为什么 Hadoop 有着高度的容错性。 高度容错性是Hadoop 可以在通用硬件上运行的基础。

Yarn

Yarn 是继 Common、HDFS、MapReduce 之后 Hadoop 的又一个子项目，它是在MapReduceV2 中提出的。

在 Hadoop1.0 中，JobTracker 由资源管理器（由 TaskScheduler 模块实现）和作业控制（由 JobTracker 中多个模块共同实现）两部分组成。

在 Hadoop1.0 中，JobTracker 没有将资源管理相关功能与应用程序相关功能拆分开，逐渐成为集群的瓶颈，进而导致集群出现可扩展性变差、资源利用率下降以及多框架支持不足等多方面的问题。

在 MapReduceV2 中，Yarn 负责管理 MapReduce 中的资源（内存、CPU 等）并且将其打包成 Container。这样可以使 MapReduce 专注于它擅长的数据处理任务，而不需要考虑资源调度。这种松耦合的架构方式实现了 Hadoop 整体框架的灵活性。

Hive

Hive 是基于Hadoop 的数据仓库基础构架，它利用简单的 SQL 语句（简称 HQL）来查询、分析存储在 HDFS 中的数据，并把 SQL 语句转换成 MapReduce 程序来进行数据的处理。Hive与传统的关系型数据库的主要区别体现在以下几点。

1）存储的位置 ， Hive 的数据存储在 HDFS 或者 HBase 中，而后者的数据一般存储在裸设备或者本地的文件系统中，由于 Hive 是基于 HDFS 构建的，那么依赖 HDFS 的容错特性，Hive 中的数据表天然具有冗余的特点。

2）数据库更新 ， Hive 是不支持更新的，一般是一次写入多次读写（这部分从 Hive 0.14之后开始支持事务操作，但是约束比较多），但是由于 Hive 是基于 HDFS 作为底层存储的，而 HDFS 的读写不支持事务特性，因此 Hive 的事务支持必然需要拆分数据文件以及日志文件才能支持事务的特性。

3）执行 SQL 的延迟 ，Hive 的延迟相对较高，因为每次执行都需要将 SQL 语句解析成MapReduce 程序。

4）数据的规模上 ，Hive 一般是 TB 级别，而后者规模相对较小。

5）可扩展性上 ，Hive 支持 UDF、UDAF、UDTF，后者相对来说可扩展性较差。

HBase

HBase（Hadoop Database）是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。它底层的文件系统使用 HDFS，使用ZooKeeper 来管理集群的 HMaster 和各RegionServer 之间的通信，监控各RegionServer 的状态，存储各 Region 的入口地址等。

1．特点

HBase 是 Key-Value 形式的数据库（类比 Java 中的 Map）。既然是数据库那肯定就有表，HBase 中的表大概有以下几个特点。

1）大：一个表可以有上亿行，上百万列（列多时，插入变慢）。

2）面向列：面向列（族）的存储和权限控制，列（族）独立检索。

3）稀疏：对于空（null）的列，并不占用存储空间，因此，表可以设计得非常稀疏。

4）每个单元格中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳。

5）HBase 中的数据都是字节，没有类型定义具体的数据对象（因为系统需要适应不同类型的数据格式和数据源，不能预先严格定义模式）。

这里需要注意的是，HBase 也是基于 HDFS，所以也具有默认 3 个副本、数据冗余的特点。此外 HBase 也是利用 WAL 的特点来保证数据读写的一致性。

2．存储

HBase 采用列式存储方式进行数据的存储。传统的关系型数据库主要是采用行式存储的方式进行数据的存储，数据读取的特点是按照行的粒度从磁盘上读取数据记录，然后根据实际需要的字段数据进行处理，如果表的字段数量较多，但是需要处理的字段较少（特别是聚合场景），由于行式存储的底层原理，仍然需要以行（全字段）的方式进行数据的查询。在这个过程中，应用程序所产生的磁盘 I/O、内存要求以及网络 I/O 等都会造成一定的浪费；而列式存储的数据读取方式主要是按照列的粒度进行数据的读取，这种按需读取的方式减少了应用程序在数据查询时所产生的磁盘 I/O、内存要求以及网络 I/O。

此外，由于相同类型的数据被统一存储，因此在数据压缩的过程中压缩算法的选用以及效率将会进一步加强，这也进一步降低了分布式计算中对于资源的要求。

列式存储的方式更适合 OLAP 型的应用场景，因为这类场景具有数据量较大以及查询字段较少（往往都是聚合类函数）的特点。例如最近比较火的 ClickHouse 也是使用列式存储的方式进行数据的存储。

Spark及Spark Streaming

Spark 由 Twitter 公司开发并开源，解决了海量数据流式分析的问题。Spark 首先将数据导入 Spark 集群，然后通过基于内存的管理方式对数据进行快速扫描，通过迭代算法实现全局 I/O 操作的最小化，达到提升整体处理性能的目的。这与 Hadoop 从“计算”找“数据” 的实现思路是类似的，通常适用于一次写入多次查询分析的场景。

Spark Streaming 是基于 Spark 的一个流式计算框架，它针对实时数据进行处理和控制，并可以将计算之后的结果写入 HDFS。它与当下比较火的实时计算框架 Flink 类似，但是二者在本质上是有区别的，因为 Spark Streaming 是基于微批量（Micro-Batch）的方式进行数据处理，而非一行一行地进行数据处理。