大数据分析:找合适的瓶,酿新的酒

为什么谈到大数据，传统企业表现出更多的困惑?其原因是，企业决策者并不清楚大数据能给业务带来哪些价值，也不知道如何学习、使用大数据分析工具。而这些大数据工具就摆在那里，谁能先一步学习使用，谁就占有先机。

算起来，接触大数据、和互联网之外的客户谈大数据也有快2年了。也该是时候整理下一些感受，和大家分享下我看到的国内大数据应用的一些困惑了。

云和大数据，应该是近几年IT炒的最热的两个话题了。在我看来，这两者之间的不同就是：云是做新的瓶，装旧的酒; 大数据是找合适的瓶，酿新的酒。

云说到底是一种基础架构的革命。原先用物理服务器的应用，在云中变成以各种虚拟服务器的形式交付出去，从而计算、存储、网络资源都能被更有效率的利用了。于是，酒量好无酒不欢的人就可以用个海碗牛饮二锅头;酒量小又想尝尝微醺小醉风情的人也可以端个小杯咂巴咂巴女儿红。

大数据的不同在于，它其实是把以前人们丢弃不理的数据都捡起来，加以重新分析利用，使之产生新价值的技术。换句话说，原先20斤的粮食只能出2斤的 酒糟，现在20斤的粮食都变成或者大部分变成酒糟。当然这酒糟肯定会和原先的酒糟有不一样，所以酿出来的酒肯定和以前不同，喝酒、装酒、储存酒的方法自然 也不同。

所以，相对于云，人们对大数据使用的困惑更大。接下来谈谈我所看到的几类最多的困惑，以及我们目前存在哪些问题。

困惑之一：大数据能干什么?

换用前面饮酒来作比方，这新酿出来的酒怎么喝才可以喝得痛快。这里不再想讨论到底哪些数据是大数据了。 下面这张图是Gartner 对各行业对于大数据需求的调查，该统计针对大数据通用的3个V ， 以及未被利用数据的需求情况做了分类。 可见几乎所有行业都对大数据有着各种各样的需求。

图片来自Gartner

为什么有这些需求，是因为以前这些类型的数据都因为技术和成本的原因，用户没有收集处理。现在有了性价比合理的手段可以让你收集处理这些数据，怎么 可能说不要?还是以酿酒做比喻，以前酿两斤酒糟要浪费18斤的粮食，现在至少20斤粮食可以有10斤都变成酒糟了，虽然这些酒糟可能和以前不大一样，但至 少可以少浪费8斤粮食呢。

现在问题来了，酒糟多了，种类不一样了,怎么根据新的酒糟酿酒呢?对不起，这个问题酒作坊就要别人来教了。但问题是，所有酒坊现在可能都面临这同一 个问题，于是就没人可以教你了，只能自己慢慢摸索。这个就是现在各行业面对大数据的最大困惑 — 海量的数据收集上来不知道怎么用。

这里不妨看看为什么传统的数据仓库领域没有这样的困惑。如下这张图很好的说明了传统和现在的区别：

图片来自Sogeti

从上图展示的流程可以看出产生困惑的根本原因是：苦逼的IT从业人员走在了业务决策者的前面 (流泪) 。传统时代，都是业务人员希望得到某类型的统计报表或者分析预测，于是IT行业人员为了满足他们的需求找方案、写算法，从而催生出了各种类型的数据仓库和 解决方案。而现在，在互联网的推动下，IT人员发觉原来我们可以通过一些新的方式存储海量的原先无法处理的数据，但业务人员却没有准备好。所以，当你告诉 他们：“嘿，哥们儿，我这里现在又有了很多数据可以帮你了。”他们一头雾水不知道这些数据对他们有什么用了。

怎么解决这个问题?先来看传统厂商Oracle、IBM他们是怎么做的。方式细节略有不同，但他们的思路基本如下：

图片来自HP首席技术专家 Greg Battas在ABDS2012大会上的 分享

简单来说，这种处理方式是把Hadoop和其它各类NewSQL、NoSQL方案以ETL，或外部表的方式引入现有的数据分析解决方案架构中。这种 方案因为上层的数据仓库没有大的改变，客户可以继续使用原先的算法和报表结构，即在新的数据平台上继续沿用旧的应用场景和分析方法。好处是由于引入了大数 据技术，可以处理多种数据源，同时降低原先海量数据ETL的成本。但这种方法依然存在不少问题：

问题一：性能瓶颈依然存在。

纵观现在各类NewSQL、NoSQL方案，分布式是一个最显著的特色。之所以大家 都采用分布式架构，就是因为传统的纵向扩展方案，在处理海量数据时候性能没法随着数据量的增长而线性扩展，或者成本代价太高。而上图的方案，虽然通过 Hadoop解决了ETL的性能瓶颈问题，但BI还是传统的数据仓库，海量的ETL使得原有数据仓库需要处理的数据量大增，所以必须花很大代价再次升级原 有的数据仓库，否则分析就会跑的比原先还慢。因此，用户依然需要升级价格不菲的上层数据仓库，向原先效率一般的算法妥协性能。

问题二：大数据投资被浪费。

旧的分析应用场景，算法是基于关系型数据库的。和大数据方案的逻辑模式有很大的不同，这不同主要有两类。

沙里淘金和打磨玉石的区别。我举过辣子鸡的例子来形容Hadoop，大致是说一盘辣子鸡就是大数据，Hadoop就是辣子鸡里剔除尖椒，找出能吃的 鸡块的方法。其实，大数据的处理就是帮你淘金的过程。以前没有那么合适的“筛子”，所以只能放弃在沙子里淘金的梦想，现在有了合适的“筛子”，就可以去从 沙滩上比较高效快速的找出那些“闪光”的东西了。而传统的数据处理方式，其实已经通过人工、半人工的方式，把很多筛捡工作做了。所以虽然丢弃了大量的数 据，但是保留下的数据已经是块“璞玉”了，要做的只是对这块“璞玉”再精雕细啄，使其成为价值连成的“美玉”。 所以，用传统的数据处理方法来处理大数据，就是拿美工刀去宰一头牛，即使有人帮你端盘子分部位，还没杀死牛人就累死。

动车组和火车的区别。分布式的大数据架构，其核心思想和三湾改编时的核心思想是一样的：把支部建到连队中去。把党的有生力量分布到各个战斗单元中， 大大提高中央战略的贯彻执行，提高各个战斗单位的机动性和战斗力。就是动车为什么比火车开得快的道理：每节车厢都有动力，虽然每节都不比火车头强劲，但车 厢越多就跑的越快。而火车头再强劲，也有拖不动更多车厢的时候。现有的分析算法，很多时候都是针对“火车头”类型的，很多时候没办法拆分成很多小的运算分 布到每个节点上。于是，如果沿用之前的算法，那么就必须增加额外的软件方案把已经分布出去了的数据再“集中”起来，额外增加的环节，肯定费时费力，效果不 可能会好。

在我看来，前面提到的传统厂商解决企业大数据应用困惑的方案不是最好的方案。什么是最好的方案呢?其实很简单，就是针对新的数据集和数据库结构特点 开发新的应用分析场景，并把这些分析应用场景直接跑到大数据架构上。而不是去削足适履，拿新的NewSQL、NoSQL嫁接传统方案。

这么做的好处不言而喻，关键是如何实现?这些事不能由搞IT的人来告诉业务人员，得让业务人员来告诉我们!大数据应用要真正在企业里生根开花，真的 需要一些数据科学家做需求生成(Demand Generation)的工作。我们要通过他们的帮助，使这张图里的大数据路径翻转过来，像传统数据处理一样，由业务人员告诉我们，他们想做什么!

我接触过很多客户，去之前得到的需求都是：希望了解Hadoop或者内存数据库。但是去了之后都发觉，他们其实不知道Hadoop或者内存数据库可 以帮他们达到哪些目的，希望我们可以告诉他们。但很坦率的说，这个不是我们这些搞IT基础架构的人该做的事情。我们已经“超前”的储备好了这类技术手段 了，怎么用这类技术真的是应该懂业务的人去想，而不是我们了。

所以，在这里我想呼吁IT行业里，处在金字塔顶的专业咨询师、数据分析人员、数据科学家们，现在是时候走出原先的框架看看新技术新架构下有些新商机 了。不要总是桎梏于传统的思路和方法，让新的大数据思想来做“削足适履”的事情了。真心希望你们可以利用专业知识和行业经验，帮着那些”求大数据若渴“的 行业用户们好好定位下对他们真正有价值的新应用场景，设计更多的有意义的分布式算法和机器学习模型，真正帮助他们解决大数据应用之惑。