作者：陆晟 刘振川 汪关盛 等
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
大数据理论与工程实践试读：
前言
大数据是近年来炙手可热的一个词汇。无论是国家还是企业，都希望从大数据产业的发展中获益，而科学家、工程师们也希望在这个新兴的行业中获得较高的回报。因此，市面上大数据相关的书籍也快速丰富了起来，从概述类的书到具体介绍某项技术的书，应有尽有。而本书则从工程实践和基础理论角度讲述大数据的应用，为不同的大数据应用场景提供了思路。
目前，在实际应用中，人们往往通过架设Hadoop，以及基于Hadoop生态的各种系统来满足大数据应用需求。然而，不是所有的大数据应用都适合用Hadoop的数据存储方式、系统架构和计算模型。例如，对于高实时性要求或者高并发的应用场景，Hadoop就不适合，因此出现了许多基于Hadoop生态的扩展，以解决某些特定类型的问题。
近年来，大数据技术一直处于高速发展中，很多两年前非常流行的技术逐渐淡出或者销声匿迹了。作为大数据业务的开创者和领头羊，Google公司从未停止过对技术的改进甚至颠覆，例如将数据存储从GFS发展到了BigTable，也推出了Dremel和Pregel等新的计算框架。这是因为Google的工程师了解需求，也知道这些需求背后的技术原理，懂得根据需求权衡和选择最适合特定需求的技术路线和方案；而不是只有榔头这一个工具，导致看任何问题都像是钉子，而解决问题的手段也只有敲击这一项。
本书不是大数据技术手册，也不是某种具体技术的说明；而是面对具体应用场景时的技术考虑和权衡。在实际应用中，各类大数据应用方案没有优劣之分，只有适合或不适合的差异。甚至大部分情况下，任何选择都需要付出代价，而针对这种收益和代价的衡量及评估才是本书所关注的。此外，书中也会出现一些具体的示例代码，作者提供这些示例代码，希望体现其背后的原理，即使某段代码采用了特定的语言和系统，也不代表在该场景下推荐使用该语言及语言所依赖的系统。
本书通过探讨技术原理，帮助读者选择合适的工具，或者自行开发适合自己应用场景的工具，无论这个工具是榔头还是钻子，是刨子还是螺丝刀，甚至是目前还不存在的某种类型的工具。作者团队衷心希望本书能为国内大数据企业建立自己的技术特色和技术优势贡献微薄之力。
本书目标读者群：主要面向架构师，或者是有具体大数据问题需要解决的工程师；也适合从零开始搭建大数据架构，或者需要将现有的非大数据的需求修改成大数据方案的读者和相关专业学习者。同时，对于那些实际上正从事大数据相关工作而自己并不清楚这一点的个人或企业，本书也能给你们带来启发。
非本书的目标读者群：希望通过教科书式学习从而掌握大数据的某项具体技术的读者；希望通过一本书就知道大数据是什么，从而可以找到一份大数据工作的人士。
本书作者都长期从事大数据相关的工作，对于很多具体的技术有自己的看法和独到见解，也真正踩过很多坑。由于应用场景的不同，作者对于技术的理解和认识也可能存在差异。我们希望这本书的推出能够抛砖引玉，涌现出更多精彩著作。 第1章 概述
随着数据的编码和电子化存储技术的发展，大数据现已变成了一种被广泛运用的技术手段。从单一的照片、到相册、再到相册集、然后到家庭相册、再到千千万万家庭的相册；同理，从单一的文件、到文件目录、到文件系统、再到磁盘阵列……随着不断积累，数据总会朝着与日俱增的方向发展。而随着使用人数和使用场景的增加，数据的增量很快就会超过人力所能处理的范畴。个人拍摄的照片尚可自行处理和筛选，而无处不在的监控就不可能再用人工方式全面地查看了。因此，在一定程度上，各种问题最终都会转化成大数据问题。
关于大数据意义和作用的文章和著作有很多了，例如，吴军博士在《智能时代》一书中列举了大量生动的例子，我们就不再重复。我们写作本书的目的，是为了说明在工程上使用大数据时的各种具体考量。大数据处理的特征
随着数据日积月累，需求的应用场景也会越来越丰富。那么，大数据到底是如何被处理的呢？对很多人来说，大数据只是一个概念，而工程师面对的却是待解决的实际问题。他们需要解决这些问题，至于是不是用大数据的方式，一开始未必就能确定。也许他们一开始并没有意识到需要用大数据。当他们发现：我的天啊！数据怎么这么多！我的程序跑个基本处理竟然要五个小时！这时，就该大数据出马了。
当你发现，需要解决的问题具备几个共同特征，那么这个问题就可以运用大数据手段去解决。也就是说，这个问题基本上就可以算是大数据问题了。
我们总结了需要利用大数据技术手段处理的数据的三大特征。
第一，数据量大。至于数据量大到什么程度才算大数据，并不存在统一的硬性标准。在不同的历史时期和软硬件条件下，数据量标准也是不同的。但不管怎么说，当数据量大到用一台处理器处理不过来、多到用单一存储设备难以存下时，就需要采用大数据手段了。
第二，数据一般带有时间属性。对有些数据来说，时间是主要属性，例如，在某个时刻的设备状态监控信息。而对另外一些数据来说，虽然时间不是最重要的属性，但也是属性之一，例如，某首歌曲或者某部电影，虽然大家关注的是其内容，但是它们同时也具有产生和被使用的时间属性。
第三，数据一般具有多个属性维度。单一属性的数据虽然可能量也很大，但是从处理和分析的角度来看，数据往往可以被分为很多详细的属性，而这些属性之间的关联和关系才是最有价值的。例如，监控视频包含的也许都是单一的图像数据，而需要被处理的常常是这些图像被分析之前的元数据以及被分析之后的详细数据。例如，采集视频的时间和采集时的地理位置、图像的分辨率是元数据，而图像分析之后得到的人数、天气情况、是否存在需要关注的异常事件等，就属于含有更详细的维度的信息。
IBM公司提出大数据有5V特征，分别是大量（Volume）、高速（Velocity）、真实（Veracity）、多样（Variety）和低价值密度（Value），它们可以用来说明大数据的数据量大、需要的处理速度快、对数据质量的追求高，同时数据的来源往往很不同，以及价值密度的高低与数据总量的大小成反比等特性。此外，还有人认为大数据的特征是体量大、可分析的维度多、数据完备性重要，以及数据不能够用[1]传统方式处理。这些特性分析和理解当然是没错的，但从事物的不同角度看，关注的重点、可以进行的分类和得到的结论会不同，因此本书中提出的三项大数据特性更多关注的是大数据项目的实施属性，所以我们也称之为大数据处理的三大特征。基本处理模型
大数据技术是一种帮助数据实现价值的技术手段。挖掘出数据中的价值，才是大数据的应用目标。大数据技术虽然是新兴的数据处理技术，但它与传统的数据仓库等技术相比，数据处理的核心模型并没有发生多大的变化。以前做过传统的数据仓库管理等工作的人转行做大数据，就会发现后者仅仅是处理步骤对应的技术产生了变化。
传统的数据类问题的解决可以分为四个基本步骤：数据采集、数据存储、数据分析和数据使用。前三个步骤都很直接，而所谓数据使用则有不同的表现形式：可能是用图表对数据进行展示；也可能是利用分析结果做出某种决策；还有可能带来另一轮的采集、存储、分析、使用过程，即在前一轮分析的基础上对结果进行新一轮处理。以前文提到的监控视频数据为例，第一轮采集的数据可能是视频流本身。这些视频数据和元数据（例如采集时间、采集地点）需要被保存下来，然后根据不同需求做出不同的分析，例如分析其中车辆的信息、车牌号码、是否违章等。至于这些数据的分析结果，可以是按时间统计的车辆通行量的图表；也可以是提交给交通管理部门的违章信息；还可以根据不同时间和不同位置的通行情况进一步分析车辆，从而画出车辆的运行轨迹图，或者分析道路拥堵情况。
这四个步骤也构成了大数据处理的基本模型（如图1-1所示）。图1-1 大数据处理的基本步骤
这个模型同具体的技术没有任何关系，只是一个概念。不过，这个概念体现了大数据处理的必要元素。其中数据的采集源可以有很多种，可以是工控设备的监控，可以是物联网的探头，也可以是日志信息或者其他公司的商业智能（Business Intelligence，BI）数据，当然也可以是某个大数据系统的分析结果。数据存储要考虑的是采集到的数据的保存问题。当然，不保存原始数据也是一种存储策略。根据需求不同，数据分析采用的形式也千差万别。有的也许是统计、有的也许需要做规划建模，而有的情况下则需要引入深度学习和其他人工智能处理方式。
从另一个维度看，这个数据处理的概念模型还可以被看作“数据—信息—知识—智慧”金字塔模型。它是一个量级由大至小、价值由低到高的数据模型。我们把大数据处理步骤的概念模型，（在一定程度上）对应放到这个金字塔数据模型当中，得到图1-2。图1-2 数据价值的金字塔模型
对应图1-1中的数据采集、数据存储、数据分析、数据使用四个步骤，围绕着数据价值的提升，我们需要对数据进行采集、导入/预处理、统计/分析和深度挖掘。这四个步骤对应于图1-2金字塔模型的四个步骤，更加偏向于工程应用。其中的导入/预处理是数据存储的前置核心步骤，而深度挖掘是为了提升数据价值属性和未来使用的常规方法。采集
大数据的采集一般分为系统日志采集、网络数据采集和其他数据采集。目前很多公司都有自己的海量数据采集工具，均采用分布式架构，能满足每秒数百兆字节的日志数据采集和传输需求，如Chukwa、Flume、Scribe、Kafka等工具也常常用于构造数据处理总线。网络数据采集指通过网络爬虫或网站公开API等方式从网站上获取数据信息。对于网络流量的采集可以使用深度报文检测（Deep Packet Inspection，DPI）或深度/动态流检测（Deep/Dynamic Flow Inspection，DFI）等带宽管理技术进行处理。其他数据采集，如企业生产经营数据或学科研究数据等保密性要求较高的数据，可以通过与企业或研究机构合作，使用特定系统接口等相关方式采集数据。导入/预处理
对海量数据进行分析时，还是应该将这些来自前端的数据导入一个大型分布式数据库或者分布式文件系统，并且可以在导入的同时做一些简单的清洗和预处理工作。在导入时使用Storm和Spark Streaming来对数据进行流式计算，满足部分业务的实时或准实时计算需求。导入与预处理过程的特点和挑战主要是导入的数据量大，每秒钟的导入量经常高达百兆字节，甚至千兆字节级别。统计/分析
统计分析的主要特点和挑战是分析涉及的数据量大，其对系统资源和I/O会有极大的占用。可利用分布式数据库或者分布式计算集群来对海量数据进行普通的分析和分类汇总等，以满足常见的分析需求。在这方面，一些实时性需求会用到GreenPlum、Exadata等，而一些批处理或者基于半结构化数据的需求可以使用Hadoop。挖掘
数据挖掘主要是对现有数据进行基于各种算法的计算，从而起到预测（Predict）的效果，同时满足一些高级别数据分析的需求。比较典型的算法有用于聚类的Kmeans，用于统计学习的支持向量机（Support Vector Machines，SVM）和用于分类的朴素贝叶斯（Naïve Bayes）。数据挖掘主要使用的工具有Hadoop的Mahout和Spark的MLlib等。工程角度的大数据历史
大家都知道，科技的发展不是孤立的，苹果也不是凭空从天上掉下来的。在它砸在牛顿脑袋上之前，它总应该是长在某棵树上的。按牛顿那句被曲解的名言所说，大家都是站在巨人的肩膀上的。
一般都认为大数据的发展源于Google在2003年年底发表的[2]MapReduce一文。而实际上这篇论文只是把一类大数据问题抽象化，从而建立了一套实用的计算模型，极大地促进了大数据技术的发展。
而按照前文的基本处理模型，实际上很多的必要步骤和技术要素都已经经过了长时间的发展和完善，甚至很多技术都已经应用很久了。从这个角度而言，大数据也是一种新瓶装旧酒的概念。当然，经过最近15年的发展，特别是和人工智能各项技术结合之后，大数据概念已经脱胎换骨，同使用某些类似技术的旧瓶概念相比，已经完全不同了。
图1-1中所示的大数据基本处理模型同二十多年前的日志处理和分析系统的结构几乎完全相同。当然，日志处理和分析系统的数据采集环节采集的都是日志信息；数据存储环节使用的一般是文本文件或者关系型数据库；数据分析环节有的用自行编写的脚本，有的利用New Relic之类的分析工具；而数据使用也许会采用类似Crystal Report的通用报表展示系统，当然也可以自行编写。事实上，目前的日志处理和分析已经形成了完整的框架，如使用ELK框架进行日志分析。其中的E、L、K分别代表Elasticsearch，Logstash， Kibana，分别解决日志处理中的查询、存储和展示问题。
在数据采集环节，即使不考虑日志采集类的技术和应用，物联网也已经发展了很多年，传感器的开发和应用也有超过二十年的历史。同样的，随着摄像头的广泛部署，视频采集技术和该技术相关的传输[3]技术也发展了二十多年，如H.264标准发布之前就已经有了H.263及H.261等标准。
在数据存储领域，NAS（Network Attached Storage）和SAN（Storage Area Network）发展了很多年。其中，大数据存储使用的很多技术是和SAN相通的，包括分片、寻址、容错、恢复、通信等。甚至在很多大数据应用中，人们会直接使用NAS服务或者专用存[4]储设备来存储数据，如Glaster FS或者EMC的存储设备。很多云服务商甚至提供了基于存储网络（Storage Network）原理的云存储服务。同样的，大数据处理集群也采用类似策略，只是数据的访问对上层处理而言更加确定。当然，用户仍旧不需要关心具体的存储策略，直接使用即可。
在数据处理方面，大数据处理在本质上是分布式处理和相关通信技术、平台的延伸。例如，20世纪著名的网格计算（Grid Computing）[5]虽然和大数据常常依赖的云计算（Cloud Computing）有不同点，但它们都是分布式计算（Distributed Computing）的衍生技术。至于分布式计算的发展就更加久远了，在20世纪六七十年代发展起来的ARPANET（Internet的前身）可以被看作是分布式计算的一种应用。
因此，目前快速发展的大数据技术是基于这些成熟的技术，为了解决具有前文列举的特性的特定应用问题，通过建立和目前软硬件水平相适应的存储技术、计算模型，而逐步发展起来的。大数据的基本处理框架
从处理模型看，大数据不外乎解决了数据采集、数据存储、数据分析和数据使用的标准问题。目前，大数据处理基本都基于Hadoop。先利用Hadoop的HDFS存储数据，然后利用Hadoop的MapReduce或者其他流式处理引擎处理数据。虽然直接使用Hadoop做计算的事例越来越少了，但是处理的基本框架仍旧是类似的（如图1-3所示）。图1-3 大数据处理框架
图1-3中的数据传输总线在很多情况下被标注成数据传输模块，用于把各种来源的数据存放入存储系统。而有的公司把这个模块作为总线使用，也就是计算系统获得的计算结果有可能会传回存储系统进行进一步计算，以实现前面“基本处理模型”一节中提到的数据再次使用的目的。
这个处理框架中的各个系统可以有多种选择。例如，数据传输总线目前最常用的是Apache的Kafka；也可以选择阿里巴巴的RocketMQ。对于Google而言，存储系统是GFS；而对于Hadoop而言，存储系统就代表着HDFS。
因此，可以用填空的方式填写以上基本处理框架，而使用Hadoop的解决方案可以作为某种意义上的“标准模型”（如图1-4所示）。图1-4 数据处理模型技术实现
所谓“标准模型”不是说这种用法是不可替代的，而是说，这是截至本书完成之日，使用最为广泛的大数据处理的工程技术选型。这种用法这么常见，自然有其实用性方面的考量和技术原因。
在基本框架下，数据从数据源进入体系中间的过程一般被称为ETL。ETL是实现数据预处理的主要技术。ETL中的三个字母分别代表的是Extract、Transform和Load，即抽取、转换、加载。ETL原本是作为构建数据仓库的一个环节，负责将分布的、异构数据源中的数据，如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。现在越来越多地将ETL应用于一般信息系统中数据的迁移、交换和同步。目前市场上主流的ETL工具有IBM公司的Data Stage，Informatica公司的Powercenter，Oracle公司的ODI、OWB，以及Teradata的Automation，开源的Pentaho的Kettle。
目前的ETL通常只能运行在单机节点上。当数据量比较大的时候，ETL的处理能力受限于单机的CPU频率、内存大小、硬盘容量。这种单机的ETL扩展比较难。大数据环境下，不仅数据容量大，而且数据增长速度快。目前单机ETL数据处理速度已经跟不上这种变化，正逐渐成为大数据处理和构建海量数据仓库的瓶颈。因此，为ETL增加集群处理的能力成为新的需求。ETL解决大数据处理的一个合理的想法就是建立数据处理的集群，将数据处理的任务分散到多台机器上去执行。基于MapReduce的Hadoop能够很好地满足数据处理的需求。它通过把数据分散存储到多台机器上、在多台机器上并行执行任务来提高数据处理的效率。大数据的技术实施方法
在大数据平台建设实施过程中，应该注意做好项目的准备工作，了解客户实际情况、需求、业务模式和数据类型等。业务探索必须充分基于业务需求。数据探索需要把握数据平台建设具有的应用和数据双驱动的特点。逻辑数据模型的设计，需要根据数据特点设计不同的数据模型。系统体系架构设计应以企业架构为指导，以大数据平台建设目标为导向，以具体业务需求为依据。根据逻辑数据模型，做好不同的物理存储、文件系统和物理数据库的技术选型。结合业务探索和数据探索得出的系统现状，确定数据转换加载的主要方式和策略。确定大数据平台前端应用体系架构。提供各种数据分析、元数据管理和大数据系统管理功能。根据项目的不同阶段进行验收测试。再根据试用评估结果，拓展大数据业务应用范围，最后对大数据应用进行推广。具体操作步骤如下。项目前期准备
大数据项目启动前应深入业务场景，对实际情况和需求进行调研，了解业务模式和数据类型，确定项目的建设背景和项目的基本需求。根据调研结果，确认大数据项目范围和主要目标，明确大数据项目的建设思路和演进路线，并确认项目阶段性验收及总体验收标准，提出项目总体实施计划。在此基础上，提出项目资源需求，确认项目团队成员及其分工，提出项目存在的风险及应对策略。业务探索
业务需求对大数据平台的成功实施极为重要，相关人员对业务需求的理解可以影响大数据平台实施过程中的每个决策，包括确立恰当的项目范围，对恰当的数据进行建模，选择恰当的产品工具等。
在业务探索阶段，先制订访谈计划，确认访谈人员、时间和访谈问题，再按照访谈计划对管理层和利益相关方进行访谈，对数据源和用户需求进行确认、筛选和分析。最后根据业务需求提炼功能需求、用户需求及非功能性需求；采用面向对象的分析方法，先根据功能需求构建功能模型，再根据用户需求构建用例模型，最后结合非功能性需求构建业务需求模型。数据探索
数据平台建设具有应用和数据双驱动的特点，数据需求建模对大数据平台有着同等重要的地位，应采用源数据和业务需求双驱动的方式实施建设。采用面向过程的分析方法，结合面向源数据的分析思想，根据数据需求和源系统数据，确定源系统数据的范围、分类、含义、加工规则等内容，最终构建数据需求模型。逻辑数据模型设计
根据具体数据需求及对数据的使用模式，数据仓库的数据架构可分为结构化数据、列式数据、文档数据和非结构化数据。各类数据的功能特点不一，加工存储的方式也不同，因此各层的数据模型设计方法也不尽相同。
结构化数据在数据模型和设计方式上沿袭和兼容传统的数据仓库和数据库，保证原有功能平稳迁移至大数据平台上，从而降低了开发、运维人员和终端用户的学习及使用成本。大数据平台中的结构化数据存储相较传统数据仓库而言，提供了更强的横向扩展能力，实现了更高的写入、读取效率。
列式数据提供按业务场景组织数据的能力，相同业务场景下频繁使用的数据集会被集中存放，以提升数据访问效率。
文档数据提供一种松耦合的半结构化数据访问方式，这种方式组织的数据会尽量贴合业务原貌，帮助相关人员更方便快捷地进行数据的建模和查询，更有效地应对各种复杂业务模型和业务变更。
非结构化数据主要是指采集来的文本、语音、视频等信息。大数据平台中的非数据化结构存储针对这类数据的特点，提供了大容量、访问速度快、可用性高的存储。物理数据库设计
物理数据库设计的注意事项如下：根据不同的逻辑数据模型，做好不同的物理存储、文件系统和物理数据库的技术选型工作，选择功能强大、稳定、技术支持良好的开源或商业产品；设计合理、可扩展、高效的数据存贮结构和方式，并可根据业务发展进行调整和调优；建立完善可靠的数据灾备和恢复机制，提高系统可用性和可靠性；使用业内领先的可靠安全手段，以保证数据安全性。系统体系结构设计
系统体系架构设计的注意事项如下：以企业架构为指导，以大数据平台建设目标为导向，以具体业务需求为依据，以同业领先实践为参考；从战略的视角，采用“自上而下规划与自下而上实现相结合”的思路；明确大数据平台所支撑的业务领域，对大数据平台的业务能力进行全局化分析、设计和扩展，确保大数据平台和其所承载应用架构的规范性、一致性、集成性、稳定性和灵活性；数据仓库架构设计过程要经过架构初步设计、创建架构模型、架构评估和架构实施四个阶段来逐步实现。数据转换加载
数据转换加载的具体过程如下：根据逻辑数据模型，结合业务探索和数据探索出的系统现状，确定数据转换加载的主要方式和策略；确定系统中所有数据源和其更新频率、数据带宽、数据结构等特性；设计系统数据流程和处理方式，确保数据转换加载的时效性和加载过程中的正确性，以及数据的安全性。数据分析
数据分析时是从宏观角度指导相关人员开展数据分析工作，即数据分析要做好前期规划，从而指导后期数据分析工作的开展。数据分析涉及具体的分析方法，如对比分析、交叉分析、相关分析、回归分析等。数据分析的目的越明确，分析就越有价值。明确分析目的后，需要梳理思路，搭建分析框架，把分析目的分解成若干个不同的分析要点；然后针对每个分析要点确定分析方法和具体分析指标；最后，确保分析框架的体系化（体系化，即先分析什么，后分析什么，各个分析点之间逻辑分明），以使分析结果具有说服力。业务应用开发
确认大数据平台业务应用体系架构，并设计和开发大数据平台业务应用。大数据平台业务体系架构应满足松耦合特性，使得在复杂应用服务依赖拓扑环境下，保证业务应用服务的有序性，并提供热升级、热插拔特性。业务应用设计及其中的报表、查询和展示设计，应采用先进可靠的数据可视化手段和方式，并能在不同环境下保障用户拥有一致性体验。元数据管理
元数据包括业务规则、数据源、汇总级别、数据别名、数据转换规则、技术配置、数据访问权限、数据用途等。元数据描述的是数据的背景、内容、数据结构及其生命周期管理。
元数据应标准化：使用元数据作为用户交流的唯一根据，确保所有用户使用一致的名词进行沟通、理解，以及解释业务问题。同时消除歧义，保证企业内信息的一致性，便于知识和经验的共享。
元数据应与业务系统无缝集成：数据装载、导入、集成过程依赖多种多样的数据源和业务系统，当元数据从不同源系统的数据集成到大数据平台时，应保证数据元素的含义是统一的。
元数据应提供周密的安全机制：在元数据层管理ACL和用户信息。需要设计用户角色来控制不同部门、不同地域的用户对不同粒度的数据进行访问的权限，并通过审计跟踪过程对数据访问进行安全检测。
元数据管理应提供扩展性：为了适应变化，元数据必须是可扩展的。频繁变化的语义层应当独立于应用程序，存储在元数据中。这样，一方面可以保证系统扩展的灵活性，另一方面可以很容易地添加新的元数据对象。大数据系统管理
设计和开发大数据系统安全、稳定运行所需的运维管理体系结构，包括开发和测试性能监视程序，开发和测试数据备份与恢复程序，建立用户支持和培训材料等。
性能监视程序主要对集群运行情况的性能指标进行监测，包括CPU占用率、内存占用率、网络IO占用率、磁盘IO占用率和磁盘剩余容量大小等系统关键指标，以及每秒并发数、每秒事务数等业务关键指标。大数据管理平台对运行于集群中的各分布式系统提供运行监控和管理工作，主要指标包括HDFS剩余容量、HDFS DataNodes实时读写块数及字节数、YARN运行应用统计、Spark集群事件统计、Spark任务执行时间线。系统运行中可随时调整运行参数报警阈值。当系统性能指标下降到报警阈值时，管理系统会发出警报，通知运维人员检查系统状态。
数据备份与恢复程序主要是为了保证分布式系统的稳定运行，确定系统数据备份策略与副本数量。当工作节点失去响应时，该程序能够快速调整系统服务拓扑，调整系统数据流，并排查工作节点故障，报告运维人员修复故障或自动修复工作节点。工作节点恢复后，程序会将其重新加入集群，并完成数据迁移与负载均衡。测试验收与试运行
根据项目的不同阶段，应按顺序进行以下几种测试。
冒烟测试：一种短流程测试。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。
安装测试：确保软件在正常情况和异常情况下都能进行安装的测试。异常情况包括磁盘空间不足、缺少目录创建权限等场景。安装测试目的是核实软件在安装后可立即正常运行。安装测试包括测试安装手册和安装代码：安装手册提供安装方法，安装代码提供安装程序时能够运行的基础数据。
探索测试：指在没有产品说明书的情况下，分步骤逐项探索软件特性，记录软件执行情况，详细描述功能，综合利用静态和动态技术来进行测试。探索测试人员只靠对产品的使用来对bug的位置进行判断，所以探索测试又被称为自由形式测试。
负载测试：测试一个应用在重负荷下的表现。测试系统在大量并发请求下的响应在何时会退化或失败，以发现设计的错误或验证系统的负载能力。在这种测试中，测试对象将承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
安全测试：测试系统在应对非授权的内部或外部用户的访问或故意破坏等情况时的能力。一般需要利用复杂的测试技术，所以对测试人员的安全技术水平有一定的要求。安全测试是检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。
验收测试：指系统相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试一般有三种策略：正式验收、非正式验收或Alpha/Beta测试。大数据应用系统试用和评估
试用和评估大数据应用系统，是指在完成测试基本业务功能和流程的基础上，从功能性、易用性和业务结合性三个角度，将大数据平台与传统数据仓库进行对比评估，并在系统使用一定时间后，进行系统性能、安全性和可扩展性的对比评估。我们会根据试用和评估反馈，进一步调整大数据平台和现有应用系统。大数据应用推广
根据试用评估结果，拓展大数据业务应用范围。根据试用评估阶段得出的迁移和使用经验，将更多的业务系统迁移至大数据平台上。使用大数据平台的结构化数据分析，结合传统数据仓库的数据分析，并根据实际业务需要，利用大数据平台的非结构化数据分析和数据挖掘功能，完成传统数据仓库与大数据平台的结合。
[1].这四项特性来自吴军博士所著《智能时代》一书的第二章，其中关于多维度的解释同本书的观点不同。本书强调的是数据存在多维度属性，吴博士强调的是数据可以被多维度分析。
[2].Jeffrey Dean & Sanjay Ghemawat, MapReduce: Simplified Data Processingon Large Clusters, OSDI 2004.
[3].H.264标准是ISO/IEC 14496定义的MPEG-4的第十部分。
[4].这种时候，一般不能采用本书中特指的大数据处理方式来处理数据，而会采用比较传统的文件或者关系型数据库方式。
[5].云计算不完全是计算技术，更多的是资源管理和调度技术。但是云计算本身是一个多层概念，在SaaS层，可以被看作是一种计算技术。 第2章 数据
从任何角度看，数据都是大数据处理的核心问题。在大数据处理的特征中提到的“数据量大”“存在时间属性”“数据的属性维度多”三个特征，本质上也是数据的特征。除这些特征之外，还有几个特性是大数据处理中的数据所具备的，分别是：数据往往按照时间批量到达；数据常常是不同格式的文本或者多媒体等非结构化数据，需要预处理；数据需要保留一定时间，过期数据需要清理；数据的不同维度属性都需要快速查询和分析，但是原始数据极少被修改。这些特性不仅和上述三个特征有关，而且更加具体。
这就带来了一些数据处理上的优势和劣势，也使更有针对性的设计有可能实现。例如，很多数据是按照时间来存放的，也是按时间来清理的，因此快速、批量地删除过期数据就变成了设计中需要考虑的问题。
下面，就让我们具体看看实际使用的大数据存储系统有哪些，它们在设计上是如何考虑的。数据存储
除了一些大公司在自行使用或者对外提供自己的大数据存储系统之外，大部分用户使用的都是Hadoop的HDFS。[1]
HDFS在设计时采用了以下假设。
硬件错误：硬件错误是很常见的。HDFS通常由成百上千的服务器构成，每台服务器存储文件系统的部分数据。由于组件的数量庞大，HDFS出现组件故障的概率并不低。因此，能快速、自动地检测错误，并从错误中恢复是HDFS的核心架构设计目标。
流式数据访问：使用HDFS的应用程序通常使用流式访问数据。HDFS更多地被用于批量数据访问，而不是用户交互式数据访问。HDFS强调的是吞吐量，而不是响应延迟，所以HDFS没有支持通用文件系统的全部功能。
大数据集：HDFS设计处理的典型数据量在GB（Gigabytes，1GB通常是1 073 741 824字节，约为10亿字节）到TB（Terabytes，1TB通常是1 099 511 627 776字节，约为1兆字节。注意，此处的兆是一万亿，而不是有时认为的一百万）之间，因此HDFS要用单一集群，在数百台机器上存储千万级的文件，并且每个文件可能都是GB到TB级别的。
简化的一致性模型：HDFS主要考虑一次写入、多次读取的文件访问模型，也就是文件创建、写入、关闭后就不再改变。这个假设简化了数据一致性问题，并且使得高吞吐成为可能。这个假设实际上最早是Google的搜索引擎在抓取网页信息时体现出的处理特征。
计算靠近数据比数据靠近计算的成本要低：这是由大数据的特性决定的。数据量过大且不得不分布式存储，在各个存储数据的节点上就近计算就比把这么巨大的数据通过网络来回传递要合理、经济得多。对于计算密集型的应用，这个假设就不成立了。当然，这种情况也不必利用大数据技术。
可以在异构软硬件平台上迁移：构成集群的机器可能是分批多次购入的，因此出现硬件异构的可能性会很大。这也是为什么Hadoop是用Java开发并作为自己的编程语言的原因之一。
这些HDFS的设计假设中，有些是基本考虑，如用低成本硬件构建集群导致高硬件错误概率，此外，还可以考虑采用IBM的Z系列服
[2]务器（如图2-1所示）用硬件保障来实现高可靠性。图2-1 IBM的Z系列服务器
当然了，实际上使用Z系列服务器本身也体现了一种大数据处理思路。此处，我们无意给IBM做广告，仅仅是为了指出同样的问题也有不同的解决思路。类似银行、证券交易所之类的机构就倾向于选择这种硬件保障类的解决思路。
回到HDFS的假设中，有的假设不能算是基本的假设，但是对于设计也有重大影响。其中最关键的一条假设——一次写入、多次读取，隐藏了另外一条假设——这些数据是极少被修改的。
硬件不稳定的基本假设和服务器集群的构成形态，使数据冗余存储成为必然。又由于数据量大的假设，同一份数据必须被分片保存；再由于硬件不稳定和数据量大的共同作用，不同分片可以采用的副本策略也必须不同。例如，第一个分片放置在服务器1、服务器2、服务器13上，那么第二个分片可能就存放在服务器4、服务器18、服务器20上。这种分片和多副本的结构会破坏原有文件的顺序读取机制，这样就使得我们必须引入一个寻址机制来找到这些数据分片。
图2-2来自HDFS架构说明的网站。其在名节点（namenode）上保存了文件名、副本个数、副本存放的块编号，而在数据节点（datanode）上存放了数据分片（数据块）的副本。该图体现了数据分片、多副本存放、副本策略这三种不同的思路。至于查找分片的位置的方法以及高效获得分片的方法，会在下一节数据寻址中讨论。图2-2 HDFS存储架构
HDFS作为GFS的开源版本，其假设同GFS的假设基本是相同的。另外，GFS还考虑到了多个客户端并发读写一个文件时的效率问题，这也是分片的副本策略必须不同的一个原因。为了支持这种并发需求，Google引入了名为Chubby的粗粒度锁机制。而这种分布式锁管理器（Distributed Lock Manager，DLM）可应用在各种分布式处理系统中。Hadoop的ZooKeeper在一定程度上也可以当作分布式锁管理器使用。不同的锁管理器针对的粒度不同，有的控制文件、有的控制表。只要有并发访问的地方，都需要分布式锁管理器。而且其包括的操作也不同，简单的就是读写锁操作，复杂的包括无排斥、并发读、[3]并发写、受保护读、受保护写、排他操作共6项资源锁操作。
不同的分布式锁的设计虽然会有差异，可是基本的部署结构都是类似的，那就是会有一个独立的服务器作为锁服务器。当需要访问分布式资源时，就去访问这个锁服务器。当然，为了避免单点失效问题，[4]锁服务器可能是以主从方式或者类似于Paxos算法的分布方式构成集群的。
分布式锁和集中式本地锁的区别在于，前者的锁服务器和进行操作动作的服务器是在不同的节点上的，因此在进行加解锁操作时，就需要互相进行通信。而且锁服务器和进行操作动作的服务器都有可能出现故障，或者它们之间的通信可能会中断，这就导致加上的锁可能没有人去解除。这就使得锁的DLM通常会使用一个定时器或者维护管理进程（House Keeping）对时间过长的分布式锁进行清理。也就是说，分布式锁往往是有生命期的，这是和本地锁的一个很大的区别，生命期同时对程序的开发和编写也有影响。例如，那种加了锁就一直使用资源的粗暴方法就会变得不合适（当然，这种方式本来也不是种好的实现方式）。同样的，Java这种垃圾回收（GC）机制不能控制，在数据量巨大时可能的导致超长垃圾回收时间的语言使用也需要[5]更加谨慎地衡量。
从实现角度看，分布式锁可以使用关系型数据库，也可以使用Redis这样的内存型名值对的高速缓存（也可以叫作数据库），或者使用Chubby这样的专用服务机制。为了避免单点错误，DLM往往会由一组服务器构成。因为这些服务器是分布的，所以就可能出现不同的用户向不同的服务器请求分布式锁，从而都获得对临界资源的访问权限的问题。为了避免这种情况的发生，就要求构成DLM的服务器节点在自己的集群内部达成一致，且对外给出统一的结论。这种在分布式系统中达成一致的技术和方法就是分布式一致性算法，也是大数据涉及的集群和分布式处理场景中的一个基本问题。具体内容请参见计算资源控制章节。
在分布式锁之外，就需要解决数据存放本身的问题了。在概述这一章中已经提到，有时存储的数据也可以被放置在专用存储设备NAS或者SAN系统中。而且有的云服务提供商利用大量的服务器模拟出NAS的存储，这种情况一般被叫作存储网络。这些存储网络系统在设计上和大数据存储系统，如HDFS，在很多层面上是相通的，都需要进行数据分片，再将数据分片存放在多台服务器上。两者主要的区别是，存储网络系统并不需要和计算靠得那么近，从而并不一定需要对计算节点加以了解。也就是说，对于存储网络和SAN系统而言，控制的仅仅是存储设备本身：通过在网络节点的多个存储设备（通常是硬盘）上分片、备份存储同一个文件的不同分片。整个网络中联接着的存储设备的各个节点都是存储节点，对外往往表现为RAID磁盘阵列。数据寻址
当数据被存放之后，接下来需要解决的问题就是如何找到这些数据，这时候有两个基本的方式。（1）制定一个通用策略。通过这个策略，数据的分片放置在了哪几个服务器或存储位置是可以被计算出来的，这就保障了任何人在任何情况下的计算都会得到一致的结论。（2）每次存储的时候都去一个统一的地方记录存储信息。当需要使用数据时，就去存储信息的地方查询，这样就可以知道数据的分片被放置在哪里了。
这两个方式各有优缺点。第一个方式不存在查询节点，也不需要查询步骤，效率较高，同时避免由信息查询节点故障导致的问题，但是其缺点是可扩展性和容错程度较低。如果没有查询具体信息的节点，那么就必须设计一种寻址算法，而寻址算法通常会和可以使用的节点的数量相关。如果考虑增加节点，那么同时也将考虑以下问题：算法得知数据存储时是在增加节点前、还是在增加节点之后？同一个分片有没有被存放在新增节点上？同样的，当节点发生故障时，虽然有备用节点可以切换，但是其容错能力是有限的，而第二种方式就可以尽量避免扩展性的问题。反之，第一个方式的优点是第二种方式的缺点，即寻址查询会在一定程度上降低效率，查询节点的故障会导致整个系统无法运行，也就是常常提到的出现单点错误。事实上，这个问题在Hadoop中存在了很长时间，Hadoop的名节点始终是一个单点，直到2.0版本之后，才通过主从备份的方式在一定程度上解决了这个问题。
对于第一种方式，最常见的策略是进行散列。通过散列函数确定数据分片需要存储的位置。出于性能考虑，密码级的散列函数一般不会被使用，如MD5或者SHA，都使用一些比较基本的快速散列函数（如FNV1a、Jenkins、DJB）。当然，也可以使用取模操作等常规的散列函数。而散列本质上是一个从大空间到小空间的单向函数，通常表现为：
H（M）= D
其中H表示散列函数，M表示原始信息，D表示散列后的散列值。对于通常的散列函数来说，由于散列后的值D所许可的空间往往远大于实际使用的存储节点的数量，如最小的D一般也有2字节，也就是有65 536种可能，而被使用的存储节点一般为几十、几百的数量级，为了映射到具体的存储节点，还需要对计算结果D做一次取模操作。例如，有N台服务器作为存储节点，那么最终的存储节点编号就是：
i = H（M）% N
而这个i就是数据需要存储的节点编号。如果存储节点数量发生了变化，如从N变成了N+1，由于H（M）通常对应到至少2字节以上的空间，因此往往会远大于节点数字N，所以最后计算出的i会有极大概率发生改变。也就是前文提到的节点扩展导致的问题。为了缓解这个问题，卡尔格等人在1997年提出了一致性散列（Consistent [6]Hashing）的概念。当然，同样的问题在更早的时候就被天睿公司（Teradata）用散列表的方式解决过，只是它们没有使用这个词汇。[7]一致性散列的基本思想是将服务器节点也做一级散列，并且和数据散列的结果都分布到同一个环上。这样，每次放置数据节点的时候，就在环上顺序寻找一个就近的节点散列值，如果找到了就存放在这个节点上，过程如图2-3所示。图2-3 一致性散列寻址（节点正常）
所以，一致性散列有的时候也被称为一致性散列环。删除节点的过程如图2-4所示。图2-4 一致性散列寻址（节点失效）
需要注意的是，在原始的一致性散列环设计中，搜寻最近的节点总是沿着一个方行进，例如按顺时针方向行进。而在图2-3、图2-4的示例中，实际上是双向搜索的，这并没改变原算法的基本原理，从程序角度讲，只是把单向的距离比较变成了距离绝对值的比较。也就是从比较（a—b）的大小变成了比较|a—b|的大小。增加节点和删除节点的情况类似，大部分数据不会受到影响，但是散列结果在增加节点附近的数据就需要被写入新增加的节点。因此，一致性散列只能保证在节点增减的时候，大部分数据的存储位置不会发生变动，但是受到增减影响的那些节点的数据仍旧需要被存放到另外的节点上。也就是说，一致性散列算法并不能完全解决前文提到的扩展性问题。
此外，一致性散列算法的一个重要的优势是时间复杂度。这个时间复杂度一般是O（1）的。而使用了一致性散列算法后，由于必须就近寻找合适的节点（或者桶），这就需要查找，即使将所有存活的节点的散列值做好预先计算和排序，寻找最近值的时间复杂度仍旧是O（log（N）），其中N是存活的节点个数。这就增加了寻址的复杂度。当然，即使复杂度增加，也比通过网络通信去名节点上查找的用时要少。
几乎和一致性散列算法同期提出的还有约会散列算法（Rendezvous Hashing），有时也被称为最高随机权重散列（Highest [8]Random Weigh Hashing，HRW）。这个算法采用了另外一个思路，那就是根据需要来存储数据，数据在该算法中叫作对象（Object）；存储数据的服务器在该算法中叫作站点（Site，因为一致[9]性散列环和约会散列算法都是为Web上寻找合适的服务站点而研发的，后来被用于数据存储）。数据存储后计算出一个散列值。假定需要存储的数据是O，而每个存储节点按照编号Si来定，那么需要被计算的散列函数就是：
Di = H（O，Si）
计算出O针对的每个服务器的散列值Di，接着比较这些值的大小，选择出最大的Di（当然，也可以是最小的），然后这个数据O就会被存放在服务器Si上。由于散列函数H在同一个系统中是一致的，对于同一个数据O和给定的服务器Si也是确定的，因此计算结果Di不会改变。当增加或者减少了服务器之后，只要新增加的服务器所计算的Di不超过原来的最大值，或者减少的服务器不是最大Di的服务器，那么存放位置就不会改变。只有当这种计算值发生改变时才需要修改存放位置，这就造成约会散列算法与一致性散列算法的不同：约会散列算法无法预先计算。因每次的对象O的编号信息都是改变的，所以每次位置计算和查找的时间复杂度会上升为O（N）。
在一致性散列算法中，由于添加或者删除了节点后，查找就近节点可能找不到所需要的数据，就需要去查找第二近的节点、第三近的节点等，这样就增加了复杂度。同理，利用约会散列算法时，如果添加或者删除了节点，也需要查找计算值相邻的服务器。因此，完全不使用名查找节点，而单纯使用寻址方式（1），在实际应用中的情况较少。即使采用方式（1），也往往会引入一个注册机构，将存放信息注册一下，从而形成一种混合式的处理模式。
另外，根据散列函数公式可以知道，要使用散列函数就必须有原始的信息M，或者是约会散列函数中所称的O。这个信息在不同的系统中选择会不一样，有的会使用数据内容进行散列。但是数据内容的长度经常非常长，为了一个存放寻址动作就对整个内容进行散列是不经济的。因此，散列可以采用一些简单的信息，例如文件名加分片号。
即使使用名节点查询的方法，为了保证不同分片分布不同，也需要使用散列函数。当然，在Hadoop中使用了一种比较极端的模式，每次存入分片时用名节点查询，而名节点则索性采用随机方式分配。这可以被认为是一种特殊的散列函数，只是散列值同输入的原始信息M无关。或者按照伪随机数的定义，散列使用的输入信息是前一个散列值，同数据内容或分片无关。
仔细分析HDFS，又可以发现其中体现出了Hadoop的两个设计原则。第一，Hadoop面对大的数据量，因此HDFS的分片大小的缺省值是64MB （Megabytes，1MB通常是1 048 576字节，也可以大致认为是1百万字节，有时也被简称为1兆字节），这个值基本上平衡了分片数和分片尺寸，也是针对HDFS设计中主要面对的GB到TB数据量级（1GB分16个64MB片）。第二，考虑到同一机架上的服务器往往会共享电源和交换机，因此，如果出现电源或交换机故障，经常会发生整个机架上的服务器都无法工作的情况。虽然这种情况发生的概率不高，HDFS也会试图在一个分片、三个副本（一个主副本，两个从副本）的情况下，将一个副本存储到另一个机架的服务器上。所以，HDFS的名节点的随机方式不是真正的全随机，而是随机主副本，然后根据自己保存的机架信息所构成的服务器树，选择从副本所在的位置。列式存储
在被广泛使用的关系型数据库中，所有的数据实际上都是被存放在一个一个二维表中的。这个二维表的中文名称叫作“表”，而英文名称为“Table”。这些名字都反映出关系型数据库的基本形态，具体可参见表2-1。表2-1 示例数据
试读结束[说明：试读内容隐藏了图片]