马如悦-百度大规模数据处理

大规模数据存储大规模数据分析AddYourTextinhere主要内容大规模数据索引大规模数据存储LustreLustre：：HDFSHDFS：：设计前提：特点：硬件是不容易坏的。随机访问性能好，没有容错，规模低于1PB，节点失效后部分数据不能访问。设计前提：特点：硬件是容易坏的，坏了也可以自动恢复。容错，不需要人工干预，节点失效后系统任然可持续提供服务，规模可以扩展到EB。系统结构主从架构:1台Namenode，多台DatanodesNamenodeDatanodeReplicationMetadata(Name,replicas,…)(/foo/data,3,…)fDatanodeDatanodeDatanodeDatanodeRack1Rack2ClientWhereisf?R1D1,R1D2,R2D1ffyahoo最大的Hadoop集群包含节点4000台；所有Hadoop集群节点总共一万台HDFS优势支持海量存储；全局命名空间；数据高可用性；服务高可靠性；系统扩展性好；数据安全性；易用性（vfs兼容层）；支持MapReduce编程框架；支持Hbase、Hypertable等分布式索引系统。HDFS不足随机读性能较差；只支持单一追加(已满足应用需要）；文件写入不立即可读，不支持“tail–f”；不支持sync、mmap和软硬链接操作；Namenode是单点(双机备份策略基本解决问题）；大量小文件会面临Namenode内存不足等问题；百度应用实践-问题存储超过20PB数据每日新增数据超过10TBNameNode瓶颈问题（容量和性能）数据安全性每周近百块故障硬盘百度应用实践-对策2000+NODESNODES：2*4core，12*1TBdisk分布式NameNode访问权限控制故障硬盘自动发现并淘汰大规模数据分析MPIMPI：：MapReduceMapReduce：：设计前提：特点：输入数据一般不会多于10TB，计算很密集，计算相关性很强，硬件不容易坏。适用于数据相关性强，迭代次数多的计算，不适合处理过大规模数据，节点数不超过百台，节点失效会影响全局。设计前提：特点：输入数据会超过100TB，数据全局相关性弱，硬件是容易坏的。适用于大规模数据处理，节点规模可以达到数千台，节点失效对系统无影响。MapReduce概念模型MapReduce实现模型Master-JobTracker–作业与任务调度–负责将中间文件信息通知给reducer所在的worker–Master周期性检查Worker的存活Worker-TaskTracker–TaskTracker空闲,向Master要任务–执行mapper或者reducer任务框架所做的处理–作业任务调度–错误处理，失败任务自动重算–防止慢作业，任务的预测执行MapReduce-Hadoop实现百度应用实践-问题每天处理1PB以上数据每天提交10000+JOBs多用户共享机群实时JOB和优先级问题JobTracker压力JAVA语言效率Hadoopmap-reduce效率复杂机器学习算法应用百度应用实践-对策可伸缩的计算资源调度系统计算资源和IO资源的平衡提高硬盘吞吐降低IOPS计算层重构(HadoopC++HadoopC++扩展扩展)Shuffle和Sort重构（HadoopC++HadoopC++扩展扩展）MapReduce与MPI配合使用大规模数据索引MysqlMysql：：HBaseHBase：：设计前提：特点：数据规模不超过100GB，数据相关性比较强，不考虑服务器失效。能提供复杂的SQL语义和事务处理，数据规模不能动态扩展，服务器死了，服务就会受影响。设计前提：特点：数据规模可能超过PB，数据相关性比较弱，必须实现分布式容错。语义比较简单，事务支持有限，数据规模能动态扩展，节点失效，自动冗余。Hbase百度应用实践-问题和对策随机访问效率偏低节点故障时超时时间长API易用性问题与HDFS耦合时的稳定性问题总结:正在重点解决的HDFSnamenode的分布式改进HDFSdatanode的读写异步化MapReduce的jobtracker的分布式改进MapReduce的新的作业和任务调度器MapReduce的hadoopc++扩展框架大规模数据处理要求系统容错性好规模可以通过机器数量扩展为了满足容错性和扩展性，放弃兼容性成熟的系统同时使用传统的方案和新方案总结:原则问题解答