More Related Content
What's hot (8)
Viewers also liked (18)
Similar to 贬顿贵厂元数据的独立服务和 独立持久化存储 -hadoop2011-淘宝 (20)
贬顿贵厂元数据的独立服务和 独立持久化存储 -hadoop2011-淘宝
- 1. 贬顿贵厂元数据的独立服务和 独立持久化存储 2009-8-22 罗李 Email: luoli523@gmail.com Twitter: luoli523
- 2. 主要内容 起因 现状 我们的想法 我们的实现 后续的发展
- 3. 起因 ? 数据的急剧膨胀 ? 文件数的不断增多 ? Block随之成倍的增长 ? 内存的急剧上涨 ? 内存数据结构 ? 一致性保证造成的性能瓶颈 ? Meta服务依靠namenode的启停 ? 部分meta数据没有持久化(block->dn)
- 4. 现状 ? 集群 – 单个集群1900台机器 1T×12（2T×6） ? 数据量 – 22.28 PB/36.98 PB 60% ? 文件数 – 1亿左右 ? Block数 – 1.3亿左右 ? Meta存储 – 只持久化了namespace的信息到fsimage
- 5. 现状 ? 内存 – 60G / 80G ～75% ? 数据结构 – BlockMap靠内存中ref来维护block->dn的信息 ? 响应 ? 删除文件个数1100万，每天的删除操作为240万 ? 创建文件操作900万～1200万 ? 重命名文件数量为1050万 ? 通过文件名获取block及其位置的操作getBlockLocations有近3亿 ? 类似“ls”的操作有700万
- 6. 新的架构 (Innodb on FusionIO) BlockChecker (Innodb on FusionIO) State Manager State Manager Datanode Block File Zookeeper Zookeeper Stateless Namenode Stateless Namenode … Stateless Namenode Datanode Datanode Datanode … Datanode
- 7. Namenode的改进 ? 无状态NN: 针对HDFS中Namenode单点瓶颈的问题，TBFS通过无状态方式 实现Namenode的水平扩展。为了实现无状态Namenode，需要将以前保留 在Namenode内存中的关键数据结构部分或全部挪到第三方，并持久化保存。 数据结构名称 描述 dir 保存HDFS目录结构的数据结构FSDirectory（文件->块的对应关系） blocksMap 保存块与文件、块与datanode和datanode与块的对应关系 datanodemap 保存datanode的storageID和对应DatanodeDescriptor的Map容器 heartbeats 保存拥有心跳的Datanode的DatanodeDescriptor的容器 corruptReplicas 保存损坏块的Map容器，key为Block，value为对应Datanode的DatanodeDescriptor集合 recentInvalidateSets 保存即将删除的块的Map容器，key为Datanode的StorageID，value是块的Block集合 excessReplicateMap 保存多余块的Map容器，key为Datanode的storageID，value是块的Block集合 保存少于replication数的块的数据结构，其内部维护了一个List<TreeSet<Block>> neededReplications 类型的优先级队列 pendingReplications 保存处于replication pending状态的block，如果超时则放入TimeoutItems列表中 leaseManager 维护写操作和追加操作租约的数据结构 7
- 8. 狈补尘别苍辞诲别的改进（续1） 将BlocksMap和FSDirectory在数 dir 据库中实现持久化保存 blocksMap (Innodb on FusionIO) (Innodb on FusionIO) State Manager State Manager Datanode Block File heartbeats datanodeMap datanodeMap和heartbeats的数据从数据 ? 基于树状结构来描述Map和Set，比 Stateless 库中读取，Namenode中只是缓存 较直观，操作方便 Stateless ? 提供了ephemeral和sequence Namenode Stateless znode的机制，方便做成员管理和提 Namenode 供分布式锁服务 Namenode ZooKeeper ? 提供了Watcher机制，提供对数据变 / 化的通知 LeaseManger … namenode datanode blockchecker Zookeeper pendin lease under excess corrupt invalidate group 为LeaseManager保 g 存全局lease信息 维护under 维护excess 维护 维护TBFS 维护replication 维护corrupt replication replication invalidate 集群中 pending相关的 块相关的持 相关的持久 相关的持久 块相关的持 namenode 8 持久化数据 久化数据 化数据 化数据 久化数据 成员信息
- 9. Namenode的改进（续2） ? Namenode与非心跳Datanode进行通信。Datanode实现了 ExternalNamenodeProtocol协议，Namenode可以通过该协议与非心跳 Datanode进行通信，即Namenode主动调用该协议提供的方法。 Namenode 2是Datanode A的External Namenode Namenode 1 Datanode A Datanode offerSerivce Protocol sendHeartbeat ExternalNamenode Protocol ExternalDatanode CommandsHandle r Datanode B Namenode 2 Datanode offerSerivce Protocol sendHeartbeat ExternalNamenode ExternalDatanode 与原有方式一致，External Protocol CommandsHandle Namenode向External r Datanode发送三种命令： replication命令，invalidate 命令和recover命令 9
- 10. BlockChecker的引入 ? BlockChecker解决Namenode无法判断出的数据不一致的情况，主要是检测 Block副本数是否满足期望，类似于社区版中离开安全模式(SafeMode.leave)时 processMisReplicatedBlocks机制。为了不影响Namenode的核心逻辑，它只和 数据库和Zookeeper交互。 ? 运行方式：1. 每隔一段时间运行一次；2. 手动执行；3. Namenode下线时执行 ? 典型场景： – 某个block的副本数小于期望值，在数据库中增加一条伪记录，触发Namenode进行检查 – 某个block的副本数大于期望值，综合zookeeper中的记录，决定是否删除一条记录，触发 Namenode进行检查 (Innodb on FusionIO) BlockChecker (Innodb on FusionIO) State Manager State Manager Datanode Block File Zookeeper Zookeeper 10
- 11. Datanode的改进 ? 提供Namenode的连接/重连机制，从而提高整个系统的可用性。在以下几种 场景下，Datanode会连接/切换目标Namenode： 1. Datanode启动时；2. 当 前Namenode失效（异常）并超过一定时限和重试次数；3. 管理员调用切换 命令。同一时刻一个Datanode只汇报给一个Namenode。 ? Namenode选择策略实现： AbsNameNodeSelector作为选择Namenode策略 的接口，ConfNameNodeSelector实现了该接口。 <<AbsNameNodeSelector>> DataNode Private AbsNameNodeSelector + selectNextNameNodeAddress() namenodeSelector; 调用 + refreshNameNodeList() 实现 selectNextNameNodeAddress : 从Name Node列表中随机选 ConfNameNodeSelector 取一个Name Node返回给调用者，并记录下来。注意，每次调 用时会将上次使用的Name Node从列表中删除，这样就避免再 + selectNextNameNodeAddress() 次选择失效的Name Node + refreshNameNodeList() refreshNameNodeList: 按照策略更新Name Node列表 11
- 12. Datanode的改进（续1） ? 目前已实现的Namenode选择策略ConfNameNodeSelector需要在配置文件中做如下配 置： <property> <name>dfs.namenode.selector</name> ConfNameNodeSelector的 <value>org.apache.hadoop.hdfs.server.common.ConfNameNodeSelector</value> 类路径 <description>The policy of looking for and selecting name node</description> </property> <property> <name>dfs.namenode.selector.timeout</name> 一个Namenode失效后重连 <value>180000</value> 的超时时间 <description>The timeout value for retrying connection to a namenode</description> </property> <property> <name>dfs.namenode.rpcaddr.list</name> Namenode的列表 <value>hdfs://dw30.kgb.sqa.cm4:51199,hdfs://dw39.kgb.sqa.cm4:51199</value> <description>The list of name nodes' RPC addr list, separated with comma</description> </property> ? Datanode在线辅助判断机制。Datanode上线后，在zookeeper中创建一个Ephemeral Node，用以给Namenode判断该Datanode是否在线。该类型的Node会在Datanode下 线后(会话失效)自动删除。如果Namenode通过datanode表中的lastupdate判断已经下 线，但是zookeeper中还有对应的node，会将其列入怀疑对象。造成这种现象一般在 TBFS重启初期，Namenode信息更新不及时。怀疑对象一般会在下一次更新时自动排 除，否则就认为它已经下线。 12
- 13. 流程一：顿狈启动 开始 在Data Node初始化时执行下面的逻辑， 会重构DataNode类的startDataNode方 时连接NN。DN 法 需要根据选取策 N 设置策 DN启动时设定，目前包括两方面：1. 从 略，从NN列表中 略 何处获得NN列表（包括配置文件或者 选取一个可用的 zookeeper）；2. 如何选择NN（随机或 Y 者根据某种权值） NN地址建立连接， N 获得 在配置文件中，NN之间以逗号隔开；如 否则流程失败 NN列 果从zookeeper中读取，需要讨论接口。 表 该列表用List<String> NNList表示 Y 从NNList中根据选择策略选择一个 N 取一个 Name Node，如果NNList中已经没有可 新NN 用的，则返回失败 Y 将该失败的NN从NNList中 移除NN 移除 连接成 功 N 连接成功，可以进行通信 Y 结束
- 14. 流程二：当前已 开始 如果侦测到当前NN失效，则开始下面的 操作 连接的NN失效， DN重新选择NN， 从现有的NNList中根据选择策略选择一 取一个 并进行连接 新NN 个Name Node，如果已经没有NN，则 试图根据既定策略重新获得列表 N Y Y 是否已 检查是否已经重新更新过，如果已经更 更新过 新过，说明所有NN都不可用 N 第一次更新，可以重新获得列表，如果 获得 失败则结束流程 NN列 表 Y N 移除NN 将该失败的NN从NNList中 移除 连接成 功 N 连接成功，可以进行通信 Y 结束
- 15. 流程叁：手动或 开始 由管理员或者后台监控进程发起更新 NN列表操作 自动更新NN列表 获得新 根据策略获得新的NN列表，如果无 NN列表 法获取，则返回失败 N Y 替换现有NN列 表 更新NNList操作 结束
- 17. 谢谢 罗李 Email: luoli523@gmail.com Twitter: luoli523