最近一段时间一直在从事和hadoop相关的工作，主要是技术内容学习、安装配置优化以及一些框架结构的设计。在此期间，我对于RDBMS和Hadoop的结合应用有了一些自己的看法，写出来大家共同探讨一下。
1、为什么要用Hadoop
这个在网上已近有很多的人说过这个问题，我在这里就不多述了。但是我想说下，对于一个工具而言，只有最合适的应用场景没有最牛的工具。hadoop对我而言也只是一个工具，所以，更多的时候我是从业务角度出发去考虑hadoop能给我带来什么。
2、RDBMS？
RDBMS是关系型数据库英文缩写，但对于我而言，就是oracle（因为我现在的公司用就是）。关于RDBMS和NOSQL谁更好这个话题争论的太多了，我也看了不少。但是我个人的感觉是，当前的RDBMS做的工作想用Hadoop来替代，基本是不可能，二者只能是互补互助，才能和谐共进（构建和谐社会，哈哈）。
3、数据仓库和数据库
就我个人的理解，数据仓库更倾向于数据的挖掘和分析，对实时性要求较低。而数据库则是对实时性响应较高，做为数据挖掘而言，虽然就目前当前看来是可以胜任，但是一旦数据量庞大（TB级别数据甚至PB级别），直接结果将是数据检索速度急剧下降，一些oracle执行的的挖掘job都有可能跑不出结果。所以，这也是为什么我在思考如何将hadoop和RDBMS结合应用的原因。废话不多说了，自己画了个草图大家先看看：
4、总体思想
由于工作环境和工作内容的特殊性，我这里并不涉及到大并发访问，所以，只要满足实时性的查询和数据挖掘即可。基于上图，我的总体思想如下：
a、将数据源在输入的时候就对数据进行拆分，一些侧重于数据分析和对实施响应要求较低的数据文件划分为“低实时性数据”。将一些相应速度要求较高的数据文件划分为“高实时性数据”。当然，这样划分可能数据之间可能会有交集，也就是说存在数据重复存放的可能性，所以，划分的具体原则需要结合业务详细制定。
b、“低实时性数据”存入HDFS文件系统，采用M/R或是Hive来进行一些挖掘的工作。而“高实时性数据”则存放在传统的RDBMS中，用以响应用户的实时查询需求。
c、Hadoop挖掘的数据结果可以协商好的格式存放到RDBMS中，提供为数据分析的基础。实际上，可以理解是Hadoop对数据内容进行的预处理，RDBMS则是在该结果的基础上进行高级功能（分析、比对、数据碰撞等）内容展示和二次分析。
d、用户也可直接的发送指令给Hadoop，进行一些特殊的数据挖掘工作，结果不需要存放到RDBMS中，直接反馈到用户web界面。（图上没表现出来）
5、总结
a、当前这样的应用模型可能会带来一些冗余数据，但是至少缓解了一些当前RDBMS的压力。
b、我最早也想过完全替换RDBMS，对于实时的查询我想采用hbase，但是在一段时间之后我发现hbase对一些查询支持的并不好。这里专门提出来也是希望大家能够给我解疑答惑，对于hbase如何应用是合适的？或者说在这个模型中是否还有hbase的位置？
b、上面说的内容都是基于我当前的工作环境来论述，大家如果觉得有疑问可以给我留言或发邮件(dajuezhao@gmail.com)。
Hadoop按默认排序 显示最新评论 共有4个评论 (最后回答: 2年前)
-
我有个疑问：当我们的数据要求实时性很高，而且数据量比较大的情况，那应该采取怎样的方案处理呢？
目前我个人采用的内存方式实现的，但是随着数据量的不断增加，内存可能还是不行。
-
我说第一眼看这个帖子这么面熟，仔细一看，原来是别人转载到这里了。
高实时的海量数据查询确实是个问题，我目前也面临这个问题，对于这个问题我有以下考虑：
1、根据业务需求对高实时响应查询的数据进行分类的存储，尽最大可能减少查询的范围。
2、是否可以对数据做预处理，在海量数据中提炼出来实际可要的数据，做数据准备。
3、采用HBase来解决查询的问题。（入库速率和稳定性是个挑战）
总的说来，1和2都是通过对数据范围的缩减来提升查询速度。3则是利用HBase来解决问题。
-
额 方法多的很，搜索嘛直接用其他分布式搜索引擎
-
b、我最早也想过完全替换RDBMS，对于实时的查询我想采用hbase，但是在一段时间之后我发现hbase对一些查询支持的并不好。这里专门提出来也是希望大家能够给我解疑答惑，对于hbase如何应用是合适的？或者说在这个模型中是否还有hbase的位置？
hbase是kv类型的查询，同时不支持跨行事物，存取其他的字段由应用程序来控制，其实对于互联网处于对索引使用方面考虑，其实很多sql都是kv类型。所以应该不是大问题。hbase的hql是非常简单和弱模式的模型。hbase完全替换关系型数据库需要时间，通过修改应用程序现在就可以实用hbase
