专栏目录
(1)大数据和应用场景介绍
(2)大数据技术综述总结
(3)HDFS原理与高可用技术原理介绍
(4)Yarn架构、资源管理原理和运维技术介绍
(5)Kafka原理和高可用介绍
1.HDFS简介
HDFS也是由Doug Cutting基于Google公司03年10月开源的论文GFS做的开源实现。目前为止，HDFS的运用非常广泛，基本上很多大数据平台大部分都会选用HDFS（或者类似HDFS）这样的分布式文件系统、来作为海量数据存储的一个解决方案。最初在设计HDFS时的背景是 当时设备的存储和读写性能都很差，并且单一设备运行稳定性低的情况 （现在硬件设备优化很好了，目前HDFS已经不是最优方案了），于是 HDFS在设计之初就是为了解决大规模、海量数据的存储以及读写，并且尽可能的保证设备的稳定性。
【HDFS的优势】
1. 高容错性，HDFS提供了“副本冗余机制”，简单来说就是 一份数据在HDFS当中存放，包含它自身在内至少会有（默认）三个副本类似随机的存放在集群不同的服务器上，并且当其中一台服务器宕机、当前这台服务器上数据丢失，但 HDFS会自动再将缺失的副本再通过copy的方式、保证数据的副本不会低于默认三个（副本默认是3个）。
2. 可构建在廉价的商业服务器上，基于第一条高容错性的优势，HDFS可以搭建在低成本的廉价服务器上，而没有必要选择非常昂贵的服务器上，因为即使廉价服务器稳定性相对较差， 但是集群规模成百上千台宕机一台、两台对于整个HDFS集群来说，基本上没有任何的影响。
3. 适合海量数据存储，分布式架构设计、HDFS可支持几万台服务器的集群规模，乘以每台服务器磁盘容量、整个HDFS文件系统容量非常之大，并且他所支持存放的单个数据文件GB、TB、PB级别都没有任何问题。
4. 适合批处理，通过 “移动计算而非移动数据”设计，简单来说就是数据在哪个节点，你就呆在哪计算就行了。 避免了数据跨网络、结点移动拷贝的工作，很大限度的提升计算速度。
5. 流式数据访问，一次写入、多次读取。文件一旦写入完成、不能修改， 仅仅只支持追加。保证了数据的一致性。
【HDFS的适用场景】
1.集群规模大：适合大文件存储、海量数据存储。
2.集稳容量大：适合批量数据访问 HDFS适用于“大文件存储、海量数据存储”、“批量数据访问”这些场景
【HDFS的缺点】
但是HDFS本身设计上也存在问题：
1. 低延时数据访问 ：这里的 “低延时”指的是例如毫秒级别要将数据写入HDFS、或毫秒级别读取HDFS内数据 ，无法支持。也就是说它某一时间大量读写不要紧，集群容量够稳定，但你要它毫秒级别完成那肯定不现实，至少任务调度、任务结果收集都要耗一点时间。
2. 并发写入、随机修改 ：①HDFS当中 文件只能有一个写、不支持多个线程同时写入一个文件 。②并且 只支持追加写，不支持随机写。
3. 小文件存储 ：小文件问题是大家在大数据领域需要格外注意的问题。首先撇开HDFS来说，假如10GB数据容量，10个1GB的数据集、1w个1M的数据集，占用存储空间相同，让你在这两种数据集中找到其中一个数据文件，明显第二种场景非常耗时，也 就是说小文件存储之后，在寻址的时间开销会非常之高、以至于会高于读取时间 。此外，回到HDFS当中来考虑， HDFS当中每一个数据文件都会对应有一份元数据信息需要存放 ，大家可以把元数据信息先简单理解为就是文件的一些基本信息（如文件名称、大小、权限等），一个文件对应一条元数据信息，当你存储的都是一些小文件、文件个数会急速增长，对应元数据也就需要更多的空间来存储，并且元数据是在内存介质中存储，这样一来会非常浪费内存资源、显然是不适用的。所以，在使用HDFS过程当中一定要注意“小文件”的这个问题。
2.HDFS架构Master/Slave
(1)基本结构关系
- NameNode是主节点，DataNode是从节点，HDFS Client是客户端、HDFS提供了比较丰富的客户端像cli、api、gui等等支持SecondaryNameNode相当于辅助NameNode工作的一个节点、但并不是NameNode的备份结点！。
- NameNode主节点：主要负责接受客户端提交过来的读写请求、以及一些类似管理的工作。比如说，数据存到HDFS当中每个文件都会对应一份元数据信息(见后介绍)，这些元数据信息都是存放在NameNode的内存区域内、由NameNode来进行维护。
- DataNode从节点：主要负责数据的存放。数据文件写入到HDFS当中会切分为小的数据块block（图中DataNode中紫色、橙色、红色等小的方块），这些数据块会存放在DataNode节点上。在一个HDFS集群当中DataNode结点可以有任意多台，当然要根据你文件系统的数据量来确定，并且后期如果容量不足的情况下，也支持DataNode结点动态添加、扩容。
- 通信：DataNode运行中一直和NameNode保持通信。一方面，在DataNode启动时，会给NameNode上报有哪些数据块（block的位置存放信息），NameNode接收到这些block位置信息会维护好一份完整的元数据信息，从而找到具体数据存放在哪些DataNode上；另一方面，运行过程中，DataNode会每隔3秒定时和NameNode做一次心跳，从而NameNode知道DataNode的运行状况。
(2)Block规则
一个10G的文件上传到HDFS中：
- 首先，在客户端处切分成一个个Block块，默认情况下Block块的大小是128M。
- 这些切分后的Block块，会以多副本的形式均匀放置到DataNode中。
- 数据存放在DataNode后，主节点NameNode需要知道文件切分了多少Block块和每个Block块具体存放的位置。这些记录信息就是元数据。
(3)NameNode和DataNode功能介绍
(4)活跃主节点和备份节点介绍(Hadoop3.X)
- ActiveNameNode是主节点。具体功能是管理整个集群，是当前活动的管理节点。作为管理节点，管理命名空间和元数据信息，管理Block副本策略。并处理客户端读写请求，为DataNode分配任务。
- Standby Namenode是Master的热备节点，并负责定期合并元数据文件。
(5)Block和client客户端关系
3.HDFS存储机制
(1)Block、元数据、副本关系
①Block是HDFS的最小存储单元，默认大小为128M（128M，据说是希望IO时间/(IO+网络传输)=1%效果最好），可以自定义修改，但是要注意修改的一些影响，块太大和太小都可能会影响性能。
②Block存储到DataNode上，会以多副本的形式进行存储，默认副本数为3，通过机架感知和副本均匀分布的策略保证数据的高可用性。数据存储之后，对应的元数据会保存在NameNode中。
(2)Block文件解析
(3)副本存放策略详解
没有“主备”关系
②block前3个副本放置遵循规律，后N个随机
(4)元信息存储和持久化策略
①元信息由于存放在NameNode内存中，如果小文件过多容易造成内存容量不足，进而宕机
②元信息持久化包含两种文件：fsimage和edits。 fsimage文件可以理解为是一个内存的快照，他会将内存当中除去block位置存放信息之外的所有元数据信息持久化写到一个磁盘当中的文件内； edits文件，这种文件可理解为Mysql的binlog日志记录文件。
【元信息持久化不丢失数据】
由于每次更新fsimage文件性能不高(一个树结构要遍历和结构变化)，因此fsimage并不会实时去发生变化，那么后边这些操作则通过edits文件做一个记录。因此及时NameNode宕机了，也能通过edits恢复fsimage最新结构。
(5)元信息存储文件详解
与DataNode Block文件不同，在NameNode中结构为：
- fsimage_前缀文件：即fsimage文件，之所以有多个是因为他定时要做合并，所以会保留有多份fsimage文件
- edits_前缀文件：即edits文件。
- VERSION：VERSION文件是java属性文件，保存了HDFS的基本信息
- seen_txid：是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数，namenode重启的时候，会按照seen_txid的数字，循序从头跑edits_0000001~到seen_txid的数字。
(6)edits与fsimage合并
①Hadoop1.x：
客户端各项操作记录会写入到edits文件内。
Secondary合并触发：Secondary会主动从NameNode中通过HttpGet方式将edits和fsimage文件拷贝并存放在本地磁盘中，开始合并。合并过程其实就是将该fsimage加载到内存当中，然后逐条执行edits日志中的各项操作、来更新内存里的元数据信息。合并完后，fsimage被持久化(快照生成)产生新的fsimage，此时内存中的元数据信息便是触发合并那个时间点一份完整的元数据信息。
Secondary转移：新的fsimge通过Http Post方式将这个新的fsimage文件发送给NameNode，旧版fsimage被替换。之前合并期间，NameNode同时还生成一个空的edits文件，Secondary在合并的过程中，所有客户端的操作都会记录在这个新的空edits文件中，直到Secondary把新的fsimage文件推给NameNode，NameNode会同时将新的fsimage、以及新的edits文件启用整个合并过程完成结束。
因此，在运行过程中HDFS会定期触发整个合并流程，从而会保证fsimage文件越来越大、但edits文件大小稳定。
②Hadoop2.x：
(不保证日志能写到Secondary)
4.读写过程
5.HDFS安全模式
(1)安全模式本质和安全模式退出介绍
(2)安全模式触发原因和两种故障排查方式
6.HDFS高可用探讨
(1)HDFS本身架构讨论
①HDFS结构劣势主要在于NameNode内存受限：可以用联邦机制解决（多个节点分享元文件，或者每个NameNode管理自己领域的DataNode，并且多个NameNode还由上一层节点进行控制做负载均衡）
②NameNode单点容易故障：可用HA解决 (见下主备节点ActiveNN和StandbyNN)
(2)高可用有哪些可以思考地方
(3)高可用技术参考
① 高可用的本质是在主节点宕机之后，从热备节点可以立马代替宕机的主节点接管集群，保证服务是不中断的。那对于NameNode来说，如果要立马接管集群并且保证服务不中断，那就需要元数据保持一致。
②下图中QJM方案介绍：
- Journal集群可以实现edits共享，实现Master主备节点的元数据同步。
- Journal集群需要部署奇数台，每次edits文件的写入都需要半数以上的节点返回成功才代表成功。保证edits元数据文件的高可用。
(4)高可用整套技术架构
- JournalNode集群：负责管理NameNode日志edits文件的管理，也就是ActiveNameNode写日志是直接写入到JournalNode集群上。
- ZKFC – ZookeeperFailoverController：每台NameNode服务器上都会运行一个ZKFC进程，主要负责两个任务： 监控当前NameNode运行状况信息、与Zookeeper集群保持心跳并将这些信息汇报给Zookeeper集群；控制NameNode Active、Standby状态的切换管理 (参考一致性算法Paxos算法 )。
- Zookeeper集群：实际中也是部署 2N+1台，核心也是通过Paxos算法，在HDFS集群中主要负责接收到ZKFC汇报的NameNode健康信息做“选举”，“选举”哪一台NameNode应该是Active状态。
- DataNode集群：负责数据的存储，但是区别于1.x的设计、 在2.x集群中DataNode上报block信息会同时上报给两台NameNode。
运行过程：
①HDFS运行过程中，如果Active的NameNode运行出现故障，此时当前NameNode上的ZKFC会将异常的健康信息汇报给Zookeeper集群，或者NameNode这台服务器宕机，Zookeeper集群长时间接收不到ZKFC的数据，都会得知第一台NameNode运行出现了问题。
②主备替换：此时Zookeeper集群会做选举、推选第二台NameNode作为Active的NameNode来接管集群，之后Zookeeper先通知给第二台NameNode上的ZKFC，由ZKFC将当前这台NameNode状态从Standby切换为Active。
③元信息恢复：fsimage文件在第二台NameNode上有一份，运行过程中edits文件一直写在JournalNode集群上、第二台NameNode可以直接拿到这些edits文件，状态切换之后，便可以先将fsimage加载内存，然后一条一条执行edits日志内容，并且集群在运行过程中DataNode会将各自服务器上block信息汇报给第一台和第二台，第二台上缓存有这些block信息再将它和内存当中部分原数据信息进行拼接。当这些操作全部执行完成之后，此时第二台NameNode内存当中元数据信息和第一台NameNode出现故障时内存当中元数据信息完全一致，这样整个HA便达到了。
