转载“Hadoop 和DBMS 的互补性”
随着Microsoft 也加入Hadoop 阵营，Hadoop 已经完全变成了DBMS 的好朋友了 , 2年之前的SIGMOD组织提出的“A Comparison of Approaches to Large-Scale Data Analysis”引发了关于并行数据库和MapReduce模型的讨论， 双方唇枪舌剑之后发现两个系统根本就是各有所长, DBMS 目前有些处理好的领域和商业支持，Hadoop 也有自己的优势和使用案例.
就如前一篇TDWI 所说的3个V 问题，新一代Hadoop MapReduce 主要解决的是数据容量和多种类型的数据（结构化，半结构化，非结构化）. 而传统的MPP DBMS 解决的主要还是速度，低延迟，实时性的问题.
| DBMS | Hadoop |
| 低延迟，一般响应时间为秒 | 高延迟，一般响应时间最少为分钟 |
| 较高的吞吐(同一时间执行sql数) | 可以提交很多任务，但不一定快速执行. |
| 处理的数据量有限制（目前为P) | 可以处理大量的数据(从10p到1E） |
| 硬件有特殊需要，不能随时添加 | 硬件可随时添加，增加计算能力 |
| 假设机器是随时可用的，不对失败做处理 | 默认机器故障时正常的，可以容忍机器失效并用其它迅速机器替代 |
| 数据库模式过渡优化 | 对数据格式没有限制 |
| 数据满足完整性（外键） | 用户程序需要自己验证完整性 |
| 必须提前知道使用模式并进行优化 或者根据使用一段时间之后的情况进行特定优化 |
面对未知的使用模式，常规使用模式可以做一定程度的优化. |
| 需要添加额外的优化计算（索引，分区等） | 大部分情况不用额外优化 |
| CPU,内存，磁盘，网络利用率较为高效 | 资源利用率不算高效，人为优化需要较多技巧，目前没有DBMS 优化技术成熟 |
| 储存能力有限, 磁盘不能随意扩展 | 储存能力极高，随时可以按需扩展 |
| 磁盘比较昂贵，经常访问的数据可使用高端SSD | 廉价磁盘，随意保存多份数据防止丢失 |
| 线型扩展能力一般, 一般到几百台机器有瓶颈 | 极高的线型扩展能力，目前yahoo 的为4000台，下一代Hadoop 目标6000 – 10000台 |
| 不具备开放性，必须数据库厂商提供功能 | 高端开放性，大多数组织参与合作 |
| 分析能力需要默认提供 | 可以自己编写UDF 函数，随时扩展功能. |
| 不太适合用来保存过多的历史数据 | 可以保存任意多的历史数据，随时可以访问. |
| 不能处理半结构化或非结构化的数据 | 可以处理XML，图片，音频视频等任意格式数据 |
| 有厂商在数据库内提供MapReduce功能 （Aster Data 和Greenplum） |
有厂商希望在Hadoop 内添加MPP DBMS 的特性降低延迟提高吞吐能力(Hadapt , MapR) |
| 可以随时装载最新数据并查询和分析 | 一般都是批量处理 , 需要特定的技术才能进行实时或叫准实时的计算 |
| 实施费用较为昂贵 | 免费开源 |
| 人员培训较为简单，拥有成熟的人才市场 | 需要IT 人员拥有较高的技能，而且培训较少. |
目前DBMS 还是在其关系型领域拥有绝对的竞争力, 适合多种不同的功能需要.
Hadoop 目前还是主要以廉价的解决方案，活跃的社区，储存能力和非结构化数据的处理见长.
目前有名的数据仓库提供商都开始在自己的产品线里面提供直接的Hadoop 集成，帮助用户选择合适的技术做合适的事情.
一些比较成功的数据仓库使用者都会同时使用DBMS 和Hadoop , 比如Ebay, Walmart, Yahoo, LinkedIn等
一些特殊的行业也会完全使用Hadoop 做其数据仓库的完整解决方案. 比如Facebook , Twitter .
Microsoft 加入Hadoop 估计也就是提供一下Windows 的便捷开发的然后骗骗用户“我们有大规模计算的能力了”，估计真要在Windows 服务器上跑Hadoop 效果可想而知.
参考资料
争论之后的A Comparison of Approaches to Large-Scale Data Analysis
http://database.cs.brown.edu/projects/mapreduce-vs-dbms/
