从谷歌（google）到Hadoop，再到大数据商业智能（Big Data BI）

从Google到Hadoop

谷歌（google）在成立公司的第一天起，就面对着大数据的问题。谷歌在大数据技术开发上，投入大量的资金和人才，其成就一直领先业界。谷歌对于核心技术也从不掩盖，积极在学术期刊上公开其大数据系统的最新进展，对业界，特别是开源社区（open source community）, 起着指导作用。在过去十年里，一般是谷歌首先发表关于大数据技术的论文，然后开源社区的程序员研究并消化这些论文，在大约三年之后推出复制系统。从Google File System(GFS), 开源复制出Hadoop File System (HDFS), 从Google MapReduce，开源复制出Hadoop MapReduce, 从Google BigTable, 开源复制出HBase，从Google Dremel, 开源复制出Cloudra Impala。。。预计这种开源的开发模式，在将来还会继续下去。

 

HadoopFile System 和 MapReduce

谷歌搜索引擎要工作，必须至少满足两个条件，第一是有廉价的海量存储系统，第二是能在此存储系统上快速建立搜素索引（searchindex）。谷歌需要扒下（crawl）互联网上所有网页的内容，还要给每个网页建立索引，其存储要求之高，运算量之大，是其他公司原先没有碰到过的。Google File System和Google MapReduce分别满足了第一和第二个条件，它们使谷歌搜索引擎的建立在技术上成为可能。 Hadoop指的是Hadoop File System和MapReduce的组合，因为它们都从谷歌而来，它们也继承了谷歌原本系统的特性。

 

Hadoop File System是一个建立在Linux文件系统上分布式文件系统，相对于Linux操作系统来说， HDFS只是一个Java应用层而已。它的构架设计是一种的主从构架（Master Slave）。一台Linux机器会作为主节点，叫NameNode，剩下的Linux机器会作为从节点，叫DataNode。NameNode存放着文件系统的元数据（metadata）, 既文件目录和文件在各个DataNode的分布信息。一个客户程序要访问HDFS，就要首先通过NameNode查询文件的存放信息，然后再和相关的DataNode进行通信。一个大文件在HDFS里会被切分成64M字节大小的文件块，均匀存储在不同DataNode上，同时每个文件块会被复制三次，分配到三个不同的DataNode上。对大文件的切分，使得整个系统负载更加均衡；对于文件块的复制，使得整个系统有很强的容错性。 HDFS本身不对数据作任何解释，数据在HDFS里就是一块数据流（blob）。还有，文件一旦在Hadoop里创建上载，可以被删除，但不能再更改。这个限制使Hadoop的结构的得到巨大的简化。当然这个限制也使一些应用如日志添加（Log Append）不能直接在HDFS上完成，这就需要在HDFS上运行附加系统，如HBase，以完成这些应用。

 

MapReduce一开始专门用来产生搜素引擎的反向索引（inverted index）的，它是一个简化了的平行计算框架。MapReduce作为一个计算框架，从理论上可以和任何存储系统一起工作，但实际上，由于MapReduce的输入和输出往往是海量数据，它主要在HDFS上运行。 MapReduce的构架也是一种主从构架，一台Linux机器会作为主节点，叫JobTracker，剩下的Linux机器成为从节点，叫TaskTracker。 JobTracker从客户程序接收任务（job），并将此任务切分成平行子任务（task）, 分配到相关的TaskTracker上执行。在Hadoop系统构架中，MapReduce JobTracker往往和HDFS的nameNode在同一台Linux机器上运行，而MapReduceTaskTracker和HDFS的DataNode在同一台机器上运行。当JobTracker分配任务时，它要首先看哪些datanode有这个任务的相关数据，然后选择在这些datanode上的TaskTracker执行任务。这样，TaskTracker只需读取本地数据，网络数据的传输被减到最少，这也是Hadoop系统能够有效处理大数据的根本原因所在。

 

之所以说MapReduce是一个简化的并行处理框架，是因为它把所有数据看作一系列的关键值对（Key-Value Pairs）。把数据都看作关键值对（KV）是一种简化，但是这种简化的计算平台在实际当中可以解决大量不同的分布计算问题，如WordCount，Sort甚至Table Join等，这一点确是令人惊讶。MapReduce的处理过程分成三个主要阶段， Map（映射），Shuffle（重排），和Reduce（归并）。 Map读取输入并产生一系列KV，当所有TaskTracker节点完成Map完成后，MapReduce会自动对KV进行重排（shuffle），按照Key重新分组，当重排结束时，有同样Key的KV paris将被分配在同一个组里，并在同一个Datanode节点上，所以在Shuffle过程， Datanode节点之间会通过网络进行大量的数据交换。当Shuffle完成后，JobTracker会通知所以相关的TaskTracker开始Reduce过程，既把在同一组的所有KV归并成一个KV。

 

节点之间的数据交换量是大规模并发处理系统可扩展性的一个重要限制因素，节点间数据交换量越大，系统的可扩展性就越差。从以上MapReduce的过程，我们可以看到数据在节点之间的交换被限制在Shuffle这个阶段，而且数据交换量和总数据量呈线性关系，所以MapReduce有很好的线性可扩展性。

 

当一个计算需要大量的数据输入和产生大量的数据输出时，如建立搜素引擎，MapReduce的性能要远远优于其它并行处理系统，这是MapReduce关键优势所在。

 

大数据商业智能分析（Big Data BI）

如何快速分析存储在Hadoop里的数据，成为越来越热点的问题。如果大数据不能被快速分析，那么其存在价值将大打折扣。BI在关系型数据库上已经有了较为成熟的产品，如MicroStrategy, Business Object，Cognos. 这些产品都可以根据用户报表要求，自动向数据库发出SQL查询。而关系型数据库可以实时执行这些SQL查询，这样用户在关系型数据库上实时可以进行BI分析。目前对于Hadoop 的BI方案主要有两种。

 

 

 

第一种就是通过MapReduce做ETL（ETL是数据仓库专用语，意思是数据提取、转换和加载），将数据从Hadoop 导入关系型数据仓库，然后仍能沿用原有BI分析构架，对存在关系型数据仓库的数据进行分析。 因为可以沿用原有BI分析构架，这种方案比较容易获得成功， 如美国电视传媒公司CBS Interactive用Hadoop –>[ETL] àTeradataà[SQL]àBI Tool这个流程，获得相当的成功；还有美国汽车资讯网站Edmund.com 用Hadoop—>[ETL]àNetezaaà[SQL]àBI Tool也是成功的例子。 （Teradata 和Netezza都是并行关系型数据库。）

 

从Hadoop拷贝数据到数据仓库里，这个过程像要建造一批同样的楼房，首先要有楼房的建筑图纸，然后根据这个图纸，把一座山丘切分成一块一块规整的建筑石块，然后再把这些石块一批一批运输到建筑工地，一个一个的搭起楼房。首先设计楼房的建筑图纸需要时间，然后切分运输石块需要时间，然后搭楼房也需要时间。设计楼房图纸只需要做一次，而切分石块和盖楼房，则需要天天做。建筑图纸一旦设计好，要改可不容易，因为所有的建好的楼房需要重新盖--这意味着如果用户有新的分析要求，这个过程很难为其作出修改。石块切分运输需也要大量时间，这意味用户不能对实时数据进行分析。

 

一般情况下，负责ETL的和负责数据分析的是两个团队，如果分析师想要改变ETL的过程，是难上加难。所以才有了第二种解决方案，就是在Hadoop上直接支持SQL查询，这样标准的BI工具就可以轻易的在Hadoop上直接运行，这就是Hive所做的事情。 Hive能自动的将SQL翻译成MapReduce所能理解的（用Java写的）Map工作和Reduce工作。这一切好像很完美，可是Hive的运行速度太慢了。即便是运行一个很简单的SQL，Hive也需要30秒至几分钟的时间，这对于需要实时反馈的数据分析师来说是不可忍受的。

 

前两个方案都有令人非常不愉快的缺陷，从根本上是因为MapReduce本来就不是为BI计算来设计的。 BI计算和搜素索引生成有不同特质，1. BI计算要聚合大量数据，其聚合运算的结果集通常要比输入数据集很多，相比之下搜素索引的结果集往往和输入数据集在一个数量级上，都是巨型数据。 2. BI计算需要在几秒或零点几秒之内返回结果，而索引更新由批处理完成就足够了，不需要几秒种之内就完成。MapReduce适合像建立索引这样的批处理任务，而不适合像BI这样的实时任务。

 

要解决MapReduce运行BI速度慢的问题，有两种途径，第一是优化现有的MapReduce计算框架，使其更快；第二是另外建立一套计算框架来取代MapReduce。谷歌在这两个途径上都作出了开拓性的工作，分别开发了Tenzing（2011年公布）和Dremel（2010年公布）再一次为开源业界指明了方向。我将在下一篇博客详细描述。

 

除了沿用SQL做BI的老路径外，Splunk为大数据BI分析提供了新思路。Splunk用更简单的搜素语言（Search query）来取代SQL, 用建立搜素索引来代替建立数据仓库。会用Google Search的人都会用搜素语言，不必单独再学；而创建索引不需要人工设计数据仓库，而且过程简单，不需要ETL那样的人工编程。 Splunk已经成为分析网站日志的利器，而其股票今年一上市就遭到热捧，这表明搜素做为大数据BI一个组成部分，已成为一个不可忽视的潮流。