一、HDFS架构介绍
HDFS 全名 Hadoop Distributed File System，是Apache Hadoop的子项目，也是业界使用最广泛的开源分布式文件系统。
核心思想是：将文件按照固定大小进行分片存储，具备：强一致性、高容错性、高吞吐性等
架构层面是典型的主从结构：
- 主节点：称为NameNode，主要存放诸如目录树、文件分片信息、分片存放位置等元数据信息
- 从节点：称为DataNode，主要用来存分片数据
HDFS官网架构
二、快手HDFS数据规模和集群规模介绍
快手HDFS 历经 3 年的飞速发展，承载了整个快手几乎全量的数据存储，直接或间接的支持了上百种业务的发展。从最初的千台规模，目前已经发展成拥有几万台服务器、几EB数据的超大规模存储系统。
1. 业务类型
在整个数据平台中，HDFS 系统是一个非常底层也是非常重要的存储系统，除了常用的Hadoop生态开源组件之外，还承载诸如kafka、clickhouse等在线核心组件数据。
2. 集群规模
作为数据平台中最底层的存储系统，目前也是整个快手中机器规模和数据规模最大的分布式存储系统，单个HDFS集群拥有：
- 几万台服务器
- 几EB数据规模、几百PB的EC数据量
- 每天拥有几百PB的数据吞吐
- 几十组NameService
- 几百亿元数据信息
- 百万级Qps
三、快手HDFS挑战与实践
在数据爆炸式增长的过程中，HDFS 系统遇见的挑战是非常大的。接下来，主要从HDFS架构四个比较核心的问题入手，重点介绍下快手的落地过程。
- 主节点扩展性问题
- 单NS性能瓶颈问题
- 节点问题
- 分级保障问题
1. 主节点扩展性问题
众所周知，主节点扩展性问题是一个非常棘手，也是非常难解决的问题。当主节点压力过大时，没办法通过扩容的手段来快速分担主节点压力。
随着集群规模越来越大，问题也越来越严重。我们认为要解决这个问题，至少需要具备两个能力：
- 具备快速新增NameService的能力
- 具备新增NS能快速分担现存NS压力的能力
无论社区2.0的Federation架构，还是社区最新3.0的Router Based Federation架构，都不能很好的满足这两个条件。综合讨论了多个方案之后，我们决定在社区最新3.0的RBF架构基础上，进行深度定制开发，来解决主节点扩展性问题。
首先，我们介绍两个业务场景的扩展性方案：
1）快手 FixedOrder && RbfBalancer机制
我们支持的第一个扩展性机制：FixedOrder机制
- 将一个路径挂载到多个NS上，记为FixedOrderMountPoint
- FixedOrderMountPoint下所有新建目录或文件都写到期望的NS（比如新增NS）
- FixedOrderMountPoint下目录或文件的访问，通过探测的方式，可以有效的访问到新老数据（增加FixedOrderMountPoint前后的文件或目录）
利用这个机制，可以通过快速新增NS，来有效缓解热点NS Qps压力过大的问题。
除此之外，我们还研发了RbfBalancer机制，通过FastCp的方式，在业务完全透明的场景下将存量数据异步搬迁到新的NS里，达到缓解老NS内存压力的效果。由于老NS Qps压力已经被快速分担，所以异步数据迁移的进度，没有强要求。
利用FixedOrder RBFBalancer机制，通过扩容新NS并快速分担老NS的压力，来解决大多数场景的扩展性问题。
2）快手 DFBH 机制
众所周知，分布式开源组件中存在大量Staing路径，比如：Yarn Staing路径、Spark Staing路径、Hive scratchdir路径、Kafka Partition路径等，这一类路径有两个特点：
- Qps非常大，需要多个NS承担
- 具有短暂的生命周期
针对这一类路径 ，我们引入了DFBH机制，来解决主节点扩展性问题：
- 通过一致性Hash实现多NS间Qps负载均衡
- 利用动态FixedOrder机制，在不搬迁数据的场景下，实现透明扩缩容NS
实现的核心思想是：
- 每个路径依据多组一致性Hash列表计算出归属NS，组合成FixedOrder
- 将增量数据写到期望NS 中 ，存量数据依旧可见
- 随着生命周期推移，逐步回退到最普通的一致性Hash策略
社区贡献：
除了完善多个扩展性方案之外，我们还解决了大量RBF正确性、性能、资源隔离等稳定性问题，同时也积极为社区提供大量BugFix，有兴趣的同学可以参考下：
https://issues.apache.org/jira/browse/HDFS-15300
https://issues.apache.org/jira/browse/HDFS-15238
https://issues.apache.org/jira/browse/HDFS-14543
https://issues.apache.org/jira/browse/HDFS-14685
https://issues.apache.org/jira/browse/HDFS-14583
https://issues.apache.org/jira/browse/HDFS-14812
https://issues.apache.org/jira/browse/HDFS-14721
https://issues.apache.org/jira/browse/HDFS-14710
https://issues.apache.org/jira/browse/HDFS-14728
https://issues.apache.org/jira/browse/HDFS-14722
https://issues.apache.org/jira/browse/HDFS-14747
https://issues.apache.org/jira/browse/HDFS-14741
https://issues.apache.org/jira/browse/HDFS-14565
https://issues.apache.org/jira/browse/HDFS-14661
2. 单NS性能瓶颈问题
众所周知，HDFS 架构中NameNode 的实现中有一把全局锁，很容易就达到处理瓶颈。社区最新3.0提出了一个Observer Read架构，通过读写分离的架构，尝试提升单个NameService的处理能力，但是最新的架构问题比较多。
针对单NS性能瓶颈这个问题，我们尝试从两个阶段解决：
- 快手特色ObserverRead架构，从读写分离角度提升NS处理能力【重点介绍】
- 优化NameNode全局锁，从提升单NN处理能力角度提升NS处理能力【进行中】
快手特色ObserverRead架构：
快手特色ObserverRead架构是基于最新的RBF框架落地的，在客户端完全透明的场景下，实现动态负载路由读请求的功能，提升整个NS处理能力。
相比社区的ObserverRead架构，快手特色ObserverRead架构有几个非常明显的优势：
- 整个架构，基于RBF框架实现，客户端完全透明
- Router检测NN节点状态，实现动态负载路由读请求
- Standby、Active节点可以支持读请求
- Observer节点支持快速扩容
在整个最新架构落地过程中，也解决了社区ObserverRead架构大量稳定性问题，比如：
- MSync RPC稳定性问题
- Observer Reader卡锁问题
- NameNode Bootstrap失败问题
- Client Interrupt导致无效重试问题（HDFS-13609）
3. 慢节点问题
随着集群规模越来越大，慢节点问题也越来越明显，经常导致作业出现长尾Task、训练“卡住”等问题。
慢节点问题主要体现在从节点DataNode上，主要是因为物理指标负载比较大，比如：网卡流量、磁盘Util、Tcp 异常等。
针对这个问题，我们从两个大的方向着手解决：
- 慢节点规避
- 慢节点根因优化
1）慢节点规避
主要从事先规避和事中熔断两个角度来实现HDFS层面的慢节点规避机制。
事先规避，即客户端在读写数据前，NameNode依据DN的负载信息进行排序，优先返回低负载的DN。
其判断依据主要有：负载指标（CPU使用率、磁盘Util、网卡流量、读写吞吐量）；客户端上报慢节点。
事中熔断，即客户端在读写数据过程中，通过吞吐阈值实时感知慢节点，进行实时慢节点摘除功能。
通过事先规避和事中熔断机制，能有效地解决长尾Task、训练“卡住”等问题。
2）慢节点根因优化
从资源利用率最大化的角度出发，从节点DataNode机器是和Yarn NodeManager混布的。
通过硬件指标采集发现：Yarn MapReduce的shuffle功能对硬件繁忙程度贡献度非常大，所以我们从Yarn Shuffle优化和DN内部机制优化两个角度尝试从根因入手解决慢节点问题。
这里，我主要介绍下DN内部优化逻辑，主要包括：
- 在线目录层级降维
即DN在不停读写的场景下，实现block存储目录的降维工作，极大地缩减磁盘元数据信息。
- DataSet全局锁优化
将DN内部全局锁细粒度化，拆分成BlockPool Volume 层级，降低BlockPool之间、磁盘之间的相互影响。
- Du操作优化
将定期的DU操作，通过内存结构计算单磁盘BP使用量。
- 选盘策略优化
添加负载选盘策略，优先选择负载比较低的磁盘。
4. 分级保障问题
众所周知，快手经常有一些大型活动，比如春节活动、电商活动、拉新活动等，而且整个活动过程中还伴随着无数个例行任务。
瞬间的洪峰流量，可能会导致HDFS系统满载，甚至过载。
为了在HDFS 系统满载的场景下尽可能的保障高优先级任务正常运行，所以我们将所有任务抽象成高优先级、中优先级和低优先级任务，同时HDFS系统支持分级保障功能，来满足这个需求。
我们主要从NameNode和DataNode两个角色入手，支持分级保障功能。
1）NameNode分级保障功能
我们深度定制了NameNode Rpc框架，将队列拆分成优先级队列，Handler依据资源配比依次处理不同优先级队列请求。与此同时，通过压力感知模块，实时感知各个优先级请求的压力，并动态调整资源配比，从而实现：
- 未满载时，按照资源配配比处理请求
- 满载时，资源倾向高优，优先处理高优请求
2）DataNode分级保障功能
由于DataNode内部是通过独占线程方式与客户端进行数据IO的，所以我们在每个磁盘上添加了磁盘限速器。
当磁盘资源达到上限后，高优先级请求到来时，会强占低优先级资源。除此之外，我们还添加了阈值调整模块，实时感知相关指标，动态调整磁盘限速器阈值，来控制单盘压力。
5. 快手HDFS架构图
最后，我们介绍下目前快手HDFS 系统的最新架构。
整个架构整体分为三层，分别是：路由层、元信息层和数据层。
1）路由层
由一组无状态的Router服务组成，Router间通过ZK来共享挂载点信息等，主要用于转发客户端的元信息请求。
2）元信息层
由多组相互独立的NameService组成，每组NameService内主要有一台Active NameNode服务、一台Standby NameNode服务、N台Observer NameNode服务组成。
其中：
- Active和Standby通过ZKFC实现动态HA切换的功能
- Active主要承担写请求压力
- Standby除了承担定期Checkpoint功能外，还支持部分读请求
- Observer主要分担读请求压力
3）数据层
由一组无状态的从节点(DataNode)组成，主要用来存在数据；通过心跳、块汇报等Rpc与主节点保持最新状态。
四、结尾
快手HDFS 经历了3年的发展，从最初的几百台节点支持PB级数据量的小规模集群，到现在的拥有几万台节点支持EB级数据量的超大规模集群。我们团队用无数个黑夜，经历了数据爆炸式增长的过程，抗住了巨大压力，踩了无数的坑，同时也积累大量经验。
当然，快手依旧处于飞速发展过程中，我们团队依旧不忘初心，怀着敬畏之心，继续匠心前行。
,
