> 原文出处：http://www.infoq.com/cn/articles/laxcus-introduction-part2 > 作者：梁祖邦 本文是系列文章的第二部分，阅读前两部分见这里《[大数据管理系统LAXCUS(一)：基础与数据](http://www.infoq.com/cn/articles/laxcus-introduction-part1)》 [TOC=2,3] ## 网络通信 LAXCUS集群网络建立在TCP/IP协议网络之上，支持IPv4和IPv6网络地址。为了适应不同的网络通信需求和节约网络通信资源，LAXCUS采用了专属的网络通信协议，和在此协议上建立的多套网络通信方案，它们共同组成了LAXCUS网络通信运行的基础。本章将阐述与网络通信有关的各个组成部分。 ### 3.1 FIXP协议 LAXCUS使用FIXP协议进行网络通信，FIXP是一套全新的二进制格式的应用层通信协议，名字全称是自由消息交换协议(Free Information eXchange Protocol)。二进制数据采用小头码位序(Little Endian)。FIXP协议具有平台独立、上下文无关、结构简单、数据尺寸小等特点。 #### 3.1.1 协议结构 如图3.1所示，协议结构布局按排列顺序由三部分组成：命令、消息、数据实体。命令分为两种：请求和应答，命令的作用是说明本次通信的基本属性。每次通信由发起方发送请求命令，受理方返回应答命令。消息在命令之后出现，消息在一次通信协议中允许出现任意多个，消息中携带本次通信需要的多类附属信息。消息之间是衔接的，彼此无分隔标记，通过消息头中的标记长度加以区别。在最后是数据实体部分，数据实体包含本次通信需要的主要内容，如音频、档案资料等。数据实体是一个可选部分，是否存在会在消息中注明。比如通信发起方通常是不需要传递数据实体的。  图3.1 FIXP协议结构 #### 3.1.2 命令结构 如图3.2，命令是一个56位(7字节)的数字序列。第一个8位的标识的作用是区分当前是请求命令或者应答命令。之后的协议版本号占用16位，协议版本号是可变的，不同的协议版本号代表不同的协议格式，在应用中分别有不同的解释。目前协议的最新版本号是256(0x100)。 命令的主要区别在第24至40位，请求命令需要提供两个8位的主命令和从命令，说明本次操作的作用目标，应答命令返回一个16位的应答码，确认本次请求是接受、还是因为其它原因拒绝。最后是16位的消息成员数，理论上，一次FIXP通信最多可以携带65535个消息。  图3.2 命令(请求/应答)结构 #### 3.1.3 消息结构 如图3.3，消息是一个不定长的数据结构，由键、类型、参数长度、参数组成。键占用16位，每个键都有一个固定的定义，键理论上有65536个，目前已经使用了大约100个。类型占用4位，说明后续的参数属性，包括布尔、短整数、整型、长整型，单浮点、双浮点、二进制数组、字符串、压缩二进制数组、压缩字符串。参数长度是一个12位的值，参数的实际尺寸由参数长度说明。需要特别指出的是，数值型参数具有字长压缩能力，例如一个整型数0x20，按照计算机字长标准需要占用4个字节，但是实际尺寸只有1个字节。这时参数长度会说明为1，忽略前面3个0。如本章开篇所述，数值型参数遵循Little Endian格式。  图3.3 消息结构 ### 3.2 通信方案 LAXCUS在FIXP协议基础上提供了四种通信方案。这些通信方案将根据所属环境和任务的不同需求，实现有区别的通信，达到节约网络流量，降低运行负载，提高计算效率的目的。 #### 3.2.1 TCP通信 TCP通信建立在TCP/IP网络的TCP模式基础上，主要针对持序的、大流量的数据传输。比如数据块的分发。在有上千台计算机运行的集群环境中，这种流量规模的数据通信会占用大量的网络带宽，造成网络阻塞，严重影响集群其它通信业务的正常进行，更严重的甚至会造成网络的瘫痪。所以，大流量的数据传输是受到限制的，已经规定必须在HOME节点监管下进行。 #### 3.2.2 UDP通信 UDP通信建立在TCP/IP网络的UDP模式基础上，主要针对于非持序、可靠性要求不高的小流量数据传输。在系统的网络通信中，基于UDP传输的FIXP协议包，数据尺寸普遍介于20至300字节之间，小于一个IP包的最大传输单元(MTU)，并且以网络监控包为主，测试节点是否正常运行的心跳包是最常用一种。UDP通信是LAXCUS使用频率最高的通信方案。 #### 3.2.3 KEEP UDP通信 UDP的优点在于对计算机的资源占用率低，缺点是数据通信不稳定，存在丢包现象。TCP恰恰相反，可以提供稳定的数据通信，但是对TCP/IP堆栈的资源占用率高。在系统的网络通信过程中，存在大量需要保持稳定通信，但是又希望采用UDP的通信业务。如何拥有二者的优点而且避免其缺点，答案就是“KEEP UDP（可持续的包通信）”。KEEP UDP是TCP和UDP之间的一种过渡方案，通过在UDP基础上模拟TCP通信过程，为UDP数据提供稳定的通信保证。这个方案的实质就是将原来在TCP/IP堆栈上进行的包的分组和重组的工作，转移到LAXCUS控制的工作线程上去执行。在减轻TCP/IP堆栈压力的同时，还能够根据当时需求，自由定义一些对包的特殊规则。目前KEEP UDP主要是发送网络日志和RPC处理，这些都是数据流量不大但是需要可靠传输的业务。 #### 3.2.4 RPC通信 RPC(远程进程调用)的出现由来以久，是一种非常优秀的网络通信方案，至今仍在被广泛使用。它通过隐藏网络两端通信的方式，使网络上两台计算机之间进行的网络调用类似本地API调用的过程。这样就极大地简化了程序员对网络编程的难度，提高了工作效率，减少了出错的机会。 LAXCUS包含了对RPC的实现，它的通信建立在TCP和KEEP UDP通信基础之上，通过在本地嵌入接口和对程序员屏蔽网络流程，实现RPC调用处理。目前节点间许多复杂的、安全度高的网络通信都被要求采用 RPC方案执行。 ### 3.3 通信检测 集群运行过程中，发生的很多故障都与网络和网络设备有关。根据统计，这些故障大致包括：线路损坏、插口松动、电磁影响、网络阻塞、网络设备损坏。其中有些是硬件故障，有些是暂时性的网络故障。判断故障的有效手段是通过发送ICMP包来检测网络可达。这项测试可以由单机处理，必要时需要多个节点对一个地址共同测试，然后汇总测试结果得出答案。系统将判断故障是暂时性的网络问题或是不可恢复的物理故障。如果问题严重，将报告给系统管理员，通过人工处理来解决故障问题。通信检测在所有节点都会执行，是体现集群弱中心化和自维持能力的必要手段。 ### 3.4 通信服务器 如1.3节所述，通信服务器是节点管理下的一个工作线程，采用FIXP协议通信。通信服务器在启动时分别绑定TCP/UDP两个模式的监听套接字(SOCKET)，套接字参数在配置文件中定义。根据系统的规定，工作节点的套接字地址在启动时由系统随机选择，管理节点的套接字必须有固定的IP地址和端口。因为只有管理节点的地址固定，工作节点才能够在网络上找到管理节点。通信服务器不主动发起通信工作，只接收外部发来的命令。在收到命令后，分派给下属的任务线程完成具体的任务处理。通信服务器还承担网络通信安全的职能，确保通信过程中，网络两端传输的数据是正确和可信任的。通信服务器的安全管理是一个可选项，是否使用由用户决定，在配置文件中设置。 ### 3.5 全局时间 在网络通信过程中，为了能够辨别各节点之间数据处理的先后顺序，需要一个参数来标识它们当时所处的位置。这个参数被称为全局时间，也称为主时钟或者时间轴。全局时间以集群中唯一的TOP运行节点的操作系统时间为标准，其它所有节点必须遵从这个时间定义，与TOP运行节点保持一致。全局时间在节点启动时向所属上级管理节点申请和获取，在本地操作系统上设置，误差要求不超过1秒。全局时间目前已经使用在网络日志、网络计算，以及主块冲突、数据冗灾处理中。 ## 网络计算 网络计算是在网络通信基础上实施的数据计算工作，相较于集中计算，网络计算更适合处理那些复杂的、数据量大、耗时长的计算任务。进行网络计算的前提是数据可以被分片。分片的办法有很多种，最常用的是按照数据范围和散列分片。需要强调的是，分片后的数据区域之间不应该存在数据重叠的现象。 LAXCUS网络计算模型的设计基于网络节点物理分散逻辑统一这个现状，其宗旨将系统职能和用户职能分开。系统负责网络通信、计算任务的分配和调度、故障管理等工作，为用户的计算业务提供一个稳定的运行环境。用户的职能由程序员通过网络计算可编程接口实现派生编程，把各种业务规则转化为计算机可执行的程序代码，然后发布放到集群上运行，与系统功能结合，共同完成网络计算工作。 另外声明：很多资料介绍中，网络计算又被称为分布计算。为减少歧意，在这里统一称为网络计算。 ### 4.1 DIFFUSE/CONVERGE算法 对于传统的集中计算的工作模式，其数据处理过程可以理解为：产生/计算，扩大到网络环境，可以进一步解释为：分散/汇合。这也是算法名称的由来。LAXCUS网络计算模型即源于这一思路。 以下结合集群网络和图4.1，阐述DIFFUSE/CONVERGE算法的处理流程。 如图所示，DIFFUSE是网络计算的开始，同时会有多个DIFFUSE请求分别作用到不同的节点上，根据内部携带的命令产生供后续的CONVERGE计算用的原始数据。在实际应用中，这些命令可以是SQL语句，或者是用户自定义和自解释的数据和参数。 CONVERGE是第二步，它分别从多个DIFFUSE结果中提取需要的数据，然后执行计算。当计算完成时，如果还有继续计算的需要，就将本次计算结果交给下个CONVERGE处理；如果没有，向任务请求方返回计算结果。这个计算结果也是DIFFUSE/CONVERGE计算的最终答案。 可以看到，DIFFUSE只执行一次，CONVERGE会执行多次迭代计算。这正是本节需要说明的：DIFFUSE/CONVERGE算法的本质是步骤间串行、步骤内并行的工作方式。当前步骤结束后进入下一个步骤，当前步骤内同时有一批线程对上次的数据进行再计算，线程之间无联系。计算过程中，每一个步骤执行同一程序的副本，当前步骤的数据输出是下次步骤的数据输入，直到最后输出结果数据，完成计算任务。 在DIFFUSE/CONVERGE计算中，出现最多的数据处理是：排序、分解、重组、筛选。 按习惯，LAXCUS把实现DIFFUSE/CONVERGE算法的中间件程序称为“任务”。任务编写完成后需要发布到节点上以供调用。  图4.1 DIFFUSE/CONVERGE 处理流程 ### 4.2 任务命名 任务发布后，需要向集群传播一个标识说明它的存在。这个标识被称为任务命名。任务命名是一个任意长度的字符串描述，由ASCII码集中的英文字符、数字、下划线的组成，英文字符不区分大小写。系统要求每个任务命名在集群中都是唯一的，这样才能够保证区别不同的发布任务。节点把任务发布成功后，会向HOME节点注册任务命名。通过任务命名，关联节点可以快速检索到成功发布的任务，保证后续启动和调用的需要。 生成任务命名的权限没有具体规定，但是重名会导致调用和计算过程的混乱，所以命名最好由系统管理员或者拥有系统管理员权限的用户分配。因为他们拥有管理整个集群的权限，通过检查全网的任务命名，防止出现重名现象。 ### 任务实现 系统为DIFFUSE/CONVERGE算法任务提供了一套编程接口，这个编程工作由程序员来完成。一个完整的任务由五个阶段组成，每个阶段的工作内容和范围，系统都由做了明确的设定。程序员编码完成后，需要打包发布到相应的节点上。CALL节点处于任务协调中心的位置，负责任务各阶段的管理和分配工作。 #### 4.3.1 INIT阶段 这个阶段是对网络计算任务进行初始化处理，设置后续阶段运行需要的配置数据。配置数据根据用户输入的自定义参数，和结合系统当前可提供的资源产生。INIT阶段任务指定发布到CALL节点。 #### 4.3.2 FROM阶段 这个阶段对应DIFFUSE算法，产生网络计算任务最初的原始数据。数据的来源目前有两种：使用SQL SELECT语句产生，或者自定义的数据和规则产生。数据产生后会被保存到磁盘上，同时生成数据位图信息返回给CALL节点。数据位图是对数据计算结果的抽象化描述，系统提供了一个基础框架，由系统或者用户生成。FROM阶段任务指定发布到DATA节点。 #### 4.3.3 TO阶段 这个阶段对应CONVERGE算法。如4.1节所述，CONVERGE是迭代化的处理过程。为匹配任务迭代，TO阶段在其之下，定义了一个子阶段：NEXTO，以加以区别。NEXTO理论上可以无限迭代。TO和NEXTO阶段的数据源自上个阶段的计算结果。本次计算结果，如果当前处理不是迭代过程的最后一次，数据就在本地保存，向CALL节点返回的是数据位图信息，否则向CALL节点返回这次计算结果。TO阶段任务指定发布到WORK节点。 #### 4.3.4 BALANCE阶段 这个阶段存在于FROM和TO/NEXTO阶段之后。它的工作是根据数据位图信息，为后面的TO/NEXTO任务平均分配当前散布在各节点上的数据资源，希望每一个TO/NEXTO任务以基本相同的时间完成数据计算，达到节省总计算时间、提高计算效率的目的。当前的数据位图信息，如果是由用户生成，那么解释工作也由用户完成，否则由系统默认的接口执行。BALANCE阶段任务指定发布到CALL节点。 #### 4.3.5 COLLECT阶段 这个阶段承接最后一次的TO/NEXTO任务，是对实际计算结果进行的最后处理。最后处理包括：对来自可能不同CALL节点的计算结果的整合，某些个性化处理，以及数据输出。数据的输出地址，系统提供了磁盘和计算机屏幕做为输出目标。COLLECT阶段任务的发布位置由用户选择，可以是CALL节点或者终端。 ### 4.4 计算过程中的数据平均分配问题 判断网络计算效率的重要指标之一是计算的运行时间。计算时间的长短，取决于所有线程中最慢的那个线程的计算时间。所以，为了实现高效的数据计算，需要保证每个线程的计算时间基本一致。而每个线程的计算时间能否保持一致，忽略掉计算机性能这个指标不谈，分散到每个线程上计算的数据量是否平均，基本上能够决定每个线程的计算时间能否保持一致。 LAXCUS采用“模”为平均数据提供指导依据。 按照LAXCUS的定义，模是数据分布数量的参考标准，是一个64位无符号整数，具有两种含义：1.相同的模，它代表的数据范围是一致的；2.在以升序排序后的模数组里，相邻的模，它们所代表的数据范围是衔接的。 在4.3节所提的数据位图信息，它的实质就是数据映射模为后，散列化的元信息集合，同时还包括节点地址、数据的磁盘地址等。 BALANCE的位图计算，是在收集了来自各个TO/NEXTO任务的数据位图信息后，按照模值进行的重新分配，尽可能的为后面的每个TO/NEXTO任务分配相同量的数据。这样，在不考虑计算机性能的情况下，理论上，每个节点的数据计算时间能够大体保持一致。 模概念的引入，解决了网络计算过程中各个线程处理时间不一致的问题，有助于提高计算效率。 ## 安全管理 安全对于当前计算机网络的重要性，已是一个不可回避的话题。数据处理过程中的任何一点疏漏都可能造成无法挽回的损失，所以提供一个全面的安全管理方案成为必然选择。基于对这种现状的考量，LAXCUS在数据处理的每一个环节都实施了安全管理。安全管理主要围绕着两个方面进行：防窃取和防篡改。同时，出于对计算机性能、计算效率、运行压力的考虑，而安全管理通常又是非常消耗计算资源和时间的计算，所以，某些环节的安全管理设为可选项，决定权交由用户选择。比如内网通信过程中的安全，由于内网的安全保障程度比较高，而且内网的数据传输量非常大，网络计算工作几乎都在内网中进行。这种情况下，为了给网络计算腾出基础资源，提高数据计算效率，可以酌情选择不采用。 本意将阐述在哪些环节实施安全措施，以及实施的办法。 ### 5.1 通信安全 在一次网络通信开始时，为了确保任务请求方是可以信任的，任务受理方会要求对方出示通信安全凭证。这个凭证将保证双方在安全的状态下通信。 通信安全凭证需要在FIXP服务器上配置，里面存储着请求方必须出示的信息。安全通信类型分为三种：地址验证、账号验证、地址/账号复合验证。当受理方要求出示安全凭证时，请求方必须遵守这个协定，向受理方出示自己的安全凭证，否则通信将被受理方中止。请求方也可以主动向受理方要求安全校验，受理方都是会接受的。 在通过安全凭证检测后，可以确定网络两端间传输的数据是正确和可信任的，这样就为后续的数据处理提供了一个基本的安全保障。 但是使用中也有例外，比如本节上面提及的内网通信。因为内网相对公共网络安全度颇高，而通信安全项除了地址验证外，其他两种都需要进行大量计算，这会造成任务处理的延迟，对大规模、高密度的网络计算来说显得得不偿失。所以，一般的建议是，在穿越VPN或者互联网的通信双方，应该启用安全通信；在信任度高的内网，这项工作可以忽略。 ### 5.2 账号安全 用户无论是以终端或者应用接口接入LAXCUS集群，系统都要求使用者提供一个登录账号。按照LAXCUS规定，账号由用户名称和密码组成，系统管理员拥有管理整个集群的权力，每一个账号必须经由系统管理员建立。用户账号由系统管理员在终端输入，账号的用户名称和密码的明文不会出现在网络的任何位置，而是首先在本地散列为SHA1码，再通过网络上传，保存到TOP节点的数据字典里，供以后查证和调用。这样就保证了账号产生过程中的安全。 账号持有人拥有修改账号密码的权利，当系统管理员建立该账号后，可以修改由系统管理员设置的密码。这样做的目的是，除了账号持有人外，任何人包括系统管理员，都不能再通过该账号，操作其属下的数据资源，从而保证了账号持有人和账号属下的数据资源的绝对安全。 账号中还包括了账号持有人的命令操作许可，这些许可也是系统管理员赋予的。操作许通过SQL命令设置。系统管理员的权限可以延伸和再分配，被赋予了系统管理员权限的用户也可以拥有与系统管理员平等的权力。 ### 5.3 登录安全 用户登录进入LAXCUS集群，除了需要提供登录账号外，还必须持有一个系统管理员颁发的安全许可证书。这是一个经过RSA算法签名的文件，由系统管理员建立和保管。用户登录时首先出示这个证书，TOP节点检查证书的有效性，确定证书有效和登录者可信后，再执行账号检查。与5.2节所述一样，网络上传的账号是散列后的SHA1码，此时又经过了证书加密，TOP节点会与本地保存的账号记录逐一比对，判断账号的有效性和操作范围，决定是接受还是拒绝。 登录成功后，双方进入正式的通信状态，此时的数据同样被要求经过加密或者签名处理。目前可供选择的加密和签名算法有:AES、DES、3DES、MD5、SHA1等。这些算法保证通信双方每一次交换的数据都是安全和可以依赖的。 ### 5.4 数据块安全 数据块的安全依赖于对数据的签名。当数据块从CACHE状态转向CHUNK状态过程中，系统会计算这个数据块的数据内容，生成一个16字节数组序列，做为校验码保存到数据块里。数据块的签名过程很快，一个64M的数据块签名生成时间，在PENTIUM4 2.0G的计算机上，通常在10毫秒以下。 当DATA节点重新启动，或者数据块被加载到内存，或者通过网络传输到另一个DATA节点，系统会重新根据数据内容再次生成一个校验码，与已经存在的校验码进行比较，确认数据的完整性，从而保证后续数据处理的数据本身是正确的。 ### 5.5 行和列集安全 数据块在从CACHE状态转入CHUNK状态过程中，除了生成针对数据块的签名，还会根据数据块的存储模型，针对每一行或者每一列集合，生成它们的CRC32校验码，并且保存在它们记录的开始位置。 设置行/列集校验码的原因是，因为整块的数据不会被经常调用，而行/列集的数据却总是在网络上大量、频繁传递，这就使得行/列集的数据校验更有实际意义。 然而相较于少量的数据块签名计算，被传输的行/列集因为粒度细、数据量大、校验次数频繁，计算持续时间也会更长，这将消耗大量计算资源，影响到网络计算的处理效率。所以，通常任务请求方在收到计算结果后，会根据数据的来源来选择是否检测。如果是内网数据，由于网络安全度高，这个校验可以被忽略。 ### 5.6 数组列安全 LAXCUS中的数组列，包括二进制的字节数组和字符串数组，这些列中的内容，偶尔会保存一些很关键的信息，比如密码、电话、家庭地址等私密信息。这些信息，通常是不希望被别人知道的，包括系统管理员和运行的集群本身。还有一些内容，比如像网页或者文档这样的文本数据，可能会很长，如果用明文的方式保存会占用较多的存储空间，将其压缩后再保存可以有效减少空间占用，而且文本数据的压缩比率都是很高的。 LAXCUS提供了这样一个选项，可以对这类信息进行压缩和加密。数据的压缩和解压、加密和解密的控制权由用户掌握，在终端或者应用接口上完成。系统在其中只是被动接受和传递，不做任何处理。具体使用，见6.3.4节介绍。

> 原文出处：http://www.infoq.com/cn/articles/laxcus-introduction-part1 > 作者：梁祖邦 ## 前言 LAXCUS是一套数据管理软件，应用于大规模数据存储和计算环境。这是一个独立和完整的产品，融合了包括数据存储、网络通信、网络计算、数据安全、网络安全、任务调度、容错处理、自动化管理、人机交互接口、应用开发等多方面的技术。LAXCUS采用JAVA语言编写，支持行/列两种数据存储，通过终端或者应用接口嵌入方式接入，执行SQL和类SQL操作。产品布署使用快捷简单，遵循LGPL协议，开放源代码，运行在LINUX平台。 [TOC=3,3] ### 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系统根用户下的一个进程，没有操作界面，在后台运行，启动时运行一个网络通信服务器保持与外界对话。 (点击图像放大) [](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2015-09-17_55fa66ed7d5f3.jpg) 图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状态的写处理，因为数据在内存进行，它们处理性能仍然基本一致。 (点击图像放大) [](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2015-09-17_55fa66f609541.png) 图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和磁盘的运行情况。当超载现象持续时，系统将启动“锁”机制，限制计算任务运行，同时通知任务发起方，减少对本节点的调用频度。 对数据超载的检测会具体到每个数据块，如果系统发现某个数据块的调用在一定时段内超过阀值，会选择临时加载到内存或者分发到其它空闲的计算机上执行，以达到降载的目的。