HDFS架构

Hadoop 分布式文件系统(HDFS)是 Hive 存储数据的地方，简单了解HDFS的基本机制和读写工作机制，对于排查HiveSQL 程序是否由于数据存储引发的性能问题有较大的帮助。

4.3.1 常见HDFS优化

常见的关于HDFS的优化角度有：

● Hive 作业生成的小文件，过多的小文件会加重NameNode 的负担，导致集群整体性能下降。

● 设置合理的HDFS文件块的大小，可以减轻NameNode的负担，增加数据本地化操作的概率，提升程序性能。

● 适当增大NameNode的Java堆，调整JVM的参数可以提升NameNode性能。

● 在集群进行扩容和缩容的情况时，需要调整NameNode 服务处理程序计数和NameNode 处理程序计数。

● 在HDFS写入大数据文件的时候，可以尝试启用写入后清理缓存，启用写入后立即对磁盘数据排队。

● 在HDFS有比较多的随机读，或者一次性需要读取大数据文件时，可以启用读取后清理缓存。

● 集群的单机性能较高，可以适当增大处理程序计数。

● HDFS在读取数据时会开启HDFS快速读取。

看到上面列举的例子中提到的很多概念，对于只是接触过HiveSQL 的读者来说可能不理解，甚至还会有一些疑问，例如：

● NameNode、DataNode是什么？

● NameNode服务处理程序计数和程序处理技术器又是什么？

● 配置读取后清理缓存为什么能增加程序性能？

● HDFS快速读取是什么？

这里先不着急回答这些问题，在了解了HDFS架构后，上面的一些调优就会变得可以理解，疑问自然可以得到解开了。随着对HDFS了解的增多，还有更多的优化选项可以挖掘。

注意：虽然对于使用HiveSQL的开发者来说，不了解Java和JVM也能够写SQL，也能进行日常的一些开发和调优。但想要自己的调优能力得到提升，学习Java 和JVM是必要的。

要求能够了解Java的语法并能使用其集合，简单了解Java面向对象语言的一些概念，例如封装、继承和多态，并简单了解JVM的模型和垃圾回收的算法。

4.3.2 HDFS基本架构和读写流程

为了对HDFS有整体的了解,主要会介绍HDFS的基本架构和读写流程。

1:HDFS基本架构HDFS基本架构如图4.14所示。

图4.14 HDFS基本架构

整个HDFS主要有3个组件：NameNode、DataNode和Client。

下面对这3个组件做个简要介绍。Client主要有以下几个职能：

● 与NameNode进行交互，获取文件位置信息和文件块信息。

● 与DataNode进行交互，读写数据文件。

● 访问并管理HDFS集群。常见的访问HDFS客户端方式有：

● 命令行交互界面，在安装HDFS组件时自带。

● 使用HttpFs服务，HttpFs提供Rest风格的操作接口，用于访问HDFS。

● 访问NameNode提供的Web服务，默认端口是50070。

扩展：在获取文件存储块的位置时，通常会配置超时时间，减少作业因集群组件异常导致的作业长时间等待

(配置项：dfs.client.file-block-storage-locations.timeout, dfs. client.file-block-storage-locations.timeout.millis)。

NameNode(NN)维护整个HDFS文件系统的目录树，以及目录树里的所有文件和目录，这些信息以两种文件存储在本地文件中：一种是NameSpace 镜像(FSImage)，即HDFS元数据的完整快照，每次NameNode启动时，默认加载最新的命名空间镜像；

另一种是命名空间镜像的编辑日志(EditLog)，它主要有几个职能：

● 管理HDFS的NameSpace，如打开、关闭重命名文件和目录。

● 管理数据块与DataNode的映射关系。

● 处理客户端的读写请求。

● 管理副本的配置策略。

在较早的HDFS版本中还有一个关键组件：SecondaryNameNode(简称SNN)。SNN被设计用来辅助并分担NN的运行压力，主要用于定期合并命名空间镜像和命名空间镜像的编辑日志。

NN在进行变更的时候会将变更操作到EditLog中，为了防止EditLog 丢失及整个日志文件过大，在出现集群故障时，恢复成本大，需要定期将编辑日志进行归档，将编辑日志和整个NameSpace镜像文件进行合并。NameNode为了防止日志读写及合并可能需要占用太多资源的情况，将这部分工作交给SNN。

DataNode节点(DN)的功能如下：

● 处理客户端的读写请求。

● 存储实际的数据。

● 接收NameNode指令创建数据块。

查看当前DataNode整体信息，可以采用如下命令：

通过上面的命令，可以快速查看当前HDFS存活节点的信息、磁盘使用情况信息及缓存使用情况信息等，通过这些信息，我们可以快速排除因节点不可用或磁盘空间不足引起的作业运行的异常。

可以使用HDFS的hdfs --help命令来获取帮助。

2.HDFS的读流程

(1)Client先与NameNode进行交互，获取数据所在DataNode的地址和文件块信息。

(2)Client 根据从NameNode 得到的消息找到DataNode 及对应的文件块，建立socket流。

(3)DataNode读取磁盘中的文件中回传给Client。

扩展：HDFS快速读取模式，Client会绕开DataNode,自己去读取数据，实现方式是借助Linux 操作系统中的Unix Domain Socket 技术。在使用这个技术的时候要配置UNIX 域套接字路径。当DataNode 需要读取的数据非常大且读取后数据无法缓存到操作系统的缓存中时，通过配置属性——读取后清除缓冲区中的所有文件，可以提升其他作业的读取效率。

3.HDFS的写流程

(1)Client先与NameNode通信，表示要写入数据，NameNode会在NameSpace中添加一个新的空文件，并告知Client已经做好写的准备工作

(2)Client接到通知，向NameNode申请DataNode的数据块，NameNode会返回一个数据块，包含所有数据节点所在DataNode的位置信息。

(3)Client得到目标数据块位置，建立socket流，并向目标数据块写入数据。

HDFS高可用架构

在实际生产环境中，单个NameNode的HDFS集群基本不用，因为存在以下的情况：

● NameNode服务器或者NameNode本身出现异常，会导致整个HDFS集群不可用，从而导致Hive的程序出现异常。

● 在运维人员维护NameNode服务器时，会导致整个HDFS集群不可用，从而导致所有Hive任务延期。

针对上面可能出现的问题，HDFS 引入了高可用(High Availability, HA)特性，在同一个集群引入多NN用来解决上述问题，允许如果出现故障启用备用的NN节点，快速进行故障转移(failover)。当需要对集群的NN进行例行运维时，可以启用备用的节点，而不影响正常的线上生产。

HDFS提供了两种HA方案：

NameNode HA With QJM与NameNode HA WithNFS。

第一种是业界较为主流的方案，如图4.15所示为第一种架构的架构图。

图4.15 HDFS HA架构

扩展：心跳指一个程序给另外一个程序周期性定时发送一个简单命令，以告知该程序还在运行，是存活的状态。

整个架构包含如下高可用设计：

NameNode服务的高可用设计新增NN Standby节点。在HA集群中，要有两个或更多独立的机器节点被配置为Name Node。在任何时间点，恰好有一个NameNode处于活动状态，而其他的NN处于备用状态。

活动NN负责集群中的所有客户端操作，而备用节点只是维护自己当前的状态和NN节点保持一致以便在必要时提供快速故障转移。

2.JounalNode 服务的高可用设计

新增一组JounalNode节点。为了让备用节点与活动节点保持同步状态，两个节点都与一组称为Journal Nodes(简称JNs)的独立守护进程通信。JNs是一个副本集，一般为3个副本，当有2个副本可以对外提供服务时，整个系统还处于可用状态。

当活动节点执行任何的NameSpace内容修改时，它会持续地将修改记录写到这些JNs中。备用节点能够从JNs读取日志，并不断监视它们对编辑日志的更改。当备用节点看到编辑时，会将它们应用到自己的名称空间。这样可确保在发生故障并在故障转移发生之前的两个NN状态完全同步。

3．服务存储状态的高可用设计

新增ZooKeeper(ZK)组件，使用多个副本用于存储HDFS集群服务状态信息。

4．故障转移控制服务的高可用设计

故障转移控制服务，发现监控的NN没有心跳，会尝试获取NN standy地址，并启动该服务，原先的standy状态变为active。但只有一个故障转移控制服务，如果不做高可用设计，也会出现单点问题，所以故障转移控制服务也被设计成支持服务的高可用。

当工作的控制服务发生故障时，会启用备用的控制服务继续对集群提供服务。

扩展：上面的架构不管是在正常情况，还是异常发生在进行故障转移时，只允许一个NN 处在工作状态,其他 NN 都处在备用(standy)状态。

这是为避免两个NN同时工作时，两个 NN 的 NameSpace 状态将会出现差异，也就是“脑裂”现象，这可能导致数据丢失或其他错误结果。

为了保证整个集群正常工作，JournalNodes只允许一个NameNode 与它通信。在故障转移期间，变为活动工作状态的NameNode将接管向JournalNodes写入数据的角色。

4.3.4 NameNode联盟

在绝大多数的场景下，单个NameNode已经够用。我们来算一下：在NameNode创建一个数据块的元数据信息差不多占用500byte，在NameNode节点给予128GB的服务器，实际长期驻留内存设置为100GB，一个元数据对应的数据块大小给予设置256MB，则整个集群能够容纳的数据量是(100×1024^3/500)×256MB=51.2PB。大部分公司的数据都难以达到这个数据量级。

HDFS 的NameNode 高可用能够增强整个HDFS 集群的可用性，保障系统即使在NameNode所在服务的服务器出现故障，也能通过启用其他服务器的NameNode继续对外提供服务。但是，当集群所管理的数据量逐渐增多时，单个NameNode服务所要占用的内存空间也会随着增多，这会带来几个问题：

● NameNode服务垃圾回收(GC)运行时间变长，导致NameNode对外响应效率变低。Hive提交任务大部分都需要访问NameNode服务，这会影响Hive的运行效率。NameNode故障恢复时间变长或集群重启时间长。在进行故障恢复或重启时，单个NameNode需要将大量持久化在磁盘中的文件数据加载到内存中，并在内存构建出整个NameSpace目录树。

● 内存无法一直持续扩展，Hadoop是运行在廉价的服务器集群上，内存资源有限。针对上面的问题，HDFS提出了NameNode联盟架构方案。原先一个NameNode管理一个HDFS集群中的所有数据，现在将一个HDFS集群的数据划分给几个NameNode同时进行管理，这几个NameNode 可以分布在不同的机器上，在对外提供服务时这几个NameNode采用同一的接口提供服务。通过这种方式解决单个NameNode无法管理一个大集群的问题。那么NameNode 联盟架构是怎样的呢？在回答这个问题之前，先来看看一个简化后的HDFS基础架构，如图4.16所示。

图4.16 HDFS基础架构简化图

整个HDFS由两部分组成：命名空间和块存储。

命名空间(NameSpace)由目录、文件和块组成。它支持所有与名称空间相关的文件系统操作，如创建、删除、修改和列出文件和目录。

块存储(Block storage)也由两部分组成：块管理和数据存储。

DataNode 提供本地文件系统数据存储和读写功能。

块管理功能如下：

● 管理DataNode集群，通过周期心跳信息，或者DataNode主动注册动作来判定能够对外提供服务的DataNode节点。

● 处理块信息并维护块的位置。 管理块复制，并删除已过度复制的块。对HDFS整体有个基本的了解后，我们再来看NameNode联盟。

Hadoop为了保证能够提供横向扩展的能力，在NameSpace这一层运行创建多个NameSpace，这几个NameSpace通过块的管理，实现共用 DataNode 的集群。几个NameNode之间的操作不互相影响，只是共用数据存储空间。NameNode架构如图4.17所示。

图4.17 NameNode联盟

图4.17中的每个块池(block pool)都是由单独的NameSpace进行管理，每个Name Space对块的操作包括删除、创建，都是独立于其他NameSpace。当一个Name space出现故障时不会影响其他NameSpace 对外提供服务。每个Name Space 和其对应的块池被统称为一个Name Space volumn，如果删除了DataNode或者Name Space，则也会删除相应的块池。NameNode联盟在一定程度上可以缓解单个NameNode的压力，但是在使用之前要对业务数据量有一个合理的预估和拆分，确保NameNode联盟中的单个NameNode的有足够资源满足需求。

计算引擎

HiveSQL最后都会转化成各个计算引擎所能执行的任务，目前Hive支持MapReduce、Tez和Spark 3种计算引擎。

4.4.1 MapReduce计算引擎

MapReduce(简称MR)很简单，也很重要。在Hive 2.0之后不推荐MR作为计算引擎，但从学习的角度来看，它是学习所有分布式计算的基础，理解了MR的基本工作原理，对于学习Tez、Spark，甚至是学习实时流计算引擎Spark Streaming、Flink和Strom也能起到很好的助益。

MR计算主要提供两个编程接口给开发者，即Mapper和Reducer。MR计算引擎约定编程接口的输入和输出格式。不管是Mapper 还是Reducer 的输入和输出格式，MR 都统一成键-值对的形式，通过这业务无关的基础数据结构，达到兼容各种业务场景的目的。

这种简单的编程接口同时屏蔽了大部分的技术细节，能够让业务人员专注在Mapper或者Reducer 上开发自己的业务代码。但从优化的角度来说，只知道Mapper 和Reducer编程接口还不够。优化往往还需要根据当时的环境信息，对能影响MR运行的某些关键环节做调整。而这些在编程接口中并没有体现。

下面来看下MR运行的完整过程：

Map 在读取数据时，先将数据拆分成若干数据，并读取到Map 方法中被处理。数据在输出的时候，被分成若干分区并写入内存缓存(buffer)中，内存缓存被数据填充到一定程度会溢出到磁盘并排序，当Map 执行完后会将一个机器上输出的临时文件进行归并存入到HDFS中。当Reduce 启动时，会启动一个线程去读取Map 输出的数据，并写入到启动Reduce机器的内存中，在数据溢出到磁盘时会对数据进行再次排序。当读取数据完成后会将临时文件进行合并，作为Reduce函数的数据源。整个过程如图4.18所示。

图4.18 Map和Reduce的工作流程

4.4.2 Tez计算引擎

Apache Tez 是进行大规模数据处理且支持DAG 作业的计算框架，它直接源于MapReduce 框架，除了能够支持MapReduce 特性，还支持新的作业形式，并允许不同类型的作业能够在一个集群中运行。MapReduce为了面向批处理的数据处理作业通用性，强制要求每个作业必须要有特定的输入和输出结构。但这种和业务场景无太多关联的结构，合并了太多的细节，提供给用户可操作的空间较少，Tez考虑到这点提供了比MapReduce更丰富的功能。Tez将原有的Map和Reduce两个操作简化为一个概念——Vertex，并将原有的计算处理节点拆分成多个组成部分：Vertex Input、Vertex Output、Sorting、Shuffling和Merging。计算节点之间的数据通信被统称为Edge，这些分解后的元操作可以任意灵活组合，产生新的操作，这些操作经过一些控制程序组装后，可形成一个大的DAG作业。

通过允许Apache Hive运行复杂的DAG任务，Tez可以用来处理数据，之前需要多个MR jobs，现在一个Tez任务中。

如图4.19所示,为MapReduce作业和Tez作业运行时的对比图。

图4.19 Tez和MapReduce作业的比较

从图4.19中我们可以看到，Tez绕过了MapReduce很多不必要的中间的数据存储和读取的过程，直接在一个作业中表达了MapReduce需要多个作业共同协作才能完成的事情。

Tez和MapReduce一样都运行使用YARN作为资源调度和管理。但与MapReduceon YARN 不同，Tez on YARN 并不是将作业提交到ResourceManager，而是提交到AMPoolServer的服务上，AMPoolServer存放着若干已经预先启动ApplicationMaster的服务。

如图4.20所示为AMPoolServer预先创建AM的示意图。

图4.20 AMPoolServer预先创建AM示意图

当用户提交一个作业上来后，AMPoolServer 从中选择一个ApplicationMaster 用于管理用户提交上来的作业，这样既可以节省ResourceManager创建ApplicationMaster的时间，而又能够重用每个ApplicationMaster 的资源，节省了资源释放和创建时间。如图4.21所示为Tez接收作业提交YARN的示意图。

图4.21 Tez作业的提交

总结起来Tez相比于MapReduce有几点重大改进：当查询需要有多个reduce逻辑时，Hive的MapReduce引擎会将计划分解，每个Redcue提交一个MR作业。这个链中的所有MR作业都需要逐个调度，每个作业都必须从HDFS中重新读取上一个作业的输出并重新洗牌。而在Tez中，几个reduce接收器可以直接连接，数据可以流水线传输，而不需要临时HDFS文件，这种模式称为MRR(Map-reduce-reduce*)。

Tez还允许一次发送整个查询计划，实现应用程序动态规划，从而使框架能够更智能地分配资源，并通过各个阶段流水线传输数据。对于更复杂的查询来说，这是一个巨大的改进，因为它消除了IO/sync障碍和各个阶段之间的调度开销。

例如下面场景可以得到一个较大的优化：

在MapReduce 计算引擎中，无论数据大小，在洗牌阶段都以相同的方式执行，将数据序列化到磁盘，再由下游的程序去拉取，并反序列化。

Tez可以允许小数据集完全在内存中处理，而MapReduce 中没有这样的优化。

仓库查询经常需要在处理完大量的数据后对小型数据集进行排序或聚合，Tez的优化也能极大地提升效率。

4.4.3 LLAP长时在线与处理程序

长时在线与处理程序(Live Long And Process)在Hive 2.0中被新引入，目前可以跟Tez一起搭配使用降低数据的处理延迟，极大地增强了Hive的交互。

如图4.22所示为LLAP的架构图

图4.22 LLAP的架构图

在TPC-DS的测试中，Tez结合LLAP在某些场景的执行速度已经优于Impala、Presto等交互性较强的大数据组件。Tez结合LLAP创造了一个混合的执行模型，一个由长时在线的守护进程和基于DAG 的计算框架组成的执行模型。该守护进程替代原来和HDFS DataNode的直接交互，且LLAP将数据缓存、预取，一些简单的查询操作和访问控制也都放到该守护进程进行处理。如图4.23所示为作业在Tez上运行和Tez+LLAP运行的对比。

图4.23 Tez结合LLAP

从图4.23中我们可以看到，在Tez结合LLAP的环境中，集群中运行的任务不需要每启动一个任务单独和HDFS进行交互，而是统一交给节点，节点取得数据后进行缓存，集群中运行的任务可以共享这些缓存数据。这种方式极大地减少了读取磁盘的操作次数。

缓存在内存中的数据对于提升作业的运行速度也有一定的帮助。LLAP仅仅是增强了Hive的交互。对于超大数据集的操作，LLAP的操作需要缓存大量数据，容易导致内存出现问题。Hive允许将任务直接提交给Tez，由Yarn进行调度和执行，从而绕开了LLAP。

对LLAP有一定的了解后，我们就来仔细盘点下LLAP的特性。

(1)新增长久活跃的守护进程，该进程被部署到集群的各个工作节点中，这些节点处理I/O、缓存和查询片段的执行。这些后台进程有以下特性：

● 无状态(stateless)。任何对LLAP 节点的请求，自身都必须包含数据的位置和元数据信息。LLAP可以处理本地和远程的数据。

● 任务的快速恢复。由于LLAP的后台守护进程是无状态，所以任何节点都可以处理输入的数据和逻辑。如果一个LLAP的后台守护进程停止工作，只需要在另外一个进程中重新执行作业即可。

● 弹性扩容。LLAP 的无状态，决定了LLAP 扩容较为简单和方便，可以支持弹性扩容。

● 节点之间的客户可互相通信，LLAP节点能够共享数据。

(2)增强了计算引擎。LLAP是基于现有的Hive，它不是新的计算引擎，只是对现有计算引擎的增强。

● 后台的守护进程是可选的，Hive可以绕过它们或在没有它们的情况下正常运行。

● 搭配计算引擎，LLAP不是一个计算引擎(如Spark, Tez, MapReduce)，整个作业的运行都是通过Hive的计算引擎放到LLAP节点和常规容器中。目前LLAP只支持Tez。

● 部分执行。LLAP可以将部分的查询放到外部容器中运行，自身只提供部分的计算结果。

● 资源管理，YARN依然负责资源的管理和分配。原先YARN是将资源分配给容器，引入LLAP, YARN会将资源分配转移到LLAP中。整个LLAP的资源还是在YARN的控制之下。

(3)优化I/O，减轻I/O的负载。LLAP能够将已经压缩的数据传输到一个独立线程中，并且一旦数据准备好了就可以立马被处理，而不用像MapReduce需要等待Map阶段OK才会开始下个阶段的数据处理。LLAP数据在处理时被处理成RLE编码的列式格式，这种格式能够方便LLAP向量化处理数据。在数据缓存时也采用这种方式最小化数据，减少在计算缓存以及数据传输过程中的I/O负载。LLAP支持多种数据存储格式及SQL的谓词下推和布隆过滤。

(4)缓存数据，LLAP的守护进程可以缓存输入的文件和数据的元数据信息，也可以缓存当前没在缓存数据中的元数据和索引信息。元数据信息被存储在Java 堆中，而缓存数据则被存储到对外缓存中。

(5)提供事务支持。在LLAP中新增的后台守护进程，由于其代替了与DataNode的直接操作，开发者可以在这之上做更多的访问权限控制，例如列级别等更加细粒度的访问控制。

4.4.4 Spark计算引擎

Apache Spark是专为大规模数据处理而设计的快速、通用支持DAG(有向无环图)作业的计算引擎，类似于Hadoop MapReduce的通用并行框架，可用来构建大型的、低延迟的数据分析应用程序。Spark具有以下几个特性。

1．高效性,Spark会将作业构成一个DAG，优化了大型作业一些重复且浪费资源的操作，对查询进行了优化，重新编写了物理执行引擎，如可以实现MRR模式。

2．易用性：Spark 不同于MapReducer 只提供两种简单的编程接口，它提供了多种编程接口去操作数据，这些操作接口如果使用MapReduce去实现，需要更多的代码。

Spark的操作接口可以分为两类：transformation(转换)和action(执行)。Transformation包含map、flatmap、distinct、reduceByKey和join等转换操作；Action包含reduce、collect、count和first等操作。

3．通用性：Spark 针对实时计算、批处理、交互式查询，提供了统一的解决方案。但在批处理方面相比于MapReduce处理同样的数据，Spark所要求的硬件设施更高，MapReduce在相同的设备下所能处理的数据量会比Spark 多。所以在实际工作中，Spark 在批处理方面只能算是MapReduce的一种补充。

4．兼容性：Spark和MapReduce一样有丰富的产品生态做支撑。例如Spark可以使用YARN作为资源管理器，Spark也可以处理Hbase和HDFS上的数据。在实际生产环境中Spark都会被纳入同集群的YARN等资源管理器中进行调度，我们称之为Spark On YARN。Spark On YARN的读写方式类似于MapReduce OnYARN。

扩展：Spark On YARN提供了两种提交作业的模式：

YARN Client和YARN Cluster。两个模式在运行计算节点，完成数据从读入、处理、输出的过程基本一样。不同的是，YARN Client 作业的监控管理放在提交作业所在的节点，YARNCluster则是交给YARN 去决定，YARN 会根据集群各个节点资源的使用情况，选择最为合适的节点来存放作业监控和管理进程。YARN Client一般用于测试，YARN Cluster用于实际生产环境。