百度技术沙龙（第2期）- 2. 互联网应用服务扩展的一点经验（转载）

源地址：http://www.infoq.com/cn/presentations/maruyue-ls-data-processing

 

在百度技术沙龙第2期（5月15日）的活动上，我们邀请到了百度分布式高级工程师马如悦以及FreeWheel的核心系统技术总监王迪分别分享了关于分布式以及服务扩展两个话题，本文将对他们的演讲内容进行一下简单的总结，并为大家提供了演示文档的下载。

为Hadoop的发展贡献自己的力量

在马如悦的演讲中，他主要介绍了百度的大规模数据存储、数据分析以及数据索引，主要包括以下内容点：

• 大规模数据存储
  • Lustre和HDFS
  • 系统结构
  • HDFS优势、不足
• 大规模数据分析
  • MPI和MapReduce
  • MapReduce概念模型、实现模型
  • MapReduce-Hadoop实现
• 大规模数据索引
  • MySQL和HBase对比
  • HBase详解
• 在以上三方面百度遇到的问题、对策和原则

其中，马如悦提到，百度现在要处理的数据量非常庞大：存储20PB+数据，每日新增数据10TB+，每天处理的数据1PB+，每天提交10K+次作业。现在使用的文件系统是HDFS，数据存储是HBase，有超过2K台服务器节点，每个节点为2*4 core。现在遇到的一个棘手问题便是namenode的瓶颈问题：因为要存储大量的（小）文件，使namenode的压力非常大，他们刚刚采购了48GB的内存，但是这48GB的内存，预计只能坚持到今年年底，到时候，可能会采购96GB的内存来紧急应对这个问题。所以百度在namenode的分布式方面，进行了很多研究。马如悦建议大家：

如果对这方面感兴趣的话，可以参考Linux 2.6.34中的Ceph文件系统，它就是一个基于PB规模的分布式文件系统。

最后，马如悦提到了百度目前正在重点研究/解决的几个问题/方向，他建议如果大家想对Hadoop做出一些成绩的话，这几个方向也是现在的热点：

• HDFS namenode的分布式改进
• HDFS datanode的读写异步化
• MapReduce的jobtracker的分布式改进
• MapReduce的新作业和任务调度器
• MapReduce的Hadoop C++扩展框架

有读者对Hadoop C++的扩展非常感兴趣，马如悦对此阐述了一下百度Hadoop的使用方式：

我们会定期在Hadoop的官方版本上找到一个稳定版本，然后进行自定义开发。过一段时间，当我们发现官方的版本如果增加了很多新增加的功能，比我们好很多，我们再开一个新的分支，把我们的功能移上去。我们的工程师在开发Hadoop的C++扩展，我们大概是在0.19版分出来的，至今我们发现chunk版本仍然跑不过百度自己的版本，所以我们不会去做移植。HCE在我们的版本上开发的，所以如果转移到chunk上，会有些难度，需要做一些调整，这会花费一些时间。上周我们工程师刚完成了一个版本，马上就可以为大家贡献出一个链接去试用。

以数据驱动为中心

王迪是FreeWheel核心系统的技术总监，从07年FreeWheel创立起，他全程参与到其广告核心系统的架构设计，也见证了FreeWheel从最初的的只有20台广告服务器、日均几十万的访问量、不到1G/天的日志量，发展到现在拥有60台广告服务器、日均广告请求5000万次、日志处理服务器8台、日均4小时处理日志200G这么一个规模。3年之间，流量增长20倍。他主要谈到了以下的一些经验和原则：

• 应用服务扩展
  • 无状态应用服务
  • 复制与多层次Cache
• 数据仓库扩展
  • De-normalization/Pivot
  • Roll up/Data Availability
  • Benchmarking与查询优化
  • Split-Loading/Sharding
• 运营原则
  • 50%运行负载上限 & N+1 Data Center
  • 监控和响应
  • 多阶段部署

很多具体的实践方法，都是针对他们具体的商业模式以及实际工作中摸索出来的，它不一定是“最好”的，但却是最适合的，比如对系统的负载当达到50%的时候，就是一个优化和扩容的信号了；再比如，以自动化回归测试为核心，但并未使用TDD单元测试，等等等等。

在提问环节，有读者对如何在回归测试中组织测试用例很感兴趣，王迪解释到：

比如我们有700个测试用例，需要QA做一些数据，可以用SQL文件的方式存在本地，然后把请求和预期也同样以文件的方式存在本地，然后在框架运行的时候，把它们载入到数据库当中，然后再服务结束后，再从数据库中取出来。