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

前言

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 ）关注我们，并与我们的编辑和其他读者朋友交流。