购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

3.3 大数据技术体系

在云计算技术和计算能力提高的推动下,人们从大数据中提取有价值信息的能力也在不断地提升。同时,通过网络将人、设备及传感器连接起来,使得数据的生成、传递、分析及分享能力发生了根本性的变化。随着社会的不断发展,产生的数据就类型、深度及广度等方面而言是有极大增长的,这也对数据管理和数据分析技术提出了新的要求。只有在对大数据的容量、多样性、处理分析速度及价值挖掘这四个方面均有应对之策时,才可以从海量的数据里面挖掘出更多有价值的信息。大规模数据的存储、异构数据源融合、分布式文件系统、分布式数据库HBase、并行计算框架、大数据实时流处理及大规模图数据处理技术等均属于大数据技术的范畴。

3.3.1 大数据存储和管理技术

3.3.1.1 分布式文件系统

随着大数据时代的到来,海量数据在持续产生。为了有效解决存储大量数据的问题,Google公司开发了一种分布式文件系统GFS(Google File System),该系统使用网络来实现文件分布式存储在不同位置的多台计算机上,使得对大规模数据的存储需求有了较好的保证。同时针对GFS开发了相应的开源系统——Hadoop分布式文件系统(Hadoop Distributed File System,HDFS),旨在达到可以依托在低成本服务器集群中保证大规模分布式文件存储的目的。

HDFS在具备良好抗干扰的基础上,还具有兼容成本较低的硬件设备的特性,因而,在保障机器实现大流量及大数据量读写和分析的同时可以兼顾成本的控制。

物理结构上,计算机集群中的多个节点构成了分布式文件系统。大规模文件系统的整体结构如图3-2所示。这些节点可以分为主节点和从节点。其中,主节点也称为名称节点(Name Node),从节点也称为数据节点(Data Node)。文件和目录的创建、重命名和删除等由名称节点负责,还要检查数据节点和文件块之间的连接,因此要找到请求的文件块的位置,用户端必须到达名称节点并读取相应的文件块。数据节点负责存储和读取信息。在存储过程中,名称节点首先分配存储空间,然后将用户数据直接发送到需要存储的相关数据节点。传输首先通过名称节点接收用户端、相应的数据节点和文件块之间的连接,然后可以检索所需的文件块。根据名称节点命令和具体的情况查看是否需要进行创建、复制和删除相应数据节点的后续操作。

需要注意的是,分布式文件系统主要是针对大批量数据的存储所设计的,着重用于处理大规模文件(TB级文件),当处理规模较小的文件时,不但无法发挥全部优势,而且会影响系统的拓展性能。

图3-2 大规模文件系统的整体结构

3.3.1.2 分布式数据库HBase

针对Google公司的Big Table开发了分布式数据库HBase,可以看成前者的开源实现,HBase以其处理速度快、准确度高、适配列数据处理及延展性好的特性,应用十分广泛,主要用于非结构化或者半结构化数据的存储。同时,HBase支持超大规模的数据进行分布式存储,主要通过水平拓展的方式,借助低成本的计算机集群对超过数量级为亿行的数据元素所组成的数据进行处理和存储。

HBase是面向列的数据库,主要适用于批量数据的处理及实时查询,可以大大降低IO开销,支持大量用户的并发查询,同时具有较高的数据压缩比。HBase在数据挖掘、决策支持及地理信息等领域有着广泛的应用。

HBase与Hadoop生态系统中其他部分的关系如图3-3所示。HBase的运行原理就是利用Hadoop MapReduce来处理HBase数据库中所存储的大规模数据,可以在短时间内完成大批量数据的计算工作;利用Zookeeper框架实现协同服务,可以对向外提供的服务进行维护,保证服务的质量,还可以兼顾对执行失败的任务的重录工作;使用HDFS作为可靠度高的底层存储,借助低成本的计算机集群进行大规模数据的存储,提高数据的准确性和系统的完整性,从而发挥出HBase对大批量数据的处理能力;通过Sqoop实现高效、便捷的RDBMS数据存储,更为方便地在HBase上进行数据处理和分析;HBase的高层语言则由Pig和Hive进行保证。

图3-3 HBase与Hadoop生态系统中其他部分的关系

3.3.2 大数据分布式批处理技术

随着大规模集成电路的制作工艺已经达到一个极限,从2005年开始CPU性能遵循的“摩尔定律”——大约每隔18个月性能翻一番,已经不再适用。因此,把程序运行效率提高的目标放在性能更高的CPU上已经不可行。这也就催生出了分布式并行编程,在大规模的计算机集群中,包括大量的低成本服务器,运行分布式程序,可以并行完成大批量数据的处理分析任务,以此来获得海量的计算能力。

分布式存储和分布式计算是大规模数据集中处理的两大核心环节。其中Google公司的分布式数据存储的主要方式是分布式文件系统GFS,整个系统的各个功能部分分别是由不同的模块来实现的,由MapReduce负责分布式计算的任务。不同于前者数据存储适用的系统,在Hadoop中是使用分布式文件系统HDFS达到分布式存储目的的,采用Hadoop MapReduce来实现分布式计算。对于MapReduce而言,都是在分布式文件系统的基础上进行存储的,集群中的多个节点上存放着这个分布式的文件。

可以用“化整为零”来描述MapReduce的核心理念。MapReduce的工作流程如图3-4所示。按照一定的规则,将一个完整的待处理数据集合化整为零,即分解成多个分片,每一个小的分片都有一个Map任务与之对应,这些小任务在多台机器上并行处理,而在数据存储的节点上存储相应的Map任务,这样数据的计算和存储就可以在同一处运行,不需要消耗额外的数据传输资源。

图3-4 MapReduce的工作流程

需要注意的是,不同的Map任务之间是不会进行直接通信的,不同的Reduce任务之间也不会有直接的信息交换发生,这就说明用户是无法显式地将消息从一台机器发送给另一台机器的,意味着需要MapReduce框架自身去实现所有的数据交换任务。

3.3.3 大数据实时流处理技术

大数据计算技术包含批量计算技术和实时计算技术,其中批量计算技术只是针对大数据类别中的静态数据类,而实时计算技术则是针对动态数据或者称为流数据的数据类处理计算的。随着大数据处理分析实时性需求的日益增加,如何实时计算海量流数据成为大数据领域新的挑战。由于传统的MapReduce框架基于离线处理计算的方式,面对静态数据的处理分析有着独特的优势,但是其离线性也意味着无法满足流数据实时性的要求,因此产生了流计算这种大数据数据处理计算技术,流计算可以很好地符合流数据实时计算的要求。

流数据(或数据流)是指满足时间分布和数量无限的动态数据集合体,数据记录是组成数据流的最小单位。随着web应用、传感检测、生产制造等领域的发展,数据流开始兴起,其具备海量、时变、快速的特点。在日常的电子商务活动中,购物网站通过对用户点击流、浏览历史等行为的了解实时分析用户的购买意图,并实时推荐分析后的相关商品,达到提高商品销量的目的,同时也可以提升用户的购物体验,让用户感受到个性化的服务,可以一举两得。

流计算平台实时获取来自不同数据源的海量数据,为了获取有价值的信息需要做到及时的分析处理。在流计算中数据的价值会随时间的推移逐渐降低,因此,收取到数据时需要及时处理,如果缓存起来或是延迟使用批量处理的话就难以获得最有价值的信息。传统的数据处理流程如图3-5所示,需要将事先采集到的数据存储在数据管理系统中,之后用户才可以从数据管理系统中进行查询操作,从而获取到需要的查询结果。这也意味着传统的数据处理流程中所存储的数据已经不具备查询的时效性了。流计算的数据处理流程如图3-6所示,包含数据实时采集、数据实时计算及实时查询服务,所查询到的结果是具有时效性的,可以实时反映当时的事件状况。

图3-5 传统的数据处理流程

图3-6 流计算的数据处理流程

3.3.4 大规模图数据处理技术

大数据时代的来临也伴随着更多的大数据是通过大规模图的形式呈现出来的,如社交网络、气象数据及交通事故等,此外,为了更加方便地进行分析处理,大量非图结构的数据也时常会被转换成图模型。随着需要分析处理的图规模的日益增大,部分甚至达到亿数量级的边和顶点数,这时需要高效的处理分析图模型就会有很大的难度,也就意味着一台机器已经无法满足所有图数据的计算,急需一个分布式的计算环境。

现存的图计算框架和图算法库已经无法适配大规模图计算的需求,此时新的图计算框架应运而生,Pregel就是代表性的产品之一,这是一种基于BSP模型实现的并行图处理系统。在Pregel中搭建的一套可扩展的、有抗干扰机制的平台,可以很好地解决大型图计算的分布式计算问题,同时该平台提供了许多应用广泛的应用接口,用以满足不同类别的图计算需求。Pregel作为分布式图计算的计算框架,主要用于图遍历、最短路径、PageRank计算等。

Pregel计算模型以有向图作为输入口,在图数据进入计算模型以后,有向图的每个顶点都会被标签成一个字符串类型的顶点身份ID,并将用户的自定义值和这些顶点进行关联绑定,而源顶点则链接到每一条有向边,同时记录其目标顶点的身份ID,并将一个可修改的用户自定义值与之关联起来。

对于顶点之间的信息交互方面,Pregel舍弃了远程数据读取或者共享内存的方式,转而采用纯消息传递模型,如图3-7所示。采用这种做法主要基于以下两个原因。

(1)顶点之间的消息传递是可以包含足够信息内容的,无须使用远距离调用或内存共享的方式。

(2)对系统整体性能的提升具有很大的帮助。具体表现在大规模图计算一般是在一个计算集群环境中进行的,在集群环境中执行远程数据读取会有较大的延时,而Pregel采用异步和批量的消息传递方式,可以相对缓解远距离调用和处理产生的延时问题。

图3-7 纯消息传递模型 Na1cQQHkQiwwsN2BjZ4MvzJ+GEXIrGNMMqnTyWa8gJfs/laYrbqPM6GOSt8qpTHB

点击中间区域
呼出菜单
上一章
目录
下一章
×