大数据之惑

推荐会员: 点金大数据 所属分类: 行业精选 发布时间: 2015-07-10 00:16

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

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

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

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

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

[转载]大数据之惑

[转载]大数据之惑

    (图片源自:Gatner

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

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

       这里反过头来不妨看看为什么以前传统的数据仓库领域为什么没有这样的困惑。如下这张图很好的说明了传统时代和现在时代的区别:

[转载]大数据之惑

[转载]大数据之惑

片源自: Sogeti

好吧,从上图这个流程可以看出产生这个最大困惑的根本原因其实是:这次我们这帮子苦逼的IT从业人员走在了业务决策者的前面 [流泪] 。传统时代,都是业务人员希望能够得到某类型的统计报表或者分析预测,于是IT行业人员开始为了满足他们的需求找方案写算法从而催生出了各种类型的数据仓库和解决方案。而这次,在互联网的推动下,IT人员居然发觉原来我们可以通过一些新的方式保留存储海量的原先没办法处理的数据信息,但这次,业务人员却完全没有准备好。所以当你告诉他们:嘿,哥们儿,我这里现在又有了很多数据可以帮你了。他们就完全一头雾水不知道这些数据对他们会有什么用了。

       那么,怎么解决这个问题?先来看传统厂商-OracleIBM他们是怎么做的。虽然详细方式略有不同,但他们的思路基本就是如下图所示: (下图源自:http://www.snia.org/sites/default/files2/ABDS2012/MainStage/GregBattas_Hadoop_Relational_Database.pdf)

[转载]大数据之惑

[转载]大数据之惑
 

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

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

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

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

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

     说了这么多,无非是想说明,在我看来,前面所提到的传统厂商解决企业大数据应用困惑的方案不是最好的方案。那么什么是最好的方案呢?其实很简单,就是针对新的数据集市和数据库结构特点开发新的应用分析场景,并且把这些分析应用场景直接跑到大数据架构上。而不是去削足适履,拿新的NewSQLNoSQL去嫁接现有的传统方案。

    这么做,好处就不讲了,前面的描述相信已经讲的挺清楚了。关键是怎么才能这样做?说到底和云一样,这些事不能由我们搞IT的人来告诉业务人员,得让业务人员来告诉我们!大数据应用要真正在企业里面生根开花,在我看来,现在是真的需要一些个数据科学家,咨询人士,去做Demand Generation的工作。我们要通过他们的帮助,使这张图里的大数据路径翻转过来,像传统数据处理一样,由业务人员告诉我们,他们想做什么!       

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

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

      

       谈了那么多,只说了一个困惑,我确实有些唠叨了。不过我觉得这个确实大数据行业应用目前面临的最大问题,然后传统的那些大佬对待这件事上又更多是的从自身,而不是用户的利益去考虑,所以有些看法实在是有些不吐不快的冲动。好了,下面再来看看我所看到的第二个困惑吧。

      困惑之二:不同的大数据方案之间有什么不一样,我该用哪些?这个问题相对来说是实施的问题,比前一个困惑好解决多了。首先,还是客户必须把前一个问题想清楚。很明确自己要做什么事,实现什么功能。然后,我们就可以把这个需求分成几个细一些的需求:

·      要处理几种数据类型?

·      要处理多大的数据量?

·      要处理的多快?

     这三个要求有比较明确答案之后,网上各大专业机构那里就有一大堆资料帮你找到答案了。这里贴张网上找到的图表,我觉得画的挺好的。它以数据处理的时效性和数据量为两个维度,把传统的RDBMSHadoopMPP,内存数据库等各类大数据方案做了一个分类。当然,这个分类针对的还是各种类别里比较典型的方案。现在实际情况,特别是MPPHadoop,各个发行版的特色功能都不尽相同,所以处理的场景也是会各有不同方向的延伸,这里就不一一展开了。总之大数据时代,一种架构包打天下的局面是不大可能出现的。未来的企业大数据整体方案,肯定是多种数据库方案结构并存的。企业数据在各个不同方案架构之间可以联合互通,分析工具依据分析场景的不同运作在不同的数据库架构上面。(下图出处: Nomura Research Institute:http://www.nri.co.jp/opinion/it_solution/2012/pdf/ITSF120409.pdf

[转载]大数据之惑 

    接下来,想和大家探一下一个问题,是由个不同数据方案间选择的困惑引申出来的。既然未来企里面肯定会有多种数据源,多种数据库结些数据,那么是否可以建立一个中的数据服务层,把用和底数据架构隔离开呢?就好像你赶着上班,没时间买菜,于是就写个菜单交给钟点工,钱让他帮你。你不用管她到底会去路场买还是超市买拟或直接找菜农买,你所需要的只是晚上你回家候你要的菜已经按你要求买好洗好摆在厨房里你直接烧就好了。这个想法看起来很美好,但我觉得在企业里实行的难度比较大,不是很现实。为什么这么说?这里只是说说我的一些看法。

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

       

      之所以提这个话题,并且说一下我的看法,主要是想引出下一个行业对于大数据的困惑。

     

      困惑之三:我们应该传统的关系型数据架构向大数据架构迁移。问题,我得没有人可以出完美的答案,因为现在的一些新企,比如互网,上来面的就是混合数据大数据的境,不存在个迁移的问题。而且他理的数据型,景也和传统不一,有一定的借但完全学的架构是不可能的。而传统的大型企在国外大多数的企自己也在摸着石头过河,一步步的走,国内企也就开个。所以其大家都在摸索程中,前方基本没有指路的明灯只有一点点星星之火可供参考。

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

     这里关于这个问题,我也想多分享一下我个人的观点和我脑海中的企业大数据转型的roadmap。仅供参考拍砖,没有挑战任何权威的意思。

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

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

1.     把旧有的应用分析运行在新的大数据平台上。这里牵涉到两个问题把数据从原先的RDBMS数据源抽取到新的大数据平台上,利用新的大数据分析方法实现传统的业务分析逻辑。这么做有可能会分析更多的数据产生更好的分析结果,也有可能会发现效率还不如原先的RDBMS方案,哪种都好至少知道了那些场景用哪类方案更合适。

2.     把大数据平台上的数据抽取到旧有数据仓库中分析展现。这个方向主要还是为了保证旧有用户的SQL使用习惯,区别是被抽取入旧数据仓库的不是什么外部表,而是经过清洗整理的有价值的数据。

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

     第三步:数据源整合,分析应用场景定制。 有了前两步的基础,基本你就可以很清楚你能够处理哪些个类型的数据,以及他们会为你带来哪些业务价值了。接下来你就可以发动“总攻”了。总攻第一步,就是整合数据源,把你将会涉及到的各类型数据分类,用各自最合适的方法储存起来整理好。然后,把你的应用,展现工具根据所涉及数据源的不同,应用场景的差异,和不同的数据存储架构做耦合,定制化应用场景,使每个应用都可以充分利用到底层架构的性能和扩展能力。对于需要跨数据源的应用场景,选定中间处理层方案,保证中间处理层方案的定制化,不会因其存在影响底层架构的性能和上层分析应用的实现。      

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

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

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

    还有一个很好的比喻可以去形容大数据处理和以前传统数据处理方式的不同,就是摄影。传统的数据处理分析就好像是传统的胶片摄影,因为原先胶片珍贵,所以拍照时候对焦曝光各类参数一定要准确,拍完了用什么药水冲印,怎么个冲印方式也要细细想好一步不错才可以保证出一张不错的照片,门槛很高。但数码摄影就不同了,快门基本可以当不要钱的,只要存储卡够大你就各种参数组合随便拍就好了。原先要拍一张好照片很难, 必须找对合适的曝光参数再找对合适的时间方位。现在很简单,只要你不怕烦,存储卡足够大,就各种参数组合各个时间段不同角度去拍好了。拍个千把张回来电脑里一导,肯定找得到一张好的,实在有些问题的还可以自己找PS修修补补就好了。所以,有了数码摄影之后,很多传统的技能已经不太需要了。只要你不怕烦,不断去拍,“积累“足够多样本就可以出好照片了。所以说,数码摄影降低了出好照片的门槛。大数据技术也一样,以Hadoop为代表的NewSQL的出现大大降低了数据分析的门槛,只不过很多人还不习惯,还在用原先的复杂方法罢了。

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

      最后还是那句话,希望有更多的数据服务,行业咨询公司可以真正从最终用户利益出发,一起推动大数据在各行各业的应用,而不是把大数据变成又一个画饼赚钱的工具。

    仅以此文祝愿各行各业的IT劳动者都能真正帮助企业在大数据海洋里淘到黄金,改造业务模式,驾驭大数据,应对新挑战!

来源:http://blog.sina.com.cn/s/blog_ae33b83901019n07.html

关键词:

版权声明:本站原创和会员推荐转载文章,仅供学习交流使用,不会用于任何商业用途,转载本站文章请注明来源、原文链接和作者,否则产生的任何版权纠纷与本站无关,如果有文章侵犯到原作者的权益,请您与我们联系删除或者进行授权,联系邮箱:service@datagold.com.cn。