大数据的关键技术与综述

在大数据时代，传统的数据处理方法还适用吗？

大数据环境下的数据处理需求

大数据环境下数据来源非常丰富且数据类型多样，存储和分析挖掘的数据量庞大，对数据展现的要求较高，并且很看重数据处理的高效性和可用性。

传统数据处理方法的不足

传统的数据采集来源单一，且存储、管理和分析数据量也相对较小，大多采用关系型数据库和并行数据仓库即可处理。对依靠并行计算提升数据处理速度方面而言，传统的并行数据库技术追求高度一致性和容错性，根据CAP理论，难以保证其可用性和扩展性。

传统的数据处理方法是以处理器为中心，而大数据环境下，需要采取以数据为中心的模式，减少数据移动带来的开销。因此，传统的数据处理方法，已经不能适应大数据的需求！

大数据的处理流程包括哪些环节？每个环节有哪些主要工具？

大数据的基本处理流程与传统数据处理流程并无太大差异，主要区别在于：由于大数据要处理大量、非结构化的数据，所以在各个处理环节中都可以采用MapReduce等方式进行并行处理。

大数据技术为什么能提高数据的处理速度？

大数据的并行处理利器——MapReduce

大数据可以通过MapReduce这一并行处理技术来提高数据的处理速度。MapReduce的设计初衷是通过大量廉价服务器实现大数据并行处理，对数据一致性要求不高，其突出优势是具有扩展性和可用性，特别适用于海量的结构化、半结构化及非结构化数据的混合处理。

MapReduce将传统的查询、分解及数据分析进行分布式处理，将处理任务分配到不同的处理节点，因此具有更强的并行处理能力。作为一个简化的并行处理的编程模型，MapReduce还降低了开发并行应用的门槛。

MapReduce是一套软件框架，包括Map（映射）和Reduce（化简）两个阶段，可以进行海量数据分割、任务分解与结果汇总，从而完成海量数据的并行处理。

MapReduce的工作原理其实是先分后合的数据处理方式。Map即“分解”，把海量数据分割成了若干部分，分给多台处理器并行处理；Reduce即“合并”，把各台处理器处理后的结果进行汇总操作以得到最终结果。如右图所示，如果采用MapReduce来统计不同几何形状的数量，它会先把任务分配到两个节点，由两个节点分别并行统计，然后再把它们的结果汇总，得到最终的计算结果。

MapReduce适合进行数据分析、日志分析、商业智能分析、客户营销、大规模索引等业务，并具有非常明显的效果。通过结合MapReduce技术进行实时分析，某家电公司的信用计算时间从33小时缩短到8秒，而MKI的基因分析时间从数天缩短到20分钟。

说到这里，再看一看MapReduce与传统的分布式并行计算环境MPI到底有何不同？MapReduce在其设计目的、使用方式以及对文件系统的支持等方面与MPI都有很大的差异，使其能够更加适应大数据环境下的处理需求。

大数据技术在数据采集方面采用了哪些新的方法

系统日志采集方法

很多互联网企业都有自己的海量数据采集工具，多用于系统日志采集，如Hadoop的Chukwa，Cloudera的Flume，Facebook的Scribe等，这些工具均采用分布式架构，能满足每秒数百MB的日志数据采集和传输需求。

网络数据采集方法：对非结构化数据的采集

网络数据采集是指通过网络爬虫或网站公开API等方式从网站上获取数据信息。该方法可以将非结构化数据从网页中抽取出来，将其存储为统一的本地数据文件，并以结构化的方式存储。它支持图片、音频、视频等文件或附件的采集，附件与正文可以自动关联。

除了网络中包含的内容之外，对于网络流量的采集可以使用DPI或DFI等带宽管理技术进行处理。

其他数据采集方法

对于企业生产经营数据或学科研究数据等保密性要求较高的数据，可以通过与企业或研究机构合作，使用特定系统接口等相关方式采集数据。

 

本文节选自《大数据——大价值、大机遇、大变革(全彩)》

李志刚 主编

电子工业出版社出版

• 使用JSP+Servlet技术生成报表
• 玩转Bootstrap（JS插件篇）
• JAVA实现对称加密
• jQuery源码解析（DOM与核心模块）

Big Data（大数据技术）是近来的一个技术热点，但从名字就能判断它并不是什么新词。毕竟，大是一个相对概念。历史上，数据库、数据仓库、数据集市等信息管理领域的技术，很大程度上也是为了解决大规模数据的问题。被誉为数据仓库之父的Bill Inmon早在20世纪90年代就经常将Big Data挂在嘴边了。

然而，Big Data作为一个专有名词成为热点，主要应归功于近年来互联网、云计算、移动和物联网的迅猛发展。无所不在的移动设备、RFID、无线传感器每分每秒都在产生数据，数以亿计用户的互联网服务时时刻刻在产生巨量的交互……要处理的数据量实在是太大、增长太快了，而业务需求和竞争压力对数据处理的实时性、有效性又提出了更高要求，传统的常规技术手段根本无法应付。

在这种情况下，技术人员纷纷研发和采用了一批新技术，主要包括分布式缓存、基于MPP的分布式数据库、分布式文件系统、各种NoSQL分布式存储方案等。

10年前，Eric Brewer提出著名的CAP定理，指出：一个分布式系统不可能满足一致性、可用性和分区容忍性这三个需求，最多只能同时满足两个。系统的关注点不同，采用的策略也不一样。只有真正理解了系统的需求，才有可能利用好CAP定理。

架构师一般有两个方向来利用CAP理论。

• Key-Value存储，如Amazon Dynamo等，可以根据CAP理论灵活选择不同倾向的数据库产品。
• 领域模型+分布式缓存+存储，可根据CAP理论结合自己的项目定制灵活的分布式方案，但难度较高。

对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着A、P的方向设计，然后通过其他手段保证对于一致性的商务需求。架构设计师不要将精力浪费在如何设计能满足三者的完美分布式系统，而应该懂得取舍。

不同的数据对一致性的要求是不同的。SNS网站可以容忍相对较长时间的不一致，而不影响交易和用户体验；而像支付宝这样的交易和账务数据则是非常敏感的，通常不能容忍超过秒级的不一致。

图1 memcached构成

Cache篇

缓存在Web开发中运用越来越广泛，mem-cached是danga.com（运营LiveJournal的技术团队）开发的一套分布式内存对象缓存系统，用于在动态系统中减少数据库负载，提升性能。

memcached具有以下特点：

协议简单；基于libevent的事件处理；内置内存存储方式；memcached不互相通信的分布式。

memcached处理的原子是每一个（Key，Value）对（以下简称KV对），Key会通过一个hash算法转化成hash-Key，便于查找、对比以及做到尽可能的散列。同时，memcached用的是一个二级散列，通过一张大hash表来维护。

memcached由两个核心组件组成：服务端（ms）和客户端（mc），在一个memcached的查询中，ms先通过计算Key的hash值来确定KV对所处在的ms位置。当ms确定后，mc就会发送一个查询请求给对应的ms，让它来查找确切的数据。因为这之间没有交互以及多播协议，所以 memcached交互带给网络的影响是最小化的。

MemcacheDB是一个分布式、Key-Value形式的持久存储系统。它不是一个缓存组件，而是一个基于对象存取的、可靠的、快速的持久存储引擎。协议与memcached一致（不完整），所以很多memcached客户端都可以跟它连接。MemcacheDB采用Berkeley DB作为持久存储组件，因此很多Berkeley DB的特性它都支持。

图2 Greenplum数据引擎软件

类似这样的产品也很多，如淘宝Tair就是Key-Value结构存储，在淘宝得到了广泛使用。后来Tair也做了一个持久化版本，思路基本与新浪MemcacheDB一致。

分布式数据库篇

支付宝公司在国内最早使用Greenplum数据库，将数据仓库从原来的Oracle RAC平台迁移到Greenplum集群。Greenplum强大的计算能力用来支持支付宝日益发展的业务需求。

Greenplum数据引擎软件专为新一代数据仓库所需的大规模数据和复杂查询功能所设计，基于MPP（海量并行处理）和Shared-Nothing（完全无共享）架构，基于开源软件和x86商用硬件设计（性价比更高）。

分布式文件系统篇

谈到分布式文件系统，不得不提的是Google的GFS。基于大量安装有Linux操作系统的普通PC构成的集群系统，整个集群系统由一台 Master（通常有几台备份）和若干台TrunkServer构成。GFS中文件备份成固定大小的Trunk分别存储在不同的TrunkServer 上，每个Trunk有多份（通常为3份）拷贝，也存储在不同的TrunkServer上。Master负责维护GFS中的 Metadata，即文件名及其Trunk信息。客户端先从Master上得到文件的Metadata，根据要读取的数据在文件中的位置与相应的 TrunkServer通信，获取文件数据。

图3 引自Facebook工程师的Hive与Hadoop关系图

在Google的论文发表后，就诞生了Hadoop。截至今日，Hadoop被很多中国最大互联网公司所追捧，百度的搜索日志分析，腾讯、淘宝和支付宝的数据仓库都可以看到Hadoop的身影。

Hadoop具备低廉的硬件成本、开源的软件体系、较强的灵活性、允许用户自己修改代码等特点，同时能支持海量数据存储和计算任务。

Hive是一个基于Hadoop的数据仓库平台，将转化为相应的MapReduce程序基于Hadoop执行。通过Hive，开发人员可以方便地进行ETL开发。

如图3所示，引用一张Facebook工程师做的Hive和Hadoop的关系图。

NoSQL篇

随着数据量增长，越来越多的人关注NoSQL，特别是2010年下半年，Facebook选择HBase来做实时消息存储系统，替换原来开发的 Cassandra系统。这使得很多人开始关注HBase。Facebook选择HBase是基于短期小批量临时数据和长期增长的很少被访问到的数据这两个需求来考虑的。

HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建大规模结构化存储集群。HBase是BigTable的开源实现，使用HDFS作为其文件存储系统。Google运行 MapReduce来处理BigTable中的海量数据，HBase同样利用MapReduce来处理HBase中的海量数据；BigTable利用 Chubby作为协同服务，HBase则利用Zookeeper作为对应。

图4 线上应用系统与数据平台的无缝融入

总结篇

近来NoSQL数据库的使用越来越普及，几乎所有的大型互联网公司都在这个领域进行着实践和探索。在享受了这类数据库与生俱来的扩展性、容错性、高读写吞吐外（尽管各主流NoSQL仍在不断完善中），越来越多的实际需求把人们带到了NoSQL并不擅长的其他领域，比如搜索、准实时统计分析、简单事务等。实践中一般会在NoSQL的外围组合一些其他技术形成一个整体解决方案。

准实时的统计分析

• 传输时统计分析，Stream Processing技术：FlumeBase、S4。

FlumeBase：可参考 http://flumebase.org/documentation/0.1.0/UserGuide.html 中的quick start和architecture两部分。

S4：Yahoo!开源数据来流计算实时框架，可参考http://labs.yahoo.com/files/KDCloud%202010%20S4.pdf

• 查询时统计分析，结果集较小时，可以直接在返回前做统计分析处理。

比如买家消费记录查询的HBase实现，Schema设计，rowkey=uid，column=搜索词和查询值，version=交易id。

搜索相关

• 充分利用NoSQL（比如HBase）内部数据的有序性、Row Key、Column Family、Version Timestamp。

我们用“HBase+二次索引”来实现实时营销的解决方案。也可以参考Facebook Message的解决方案：http://blog.bluedavy.com/?p=258

• 构建一个外围系统完成索引建立。

Google MegaStore：原文链接为http://www.cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf ，中文译文链接为http://cloud.csdn.net/a/20110216/291968.html 。

也有人开始尝试基于HBase的MegaStore实现，链接为https://github.com/drevell/megalon 。

简单事务

• 事务处理服务 + NoSQL存储。
• 淘宝开发的千亿级海量数据库Oceanbase，通过update server角色执行将写操作限制在一台机器上，实现事务。参考链接为：http://www.nosqlnotes.net/archives/170 。
• Google MegaStore通过为用户提供机制，根据应用特点划分entity group，将事务涉及的数据分布到一台机器上，实现事务。