MapReduce和数据仓库

[Qing]

前端日子，一月中旬，有个比较热闹的争议，是MapReduce跟数据库之争，是由一位数据库理论专家撰写了一篇文章，说MapReduce是一种数据库技术的倒退（http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-back.html ）。如果他否定其他的技术，恐怕也没什么事，但他这次搞错对象了。MapReduce是谁搞得啊？是Google。这下，这位作者可创下大祸，引无数英雄竞耻笑。所有的评论，几乎一边倒地将此位先生批判n遍。

大家有兴趣可以去看看原文和评论，作者抛出MapReduce的五大退步。

他竟然不用sql的方式而用编程语言访问数据库，失败。他的实现很糟糕，失败。他也并不是什么新贵，Teradata用这种技术已经好多年，失败。他缺少很多功能，比如批量装载、事务、参照完整性…失败。他跟数据库管理工具如报表工具，bi工具等都不兼容，失败中的失败。

此文的思维逻辑确实有点奇怪。我对MapReduce不甚了解。他是个关系数据库吗？惹得作者如此批评。就算是个数据库，如果为了特定目的而进行底层技术的革新也未尝不可。至少在数据仓库领域，目的就不同。它主要用于查询，一般来说都是从它里面select groupby，很少有那些事务处理。为了OLAP，完全可以重新设计一种适合多维存储的MOLAP方式，这是一个实实在在的突破关系理论的实证。作者像是一位保守老顽固。呵，我也开始批判他了，不由自主。

好奇害死猫，决定去瞅了一眼MapReduce是个什么东东，有几张幻灯片可以研究一下（http://labs.google.com/papers/mapreduce-osdi04-slides/index.html ）。他的主要目的是为了处理大量的数据进来，数据出去的工作（有点像ETL？），他要用成百上千的CPU来完成这些任务。于是MapReduce提供了一套自动并行和分布式、容错、IO调度和状态监控的框架。哦，听起来不像是数据库。他提供一套机制适合处理海量数据，但对于如何处理这些数据，他不管。咦，他好像用作数据仓库的底层技术蛮合适的。上面那位作者说这个机制没什么希罕，Teradata已经用了。但如果Teradata实在太贵，有些高高在上。所以，如果MapReduce能够被平民化，至少可以让这个市场竞争地更加有趣一些。

如果这种技术可以普及，是不是小企业也可以建立强大的数据仓库，凑一些PC机，改装改装就OK，哈哈，那就好了。

 

有兴趣的可以研究一下。

[supper]

这里也有篇中文的二手文章，我看见英语就头痛，所以还是看看汉字了解下了

http://www.mengyan.org/blog/archives/2006/11/15/138.html

结果还是没怎么搞明白，怎么感觉像分布式的数据压缩似的，跟数据库仿佛一点不沾边

2008/2/2, Qing <happ...@gmail.com>:

前端日子，一月中旬，有个比较热闹的争议，是MapReduce跟数据库之争，是由一位数据库理论专家撰写了一篇文章，说MapReduce是一种数据库技术的倒退（http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-back.html ）。如果他否定其他的技术，恐怕也没什么事，但他这次搞错对象了。MapReduce是谁搞得啊？是Google。这下，这位作者可创下大祸，引无数英雄竞耻笑。所有的评论，几乎一边倒地将此位先生批判n遍。

大家有兴趣可以去看看原文和评论，作者抛出MapReduce的五大退步。

--
The Glory and The Dream,Buried in The Life......

[Qing]

跟数据库确实不怎么沾边，但是跟数据沾边。

 

当初我看到MapReduce的时候，有一个感觉，觉着他的目的非常适合数据仓库的应用——查询。但它不是提供一个数据库工具，而是一套机制。好的架构会将不变的东西从变化的东西里面抽象出来，会将不同功能隔离开。MapReduce是将可以在若干台机器之间同时计算的能力从数据访问逻辑里面抽象出来了。前者是相对不变的，计算不是数据库，也需要这种多机协作的能力，至于你需要选取一条数据，或者汇总一堆数据，那是变化的逻辑。

 

关于MapReduce的详细技术，在supper提供的链接文章里面介绍的比较好。在上次遭人骂的文章中，作者也提到，map就像是group by操作，而reduce就像是聚集函数操作，如求和、平均数等等。但要注意，mapreduce没有给你任何groupby或者sum的具体实现，所有实现都得你自己去完成，编程完成。不过你编程的时候只需要记住它的规矩，专注在数据访问逻辑上，就可以轻而易举享受分布式计算的强大威力。

 

因此，他是一种底层的技术，数据库可以是在它之上的应用，两者相比，就像是tcpip跟http相比一样。

 

但有一点也是显而易见的，它跟数据仓库的差距还远的很呐。要编程，看到这个词估计就能将人吓退三步。这两天，我琢磨此事，想找找有没有什么案例，发现了一个，请看：

http://highscalability.com/how-rackspace-now-uses-mapreduce-and-hadoop-query-terabytes-data

 

原文英文，那些看了英语就头痛的朋友，请看我下面简介一下。不过看完要记住，我可也是忍住头痛为大家谋福利的。

 

这篇文章讲述了一家Rackspace公司的英雄事迹，这是一家主机托管的提供商，其中有个部门叫Mailtrust，是提供邮件服务的。长期受大量的邮件日志所困扰，每天几百个G的日志。最早用文本，然后用mysql数据，都遇到很大问题。于是，花了仨月用了mapreduce的解决方案，结果，腰好腿好身体好，现在可以从各个角度去查看数据，都贼快贼快地啦。

 

他们是怎么做的呢。架构是用开源的Hadoop＋Lucene＋Solr，Hadoop是mapreduce的开源实现，因为后者是google用的，但并非开源。Lucene是文本搜索，Solr不知道干吗的。其中Hadoop、Lucene经常会出现在一起，因为他们现在都在另一个搜索引擎开源项目Nutch中使用，而Hadoop最早就是Nutch的一部分，后来分离出来单独立项。Hadoop后来被yahoo支持的一下（现在可能得算是微软支持了），不过他基本还是个模仿者，而不是开创者。Hadoop实现了google的MapReduce和GFS的文件系统。对这两项技术，google都没有发布自己的源码，只是出了一些论文。而作为开源项目，没有经过太多考验，我相信它现在还不可能有google的那套成熟，虽然基于相同的理论。然而从另一个角度看，毕竟人家也是不断发展的，如今被Mailtrust使用，也就是经历考验。

 

历史课上完，来看看mailtrust怎么用它。这套系统部署在若干台机器上，这些机器都是HDFS文件系统（模仿google文件系统），实时从几百台邮件服务器接受邮件日志，然后分解（应该是Lucene干得事）、建立文本索引（应该事Solr干得事）、然后压缩。分解、建立索引，这个操作就是这个系统的逻辑，他们应该属于Map过程，而且，他们不是一台机器干的，而是好多台机器同时干的。到了晚上，这个系统还会去生成报表，比如那些地区的访问量、垃圾邮件的分布（甚至是分析？）等等。这应该属于Reduce过程。不过我猜想，其实并不是只分这两个过程，而是所有的处理都可以分成这两个基本过程，可以嵌套。不过这是另一个话题，不说这个。

 

案例基本如此，看起来挺让人振奋，但有些东西还是需要思考一下：

1、这个案例只是应用于特定的日志处理、查询、分析，离通用的数据仓库处理还远的很；

2、那些特定的map、reduce处理必定都得是编程完成，那些统计分析也是用开发语言，而不是用分析工具完成的；
3、如果用在电讯行业，如果要用于对交换机的cdr进行分析，倒是可以用这种分布式计算进行分析；

4、也许，未来会有基于mapreduce架构的数据仓库和etl工具，尽量让人使用现在数据库的使用界面，sql、er关系...；

5、这个案例可能包含较大水份，也许是他们信口开河。毕竟，我们写案例经常会这么干。

 

 

2008/2/1 supper <suppe...@gmail.com>:

这里也有篇中文的二手文章，我看见英语就头痛，所以还是看看汉字了解下了

...

结果还是没怎么搞明白，怎么感觉像分布式的数据压缩似的，跟数据库仿佛一点不沾边

[wow.wkcow]

Nutch，或者严格来说mapreduce 在处理非结构化数据的时候 其作用是非常明显的；
但对于结构化数据，数据仓库是目前非常好的方式；

在目前的很多尝试或者应用中，其实是将二者结合来用的，用mapreduce 来存储文本型数据，而用数据仓库来存储结构性数据，这样在etl,
tm, bi 方面就能够实现协调工作了，google 的目前确实是最成熟的，但就目前的观察来看，他们也不是简单的mapreduce

On 2月3日, 下午1时01分, Qing <happys...@gmail.com> wrote:
> 跟数据库确实不怎么沾边，但是跟数据沾边。
>
> 当初我看到MapReduce的时候，有一个感觉，觉着他的目的非常适合数据仓库的应用----查询。但它不是提供一个数据库工具，而是一套机制。好的架构会将不变的东西从变化的东西里面抽象出来，会将不同功能隔离开。MapReduce是将
> *可以在若干台机器之间同时计算的能力*从*数据访问逻辑*

> 里面抽象出来了。前者是相对不变的，计算不是数据库，也需要这种多机协作的能力，至于你需要选取一条数据，或者汇总一堆数据，那是变化的逻辑。
>
> 关于MapReduce的详细技术，在supper提供的链接文章里面介绍的比较好。在上次遭人骂的文章中，作者也提到，map就像是group
> by操作，而reduce就像是聚集函数操作，如求和、平均数等等。但要注意，mapreduce没有给你任何groupby或者sum的具体实现，所有实现都得你自己去完成，编程完成。不过你编程的时候只需要记住它的规矩，专注在数据访问逻辑上，就可以轻而易举享受分布式计算的强大威力。
>
> 因此，他是一种底层的技术，数据库可以是在它之上的应用，两者相比，就像是tcpip跟http相比一样。
>

> 但有一点也是显而易见的，它跟数据仓库的差距还远的很呐。要编程，看到这个词估计就能将人吓退三步。这两天，我琢磨此事，想找找有没有什么案例，发现了一个，请看：http://highscalability.com/how-rackspace-now-uses-mapreduce-and-hadoo...

>
> 原文英文，那些看了英语就头痛的朋友，请看我下面简介一下。不过看完要记住，我可也是忍住头痛为大家谋福利的。
>
> 这篇文章讲述了一家Rackspace公司的英雄事迹，这是一家主机托管的提供商，其中有个部门叫Mailtrust，是提供邮件服务的。长期受大量的邮件日志所困扰，每天几百个G的日志。最早用文本，然后用mysql数据，都遇到很大问题。于是，花了仨月用了mapreduce的解决方案，结果，腰好腿好身体好，现在可以从各个角度去查看数据，都贼快贼快地啦。
>
> 他们是怎么做的呢。架构是用开源的Hadoop＋Lucene＋Solr，Hadoop是mapreduce的开源实现，因为后者是google用的，但并非开源。Lucene是文本搜索，Solr不知道干吗的。其中Hadoop、Lucene经常会出现在一起，因为他们现在都在另一个搜索引擎开源项目Nutch中使用，而Hadoop最早就是Nutch的一部分，后来分离出来单独立项。Hadoop后来被yahoo支持的一下（现在可能得算是微软支持了），不过他基本还是个模仿者，而不是开创者。Hadoop实现了google的MapReduce和GFS的文件系统。对这两项技术，google都没有发布自己的源码，只是出了一些论文。而作为开源项目，没有经过太多考验，我相信它现在还不可能有google的那套成熟，虽然基于相同的理论。然而从另一个角度看，毕竟人家也是不断发展的，如今被Mailtrust使用，也就是经历考验。
>
> 历史课上完，来看看mailtrust怎么用它。这套系统部署在若干台机器上，这些机器都是HDFS文件系统（模仿google文件系统），实时从几百台邮件服务器接受邮件日志，然后分解（应该是Lucene干得事）、建立文本索引（应该事Solr干得事）、然后压缩。分解、建立索引，这个操作就是这个系统的逻辑，他们应该属于Map过程，而且，他们不是一台机器干的，而是好多台机器同时干的。到了晚上，这个系统还会去生成报表，比如那些地区的访问量、垃圾邮件的分布（甚至是分析？）等等。这应该属于Reduce过程。不过我猜想，其实并不是只分这两个过程，而是所有的处理都可以分成这两个基本过程，可以嵌套。不过这是另一个话题，不说这个。
>
> 案例基本如此，看起来挺让人振奋，但有些东西还是需要思考一下：
> 1、这个案例只是应用于特定的日志处理、查询、分析，离通用的数据仓库处理还远的很；
> 2、那些特定的map、reduce处理必定都得是编程完成，那些统计分析也是用开发语言，而不是用分析工具完成的；
> 3、如果用在电讯行业，如果要用于对交换机的cdr进行分析，倒是可以用这种分布式计算进行分析；
> 4、也许，未来会有基于mapreduce架构的数据仓库和etl工具，尽量让人使用现在数据库的使用界面，sql、er关系...；
> 5、这个案例可能包含较大水份，也许是他们信口开河。毕竟，我们写案例经常会这么干。
>

> 2008/2/1 supper <suppere...@gmail.com>:

[hunter]

看大虾们的介绍好像觉得太基础了。。就像tcp/ip没有多少人需要掌握一样。。。

On Feb 3, 8:48 am, "wow.wkcow" <wow.wk...@gmail.com> wrote:
> Nutch，或者严格来说mapreduce 在处理非结构化数据的时候 其作用是非常明显的；
> 但对于结构化数据，数据仓库是目前非常好的方式；
>
> 在目前的很多尝试或者应用中，其实是将二者结合来用的，用mapreduce 来存储文本型数据，而用数据仓库来存储结构性数据，这样在etl,
> tm, bi 方面就能够实现协调工作了，google 的目前确实是最成熟的，但就目前的观察来看，他们也不是简单的mapreduce
>
> On 2月3日, 下午1时01分, Qing <happys...@gmail.com> wrote:
>
>
>
> > 跟数据库确实不怎么沾边，但是跟数据沾边。
>

> > 当初我看到MapReduce的时候，有一个感觉，觉着他的目的非常适合数据仓库的应用----查询。但它不是提供一个数据库工具，而是一套机制。好的架构会将-不变的东西从变化的东西里面抽象出来，会将不同功能隔离开。MapReduce是将

> > *可以在若干台机器之间同时计算的能力*从*数据访问逻辑*
> > 里面抽象出来了。前者是相对不变的，计算不是数据库，也需要这种多机协作的能力，至于你需要选取一条数据，或者汇总一堆数据，那是变化的逻辑。
>
> > 关于MapReduce的详细技术，在supper提供的链接文章里面介绍的比较好。在上次遭人骂的文章中，作者也提到，map就像是group

> > by操作，而reduce就像是聚集函数操作，如求和、平均数等等。但要注意，mapreduce没有给你任何groupby或者sum的具体实现，所有实现都-得你自己去完成，编程完成。不过你编程的时候只需要记住它的规矩，专注在数据访问逻辑上，就可以轻而易举享受分布式计算的强大威力。

>
> > 因此，他是一种底层的技术，数据库可以是在它之上的应用，两者相比，就像是tcpip跟http相比一样。
>

> > 但有一点也是显而易见的，它跟数据仓库的差距还远的很呐。要编程，看到这个词估计就能将人吓退三步。这两天，我琢磨此事，想找找有没有什么案例，发现了一个，请-看：http://highscalability.com/how-rackspace-now-uses-mapreduce-and-hadoo...

>
> > 原文英文，那些看了英语就头痛的朋友，请看我下面简介一下。不过看完要记住，我可也是忍住头痛为大家谋福利的。
>

> > 这篇文章讲述了一家Rackspace公司的英雄事迹，这是一家主机托管的提供商，其中有个部门叫Mailtrust，是提供邮件服务的。长期受大量的邮件日志-所困扰，每天几百个G的日志。最早用文本，然后用mysql数据，都遇到很大问题。于是，花了仨月用了mapreduce的解决方案，结果，腰好腿好身体好，现-在可以从各个角度去查看数据，都贼快贼快地啦。
>
> > 他们是怎么做的呢。架构是用开源的Hadoop＋Lucene＋Solr，Hadoop是mapreduce的开源实现，因为后者是google用的，但并非开-源。Lucene是文本搜索，Solr不知道干吗的。其中Hadoop、Lucene经常会出现在一起，因为他们现在都在另一个搜索引擎开源项目Nutch中使-用，而Hadoop最早就是Nutch的一部分，后来分离出来单独立项。Hadoop后来被yahoo支持的一下（现在可能得算是微软支持了），不过他基本还是-个模仿者，而不是开创者。Hadoop实现了google的MapReduce和GFS的文件系统。对这两项技术，google都没有发布自己的源码，只是出了-一些论文。而作为开源项目，没有经过太多考验，我相信它现在还不可能有google的那套成熟，虽然基于相同的理论。然而从另一个角度看，毕竟人家也是不断发展-的，如今被Mailtrust使用，也就是经历考验。
>
> > 历史课上完，来看看mailtrust怎么用它。这套系统部署在若干台机器上，这些机器都是HDFS文件系统（模仿google文件系统），实时从几百台邮件服-务器接受邮件日志，然后分解（应该是Lucene干得事）、建立文本索引（应该事Solr干得事）、然后压缩。分解、建立索引，这个操作就是这个系统的逻辑，他-们应该属于Map过程，而且，他们不是一台机器干的，而是好多台机器同时干的。到了晚上，这个系统还会去生成报表，比如那些地区的访问量、垃圾邮件的分布（甚至-是分析？）等等。这应该属于Reduce过程。不过我猜想，其实并不是只分这两个过程，而是所有的处理都可以分成这两个基本过程，可以嵌套。不过这是另一个话题-，不说这个。

>
> > 案例基本如此，看起来挺让人振奋，但有些东西还是需要思考一下：
> > 1、这个案例只是应用于特定的日志处理、查询、分析，离通用的数据仓库处理还远的很；
> > 2、那些特定的map、reduce处理必定都得是编程完成，那些统计分析也是用开发语言，而不是用分析工具完成的；
> > 3、如果用在电讯行业，如果要用于对交换机的cdr进行分析，倒是可以用这种分布式计算进行分析；
> > 4、也许，未来会有基于mapreduce架构的数据仓库和etl工具，尽量让人使用现在数据库的使用界面，sql、er关系...；
> > 5、这个案例可能包含较大水份，也许是他们信口开河。毕竟，我们写案例经常会这么干。
>
> > 2008/2/1 supper <suppere...@gmail.com>:
>
> > > 这里也有篇中文的二手文章，我看见英语就头痛，所以还是看看汉字了解下了
> > > ...

> > > 结果还是没怎么搞明白，怎么感觉像分布式的数据压缩似的，跟数据库仿佛一点不沾边- Hide quoted text -
>
> - Show quoted text -