1.3.3 大数据技术
1.大数据处理
文献[81]指出，数据科学（data science）涉及通过原理、过程和技术来理解特定现象的数据（自动化）分析。从某种程度上说，数据科学的终极目标是改进决策支持，这在商界通常是最重要的。随着信息通信技术的发展，普通民众从各类媒体上获得的印象不同，人们通常认为的大多数数据处理实际上并不属于数据科学的范畴。数据领域的工程（engineering）和处理（processing）是数据科学得以开展的前提。具体来说，数据领域的工程和处理包含了大量的大数据技术，这些技术的进化和相互作用充实了数据科学的内涵和外延，造就了自动化的、由数据驱动的决策。
文献[82]首先给出大数据的概念，其次阐述大数据分析及其有益之处，然后给出了进行成功的大数据分析的必备条件，最后讨论了大数据领域的隐私保护。要实现成功的大数据分析，首先需要具备执行支持和赞助，这与大多数常规的分析类项目相同，例如商业智能（business intelligence）[83][84]。大数据分析的前提条件与常规的分析类项目的主要区别如下：
（1）清晰的商业需求
众所周知，潜在的项目应当是商业性质的，而并非由技术驱动。项目应当是为了满足具体的商业需求，例如解决一个具体的问题或者尝试抓住一个机会。文献[85]指出，在大多数商业机构和组织中，最初的大数据分析需求都关注于以消费者为导向的目标，使用已有的和新近获得的内部数据来构建与消费者的良好关系，进而改进商业运行模式并改善消费者的体验。针对上述观点，文献[86]指出成功的大数据分析倡议应当始于具体的或是严密定义的目标的集合，而不应当采用边走边看的方法，在构建模型的过程中逐步探索可能出现的结果。文献[87]对大数据分析在不同产业领域的应用案例进行了罗列：
·汽车保险（automobile insurance）[88]：价格调整、客户风险分析和欺诈检测等。
·电信技术（telecommunication）[89]：跨社交网络的服务模式分析、消费者社交网络的盈利状况和客户流失最小化（churn minimization）。
·制造、分发和零售（manufacturing，distribution and retail）[90]：跟踪货架可用性、评估促销展示的影响、评估促销活动的有效性，以及库存管理、价格调整和点击量分析。
·交通和物流（transportation and logistics）[91]：实时的车队管理和RFID资产跟踪。
·公共事业（utility）[92]：分析智能电网数据来确定可变的价格模型，分析海量智能仪表的数据来预测能源需求、设计定制化的资费方案。
·游戏行业（gaming）[93]：分析游戏体验来给游戏研发者提供反馈，找寻游戏中的增值服务推销机遇。
·执法机关（law enforcement）[94]：分析人与人之间的关联来识别出潜在且容易制造麻烦的群体，确定个体或组织的位置。
（2）强大且坚定的资助
没有强大的资助，任何IT项目都难以获得成功，大数据分析项目也不例外。如果项目在企业中是部门级别的，那么通常由独立的部门进行资助。如果项目的战略意义重大，涉及整个企业，那么应当得到高级管理者的支持。文献[85]指出，在企业接纳大数据的初期，首席信息官（Chief Information Officer，CIO）通常主导了所需的经费，而随着相关的技术基础设施逐步完善，企业从上到下均认识到大数据带来的商业价值之后，资助转变为由涉及特定功能需求的主管来决定，例如首席营销官（Chief Marketing Officer，CMO）、首席财务官（Chief Finance Officer，CFO）和首席执行官（Chief Executive Officer，CEO）。
（3）商业活动与分析策略的匹配
在实施大数据分析项目前，务必要确定其所支持的商业战略。这也是绝大多数大数据分析项目是由商业决策而非IT部门决定的原因。对于基于分析的商业组织来说，实际上商业活动和分析策略是相辅相成、缺一不可的。如果没有分析与相应的决策，商业战略是不可能获得成功的。在这方面，在线零售商巨头是最佳的典范，例如淘宝、京东、当当网和亚马逊。为众人所熟知的分析案例是产品推荐，当消费者浏览零售商的网站时，推荐引擎将消费者的查找关键字、历史点击情况、购物车内容分析、在其他店铺的历史消费情况和当前产品性价比等进行综合考量，然后给用户推送最容易达成交易的产品名目。不为公众所熟知的商业智能应用包括报表（reporting）、数据实时监测（dashboard）、计分卡（scorecard）、需求预测（demand forecasting）、价格调整（pricing）、产品返修分析（produce return analysis）、细分市场分析（market segmentation analysis）、营销活动管理（campaign management）和搜索引擎优化（search engine optimization）。
（4）基于事实的决策文化
机构或者组织要从大数据分析中获益，那么其所做的决定必须基于“事实”（即由分析产生的结果）。此外，必须持续进行验证以确定怎样做才是最好的。一般来说，改变如何进行决策的文化要比解决技术问题更具有挑战性。例如“奥克兰运动家队”（Oakland Athletics）和比利·比恩（Billy Beane）经理的故事[95]，为了推行新的分析方法，比恩不得不挑战拥有多年棒球经验的反对者的权威和影响力。现在，每个竞技体育团队都依赖大数据分析来做各类决定，例如在美式足球中什么时候做出两分转换（two-point conversion）。
（5）优秀且强大的数据基础设施
数据对商业智能和分析来说是至关重要的。当拥有优秀且强大的数据基础设施时，各类应用程序通常可以在数天内研发完成。相反，缺乏良好的数据基础设施会导致应用程序的研发无法进行。一般来说，IT部门十分清楚数据基础设施的重要性，但其他部门通常默认数据基础设施是已有的，并且不乐于协助提供需要创建和维护数据基础设施所需的各类资料。优秀且强大的数据基础设施涵盖了如下要点：技术革新（technology advance）、数据仓库（data warehouse）、数据集市应用程序（data mart application）、分析沙盒（analytical sandbox）、内存中的分析（in-memory analytics）、数据库中的分析（in-database analytics）、列式数据库（columnar database）、流式处理引擎和复杂事件处理引擎（streaming and complex event processing engine）、基于云的服务（cloud-based service）、Hadoop和MapReduce、非关系数据库（non-relational database）以及平台的选择和集成（platform selection and integration）。
（6）正确的分析工具
尽管传统的商业智能供应商宣称他们的产品支持数据挖掘和数据预测两个方面的分析，但实际使用过程中的情况通常不能令人满意，例如将数据进行简单的分割、转化和可视化并不是数据挖掘。数据挖掘需要使用包含复杂算法和过程的软件工具，这些复杂算法和过程的设计初衷就是为了寻找数据中隐藏的关系。在分析软件领域，统计分析系统（Statistical Analysis System，SAS）[1]以及统计产品与服务解决方案（Statistical Product and Service Solution，SPSS）[2]是这方面的先驱。统计分析系统是由多个专业模块构成的，例如数据的访问、存储、分析、报表、图形、预测等。这些模块共同支持以数据为中心的四大任务：数据访问、数据管理、数据呈现和数据分析。统计产品与服务解决方案在2000年之前的名称为社会科学统计软件包（Statistical Package for the Social Sciences，SPSS）。目前，统计产品与服务解决方案的研发由IBM公司主导，其具有完善的数据输入、分析、报表等功能，具有完善的数据接口以及功能模块。同类的统计分析产品还有RapidMiner[3]、Minitab[4]、R[5]和GNU PSPP[6]等。
（7）优秀的分析人员
尽管大数据分析的主要环节和操作目前都实现了自动化，但具有扎实专业基础知识以及从业经验的分析师仍然必不可少。文献[96]指出，在大数据分析与应用的领域，数据科学家和终端用户之间必不可少的连接纽带就是数据分析师。一般来说，数据分析师分为两类：商业智能分析师（business intelligence analyst）和企业分析师（enterprise analyst）。商业智能分析师隶属于商业智能分析部门，其面向整个组织架构开展工作。企业分析师在各个部门从事数据分析工作，例如策划与运营部、市场部以及后勤部等。商业智能分析师对整个组织架构的数据以及相关数据分析工具的认知通常要优于企业分析师。例如，商业智能分析师可以设计和实现企业范畴的计分表系统，管理信息系统（Management Information System，MIS）专业的毕业生比较适合商业智能分析师这个职位。企业分析师对自身所在部门的数据和相关数据分析工具更加熟悉一些。例如，供应链分析师能够通过分析对供应链进行过程优化，其中包含了原材料选购、物流运输、仓储管理和产品分发等环节。绝大多数组织都同时拥有这两类分析师，他们在日常工作中各司其职并互相合作。
2.三代大数据处理技术
文献[97]给出了大数据处理技术发展的时间线，并将大数据处理技术的发展划分为三代：批处理（batch processing）、实时处理（real-time processing）和混合计算（hybrid computation）。
（1）批处理
第一代大数据处理技术批处理始于2003年，彼时谷歌（Google）发表了关于谷歌文件系统（Google File System，GFS）[98]和分布式计算框架（MapReduce framework）[99]的论文。2005年，Doug Cutting基于谷歌文件系统GFS和分布式计算框架MapReduce的论文研发了Hadoop[100]。在此后的一段时间内，业界的商业巨头和各类组织均未遇到切实的大数据问题，因此可以认为第一代大数据处理实际上始于2006年，彼时Hadoop刚刚诞生不久[101]。2008年，雅虎（Yahoo）发布了Hadoop的一个稳定版本，并开始着手在MapReduce之上的抽象层进行工作。同样是在2008年，雅虎发布了Hadoop体系结构中的一个重要组件Pig[102]。此外，Facebook在2009年发布了Hadoop体系结构中的另一个重要组件Hive[103]。此后，Hadoop以其可靠性和稳定性在批处理领域赢得了广泛的应用。目前，Hadoop是批处理技术领域中的事实标准（de facto），且批处理领域未见更新的研究进展。
批处理技术是用来处理海量静态（static）数据的。换言之，批处理所处理的数据是系统中已经存储过的数据。对于已经启动的批处理任务，新产生的数据不再参与处理过程。批处理技术所对应的系统的主要特点是可扩展性。为了更好地应对大数据的海量规模，进而获得高可扩展性，批处理技术大多采用并行的分布式处理架构，例如著名的MapReduce。MapReduce技术具有如下优点：1）给出了简单且统一的数据视图；2）与生俱来的可扩展性；3）针对影响分布式软件编写的诸多挑战因素（例如潜在的硬件失效、网络状态的波动和设备的异质性），MapReduce极大程度地屏蔽了编程的复杂性。除了上述优点，MapReduce在特定的应用环境下还具有一些不足[104]，例如，针对大多数实时性系统和应用的数据分析事务通常都需要迭代运行若干次。这对原始的MapReduce来说是无法实现的。对于该问题，学界和业界已有一些相关的改进方案[105][106][107][108]。此外，对于用户日益增长的数据分析需求，如何更好地实现高效的数据处理，需要针对实时性、流计算、数据的访问与索引化等进行改进。总体来说，批处理技术具有良好的可靠性，但批处理的过程通常需要较长的时间来完成。因此，批处理技术无法适用于时延要求低的应用。如前所述，批处理在启动之后无法对新的数据进行处理，其不能在执行过程中被中断或者重配置。
（2）实时处理
第二代大数据处理技术实时处理始于2010年，彼时以雅虎和推特（Twitter）为代表的全球性公司面临不仅要处理海量静态数据，还要处理海量的实时数据或流数据的难题。于是，雅虎在2010年研发了名为分布式流计算平台（distributed stream computing platform）的框架[109]，简称S4。该框架是第一个面向实时处理的解决方案。第二代大数据处理技术的另一个里程碑是面向分布式容错实时计算（distributed and fault-tolerant real-time computation）的Storm[110]。2011年，Nathan Marz开发了Storm框架，并由推特以开源的形式发布。类似地，作为一个创始于2008年的Hadoop数据管理软件与服务提供商，Cloudera在2011年发布了日志收集系统Flume[111]，该系统是一个面向海量数据的、具备高可用性和高可靠性的分布式日志采集和聚合系统。领英（Linkedin）在2011年发布了一个分布式流处理平台Kafka[112]，该平台是一种高吞吐量的分布式发布/订阅消息系统。此外，领英还在2013年研发了针对状态可扩展的流处理（stateful scalable stream processing）的Samza[113]技术。谷歌在2013年针对因特网规模的容错流处理研发了Millwheel[114]技术。目前，实时处理技术正在持续发展中，新型的技术也在不断地涌现出来，但是还没有类似批处理领域中的Hadoop的事实标准。
实时处理技术主要针对的是大数据的速度（Velocity）特性。换言之，实时处理能够以较低的时延来处理流数据。这类处理技术在分布式和并行化方面或多或少借鉴了与批处理技术相同的设计理念，而为了获得较低的时延，实时处理技术还对存储在内存（memory）中的小规模数据集进行分析。因此，实时处理技术类似于小型化批处理的无限序列，其中需要处理的数据来源于内存/主存（primary storage），而不是辅存（secondary storage）。在具体实现中，实时处理技术采用的是无盘化（diskless）技术。目前，面向异质数据源的流数据处理得到了广泛的应用，常见的案例如下：1）智慧城市（Smart City）中的交通指挥、能源供给、视频监控和垃圾收集等；2）舆情管理（public opinion management）中的移动设备定位、社交网络分析、音视频甄别和灾害预警等；3）生产和物流（production and logistics）中的工业传感器管理、品质控制、质量溯源、生产优化、物流优化等；4）影音娱乐，包括广告推送、游戏平台、电视频道和音频广播等。
（3）混合计算
第三代大数据处理技术混合计算始于2012年，其标志为Nathan Marz研发了拉姆达体系结构（Lambda architecture）[115]。拉姆达体系结构是一个实时的大数据处理框架，其基本理念如下：大数据系统的架构分为三个层次，即批处理层（batch layer）、服务层（service layer）和实时处理层（speed layer），其能够满足实时大数据系统的关键性要求，例如高容错性、低延时性和高扩展性等。目前，混合计算方面的相关技术在保持发展，学界和业界认为其将是未来十年内极具挑战性的研究领域。
混合计算技术的出现源于众多应用领域都对批处理技术与实时处理技术的结合存在需求，因此产生了拉姆达体系结构这个混合处理模型。在拉姆达体系结构中，批处理层管理主要数据集，通常该数据集存储在分布式文件系统中，并且其数据是不可变的（unchangeable）。服务层从数据仓库中加载数据并生成批处理视图，负责为各类查询提供批处理的结果。实时处理层只针对有低时延需求的应用所涉及的新数据进行处理。一般来说，为了获得完整的数据分析结果，需要对批处理视图和实时处理视图都进行查询，然后将结果进行合并（merge）。此时，需要对同步、结果组合以及模块协调（module coordination）等事务进行处理。换言之，在混合计算模型中，批处理技术对所有现存的数据进行处理，以产生批处理结果。批处理对整个数据集进行循环式的处理，单次执行需要较长的时间，因此新的数据只能等待下一次批处理任务时再加入数据集进行处理。针对批处理耗时较长这个问题，引入实时处理技术进行弥补。实时处理技术对新的数据进行实时处理，以产生流处理结果。与批处理技术不同，实时处理技术仅对新数据进行处理，即未被批处理任务分析过的数据。合并上述两个结果，可以形成最终的结果。
3.大数据处理的生命周期和典型工具
大数据处理的各项技术通常都涉及整个大数据的生命周期。文献[116]提出了一种科学数据生命周期管理（Scientific Data Lifecycle Management，SDLM）模型，分析了现代数据管理中涉及的主要阶段以及反映出的具体细节。此外，该文献还提出了科学数据基础设施（Scientific Data Infrastructure，SDI）模型，并为大数据的研究者提供了建立交互类数据项目的基础。文献[117]对大数据生态系统体系结构中所涉及的构件进行了详细的阐述，并通过对相关重要构件的分析总结出了大数据所面临的主要挑战。此外，其还给出了大数据生态系统中大数据的生命周期。具体来说，从数据的产生到数据的最终消费包含以下环节：数据源（data source）、数据采集与注册（data collection and registration）、数据过滤与分类（data filter and classification）、数据分析与建模（data analytics and modeling）、数据可视化（data visualization）以及数据消费者（data consumer）。文献[118]中阐述的DataONE模型指出数据生命周期包含如下的闭环阶段：采集（collect）、确保（assure）、描述（describe）、保存（preserve）、发现（discover）、集成（integrate）、分析（analyze）和计划（plan），计划阶段所得到的方案与结论又反馈给采集阶段，如此往复，形成闭环。
文献[97]将大数据的生命周期分为数据获取（data acquisition）、数据存储（data storage）、数据分析（data analysis）以及结果（result），并且将前述大数据处理的三代技术中相关的工具映射至数据获取、数据存储和数据分析三个环节来进行分类讨论，详情如表1-2所示。在数据获取阶段，通常涉及从多源异构的数据源获取数据，这些数据源可能是批处理数据源，也有可能是实时流数据源；在数据存储阶段，需要对前一阶段已经获取到的数据进行存储，以便进行后续的分析与处理，常见的存储方式有磁盘（disk）形式和无盘（diskless）形式。在数据分析阶段，针对不同的应用需求，会运用各类模型和算法来对数据进行分析与处理。在表1-2中，三代技术中不同的处理阶段所涉及的工具存在重叠。此外，对于混合计算技术，其本身同时涉及批处理技术和实时处理技术，实现混合计算模型的技术也要比单纯的批处理技术和实时处理技术更加复杂；鉴于混合计算技术的上述特点，这里不对在数据的获取、存储与分析方面所涉及的具体工具做特别的划分。
表1-2 大数据处理的典型工具
（1）HDFS
Hadoop[7]分布式文件系统（Hadoop Distributed File System，HDFS）目前是Apache Hadoop项目的一个子项目，与已有的分布式文件系统有很多相似之处。此外，作为专门针对商业化硬件（commodity hardware）设计的文件系统，HDFS的独特之处也很明显：首先其具有很高的容错性，其次可以部署在较为廉价的硬件上，最后能够提供高吞吐量的应用数据访问能力。对于终端用户而言，HDFS就是一个传统的文件系统，具有文件和目录的创建、修改、删除等常规操作。HDFS采用主/从（Master/Slave）体系结构。单个HDFS集群仅包含一个名称节点（NameNode），其提供元数据服务，管理文件系统的命名空间（namespace），并引导用户对文件的访问。此外，单个HDFS集群可以包含多个数据节点（DataNode），数据节点负责管理与自身相关联的存储空间。HDFS对外给出文件系统的命名空间作为用户对数据进行访存的接口。在HDFS内部，单个文件通常被分割成多个块（block），这些块存储在一系列数据节点上。由名称节点在整个HDFS集群的命名空间上执行文件和目录的打开、读取和关闭等操作。文件的块与数据节点之间的映射也是由名称节点管理的。数据节点基于名称节点的指令来实施块的创建、复制和删除等。
（2）Sqoop
Sqoop[8]是一个在Hadoop和关系数据库服务器之间传送数据的工具，方便大量数据的导入导出工作，其支持多种类型的数据存储软件。Sqoop的核心功能为数据的导入和导出。导入数据：从诸如MySQL、SQL Server和Oracle等关系数据库将数据导入到Hadoop下的HDFS、Hive和HBase等数据存储系统。导出数据：从Hadoop的文件系统中将数据导出至关系数据库。Sqoop的一个显著特点是可以使用MapReduce将数据从传统的关系数据库导入到HDFS中。Sqoop作为一个通用性的工具，只需要在一个节点上安装，因此安装和使用十分便捷。
（3）Flume
Flume是由Hadoop生态系统中著名的软件公司Cloudera于2011年发布，该软件能够支持分布式海量日志的采集、集成与传输，以实时的方式从数据发送方获取数据，并传输给数据接收方。Flume具有两个显著的特点：可靠性和可扩展性。针对可靠性，其提供了从强到弱的三级保障，即End-to-end、Store on failure和Best effort。针对可扩展性，其采用三层的体系结构，即Agent、Collector和Storage，每层都可以在水平方向上进行扩展。Flume以Agent的方式运行，单个Agent包含Source、Channel和Sink三个组件，由Agent对数据进行收集，然后交付给存储机制。从多个数据源收集到的日志信息依次经过上述三个组件，然后存入HDFS或HBase中。因此，通过Flume可以将数据便捷地转交给Hadoop体系结构。
（4）Scribe
Scribe[9]是由Facebook开发的分布式日志系统，在Facebook内部已经得到了广泛的应用。Scribe能够针对位于不同数据源的日志信息进行收集，然后存储至某个统一的存储系统，这个存储系统可以是网络文件系统（Network File System，NFS），也可以是分布式文件系统。Scribe的体系结构由三部分组成：Scribe Agent、Scribe和Storage。第一部分Scribe Agent为用户提供接口，用户使用该接口来发送数据。第二部分Scribe接收由Scribe Agent发送来的数据，根据各类数据所具有的不同topic再次分发给不同的实体。第三部分Storage包含多种存储系统和介质。Scribe的日志收集行为只包括主动写入的日志，Scribe自身没有主动抓取日志的功能。因此，用户需要主动向Scribe Agent发送相关的日志信息。
（5）HBase
HBase[10]的全称为Hadoop Database，是基于谷歌BigTable的开源实现，其使用Hadoop体系结构中的HDFS作为基本的文件系统。谷歌根据BigTable的理念设计实现了谷歌文件系统GFS，但是该方案未开源。HBase可以称为BigTable的山寨版，是开源的。HBase在Hadoop体系结构中的位置介于HDFS和MapReduce之间，其架构为主/从形式，内部的两个核心构件为Master和RegionServer。HBase是建立在HDFS之上的分布式面向列的数据库，能够针对海量结构化数据实现随机的实时访问，其设计理念和运行模式都充分利用了HDFS的高容错性。由于HBase是面向列的，因此它在数据库的表中是按照行进行排序的。在HBase中，所有的存储内容都是字节，任何要存储的内容都需要先转换成字节流的形式，此外数据库的行键值按照字节进行排序，同时形成了索引。
（6）MapReduce
MapReduce[11]是Hadoop体系结构中极为重要的核心构件之一。作为一个分布式的并行计算模型，MapReduce包含的两个单词分别具有特定的含义：“Map”表示“映射”；“Reduce”表示“归约”。上述两个概念的基本理念源于函数式编程语言（functional programming language）。与传统的编程语言不同，函数式编程语言是一类非冯诺依曼式的程序设计语言，其编程范式的抽象程度很高，主要由原始函数、定义函数和函数型构成。MapReduce的这种设计思想使分布式并行程序设计的难度得以简化，用户将已有的代码稍加修改就能够运行在分布式环境下。在实际应用场景中，大多数情况下收集到的大量多源异构数据都不具有特定的规律和特征。MapReduce的工作过程能够在一定程度上将上述数据按照某种规律进行归纳和总结。在“Map”阶段，通过指定的映射函数提取数据的特征，得到的结果的形式为键值对<key,value>。在“Reduce”阶段，通过指定的归约函数对“Map”阶段得到的结果进行统计。对于不同的具体问题，所需要的归约函数的个数可能千差万别。总体来说，MapReduce具有开发难度低、扩展性强和容错性高三个显著特点。尽管其分布式并行计算模型能大幅度提高海量数据的处理速度，但受限于大数据的规模，通常MapReduce的作业例程的执行时间为分钟级，随着数据量的增加，耗时若干天也很普遍。
（7）Hive
Hive[12]针对数据仓库来提供类似SQL语句的查询功能，其能够将以结构化形式存储的数据映射成数据库表，主要应用场景为多维度数据分析和海量结构化数据离线分析。Hive的体系结构主要包含用户接口、元数据存储、解释器、编译器、优化器和执行器。虽然使用MapReduce也能够实现查询，但是对于逻辑复杂度高的查询，用户在实现时难度较大。Hive提供类似于SQL的语法接口，降低了学习成本，提高了开发效率。Hive基于SQL的语法来定义名为HiveQL或HQL的查询语言，其支持常规的索引化和基本的数据查询，更重要的是能够将基于SQL的查询需求转化为MapReduce的作业例程。除了自身具有的功能之外，用户可以在Hive中编写自定义函数，具体来说分为三种：用户自定义函数（User Defined Function，UDF）、用户自定义聚合函数（User Defined Aggregation Function，UDAF）和用户自定义表生成函数（User Defined Table-generating Function，UDTF）。
（8）Pig
Pig[13]是一个面向过程的高级程序设计语言，能够分析大型数据集，并将结果表示为数据流，其内置了多种数据类型，并且支持元组（tuple）、映射（map）和包（package）等范式。Pig有两种工作模式：Local模式和MapReduce模式。在Local模式下，Pig的运行独立于Hadoop体系结构，全部操作均在本地进行。在MapReduce模式下，Pig使用了Hadoop集群中的分布式文件系统HDFS。作为一种程序设计语言，Pig能够对数据进行加载、处理，并且存储获得的结果。Pig和Hive均能够简化Hadoop的常见工作任务。Hive通常应用在静态数据上，处理例行性的分析任务。Pig比Hive在规模上更加轻量，其与SQL的结合使得用户能够使用比Hive更加简洁的代码来给出解决方案。与MapReduce相比，Pig在接口方面提供了更高层次的抽象，具有更多的数据结构类型。此外，Pig还提供了大量的数据变换操作，MapReduce在这方面比较薄弱。
（9）Cascading
Cascading[14]是用Java语言编写成的开源库，能够脱离MapReduce来完成对复杂数据工作流的处理。该开源库提供的应用程序编程接口定义了复杂的数据流以及将这些数据流与后端系统集成的规则。此外，其还定义了将逻辑数据流映射至计算平台并进行执行的规则。针对数据的提取、转换和加载（Extract Transform Load，ETL），Cascading提供了6个基本操作：复制（copy）、过滤（filter）、合并（merge）、计数（count）、平均（average）和结合（join）。初级的ETL应用程序通常涉及数据和文件的复制，以及不良数据的过滤。针对多种不同数据源的输入文件，需要对它们进行合并。计数和平均是对数据和记录进行处理的常用操作。结合指的是将不同处理分支中的处理结果按照给定的规则进行结合。
（10）Spark
与Hadoop类似，Spark[15]也是一个针对大数据的分布式计算框架。Spark可以用来构建大规模、低延迟的数据处理应用程序。相对于Hadoop，Spark的显著特点是能够在内存中进行计算，因此又称为通用内存并行计算框架，与MapReduce兼容，其主要构件包括SparkCore、SparkSQL、SparkStreaming、MLlib、GraphX、BlinkDB和Tachyon。Hadoop存在磁盘I/O和序列化等性能瓶颈，在Spark的设计理念中，选用内存来存储Hadoop中存储在HDFS的中间结果。Spark兼容HDFS，能够很好地融入Hadoop体系结构，被认为是MapReduce的替代品。根据Spark官方网站的数据，Spark的批处理速度比MapReduce提升了近10倍，内存中的数据分析速度则提升了近100倍。Spark模型所特有的弹性分布式数据集（Resilient Distributed Dataset，RDD）使得针对数据的灾难恢复在内存和磁盘上都可以实现。总体来说，Spark的编程模型具有以下四个特点：速度（speed）、简易（ease of use）、通用（generality）和兼容（runs everywhere）。在速度方面，Spark使用基于有向无环图（Directed Acyclic Graph，DAG）的作业调度算法，采用先进的查询优化器和物理执行器提高了数据的批处理和流式处理的性能。在简易方面，Spark支持多种高级算法，用户可以使用Java、Scala、Python、R和SQL等语言编写交互式应用程序。在通用方面，Spark提供了大量的通用库，使用这些库可以方便地开发出针对不同应用场景的统一解决方案，极大地降低了研发与运营的成本。在兼容方面，Spark本身能够方便地与现有的各类开源系统无缝衔接，例如已有的Hadoop体系结构中的HDFS和Hbase。
（11）Shark
作为一个面向大规模数据的数据仓库工具，Shark[16]最初是基于Hive的代码进行开发的。Hive在执行交互查询时需要在私有数据仓库上执行非常耗时的ETL操作，为了弥补这个性能问题，Shark成了Hadoop体系结构中的首个交互式SQL软件。Shark支持Hive包含的查询语言、元存储、序列化格式以及自定义函数。后来，Hadoop体系结构中MapReduce本身的结构限制了Shark的发展，研究者们中止了Shark的研发，启动了Shark SQL这个新项目。Shark SQL是基于Spark的一个组件，提供了针对结构化数据的便捷操作，统一了结构化查询语言与命令式语言。Shark在Spark的体系结构中提供了和Hive相同的HiveQL编程接口，因此与Hive兼容。通过Hive的HQL解析，将HQL转换成Spark上的RDD操作。
（12）Kafka
Kafka[17]是一个分布式流处理平台（distributed streaming platform），最初由领英公司开发，使用的编程语言是Java和Scala。Kafka支持分区（partition）和副本（replica），针对消息队列进行处理。消息传送功能包含连接服务（connection service）、消息的路由（routing）、传送（delivery）、持久性（durability）、安全性（security）和日志记录（log）。Kafka的主要应用程序接口有如下四类：生产者（producer API）、消费者（consumer API）、流（stream API）和连接器（connector API）。Kafka对外的接口设计理念是基于话题（topic）的，消息生成后被写入话题中，用户从话题中读取消息。单个的话题由多个分区构成，当系统性能下降时，通常的操作是增加分区的个数。分区之间的消息互相独立，每个分区内的消息是有序的。新消息的写入操作在具体实现中为相应文件内容的追加操作，该方式具有较强的性能。由于一个话题可以包含多个分区，因此Kafka具有高吞吐量、低延迟的特性。消息队列包含两个模型：点对点（point-to-point）和发布/订阅（publish/subscribe）。对于点对点模型，消息生成后进入队列，由用户从队列中取出消息并使用。当消息被使用后，其生命周期已经结束，即该消息无法再次被使用。虽然消息队列支持多个用户，但一个消息仅能够被一个用户所使用。对于发布/订阅模型，消息生成后其相关信息会被发布到多个话题中，只要订阅了相关话题的用户就都可以使用该消息。与点对点模型不同，在发布/订阅模型中一个消息可以被多个用户使用。
（13）Kestrel
Kestrel是由推特（Twitter）开发的开源中间件（middleware），使用的编程语言为Scala，其前身是名为Starling的轻量级分布式队列服务器，同样Kestrel也具有轻量化的特点。Starling支持MemCache协议，其能够方便地构建网络访问队列。推特早期使用Starling来处理大量的队列消息，后来推特将基于Ruby语言的Starling项目进行重构，使用Scala语言将其重新实现，得到Kestrel。在协议支持性方面，Kestrel支持三类协议：MemCache、Text和Thrift，其中MemCache协议没有完整地实现，仅支持部分操作。Kestrel本身运行在Java虚拟机（Java Virtual Machine，JVM）上，针对Java的各类优化措施均可以使用。为了改善性能，Kestrel中的队列存储在内存中，针对队列的操作日志保存在硬盘中。虽然Kestrel本身是轻量化的，但其具有丰富的配置选项，能够很方便地组成集群，集群中的节点互相之间是透明的，针对队列中消息获取的GET协议支持阻塞获取和可靠获取。阻塞获取是指用户可以设置超时时间，在时间内有消息的话即刻返回，如果超时后还没有消息就结束等待。可靠获取是指队列服务器只有在收到用户明确的确认反馈后，才将相关的消息从队列中永久删除。如果用户使用GET操作从队列获取消息后队列服务器马上将该消息从队列中删除，那么此后需要用户来确保该消息不会异常丢失，这对网络状态和系统运行的特定环境要求较为苛刻。因此，用户可以采用可靠获取的方式来消除上述疑虑。
（14）Storm
Storm[18]编写而成的分布式实时处理系统，其雏形是由Nathan Marz和BackType构建的，BackType是一家社交数据分析公司。2011年，推特收购BackType，并将Storm开源。Storm的主要功能是针对持续产生的数据流进行计算，进而弥补了Hadoop体系结构对实时性支持的缺失。Storm的处理速度快，具有良好的可扩展性和容错性，其所处理的数据位于内存中。用户在Storm中设计的计算图称为拓扑（topology），拓扑中包含主节点和从节点，且以集群的形式呈现。Storm的主/从体系结构是由两类节点实现的：控制节点（master node）和工作节点（worker node），调度相关的信息以及主从节点的重要工作数据都是由ZooKeeper集群来负责处理的。控制节点为主节点，其上运行的Nimbus进程主要负责状态监测与资源管理，该进程维护和分析Storm的拓扑，同时收集需要执行的任务，然后将收集到的任务指派给可用的工作节点。工作节点为从节点，其上运行的Supervisor进程包含一个或多个工作进程（worker），工作进程根据所要处理的任务量来配置合理数量的执行器（executor）以便执行任务。Supervisor进程监听本地节点的状态，根据实际情况启动或者结束工作进程。拓扑中的数据在喷嘴（spout）之间传递，喷嘴把从外部数据源获取到的数据提供给拓扑，因此是Storm中流的来源。数据流中数据的格式称为元组（tuple），具体来说为键值对（key-value pair），元组用来封装需要处理的实际数据。针对数据流的计算逻辑都是在螺栓（bolt）中执行的，具体的处理过程中除了需要指定消息的生成、分发和连接，其余的都与传统应用程序类似。
（15）Trident
Trident[19]是位于Storm已有的实时处理环境之上更高层的抽象构件，提供了状态流处理和低延迟的分布式查询功能，其屏蔽了计算事务处理和运行状态管理的细节。此外，还针对数据库增加了更新操作的原语。在Trident中，数据流的处理按照批次进行，即所谓的事务。一般来说，对于不同的数据源，每个批次的数据量的规模可达数百万个元组。一个处理批次称为一个事务，当所有处理完成之后，认为该事务成功结束；当事务中的一个或者多个元组处理失败时，整个事务需要回滚（rollback），然后重新提交。Trident的事务控制包含三个层次：非事务控制（non-transactional）、严格的事务控制（transactional）和不透明的事务控制（opaque-transactional）。对于非事务控制，单个批次内的元组处理可以出现部分处理成功的情况，处理失败的元组可以在其他批次进行重试。对于严格的事务控制，单个批次内处理失败的元组只能在该批次内进行重试，如果失败的元组一直无法成功处理，那么进程挂起，即不包含容错机制。对于不透明的事务控制，单个批次内处理失败的元组可以在其他批次内重试一次，其容错机制规定重试操作有且仅有一次。上述针对消息的可靠性保障机制使得数据的处理有且仅有一次，保证了事务数据的持久性。容错机制使得失败的元组在重试环节的状态更新是幂等的，幂等性是统计学中的一个重要性能指标，其保证了即使数据被多次处理，从处理结果的角度来看和处理一次是相同的。Trident的出现显著减少了编写基于Storm的应用程序的代码量，其本身具有函数、过滤器、连接、分组和聚合功能。在组件方面，它保留了Spout，将Bolt组件中实现的处理逻辑映射为一些新的具体操作，例如过滤、函数和分组统计等。数据的状态可以保存在拓扑内部存储当中（例如内存），也可以保存在外部存储当中（例如磁盘），Trident的应用程序接口支持这两种机制。
（16）S4
S4项目[20]是由雅虎（Yahoo）提出的，作为一个分布式流处理计算引擎，其设计的初衷是与按点击数付费的广告结合，基于实时的计算来评估潜在用户是否可能对广告进行点击。这里S4是指简单的（Simple）、可扩展的（Scalable）、流（Streaming）以及系统（System）。在S4项目提出之前，雅虎已经拥有了Hadoop，但Hadoop的基本理念是批处理，即利用MapReduce对已经过存储的静态数据进行处理。尽管MapReduce的处理速度非常快，但是从本质上说，其无法处理流数据。S4项目将流数据看作事件，其具体的实现中包含五个重要构件：处理节点（processing element）、事件（event）、处理节点容器（Processing Element Container，PEC）、机器节点（node）和机器节点集群（cluster）。一个集群中包含多个机器节点，一个机器节点中包含一个处理节点容器，一个处理节点容器中包含多个处理节点。处理节点对事件进行处理，处理结果作为新的事件，其能够被其他处理节点处理。上述的点击付费广告的应用场景具有很高的实时性要求，而Hadoop无法很好地应对这样的要求。具体来说，MapReduce所处理的数据是保存在分布式文件系统上的，在执行数据处理任务之前，MapReduce有一个数据准备的过程，需要处理的数据会按照分块依次进行运算，不同的数据分块大小可以对所谓的实时性进行调节。当数据块较小时，可以获得一定的低延迟性，但是数据准备的过程就会变得很长；当数据块较大时，数据处理的过程无法实现较低的延迟性。诸如S4的流计算系统所处理的数据是实时的流数据，即数据源源不断地从外部数据源到达处理系统。流计算处理系统的主要目标是在保证给定的准确度和精确性的前提下以最快的速度完成数据的处理。如果流数据不能够被及时处理，那么其潜在的价值就会大打折扣，随着处理时间的增长，流数据的潜在价值保持递减。软件开发者能够根据不同的场景和需求在S4的上层开发处理流数据的应用程序。
（17）Spark Streaming
作为Spark的组成部分，Spark Streaming[21]主要针对流计算任务，其能够与Spark的其他构件很好地进行协作。一般来说，大数据的处理有两类方式：批处理和流计算。对于批处理，任务执行的对象是预先保存好的数据，其任务频率可以是每小时一次，每十小时一次，也可以是每二十四小时一次。批处理的典型工具有Spark和MapReduce。对于流处理，任务执行的对象是实时到达的、源源不断的数据流。换言之，只要有数据到达，那么就一直保持处理。流处理的典型工具有Kafka和Storm。作为Spark基础应用程序接口的扩展，Spark Streaming能够从众多第三方应用程序获得数据，例如Kafka、Flume和Kinesis等。在Spark Streaming中，数据的抽象表示是以离散化的形式组织的，即DStreams。DStreams可以用来表示连续的数据流。在Spark Streaming的内部，DStreams是由若干连续的弹性数据集（Resilient Distributed Dataset，RDD）构成的，每个弹性数据集中包含的数据都是来源于确定时间间隔。Spark Streaming的数据处理模式是对确定时间间隔内的数据进行批处理。由于部分中间结果需要在外存中进行存储，因此传统的批处理系统一般运行起来较为缓慢，但是这样的处理模式可以具有很高的容错性。Spark Streaming的数据处理模式是基于弹性数据集进行的，通常将绝大部分中间结果保存在内存中，可以根据弹性数据集之间的互相依赖关系进行高速运算。这样的处理模式也被称为微批次处理架构，具体的特点是数据处理的粒度较为粗糙，针对每个选定的弹性数据集进行处理，对于批次内包含的数据无法实现进一步的细分。
（18）Lambdoop
2013年，项目负责人Rubén Casado在巴塞罗那的NoSQL Matters大会上发布了Lambdoop框架。Lambdoop是一个结合了实时处理和批处理的大数据应用程序开发框架，其基于Java语言。Lambdoop中可供选择的处理范式（processing paradigm）有三种：非实时批处理、实时流处理和混合计算模型。Lambdoop实现了一个基于Lambda的体系结构，该结构为软件开发者提供了一个抽象层（abstraction layer），使用与Lambda架构类似的方式来开发大数据相关的应用程序。对于使用Lambdoop应用程序开发框架的用户，软件开发者在应用程序的开发过程中不需要处理不同技术、参数配置和数据格式等烦琐的细节问题，只需要使用必需的应用程序接口。此外，Lambdoop还提供了辅助的软件工具，例如输入/输出驱动、数据可视化接口、聚类管理工具以及大量人工智能算法的具体实现。大多数已有的大数据处理技术关注于海量静态数据的管理，例如前述的Hadoop、Hive和Pig等。此外，学界和业界也对动态数据的实时处理较为关注，典型的应用软件有前述的Storm和S4。由于针对海量静态数据的批处理能够考虑到更多相关信息，因此相应的处理结果具有更高的可靠性和健壮性，例如训练出更加精确的预测模型。遗憾的是，绝大多数批处理过程耗时较长，在对响应时间要求较高的应用领域，批处理是不可行的。从理论上来说，实时处理能够解决上述问题，但实时处理有一个重大的缺陷：由于需要保证较小的延迟，实时处理所分析的数据量是十分有限的。在实际的生产环境中，通常需要实时处理和批处理两种方式各自具有的优点，这对软件开发者来说是一个挑战性的难题，同时这也是Lambdoop的设计初衷[130]。
（19）SummingBird
SummingBird是由推特于2013年开源的数据分析工具[132]，大数据时代的数据处理分为批处理和实时处理两大领域，这两种方式各有利弊，仅采用一种处理方式无法满足各类应用日益多样化的需求。作为能够处理大规模数据的应用软件，SummingBird的设计初衷是将上述两种处理方式结合起来，最大限度地获得批处理技术提供的容错性和实时处理技术提供的实时性，其支持批处理模式（基于Hadoop/MapReduce）、流处理模式（基于Storm）以及混合模式。SummingBird最大的特点是无缝融合了批处理和流处理。推特通过SummingBird整合批处理和流处理来降低在处理模式之间转换带来的开销，提供近乎原生Scala和Java的方式来执行MapReduce任务。SummingBird作业流程包含两种形式的数据：流（stream）和快照（snapshot），前者记录了数据处理的全部历史，后者为作业系统在单个时间戳上的快照。简单地说，SummingBird可以认为是Hadoop和Storm的结合，具体包含以下构件：Producer，即数据的抽象，传递给指定的平台做MapReduce流编译；Platform，即平台的实例，由MapReduce库实现，SummingBird提供了平台对Storm和相关内存处理的支持；Source，即数据源；Store，即包含所有键值对的快照；Sink，即能够生成包含Producer具体数值的非聚合流，Sink是流，不是快照；Service，即供用户在Producer流中的当前数值上执行查找合并（lookup join）和左端合并（left join）的操作，合并的连接值可以为其他Store的快照、其他Sink的流和其他异步功能提供的快照或者流；Plan，由Platform生成，是MapReduce流的最终实现。对于Storm来说Plan是StormTopology的实例，对于Memory来说Plan是内存中的stream。文献[133]分析了SummingBird平台的可行性和优势，提出了基于SummingBird的能源互联网云计算平台。
4.大数据生态系统
文献[117]指出，大数据本身囊括了存储、处理、可视化和结果表达等若干个复杂的构件。其不仅是一个数据库或者Hadoop体系结构的问题，尽管它们构成了大规模数据处理和数据分析的核心技术和构件[134][135]。所有互相关联的构件共同构成了大数据生态系统（big data ecosystem），该系统涵盖了大数据的整个生命周期中的基础设施结构与处理模型。当前，Hadoop是大数据生态系统中的核心构件。
Hadoop的出现使得具有不同结构或者完全无结构的超大规模数据能够被处理、管理和分析，但是该体系结构也存在一些局限性[68]：
·生成多个数据副本：由于HDFS设计的初衷是提高效率，因此数据被存储为多个副本。一般来说，数据是以至少一式三份的形式产生的。但是，为了通过数据本地化来保持性能，必须产生数据的六个副本。因此，数据的规模进一步增大。
·具有挑战性的框架：当前MapReduce框架的结构比较复杂，尤其是当需要利用复杂的转换逻辑时。学界和业界在改进MapReduce框架方面已有一些尝试，所做的工作大多集中于研发开源模块来对初始的框架进行简化，但这些开源模块使用的也是注册语言（registered language）。
·非常有限的SQL支持：Hadoop将分布式系统领域的若干开源项目和编程框架进行联合，进而完成大数据分析的完整周期。但是，其对SQL的支持很有限，而且缺乏基本的SQL函数，使得常规数据分析中的很多功能存在缺失，例如子查询（subquery）操作和分组（grouping）操作。
·缺乏基本的技术：如前所述，Hadoop的体系结构是由开源项目组合而成的，Hadoop项目中包含了一些精妙的数据挖掘函数库。但是从整体角度来看，这些函数库或者说单个的技术之间在设计理念、数据结构和代码实现上缺乏一致性。因此，对于MapReduce来说，需要比较成体系的、设计与实现具有一致性的算法和相应的函数库。
·低效的执行：HDFS没有考虑对查询进行优化。因此，其执行操作时无法拥有较高的性价比。这样导致的结果是Hadoop中簇的规模通常比实际所需的类似数据库要大很多倍。
[1] https://www.sas.com/
[2] https://www.ibm.com/analytics/spss-statistics-software/
[3] https://rapidminer.com/
[4] http://www.minitab.com/en-us/
[5] https://www.r-project.org/
[6] http://www.gnu.org/software/pspp/
[7] https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
[8] https://sqoop.apache.org/
[9] https://github.com/facebookarchive/scribe/
[10] https://hbase.apache.org/
[11] https://hadoop.apache.org/docs/r1.0.4/cn/mapred_tutorial.html
[12] https://hive.apache.org/
[13] https://pig.apache.org/
[14] https://www.cascading.org/
[15] https://spark.apache.org/
[16] https://github.com/amplab/shark/wiki/Shark-User-Guide/
[17] http://kafka.apachecn.org/intro.html
[18] https://storm.apache.org/是使用Java和Clojure◣28注：https://www.clojure.org/
[19] https://storm.apache.org/releases/current/Trident-tutorial.html
[20] https://incubator.apache.org/projects/s4.html
[21] https://spark.apache.org/streaming/