大规模数据处理.ppt

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