Hadoop大数据 --HDFS

Apache Hadoop 软件库是一个框架，允许在集群服务器上使用简单的编程模型对大数据集进行分布式处理。Hadoop 被设计成能够从单台服务器扩展到数以千计的服务器，每台服务器都有本地的计算和存储资源。Hadoop 的高可用性并不依赖硬件，其代码库自身就能在应用层侦测并处理硬件故障，因此能基于服务器集群提供高可用性的服务。

HDFS：Hadoop 生态圈的基本组成部分是 Hadoop 分布式文件系统（HDFS）。HDFS 是一种分布式文件系统，数据被保存在计算机集群上，HDFS 为 HBase 等工具提供了基础。
MapReduce：Hadoop 的主要执行框架是 MapReduce，它是一个分布式、并行处理的编程模型，MapReduce 把任务分为 map(映射)阶段和 reduce(化简)阶段。由于 MapReduce 工作原理的特性，Hadoop 能以并行的方式访问数据，从而实现快速访问数据。
Hbase：HBase 是一个建立在 HDFS 之上，面向列的 NoSQL 数据库，用于快速读/写大量数据，HBase 使用 Zookeeper 进行管理。
Zookeeper：用于 Hadoop 的分布式协调服务。Hadoop 的许多组件依赖于 Zookeeper，它运行在计算机集群中，用于管理 Hadoop 集群。
Pig：它是 MapReduce 编程的复杂性的抽象。Pig 平台包括运行环境和用于分析 Hadoop 数据集的脚本语言(Pig Latin)，其编译器将 Pig Latin 翻译成 MapReduce 程序序列。
Hive：类似于 SQL 高级语言，用于运行存储在 Hadoop 上的查询语句，Hive 让不熟悉 MapReduce 的开发人员也能编写数据查询语句，然后这些语句被翻译为 Hadoop 上面的 MapReduce 任务。像 Pig 一样，Hive 作为一个抽象层工具，吸引了很多熟悉 SQL 而不是 Java 编程的数据分析师。
Sqoop：一个连接工具，用于在关系数据库、数据仓库和 Hadoop 之间转移数据。Sqoop 利用数据库技术描述架构，进行数据的导入/导出；利用 MapReduce 实现并行化运行和容错技术。
Flume：提供了分布式、可靠、高效的服务，用于收集、汇总大数据，并将单台计算机的大量数据转移到 HDFS。它基于一个简单而灵活的架构，利用简单的可扩展的数据模型，将企业中多台计算机上的数据转移到 Hadoop 中。

Hadoop 安装有如下三种方式：

单机模式：安装简单，几乎不用做任何配置，但仅限于调试用途；
伪分布模式：在单节点上同时启动 NameNode、DataNode、JobTracker、TaskTracker、Secondary Namenode 等 5 个进程，模拟分布式运行的各个节点；
完全分布式模式：正常的 Hadoop 集群，由多个各司其职的节点构成。

HDFS（Hadoop Distributed File System）是一个分布式文件系统。它具有高容错性并提供了高吞吐量的数据访问，非常适合大规模数据集上的应用，它提供了一个高度容错性和高吞吐量的海量数据存储解决方案。

高吞吐量访问：HDFS 的每个 Block 分布在不同的 Rack 上，在用户访问时，HDFS 会计算使用最近和访问量最小的服务器给用户提供。由于 Block 在不同的 Rack 上都有备份，所以不再是单数据访问，速度和效率是非常快的。另外 HDFS 可以并行从服务器集群中读写，增加了文件读写的访问带宽。
高容错性：系统故障不可避免，如何做到故障之后的数据恢复和容错处理是至关重要的。HDFS 通过多方面保证数据的可靠性，多份复制并且分布到物理位置的不同服务器上，数据校验功能、后台的连续自检数据一致性功能都为高容错提供了可能。
线性扩展：因为 HDFS 的 Block 信息存放到 NameNode 上，文件的 Block 分布到 DataNode 上，当扩充的时候仅仅添加 DataNode 数量，系统可以在不停止服务的情况下做扩充，不需要人工干预。

Namenode

namenode又称为名称节点，是负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog。

FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据
操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作
注意，这个两个都是文件，也会加载解析到内存中。
为啥会拆成两个呢? 主要是因为fsimage这个文件会很大的，多了之后就不好操作了，就拆分成两个。把后续增量的修改放到EditLog中, 一个FsImage和一个Editlog 进行合并会得到一个新的FsImage.

除了namenode 、data nod、节点外还有一个sendaryNamenode的节点用来做备份

SecondaryNameNode的工作情况：
1. SecondaryNameNode会定期和NameNode通信，请求其停止使用EditLog文件，暂时将新的写操作写到一个新的文件edit.new上来，这个操作是瞬间完成，上层写日志的函数完全感觉不到差别；
2. SecondaryNameNode通过HTTP GET方式从NameNode上获取到FsImage和EditLog文件，并下载到本地的相应目录下；
3. SecondaryNameNode将下载下来的FsImage载入到内存，然后一条一条地执行EditLog文件中的各项更新操作，使得内存中的FsImage保持最新；这个过程就是EditLog和FsImage文件合并；
4. SecondaryNameNode执行完（3）操作之后，会通过post方式将新的FsImage文件发送到NameNode节点上
5. NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage文件，同时将edit.new替换EditLog文件，通过这个过程EditLog就变小了

除了这个自带的备份操作，还需要进行人工的备份，把一份fsimage到多个地方进行备份，万一namenode的节点坏了呢。

DataNode

datanode数据节点，用来具体的存储文件，维护了blockId 与 datanode本地文件的映射。需要不断的与namenode节点通信，来告知其自己的信息，方便nameode来管控整个系统。

HDFS 2.0

有问题，就得改。1.0上有很多的毛病，为了修复这些问题才出了2.0
* 单点故障问题
* 不可以水平扩展（是否可以通过纵向扩展来解决？）
* 系统整体性能受限于单个名称节点的吞吐量
* 单个名称节点难以提供不同程序之间的隔离性
* HDFS HA是热备份，提供高可用性，但是无法解决可扩展性、系统性能和隔离性

解决上面这些问题所使用的手段就是 热备份 federation

热备份 (HDFS HA)

HDFS HA（High Availability）是为了解决单点故障问题
HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”
两种名称节点的状态同步，可以借助于一个共享存储系统来实现
一旦活跃名称节点出现故障，就可以立即切换到待命名称节点
Zookeeper确保一个名称节点在对外服务
名称节点维护映射信息，数据节点同时向两个名称节点汇报信息

Federation(大概翻译成联盟)

多个命名空间。为了处理一个namenode的局限性，搞了几个namanode大家一起来管理。就像编程中的命名空间一样

在HDFS Federation中，设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联盟（Federation）关系，不需要彼此协调。并且向后兼容
HDFS Federation中，所有名称节点会共享底层的数据节点存储资源，数据节点向所有名称节点汇报
属于同一个命名空间的块构成一个“块池

原文参考：https://blog.csdn.net/weixin_38750084/article/details/82963235 、https://blog.csdn.net/xjz729827161/article/details/79463140

1、HDFS 是做什么的

　　HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集（Large Data Set）的应用处理带来了很多便利。

2、为什么要选择HDFS

优势：

高容错性：数据自动保存多个副本。它通过增加副本的形式，提高容错性

适合批处理：它是通过移动计算而不是移动数据

适合大数据处理：处理数据达到 GB、TB、甚至PB级别的数据

流式文件访问：一次写入，多次读取。文件一旦写入不能修改，只能追加。

可构建在廉价机器上：它提供了容错和恢复机制。比如某一个副本丢失，可以通过其它副本来恢复。

劣势：

低延时数据访问:

比如毫秒级的来存储数据，这是不行的，它做不到。

它适合高吞吐率的场景，就是在某一时间内写入大量的数据。但是它在低延时的情况下是不行的，比如毫秒级以内读取数据，这样它是很难做到的。

小文件存储:

存储大量小文件(这里的小文件是指小于HDFS系统的Block大小的文件（默认64M）)的话，它会占用 NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，因为NameNode的内存总是有限的。
小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。

并发写入、文件随机修改

一个文件只能有一个写，不允许多个线程同时写。
仅支持数据 append（追加），不支持文件的随机修改。

HDFS 如何存储数据:

　HDFS 采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。下面我们分别介绍这四个组成部分

　　1、Client：就是客户端。

文件切分。文件上传 HDFS 的时候，Client 将文件切分成一个一个的Block，然后进行存储。
与 NameNode 交互，获取文件的位置信息。
与 DataNode 交互，读取或者写入数据。
Client 提供一些命令来管理 HDFS，比如启动或者关闭HDFS。
Client 可以通过一些命令来访问 HDFS。

　　2、NameNode：就是 master，它是一个主管、管理者。

管理 HDFS 的名称空间
管理数据块（Block）映射信息
配置副本策略
处理客户端读写请求。

　　3、DataNode：就是Slave。NameNode 下达命令，DataNode 执行实际的操作。

存储实际的数据块。
执行数据块的读/写操作。

　　4、Secondary NameNode：并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。

辅助 NameNode，分担其工作量。
定期合并 fsimage和fsedits，并推送给NameNode。
在紧急情况下，可辅助恢复 NameNode。

其实这个hdfs 和 k8s 差多，有maste 节点也是主节点，然后就是node 节点，虽然有一定差距，但他们也是有类似地方的。

HDFS 如何读取文件：

HDFS的文件读取原理，主要包括以下几个步骤：

首先调用FileSystem对象的open方法，其实获取的是一个DistributedFileSystem的实例。
DistributedFileSystem通过RPC(远程过程调用)获得文件的第一批block的locations，同一block按照重复数会返回多个locations，这些locations按照hadoop拓扑结构排序，距离客户端近的排在前面。
前两步会返回一个FSDataInputStream对象，该对象会被封装成 DFSInputStream对象，DFSInputStream可以方便的管理datanode和namenode数据流。客户端调用read方法，DFSInputStream就会找出离客户端最近的datanode并连接datanode。
数据从datanode源源不断的流向客户端。
如果第一个block块的数据读完了，就会关闭指向第一个block块的datanode连接，接着读取下一个block块。这些操作对客户端来说是透明的，从客户端的角度来看只是读一个持续不断的流。
如果第一批block都读完了，DFSInputStream就会去namenode拿下一批blocks的location，然后继续读，如果所有的block块都读完，这时就会关闭掉所有的流。

HDFS 如何写入文件：

HDFS的文件写入原理，主要包括以下几个步骤：

客户端通过调用 DistributedFileSystem 的create方法，创建一个新的文件。
DistributedFileSystem 通过 RPC（远程过程调用）调用 NameNode，去创建一个没有blocks关联的新文件。创建前，NameNode 会做各种校验，比如文件是否存在，客户端有无权限去创建等。如果校验通过，NameNode 就会记录下新文件，否则就会抛出IO异常。
前两步结束后会返回 FSDataOutputStream 的对象，和读文件的时候相似，FSDataOutputStream 被封装成 DFSOutputStream，DFSOutputStream 可以协调 NameNode和 DataNode。客户端开始写数据到DFSOutputStream,DFSOutputStream会把数据切成一个个小packet，然后排成队列 data queue。
DataStreamer 会去处理接受 data queue，它先问询 NameNode 这个新的 block 最适合存储的在哪几个DataNode里，比如重复数是3，那么就找到3个最适合的 DataNode，把它们排成一个 pipeline。DataStreamer 把 packet 按队列输出到管道的第一个 DataNode 中，第一个 DataNode又把 packet 输出到第二个 DataNode 中，以此类推。
DFSOutputStream 还有一个队列叫 ack queue，也是由 packet 组成，等待DataNode的收到响应，当pipeline中的所有DataNode都表示已经收到的时候，这时akc queue才会把对应的packet包移除掉。
客户端完成写数据后，调用close方法关闭写入流。
DataStreamer 把剩余的包都刷到 pipeline 里，然后等待 ack 信息，收到最后一个 ack 后，通知 DataNode 把文件标示为已完成。

HDFS 副本存放策略

namenode如何选择在哪个datanode 存储副本（replication）？

这里需要对可靠性、写入带宽和读取带宽进行权衡。Hadoop对datanode存储副本有自己的副本策略，在其发展过程中一共有两个版本的副本策略，分别如下所示

NameNode HA

　　　　解决方案：

基于NFS共享存储解决方案
基于Qurom Journal Manager(QJM)解决方案

　　　　1、基于NFS方案

　　　　　　Active NN与Standby NN通过NFS实现共享数据，但如果Active NN与NFS之间或Standby NN与NFS之间，其中一处有网络故障的话，那就会造成数据同步问题

　　　　2、基于QJM方案

　　架构如下图

　Active NN、Standby NN有主备之分，NN Active是主的，NN Standby备用的

　　集群启动之后，一个namenode是active状态，来处理client与datanode之间的请求，并把相应的日志文件写到本地中或JN中；

　　Active NN与Standby NN之间是通过一组JN共享数据（JN一般为奇数个，ZK一般也为奇数个），Active NN会把日志文件、镜像文件写到JN中去，只要JN中有一半写成功，那就表明Active NN向JN中写成功啦，Standby NN就开始从JN中读取数据，来实现与Active NN数据同步，这种方式支持容错，因为Standby NN在启动的时候，会加载镜像文件（fsimage）并周期性的从JN中获取日志文件来保持与Active NN同步

　　为了实现Standby NN在Active NN挂掉之后，能迅速的再提供服务，需要DN不仅需要向Active NN汇报，同时还要向Standby NN汇报，这样就使得Standby NN能保存数据块在DN上的位置信息，因为在NameNode在启动过程中最费时工作，就是处理所有DN上的数据块的信息

　　为了实现Active NN高热备，增加了FailoverController和ZK，FailoverController通过Heartbeat的方式与ZK通信，通过ZK来选举，一旦Active NN挂掉，就选取另一个FailoverController作为active状态，然后FailoverController通过rpc，让standby NN转变为Active NN

　　FailoverController一方面监控NN的状态信息，一方面还向ZK定时发送心跳，使自己被选举。当自己被选为主（Active）的时候，就会通过rpc使相应NN转变Active状态

结合HDFS2的新特性，在实际生成环境中部署图

图有12个DN,有4个NN，NN-1与NN-2是主备关系，它们管理/share目录；

NN-3与NN-4是主备关系，它们管理/user目录。