一、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级数据量的超大规模集群。我们团队用无数个黑夜,经历了数据爆炸式增长的过程,抗住了巨大压力,踩了无数的坑,同时也积累大量经验。


当然,快手依旧处于飞速发展过程中,我们团队依旧不忘初心,怀着敬畏之心,继续匠心前行。
温馨提示:
1、在论坛里发表的文章仅代表作者本人的观点,与本网站立场无关。
2、论坛的所有内容都不保证其准确性,有效性,时间性。阅读本站内容因误导等因素而造成的损失本站不承担连带责任。
3、当政府机关依照法定程序要求披露信息时,论坛均得免责。
4、若因线路及非本站所能控制范围的故障导致暂停服务期间造成的一切不便与损失,论坛不负任何责任。
5、注册会员通过任何手段和方法针对论坛进行破坏,我们有权对其行为作出处理。并保留进一步追究其责任的权利。
回复

使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    • 售后服务
    • 关注我们
    • 社区新手

    QQ|手机版|小黑屋|数据通

    Powered by datatong.net X3.4  © 2008-2020 数据通