这是我参与「第四届青训营 」笔记创作活动的第14天
9.3 元数据高扩展性
1.元数据扩展性挑战
1.1 元数据节点扩展性的挑战
HDFS NameNode是个集中式服务，部署在单个机器上，内存和磁盘的容量、CPU 的计算力都不能无限扩展。
scale up Vs. scale out
1）扩容单个服务器的能力
2）部署多个服务器来服务
挑战
1）名字空间分裂
2）DataNode汇报
3）目录树结构本身复杂
1.2 常见的Scale Out方案
KV模型的系统可以使用partition：Redis、Kafka、MySQL (分库分表)
下图:三种数据路由方式：服务端侧、路由层、客户端侧
思考:目录树怎么拆分比较合理?
2.社区的解决方案
2.1 社区解决方案-BlockPool
解决DN同时服务多组NN的问题
文件服务分层：、Namespace、Block Storage
用blockpool来区分DN的服务：数据块存储、心跳和块上报
2.2 社区解决方案-viewfs
Federation架构:将多个不同集群组合起来，对外表现像一个集群一样。
下图: viewfs 通过在client-side的配置，指定不同的目录访问不同的NameNode。
局限性:运维复杂
3.字节跳动的NNProxy方案
3.1 字节跳动的NNProxy
NNProxy是ByteDance自研的HDFS代理层，提供了路由服务。
于2016年开源，项目地址:github.com/bytedance/n…
开源社区的Router Based Federation在2017年上线。
NNProxy主要实现了路由管理和RPC转发以及鉴权、限流、查询缓存等额外能力 下图: NNProxy 所在系统上下游
3.2 NNProxy路由规则保存
回顾:三种数据路由方式：服务端侧、路由层、客户端侧
考虑点:扩展性、运维性
图:路由规则的保存
3.3 NNProxy路由转发实现
图:目录树视图
路径最长匹配规则：/、/home、/user/bob、/user/tiger/warehouse、/usertiger/dump
进一步思考:单个NN不会遇到瓶颈了么?、跨集群rename
4.案例：小文件问题
小文件问题(L SOF，lots of small files) :大小不到一个HDFS Block大小的文件过多
1）NameNode瓶颈
2）I/O变小，数据访问变慢
3）计算任务启动慢
右图: MapReduce 的worker数量过多容易弓|起小文件问题
解决方案:后台任务合并小文件、Shuffle Service
9.4 存储数据高扩展性
1.超大集群的长尾问题
1.1 延迟的分布和长尾延迟
延迟的分布:用百分数来表示访问的延迟的统计特征，例如p95延迟为1ms,代表95%的请求延迟要低于1ms,但后5%的请求延迟会大于1ms
长尾延迟:尾部(p99/p999/p999) 的延迟，衡量系统最差的请求的情况。会显著的要差于平均值
上图：延迟的长尾
下图：延迟的分布
1.2 尾部延迟放大
木桶原理：尾部延迟放大:访问的服务变多，尾部的请求就会越发的慢。
如何变慢：固定延迟阈值、固定延迟百分位
1.3 长尾问题的表现-慢节点
➢慢节点:读取速度过慢，导致客户端阳塞。
慢节点的发生难以避免和预测：
1）共享资源、后台维护活动、请求多级排队、功率限制
2）固定的损耗:机器损坏率
3）混沌现象
离线任务也会遇到长尾问题：
1）全部任务完成时间取决于最慢的任务什么时候完成。
2）集群规模变大，任务的数据量变大。
3）只要任何数据块的读取受到长尾影响，整个任务就会因此停滞。
集群扩大10倍，问题扩大N(>10)倍
2.超大集群的可靠性问题
2.1 超大集群下的数据可靠性
➢条件一:超大集群下，有一部分机器是损坏来不及修理的。
➢条件二:副本放置策略完全随机。
➢条件三: DN的容量足够大
推论:必然有部分数据全部副本在损坏的机器上，发生数据丢失。
估算:三副本，10000 台机器，每台-百万副本。
有多少种放置的组合数?
损坏100台机器，会有多少副本丢失?
叠加长尾问题，容易导致整个任务无法执行下去。
2.2 Copyset
将DataNode分为若干个Copyset选块在copyset内部选择
原理:减少了副本放置的组合数，从而降低副本丢失的概率。
思考:缺陷是什么?
3.超大集群的不均匀问题
3.1 超大集群的负载均衡和数据迁移
3.2 数据写入不均
数据的不均匀：、节点容量不均匀、数据新旧不均匀、访问类型不均匀、资源负载不均匀
图：DN的写入量不均匀
3.3 DN冷热不均
图：DN的访问不均匀
3.4 负载均衡和数据迁移的典型场景
4.数据迁移工具速览
4.1 数据迁移工具-跨NN迁移
➢DistCopy
基于MapReduce,通过一个个任务， 将数据从一个NameNode拷贝到另一个NameNode.
需要拷贝数据，流量较大，速度较慢。
➢FastCopy
开源社区的无需拷贝数据的快速元数据迁移方案
前提条件:新旧集群的DN列表吻合
对于元数据，直接复制目录树的结构和块信息。
对于数据块，直接要求DataNode从源BlockPool hardlink到目标BlookPool,没有数据拷贝。
hardlink: 直接让两个路径指向同一块数据。
4.2 数据迁移工具-Balancer
工具向DataNode发起迁移命令，平衡各个DataNode的容量。
场景：单机房使用、多机房使用、限流措施
评价标准：稳定性成本、可运维性、执行效率
结语
HDFS作为大数据离线分析场景的核心组件，高可用和高扩展性是架构设计的重中之重。 高可用确保了业务能稳定运行，HDFS 上存储的数据随时可以访问。 高扩展性确保了HDFS能存储的数据量能随着资源投入无限扩展下去，业务发展不被基础组件拖累。 字节跳动HDFS依然在持续迭代，在元数据扩展性、数据治理与调度、数据生态体系、单机存储引擎、云上存储等方向依然大有可为。
