最近一段时间一直在从事和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)。
按默认排序 显示最新评论 共有4个评论 (最后回答: 2年前)
-
DEC_LIU3年前
我有个疑问:当我们的数据要求实时性很高,而且数据量比较大的情况,那应该采取怎样的方案处理呢?
目前我个人采用的内存方式实现的,但是随着数据量的不断增加,内存可能还是不行。
-
江舟3年前
我说第一眼看这个帖子这么面熟,仔细一看,原来是别人转载到这里了。
高实时的海量数据查询确实是个问题,我目前也面临这个问题,对于这个问题我有以下考虑:
1、根据业务需求对高实时响应查询的数据进行分类的存储,尽最大可能减少查询的范围。
2、是否可以对数据做预处理,在海量数据中提炼出来实际可要的数据,做数据准备。
3、采用HBase来解决查询的问题。(入库速率和稳定性是个挑战)
总的说来,1和2都是通过对数据范围的缩减来提升查询速度。3则是利用HBase来解决问题。
-
小神仙2年前额 方法多的很,搜索嘛直接用其他分布式搜索引擎
-
xiamin...2年前
b、我最早也想过完全替换RDBMS,对于实时的查询我想采用hbase,但是在一段时间之后我发现hbase对一些查询支持的并不好。这里专门提出来也是希望大家能够给我解疑答惑,对于hbase如何应用是合适的?或者说在这个模型中是否还有hbase的位置?
hbase是kv类型的查询,同时不支持跨行事物,存取其他的字段由应用程序来控制,其实对于互联网处于对索引使用方面考虑,其实很多sql都是kv类型。所以应该不是大问题。hbase的hql是非常简单和弱模式的模型。hbase完全替换关系型数据库需要时间,通过修改应用程序现在就可以实用hbase