罗李：构建一个跨机房的Hadoop集群
- 2. 提纲 – 背景介绍 – 构建跨机房集群的困难 – 我们的方案
- 3. 背景介绍 – 云梯集群 • • • • • Hadoop集群 版本代码有云梯开发团队维护 2009年开始上线服务 跨机房之前（2013年4月）规模4500台，109PB 大集群，多租户（>5000），多资源组(>150) • 生产任务、数据分析、数据开发和测试共享集 群 • 计算分时，存储和计算quota • 目前规模：5000 × 2 （分布在2个IDC）
- 4. 背景介绍 – 曾经限制云梯扩展性的因素 • • • • • • NameNode处理RPC性能 NameNode内存 JobTracker处理RPC性能 JobTracker带宽 JDK限制 。。。 – 现在 • 云梯集群机房机位不够 • 数据量的日增长速度让云梯机房最多支撑到 2013年6月底
- 5. 背景介绍 – 云梯机房机位已满 – 存储利用率超过85% – 计算利用率接近100% – 几乎每天都有新的存储和计算资源的申请
- 7. NameNode的扩展性 – 性能压力：存储容量 • N亿文件，N亿block • 可垂直扩展：物理内存，96GB->192GB->…->1TB? – 性能压力：RPC请求压力 • • • • 几乎所有的RPC是有状态的，需要全局锁，更新树 Client请求: 5000(slaves) * 20(slots/slaves) = 10w并发 DataNode请求: blockReport & heartbeat ≈ 2000 qps 垂直扩展？CPU主频1.8GHz->3.2GHz->??? 多核??? – 多NameNode的目的：水平扩展，分散Client的RPC 请求压力 – 借鉴成熟的方案——HDFS Federation
- 8. 跨机房网络限制 – 带宽 • 单机房内：点对点的带宽1Gbps • 跨机房间（5000 vs. 5000）：点对点的带宽≈20Mbps • 总带宽较小，容易被打满，成为瓶颈 – 延时 • 1ms之内 -> 5-10ms • 对离线作业的影响可控 – 故障 • 机房间网络故障如何处理？ • 如何保障断网后，任意一个机房内部的服务是否正常？
- 9. 数据和计算如何跨机房分布 – N个资源组，M个机房 GroupA GroupC GroupB DC1 DC2 GroupD • 任意资源组的计算/存储资源不超过单个机房总量 • 单个计算任务 (Job) 的所有 Task 在同一机房内运行 • (默认)产生的数据只写到本地机房 • 也有部分数据需要跨机房写 • (默认)只读取本机房的文件副本 • 也有少部分作业直接跨机房读 尽量减少 跨机房的 数据流量
- 11. 技术实现
- 12. 多namenode方案 —— federation – 业界有成功案例：Facebook – 原始方案：单机房多NameNode – 目的：拆分Namespace /group/B /group/D /group/A /group/C NN1 DN Block Pools Pool1 /disk*/p1 Pool2 /disk*/p2 DN NN2 DN DN DN DN
- 13. Namespace split – distcp？ —— 慢，代价大 – FastCopy？ —— 快很多，没有物理拷贝，但仍然太慢 • From Facebook • https://issues.apache.org/jira/browse/HDFS-2139 1. 从源NameNode上获取文件信息和 block 信息，并在 目标 NameNode 上创建同样的文件 2. 获取 block 所在 DataNode 信息 3. 在DataNode上多个block pool之间复制数据（Hard Link） 4. block report 给目标 NameNode – 我们的方案
- 14. Namespace split – 我们的拆分方案 /group/A /group/A /group/C /group/B /group/C /group/D 1，nn2 load fsimag1 NN1 NN2 3，pool1 report to NN1 4，pool2 report to NN2 DN1 Pool1 /disk*/p 1 /group/B /group/D /group/A /group/B /group/C /group/D DN2 Pool2 /disk*/p2 Pool1 /disk*/p 1 DN3 Pool2 /disk*/p2 2，hardlink pool1 to pool2 Pool1 /disk*/p 1 Pool2 /disk*/p2
- 15. 对Client透明：ViewFS – 用户无需感知集群多机房的细节 – HDFS多NameNode • ViewFS – MapReduce 计算 • JobTracker Proxy • ResourceManager Proxy（Hadoop 2.0）
- 16. 对Client透明：ViewFS – 配合HDFS Federation使用 – 要点： • • • • • Client Side Mount Table 屏蔽多namespace细节 fs.default.name: hdfs://nn.ali.com:9000/ -> viewfs://nsX/ Defaut filesystem: DistributedFileSystem -> ViewFileSystem 用户路径随之改变 – 我们的改进 • Zookeeper保存Mount table，方便更新和统一管理 • 需要对以下场景真正的透明化 – 用户代码hard code：hdfs://nn.ali.com:9000/ – Hive元数据库：hdfs://nn.ali.com:9000/group/tb/hive/tb1 – Hive local mode：把非hdfs开头的路径作为local方式 • 一个新的FileSystem封装了ViewFileSystem
- 18. 对Client透明：ViewFS create fs.hdfs.impl = Yunti3FileSystem mkdir hdfs://hdpnn:9000 /group/A -> nn1 /group/C-> nn1 /group/B -> nn2 /group/D -> nn2 Yunti3 FileSystem viewfs://nsX View Distributed FileSystem ZooKeeper FileSystem hdfs://nn1:9000 hdfs://nn2:9000 Distributed Distributed FileSystem /group/A /group/C open FileSystem NameNode (NS1) NameNode (NS2) Client /group/B /group/D
- 19. MR ProxyNode – MR ProxyNode： • 每个 JobTracker 只调度一个机房内的作业 • ProxyNode 直接处理 JobClient 请求，并自动转发给相应 的 JobTracker 或 ResourceManager • 提供同一的Job查询接口（Web UI / App） – Job 调度机制优化：把计算调度到数据所在的地方 1. 跨机房列表中的数据正在传输中（DC1->DC2），DC2上的 Job 被暂停调度，等待传输完毕 2. Ad-hoc查询，DC2上的 Job 需要读DC1上的数据，Job暂停 调度，通知 CrossNode，数据传输完毕后继续调度 3. 跨机房数据 Join，DC1大表，DC2小表，Job 调度到DC1上， 跨机房直接读取DC2数据，无需等待
- 20. MR proxynode (cont.) JobClient JobClient Mapping: groupA -> JT1 groupB -> JT2 MR ProxyNode RM1 NM JT1 TT TT JT2 TT TT TT RM2 TT NM
- 22. CROSSNODE – 一个独立的服务，对NameNode发送指令 – 主要功能 1. 根据预置的跨机房文件列表计算待拷贝的文件 2. 让NameNode增加跨机房的文件副本 3. 维护文件原始副本数，跨机房副本数，实际副本数 等状态信息 4. 从NameNode实时同步文件创建，移动，删除等信息 5. 对跨机房的流量进行监控和限速 6. CrossFsck 检查当前跨机房文件的副本放置状况，并 指挥NameNode 进行纠正
- 23. CrossNode (cont.) – 跨机房数据迁移，几十PB的数据迁移 • 将整个资源组的数据作为跨机房文件列表（/group/B） • 副本数 3:0 -> 3:3 -> 0:3 – 如何预先知道需要跨机房的文件？ • 通过历史作业分析得到大部分需要跨机房的文件或目 录 • 形成一个跨机房文件列表，作为CrossNode的输入 – HDFS文件副本复制不及时？ • JobTracker对所有的Job输入做检查 • 和CrossNode进行通信 • 可以暂停Job的执行
- 25. 云梯现在的样子 – 多NameNode，跨越2个物理机房： • HDFS Federation – 跨机房副本管理，数据迁移 • CrossNode – 多机房对用户透明 • ViewFS • MR ProxyNode – 规模已接近万台（还没到一万，到那天我会告诉大家的） – 可存储数据容量220PB
- 26. 云梯将来的样子 • 对外服务？ • 云端企业私有hadoop集群？ • 集成分布式解决方案？ • 搭载云梯hadoop版本 • 搭载我们的hbase版本和hive版本 • hadoop淘宝开源发行版？ • 。。。。。
- 27. 加入我们 – 阿里巴巴数据平台事业部 – 阿里巴巴技术保障部 – 我们正在招聘Hadoop/Hbase/Hive开发工程师， 运维工程师，SA，Java工程师，数据开发工程 师，算法工程师，妹子等等。。。 – guili.ll@taobao.com – @luoli523
- 28. 谢谢