沈MM再聊大数据

自从去年上半年做了一个涉及大数据的项目，就被认为是部门里的大数据第一人，其实万不敢当。在此之前所在部门的确对这方面毫无涉足，我们是部门内的先行者。但要说有多么了解大数据，其实也很汗颜，认真一点说，我们是想借助这个项目去大数据的海洋里试驾远航，可事实是我们赶在被真正的大数据的海浪打翻之前就已经回到岸边。

也正因这个项目，令我们开拓了视野，自从转型到技术开发，从曾经只顾得上埋头啃传输协议，到终有机会抬头看看虚拟化，捣鼓云计算，再涉足大数据，借助技术开发部各种高端项目，令我有机会凑近前沿科技。也正是因为做了这个项目，开始对外界关于大数据的各种信息开始敏感，而当时正在项目中的我们，更多关注的是当前脚下的路，而不是周围的风景。

所以当这个项目完结相当长一段时间以后，我们依然在留心大数据方面的消息，虽然再入这个领域的机会很小，但已经变成一种习惯意识，也曾有莫名的滑稽的自豪感，就像一个孩子，会指着橱窗里彩色的糖果对着其他流口水的小伙伴们说，看，我吃过中间这个最大的！

这两年，“大数据”这个词在公众眼前出现的次数越来越多，听起来的确气势恢宏，所以很多人都敬仰着不明觉厉。而随着越来越多的使用，各类商家无论什么都冠上“大数据”三个字以期身价倍增，连个街头乞丐都会用大数据给自己找摊位，用得多了，民众就会有困惑，大数据到底是什么玩意？怎么什么人都能玩得转？

那么我们就先来说说，什么是大数据。

大数据，顾名思义，首先是要大。但是，多大才算大呢？只是单纯的大吗？其实这是非常有争议的，因为大数据，不像通讯领域的3G、4G，有严格的标准，有章可循。

大多数研究者认为，大数据和海量数据是有区别的，那么就有了第一个定义：大数据 = 海量数据 + 复杂类型的数据

数据库中的数据可以分为三种类型：结构性数据，非结构性数据以及半结构性数据。如果是结构性数据，一般通过购买更多的存储来解决，但当海量的非结构性及半结构性数据存在的时候，情况就变得复杂了。对于大数据在数据处理这方面的应用，很多人都在质疑，大数据和传统的数据统计/数据分析有什么区别，认为现在的宣传都是炒作，都是偷换概念，实际上没有什么新鲜的东西。

其实还是有明显区别的。

传统的统计学，数据分析，都是基于样本数据的，在进行各种分析前，首先需要采样。那么这里就引出了大数据的第一个特征，也是很容易被人们忽视的：大数据的运算范围，并不是样本数据，哪怕规模宏大的样本数据。而是，全数据。随机抽样，有它的弊端，数据的可靠性存在着偏差，而直接跳过采样，采用全数据，是大数据的一个霸气里程碑。

可能是为了浅显易懂，就取了“BigData”，“大数据”这么样的一个名字，如果换成“马斯戴德”之类的名字，估计会显得高深莫测一些，也可以和现在的数据分析处理技术有一个一目了然的区别。

提到大数据，就要提到大数据的4V特征，其实我很不想说这个，但是提到大数据你不说这个，人家就会觉得你业余（其实我本来也很业余）。4V是这4个词的缩写：Volume（大量）、Velocity（高速）、Variety（多样）、Value（价值）。

其实上面已经提到了两个V，Volume 和 Variety，这是大数据自身的两个不能回避的特征。

可是很多人都会有疑问：对于体量大的标准如何衡定？到底多大才算大？

Hadoop是什么？这次看名字看不出来了吧？

来，让我告诉你，Hadoop 是一个大象小玩偶的名字。

只不过是一个特殊的玩偶。因为它是 Hadoop 创始人爱女的一个钟爱玩偶。所以，我们今天看到的 Hadoop 被命名成 Hadoop。

啊……让我们感叹一下伟大的父爱……

扯远。

我们先来一段稍显官方的生硬解说词：

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。Hadoop的框架最核心的设计就是：HDFS 和 MapReduce。HDFS为海量的数据提供了存储，而 MapReduce 为海量的数据提供了计算。

说白了，Hadoop 是一个实现了MapReduce模式的开源的分布式并行编程框架。是不是又有一堆疑问？OK，我们先来探讨一下Hadoop的灵魂——MapReduce。

面对数据的爆炸性增长，谷歌的工程师 Jeff Dean 和 Sanjay Ghemawat 架构并发布了两个开创性的系统：谷歌文件系统（GFS）和谷歌MapReduce（GMR）。前者是一个出色而实用的解决方案，使用常规的硬件扩展并管理数据，后者同样辉煌，造就了一个适用于大规模并行处理的计算框架。谷歌MapReduce（GMR）为普通开发者/用户进行大数据处理提供了简易的方式，并使之快速、具备容错性。谷歌文件系统（GFS）和谷歌MapReduce（GMR）也为谷歌搜索引擎对网页进行抓取、分析提供了核心动力。而实际上，HDFS 就是 Google File System（GFS）的开源实现，MapReduce 是Google MapReduce 的开源实现。Hadoop项目已经发展成为一个生态系统，并触及了大数据领域的方方面面。当初我们敏感地意识到大数据的运用离不开计算平台，就好比美丽的花朵离不开绚丽的颜色。但在我们对Hadoop平台进行了几轮深入分析之后，的确是对它又爱又恨。

MapReduce是一种模式，一种什么模式呢？一种云计算的核心计算模式，一种分布式运算技术，也是简化的分布式编程模式，它主要用于解决问题的程序开发模型，也是开发人员拆解问题的方法。MapReduce模式的主要思想是将自动分割要执行的问题（例如程序）拆解成map（映射）和reduce（化简）的方式，如下图所示：

在数据被分割后通过Map 函数的程序将数据映射成不同的区块，分配给计算机机群处理达到分布式运算的效果，在通过Reduce 函数的程序将结果汇整，从而输出开发者需要的结果。MapReduce 借鉴了函数式程序设计语言的设计思想，其软件实现是指定一个Map 函数，把键值对(key/value)映射成新的键值对(key/value)，形成一系列中间结果形式的key/value 对，然后把它们传给Reduce(规约)函数，把具有相同中间形式key 的value 合并在一起。Map 和Reduce 函数具有一定的关联性。

（话说你们真的喜欢看这个么.... 真的要往下看么.... o(╯□╰)o）

一个MapReduce作业（job）通常会把输入的数据集切分为若干独立的数据块，由 Map任务（task）以完全并行的方式处理它们。框架会对Map的输出先进行排序，然后把结果输入给Reduce任务。通常作业的输入和输出都会被存储在文件系统中。整个框架负责任务的调度和监控，以及重新执行已经失败的任务。如下图所示（Hadoop MapReduce处理流程图）：

MapReduce致力于解决大规模数据处理的问题，因此在设计之初就考虑了数据的局部性原理，利用局部性原理将整个问题分而治之。由于MapReduce集群由普通PC机构成，为无共享式架构。在处理之前，将数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理（map），将处理后的数据进行合并（combine）、排序（shuffle and sort）后再分发（至reduce节点），避免了大量数据的传输，提高了处理效率。无共享式架构的另一个好处是配合复制（replication）策略，集群可以具有良好的容错性，一部分节点的down机对集群的正常工作不会造成影响。而这种可靠性的提升，正离不开它底层的文件系统，HDFS。

HDFS是Hadoop Distribute File System 的简称，也就是Hadoop的一个分布式文件系统。HDFS设计理念之一就是让它能运行在普通的硬件之上，即便硬件出现故障，也可以通过容错策略来保证数据的高可用。由于HDFS存储的数据集作为hadoop的分析对象，在数据集生成后，长时间在此数据集上进行各种分析。每次分析都将涉及该数据集的大部分数据甚至全部数据，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要，所以HDFS具有最高效的访问模式：一次写入、多次读取(流式数据访问)。

一个HDFS集群是有由一个Namenode和一定数目的Datanode组成。Namenode是一个中心服务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在内部，一个文件其实分成一个或多个block，这些block存储在Datanode集合里。如下图所示（HDFS体系结构图）：

刚开始分析的时候，我很容易在名称上将Datanode和Namenode弄混，后来想了个办法，Namenode是那个有命名权的人，这种人一般位高权重，高高在上，一个就够了；Datanode虽然看起来很有货，但就是个干苦力的，基础工作都是它们做，这样一想，名字就搞清楚了。

对于block，每一个block会在多个datanode上存储多份副本，默认是3份。Rack 是指机柜的意思，一个block的三个副本通常会保存到两个或者两个以上的机柜中（当然是机柜中的服务器），这样做的目的是做防灾容错，因为发生一个机柜掉电或者一个机柜的交换机挂了的概率还是蛮高的。这样既保证了可以使各任务就近读取缩短处理时间，又有很好的数据备份安全，唯一有些缺憾的是，备份数量过多的话，会拉长数据balance的时间。

如果把HDFS和MapReduce结合起来看，内部工作原理就是下面这张图，浅显易懂：

因为我们是从平台转型过来的，自然对新事物中的平台或框架更感兴趣和敏感，当我们锁定了Hadoop这种计算框架之后，花了很大的精力来分析和测试。最初接触到的时候被很多概念所蒙蔽，但我们最终克服了它，并在测试数据的背后寻找到了真相。关于HDFS我们就简单讲这么多，我实在是不想让这篇文章看起来像一个枯燥乏味的技术细节探讨专题，Hadoop是免费的开源软件，网上相关的资料特别多，有兴趣深挖的筒子可以移步百度。

由于Hadoop技术出现的特别早，而且，其本身也有一些掣肘，所以后来又出现了一个加强版：Spark。

.

（快回来~~！我说的不是车~~

百科是这样对它定义的：

相信这简单几句话也讲的很清楚，Spark的广告语号称有百倍于Hadoop的速度，这在为海量数据计算动辄要等上十几个小时甚至更久的人们眼睛冒光……我们当时也冒光了……于是我们咔咔把环境搭起来，然后和Hadoop测试比较了……然后我们愤怒地咆哮：广告都他喵是骗人的！当然，情绪是要发泄的，但Calm down之后，好好想一想，是有原因的。

Spark为什么敢说它快？是因为它有RDD。如果说MapReduce是Hadoop类框架的灵魂，那么RDD就是Spark的九丈矛。RDD（弹性分布式数据集）作为原始数据的抽象，可以cache到内存中，那么每次对RDD数据集的操作之后的结果，都可以存放到内存中，下一个操作可以直接从内存中输入，省去了MapReduce大量的磁盘IO操作。这对于迭代运算比较常见的机器学习算法来说，效率提升比较大。在这些它所擅长的方面，它的高速高效是无疑的，但如果没有特别适合它的计算模型，那么它就是辆跑在石头地里的宝马，比拖拉机快不到哪里去。所以Spark更适合于迭代运算比较多的ML和DM运算，而不适用那种异步细粒度更新状态的应用，例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型，当然不适合把大量数据拿到内存中了。增量改动完了，也就不用了，不需要迭代了。

关于Hadoop和Spark平台的一些性能数据，可以参考我之前的博文《大数据实测之三英战吕布》。

RDD的技术细节此处也不做过多赘述，请百度其相关资料。

我们再回到大数据的4V，正是因为大数据的Volume（大量）和 Variety（多样）才对Velocity（高速）有了更高的要求，从而催生出各种新的计算框架，并且这种革新一直在持续。Hadoop被提出来已经十几年了，从那时以来，已经有太多的东西发生了变化：多核心处理器、大内存地址空间、10G网络带宽、SSD，而至今，这已经产生足够的成本效益。这些极大改变了在构建可容错分布式商用系统规模方面的取舍。此外，我们对于可处理数据的规模的观念也发生了变化。在继Hadoop和Spark之后，又有很多新技术和新平台出现，满地繁花。科技就是这样，不断地在进步，你刚刚搞清楚一样东西，却发现它已经过时了。

最后我们再说大数据的第四个V，Value，价值。

在商业上，不少公司开始借助大数据为他们创造更多的机会，成功的公司诸如亚马逊、eBay、谷歌，它们依然想要据此更上一层楼，也促使随后的商业领袖重新思考：大数据可以用来做什么？

我曾经写过的一篇博文，《沈MM也来聊聊大数据》，可能很多人会觉得里面提出的“通过大数据就能透析未来”这种言论有些大言耸听，嗯，老实说，我承认对它有进行文学艺术加工，所以略显夸张。但我依然不否认我对这种趋势的看法，大数据，其最大的价值就是预测。

但这种预测又和我们通常意义上所讲的预测不同。

写到这里的时候，我旁边负责写算法系列的同事探头问我，你说算命算不算大数据？

滚~~~

一般人们对预测的评价准则和关心重点，都是“准不准”，比如，章鱼保罗，马航事件里的巫术师，或者，天气预报。

前两种都是不科学的，我们笑而弃之。

天气预报是大家最熟悉的预测类信息了，但你也一定遇到过抱怨，明明说今天天晴啊，怎么下雨了？！

因为大家都熟悉，我们就从天气预报这个深入民心的基于大数据预测分析的典型代表为切入点，看看大数据在预测上的一些普适特征，特别是互联网方面：

1、大数据预测的时效性

天气预报粒度从天缩短到小时，有严苛的时效要求，基于海量数据通过传统方式进行计算，得出结论时明天早已到来，预测并无价值。其他领域的大数据预测应用特征对“时效性”有更高要求，譬如股市、实时定价，所以不要忘记大数据的另一个V，Velocity（高速）。好在如今云计算、分布式计算和超级计算机的发展则提供了这样的高速计算能力。

2、大数据预测的数据源

天气预报需要收集海量气象数据，气象卫星、气象站台负责收集，但整套系统的部署和运维耗资巨大。传统行业在互联网高速发展之前鲜有领域具备这样的数据收集能力。WEB1.0为中心化信息产生、WEB2.0为社会化创造、移动互联网则是随时随地、社会化和多设备的数据上传，每一次演化数据收集的成本都大幅降低，范围和规模则大幅扩大。大数据被引爆的同时，借助于互联网，大数据预测所需数据源不再是问题。

3、大数据预测的动态性

不同时点的计算因子动态变化，任何变量都会引发整个系统变化，甚至产生蝴蝶效应。如果某个变量对结果起决定性作用且难以捕捉，预测难上加难，譬如人为因素。大数据预测的应用场景大都是极不稳定的领域但有固定规律，譬如天气、股市、疾病。这需要预测系统对每一个变量数据的精准捕捉，并接近实时地调整预测。在信息急速爆炸的今天，大数据的实时预测对传感器网络和大数据计算能力提出了更高的要求。

4、大数据预测的规律性

大数据预测与传统的基于抽样的预测不同之处在于，其基于海量历史数据和实时动态数据，发现数据与结果之间的规律，并假设此规律会延续，捕捉到变量之后进行预测。一个领域本身便有相对稳定的规律，大数据预测才有机会得到应用。古人夜观天象就说明天气是由规律可循的，因此气象预报最早得到应用。反面案例则是规律难以捉摸，数据源收集困难的地震预测，还有双色球彩票。

其实传统的数据分析挖掘一直在做相似的事情，只不过效率会低一些或者说挖掘的深度、广度和精度不够。大数据预测则是基于大数据和预测模型去预测未来某件事情的概率。就像天气预报，它只是说明天天晴的概率比较大，但不能肯定明天绝不会下雨。

大数据预测让分析从“面向已经发生的过去”转向“面向即将发生的未来”是大数据与传统数据分析的最大不同。

大数据预测的逻辑基础是，每一种非常规的变化事前一定有征兆，每一件事情都有迹可循，如果找到了征兆与变化之间的规律，就可以进行预测。大数据预测无法确定某件事情必然会发生，它更多是给出一个概率。《大数据时代》中明确地指出，大数据预测“不是精确性，而是混杂性”“不是因果关系，而是相关关系”。

如果说，预测是大数据的核心，那么预测的核心是什么呢？

我们当时埋头在大数据运算里好几个月，突然有一天潘然醒悟，速度再快，计算量再多，结果不够可靠，一切都是白搭，而能指引我们在茫茫数据海洋里找到彼岸的，唯有算法这盏明灯。

在我的上一篇关于大数据的博文里，我对算法很是崇拜了一通，老实说，在这个项目之前我对算法完全不懂，听上去就很厉害的样子。但是大数据，决然少不了算法，一套好的算法，就像是精妙的剑谱，招招制胜。

我不懂算法没关系，我们立马抽调一个懂算法的博士Dr.P进项目，于是接下来的一段时间，Dr.P先生整天给我们讲各种算法原理，画各种曲线图，随手就在玻璃墙上写出来好多天书一样的公式，也不管你看得懂看不懂……我的数学在离开高数课堂近十年之后又被从小黑屋里捡起来打磨，磨完了高数又磨了线性代数，但依然有些公式令我力不从心（领导，我开玩笑的）……

接下来，搭环境，攻克R语言，搞定R-Python，我们总算迈出了颤颤巍巍的第一小步。我们的一小步，是部门的一大步。

这个时候我才开始觉得，我们手里的数据，开始变得有意义。

我们当时手里有一套比较原始的算法，采用的是线性拟合，由于数据实在太复杂，最后出来的结果非常不令人满意。于是Dr.P带领我们给它换了一个在我看来很高级的算法——神经网络算法。换了算法之后果然不一样，当然其中过程之艰辛也就不多说了，我们的新算法将精度提升15%+。

算法的具体实现上也有优化空间，经过我们的努力，预测准确度提高近10%。

这里要解释一下如何评估预测结果，比如我要预测一年后会发生某事，或某指标的升降，不可能要等一年以后才来验证，检验标准的关键在于这个预测模型是否正确。业界一般的做法是，在原有数据集的整个区间内，拿出前一段的数据做训练学习，用后一段的数据做验证比较。打个比方，100天的天气数据，我用1-80天来做训练，然后预测后20天的数据，用这预测出来的20天结果和真实的最后20天数据做比较，有多少误差，很容易辨别。

以上，只是我们在算法上做的一个小小的尝试，这部分依然有很大的优化空间，算法的种类也纷繁多样，变化无穷。

得益于我们博士资源比较多，你砸个蛋糕过来一定会波及到一个博士，所以算法这么精髓的东西交给博士们打理就可以了，我们探路者已经功成身退。

对于算法我还是个门外汉，就不做过多饶舌，但这绝对是大数据预测的关键。关于更多算法的相关总结文章，可以参考前面那个算命博士写的总结，【跳转门在此】（此博非Dr.P，不过他的文章难产了，写好以后我会加进来）

关于大数据的未来，我个人的看法是挑战依然很大。

大数据无处不在，人们每天创造出越来越多的应用来收获其中的价值，无论是在我们的个人生活还是专业领域，从很多方面来说，大数据是数据产生速度的一种反映，实际上有分析家预计到2020年，数据产生的速度，将会是如今数据产生速度的50倍。

一方面，科学数据的增长等，加速了这种数据的猛增，举例来说：欧洲研究组织进行的核试验每秒钟能产生40TB的数据。另一方面，一些非常积极的社会和经济变化，也加剧了数据的泛滥，想想这些例子，迅速普及的移动设备，有GPS功能和富媒体，还有社交网络让全世界数十亿人进行数码联系……

这些新兴科技，令如今每天产生的新数据按从前定义就是大数据，那么所有这些数据持续增长，是一种什么样的局面？数据不断地在变大，但是价值密度却在在变低。如何高效地去除垃圾数据，提取有效信息的难度也在不断上升。

这里有两页我以前写的胶片，便是我所看见的大数据未来：

我在《大数据时代》里发现了一段话，权且作为本文的结束语：

“大数据并不是一个充斥着算法和机械的冰冷世界，人类的作用依然无法被完全替代。大数据为我们提供的不是最终答案，只是参-，帮助是暂时的，而更好的方法和答案还在不久的将来。”

-----------------------------------------------------------------The End.

后记：

12年的夏天，我曾写过一篇很长很长的项目总结：《硬盘那些事》，吐槽在OMUd项目中遇到的各种奇葩狗血困难以及整个项目过程中的心路历程，每次回头看看，都别有一番感触。

这一回又接到任务，要对14年做的一个大数据相关的项目进行总结，并顺带给部门全员进行一下大数据的扫盲科普。看起来有要求，但其实又没要求，这样的文章最难写，于是我反反复复写了好几稿，自己都不能满意。本来我想像前一篇总结一样，关注项目的过程本身的思考，但又觉得既然困难都已克服，就无须拿出来碎碎念，最终，你们见到的这一稿是V5.0，我也是蛮拼的……

其实这个项目本身，并没有对大数据进行更深入的研究，所以我不能够说是大数据方面的专家，连资深人士都不敢妄称，接到这个任务也的确是有些诚惶诚恐，生怕自己的见解不到位惹来内行人士的笑话。大数据所涉及的面非常广泛，写着写着可能就写忘了一些东西，写的并不算全面，但我想我把我理解中的主要的点都写出来了，算是对这项目一个交代。

在这个项目的过程中，得到了很多相关部门的人的大力支持，大多数都是我不认识的，但他们都很耐心地与我交流、探讨，甚至慷慨相助，对此我一直心怀感激。

借此，我诚挚地奉上我的谢意，希望那些曾经帮助过我的各位能够在自己的领域里，独创一片天地。

Hadoop 大数据

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。