百度作为全球最大的中文搜索引擎公司，提供基于搜索引擎的各种产品，包括以网络搜索为主的功能性搜索；以贴吧为主的社区搜索；针对区域、行业的垂直搜索、MP3音乐搜索，以及百科等，几乎覆盖了中文网络世界中所有的搜索需求。
百度对海量数据处理的要求是比较高的，要在线下对数据进行分析，还要在规定的时间内处理完并反馈到平台上。百度在互联网领域的平台需求如图3-3所示，这里就需要通过性能较好的云平台进行处理了，Hadoop就是很好的选择。在百度，Hadoop主要应用于以下几个方面：
日志的存储和统计；
网页数据的分析和挖掘；
商业分析，如用户的行为和广告关注度等；
在线数据的反馈，及时得到在线广告的点击情况；
用户网页的聚类，分析用户的推荐度及用户之间的关联度。
MapReduce 主要是一种思想，不能解决所有领域内与计算有关的问题，百度的研究人员认为比较好的模型应该如图3-4所示，HDFS实现共享存储，一些计算使用 MapReduce解决，一些计算使用MPI解决，而还有一些计算需要通过两者来共同处理。因为MapReduce适合处理数据很大且适合划分的数据，所 以在处理这类数据时就可以用MapReduce做一些过滤，得到基本的向量矩阵，然后通过MPI进一步处理后返回结果，只有整合技术才能更好地解决问题。
 |
| 图3-3 互联网领域的平台需求 |
百度现在拥有3个Hadoop集群，总规模在700台机器左右，其中有100多台新机器和600多台要淘汰的机器（它们的计算能力相当于200多台新机器），不过其规模还在不断的增加中。现在每天运行的MapReduce任务在3000个左右，处理数据约120TB/天。
百度为了更好地用Hadoop进行数据处理，在以下几个方面做了改进和调整：
（1）调整MapReduce策略
限制作业处于运行状态的任务数；
调整预测执行策略，控制预测执行量，一些任务不需要预测执行；
根据节点内存状况进行调度；
平衡中间结果输出，通过压缩处理减少I/O负担。
 |
（2）改进HDFS的效率和功能
权限控制，在PB级数据量的集群上数据应该是共享的，这样分析起来比较容易，但是需要对权限进行限制；
让分区与节点独立，这样，一个分区坏掉后节点上的其他分区还可以正常使用；
修改DFSClient选取块副本位置的策略，增加功能使DFSClient选取块时跳过出错的DataNode；
解决VFS（Virtual File System）的POSIX（Portable Operating System Interface of Unix）兼容性问题。
（3）修改Speculative的执行策略
采用速率倒数替代速率，防止数据分布不均时经常不能启动预测执行情况的发生；
增加任务时必须达到某个百分比后才能启动预测执行的限制，解决reduce运行等待map数据的时间问题；
只有一个map或reduce时，可以直接启动预测执行。
（4）对资源使用进行控制
对应用物理内存进行控制。如果内存使用过多会导致操作系统跳过一些任务，百度通过修改Linux内核对进程使用的物理内存进行独立的限制，超过阈值可以终止进程。
分组调度计算资源，实现存储共享、计算独立，在Hadoop中运行的进程是不可抢占的。
在大块文件系统中，X86平台下一个页的大小是4KB。如果页较小，管理的数据就会很多，会增加数据操作的代价并影响计算效率，因此需要增加页的大小。
百度在使用Hadoop时也遇到了一些问题，主要有：
MapReduce的效率问题：比如，如何在shuffle效率方面减少I/O次数以提高并行效率；如何在排序效率方面设置排序为可配置的，因为排序过程会浪费很多的计算资源，而一些情况下是不需要排序的。
HDFS的效率和可靠性问题：如何提高随机访问效率，以及数据写入的实时性问题，如果Hadoop每写一条日志就在HDFS上存储一次，效率会很低。
内 存使用的问题：reducer端的shuffle会频繁地使用内存，这里采用类似Linux的buddy system来解决，保证Hadoop用最小的开销达到最高的利用率；当Java 进程内容使用内存较多时，可以调整垃圾回收（GC）策略；有时存在大量的内存复制现象，这会消耗大量CPU资源，同时还会导致内存使用峰值极高，这时需要 减少内存的复制。
作业调度的问题：如何限制任务的map和reduce计算单元的数量，以确保重要计算可以有足够的计算单元；如何对TaskTracker进行分组控制，以限制作业执行的机器，同时还可以在用户提交任务时确定执行的分组并对分组进行认证。
性 能提升的问题：UserLogs cleanup在每次task结束的时候都要查看一下日志，以决定是否清除，这会占用一定的任务资源，可以通过将清理线程从子Java进程移到 TaskTracker来解决；子Java进程会对文本行进行切割而map和reduce进程则会重新切割，这将造成重复处理，这时需要关掉Java进程 的切割功能；在排序的时候也可以实现并行排序来提升性能；实现对数据的异步读写也可以提升性能。
健 壮性的问题：需要对mapper和reducer程序的内存消耗进行限制，这就要修改Linux内核，增加其限制进程的物理内存的功能；也可以通过多个 map程序共享一块内存，以一定的代价减少对物理内存的使用；还可以将DataNode和TaskTracker的UGI配置为普通用户并设置账号密码； 或者让DataNode和TaskTracker分账号启动，确保HDFS数据的安全性，防止Tracker操作DataNode中的内容；在不能保证用 户的每个程序都很健壮的情况下，有时需要将进程终止掉，但要保证父进程终止后子进程也被终止。
Streaming 局限性的问题：比如，只能处理文本数据，mapper和reducer按照文本行的协议通信，无法对二进制的数据进行简单处理。为了解决这个问题，百度人 员新写了一个类Bistreaming（Binary Streaming），这里的子Java进程mapper和reducer按照（KeyLen，Key，ValLen，Value）的方式通信，用户可以 按照这个协议编写程序。
用户认证的问题：这个问题的解决办法是让用户名、密码、所属组都在NameNode和Job Tracker上集中维护，用户连接时需要提供用户名和密码，从而保证数据的安全性。
百度下一步的工作重点可能主要会涉及以下内容：
内存方面，降低NameNode的内存使用并研究JVM的内存管理；
调度方面，改进任务可以被抢占的情况，同时开发出自己的基于Capacity的作业调度器，让等待作业队列具有优先级且队列中的作业可以设置Capacity，并可以支持TaskTracker分组；
压缩算法，选择较好的方法提高压缩比、减少存储容量，同时选取高效率的算法以进行shuffle数据的压缩和解压；
对mapper程序和reducer程序使用的资源进行控制，防止过度消耗资源导致机器死机。以前是通过修改Linux内核来进行控制的，现在考虑通过在Linux中引入cgroup来对mapper和reducer使用的资源进行控制；
将DataNode的并发数据读写方式由多线程改为select方式，以支持大规模并发读写和Hypertable的应用。
百度同时也在使用Hypertable，它是以Google发布的BigTable为基础的开源分布式数据存储系统，百度将它作为分析用户行为的平台，同时在元数据集中化、内存占用优化、集群安全停机、故障自动恢复等方面做了一些改进。
Facebook 作为全球知名的社交网站，拥有超过3亿的活跃用户，其中约有3千万用户至少每天更新一次自己的状态；用户每月总共上传10亿余张照片、1千万个视频；以及 每周共享10亿条内容，包括日志、链接、新闻、微博等。因此Facebook需要存储和处理的数据量是非常巨大的，每天新增加4TB压缩后的数据，扫描 135TB大小的数据，在集群上执行Hive任务超过7500次，每小时需要进行8万次计算，所以高性能的云平台对Facebook来说是非常重要的，而 Facebook主要将Hadoop平台用于日志处理、推荐系统和数据仓库等方面。
Facebook 将数据存储在利用Hadoop/Hive搭建的数据仓库上，这个数据仓库拥有4800个内核，具有5.5PB的存储量，每个节点可存储12TB大小的数 据，同时，它还具有两层网络拓扑，如图3-5所示。Facebook中的MapReduce集群是动态变化的，它基于负载情况和集群节点之间的配置信息可 动态移动。
 |
| （点击查看大图）图3-5 集群的网络拓扑 |
图 3-6为Facebook的数据仓库架构，在这个架构中，网络服务器和内部服务生成日志数据，这里Facebook使用开源日志收集系统，它可以将数以百 计的日志数据集存储在NFS服务器上，但大部分日志数据会复制到同一个中心的HDFS实例中，而HDFS存储的数据都会放到利用Hive构建的数据仓库 中。Hive提供了类SQL的语言来与MapReduce结合，创建并发布多种摘要和报告，以及在它们的基础上进行历史分析。Hive上基于浏览器的接口 允许用户执行Hive查询。Oracle和MySQL数据库用来发布这些摘要，这些数据容量相对较小，但查询频率较高并需要实时响应。一些旧的数据需要及 时归档，并存储在较便宜的存储器上，如图3-7所示。
 |
| （点击查看大图）图3-6 Facebook数据仓库架构 |
下 面介绍Facebook在AvatarNode和调度策略方面所做的一些工作。AvatarNode主要用于HDFS的恢复和启动，若HDFS崩溃，原有 技术恢复首先需要花10～15分钟来读取12GB的文件镜像并写回，还要用20～30分钟处理来自2000个DataNode的数据块报告，最后用 40～60分钟来恢复崩溃的NameNode和部署软件。表3-1说明了BackupNode和AvatarNode的区别，AvatarNode作为普 通的NameNode启动，处理所有来自DataNode的消息。AvatarDataNode与DataNode相似，支持多线程和针对多个主节点的多 队列，但无法区分原始和备份。人工恢复使用AvatarShell命令行工具，AvatarShell执行恢复操作并更新ZooKeeper的 zNode，恢复过程对用户来说是透明的。分布式Avatar文件系统实现在现有文件系统的上层。
 |
| （点击查看大图）图3-7 数据归档 |
表3-1 BackupNode和AvatarNode的区别
 |
基 于位置的调度策略在实际应用中存在着一些问题：如需要高内存的任务可能会被分配给拥有低内存的TaskTracker；CPU资源有时未被充分利用；为不 同硬件的TaskTracker进行配置也比较困难等。Facebook采用基于资源的调度策略，即公平享有调度方法，实时监测系统并收集CPU和内存的 使用情况，调度器会分析实时的内存消耗情况，然后在任务之间公平分配任务的内存使用量。它通过读取/proc/目录解析进程树，并收集进程树上所有的 CPU和内存的使用信息，然后通过TaskCounters在心跳（heartbeat）时发送信息。
Facebook 的数据仓库使用Hive，其构架如图3-8所示，有关Hive查询语言的相关知识可查阅第11章的内容。这里HDFS支持三种文件格式：文本文件 （TextFile），方便其他应用程序读写；顺序文件（SequenceFile），只有Hadoop能够读取并支持分块压缩；RCFile，使用顺序 文件基于块的存储方式，每个块按列存储，这样有较好的压缩率和查询性能。Facebook未来会在Hive上进行改进，以支持索引、视图、子查询等新功 能。
 |
| （点击查看大图）图3-8 Hive的体系结构 |
现在Facebook使用Hadoop遇到的挑战有：
服务质量和隔离性方面，较大的任务会影响集群性能；
安全性方面，如果软件漏洞导致NameNode事务日志崩溃该如何处理；
数据归档方面，如何选择归档数据，以及数据如何归档；
性能提升方面，如何有效地解决瓶颈等。