前言

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和磁盘的运行情况。当超载现象持续时，系统将启动“锁”机制，限制计算任务运行，同时通知任务发起方，减少对本节点的调用频度。

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