互联网络用户的剧增和宽带网络的普及，使得互联网络服务的本质是以海量数据处理为中心的服务。从搜索引擎、视频共享到电子商务，互联网络服务的成功与否在 很大程度上依赖于所提供数据的规模和质量，数据处理的及时性、有效数据的比例等。 Gordon Bell、Jim Gray和Alex Szalay在2006年1月的Computer杂志上发表的“Petascale computational systems”中指出，计算机科学正在发生变化，以数据密集（Data-intensive）型计算为主要趋势。高性能计算系统必须设计为一个均衡的系 统，不仅仅是单纯的处理器性能达到Peta级，而且也包括I/O和网络。数据的局部性（Data Locality）在PB级的数据处理中显得尤为重要，即应该尽量让计算靠近数据存储而不是远程拷贝数据进行计算。Gordon的因特网经济模型表明，在 因特网上远程移动1字节数据的代价是昂贵的，这只有在平均每字节数据需要耗费10万个CPU指令周期处理时才是划算的。数据局部性对软件的设计提出了挑 战，因为大多数的中间件都未考虑数据移动的昂贵代价和未利用数据的缓存策略。
海量数据处理问题的挑战 海量数据处理能力面对的挑战是： n 面对PB级数据，很难完全在内存中完成处理过程，很大程度上依赖于磁盘I/O，并且需要可扩展的处理能力 n 需要降低数据处理的成本，包括利用普通商用PC服务器组成的集群，最小化每单元计算能力、RAM和I/O的成本 n 需要保障在大规模计算过程中的可靠性
每18到24个月CPU频率和磁盘传输速率，RAM和磁盘容量会加倍，但是磁盘寻址时间由于音圈电机定位的限制其发展速度却近乎常数（每年不到5%）。 可扩展的海量数据计算必须从依赖于磁盘寻址时间（seek-time）的计算转到依赖于磁盘传输时间（transfer-time)，即传统的关系数据库 系统技术不再适用。 Map/Reduce最早由Google研发人员提出。这种处理方式实际上是在数据存放的时候不建立索引，等实际处理数据的时候再将这些数据读入内存进行 排序，并可以将数据分隔在不同的机器上同时进行处理。Map/Reduce把对数据记录的所有操作都归结两个步骤：其中Map对现有数据做一个先期处理， 得到一个中间数据集，Reduce再对中间数据集进行去重、过滤等后期处理，最后得到所要的结果。在使用Map/Reduce框架时，待处理的数据先通过 顺序读磁盘进行分别处理，在内存中排序后交由合并程序进行后处理，尽量避免了磁盘的随机存取操作，使得海量数据的处理效率得到快速提高。 Yahoo的Hadoop 开 发人员经过试验，在10MB/s传输速率和10ms的磁盘寻道时间的情况下，更新1TB数据中的100M数据，如果使用基于传统B树的关系数据库系统，则 随机更新需要1000天，批处理更新需要100天，而使用顺序读取的排序/合并的新型数据处理方法（如Map/Reduce）只需要1天，即效率提高 100倍！ 如果需要处理100T的数据集，在1个节点上，以50MB/s的速度扫描需要23天，而平均故障间隔时间（MTBF）为3年。如果在1000个节点的集群 上，33分钟可以完成扫描，但MTBF为1天。这就需要新的框架来实现可靠性的保障，同时这种可靠性也是可扩展和容易管理的。
转自http://www.huomo.cn