BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

大数据管理系统LAXCUS(一):基础与数据

| 作者 梁祖邦 关注 0 他的粉丝 发布于 2014年12月25日. 估计阅读时间: 38 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

前言

LAXCUS是一套数据管理软件,应用于大规模数据存储和计算环境。这是一个独立和完整的产品,融合了包括数据存储、网络通信、网络计算、数据安全、网络安全、任务调度、容错处理、自动化管理、人机交互接口、应用开发等多方面的技术。LAXCUS采用JAVA语言编写,支持行/列两种数据存储,通过终端或者应用接口嵌入方式接入,执行SQL和类SQL操作。产品布署使用快捷简单,遵循LGPL协议,开放源代码,运行在LINUX平台。

1.1 基于现状的一些思考

在过去十几年里,随着互联网络和各种新兴技术的快速发展,数字信息存量呈爆炸性增长之势。面对如此庞大的数据,如何实现高效的存储和计算,通常采用的提高CPU性能和改用更大容量磁盘的做法,已经变得越来越困难。在这种背景下,以网络和网络通信技术为依托,将分散在不同地理位置的计算机连接起来,组成空间上分散、逻辑上统一的数据存储和计算集群,成为当前实现大规模数据处理的主要选择。

集群计算的优势在于:它强调总体的处理能力,每台计算机做为单个节点参与计算过程,承担其中一部分计算任务,处理能力的强弱由全部节点共同决定。这种工作模式极大地发挥出网络的能量,使得单台计算机的处理性能变得不再重要。并且由于网络的连接,每台计算机随时可以加入或者撤离计算过程。这种类似计算机“即插即用”的功能,使得集群在运行过程中可以动态地调整自己的计算能力,赋与了集群计算近乎无限增长的可能,这是传统的集中式计算无法比拟的。同时由于不再追求单台计算机的处理性能,采购硬件设备时,可以根据实际应用需求酌情考量,为节约成本投入提供了选择的空间。

但是必须看到,正如硬币的两面一样,集群计算在提供了前所未有的处理能力的同时,也有着它与生俱来的许多问题。

首先由于连接的节点众多且分散,集群组织结构变得庞大。个体硬件品质良莠不一,网络线路、通信设备、计算机之间的连接和通信过程存在着不确定性,硬件设备内部、设备与设备、设备与外界环境,彼此互相交叉影响。在这样的条件下,保证每台设备完全稳定运行已无可能,解决集群组织不安定状态下的稳定计算成为首要问题。

另外,与集中计算不同的是,集群的数据处理是一个分散的计算过程。它的前端受理大量的请求任务,然后将这些任务分配到后端众多的计算机上去执行。一个高效并且合理的分布计算算法成为必须。算法需要解决的问题包括:任务分配、过程调度、故障容错、数据筛选、数据平衡、数据汇总等诸多环节的工作,最终形成与集中计算一样的处理结果。这个过程十分复杂。

数据管理益变得重要。在一个大规模的数据存储序列中,要保证完全正确的处理结果,任何单点上的数据都不能遗漏。这需要感知每个数据的存在,确定数据的物理位置,能够验证数据的可用性和正确性,即使在故障状态下,仍然需要确保计算过程的正常进行。这是对数据处理的基本要求。

更重要的是用户体验。没有人会喜欢一个复杂、繁琐、难以维护的系统。相反,一个人机界面友好、容易操作的产品更容易受到用户青睐。这需要在产品设计时做很多工作,综合考量产品的应用范围、处理效率、运营成本,以及用户的使用行为和习惯,做出必要的取舍,辅以技术实现,才能产生良好的使用体验。

当能够提供的硬件基础设施已经固定,各种应用需求还在不断发展和变化,如何适应这种变革中的趋势,以上种种,都是软件设计需要思考的问题。

1.2 产品特点

由于新的系统基于网络环境,需要适应数据在存储量和计算能力上的可调节的增减,这种运行中动态波动的数据计算,完全不同与传统的处理方式。一系列新的变化促使我重新审视产品的定位和设计,这些因素叠加在一起,最终形成了与以往完全不同的结果。

1.2.1 以普通硬件为标准的动态可伸缩的容错处理

LAXCUS将集群设备的硬件参考标准定位为普通的个人计算机。这种设计有两个好处:1.将用户的硬件设备投入成本降到足够低;2.需要充分考虑硬件的不稳定性。在产品设计和实现中,硬件的不稳定由软件通过监控和故障冗灾机制来弥补恢复,任何设备和设备组件的失效被视为正常情况,而不是异常。设备故障通过自检报告和管理服务器追踪来感知。发生和发现故障后,故障点将被隔离,同时通知系统管理员。设备的故障恢复被视为新设备加入。故障设备中的数据通过多机冗余备份和复制机制来保证有效存在。

1.2.2 弱中心化管理

见图1.1,运行中的集群由节点构成。节点按功能划分为管理节点和任务节点,TOP和HOME是管理节点,其它都是任务节点。管理节点是整个集群的核心,承担着监督和管理任务节点作用。与强调管理节点的中心全责监管的理念不同,LAXCUS采取了弱中心化的管理设计措施。在LAXCUS集群中,管理节点只承担少量和重要的管理任务,任务节点在负责具体工作的同时,也需要监视自身的工作行为。这种自维持的工作方式,可以减少与管理节点的通信。带来的优势就是:管理节点的压力减轻,能够腾出更多计算能力处理主要的任务,任务处理速度可以更快,服务器硬件配置因此可以降低。任务节点由于自维持的特点,既使在管理节点宕机情况下,也能维持一段时间的正常运行,直到再次发起对管理节点的请求。而这段时间内,管理节点可能已经恢复。弱中心化管理增强了集群的稳定性。

1.2.3 多集体群的协同工作模式

见图1.1的LAXCUS集群结构图,其中包括两个HOME集群,TOP节点位于两个HOME集群上。这是一个典型的多集群结构模型,LAXCUS最显著特点之一,就是能够支持多个集群跨地域协同工作,这与单集群处理系统有着根本的不同。在传统的单集群系统中,管理节点承担着管理维护整个集群运行的工作任务,如果一味提高集群中计算机的数量,就会增加管理节点的处理压力,从而影响到集群的稳定运行。采用多集群协同工作方式后,将每个集群的计算机数量限制在一定规模,则能够有效化解这个可能成为瓶颈的问题。另一方面,由于多集群结构是数个子集群的组合,每个子集群可以分散在不同甚至遥远的地理位置,只要能够通过VPN或者互联网络实现连接,就能够实现更大规模的网络计算,成倍增加集群的数据处理能力,进一步提升工作效率。

1.2.4 以支持大规模检索/添加为主,兼顾小批量删除/更新的数据处理

在产品设计前,通过对大量数据操作行为的追踪和分析发现,数据操作主要集中在添加和检索阶段,删除和更新极少发生,其中检索行为又远远超过添加。这个现象促使我对数据存储设计产生了不同以往的定位,将整个存储方案重点围绕着检索展开,并据此制定了以下的执行策略:首先,为保证大数量高频度的检索操作,结合到计算机内的CPU、内存、磁盘各主要工作部件的性能,在保持数据的最大吞吐量上,流式处理效率最高。并行的数据写入在进入存储层面时,汇流为串行模式。检索操作的最终目标是磁盘(温彻斯特硬盘),磁盘检索受制于磁盘物理特性的影响,在数据计算过程中,严重拖滞了整体性能的发挥,为提高数据处理性能,需要在检索前对数据进行优化,如关联和聚凑,同时提供一批优化规则给用户,让用户能够按照自己的意愿去组织和检索数据。删除不改变数据本身,只对数据做无效记录。数据更新分解为删除和添加两步操作,其目的在于简化和内聚数据处理流程,同时避免发生多次磁盘读写现象。

1.2.5 数据即时存取

即时存取是衡量系统是否支持实时处理的关键性指标。其表现是数据一旦进入存储环境,立即生效并且可以使用,而不是之后的某一个时段才能生效和使用。由于实现了即时存取,LAXCUS可以保证在任何时间任何范围内对全网数据执行无遗漏的检索,达到与关系数据库同等的响应能力。即时存取非常重要,是许多关键业务处理必须满足的一项功能。

1.2.6 SQL

LAXCUS采用SQL做为系统的人机交互接口。采用SQL的原因主要有二:以关系代数为后盾的理论基础,优秀的类自然语言表述能力。关系代数将数据处理和处理结果的严谨性得以体现,类自然语言使得SQL灵活简单、易学易用,还有其丰富的功能、语法规范标准化、被普遍接受的程度、管理维护成本低,这些都是促成LAXCUS采用SQL的原因。更重要的是,在SQL发展的四十年里,其衍生出的各种数据设计思想和使用经验,影响延续到今天,即使在这个大规模数据处理时代,也是可以借鉴和弥足珍贵的。

但是大规模数据处理和以SQL为代表的关系数据库的应用需求毕竟有太多不同,所以本着扬弃的原则,LAXCUS保留了大部分SQL功能,取消了一些不合适大规模数据处理的定义,对其中一些定义中的元素和概念进行了调整,同时引入了一批新的概念和操纵语句。这些变化,都是为了适应大规模数据处理时代所做的抉择。

有关SQL的更多介绍,将在第6章阐述。

1.2.7 网络计算可编程接口

为了满足各种大规模数据计算业务需要,方便用户开发LAXCUS上运行的网络计算中间件程序,LAXCUS为程序员提供了一套经过抽象处理的网络计算可编程接口。接口将网络计算流程规范化,屏蔽了系统的服务部分,呈现给程序员的是一组可派生的接口类。这样就使程序员不必考虑网络计算过程中的任务分配和调度问题,只需要将精力集中到业务规则的编程实现上。完成后打包发布,剩下的工作,将交给集群去托管处理。用户可以通过终端,使用SQL和类SQL语句操作中间件运行。LAXCUS将集群环境下的大规模计算任务简单化,降低了程序员的开发难度和用户布署使用的压力,也减少了故障发生概率。为防止运行中的错误,LAXCUS还提供了一套错误检索机制,帮助快速定位和检查错误,尽可能不影响系统运行。 出于安全的考虑,这些中间件程序被限制在“沙箱”框架内工作,避免因为恶意破坏或者越权操作影响到系统正常运行。

1.3 架构

如图1.1所示,LAXCUS是一个由多种类型节点组成,通过网络实现连接,有任意多个子集群同时运行的数据存储和计算的集群。节点在这里是一个逻辑单位概念,每个节点都严格遵守设计规定的工作范围。理论上,一台物理计算机上可以拥有任意个节点,包括组织成为一个集群。节点从工作属性来看,具有双重身份,即是服务器又是客户端。当它做为服务器使用时,接受来自其它节点的任务调度;当做为客户端使用时,会向其它节点发送处理命令。节点按功能分为管理节点和工作节点。管理节点在所属集群内可以同时存在多个,但是只能有一个处于运行服务状态,职责是监督和控制所属范围内的节点运行。其它管理节点处于备用状态,监督这个运行节点的工作,当运行节点故障失效时,通过协商方式推选出一个新的节点,来接替故障节点继续实施监督和控制工作。工作节点可以有任意多个,数量上没有限制,视用户需求决定。各节点之间通过网络进行任务分配和调用,形成分散且协同的工作模式。软件层面上,节点实质是LINUX系统根用户下的一个进程,没有操作界面,在后台运行,启动时运行一个网络通信服务器保持与外界对话。

(点击图像放大)

图1.1 LAXCUS集群

1.3.1 TOP节点

TOP是管理节点,是LAXCUS集群的基础核心节点,必须保证有效存在。其它类型的节点都是TOP节点的下属节点,TOP节点在其它节点前启动,在其它节点全部停止后才能停止。TOP节点的管理范围包括:接受、保存、检查、分配所属的用户登录账号、操作权限、数据库配置、网络资源,同时接受HOME节点和终端的注册,以及监测它们的运行。如上面所述,TOP节点做为管理节点要求有多个,但是通常要求一个运行节点和最少一个备份节点,因为TOP节点故障会造成整个集群的运行管理混乱,随时保持最少一个备份节点替代故障节点是必须的。TOP备份节点在备用期间,除了监测运行中的TOP节点,还会通过网络定时复制它的管理资料和运行数据。当运行节点发生故障后,协商选举出的新的运行节点会通知原来的HOME节点和终端,重新注册到它的环境下。

通常情况下,TOP节点只维持不多的HOME节点和终端/应用接口的通信,所以它的管理任务并不繁重。

1.3.2 HOME节点

HOME节点是LAXCUS子集群(也称HOME集群)的管理节点,是HOME集群的核心。对上,向TOP节点注册,接受TOP节点的管理;对下,接受所属集群节点的注册,监控和协调它们运行。LAXCUS中定义的工作节点全部运行在HOME集群内。HOME节点的管理范围包括:汇总工作节点的元信息、追踪工作节点的运行状态、检测网络故障和故障节点、控制数据块分发、协调集群负载均衡。与TOP节点一样,HOME集群也要求一个运行节点和最少一个备份节点,备份节点定时复制运行节点上的运行数据。

1.3.3 LOG节点

在整个运行过程中,LOG节点唯一的工作就是接收和保存其它节点发来的日志信息。对这些节点,LOG节点将根据它们的节点类型和节点地址建立目录,日志文件名是当前操作系统日期。日志中的主要信息是各节点的工作流程和运行错误,这些信息能够为分布状态下的数据追踪和分析、程序调试、定位和判断节点运行故障提供重要依据,所以LOG节点的工作虽然简单,但是非常重要。

1.3.4 CALL节点

CALL节点介于LAXCUS集群的中继环节,起到类似路由器的作用。对外,它接受终端和应用接口的调用;对内,它定时收集DATA、WORK、BUILD节点的运行信息,把终端和应用接口的指令转换成具体的操作任务,分派给DATA、WORD、BUILD节点执行,并且在中间协调网络计算过程,将最后的计算结果返回给任务发起方。CALL节点通常做为一个根用户进程独立运行,也可以是一个WEB服务器(如TOMCAT)的子进程,绑定在WEB服务器上运行。CALL还是集群中除TOP节点外,唯一与外界保持联络的节点。

1.3.5 WORK节点

WORK节点在整个运行过程中只做一件事:接受CALL节点调用,执行具体的数据计算。在实际应用中,WORK节点的工作量会很大,经常发生硬件部件使用达至极限的超载现象(如CPU的使用率达到100%)。如果这种现象持续存在,WORK节点会通知CALL节点,减少对自己的调用。

1.3.6 DATA节点

DATA节点提供数据存储服务,它的数据管理范围包括:建立、检查、回收数据空间,接受SQL操纵,添加、检索、删除、转发、检查、优化数据。DATA节点有“级别”概念,分为“主节点”(PRIME SITE)和“从节点”(SLAVE SITE),它们的区别在于数据处理范围不同。主节点具有“读/写”能力,负责数据的添加、删除、更新、检索、优化工作,从节点只执行读操作,承担检索和来自主节点的数据备份工作。网络计算的初始数据也从DATA节点上产生,数据来源一般是SQL SELECT的检索结果,或者根据业务规则生成的信息,这些数据将提供给后续的WORK节点使用。

1.3.7 BUILD节点

BUILD节点的工作是处理ETL业务(extrace、transform、load),它在执行前会收集DATA节点的数据,然后执行ETL处理。一般经过BUILD节点处理后的数据计算效率会更高。系统提供了一套API接口,支持ETL业务服务。用户需要派生接口实现自己的业务流程。与其它节点不同的是,BUILD节点只在收到用户或者管理节点的作业指令后才进行工作,通常情况下都处于空闲状态。

1.3.8 终端

终端是由用户驱动的界面输入接口,为用户提供SQL和类SQL语句的远程操控能力。 它能够在任何可以联网的位置运行,是一个纯客户端的概念。所以,从这一点严格地说,终端并不属于集群范畴。为适应不同操作系统和用户的使用习惯,LAXCUS提供了两种模式的终端:基于字符界面的LAXCUS Console和基于图形界面的LAXCUS Terminal,如图1.2和图1.3。图形界面的终端主要是考虑了WINDOWS用户的需求,而专业的LINUX用户可能更喜欢使用字符界面。两种终端的操作指令是完全一样的。

图1.2 LAXCUS字符终端

图1.3 LAXCUS图形终端

当前发生的很多大规模数据计算,一次计算驱动几个GB的数据已经是十分普遍的现象。这种在网络间传递,数量大、发生频度高的数据处理,需要保证数据具有足够的稳定性和可靠性,才能正确完成计算任务。这是一个复杂的工作,必须兼顾好每一个环节。在这一章里,将从数据的存储、组织、分配、维护等多个角度去阐述数据的设计和管理,以及如何优化它们。

2.1 数据块

在实际的数据应用中,一个单位的数据尺寸往往有很大的随机性。小者可能是几十个字节,大者可能达到数十兆,甚至数百兆。当一个集群里的计算机,每台计算机的数据存储量达到TB规模,每天可能处理的数据超过PB量级的时候,即使磁盘文件系统支持这种单位的存储,也将使磁盘运行不堪重负,这是操作系统不能接受的,并且因此产生的磁盘碎片也是对磁盘空间的极大浪费。

针对这种现状,LAXCUS设计了一套新的数据存储流程,来保障高效的数据处理。首先,在内存的自由区域开辟出一块固定长度的空间,此后的每一批数据,系统都以流式的串行追加方式写入。这样即使当时有多个写入者,因为内存处理效率颇高和串行写入的原因,在写入过程中几乎没有延迟或者很小,也不会产生写入冲突。当内存空间的数据量达到规定阀值的时候,系统将内存空间关闭,并且执行一系列的数据优化措施,包括压缩和重组这样的处理,最后将这片内存数据以文件形式一次性写入磁盘。这个进入磁盘的文件,被称为“数据块”。

LAXCUS将驻留在内存时的数据称为数据块的“CACHE”状态,写入磁盘后,被称为数据块的“CHUNK”状态。系统设置的内存数据区域的标准阀值是64M,这个参数也可以由用户定义,最大不能超过4G。对于超大尺寸的内存数据区域,系统将视磁盘文件系统和可用内存空间而定,如果不能支持,将自动调整到合适的尺寸。

为了能够区分内存和磁盘上的每一个数据块,系统会在每个数据块生成时,为它设置一个64位的无符号长整数,做为唯一标识它的编号。编号由TOP运行节点提供,保证集群中唯一,不会重复。数据写入磁盘后,这个编号也是数据块的文件名。

依据1.3.6节对DATA节点的定义,数据块只保存在DATA节点上,并且依从DATA节点的主从关系。所有主节点上保有的数据块都是主块(PRIME CHUNK),从节点保存从块(SLAVE CHUNK)。数据块的主从角色会根据所属DATA节点级别发生变化。一个集群上,同质数据块只允许拥有一个主块,其它都是从块。写数据的传入,由CALL节点负责实施,向相关的DATA主节点均匀推送,这样可以使这些DATA主节点,在各自拥有的数据量上保持一个相对均衡的状态。

系统不会在非DATA节点上缓存数据,这个设计是参考了大量实例后做的决定。经统计,单位时间内的网络计算,一个指令被重复执行的概率极低,这就连带影响到数据的重复命中率,使得在内存里缓存数据没有意义,并且缓存数据会占用大量宝贵的内存空间,显得得不偿失。

数据块的采用,很好地消除了磁盘碎片的现象,也减轻数据输入磁盘时的写处理压力。按照数据块标准的64M计算,数据写入磁盘的时间不会超过1秒。检索数据时,将按照优化规则从磁盘读取数据,这样也降低了数据输出过程的读处理压力。

2.2 存储模型

存储模型是数据在磁盘上的物理组织结构。在许多介绍数据库的书籍里,存储模型又被称为内模型。它在很大程度上决定了数据的可应用范围,是衡量数据存取性能的重要指标之一。

LAXCUS在数据块的基础上实现了行存储模型(NSM)和列存储模型(DSM)。因为两种存储模型的组织结构完全不同,以下将结合图2.1和数据运作流程,来阐述这两种存储模型的特点及优劣。

这是一个网络音乐文件表,由6个属性组成。图2.1左侧是行存储模型,每一行由不同属性的列值组成,数据是从左到右、从上到下的排列,形成行与行连接的布局。图2.1右侧是列存储模型,同属性的列值被组织在一起,成为列的集合,数据是从上向下、从左到右的排列,形成列集合与列集合连接的布局。

如2.1节所述,行/列存储模型都是建立在数据块的基础上。CACHE状态时,数据的读/写处理都在内存中进行,虽然两种存储模型的组织结构不尽相同,但是因为内存处理效率颇高,这个问题在速度面前就显示得微不足道。放到实际环境中检验,通过追踪两个存储模型的数据处理流程,发现它们的处理效率的确没有差别,所以两种存储模型虽然结构不同,但是在CACHE状态可以完全忽略。

差异主要体现在数据块的CHUNK状态。进行CHUNK状态后,数据处理将在磁盘上执行。行存储是以行为单位,若整行读取,那么行存储效率很高;如果读取多行,最好在数据写入前将被检索的数据排列在一起,这样只需要对磁盘做一次定位和读取。同样的,列存储是以列集合为单位,它适合对单列连续数据的读取,如果读取多列数据,就需要扫描不同的磁盘位置,这会降低磁盘检索效率。

数据块CHUNK状态的写处理,只会发生删除和更新操作。因为更新被分解为删除和追加,所以实质仍然是删除操作。删除操作不会将数据从磁盘中清除,只在数据的某个位置做一个无效标记。如果是批量删除,就需要分别做多个无效标记,这种操作对磁盘性能影响很大。

但是在实际应用时不是这样。根据磁盘(温彻斯特硬盘)工作特性,一个完整的读/写处理,分为磁头定位、等待、数据传输三个阶段。从目前磁盘性能的发展趋势来看,带宽速率的提升优于磁头定位,况且现在计算机的内存容量已经足够大,缓存一些数据也绰绰有余。根据这种情况,实际的读/写处理,是将需要的数据一次性调入内存,在内存中完成处理后再输出。这种处理方式,非常有助于提高磁盘处理效率。

在其它方面,列存储模型的数据是可以压缩的,压缩的直接优势就是能够节省磁盘和内存的空间。比如当某一列有10个999的整数时,就不必把10个999依次排列,而是在999前面加一个10,就表达了10个999的含义。行存储模型则没有这方面的能力。列存储模型的值还可以自动成为索引使用,省略了用户设置索引这一步骤,其优势除了节省磁盘和内存空间,还因为没有了关联操作,简化了存储层面上的计算。行存储模型如果使用索引,则需要用户说明具体的列,并且在行数据集合之外开辟一块索引数据空间,处理前进行关联才能生效。

综上所述,行/列存储模型在CACHE状态的处理性能持平。在CHUNK状态,行存储模型适合整行读取,列存储模型适合单列读取。CHUNK状态的写处理,因为数据在内存进行,它们处理性能仍然基本一致。

(点击图像放大)

图2.1 行存储模型和列存储模型

2.3 行级锁

从数据组织的逻辑角度来看,“行”是能够表述一个完整信息的最小单位。为了保证数据一致性,防止多方操作竞用可能引起的数据混乱,LAXCUS在“行”这个层级对数据执行锁定操作,这个设计理念与关系数据库完全一致。行级锁是一个互斥锁,在一个时间内只允许执行多读或者单写操作。因为它的粒度足够细,只对单个行进行操作,不会涉及到其它行,所以几乎对整个集群计算没有什么影响。目前行级锁在行/列两个存储模型上都已经得到技术实现。

2.4 元信息

为了快速定位和计算数据,元信息做为数据操作者和被操作对象之间的中间媒质,来配合完成这项工作。元信息的本质是实体资源的抽象描述,包括节点元信息和数据元信息,前者由网络地址、运行参数组成,后者将数据块的“列”格式化为4至16字节不等的数值,按顺序排列。

元信息的数据量都很小,在所在节点的运行过程中产生,随节点运行发生变化和更新。这些特点使它适合在内存中驻留,执行快速计算。产生元信息的节点会不定期的,向它的上级管理节点提交元信息,管理节点根据这些元信息按规则进行汇总和排列。需要元信息的节点,向它的上级管理节点申请和获取,存储在本地内存中,并将元信息重新筛选和排列,形成一种类似索引的数据结构,为后续的数据计算提供必要的判断和准备依据。

2.5 内存模式

数据块存储在磁盘上,受制于磁盘性能的限制,其读写效率相较于CPU和内存严重滞后,拖慢了整个计算过程。尤其在面对热点数据块读写,或者需要提取大量数据计算时,这个影响尤其明显。一个简单的办法是把数据块调入内存,使其以接近CPU的速度运行,可以有效减少磁盘对数据的影响。

系统提供了两个加载数据块的方案:1.当内存空间比较充裕时,由系统判断,把热点数据块调入内存。 2.由用户决定,通过终端或者应用接口发送指令,指定某些或者某台计算机上的数据块,把它们加载到内存里。加载数据的过程中,系统会判断计算机的实际内存容量,在接近限制前会停止,不会发生内存溢出的现象。

如果是系统加载的数据块,这个调用是临时的,热点数据块会持续受到监视,当低于调用阀值,或者内存有限,使用频率更高的数据块需要加入时,会把它从内存中移出。

用户也可以做反向操作,把数据块从内存中释放,同样是通过终端或者应用接口进行。

内存模式不影响数据的写操作,如果是添加、删除、更新情况,会同步修改在内存和磁盘的数据块。

内存模式更适合只读操作,这和大规模数据检索需求匹配。尤其在今天很多CPU都已经是64位,寻址范围突破4G限制的情况下,内存可以充当一个临时的数据仓库,是一个提升数据计算效率的好办法。

2.6 快照和备份

每一个CACHE状态的主数据块,在主节点上生成后,会通过网络定向通知其它几个关联节点,产生相同编号的CACHE数据块。此后这个主数据块,每一次写操作,都会通过网络向它们传递当前数据的复本。这些以复本形式存在的CACHE状态数据块,被称为“快照”。

每一个主数据块,从CACHE状态转入CHUNK状态后,主节点将立即启动,通过网络分发这个数据块的数据复本。这些被传播到不同节点的数据块,被称为“备份”。备份也就是2.1节所述的从块。

备份数据块传递完成后,主DATA节点会通知关联的DATA节点,将CACHE状态的“快照”删除。此后的运行过程中,如果发生写操作,CHUNK状态的主数据块仍会执行与快照一样的处理。

快照和备份的分配,将根据集群的网段原则进行选择。这是一个类似LINUX TRACEROUTE命令的处理过程,通过向不同DATA节点发送ICMP包,探测当前节点与目标节点的跳点数,判断网段之间的距离,按照由远及近的顺序进行分配。

系统规定同质数据块的默认存量是3,即有1个主块,2个属于快照或者备份的从块。主块允许执行读/写处理,从块只能执行读处理,和接受主块的原始数据覆写操作。这个参数也可以由用户定义,但在运行时将受到具体环境的限制,如果实际节点存量不足,将只能满足到最大可用数量要求。

快照和备份使同质数据块之间保持了原始级的数据一致性,同时还实现了分解读处理压力、负载平衡、冗灾恢复的目的。如果当某个数据块读操作压力过大时,这个DATA节点会向HOME节点提出请求,HOME节点会进行协调,将这个数据块分发到其它空闲DATA节点上,以降低请求节点的读取压力。或者某个DATA主节点发生运行故障,HOME节点能够快速感知,然后根据数据块编号,从相同的快照或者备份中选择一个,把它分发到某个正常的DATA主节点,升级为主数据块,来取代故障数据块。选择的依据是时间,在所有快照或者备份中,以文件修改日期最新的那个为准。

2.7 完整性检查

DATA节点启动时,会对磁盘上的每个数据块进行扫描,检索它的数据完整性。扫描将首先判断数据块的存储模型,再分别进行处理,具体到数据块的每一行或者列集合。如果扫描过程中发现错误,将进入暂停状态,通过网络申请一段正确的数据复本,来覆盖错误的数据。数据块的扫描在内存中进行,完成后释放。扫描采用CRC32校验和算法,这个计算过程非常快,在32位的PENTIUM4 2G计算机上,一个标准的64M数据块的执行时间不会超过1秒。通过完整性检查,可以即时判断数据块的每一段数据错误,保证后续正确的数据处理。

2.8 数据优化

数据块长时间运行后,由于删除和更新操作的增加,会对数据块的不同位置做很多无效标记。这些无效标记导致了数据碎片的产生,除了占据着磁盘空间,还严重影响到磁盘数据检索效率。为了消除这个影响,提高数据检索效率,有必要对数据块做优化处理。

系统提供了一个数据优化的命令,用户可以通过终端或者应用接口发起操作,或者定义在数据字典里,委托给TOP节点管理,定时启动。

数据优化只作用于DATA主节点的主数据块上。工作完成后,会通知关联的从节点,更新相同编号的数据块。在数据优化期间,全部数据块都被锁定,所以这个时候不能执行任何数据操作。但是优化过程完全在内存中进行,计算一个标准的64M数据块,更新时间大约在1秒左右,所以也能够较快完成任务。考虑到需要回避正常计算业务工作的时段,建议这项工作在系统的空闲时间进行,比如夜间的某个时刻,这些时间的用户请求量通常会显著减少。

2.9 数据构建

数据优化是在不修改数据结构的前提下,对DATA主节点下的数据块进行的更新工作,目的是清除垃圾数据和提高检索效率。数据构建在此基础上更进一步,依靠一种或者多种数据结构的数据块,提取它们全部或者部分数据信息,经过筛选、分析、计算,形成包括存储模型、数据结构、数据内容在内的新的数据集合,并且工作位置也转到BUILD节点上进行。

数据构建属于ETL服务的一部分。因为数据构建会涉及到不同的业务方案,无法进行统一处理,所以系统提供了一套API。API提供了规范的数据处理流程,其中具体的业务,由了解业务的工作人员按照实际需求编写计算机代码。编码完成后,发布到BUILD节点运行,BUILD节点会自动感知并且识别它们。

启动数据构建的工作由用户通过终端或者应用接口触发,或者交由TOP节点代为管理执行。BUILD节点在收到命令后,按照系统规定的工作流程处理。

数据构建是大规模数据计算中一项很重要的功能,在很多场合都有实际应用。例如许多数据计算业务都需要分别采集各种不同的数据,如果在运行时处理,过程会繁琐,耗时长,运算成本高。如果提前产生,一次性获得全部数据结果,然后在这个基础上再进行计算,程序员的开发工作和数据处理会变得简单,时间会缩短,运算成本也会降低。

2.10 主块冲突

首先,主数据块在任何时间只能有一个。当DATA主节点发生故障恢复后,会重新向HOME节点注册,同步上传的还有节点所属的数据信息。HOME节点会检查每一个数据元信息,与内存中驻留的数据元信息进行比较,这时可能会发生两个相同编号主数据块的情况,这就是主块冲突。

解决主块冲突的唯一办法仍然是时间。根据两个主数据块最后的文件修改时间,判断它们的数据有效性,以时间最新的那个主块为准。旧的主块将会从磁盘删除,从而达到防止主块冲突的目的。

2.11 负载检测

在系统运行过程中,一个现实的情况是:随时会因为需求增加有大批计算任务加入,同时也会有个别节点因为各种原因而退出运行过程。在这种波动的运行状态里,不可能完全杜绝超载现象,能做到的只是尽可能减少超载发生频率。

使计算机发生超载的源头主要有两个:CPU、磁盘。CPU超载原因是存在大量数据计算,磁盘超载是读写频率过高,减少超载现象的有效办法是限制计算任务量。通过LINUX的top命令能够观察到CPU和磁盘的运行情况。当超载现象持续时,系统将启动“锁”机制,限制计算任务运行,同时通知任务发起方,减少对本节点的调用频度。

对数据超载的检测会具体到每个数据块,如果系统发现某个数据块的调用在一定时段内超过阀值,会选择临时加载到内存或者分发到其它空闲的计算机上执行,以达到降载的目的。


感谢梁堰波对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT