大数据理解

算起来，接触大数据、和互联网之外的客户谈大数据也有快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使得原有数据仓库需要处理的数据量大增，所以必须花很大代价再次升级原有的数据仓库，否则分析就会跑的比原先还慢。因此，用户依然需要升级价格不菲的上层数据仓库，向原先效率一般的算法妥协性能。

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

1. 沙里淘金和打磨玉石的区别。我举过辣子鸡的例子来形容Hadoop，大致是说一盘辣子鸡就是大数据，Hadoop就是辣子鸡里剔除尖椒，找出能吃的鸡块的方法。其实，大数据的处理就是帮你淘金的过程。以前没有那么合适的“筛子”，所以只能放弃在沙子里淘金的梦想，现在有了合适的“筛子”，就可以去从沙滩上比较高效快速的找出那些“闪光”的东西了。而传统的数据处理方式，其实已经通过人工、半人工的方式，把很多筛捡工作做了。所以虽然丢弃了大量的数据，但是保留下的数据已经是块“璞玉”了，要做的只是对这块“璞玉”再精雕细啄，使其成为价值连成的“美玉”。 所以，用传统的数据处理方法来处理大数据，就是拿美工刀去宰一头牛，即使有人帮你端盘子分部位，还没杀死牛人就累死。
   
   
2. 动车组和火车的区别。分布式的大数据架构，其核心思想和三湾改编时的核心思想是一样的：把支部建到连队中去。把党的有生力量分布到各个战斗单元中，大大提高中央战略的贯彻执行，提高各个战斗单位的机动性和战斗力。就是动车为什么比火车开得快的道理：每节车厢都有动力，虽然每节都不比火车头强劲，但车厢越多就跑的越快。而火车头再强劲，也有拖不动更多车厢的时候。现有的分析算法，很多时候都是针对“火车头”类型的，很多时候没办法拆分成很多小的运算分布到每个节点上。于是，如果沿用之前的算法，那么就必须增加额外的软件方案把已经分布出去了的数据再“集中”起来，额外增加的环节，肯定费时费力，效果不可能会好。

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

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

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

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

困惑之二：不同的大数据方案之间有什么不一样，我该用哪些？

首先，客户必须把前一个问题想清楚，明确自己要做什么事，实现什么功能。然后，我们就可以把这个需求分解成小的需求：

• 要处理几种数据类型？
• 要处理多大的数据量？
• 要处理的多快？ 

这三个要求有比较明确答案之后。这张图表以数据处理的时效性和数据量为两个维度，把传统的RDBMS和Hadoop、MPP、内存数据库等各类大数据方案做分类。这个分类针对的还是各种类别里比较典型的方案。现在实际情况，特别是MPP和Hadoop，各个发行版的特色功能都不尽相同，所以处理的场景也会各有不同方向的延伸。

大数据时代，一种架构包打天下的局面是不大可能出现的。未来的企业大数据整体方案，肯定是多种数据库方案结构并存的。企业数据在各个不同方案架构之间可以联合互通，根据分析场景的不同分析工具运作在不同的数据库架构上。

图片来自 Nomura Research Institute

既然未来企业里面肯定会有多种数据源，多种数据库结构，那么是否可以建立一个中间的数据服务层，把应用和底层数据库架构隔离开呢？就好像你赶着上班，没时间买菜，于是就写个菜单交给钟点工，给他钱让他帮你买。你不用管她到底会去路边菜市场买还是超市买。这个想法看起来很美好，但我觉得在企业里实行的难度比较大，不是很现实。为什么这么说？这里只是说说我的一些看法。

看看对大数据应用最纯熟的互联网，他们的方式就是：简洁，直接。什么样的数据，用哪种方式存储效率最高，处理起来最快就用哪种方式。能直接在文件系统上做的就不放到数据库里。数据的分析也是如此，结构层次越少越好，数据访问越直接越好，能用编程语言直接解决的问题就坚决不采用数据仓库用SQL。该用SQL解决的问题也不去为了统一接口而再去跑一遍Java或Python。一切以高效直接为前提，充分贯彻“把支部建到连队里”的核心思想，发挥小快灵的优势。以Hadoop举例，很多互联网或者发行版都开始尝试放弃Map/Reduce直接对HDFS进行操作处理，其思想就是想更直接，更简洁。所以，前面所述的“建立一个数据服务层”还是传统企业的旧思路老方法，希望通过建立中间层减少开发移植难度，其实结果就是发挥不出大数据架构本身的性能和规模优势，限制住了技术架构本身的发展空间。之所以提这个话题，主要是想引出下一个行业对于大数据的困惑。

困惑之三：我们应该怎样从传统的关系型数据架构向大数据架构迁移。

这个问题，我觉得没有人可以给出完美的答案，因为现在的一些新企业，比如互联网，面对的就是混合数据大数据的环境，不存在迁移的问题。而且他们要处理的数据类型，应用场景也和传统企业不一样，只有一定的借鉴意义，完全复制是不明智的。传统的大型企业，现在国外大多数的企业自己在摸着石头过河，国内企业刚开个头。其实大家都在摸索过程中，前方基本没有指路的明灯，只有一点点星星之火可供参考。

谁能帮你呢？我觉得还是那些搞企业咨询的人士。至少他们可以看到很多国外类似企业的成功或者失败案例。但前提是他们真正站在中立的立场帮你从新的应用场景着手分析规划。

关于这个问题，我也分享个人的观点，仅供参考。

第一步：先把大数据存起来，用起来。现在看过很多传统企业请各类咨询人士做的大数据战略规划，我没资格评价这些规划的可行性和问题所在，但我觉得对于接受新生事物，首先要做的就是先尝个鲜，而不是知道它的未来会怎样。如果小试牛刀的结果不好，那么调整重头再来的成本也比较小。所以我的建议，首先找个方案，把你准备分析处理的数据用新的办法存起来，然后再试着在上面做些简单的查询，比较之类的应用，看看效果好不好，领导买不买单。如果效果好了，那么再试着在这上面实现新的业务应用场景，解决一部分业务人员的某些实际需求；效果好的话再试着做第二个应用，第三个分析。。。。。。慢慢的让越来越多人看到这些新数据新应用的价值。

第二步：考虑新的大数据平台和原有数据平台的互通，联合问题。这里有两个方面： 

1. 把旧的应用分析运行在新的大数据平台上。把数据从原先的RDBMS数据源抽取到新的大数据平台上，利用新的大数据分析方法实现传统的业务分析逻辑。这么做有可能会分析更多的数据产生更好的分析结果，也有可能会发现效率还不如原先的RDBMS方案。
   
   
2. 把大数据平台上的数据抽取到旧有数据仓库中分析展现。这个方向主要还是为了保证旧有用户的SQL使用习惯，区别是抽入旧数据仓库的不是外部表，而是经过清洗整理的有价值的数据。

通过这两个方面的尝试，基本就可以把哪些应用可以迁移，哪些不可以迁移搞清楚了。为下一步打下扎实的基础。 

第三步：数据源整合，分析应用场景定制。 有了前两步的基础，基本你就可以很清楚你能够处理哪些类型的数据，以及他们会为你带来哪些业务价值了。接下来就可以发动“总攻”了。

总攻第一步，就是整合数据源，把将会涉及到的各类型数据分类，用各自最合适的方法储存起来整理好。然后，把应用、展现工具根据所涉及数据源的不同，应用场景的差异，和不同的数据存储架构做耦合，定制化应用场景，使每个应用都可以充分利用到底层架构的性能和扩展能力。对于需要跨数据源的应用场景，选定中间处理层方案，保证中间处理层方案的定制化，不会因其存在影响底层架构的性能和上层分析应用的实现。

这样的步骤，没办法一下子让企业领导看到“未来10年以后的IT架构宏伟蓝图”，但可操作性比较强，而且一步不对修改调整的机会也比较大。这种思路属于互联网和新兴行业那种“小步快跑”的思维模式，先走几步看看，如果不行也有了宝贵的经验教训，花的代价也不算很大。

大致上来说，我所能感受到的，行业用户对于大数据的困惑就是以上所说的三个方面。之所以会有这些困惑，归根结底还是因为大数据的处理方式和以前的传统方式太不同了。

以Hadoop为代表的大数据处理体系，其实是采取了一种粗放的方式处理海量的数据，机器学习的原理很多时候也是依靠大量的样本而不是精确的逻辑。举个例子，我们常说的“清明时节雨纷纷”，根本没有逻辑和科学公式去推导出这个结论。之所以会有这个结论，是无数劳动人民通过多年观察，从“海量的”清明气候样本中发现，每到这几天总是下雨比较多。而为什么清明这几天会下雨，却没有人去仔细分析。大数据的处理方式类似，它依托前人留下的经验，历史数据，归纳总结，而不是去依赖一些复杂的公式演算。其所依仗的，就是“样本”多，而且能够通过技术手段快速高效的分析整理海量的样本。而之前因为没办法处理这么多样本，只能靠先进高精尖的数学模型。所以，想用好大数据，一是要调整思路，尽量用简单的方式去处理大量的数据；二是在某些情况下可能需要考虑通过多采样等方式把数据“变大”。

所以，企业要想用好大数据，在沙海里淘金，就应该大胆的抛弃掉原有的一套成熟的架构和方案。从零开始，真正的去思考这么多数据，这些个新方法对于企业能够有什么意义，产生什么价值。然后，就是把想法一个个在Hadoop，MPP等等架构上实现，落地，一旦发觉有问题了就马上调整，从头再来。而不是先像以前那样看看别的人都怎么做，然后做几十页“看上去很美“的PPT，画一个”未来十年“的美丽的大饼了事。要多向互联网和新兴行业学习，改变思路，挂钩业务，活在当下，小步快跑。