这是我参与「第四届青训营」笔记创作活动的第1天
元数据高扩展性
元数据扩展性挑战
HDFS NN 是集中式服务，部署在单个机器上，单机的处理能力不能无限扩展，所以需要元数据扩展
挑战：
- 名字空间分裂
- DN 汇报
- 目录树结构本身复杂
- Scale up：扩容单个服务器的能力
- Scale out：部署多个服务器来服务
常见的 Scale Out 方案
KV 模型的系统可以使用 Partition（按照 KEY 的值不同，让不同的节点处理）
- Redis
- Kafka
- MySQL
图上的三种数据路由方式
- 服务端侧（分区信息在服务器侧）
- 路由层（分区信息在路由层）
- 客户端层（分区信息在客户端）
社区的解决方案
BlockPoll 方案
解决 DN 服务多组 NN 的问题
- 同一 block id 在不同的 NN 上出现（生成了相同的），DN 就不知道到底要访问哪个数据
文件服务分层
- Namespace
- Block Storage
用 blockpoll 区分 DN 的服务（给每个 NN 一个唯一的 ID）（把 Block id 变为 NN ID+Block id）
- 数据块存储
- 心跳和块上报
viewfs 方案
Federation（联邦）架构：将多个不同集群组合，对外表现为一个集群
viewfs 通过在 client-side 的配置，指定不同的目录访问不同的 NN
局限性：运维复杂
- viewfs 挂在路径必须在同一层，不能嵌套
- 信息保存在 client 端，viewfs 无法控制，要客户自行更新
字节跳动的 NNProxy 方案
主要实现了路由管理和 RPC 转发，以及鉴权、限流、查询缓存等额外功能
路由规则保存
路由信息无论保存在服务端还是客户端都很困难，所以引入了 proxy
路由层实际不保存信息，信息都存在 ZooKeeper 这样的强一致高可用的节点上
路由转发实现
使用最长匹配规则，进一步划分目录树，解决了 viewfs 无法嵌套的问题
案例：小文件问题
大小不到一个 HDFS block 大小的文件过多
- NameNode 瓶颈
- I/O 变成小的随机 I/O，数据访问变慢
- 计算任务启动慢
MapReduce 的 worker 数量过多容易引起小文件问题
解决方案：
- 后台任务合并小文件
- Shuffle Service（等于提前做了小文件的合并）
