[1] 构建一个跨机房的Hadoop集群

构建一个跨机房的Hadoop集群吴威(无谓)提纲•项目背景•构建跨机房集群的困难•技术方案阿里巴巴离线数据处理现状•两大离线计算平台•云梯Hadoop集群：2009年开始对内提供服务•ODPS集群：2012年开始服务•特点•大集群，多租户（5000），多资源组(150)•生产任务、数据分析、数据开发和测试共享集群•计算分时，存储和计算quota•面临同样的问题：扩展性为什么要搞大集群？•大集群的缺点•稳定性不足：开发任务影响生产任务？•数据没有冗余•以上都可以通过技术解决•优点•数据管理方便：集中式权限管理和分配•数据获取更加便利：开发人员直接读取生产数据•方便的数据共享：跨部门数据使用•运维和监控更加简单•为什么要搞跨机房的大集群？•阿里云梯集群：单集群4500台，容量109PB，单机房！•数据日增量大，扩容加机器，2T硬盘换4T，8核CPU换12核…•机房规模是现阶段Hadoop集群规模的上限1.NameNode的扩展性2.机房间网络限制3.数据应该如何跨机房分布？4.计算应该如何跨机房分布？5.几十PB数据的迁移，带数据升级6.怎样做到对用户透明？7.方案是否能扩展到多机房（=3）？需要解决的问题NAMENODE的扩展性•性能压力：存储容量•上亿文件，上亿block•可垂直扩展：物理内存，96GB-192GB-…-1TB?•性能压力：RPC请求压力•几乎所有的RPC是有状态的，需要全局锁，更新树•Client请求:5000(slaves)*20(slots/slaves)=10w并发•DataNode请求:blockReport&heartbeat≈2000qps•垂直扩展？CPU主频1.8GHz-3.2GHz-???多核???•多NameNode的目的：水平扩展，分散Client的RPC请求压力•借鉴成熟的方案——HDFSFederation跨机房网络限制•带宽•单机房内：点对点的带宽1Gbps•跨机房间（5000vs.5000）：点对点的带宽≈20Mbps•总带宽较小，容易被打满，成为瓶颈•延时•1ms之内-5-10ms•对离线作业的影响可控•故障•机房间网络故障如何处理？•如何保障断网后，任意一个机房内部的服务是否正常？数据和计算如何跨机房分布•N个资源组，M个机房GroupAGroupCGroupBDC1DC2GroupD•任意资源组的计算/存储资源不超过单个机房总量•单个计算任务(Job)的所有Task在同一机房内运行•(默认)产生的数据只写到本地机房•也有部分数据需要跨机房写•(默认)只读取本机房的文件副本•也有少部分作业直接跨机房读尽量减少跨机房的数据流量资源组切分和聚类•任意两个资源组之间通过相互数据访问建立关系•距离：每个资源组的作业访问其他资源组的数据量越大，关系越紧密，距离越近（距离系数是数据量反比）•聚类：距离接近资源组放在同一个机房内，降低机房见的数据拷贝量•聚类中心：每个机房一个聚类中心。也可以先找到资源大组，作为聚类中心资源组切分和聚类(CONT.)GroupA读取其他资源组的系数其他资源组读取GroupA系数跨机房的架构机房1机房2独享带宽用户Gateway内部网络NN1NN2JT1JT2/group/B/group/D/group/A/group/CDNTTDNTTDNTTDNTTDNTTgroupBDNTTgroupATaskTaskTaskTaskTaskDNTT/group/B/tbl1/group/A/tbl2CrossNode技术实现HDFSFEDERATION•社区成熟方案，Facebook等公司大规模使用•原始方案：单机房多NameNode•目的：拆分NamespaceNN1DNDNDNDNDNDNNN2Pool1/disk*/p1Pool2/disk*/p2/group/B/group/D/group/A/group/CBlockPoolsHDFSFEDERATION(CONT.)•可以扩展到多机房•方便的控制跨机房的数据量NN1DNDNDNDNDNDNNN2BlockPoolsPool1/disk*/p1NN1扩展一个节点/group/B/group/D/group/A/group/CNAMESPACE拆分：FASTCOPY•为什么不用distcp？•FastCopy•FromFacebook•从源NameNode上获取文件信息和block信息，并在目标NameNode上创建同样的文件2.获取block所在DataNode信息3.在DataNode上多个blockpool之间复制数据（HardLink）4.blockreport给目标NameNode•性能优化•利用MRJob的并行化•优化Job初始化的时间，使用servlet取代多次RPCcall，直接生成jobinputsplitsCROSSNODE•一个独立的服务，对NameNode发送指令•主要功能1.根据预置的跨机房文件列表计算待拷贝的文件2.让NameNode增加跨机房的文件副本3.维护文件原始副本数，跨机房副本数，实际副本数等状态信息4.从NameNode实时同步文件创建，移动，删除等信息5.对跨机房的流量进行监控和限速6.CrossFsck检查当前跨机房文件的副本放置状况，并指挥NameNode进行纠正CROSSNODE(CONT.)•跨机房数据迁移，几十PB的数据迁移•将整个资源组的数据作为跨机房文件列表（/group/B）•副本数3:0-3:3-0:3•如何预先知道需要跨机房的文件？•通过历史作业分析得到大部分需要跨机房的文件或目录•形成一个跨机房文件列表，作为CrossNode的输入•HDFS文件副本复制不及时？•JobTracker对所有的Job输入做检查•和CrossNode进行通信•可以暂停Job的执行CROSSNODE内部结构/a/bDC2/c/dDC2如何对用户透明•用户无需感知集群多机房的细节•HDFS多NameNode•ViewFS•MapReduce计算•JobTrackerProxy•ResourceManagerProxy（Hadoop2.0）VIEWFS•社区方案，配合HDFSFederation使用•要点：•ClientSideMountTable•屏蔽多namespace细节•fs.default.name:hdfs://nn.ali.com:9000/-viewfs://nsX/•Defautfilesystem:DistributedFileSystem-ViewFileSystem•用户路径随之改变•我们的改进•Zookeeper保存Mounttable，方便更新和统一管理•需要对以下场景真正的透明化•用户代码hardcode：hdfs://nn.ali.com:9000/•Hive元数据库：hdfs://nn.ali.com:9000/group/tb/hive/tb1•Hivelocalmode：把非hdfs开头的路径作为local方式•一个新的FileSystem封装了ViewFileSystemNewFileSystemVIEWFS(CONT.)Zookeepernn1.ali.comnn2….nn3.ali.com/group/A/group/BConfig:mounttableViewFileSystemhdfs://nn.ali.com:9000/group/A/filefs.hdfs.implViewFSAdminToolsUpdateWatchMRPROXYNODE•MRProxyNode：•每个JobTracker只调度一个机房内的作业•ProxyNode直接处理JobClient请求，并自动转发给相应的JobTracker或ResourceManager•提供同一的Job查询接口（WebUI/App）•Job调度机制优化：把计算调度到数据所在的地方1.跨机房列表中的数据正在传输中（DC1-DC2），DC2上的Job被暂停调度，等待传输完毕2.Ad-hoc查询，DC2上的Job需要读DC1上的数据，Job暂停调度，通知CrossNode，数据传输完毕后继续调度3.跨机房数据Join，DC1大表，DC2小表，Job调度到DC1上，跨机房直接读取DC2数据，无需等待MRPROXYNODE(CONT.)JobClientJobClientMRProxyNodeJT1JT2TTTTTTTTTTTTMapping:groupA-JT1groupB-JT2NMNMRM1RM2总结——我们的方案•多NameNode：•HDFSFederation•跨机房副本管理，数据迁移•CrossNode•多机房对用户透明•ViewFS•MRProxyNode加入我们•阿里巴巴数据平台事业部••我们正在招聘Hadoop/HBase开发工程师，Java工程师，数据开发工程师等等。。。Q&A谢谢！