云安全联盟大数据工作组发布

译者：李毅 中国惠普大学资深培训专家

** 摘要 **
在本文中，我们提出了一个大数据的六维度分类方法。这个分类方法的主要目的是帮助决策制定者在计算、存储架构、数据分析技术、安全与隐私框架等多种选择中确定正确的方向。这其中需要分析的数据是分类的核心。

简介
大数据指的是与我们每一个人以及周边事物有关而且被政府和企业所收集的大量数字信息。这些数据不仅仅是由传统的信息交换软件通过台式机、移动电话等设备产生，也来自于各种环境中所嵌入的无数类型各异的传感器；它即来源于城市街道（摄像头、麦克风）或喷气引擎（温度传感器），也来源于快速蔓延的物联网 － 每一个电子设备都将连接到互联网并产生数据。

每天，我们生成2.5艾（1艾等于10的18次方）字节的数据－当今世界上将近90%的数据是在最近两年中生成的（比如2011年［1］）。有关存储、计算、安全与隐私、和分析方面的问题都被大数据的快速、大容量和多样性等特点给加以放大，这些问题包括可大规模扩展的云计算基础架构、数据来源和格式的多样性、数据采集的流特性和云内迁移的巨大容量需求。

图1显示了基于六个维度的分类。这六个维度涵盖了构建大数据基础架构所必需要的各个方面。本文后面的部分将对每一个维度进行介绍。

** 数据**
首先要回答的问题是：大数据产生于哪里？把数据的来源进行归类是为了理解有哪些基础架构可供选择以及特定的数据类型对它们的要求。所有的“数据”都是不同的。数据将决定需要什么样的架构来存储它、处理它并在它之上进行分析。我们有多种方式来看待数据的问题。

延迟的要求
第一种方式是根据处理数据所需要的时间跨度来界定数据：
• 实时 （财务流、复杂事件处理（Complex event Processing － CEP）、入侵检测、欺诈检测）
• 近实时 （广告投送）
• 批处理 （零售、取证、生物信息学、地理数据、多种类型的历史数据）

“实时”应用程序的例子
很多应用程序会涉及以下各种近乎实时的数据：
• 在线广告优化（包括实时竞价）
• 高频在线交易平台
• 安全事件监控
• 财务交易监控及欺诈检测
• Web分析及其他类型的仪表盘（dashboard）
• 在线游戏或电子商务的客户流失预测
• 基于行为和使用情况对设备、工业厂房或者物流系统进行优化
• 控制系统相关的任务：例如智能电网、核电站
• 关于某推文（tweets）的情绪分析
在大多数这些应用程序中，数据是持续在改变的。为了响应特定的事件，现实且（或）必要的选择是在一个特定时间框架（“最近一小时被查看的页面”或“最近一小时／天／星期／月内的交易）内只考虑相关的数据而不考虑过去全部的数据。

实时应用程序对大数据技术解决方案中关键属性的影响
为了选择恰当的手段和大数据技术解决方案来处理手头的问题，理解对这个决策有影响的一些关键属性是非常重要的。除了延迟的要求（用于计算结果的时间）外，还应包括以下的：
• 事件特征
• 包括应用程序需要的数据输入／输出速率
• 事件响应复杂度
• 处理的复杂度
• 每个事件中处理任务的计算复杂度是怎样的？
• 数据域的复杂度
• 为了支持这些处理需要访问的数据量规模？
• 它是否可以在存储在内存中？或者它是否已经分散到多个位置和存储介质中？
正如所料想的，当很高的输入／输出速率与低延迟的要求相结合就会给底层的基础架构带来严峻的挑战，这样事件响应复杂度在计算和数据域两方面都会比较高。

延迟是当一个事件发生到事件所需的响应完成之间所需要的时间。换而言之，它是完成计算从而作出决策所需花费的时间。

我们在这里考虑的是两个大类：低延迟与高延迟的要求
• 这里我们把“低延迟”应用程序定义为需要的响应时间在几十个毫秒之内的应用程序。对于类似高频交易及实时竞价或者在线广告优化的应用程序，在应用程序的场景中对于延迟有一个可接受的上限要求。通常，在线广告优化系统大约要求20-50毫秒，而高频交易系统可能有更严格的实时响应要求。虽然应用程序和基础架构在功能上都具有特定的延迟，但随着时间的推移，被我们归于这个类别的都是那些需要“实时”响应的应用程序。
• 我们认为一个“中到高延迟”的应用程序对响应时间的要求大约为几秒到几分钟，（甚至可以能到几小时）。例如，场景中会涉及用户交互和仪表盘的应用程序，一般在每几秒甚至几分钟后更新结果是可以接受的。大多数的报表和长期的数据分析可以忍受大约几分钟，有时甚至是几小时或几天的延迟。

这里的真正问题是应用程序是否可以实时地响应。如果数据以每秒10万个事件的速度生成，但是主要的业务行为是经理每几天手工地检查聚合的数据并调整业务战略，那么低延迟就不是关键的业务问题。另一方面，如果一个流程控制系统是由一组传感器的数据所驱动，或者一个企业为了检测访客人数的突然下降而为网站部署了一个新的主页，这就需要更加及时的响应。

如图2所示，从较高的层面来看，一个计算的总体延迟是由通讯网络的延迟、计算的延迟和数据库的延迟构成的。应用程序自身严重影响着对这三个大类（网络、计算和数据库）的精确估算。计算密集型的应用程序为网络和数据库操作所保留的余地很小。

图2:关于延迟的需求特性

实时应用程序的大数据解决方案
当考虑一个应用程序的大数据技术平台时，其中一个主要考虑因素时延迟的要求。如果不需要低延迟，多数将数据收集到磁盘上或者内存中然后再对数据完成计算的传统方式就足够了。相反的，低延迟要求一般意味着数据进入后就必须处理。

结构
另一种将大数据映射到域的方式是根据其结构或者组织的等级：
• 结构化（零售、财务、生物信息学、地理数据）
• 半结构化（Web日志、电子邮件、文档）
• 非结构化（图像、视频、传感器数据、网页）
以结构化、非结构化或半结构化来认识数据是非常有用的。我们提供了以下的一些例子，当是请注意通过目前很难用一个正式的定义来描述这些类别。

结构化数据
结构化数据简单讲就是关系型数据库和电子表格中包含的数据。结构化数据遵从一个数据模型，它很大程度上是用数据所从属的字段（名字、地址、年龄及其他）以及每个字段的数据类型（数字、货币、字母、名字、日期、地址）来描述。该模型中每个字段也会定义限制或约束条件（例如，在某个范围内的整数）而且不同字段的要素之间的约束条件也用于强化一致性（没有副本，在同一个时间里不能在两个不同的地方存在）（译者注：这是受关系型数据库第三范式的影响，其主要理念是避免数据冗余而保持简洁。）

非结构数据
非结构数据（或非结构信息）是指没有预先定义的数据模型或者没有按预先规定的方式组织的信息。非结构化的信息通常是也文本为主，但是也可能包含诸如日期、数字和facts（译者注：Facts可以是一个类成员或者个体属性值）。另一类的例子包括以照片和图像、视频、传感器数据流、Web页面、PowerPonit文稿、email、博客文章、Wiki和Word文档等形式展现的裸数据（无标签）。

半结构化数据
半结构化数据处于结构化数据与非结构化数据之间。它们是一种结构化数据，但是缺乏由底层数据模型规定的严格结构。对于半结构化数据，标签和其他类型的标记用于标识数据中的特定要素，但是该数据没有一个严格的结构所以不经过进一步的处理是很难提取出完整的语义含意。例如，文字处理软件现在可以创建包含作者名字及创建日期的元数据，而文档的主体则是由非结构化数据构成。（由于没有现成的模型能够把文本聚类到简洁的类目里，就必须依靠先进的学习算法对文本进行挖掘从而理解文本的含义）。作为另一个细微的差别，文档中的文本可以进一步打上包括目录、章、节等等的标签。电子邮件给邮件消息内容中的非结构化数据加上了发件人、收件人、日期、时间和其他固定的字段以及附件。照片和其他的图形可以用诸如作者、日期、位置和其他内容相关的关键字（例如照片中人的名字）来标识，使得它能够被识别和定位。通常用XML和其他的标识型语言来管理半结构化数据。

另一个对这个域进行界定的方式是检查制造数据并且需要从数据中提取信息的行业类型。
• 金融服务
• 零售
• 网络安全
• 大型科技
• 社交网络
• 物联网／传感器网络
• 虚拟媒体

图3展示了数据处理问题涉及的多个域及特定的子域。

图4展示了大数据是如何纵向映射到时间和结构轴向的。这里可以得出一个结论即所有这里列出的行业的应用场景中都需要处理所有的数据结构类型并且应对各种响应时间的需求。在这种情况下，行业领域是描述大数据的另一个正交轴。于是我们通过一些最常见的应用场景直观展现了这些域并且包括它们与行业、时间和结构的映射。

计算基础架构
尽管Hadoop是使用廉价计算资源并行处理大型数据集的流行选择，在不同的领域中还有很多其他的计算基础架构可供使用。图5显示了多种处理架构类型的分类。数据处理是以批处理模式还是针对流数据的实时／近实时处理（数据持续进入而且需要立即处理）决定了大数据的计算模式在第一层概念上的差异。这本节我们主要介绍两个专用基础架构：用于批处理的Hadoop和实时处理的Spark。

MapReduce是一个编程模型以及用于处理及生成大型数据集的相关应用。用户定义一个map函数来处理一个键／值对然后生成一个中间状态的键／值对，而一个reduce函数将把同一个中间状态的键的所有相关的中间状态值进行合并。很多现实世界的任务都可以在这个模型中描述，可以参见在参考论文中介绍［2］。

以这种函数式风格开发的程序能够在一个大规模的廉价主机集群中自动执行。运行系统负责处理具体的数据分块、在一个主机集合中调度程序的执行、处理主机故障以及管理必需的主机间通讯。这允许没有任何并行和分布式系统的经验的开发人员也能利用轻松地使用一个大型分布式系统中的资源。

Leslie Valiant最早提出了块同步并行处理[3]模型。在该模型中，处理器按照一些步骤独立地执行来处理本地的数据。在计算过程中他们也会跟其他的处理器通信。但是他们在执行过程都会在已知点停下来进行同步；这些点被称为边界同步点。这种方法确保能够很容易检测到死锁（译者注：是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象）或者活锁（译者注：两者一直谦让，都无法使用资源）问题。

低延迟：流式计算
如果一个应用程序需要在每一个事件发生时“立即”响应，就需要某种形式的流式计算，它会在数据到来时就马上进行处理。常见的方式是有一小段代码负责独立地处理某一个事件。为了加速这个过程，数据流会被分片并在集群内分布地处理。

Apache Storm是事件处理的流行框架，它由Twitter开发并由Twitter和其他需要该实时处理模式的公司发布。另一个例子是Amazon的Kinesis，或者MapR的流式功能。这些框架负责管理在多个集群节点间的扩展而且定义了支持弹性和容错的多个级别，例如，通过检查点来确保系统能够在故障种恢复。

这些流式计算框架只是解决了计算负载的并行化；为了能够进行查询就需要另外一个存储层来保存结果。由于计算的“当前状态”是保存在流式计算框架内，一般没有很清晰的方式来访问和查询这些信息，对于外部模块这个问题尤甚。依据已经处理完的数据总量，这可能引发对一个大型、高性能存储的后台需求。

简而言之，Apache Spark（下面会详细介绍）采取了一种混合的方式。事件被采集到一个缓存中，然后以批处理的方式按固定的间隔（每几秒钟）进行处理。由于Spark把数据放在内存里，它能够在原则上快速来处理批处理任务从而跟得上输入数据流的节奏。

总之，低延迟处理一般需要某种形式的流式计算，及其相关的计算和存储基础架构。很值得注意的是如果应用程序的需求很极端（例如，如果要求毫秒级以内的延迟），那么传统的系列软件可能就不足以支持这类任务。可能必需使用专用的系列软件或者组件来针对应用程序进行定制化。

高延迟：批处理
如果应用程序可能容忍高延迟（例如，它不需要在几秒、或者几分钟内生成结果），那么就可以考虑针面向批处理的计算方式。

最简单的例子包括应用程序扫描日志文件来判断需要做什么。另外，在应用程序查询数据并计算出所需要的结果后，所有数据可以加载到数据库中。这里使用的数据库可以是传统的SQL数据库、或存储型数据库例如Cassandra，或能够执行聚合任务的数据，如CouchDB。

批处理可以基于Apache Hadoop（后面会详细介绍）这类的框架来进行有效地扩展，它能够把底层的处理按照map－reduce模式进行。日志数据可以通过分布化的方式保存在集群中。应用程序能够以并行的方式来降低响应时间。

由于Hadoop已经成熟，在Hadoop之上就发展出了很多项目。Apache Drill就是这样的一个例子，它是一个与Google基于BigQuery的Dremel类似的垂直数据库（或列式数据库）。垂直数据库是针对你必须扫描整个表然后对与条件匹配的条目进行计算的任务进行了优化。不同与传统数据库以行的方式保存数据，它以列的方式保存数据。所以与日志文件中每个条目一行的方式不同，它选择数据中每一个字段并把它们保存在一起，而是实现了好得多的IO特性。惠普的Vertica和ParStream也是垂直数据库。

有些项目和产品已经开始用内存替换数据库底层的磁盘（或者把闪存和内存混合使用）作为存储媒介，值得注意的是SAP的HANA、GridGain和Apache Spark都绕过了磁盘的速度限制。虽然这些系统已经显著地减少了查询之间的轮转时间，但是本质上讲还是批处理。另一个高性能解决方案的例子是结合了闪存的内存系统Aerospike。

Hadoop 1.0

Hadoop［4］是根据Google的MapReduce和Google文件系统研究论文发展起来的开源分布式基础架构，用于程序开发和数据存储。它是基于“map reduce”计算模式的，首先一个计算任务的输入经过“Map”被分割到多个独立处理输入数据子集的工作节点，第二个步骤是“reduce”即所有“Map”的子任务的结果被收集起来并以某种方式进行组合来形成计算任务的整体输出（图6）。数据既包括保存在Hadoop文件系统中的非结构化数据，也包括保存在数据库中的结构化数据。由于Hadoop的设计目标是解决那些输入数据量很大以至于单台计算机的硬盘空间无法满足存储要求的问题，所以MapReduce计算模式的设计思路是把计算安排到存放数据的节点上，而不是把数据搬到执行计算的节点去。在该框架的设计中通过数据复制实现很强的容错能力，而且在架构中会通过轮询来保持对工作节点进度的跟踪，并且如果某些节点失效则会把这些任务重新分配给其他的节点。另外，该框架将自动地在计算／存储网络上分配“map”和“reduce”计算任务。以上所有工作都是由Hadoop运行环境自动完成，而开发人员只需要动手开发map和reduce的例程。

整个Hadoop生态系统包括以下的项目：
• Pig － 一个支持通过高级语言编程来分析大型数据集的平台。Pig提供了一个编译器，它可以把Pig程序翻译成Hpadoop框架可以执行的MapReduce作业序列。
• Hive － Hadoop环境所支持的一个数据仓库解决方案。它把为人熟知的关系型数据库概念，如表、列和分区，以及SQL的子集（HiveQL）引入了Hadoop的非结构化世界。Hive的查询被编译成Hadoop执行的MapReduce作业。
• HBase － 一个为在Hadoop中为支持大规模稀疏表而设计的列式NoSQL数据存储环境。
• Flume － 一个用于在数据生成的同时进行搬移的分布式、稳定的、可用服务。Flume非常适合从多个系统中收集日至并且在日志数据生成时就将其加载到Hadoop分布式文件系统（HDFS）中。
• Lucent － 一个针对高性能、全功能文本搜索的搜索引擎库。
• Avro － 使用JSON对预定义的数据类型和协议进行数据序列化的技术，而且把序列化成一种紧凑二进制格式。
• Zookeeper － 维护配置信息和命名的集中服务，提供分布式的同步及分组服务
• Oozie － 用于管理和构建Apache Hadoop作业执行的工作流调度系统。

图6：Hadoop MapReduce数据流

Hadoop很适合作批处理，但是通常人们认为它并不适合于处理没有终止的数据流。这是因为一个Hadoop作业缺省认为所有数据分布在多个节点上的文件中，而且会启动Map和Redcue来处理固定大小的输入并生成固定大小的输入。对于流式应用程序，数据流是稳定且不会停止的，Hadoop模型就显得太笨重且不够理想。动态地添加新的map任务来处理新近到达的输入（以滑动窗口的方式来处理数据流的系统可能会把处理旧数据处理任务迁移走）导致了太多的开销以及太多的性能损耗。

Hadoop也不适合于需要使用于上一次计算结果的迭代算法。这类算法包括很多种对于复杂数据分析非常关键的机器学习算法，例如在线学习算法［6］。

Hadoop对于需要使用一个共享的全局状态的算法也不适用，因为整个MapReduce模型是并行运行map任务而不需要访问一个共享状态的，这样可以避免由于锁、Semaphores（信号灯）以及网络延迟而形成服务器性能瓶颈。在概率模型中用于评估的蒙特卡罗模拟就是会发生这类问题的例子。

图7 展示了Hadoop的多个组件是如何结合在一起的

图7：Hadoop 1.0软件集

Hadoop 2.0
正是因为这些原因，人们开发了Hadoop 2.0. 关键是该架构实现了HDFS、资源管理及MapReduce编程的解耦，并且引入了称为YARN的资源管理层，它负责管理底层的资源。现在一个Hadoop 2.0的应用程序可以在Hadoop管理的存储和计算节点之上部署自己的应用程序级调度例程。

图8：Hadoop 2.0软件集-包括资源管理的YARN和执行引擎 TEZ

Berkeley Spark [39,40]
Spark是一个由加州大学伯克利分校发明的开源集群计算系统，它的目标是加速数据分析 － 包括运行阶段和开发阶段。为了更快地运行程序，Spark提供了在内存中进行集群计算的原语：一个作业可以把数据加载到内存中并且能够以比基于磁盘的Hadoop系统快得多的速度进行反复地查询。Spark也希望统一处理栈，当前是由MapReduce完成批处理，HBase完成交互查询而实时分析的处理由其他框架完成 － 例如推特的Strom。这三个软件集难以用一致的指标来维护。而且它们也很难完成对流式数据的交互式查询。统一的Spark就是为了高效且可扩展地处理这些需求而设计的。

Spark的一个重要概念是弹性分布式数据集（RDD － Resilient Distributed dataset），它是一个集群中分散保存在内存或磁盘中的对象集合。Spark中的应用程序可以把这些RDD加载到集群节点的内存中并且在运行中由Spark运行环境来自动地处理数据的分区和本地化。这能够支持快速的迭代处理。一个输入的数据流可以分割成一系列的批处理并且做为一个小型批处理作业序列来处理。Spark架构把流处理和批处理无缝地结合在了一起。

为了便于快速开发，Spark为Scale、Java和Python提供了简洁明了的API。Spark也可以使用Scala和Python shell交互式地快速查询大数据集。Spark将数据保持在内存中的初衷是为了有助于两类应用程序：迭代的机器学习算法和交互式的数据挖掘。在这两类场景下，Spark的表现都比Hadoop MapReduce快100倍。

Spark也是Shark后台的引擎，Shark是一个与Apache Hive完全兼容的数据仓库，它的运行速度也是Hive的100倍。由于Spark是一个新的引擎，所以它能够访问Hadoop支持的所有数据源。

由于使用诸如YARN和HDFS等相同的底层基础架构，Spark能够无缝地与Hadoop 2.0生态系统集成（图9）并做为MapReduce的一种替代手段。GraphX和MLlib库包括可以实时运行的复杂图计算和机器学习算法。BlinkDB是一个大规模并行、运行交互式SQL查询的近似查询引擎，它为响应时间而对查询精确度做了妥协，其返回结果带有明确的的错误率注释。BlinkDB在2-10％的错误率下性能表现是Hive的200倍。

图9：Hadoop 2.0生态系统中的Spark

存储基础架构
以多媒体、文本等格式快速涌入的海量数据很难以行式及列式的数据库结构来装载。针对这类问题，产生了很多解决方案来满足程序员在开发使用大型数据集的社交、分析、游戏、金融和医学APP时对于扩展性和速度的需求。图10显示了用于存储海量数据的多种类型的数据库。

图10：存储基础架构

为了扩展数据库以应对数据在容量、速度和多样性的挑战，我们需要在多个服务期间进行水平扩展而不是对单个服务器进行升级（增加更多的内存或者增加硬盘的容量）来垂直扩展。但是水平扩展要用到将数据保存在不同位置的分布式架构。这样的设计就带来了所有分布式计算系统都共同面对的特定挑战：CAP理论［9］。根据CAP理论，一个分布式存储系具备分区容错能力（当任意信息丢失或者部分系统故障时系统还可以继续运行）时就需要牺牲一致性（所有人都能看到相同的数据）或者可用性（你可以随时读／写）。请注意分区容错性并不只是一个可选选项，因为当节点崩溃（无论什么原因）或者网络上有任意数量的包被丢弃（由于交换机故障或者其他原因）发生时就会导致分区的产生。当“分区”不可避免地发生时而且分布式系统的各个分区无法互相通讯时，问题就变成了是否要保持一致性（意味着只有在满足一致性时才能响应查询请求，而当一致性无法保障时就不响应查询请求，而这也就意味着会牺牲可用性）或者是否要保持可用性（意味着尽管有些不一致也会应答所有的查询）。

评判一个数据库的标准指标是它们的ACID属性：
• 原子性 一个交易的所有请求要么都完成要么都放弃。如果一个交易中有一部分失败，整个交易就会失败而数据库的状态会保持不变。
• 一致性 确保每一个交易都会把数据库从一个健全状态改到另一个健全状态。
• 隔离性 如果交易在持续执行时，能够确保在一个系统状态中获得同时执行的交易的结果。
• 持久性 意味着一旦一个交易被提交就会始终保持下来，即使发生掉电、崩溃或错误也不会受影响。
ACID专注于一致性是关系型数据所采取的传统方式。为了处理互联网及基于云计算的存储模型的需求，图谱的另一端是由Eric Brewer［10］提出的另一个设计理念，被称为BSAE：基本可用、软状态及最终一致性。多数NoSQL都是基于BASE原则的，也就是在CAP理论中选择C或者A。

下面的表汇总了最常见的数据库模型，列出它们的优势以及在CAP理论中他们对于一致性和可用性的取舍［8］。

                                           表1    用于大数据的数据库类型

图11 存储技术图

图12：数据库能够处理的数据复杂度vs 多种类型数据的规模

性能评估及代表性基准
如在本节的前面说讨论的，在过去的几年中多种数据库类型和NoSQL解决方案已经衍生分化成键／值存储、文档型数据库、图数据库和newSQL。由于这些解决方案针对不同的细分领域，所以试图评估数据库对于某个特定问题的表现就很重要但是也越来越困难。

不同的数据库使用不同的方法对数据进行存储和访问。一些数据库，诸如Couchbase和MongoDB，会试图运行在已经在内存中缓存了数据集的硬件上。另一些数据库，例如Aerospike所做的优化就是直接对固态盘（SSD）进行写操作，这就使它在涉及大量插入操作的场景下基准成绩突出。虽然内存数据库在延迟和吞吐量方面有很大的优势，当很大的数据集需要处理时就会发生扩展性的问题。SSD相比与内存则拥有更好的密度和更低的每GB成本，因此对于SSD数据库可以在较少的节点上扩展为更大的数据集 － 当数据集很大时则越有价值。通过增加更过内存型主机来进行扩展最终将导致更高的故障恢复成本，因为主机越多发生错误的概率越大。

除了用于存储数据及实现容错的不同技术，性能基准还要应对这样的一个事实即现实世界里各类的场景将会以所有的方式来访问并保持数据。在一个基准的研究中，测试了两个常见的情景：对持久性有很高要求的应用程序 － 每一个提交的交易必须写盘并复制以放节点故障；放宽对这些要求而追求速度尽可能高的应用程序［16］。另一个研究测试了包括只读交易、读写、只写［17］等等各种场景下所能达到的吞吐量和延迟指标。UC Berkeley AmpLab进行的研究针对特定类型的查询［18］做了在三个不同场景下Shark与一些代表性数据库的对比测试。

一般而言，在快速发展的业态下很难对性能有明确的阐述。性能严重依赖于所使用的查询引擎、存储架构及数据被保存的方式。图11代表了关于能力的一个宽泛分类而不应该被视为一个确切的排名。图12展示了考虑到存储的数据的复杂度及能够数据的数据量大小后不同数据库类型的对比。

分析
机器学习算法能够以自动且可扩展的方式对所收集的大型、多维数据进行洞察分析。广义上说，机器学习是指计算机具有对数据自动进行模式学习并得出推论的能力。这些算法可以根据很多不同的维度进行分类。

算法类型

图13展示了该分类。

图13：机器学习算法

监督式学习 － 这个类别包括所有将输入数据映射到给定的目标值或分类标签的机器学习算法。通常已知的算法包括对分类标签（类）进行预测的分类（Classification）和对连续值变量进行预测的回归/预测（regression/rediction）。在这些算法中，学习者利用一个大型的训练数据集生成一个源自一个类集的特征向量（分类的情况下）或值（回归的情况下）的映射函数。每一个数据点都有人工的标注是训练数据的必要条件。要获得可能数百万数据点的人工标注的成本降非常高，因此对于很多大数据应用程序而言这类标注不是完全可行的。但是，当今的很多大数据应用程序利用较小的训练数据集就能够取得对于现实世界的大规模、未标注数据集的最佳成果。在这个类别中一些最广泛使用的分类工具包括：神经网络、决策树、支持向量机和朴素贝叶斯；而回归／预测的算法则包括：线性回归、多项式回归、径向基函数，MARS和多线性插值。

无监督式学习 － 这个类别包括所有不需要相关的人工标签就可以对输入数据的隐含结构进行学习的机器学习算法。常用的算法包括聚类和源信号分离。输入数据的必要条件是存在能够在知识发现中发掘的代表性功能。这个技术特别适合于通过该学习框架能够很方便访问大量未标注数据集的大数据应用程序。本类别中一些广泛使用的工具包括K均值聚类，高斯混合模型，谱聚类，层次聚类，主成分分析，独立分量分析。

强化学习 － 这个类别包括所有学习观察与行动之间的映射函数从而使奖励函数值（译者注：奖励函数值即强化信号）最大的所有机器学习算法。该学习算法的优化目标是在一段时间内采取一个行动而去的最大的奖励。这类算法虽然在机器人领域很流行，但是现在大数据社区也取得了有限的进展。这个类别中广泛使用的工具包括马尔可夫决策过程和Q-learning。

半监督式分类 － 这个类别使用少量有标注的数据并把这些信息与大量无标注数据融合而实现一个适当的学习算法。由于存在大量用传统监督式学习无法很好地进行分析的无标注数据，大数据社区对于这类算法就特别感兴趣。另一方面，半监督式学习技术以一种有效的方式寻找已标注与未标注数据见的结构共性来生成对大型数据集的映射函数。在本分类中俄子项算法包括生成模型，基于图的模型和多视图模型。这个类别中一些最广泛使用的工具包括主动学习，迁移学习和合作培训。

数据挖掘的多样性
由于上面的分类适合于简单、结构化的数据集，所以复杂、非结构化数据集需要进一步的界定并从中获益。数据的多样性可以划分为六个宽泛的类别而之前一节所提到的机器学习算法也能够以多种方式进行适配并／或加强来应用到多种非结构化的数据集上。
• 时序数据 － 绝大多数大数据应用程序都对时间很敏感，因此对于时序数据采用可扩展的机器学习算法就变得很重要。时序数据是通过随着时间推移反复测量而得到的数值或事件序列，例如股票市场的数据。可以对时序数据进行成功建模的算法包括隐马尔可夫模型，马尔可夫随机场（时空建模）和条件随机域。将这些算法扩展到大数据领域是个热门的研究课题。最近，研究人员已经成功地扩展了一个传统的动态时间归整（DTW）算法来处理万亿量级的数据点。
• 流数据 － 数据持续抵达，例如，来源于远程传感器，零售交易，监控系统，互联网流量，和电信网络的数据。为了解决这类数据的需求，机器学习算法必须以一种在线的方式工作。多数机器学习算法需要对数据进行批处理，例如聚类需要一次性检查整个数据来学习有意义的类。这些技术对于流数据而言是不可扩展的，因为存储过去的数据在计算上是不可行的。现在，已经提出了一些针对流数据的与离线算法近似的分布式机器学习算法，其中包括分布的K－均值和分布的奇异值分解。一些包括Apache Mahout和Vowpal Wabbit在内的工具已经使用了这些算法。另一方面，有一些算法可以解决这些挑战，例如线性支持向量机，内核支持向量机算法，平行树学习。
• 序列数据 － 序列数据是由带有或不带有时间概念［19］的已经排序的要素或事件序列构成。序列数据的分析出现在许多不同的环境中，包括零售数据分析（确定客户购买一种类型的商品后是否还会购买另一种类型的商品），或分析基因和蛋白质序列。这里常用的机器学习算法经常包括隐式马尔可夫模型和序列比对算法（比如用于本地DNA序列比对的BLAST）。
• 图数据 － 很多问题都会自然建模成图，这些问题包括社交网络分析、万维网分析、生物网络分析及分析或合成蛋白质结构。几乎所有的大型图挖掘算法可以很有效地用矩阵来表示，进而有必要使用大规模的矩阵求解器。目前已经能够处理这种大规模数据的技术包括协同过滤、奇异值分解（SVD）、和网页排名（Page Rank）。旨在解决这一挑战的两个工具是Presto和GraphLab。
• 空间数据 – 空间数据库保存着与空间相关的数据，例如地图、医疗影像数据、远程传感器数据、VLSI芯片布局数据及其他。由于数据之间具有空间上的联系，所以这些数据不能视为完全独立的；学习算法可以掌握期间的联系。
• 多媒体数据 – 这个类别包括图像、视频、音频和文本标记。这个类别所使用的挖掘算法包括用于图像分割，运动矢量分析，模型构建的数字信号处理技术。

多样的数据分类很容易映射到不同垂直细分行业的特定应用场景；例如，金融行业会使用时序数据或者社交网络中的图数据。有些类别也可能会涵盖多种数据；例如大规模科学计算会涉及所有的数据类型和挖掘算法。

统计技术
机器学习并不是大数据意义的唯一范例。实际上统计技术在很长的时间里都是数据分析的标准方法。有人认为统计技术与机器学习技术之间的差别仅仅是术语不同而已。表二总结了在两个社区（机器学习社区和统计界）之间叫法不同的通用概念。

虽然有很多相似而且只是表面上的再造，但实际上机器学习算法完全不涉及概率或者统计；例如，支持向量机和神经网络。此外，大数据分析所涉及的数据往往也不仅是数据量巨大而且是多维的，因此计算问题也是需要重点考虑。同样机器学习算法也不得不关注传统统计公式所忽略的计算问题。因此，在很多方面，统计技术都被视为机器学习技术的一个子集。这会陷入对建模和推理感兴趣的统计学家与热爱算法和预测的机器学习专家之间的哲学讨论，也就超出了本文的范畴。

文献中经常使用的另一个术语是“数据挖掘”。这是一个很常见的术语，它是指从数据中进行推演和预测的全套技术。因此，机器学习技术是数据挖掘技术的一个子集，数据挖掘技术还包括人们由于推理和预测的可视化技术。

图14：机器学习的流程图

图14显示了用于在数据分析中决定用哪一类学习算法的基本流程图

评估分类和预测的指标
分类和预测可以通过以下五个主要的参数来评估：
• 准确性：指定的分类器或者预测因子能够对于新数据或者之前没有看到的数据（例如，没有分类标签信息的元组）进行正确预测的能力
• 速度：生成或者使用指定分类器和预测因子所涉及的计算成本
• 鲁棒性：当存在数据噪声或者数据值丢失时，分类器和预测因子能够正确预测的能力
• 可扩展性：对于大量的数据能够高效构建分类器和预测因子的能力
• 可解释性：对分类器和预测因子所能提供信息的理解和领悟等级（可解释性是很主观的因此很难评估）

分类器对于第一个指定的测试集的准确性是元组分类正确的百分率（这些有标签的元组之前并没有用于训练分类器）。同样，预测因子的准确性是指一个指定的预测因子对新数据或者之前没有看到的数据针对预测属性所猜测的值有多准。分类器的错误率或分类误判率是指其其余没有正确分类的元组所占的百分率。

一个分类器有m个分类，一个混淆矩阵（Confusion Matrix）是一个m x m的表。在该表中的一个条目CM i j 表示被标记为分类J的分类i的元组数量。如果一个分类器的准确性很高，大部分的非对角项就都被0填充。通过混淆矩阵可以计算其他的指标，例如精确度和灵敏度。

一个预测因子的准确性是由一个指标计算得来的，例如一个测试集的均方根误差。准确性可以使用一个或多个与训练集无关的测试集来进行评估，而且评估技术也需要探讨，例如交叉验证和自举。当一个学习者输出的分类器对于训练数据是100%准确但是对于测试数据的准确率是50%时，而它应该对两者的准确率为75%时，我们说该学习者过度拟合。过度拟合可以使用偏差和方差来测量。偏差是指一个学习者倾向学习同一个错误的东西而方差是学习者不顾真实的东西而倾向于学习随机的东西[38]。

学习者的泛化误差可以表示为偏差平方和方差的总和。因此，最小化泛化误差与同时最小化偏差和方差之间需要有所妥协。如果通过最小化方差来实现泛化误差最小化，则会导致偏差较大也就意味着严重欠拟合。如果偏差降低而方差升高，则会导致过度拟合。

可视化
最常用的大数据可视化技术大致可分为以下三类（图 15）。

图15： 可视化技术分类

抽象/汇总可视化 – 通常大数据分析在发现任何有意义的相关性之前都需要处理海量的数据（譬如，万亿条记录，TB级的数据）。在这个量级上对现有的可视化技术进行扩展不是一个容易的事情。后来出现了一类新的可视化技术，它们在通过可视化例程进行渲染之前会对海量数据进行处理和抽象／汇总［23］。这些技术被归入交互式可视化方法之下。数据抽象的常见例子是把数据用直方图分级或者以数据立方的方式展现。人们提出了很多聚类算法，用新型的概念把以分级为基础的数据进行了扩展。它们所带来的新优势是以更紧凑、降维的方式来展现数据。

交互式／实时可视化 － 交互式可视化范畴内有一类新型的技术，它们必须要实时地满足用户的交互需求。这些技术需要实时地支持客户对数据的探索，即使是复杂的可视化机制也要在一秒钟之内完成［24］。在允许用户在数据中快速发现重要的见解并且在这些见解之上证明或者反驳不用数据科学理论的场景下，这些技术则具有着非常强大的功能。这些技术对于以数据为驱动来进行洞察分析的行业也是非常关键的。今天诸如Tableau和微软的Pivot Table等很多行业软件对于交互式可视化都采用了类似的策略 。

安全和隐私
大数据的安全及隐私挑战被分解到大数据生态系统的四个方面中就如图16中所描绘的：
• 基础架构安全
• 数据隐私
• 数据管理
• 完整性及反应式安全

对大数据系统的基础架构进行安全防护设计将涉及对分布式计算和数据存储的安全防护。对数据本身的保护是很重要的，因为我们要在信息传播过程中取保对隐私的保护并且通过使用加密和颗粒化的访问控制来保护敏感数据。管理海量数据对于可扩展及分布式解决方案的需要不仅仅是对数据存储进行保护也需要对其进行有效的审计及数据来源调查。最终，未了确保基础架构的安全，必须对来自多种终端的数据流进行完整性检查从而可以将其用于对安全事件进行实时分析。

我们也将对之前介绍过的多种数据形式所带来的安全问题进行阐述。

流式数据 － 根据数据的公共与否，对于流式数据有两个互补的安全问题。对于公共数据，私密性不是问题但是对于个体使用者（例如，政府）需要制定过滤标准。对于私有数据，就需要关注私密性与此同时为了达成特定的目的也可以披露一些经过修改的数据，例如预测分析。

在《Private Searching On Streaming Data》［25］中，Ostrovsky和Skeith考虑了对流式数据的私有搜索问题，他们在多种加密假设条件下有效地对满足一个保密条件（例如隐藏关键字具有或者缺少一个密码组合）进行搜索。在他们的方案中，客户端能够把安全条件杂错转换后发送给过滤器节点。过滤器节点可以使用杂错条件把收到的数据加密形成加密的过滤消息，它只能由客户端解密。这使得在真实数据在过滤的过程中有效地隐藏了相关的条件。

流式时序数据的连续性质对隐藏这类数据中的敏感信息提出了特别的技术挑战。实际上，数据点的简单随机扰动不能提供严格的隐私保护。在《时间序列的可压缩性和隐私》中，Papadimitriou等人研究了时间序列的可压缩性和部分信息隐藏之间的取舍，而且通过对单个值进行扰动而带来的不确定性该如何进行却舍也做了研究。

图16 安全及隐私分类

图数据 － 在《Private analysis of graph structure》［27］中，Karwa等人提出的高效算在提供了严格的隐私保护下的同时也能够从图数据中发布有用的统计信息。他们的算法用于处理反映个体之间关系的数据集，例如社交联系或者电子邮件交流。该算法有效地隐蔽了任何特定关系的存在性或者缺失。具体而言， 该算法对子图计数查询返回恰当的答案。对于给定的查询图（例如一个三角形或者星形），其目标是返回输入图中查询图的同构副本的数量。

科学 － 通常科学数据不需要保密。然而，器的数据必须要确保数据的完整性，尤其是来自远端传感的数据。文献中提及的轻量级、短签名可以用于这类任务。这里有很多文献关于数字签名，例如着眼于短签名的生成文档［28］、［29］和［30］。

然而，在很多科学应用场景中传感器是部署在开放环境中，因此很容易受到物理攻击、可能会影响传感器的加密密钥。在［31］中，作者提出一个框架用来在大型传感器网络中进行安全地信息聚合，它消除了攻击者可以利用的关键弱点。在它们的框架中，传感器网络中的特定节点 － 称为聚合器 － 帮助对一个查询所请求的信息进行聚合。通过构建高效的随机抽样机制和交互式证明系统，即使聚合器和一小部分的传感器节点损坏时用户也能够验证聚合器给出的答案最大程度贴近真值。

Web － 可以部署一些标准的加密协议来保护web通信，其中包括TLS、Kerberos、OAuth、PKI、SeureBGP、NDSSEC（Secure NDS）、IEEE802系列协议、IPSec及移动通信中IPv6重路由安全。

但前，为了安全智能和预测，大数据分析也能够对web服务器所产生的日志进行分析。在NIST特刊 800-92［32］中，作者推荐了机构中关于日志数据的最佳实践。由于网络服务器、工作站和其他计算设备的广泛部署，以及对网络和系统的威胁不断增加，计算机安全日志的数量、数量和种类都大大增加了。这也提升了对于计算机安全日志管理的需求，安全日志管理即对计算机安全日志数据进行生成、传输、分析并处置的流程。一般的建议是组织内需要制定日志管理的策略和流程、在整个组织内合理定义日志管理的优先级、构建并维护一个日志管理的基础架构、为所有员工的日志管理职责提供必要的支持、并且制定日志管理的标准操作流程。

零售及金融数据 － 由于个人的零售和金融数据具有很强的隐私特征，所以在对数据进行存储和传输时需要始终尊崇行业的最佳实践。现在的一些实践是始终保持对数据的加密、在传输过程中及保存在基础架构中时需要确保对数据的访问具备正确的授权与认证。诸如PCI－DSS这样的金融行业合规性标准也阐述了安全最佳实践及法律要求。

这类数据的大量生成催生出了很多分析技术，进而也生成了很多对于第三方机构而言极富价值的信息，他们希望以此来为产品定位正确的人群。在实践中，这些数据需要经过匿名化和聚合过程来完全去除特别的身份信息后才能共享。这个过程往往是即席查询，在与公众开放数据［34］进行关联时基于经验性的证据［33］就可以实现很多“去匿名化”的实例。（译者注：去匿名化是一种数据挖掘策略，通过把匿名数据于其他数据来源做相互对照来重新识别出匿名数据来源。）分析结果共享的终极目标是没有私人信息能够被真实地看到。然而，第三方及研究机构通常希望做自己的研究于分析，为此提取有用且严格清洗过的数据仍然是一个挑战。

业界已经提出了一些用于解决隐私保护数据披露的正式模型［35］，其中最强的模型之一是差分隐私框架［36］。在“GUPT：privacy preserving data analysis made easy”中，作者介绍了称为GUPT的系统的设计及评估，该系统基于差分隐私确保用于应用程序的数据不会透露隐私。GUPT使用一个数据敏感度模型在整个过程中降低数据的隐私。它可以为不同的用户应用程序赋予不同的隐私等级，从而保证整体稳定的隐私等级并且实现应用程序的最大功效。

总结
我们首先给出了大数据领域进行分类的六个最重要的维度。这六个维度是数据域、计算基础架构、存储架构、分析、可视化、安全及隐私。大数据的基础架构和方法论还在保持着快速的发展势头，但是在很多场景中它们所依赖的底层技术已经在很多年前就已经发明了。人类活动的数字化和机器间通信的快速增长于大规模廉价硬件的结合，使得以前有关并行及分布式计算的学术思想得以实现，并且通过必要的优化使之在现实世界中的应用更加有益。

参考文档
[1] IBM Study, “StorageNewsletter » Every Day We Create 2.5 Quintillion Bytes of Data,” 21-Oct-2011. http://www.storagenewsletter.com/rubriques/market-reportsresearch/ibm-cmo-study/.
[2] J. Dean and S. Ghemawat, “MapReduce: simplified data processing on large clusters,” in Proceedings of the 6th conference on Symposium on Opearting Systems Design & Implementation - Volume 6, Berkeley, CA, USA, 2004, pp. 10–10.
[3] L. Valiant, “A bridging model for parallel computation,” CACM, vol. 33, no. 8, pp. 103–111, Aug. 1990.
[4] “Welcome to ApacheTM Hadoop®!” http://hadoop.apache.org/.
[5] S. Ghemawat, H. Gobioff, and S.-T. Leung, “The Google file system,” in Proceedings of the nineteenth ACM symposium on Operating systems principles, New York, NY, USA, 2003, pp. 29–43.
[6] J. Lin and C. Dyer, Data-Intensive Text Processing with MapReduce. Morgan & Claypool, 2010.
[7] “Hadoop Tutorial - YDN.” http://developer.yahoo.com/hadoop/tutorial/module4.html#dataflow.
[8] “Breaking Down ‘Big Data’ – Database Models – SoftLayer Blog.” http://blog.softlayer.com/2012/breaking-down-big-data-database-models/.
[9] “CAP theorem,” Wikipedia, the free encyclopedia. 16-Aug-2013.
[10] “CAP Twelve Years Later: How the ‘Rules’ Have Changed.” http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed.
[11] “Google Research Publication: BigTable.” http://research.google.com/archive/bigtable.html.
[12] “Amazon’s Dynamo - All Things Distributed.” http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html.
[13] “Graph database,” Wikipedia, the free encyclopedia. 21-Aug-2013.
[14] “New SQL: An Alternative to NoSQL and Old SQL for New OLTP Apps.” http://cacm.acm.org/blogs/blog-cacm/109710-new-sql-an-alternative-to-nosql-and-old-sql-for-new-oltp-apps/fulltext.
[15] Max De Marzi, “Introduction to Graph Databases,” 29-Apr-2012. http://www.slideshare.net/maxdemarzi/introduction-to-graph-databases-12735789.
[16] “Thumbtack Technology - Ultra-High Performance NoSQL Benchmarking: Analyzing Durability and Performance Tradeoffs.” http://thumbtack.net/whitepapers/ultra-high-performance-nosql-benchmark.html.
[17] T. Rabl, S. Gómez-Villamor, M. Sadoghi, V. Muntés-Mulero, H.-A. Jacobsen, and S. Mankovskii, “Solving Big Data Challenges for Enterprise Application Performance Management,” Proc VLDB Endow, vol. 5, no. 12, pp. 1724–1735, Aug. 2012.
[18] “Big Data Benchmark.” https://amplab.cs.berkeley.edu/benchmark/.
[19] J. Han, M. Kamber, and J. Pei, Data mining: concepts and techniques. Burlington, MA: Elsevier, 2012.
[20] R. Tibshirani, “Glossary of Machine learning and statistical terms.” Stanford University, 2012.
[21] B. Bederson and et. al., “Ordered and quantum treemaps: Making effective use of 2D space to display hierarchies.” https://www.researchgate.net/publication/220184592_Ordered_and_quantum_treemaps_Making_effective_use_of_2D_space_to_display_hierarchies.
[22] “Force-directed graph drawing - Wikipedia, the free encyclopedia.” http://en.wikipedia.org/wiki/Force-directed_graph_drawing.
[23] B. Shneiderman, “Extreme Visualization: Squeezing a Billion Records into a Million Pixels.” http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.145.2521.
[24] Z. Liu and et. al., “Stanford Vis Group | imMens: Real-time Visual Querying of Big Data.” http://vis.stanford.edu/papers/immens
[25] R. Ostrovsky and et. al., “Private Searching On Streaming Data.” http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.157.1127.
[26] S. Papadimitriou and et. al., “Time series compressibility and privacy.” http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.66.7150.
[27] V. Karwa and et. al., “Private analysis of graph structure.” http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.227.8815.
[28] D. Boneh and et. al., “Short Group Signatures.” http://crypto.stanford.edu/~dabo/abstracts/groupsigs.html.
[29] P. Gaborit and et. al., “Lightweight code-based identification and signature.” http://citeseer.uark.edu:8080/citeseerx/viewdoc/summary;jsessionid=410E9FDC4CC2BF40183250734B93BE7D?doi=10.1.1.131.3620.
[30] D. Boneh, B. Lynn, and H. Shacham, “Short Signatures from the Weil Pairing,” in Advances in Cryptology – ASIACRYPT 2001, C. Boyd, Ed. Springer Berlin Heidelberg, 2001, pp. 514–532.
[31] B. Przydatek and et. al., “SIA: secure information aggregation in sensor networks.” http://dl.acm.org/citation.cfm?id=958521.
[32] K. Kent and et. al., “Guide to Computer Security Log Management. SP 800-92.” http://dl.acm.org/citation.cfm?id=2206303.
[33] L. Sweeney, “k-anonymity: a model for protecting privacy.” http://dataprivacylab.org/dataprivacy/projects/kanonymity/kanonymity.html.
[34] A. Narayanan and et. al., “Robust De-anonymization of Large Sparse Datasets.” http://dl.acm.org/citation.cfm?id=1398064.
[35] B. Fung and et. al., “Privacy-Preserving Data Publishing: A Survey on Recent Developments.” http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.150.6812.
[36] C. Dwork, “Differential Privacy.” http://research.microsoft.com/apps/pubs/default.aspx?id=64346.
[37] P. Mohan and et. al., “GUPT: privacy preserving data analysis made easy.” http://dl.acm.org/citation.cfm?id=2213876.
[38] P. Domingos, “A few useful things to know about machine learning.” http://dl.acm.org/citation.cfm?id=2347755.
[39] “Spark | AMPLab – UC Berkeley,” AMPLab - UC Berkeley. https://amplab.cs.berkeley.edu/publication/.
[40] M. Zaharia, M. Chowdhury, M. J. Franklin, S. Shenker, and I. Stoica, “Spark: Cluster Computing with Working Sets,” in Proceedings of the 2Nd USENIX Conference on Hot Topics in Cloud Computing, Berkeley, CA, USA, 2010, pp. 10–10.