大数据不单单只是Hadoop

这段时间接触大数据相关项目比较多，自然有些体会和感触。感觉到自己之前对于这个领域的认识并不全面，甚至有点盲目，然后在具体项目或者概念认证阶段走了不少弯路。但好在在这些项目过程中认识接触了不少合作伙伴的兄弟姐妹们，从他们那里学到了不少东西。现在试着把这些心得整理下分享给大家，希望对于各位对大数据感兴趣的童鞋们有点帮助吧。这篇PPT主要有两个部分：一个部分是讲大数据应用场景以及和传统方案的区别等等，还有一个部分是介绍国内大数据一些解决方案提供商和一些实际应用案例的。这里只贴出第一部分，希望能够帮大家理清些大数据的概念性问题。

上图中，精确数据是指每条数据都有着准确的含义和确定的价值，表达很明确的信息。比如，制造业的一条生产记录。传统关系型数据库以处理这类数据。并基于此类数据通过复杂逻辑分析推演出业务价值为强项。

大数据时代数据的特点是大量模糊数据。单条数据没有确定的价值和明确的含义。比如，一个网页的点击记录。Hadoop的优势是能对海量模糊数据进行汇总排序比对等操作，把他们变成有意义的数据，再通过海量的样本比对等方式归纳产生业务价值。

所以，从本质上说这是两种针对不同场景不同对象的不同技术。如果要采用Hadoop去取代RISC架构的数据库，BI应用。那么必须打破原来企业经典的沿用几十年的数据结构，重新定义数据模型，表结构等等。还是我以前提过的，就是要重新从头练另一门武功。但那样下来效率是否一定就会比以前高，效果是否一定比以前好，从我几个项目试验的结果来看也并不乐观。

但是，在某些情况下大数据技术也能比RISC架构更好的解决一些传统的结构化数据问题，比如ETL。在一些行业里，ETL工作往往需要一个很长的处理流程。利用Map/Reduce技术可以大大缩短ETL的工作流程，提高效率，而且随着数据量的不断增长，这种优势会越来越明显。所以说，是否用Hadoop去尝试替代原先的RISC架构，关键还是看数据量是否够大以及数据类型是否多样化。

以上这张图取自BI Reasrch。以数据查询的延迟性需求为纵轴，数据量和结构化程度为横轴列出了Hadoop技术和传统关系型即RDBMS的应用场景区别。Hadoop之所以会出现其实就是为了应付海量的非结构化数据的离线分析的。所以其应用场景也基本是以此类为强项，即数据量大，结构化程度低，分析的实时性要求不高。当然随着其技术的发展，外沿通过不同组件如Hive的补充有所拓展。但要其完全取代原先的RDBMS基本是不可能的事情。

正如第一张图所说，大数据时代，没有一种方案是可以包打天下的。企业内部未来也必将是多种方案并存来处理各类不同类型数据的环境。下面试着将目前数据库的几类应用场景分分类，同时列出了每一类国内外的一些解决方案名字。国外的方案我为了简单起见，只列出特性比较鲜明的。没有写Exadata是因为它有点属于混合方案，把它简单定位在一个领域有点不太合适。而且国内可以和它具备相同类型的方案也没有，就先不提了。改天有空我再整理下我对于Exadata的一些粗浅认识给大家来喷一下。 关于国内方案，我列出的是仅限于我知道的或是合作过的方案提供商，当然还有很多遗漏的。当然也有些我认为特色不鲜明没有什么核心技术的也就不提了。这里只列出他们的名字和专注领域类型，详细的一些介绍就不在这里贴出来了，反正他们都可以在新浪微博里找到，呵呵。

当然，上图所列出的场景所针对的解决方案也不是唯一的。一些场景是多个方案都可以胜任的。

　　比如Mongo DB也可以做MAP/Reduce的工作。Hive能够为Hadoop体系提供SQL的接口等等

最后，再谈一下我对国内大数据解决方案提供商的一些总体感觉。当然，还是那句话，这些观点只是在我接触过的几个方案中得出的，并不代表国内总体的情况，我没有这么多的精力去了解，也没有这个能力。这些感觉仅供参考。

关于适宜客户群，我上面说的也只是我个人的一些建议。我觉得，这些国内解决方案的供应商，需要通过一些实际企业应用案例实施的磨练，以及一些合作伙伴的帮助，才能真正走向成熟，走向商用，去挑战那些国外的知名产品。我觉得从目前来看，技术不是问题，路线方向也没有什么错误。关键是对自身的规划和技术走向商用，走向产品化流程化的运作能力。我也真心希望国内的那些大企业大公司能够给国内的这些有技术有想法的方案提供商一些机会，让他们能够积累经验，成长壮大。

声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。