有人问起，为什么我公司选用DBMS(MySQL)来做资料分析，而不用 Hadoop。在这边，我把跟公司的DB怪才同事的讨论结果，稍为简单叙述一下。首先，要先理解到的一点是，在 MapReduce 及 Hadoop 出现之前，Data Mining的工具及技术，已经在DBMS上建构了有30年了，相关的技术也发产的很成熟且有许多专书论述。

ETL(Extract, Transform, Load)是这个领域的关键字，用 ETL 去找下去，会找到许多的书籍讲怎么做资料分析

Extract: 如何在杂乱的原始资料中，找出有用的讯号，并把这些讯号归档

例如：把 Apache 的 access.log 转换成一对对的 (timestamp, session)

Transform: 如何把整理好的讯号，转换成更好用的中介查询表格

例如：把前面的 (timestamp, session) 转换成以小时为单位的存取次数 (time-slice, count)

Load: 把整理好的资料，存到数据库中。 

透过这个转换过的Fact Table，我们可以把很昂贵的『每日访问总数查寻』从 

# pseudo code 应该是错的，不过你知道我在表达什么就好了 :P

SELECT COUNT(UNIQUE session) FROM http_access
  GROUP BY DATE_FORMAT(timestamp,'%Y %m %d')

变成

SELECT SUM(count) FROM access_counts
  GROUP BY DATE_FORMAT(time_slice,'%Y %m %d')

    假设，你的原始资料有一整年这么多，总共有四千万笔(40M)，那么，前者就是把四千万笔的资料读出来，然后过滤加总，而后者，由于资料汇入时已先处理过了，所以要处理的只有24 *365笔资料；而这两者间所花费的时间差易，会随着查寻次数而产生重大差异。  

试问，若是每次你老板跟你要资料时，你要跟他说，要等半小时才可以，还是说等我五分钟？ 至于前面的半小时是怎么算出来的呢？

由于DB运算，瓶颈多是卡在硬盘存取上，在前面的例子中，40M笔资料，假设一笔是1K bytes，那么，总资料量是 40GB ，从硬盘循序读取 40GB 出来，所花的时间是 40GB / 40MB/s(硬盘速度) = 17分钟 

MapReduce & DBMS  

    MapReduce是把资料分拆运算，然后再加总的技术；但是，MapReduce的概念对 RDBMS 并不是什么新奇的事，在这份IBM的文件中，便清楚的叙述到，DBMS会对 SQL 指令做编译，DBMS内部就会依资料型态、INDEX档、CPU Core的数量等，去做最佳化，这些，是Hadoop不会帮你做的。 

既然DBMS那么好那么，为什么会有 MapReduce 等技术的出现呢，那是因为，DBMS可以帮你scale up，但是最终，还是会碰上硬件的极限，那么，这时只有 scale out ，才能解决这问题。 但是 scale out 的程序难度，总是比 scale up 困难，而且，一个不好的分析模式，并不会因为跑的快10倍，就变得比较好；因此， ETL 的概念，在使用 MapReduce 时仍是可以应用的。

讲到这边，什么时候该用 Hadoop ，什么时候该选用 DBMS ，应该很清楚了

1.首先，就是要先看你要找的分析讯号是什么，定好分析的步骤及查询表格

2.再来，看你的资料量会有多大，做些简单的计算，看看是不是能在合理的时间内跑完

3.最后，看你这些报表倒底是有多常被取用，若是，这是内部的报表，只要一个月能出一次就好，那么，Hadoop可能就大才小用；若是，你是要做产品，像Google Analytics做到实时大量分析，那么你可能就需要用到Hadoop

赞赞赞