第3章　大数据热点问题研究

大数据已经不能简单地从数据量方面进行理解，而是对大数据的分析方面进行理解，只有通过分析才能获取很多潜在的、深入的、有价值的信息。由于越来越多的应用涉及大数据，而这些大数据的属性，包括数量、速度、多样性等都呈现出大数据不断增长的复杂性，所以大数据的分析方法在大数据领域就显得尤为重要，并且对最终信息是否具有价值起着决定性的作用。

大数据分析普遍存在的方法理论如下。

① 可视化分析。大数据分析的使用者有大数据分析专家，同时还有普通用户，两者对于大数据分析最基本的要求就是可视化分析，可视化分析能够直观地呈现大数据特点，同时能够非常容易被使用者所接受，就如同看图说话一样简单明了。

② 数据挖掘算法。大数据分析的理论核心就是数据挖掘算法，各种数据挖掘的算法基于不同的数据类型和格式才能更加科学地呈现出数据本身具备的特点，也正是因为这些被全世界统计学家所公认的各种统计方法才能深入数据内部，挖掘出公认的价值。另外一个方面也是因为有了这些数据挖掘的算法才能更快速地处理大数据，如果一个算法得花上好几年才能得出结论，那大数据的价值也就无从说起了。

③ 预测性分析。大数据分析最重要的应用领域之一就是预测性分析，要从大数据中挖掘出特点，首先要建立科学的模型，之后可以通过模型代入新的数据，从而预测未来的数据。

④ 语义引擎。非结构化数据的多元化给数据分析带来新的挑战，需要一套工具系统地去解析、提炼、分析数据。语义引擎需要被设计成具有足够的人工智能能力，以便从数据中主动地提取信息。

⑤ 数据质量和数据管理。大数据分析离不开数据质量和数据管理，高质量的数据和有效的数据管理，无论是在学术研究还是在商业应用领域，都能够保证分析结果的真实性和价值性。

以上五个方面均是大数据分析的基础，进一步深入分析大数据，还需要更加复杂的理论和方法。

3.1　大数据存储管理与索引查询

随着信息社会的发展，越来越多的信息被数据化，尤其是伴随着Internet的发展，数据呈爆炸式增长。从存储服务的发展趋势来看，一方面是对数据存储量的需求越来越大，另一方面是对数据的有效管理提出了更高的要求。同时，数据量的增长也使得数据索引查询的重要性日益凸显。如何快速建立索引，如何准确查询出想要的数据是大数据研究中的一个热点问题。

3.1.1　大数据存储管理

所谓大数据存储，就是指数据在存储过程中的容量增长是没有止境的，因此用户需要不断地扩张存储空间。但是，存储容量的增长往往同存储性能并不成正比，这也就造成了数据存储上的误区和障碍。海量存储技术的概念已经不仅仅是单台的存储设备，而是多个存储设备的连接，这使得数据管理成为一大难题。因此，统一平台的数据管理产品近年来受到了广大用户的欢迎。这一类型产品能够整合不同平台的存储设备在一个单一的控制界面上，结合虚拟化软件对存储资源进行管理，这样的产品无疑简化了用户的管理。

数据容量的增长是无限的，如果只是一味地添加存储设备，那么无疑会大幅增加存储成本，所以海量存储对于数据的精简也提出了要求。同时，不同应用对于存储容量的需求也有所不同，而应用所要求的存储空间往往并不能得到充分利用，这也造成了浪费。

针对以上的问题，重复数据删除和自动精简配置两项技术在近年来受到了广泛的关注。重复数据删除通过文件块级的比对，将重复的数据块删除而只留下单一实例。这一做法使得冗余的存储空间得到释放，从客观上增加了存储容量。

具体到企业，企业所面临的大数据存储的问题主要源自于三个方面：一是存储数据的成本在不断地增加，如何削减开支节约成本以保证高可用性；二是数据存储容量爆炸性增长且难以预估；三是越来越复杂的环境使得存储的数据无法管理。企业信息架构如何适应现状，并提供一个较为理想的解决方案，目前业界有几个发展方向。

（1）存储虚拟化

对于存储面临的难题，业界采用的解决手段之一就是存储虚拟化。虚拟存储的概念实际上在早期的计算机虚拟存储器中就已经很好地得以体现，常说的网络存储虚拟化只不过是在更大规模范围内体现存储虚拟化的思想。该技术通过聚合多个存储设备的空间，灵活部署存储空间的分配，从而实现现有存储空间高利用率，避免了不必要的设备开支。

存储虚拟化的好处显而易见，可实现存储系统的整合，提高存储空间的利用率，简化系统的管理，保护原有投资等。越来越多的厂商正积极投身于存储虚拟化领域，比如数据复制、自动精简配置等技术也用到了虚拟化技术。虚拟化并不是一个单独的产品，而是存储系统的一项基本功能，它对于整合异构存储环境、降低系统整体拥有成本是十分有效的。在存储系统的各个层面和不同应用领域都广泛使用虚拟化这个概念，考虑整个存储大体分为应用、文件和块设备三个层次，相应的虚拟化技术也大致可以按这三个层次分类。

目前大部分设备提供商和服务提供商都在自己的产品中包含存储虚拟化技术，使得用户能够方便地使用。

（2）容量扩展

目前而言，在发展趋势上，存储管理的重点已经从对存储资源的管理转变到对数据资源的管理。随着存储系统规模的不断扩大，数据如何在存储系统中进行时空分布成为保证数据的存取性能、安全性和经济性的重要问题。面对信息海量增长对存储扩容的需求，目前主流厂商均提出了各自的解决方案。由于存储管理现状比较复杂，存储技术的发展在业界还没有形成统一的认识，因此在应对存储容量增长的问题上，尚存在很大的提升空间。技术是发展的，数据存储管理也是在不断变化的过程中得到完善，企业信息架构的“分”与“合”的情况并不绝对。目前出现了许多的融合技术，如网络附属存储（NAS）与网络存储（SAN）的融合、统一存储网等，这些都将对企业信息架构产生不同的影响。至于到底采用哪种技术更合适，取决于企业自身对数据的需求。

但是不论采取哪种方法，都不是最理想的大数据存储的方式，为了更好地支持大规模数据的存储、传输与处理，目前针对大数据存储的研究主要集中在如下三个方向。

① 高性能I/O（ Input/output，输入输出接口）。集群由于其很高的性价比和良好的可扩展性，近年来在HPC（High Performance Computing高性能计算集群）领域得到了广泛的应用，数据共享是集群系统中的一个基本需求，当前经常使用的是网络文件系统NFS或CIFS（Common Internet File System，通用网络文件系统）。当一个计算任务在Linux集群上运行时，计算节点首先通过NFS协议从存储系统中获取数据，然后进行计算处理，最后将计算结果写入存储系统。在这个过程中，计算任务的开始和结束阶段数据读写的I/O负载非常大，而在计算过程中几乎没有任何负载。当今的Linux集群系统处理能力越来越强，动辄达到几十甚至上百个TFLOPS（Floating-point operations per second每秒峰值速度），于是用于计算处理的时间越来越短，但传统存储技术架构对带宽和I/O能力的提高却非常困难且成本高昂。这造成了当原始数据量较大时，I/O读写所占的整体时间就相当可观，成为HPC集群系统的性能瓶颈。I/O效率的改进，已经成为今天大多数Linux并行集群系统提高效率的首要任务。

② 网格存储系统。高能物理的数据需求除了容量特别大之外，还要求广泛的共享。比如运行于北京正负电子对撞机（BECPⅡ）上的新一代北京谱仪实验Ⅲ（BESⅢ），未来五年内将累积数据5PB，分布在全球20多个研究单位将对其进行访问和分析，因此采用网格存储系统应该能够满足海量存储、全球分布、快速访问、统一命名的需求。网格存储主要研究的内容包括，网格文件名称服务、存储资源管理、高性能的广域网数据传输、数据复制、透明的网格文件访问协议等。

对于大数据存储问题，还有一些企业和机构从其他角度入手，例如使用新的存储介质，或是采用新的存储形式，这样都能从一定程度上解决大数据的存储问题，但是由于各个公司或单位的大数据来源各有不同，存储的方式不能一概而论，涉及具体问题的时候还需要选择不同的方法。

3.1.2　大数据索引查询

索引（index）是除表之外另一重要的、用户定义的存储在物理介质上的数据结构，当根据索引码的值搜索数据时，索引提供了对数据的快速访问。实际上， 没有索引数据库也能根据选择（Select）语句成功地检索到结果，但随着表变得越来越大，使用“适当”的索引的效果就越来越明显。

索引可以极大地提高查询效率，但由于使用索引需要一定的成本，不但需要占用很多的磁盘空间，而且需要自动维护，会增加执行数据操纵语言命令（DML）操作的成本，所以索引也不是创建得越多越好。也就是说，在大数据时代，对大数据的索引查询，并不是索引建立得越多越好，而是建立“适当”的索引，才能获得最好的效果。

一般而言，如果需要从一个大数据量的表中访问很小比例的行，那么就应该在这个表上建立索引。而下面几种情况下应不建或少建索引。

① 表的记录数太少。

② 经常插入、删除、修改的表。

③ 数据重复且分布平均的表字段。

④ 经常和主字段一块查询且主字段的选择率（列上不同取值的个数与数据总数的比值）非常高的表字段。

至于如何建立一个“适合”的索引，在不同的情况下有不同的方法，但是这些方法都有如下几个需要遵守的规律。

（1）对于查询中很少涉及的列或者重复值比较多的列，不需要建立索引

在查询的时候，如果不按某个字段去查询，则在这个字段上建立索引也是浪费。如现在有一张员工信息表，可能按员工编号、员工姓名或者出生地去查询员工信息。但是，人们往往不会按照身份证号码去查询，虽然这个身份证号码是唯一的。此时，即使在这个字段上建立索引，也不能够提高查询的速度，还增加了系统维护时间和占用了系统空间。另外，如上面的员工信息表，有些字段重复值比较多，如性别字段主要就是“男”、“女”，职位字段中也是有限的几个内容。此时，在这些字段上添加索引也不会显著的增加查询速度，减少用户响应时间。相反，因为需要占用空间，反而会降低数据库的整体性能。

（2）对于按范围查询的列，最好建立索引

在信息化管理系统中，很多时候需要按范围来查询某些交易记录。如在ERP系统中，经常需要查询当月的销售订单与销售出货情况，这就需要按日期范围来查询交易记录。如有时候发现库存不对时，也需要某段时期的库存进出情况，如5月1日到12月3日的库存交易情况等，也是根据日期来进行查询。对于这些需要在指定范围内快速或者频繁查询的数据列，需要为其建立索引。因为索引已经排序，其保存的时候指定的范围是连续的，查询可以利用索引的排序，加快查询时间，减少用户等待时间。

虽然可能需要按范围来进行查询，但是如果这个范围查询条件利用不多的情况下，最好不采用索引。如在员工信息表中，可能需要查询2008年3月份以前入职的员工明细，要为他们增加福利。但是由于表中记录不多，而且也很少进行类似的查询，如果为这个字段建立索引，索引所获得的收益要低于其成本支出，对数据库管理员来说，是得不偿失的。

再者，若采用范围查询的话，最好能利用TOP关键字来限制一次查询的结果，如第一次按顺序只显示前面的500条记录等。把TOP关键字跟范围查询一起使用，可以大大地提高查询的效率。

（3）对于一些特殊的数据类型，不要建立索引

在表中，有些字段比较特殊，如文本字段（TXT）、图像类型字段（IMAGE）等，如果表中的字段属于这些数据类型，则最好不要为其建立索引。因为这些字段有一些共同的特点，长度不确定，要么很长、要么就是空字符串。文本数据类型常在应用系统的数据库表中用来做备注的数据类型，有时候备注很长，但有时候又没有数据。如果这种类型的字段上建立索引，根本起不了作用，还增加了系统的负担。所以，在一些比较特殊的数据类型上，建立索引要谨慎，在通常情况下没有必要为其建立索引。

但是也有特殊的情况，例如在企业资源计划（ERP）系统中，有个产品信息表，其中有个“产品规格”这个字段，有时候其长度可能长达5000个字符。只有文本型的数据类型可以容纳这么大的数据量，而且在查询的时候，用户又喜欢通过规范这个参数来查询产品信息，若不为这个字段建立索引的话，则查询的速度会很慢。遇到这种情况时，数据库管理员只有牺牲一点系统资源，为其建立索引。

从这里也可以看出，虽然以上几条说的是一些相对共性的规律，但是否必须遵循，还需要数据库管理员根据企业的实际情况，做出合理的选择。

3.2　Hadoop性能优化问题

Hadoop由Apache Software Foundation公司将其作为Lucene的子项目Nutch的一部分引入的，Hadoop是用于处理和分析数据的分布式软件框架，特征是具有高可靠性、高效性及可伸缩性的特点。Hadoop可靠性表现在，假设存储节点会失败，采用数据副本的方式是保证节点失败后，仍可以从其副本中得到重新分配的依据。Hadoop高效性是指其采用并行计算的方式处理数据，提高处理速度。此外，Hadoop可以构建在廉价的计算机集群上，故被广泛使用。

Hadoop包括许多子项目，例如HBase、Pig、Hive、HDFS和MapReduce等，其中最核心的组成项目是HDFS和MapReduce。HDFS是一种分布式存储技术，为Hadoop的并行计算提供数据支持。MapReduce是一种并行编程模型，包括Map和Reduce两个部分，Map和Reduce的作用分别是作业的分解与结果的汇总。MapReduce和HDFS都是采用的主从式架构，通过构建主节点来屏蔽从节点复杂的底层结构。同时，该主从式架构简化了MapReduce使用文件目录的映射。

Hadoop由于其良好的扩展性和容错性，已得到越来越广泛的应用。Hadoop作为一个基础数据处理平台，虽然其应用价值已得到大家认可，但仍存在如下问题。

（1）Namenode/JobTracker单点故障

Hadoop采用的是主从式架构，该架构管理起来比较简单，但存在致命的单点故障和空间容量不足等缺点，这已经严重影响了Hadoop的可扩展性。

（2）HDFS小文件问题

在HDFS中，任何Block文件或者目录在内存中均以对象的形式存储，每个对象约占150byte，如果有10000000个小文件，每个文件占用一个Block，则Namenode需要2G空间。如果存储1亿个文件，则Namenode需要20G空间。这样Namenode内存容量严重制约了集群的扩展。

（3）Jobtracker并行监控和调度负载过大

为了解决该问题，Yahoo已经开始着手设计下一代Hadoop MapReduce。他们的主要思路是将监控和调度分离，独立出一个专门的组件进行监控，而Jobtracker只负责总体调度，至于局部调度，交给作业所在的客户端（Client）。

（4）数据处理性能

很多实验表明，其处理性能有很大的提升空间。Hadoop类似于数据库，可能需要专门的优化工程师根据实际的应用需要对Hadoop进行调优，称之为“Hadoop Performance Optimization（HPO）”。

为了提高其数据性能，很多人开始优化Hadoop，对于Hadoop当前主要有几个优化思路。

① 从应用程序角度进行优化。由于MapReduce是迭代逐行解析数据文件的，怎样在迭代的情况下，编写高效率的应用程序，是一种优化思路。

② 对Hadoop参数进行调优。当前Hadoop系统有190多个配置参数，怎样调整这些参数，使Hadoop作业运行尽可能的快，也是一种优化思路。

③ 从系统实现角度进行优化。这种优化难度是最大的，它是从Hadoop实现机制角度，发现当前Hadoop设计和实现上的缺点，然后进行源码级的修改。该方法虽难度大，但往往效果明显。

以上三种思路出发点均是提高Hadoop应用程序的效率，随着社会的发展，绿色环保观念也越来越多地融入了企业，因而很多人开始研究Green Hadoop，即怎样让Hadoop完成相应数据处理任务的同时，使用最少的能源。

3.3　图数据并行计算模型和框架

3.3.1　MapReduce模型

Google公司在2008年提出了MapReduce编程模型，MapReduce的实现使得很多基于大规模数据的最常用计算能够在大规模计算机集群上高效实现。

图3-1为MapReduce模型的示意图，图中正上方有一个用户程序（UserProgram），这是整个MapReduce过程的起点，因为它链接了MapReduce库，并实现了最基本的Map和Reduce函数。MapReduce过程大致如下。

① 首先通过MapReduce库，UserProgram输入的文件分成M份，M的大小由用户指定。图中左边就是将输入文件（Inputfile）分割成了切片（split）0～4，之后通过Fork将UserProgram拷贝到集群中其他机器上。

② 在UserProgram拷贝的副本中，有一个被称为调度者（Master），它负责任务的调度，其余的被称为实施者（Worker），Worker负责执行Master分配的任务。

③ 一部分Worker被分配了Map任务，Map任务的数量是和之前分割的split数量是一一对应的，Map任务就是从输入的数据中得到键值对（key-value对），之后调用Map函数生成键值对，然后这个键值对将被缓存在内存中。

④ 被缓存的键值对将会定期的写进磁盘中，并且被分为R个区，R的大小与Reduce作业的数量是一致的。键值对在磁盘中的位置是被通报给Master，而Master将键值对的位置信息转发给执行Reduce任务的Worker。

⑤ 负责Reduce作业的Worker收到Master发给他们的他们该负责的分区的地址，当Reduce Worker将他所负责的所有键值对都读过来之后，先将它们进行排序，使得键值相同的键值对聚集在一起。因为不同的键可能会映射在同一个Reduce Worker负责的分区。

⑥ Reduce Worker遍历所有的键值对，对每一个唯一的键，都将其对应的键值对传递给Reduce函数，函数的输出会添加到这个分区的输出文件中。

⑦ 当所有的Map和Reduce任务都完成了，Master将Use rProgram唤醒。

当MapReduce执行完毕后，其输出存放在R个分区的输出文件中，而这R个文件通常不需要合并，因为有可能需要将其作为输入交给另一个MapReduce程序来处理。

3.3.2　非MapReduce模型

在处理大数据问题时，MapReduce编程模型在处理数据并行类问题时具有良好性能，但是在处理其他问题时由于模型固化而无法使用最优的并行化模式，因而一些研究尝试对编程模型进行优化或是设计新的模型系统，具有代表性的设计有Merge、Haloop、Dryad等。

（1）Merge模型

Merge模型是雅虎的研究人员为了增强MapReduce对多数据集问题的处理能力而提出的，该模型在MapReduce模型的基础上增加了Merge阶段，如图3-2所示。

归并（Merge）模型只是对MapReduce进行了细微的改动，增加了多个数据集的合并功能，它的映射（Map）与规约（Reduce）阶段与原模型相同，可以当成多个MapReduce任务同步执行，而模型主要改进集中在Merge阶段，其主要功能是将不同Reduce的处理结果按照一定规则进行键值匹配，符合规则的匹配结果交由Merge阶段的函数处理。在Merge阶段，使用者需要定义Matcher和Merger两个处理过程，而Mergeselector定义则是可选的，与MapReduce模型中的Combiner类似。

（2）Haloop模型

Haloop模型是为了优化MapReduce对循环和迭代过程的运行效率而提出的，该模型的架构和设计思想如图3-3所示。

Haloop模型是在MapReduce模型的基础上增加了循环控制功能，将Job级的流程控制集成到了模型内部，在原系统的基础上增加了循环控制逻辑（LoopControl），同时为了实现模型内循环，还对结果数据的存储方式进行了修改，增加了缓存和索引，减少了对分布式文件系统的读写次数，有利于循环和迭代类处理任务执行效率的提升。与Haloop模型类似的还有Twister模型，该模型也是针对循环和迭代处理过程优化的问题提出的。

（3）Dryad模型

Dryad模型与上述几种模型不同，它是微软提出的一款全新的编程模型及系统，该模型的系统架构如图3-4所示。

在Dryad编程模型中，使用者可以定义多个处理函数，函数间的流程定义与依赖关系通过有向无环图定义。与MapReduce的中间数据传输有所区别，在Dryad模型中可以选择数据传输通道（Channel）的模式，可以通过内存、文件和网络等多种方式。

在Dryad系统架构设计中，资源管理与任务管理是相互独立的，图3-4中的名称服务器（NS，NameServer）节点负责系统资源管理，该节点的功能是发现并维护集群中的所有可用资源，并且掌握集群资源的拓扑结构，这样的设计有助于任务分配时优化资源配置，借助拓扑信息来降低数据传输的网络开销。而Dryad的任务管理则对图3-4中的作业管理（JM，Job Manager）进行管理，它根据定义好的任务流程图来进行任务管理，确定处理函数的下发和中间数据的传输，而与MapReduce系统任务管理最大的区别在于，JM在逻辑上是与任务对应的，可以部署在系统外部，甚至可以使用用户终端来担任。

除了MapReduce类系统和Dryad模型系统以外，新的通用并行计算编程模型系统设计还有Nephde、Nephele/PACTs等，在此就不逐一介绍。

3.4　并行化机器学习和数据挖掘算法

随着互联网的广泛应用，使得网络环境逐渐成为一个“大数据”环境。在大数据量环境下进行关联规则的挖掘需要大量的计算资源，分布式系统是一个可行的方案，许多网络应用本来就是分布式的，这就方便了分布式系统的应用，分布式的关联规则挖掘算法就应运而生了。分布式关联规则的挖掘其本质上是一种并行的关联规则挖掘，但它是基于计算机网络环境下的关联规则挖掘。分布式关联规则挖掘算法具有高度的适应性、可伸缩性、低性能损耗和容易连接等特性，所以它可以作为关联规则挖掘的理想平台。

3.4.1　记数分布算法

记数分布算法（Count Distribution，CD）是一种典型的基于Apriori的并行算法。在第一阶段，每个分区独立地进行数据库扫描，计算出各个候选集的支持度，然后将各候选集的支持度进行相加得到全局支持度，相加后的支持度若大于最小支持度则认为该项集是频繁项目集。CD算法在每一次扫描结束后需要一个同步点，然后再进行下一次分区的扫描。CD算法在每一次扫描后的通讯量复杂性为O(n2)，因为随着结点数的增多CD算法的通讯量将迅速增加，因此CD算法不能作为一种扩展性好的分布式算法。图3-5为CD算法示意图。

3.4.2　数据分布算法

CD算法是在任意水平分区的基础上进行并行计算，而数据分布算法（Distribution，DD算法）着眼点主要是放在优化分区上面。DD算法的基本思路是将候选项集在各个结点之间进行均匀分布，这样处理可以在随着结点增加时每遍扫描的候选项集数目可以减少，从而提高算法的并行效率。其缺点是各个结点之间的数据要进行传递，这样在各个结点数据量较大的情况下会降低算法的效率。图3-6为DD算法示意图。

3.4.3　有限差分算法

为了减少各个分区间的通讯量问题，有限差分算法（FDM）对CD算法进行了改进；FDM算法首先在每个分区中运行Apriori算法找出每个分区局部大的项集，然后在每个节点全局大的项集之间进行支持度和计数交换，FDM算法在每一次扫描后的通讯量复杂性为O(n)。

3.5　Web信息挖掘和检索

传统的数据库系统提供了有效的和可靠的技术来查询结构化数据，然而由于WWW的迅速发展，越来越多的信息以非结构化或半结构化的形式存储，如超级文本标记语言（HTML）文档。目前，对这类文档数据的访问主要是基于浏览和信息检索技术，已知浏览器和搜索引擎检索信息的能力是非常有限制的。由于数据库概念和管理与查询Web信息的内在相关性，研究如何对Web信息查询的应用数据库技术就成为热门话题。目前的研究可分为以下三个方面。

（1）模型化Web及查询

假设把Web看成一个有向图，节点代表Web页，边表示页之间的连接。首要任务就是形成查询语句从Web上检索相关Web页，查询可以是基于所需查询页的内容，也可以是基于连接页之间的连接结构，像目前的搜索引擎定位Web页就是基于Web页中所包含的关键字。比较复杂一些的查询可以对页中的内容进行判断，如发现其中包含词语“风景”的页面，跟在一个指向一幅图像链接页面之后。更高级查询例子可以涉及Web页面的结构，例如查询从根节点CNNWeb站点出发到可达的五个链接之内的所有图像。

（2）信息抽取和集成

整个Web就是一座数字图书馆，其中的信息都被分散地包含在一个个的Web文档页中，也称为Web数据库。但不能像查询传统数据库那样来查询Web数据库，于是很多学者就研究如何从HTML文档页中挖掘抽取所需数据以及怎样查询异构数据源。所以在这方面，目前集中在两个方法研究的最多：一是从HTML文档页抽取数据的结构，通常是由一套进程信息（Wrapper）程序来执行，这个方法存在的问题是这些Wrapper程序的自动化创建和维护；二是异构数据源的数据集成查询，可借助中介者模式（Mediato）来对数据进行集成。

（3）Web站点构建和重构

与数据库概念和技术相关的另一个Web应用是建立、重构和管理Web站点，前面两部分讲的是处理现有的Web站点，而现在要考虑站点创建过程。Web站点能通过存储在数据库或结构化文件中的原始数据来创建，或对现有的Web站点进行重构。完成这个任务需要一定的方法，主要是对Web站点的结构过程模型化或建模，需要重构以后模型的查询语言。

3.5.1　数据模型

解决上述三个问题中的任一个都需要建立一个数据模型，对Web本身、Web站点结构和Web页面的内部结构都要模型化。下面列出两类常用的数据模型。

（1）标志图数据模型

如上面所说的，这些Web应用需要对Web页和Web页之间的连接过程模型化。这些页面可能分散在几个站点也可能处于同一个站点内，因此模型化这些数据的一个自然方法需考虑用基于标志图的数据模型，在标志图数据模型中，节点表示Web页或Web页的内部组件，弧表示页面之间的连接，弧线上标志是属性名。对标志图数据模型，已有针对其查询的一些语言，这些查询语言一个共同特征是都有对图形成规则路径表达过程的查询能力。

（2）半结构化数据模型

在很多情况下有关Web数据的结构是很不规则的，不能事先对其指定一个固定的图解。当对来自多数据源的数据模型化时，一些数据属性的表示因数据源的不同而不同，因此这种情况把这些数据看作半结构化数据是比较适合的。半结构化数据有如下一些特征。

① 其图解不能事先给定，可能被隐含在数据中。

② 图解大小可能相对较大，而且其图解会经常变化。

③ 数据不是强类型的，对不同的对象、相同属性的值可以有不同的类型。

有文献提出了一种基于有向标志图的半结构化数据模型。在半结构化数据模型中，对起源于一个给定节点的弧集合没有加以限制，或者说对属性值的类型没有限制，对半结构化数据的查询可以通过弧变量（其约束到弧标志上），而不是节点查询。

3.5.2　查询语言

（1）查询语言的一般性分类

当对Web数据建立了数据模型之后，另一个要考虑的问题是如何才能得到模型中的数据信息，这就需要开发查询语言来查询模型化的数据。当前广泛使用的搜索引擎（SearchEngines）是第一个Web数据查询的工具，其查询主要是基于被网络爬虫（WebCrawlers）搜索所发现的文档页中的字和词的索引，这个方面有很大的局限性，没有利用Web的连接结构、页面结构，有文献还提出了利用Web结构来提高搜索引擎搜索关于某一主题的权威性Web源。除了SearchEngines外，还有很多的查询语言可以用来查询Web数据，大致可分为如下三种。

① 超文本文档查询语言。

② 图查询语言。

③ 半结构化数据查询语言。

（2）Web查询语言

Web查询语言发展至今已有各种各样的查询语句出现，从功能上来分，可以分为两代语言。

第一代Web查询语言。第一代查询语言目标是把数据库使用的基于结构的查询与搜索引擎使用的基于内容的查询接合起来，像WebSQL、W3QS、WebLog是其代表，它们把Web文档页看作带有两个属性的原子对象，这两个属性是Web页是否包含一定的文本模式和指向其他对象的链接。这些查询语言在以下两个应用方面是很有用的，数据打包、转换和重构，Web站点构建和重构。

第二代Web查询语言。在上面提到的两个应用中，如何能访问Web文档页的内部结构是问题的本质所在，例如从HTML页中抽取数据元组集合，第二代查询语言能满足这个要求。第二代查询语言又称为“Web数据操作语言”，在下面两个方面优于第一代查询语言，一是它们提供访问Web对象内部结构的方法，与第一代查询语言不同的是，第二代查询语言不仅模型化连接Web文档的外部连接而且还模型化Web文档的内部结构，其中的一些还支持有序集合和记录的更自然化的数据表示；二是第二代查询语言能为查询结果创建新的复杂结构，由于Web上的数据通常是半结构化的、甚至是非结构化的，这些语言仍强调支持半结构化特征的能力，例如Web OQL、Strudel和Florid是第二代查询语言。

3.5.3　Web文档页的数据抽取

从Web文档页中抽取信息数据是上节提到的Web应用中的一个方面，也是本节中所要讨论的主题。目前被广泛使用的方法是利用进程信息（Wrapper）来对Web页进行分析，下面一节将介绍有关Wrapper的一些情况。

（1）Wrapper组件

通过对WWW信息源建立相应的Wrapper，使之能够像访问传统数据库那样访问这些信息源。一个Web源的Wrapper接受查询，从Web信息源取回相关文档页，根据一定的语句（如Web页的语句结构），解析这些文档页，把Web页中的数据映射成预定义的特定形式，如根据定义的数据模型将Web页映射成一棵标志树。

建立Wrapper的三个步骤：

① 分析源文档页结构。包括识别页面中相关区域和子区域，这个任务通过分析页面中的HTML标志以及它们之间的等级关系来完成，这步一般需要有人工介入。

② 为源文档页建立分析器。根据第一步分析得到的语句和词汇信息分析器被自动产生。

③ 在Wrapper、Mediator和Web源之间增加通信。Wrapper从接受查询到提交结果需要知道页面在网络上的位置信息，与文档源的连接以及与Mediator之间的通信，这些都需要Wrapper有与外部通信的能力，对WWW源建立相应的Wrapper。

两个优点：

① 能像查询数据库方式查询Web信息源。

② 对所有建立了Wrapper的信息源能使用一个公共查询语言，通过Mediator能以集成化的方法访问异构信息源。

两个缺点：

① 需要预先知道数据源的结构知识。

② 当数据源变化之后，建立好的Wrapper不能自己随着改变，需要额外的工作来对Wrapper进行调整。

为利用Wrapper的优点克服其不足之处，大量的研究工作仍在进行中，有的提出对Wrapper应用机器学习来自动学习文档页面信息，以提高其创建的自动化性和适应Web信息源的动态性。

（2）基于Wrapper的Web查询方法

目前最普遍的方法是Wrapper使用文献的方法，Wrapper解析来自特定Web源文档页将其映射成预定义的格式。尽管Wrapper提供了从Web源抽取数据的有效方法，但仍存在上节列出的两个显著缺点，而且目前Wrapper的产生还是半自动化的。

（3）基于实体的Web数据抽取

有相关文献提出，使用一个语义数据模型来提供一个应用实体，该实体描述相关数据，包括数据之间的关系、出现的词汇和关键文本。通过解析这个实体自动产生一个关系数据库图解和一个“常量/关键字”识别器，识别器用来抽取填充到数据库中的数据。这个方法是非常有效的，但需要手工来为一个给定应用领域创建一个应用实体。

（4）基于实例的Web数据抽取

这是一个从Web源抽取半结构化数据的很有创造性的思想，是系统从用户提供的一对样本对象收集必要信息，然后用这些信息从新的页面中抽取新的对象或文本。

3.6　大数据可视化计算与分析

大数据分析是大数据研究领域的核心内容之一，数据的分析过程往往离不开机器和人的相互协作与优势互补。从这一立足点出发，大数据分析的理论和方法研究可以从两个维度展开，一是从机器或计算机的维度出发，强调机器的计算能力和人工智能，以各种高性能处理算法、智能搜索与挖掘算法等为主要研究内容，例如基于Hadoop和MapReduce框架的大数据处理方法以及各类面向大数据的机器学习和数据挖掘方法等，这也是目前大数据分析领域的研究主流；另一个维度从人作为分析主体和需求主体的角度出发，强调基于人机交互的、符合人的认知规律的分析方法，意图将人所具备的、机器并不擅长的认知能力融入分析过程中，这一研究分支以大数据可视分析（Visual Analytics Of BigData）为主要代表。

一幅图胜过千言万语，人类从外界获得的信息约有80%以上来自于视觉系统。当大数据以直观的、可视化的图形形式展示在分析者面前时，分析者往往能够一眼洞悉数据背后隐藏的信息并转化为认知。如图3-7所示是互联网星际图（http://internet-map.net/），将196个国家的35万个网站数据整合起来，并根据200多万个网站链接将这些星球通过关系链联系起来，每一个星球的大小根据其网站流量来决定。而星球之间的距离远近则根据链接出现的频率、强度和用户跳转时创建的链接，可以立即看出Facebook和Google是流量最大的网站。这些“一眼”识别出的图形特征（例如异常点、相似的图形标记）在视觉上容易察觉，而通过机器计算却很难理解其涵义。因此，大数据可视分析是大数据分析不可或缺的重要手段和工具。事实上，在科学计算可视化领域以及传统的商业智能（Business Intelligence）领域，可视化一直是重要的方法和手段。

可视分析是大数据分析的重要方法，能够有效地弥补计算机自动化分析方法的劣势与不足。大数据可视分析将人面对可视化信息时强大的感知、认知能力与计算机的分析计算能力优势进行有机融合，在数据挖掘等技术的基础上，综合利用认知理论、信息可视化以及人机交互技术，辅助人们更为直观和高效地洞悉大数据背后的信息、知识与智慧。