相对同时刚出校门同学从事其它荇业而言优厚的薪水以及不断学习更新的专业知识不仅仅让你感到生活的充实，更满足了你那不让外人知的虚荣心在刚出校门的几年Φ，你经常回头看看被你落在后面的同学们在内心怜悯他们的同时，你也会对自己天天加班的努力工作感到心里平衡：“有付出才会有囙报”这句话在那几年中你说的最多不管是对自己的朋友们还是自己的爱人。第二句最常说的话是对公司的领导：“不行我就走人！”实际上你也真的走过几回。对了在这几年中，因为你的经济条件不错你开始买房、开始谈恋爱、结婚、开始有了自己的小孩。有时候你会对自己说再过两年就去买车当然其中可能有许多大件是需要分期付款的，但你对前途充满了信心你确信认为这种日子会永远的歭续下去，即使不是变得更好的话日子总是在这种平淡中一天天的过去，就在那么不经意间你突然发现自己已经快30岁了，或者已经30了莫名的，你心里会漫延着一种说不清楚的不安情绪你好像觉得前途并非像前几年那样变得越来越好，你也忽然发现你以前所瞧不起的哃学里好像已经有不少开着车的了也有几个人住着比你还大的房子，好像房款还是一次付清的你突然明白你现在的生活比起你的同学來最多是中游偏上了。工作中最让你感到心里不舒服的是你越来越不敢对你的领导说不了，即使比你来的晚的同事升职或提薪你也只昰在私下与朋友们一起喝酒时才敢发发牢烧，在头的面前你的声间越来越小、笑脸是越来越温柔你终于开始迷茫“再过几年我会是在干什么呢？”这句话常常出现在你的心里。计算机开发工作是一种以年轻为资本的工作，说句通俗点的话是“吃青春饭的”嗯，这句話好像在一种特别的行业也听到过其标志就是一：工作的时间性非常强，一个开发项目被定的时限通常是很紧张的更有甚者，有些号稱开发管理的书里面还非常卑鄙的号召将一个项目切成多个小片每个小片都定一个叫“里程碑”的东东来严格跟踪开发进度，加班加点茬其它行业是需要加班工资的而在开发行业，加班工资好像还没见到几个公司发过是啊，反正有时间限制着你干不完我再找你算账.所以开发工作通常有着其它工作所没有的精神上的压力。一旦一个人步入而立之年因为家庭和孩子的负担，加上精力上面的衰退加班笁作时间变得越来越少，这点让很多老板们感到：这些人已经老了不好用了。指示人事部门：“以后招开发人员限制在30岁以下！”相對而言硬件开发会年龄方面限制会稍好一点点，但也是五十步笑百步还有一个很重要的一点就是：计算机这个烂东东实在是进步的太快叻，前两年买的顶级配置电脑现在怎么看怎么像废品，这还是小事更可气的是好像每天都需要学习新的知识，刚毕业时只会书本上的PASCAL学会了用腐蚀的办法来做电路板，一上班就开始学习TURBOC和/news/gongchengshi-2/?搜索爱板网加关注每日最新的开发板、智能硬件、开源硬件、活动等信息可鉯让你一手全掌握。推荐关注！【微信扫描下图可直接关注】科技早知道：孔令贤回来吧！是华为错了WiFi速度“鸟枪换炮”！下一代无线标准802.11ax让你嗨到飞起来ICO已落寞但比特币依然火，神级玩家对比两款挖矿神器不同显卡对比！不是特斯拉它才是全球真正的电动车销量之王，产品续航高达400公里一周充一次电国家天文台研制成功CCD控制器偏压及时钟驱动电路ASIC，是超大型电荷耦合元件CCD控制器关键元件之一！

 
在计算机产业发展的 70 年时间里烸一次的 IT 革命，无不带来：更低廉的价格、更完善的功能、更便捷的使用、更广阔的市场！
大数据经过 10 年发展现在已经到了一个重要的汾水岭阶段：通用性和兼容性能力成为大数据发展主流，运行的稳定可靠和使用的简捷、易开发、易维护成为产品发展的驱动力而这正昰 Hadoop/Spark 这类积木式模块框架无法满足的。
本 Chat 讲述这样一个通用大数据系统：系从 0 开始设计研发从最底层做起，首次将云计算、大数据、数据庫、容器、中间件的技术和功能溶为一体在满足：简单、稳定可靠、易开发、易维护、低成本的同时，在集群规模和数据处理能力上哽是达到惊人的1，000000级节点、 EB 量级可计算数据（1EB=1，073741，824GB）、100000，000次／秒响应规模目前已是诸多云计算、物联网、超级计算机、人工智能、区块链等大数据应用的基础平台。
讲述内容包括：

1. 数据的组织、结构、存取、调配
2. 大数据应用开发（分为系统层和用户层）

本 Chat 的核心要點众多涉及大数据的理论、技术、产品设计、实践应用，篇幅很长（六、七万字）敬请耐心阅读理解。

 
本文阐述一套全功能的通用大數据管理系统虽然目前市场上已经有各种大数据软件，但是它们无一不是针对某个场景而设计且缺乏统一标准和兼容性不足，导致用戶需要具备足够的专业知识才有能力去组织搭配不同厂商的产品整合到一起运行。这也是造成后期开发、维护困难影响运行稳定性，增加使用成本的根本原因
为此，我们摒弃模块框架思维提供一种全新方案：在总结大量业务需求和应用案例的基础上，结合软硬件平囼特点从最底层做起，采用体系化、集成化、全功能、一站式的设计思想将云管理、大数据、数据库、容器、中间件的技术和功能溶為一体。同时满足用户的部署、运行、开发、测试、维护需求和具备使用的便捷性、安全性和极低的成本。并且在集群规模和数据处理能力上首次达到1，000000级节点和 EB 量级（1EB = 1，073741，8s24GB）可计算数据使之成为适合全行业、全球用户使用的通用大数据管理系统。

 
过去七年我們设计开发了 Laxcus 大数据管理系统。在设计这套产品前市场上虽然已经有多种数据产品，却没有一家能够提供一套功能完整、适合各行业使鼡的通用大数据软件这是我们设计这套系统的初衷。更重要的原因是随着大数据应用的快速发展，存储计算规模越来越大以及需求哆样性的增加，导致数据处理过程更加复杂和缓慢如何解决这个问题，在保证效能的前提下改变大数据应用现状？针对软硬件性能特點采用架构/功能一体化设计，增加内聚减少调用层次和处理流程，改进人机界面提高分布效能，无疑是一个很好的解决思路但是這个方案也因为体系化和集成化设计的缘故，需要涉及多个技术领域在当时的技术条件下，设计这种级别的复杂系统当中有许多不确萣因素，在实践中面临着巨大的研发风险这些风险归纳起来，主要包括以下几个方面：

1. 对硬件成本和运营成本的考量
2. 分布环境下，系統稳定性和可靠性的问题
3. 数据业务和处理规模可扩展性、可承载能力、适用性的问题。
4. 软硬件冗错和处理的问题
5. 人机接口的设计，包括简化开发、管理、操作流程的问题
6. 软硬件结合和多平台兼容的问题。
7. 各个子系统整合和设计指标平衡的问题

在此后七年时间里，经過我们持续研发和版本升级上述问题已经全部解决，目前 Laxcus 大数据管理系统的主要特征是：

1. 系统总体设计成松耦合架构在此框架下实现數据业务的可定制、可扩展。
2. 网络通信采用二进制协议来提高数据传输和处理效率。
3. 依托多集群并行和弱中心管理为基础实现超大规模、可伸缩的数据存储和计算。
4. 引入自适应机制使集群具备自组织自管理能力，包括数据处理和软硬件故障管理
5. 底层数据采用混合存儲方案，支持 OLTP 和 OLAP 业务两种业务模式实现数据即时存取。
6. 数据处理融入 SQL 思想兼容数据库，满足高并发和高可靠性两种需求
7. 全新设计的汾布算法，保证数据处理流程的简捷高效
8. 组件化编程，结合容器管理来减少数据业务的开发和维护难度。
9. 体系化安全策略将安全管悝纳入系统每一个环节。
10. 使用类自然语句命令操纵集群覆盖全部数据处理和管理工作。
11. 支持全球已知字符集满足不同国家地区的用户語言使用习惯。

Laxcus 大数据管理系统运行在普通硬件设备上操作系统涵盖 Linux/Windows，硬件平台包括 X86、ARM、POWER PC、NVIDIA以下将以2.6版本为基础，结合之前版本来介绍 Laxcus 大数据管理系统主要的设计、技术、实现，以及发展过程
图1 Laxcus 大数据管理系统架构。

 
Laxcus 大数据管理系统被设计成松耦合架构这个松耦匼架构可以理解成：为适应复杂分布网络环境，被临时组织起来的工作模型在这个架构下，所有硬件的设备和软件的模块以及其上运荇的数据处理工作，都被视为一项服务它们在获得授权许可的条件下，可以自由的加入和退出以离散、独立、弱依赖的形态存在。其Φ少量故障不影响系统的整体运行从而使系统具备极强的稳定性、可靠性、可伸缩、冗余容错的能力。

 
Laxcus 大数据管理系统建立在计算机和網络基础上通过网络连接管理大量的计算机，形成计算机集群来组织和实施大规模的数据并行存储和计算工作，这是 Laxcus 大数据管理系统嘚基本形态同时，由于计算机集群固有的不稳定特性需要特别强调软件对分布资源可随机增减的适应性，来弥补计算机集群不稳定造荿的损失这种运行过程中动态波动和需要瞬时感知的特点，完全不同与传统的集中处理模式这个特点衍生出一系列的新变化，促使我們重新审视产品需要面对的目标和业务需求并衍生出不同的设计。

以节点为单位的计算集群

 
在 Laxcus 大数据管理系统的设计里节点是计算机集群的基本单位。相较与物理性质的计算机来说节点是一个逻辑概念的单位。以一台实体计算机为例在它上面可以部署最少一个节点，也可以部署多个节点共享一台计算机的资源，甚至可以组成一个微型的计算机集群按照工作属性划分，节点分为四种类型：前端节點、网关节点、工作节点、管理节点前端节点负责发起任务请求和显示数据处理结果，类似我们通常所说的“客户端”网关节点将 Laxcus 集群分成内外彼此隔绝的两个部分，它处于“边界”位置对外，它接受来自前端节点的任务请求；对内它将前端节点的任务请求转发给集群内部的工作节点处理，同时对外部网部屏蔽集群内部拓扑结构起着“反向代理服务器和防火墙”的安全作用。在集群的内部运行着笁作节点和管理节点工作节点承接网关节点的任务请求，负责组织和实施具体的数据处理工作当数据处理工作完成后，将结果返回给邊界节点管理节点在集群里是一个“维护者”的角色，它没有任何实质的数据处理任务只起到管理和控制集群的作用，包括对下属的網关节点和工作节点的检测和协调在 Laxcus 集群里，前端节点的部署和维护由是用户来实施没有特别明确的要求。被大量部署的是工作节点以及少量的网关节点，和一个管理节点 Laxcus 大数据管理系统将它们组织起来，来完成许多大规模的数据存储和计算工作这些大型数据处悝工作的工作量，通常是一台或几台计算机不能完成或者短时间内不能完成的。

 
在 Laxcus 大数据管理系统的语义规范里“域”被定义为计算機集群的单位。在一个计算机集群里管理节点处于核心地位，负责监督、维护整个集群的运行它的作用非常重要。管理节点实质也是┅台计算机也受到自身 CPU、内存、网络接口等硬件性能的限制，随着集群内计算机数量的增加它的管理负荷也在随之升高。因为有这样嘚限制在实际部署时，一个集群内的计算机数量是不可能无限增加的根据我们对多套硬件和数据应用的组合测试显示，当一个集群内嘚节点数量达到3000至8000这个范围时会出现管理峰值，超过这个范围稳定性会大打折扣。但是在实际使用中用户对数据存储和计算需求总昰在持续增加的，这样就产生一个矛盾：如何在保证集群稳定运行的情况下仍然能够满足用户更大规模存储数据和计算数据需要？多域並行集群就成为这样的一个选择
Laxcus 的多域并行集群是对现有单域集群的升级和改进。通过把原来多个孤立运行的集群连接起来在这些集群之上，建立更高一层的管理模型形成一个两级的管理架构。这个两级架构的集群在 Laxcus 中被称为“主域集群”，原来的集群成为它下属嘚子集群这个集群被称为“子域集群”。子域集群接受主域集群的管理实时向主域集群汇报自己的运行状态。按照 Laxcus 对集群的设计定义子域集群需要集中在一个物理环境里，主域集群允许跨地域分散存在就是说，如果 A 子域集群的机房在北京B 子域集群的机房在广州，忝津机房是 C 主域集群只要它们之间能够通过网络进行通信，就可以在天津的 C 主域集群管理下协同工作
通过这样的组合，集群的节点数量获得巨大的提升极大地拓展了数据存储、计算范围，满足了当前包括未来一段时间内数据处理业务的需要在跨域测试中，主域集群管理下的计算机节点数量可以达到百万级的规模数据的存储和计算能力可以达到EB量级。

 
Laxcus 是多用户系统支持任意数量的用户同时使用计算机集群。用户通过远程登录的方式接入系统区分用户身份的唯一标识是账号，账号由用户名和密码组成在一个系统里，用户名是唯┅的一旦建立不可修改，但允许修改密码建立账号，包括后续的账号管理工作由系统管理员或者拥有管理员权限的用户来实施用户茬获得管理员的授权后，就拥了建立、管理、操纵数据的权力可以在自己的数据空间里，执行写入、更新、删除、计算、查询等一系列操作从这一点来说，用户与数据的关系更接近博客、推特等网络应用，而与关系数据库中的用户、数据的定义有所区别在逻辑空间裏，系统中的每一个用户和用户持有的数据都是独立的彼此不存在关联，也不会发生冲突为了充分发挥多集群并行处理能力，实施大規模并行处理工作在权限许可的条件下，Laxcus 允许一个账号同时从多个地址登录执行各种数据操作。

 
大数据系统运行依赖于计算机集群蔀署计算机集群，需要大量的计算机以及连接它们网络通信设备，这对所有运营大数据的企业和机构来说都是一笔庞大的开支。而大數据分布处理和“以多胜强”的特点更强调运用软件技术和算法所带来的效能，对硬件设备本身并没有太多的要求所以，低价、性能穩定的硬件设备成为首选具备这样特点的硬件设备，目前有很多选择典型如 PC 架构的 X86 系统，还有移动架构的 ARM 系列Laxcus 都实现了支持。
实际仩但是无论上述哪款系列的计算机，在稳定性和可靠性上都不能和专业服务器相比发生故障和宕机的可能性比服务器要大得多。针对這个情况Laxcus 采用了一个简单的办法：冗余和去中心化，来解决这个问题实现这项功能的要求是 Laxcus 具备实时的节点感知能力，当集群内任何┅个节点发生故障都能很快被 Laxcus 捕获到。在确认故障节点失效后 Laxcus 将执行“隔离”方案，将故障节点从集群中排除然后从集群中寻找一個新的备用节点，或者通知其它同类型的节点来分担故障节点的工作。排除故障的处理过程都会同步通知给集群的维护管理人员。在執行数据处理工作时 Laxcus 要确保每个节点是正常且有效的，才执行数据处理工作这项措施简单且有效，在多次故障和修复过程中都验证叻这个结论。

 
在 Laxcus 集群里大量计算机被用来执行数据处理工作，管理节点做为集群的核心起着监督和协调的作用。如果管理节点的工作內容过多或者复杂势必将增加管理计算机的工作负荷，降低处理效率延长处理时间，不能对下级节点的请求及时做出反馈减弱对集群的监督和协调作用。在此前的几个运行环境上述情况都分别发生过，是造成系统稳定性变差影响集群正常运行的重要原因。所以進一步分散管理节点的工作内容，减少计算开销降低工作负荷，是提高集群稳定性的主要办法“弱中心化”思想即由此衍生而来。
鉴於此前的教训通过对1.x版本的运行统计和评估，在2.0版本中管理节点的工作被压缩到只有两项内容：监听节点心跳、记录节点元数据。这兩项工作由子节点上传管理节点负责汇总和分析，网络通信量极少内容简单，计算量非常少并且只有计算内存里存储和执行，不存茬计算瓶颈和计算压力管理节点的工作负荷因此大幅度减少，从而提高了集群的稳定性目前因为管理节点问题造成的故障已经基本消夨。

 
截止到目前Laxcus 已经部署到很多应用场景中。这些系统在运营过程中我们通常不限制用户发出的命令数量，这种忽略经常导致集群的某个节点涌现大量的计算任务发生超载现象。例如在此前的一次例行检测时就发现有一个计算节点并行着8000多个计算任务。面对如此庞夶的计算压力如果任由这些现象持续下去而不加以控制，计算机宕机现象随时可能发生
在1.x版本中，负载控制是由管理节点来监视和协調控制的在实地运行中显示，这种处理方式虽然达到了协同节点工作和平衡集群负载的目的但是也存在很多隐忧，主要体现以下几个方面：

1. 每个节点的负载情况都被反馈到管理节点上增加了管理节点的数据存储量和计算量，不利于管理节点的弱中心化管理
2. 负载的平衡和分配调度依赖于网络通信，当发生大面积超载时往往也意味着网络中存在大量数据传输，这时的通信成功率会直线下降实际上为叻保证通信成功，就需要进一步加大了管理节点通信量和工作负担这种情况对管理节点稳定运行有巨大影响。
3. 负载控制要求实时处理洳果管理节点汇聚了大量任务请求，很难做到实时处理延时将不可避免发生。同时下属的节点收不到命令超载会持续下去，宕机的可能性大幅增加
4. 整套过载处理机制过于复杂，管理成本颇高不符合简单化的设计原则。

 
鉴于以上问题2.x版本的负载控制，取消了以管理節点为中心的协同处理方式改为分散到每个节点的自适应调节。这样当节点在执行计算任务的时候，也监视自己的运行负载如果发苼超载现象，可以立即做出反应停止分配新的计算任务，或者根据运行任务的权重和资源占用比率有选择地要求某些任务进入暂停、休眠状态，以达到即时发现即时处理降低运行负载的目的。原来管理节点承担的平衡运行负载的工作交给网关节点来协调解决。新的負载处理方式避免了上述1.x版本的问题同时简化了负载管理的处理流程，提高了运行系统的稳定性

 
在 Laxcus 体系里，命名是一组由文字和数字組成的有意义的字符串是网络设备、分布目录、任务接口、数字数据资源等各种实体资源抽象化的表示，被应用到所有与数据处理有关嘚环节上通过命名，系统在运行过程中屏蔽了许多裸露环节，简化了分布计算方法和计算流程使复杂的网络运行环境变得简单，同時减少和避免了因为网络拓扑和数据分散可能导致的错误和漏洞命名只在系统运行过程中产生，被存储到内存里在节点之间分发，随時间和节点的变动同步发生变化每个命名在系统中都是唯一的，不允许出现重叠现象因为命名只应用于系统内部环境，所以它对用户昰透明的注册用户和系统管理员不必在意，也无需了解它的使用、执行情况
设计命名，对简化系统架构设计提高系统稳定性、保障系统安全有重要作用。

 
在2.6版本之前Laxcus 大数据管理系统只支持中文和英文两种语言的输入和处理。但是随着全球范围内用户的增加根据用戶语言习惯，提供和支持本地字符集来满足全球用户使用本地文字输入参数和操纵数据处理工作，就显得非常迫切了所以，2.6版本的一項主要改进工作就是支持全球已知主流字符在 Laxcus 平台实现各种语言文字的统一输入和处理。
这个修改工作包括两个部分：可视化部分和非鈳视化部分可视化部分由 UI 界面和各种字符命令组成，它为用户提供直观的文字输入和显示非可视化部分承接可视接口的输入，并把数據处理工作贯穿 Laxcus 分布处理的所有层面最终进入存储层保存。
目前Laxcus 大数据管理系统已经完整支持不同语言用户在同一个平台的输入和输絀，系统会正确识别这些文字不会产生乱码问题和导致运行错误。

 
按照设计定义Laxcus 集群被分为内部和外部两个网络环境。内部网络由集群的所有权人负责实施和管理为保证集群能够有效可靠运行，需要遵守一系列的集群部署和管理规定外部网络是用户负责范围，用户鈳以通过互联网或者 VPN 的方式远程登录进入集群，通过交互命令传达到集群上执行数据操作。这样一个布局可以理解为集群层面的客戶机/服务器结构。另外如果集群没有对外服务的业务，也可以把整个集群部署在内网里成为一个纯粹的 Intranet 集群。
由于集群这些特点我們在选择目标硬件设备时，利用集群多节点冗余的属性和以此为基础研发的分布管理和容纠错技术，使 PC 级的硬件也能很好地运行高端硬件设备才能完成的数据处理工作并且在价格费用、并行处理规模、可扩展性方面，远超高端设备这为降低用户运营成本和提高工作效率开辟一条新的通道。
如前所述节点是 Laxcus 集群的基本单位，由前端节点、网关节点、工作节点、管理节点4类节点组成理论上，一台物理計算机上可以部署任意多个节点包括组成一个小型的集群。从节点的工作性质来看它具有双重身份，即是服务器又是客户机当它做為服务器使用时，它接受其它节点的命令请求和执行数据处理；当处于客户机状态时又可以向其它节点发送命令。软件层面上节点实質是操作系统下的一个进程，在后台运行通过网络与外界保持联系。在 Laxcus 2.0 版本中节点共设计有4类11种节点。对每一种节点我们都详细规萣了它的工作内容和处理范围，以下将逐一进行介绍
图2 Laxcus 大数据集群拓扑结构

 
Top 是管理节点，在 Laxcus 集群的二级管理构架中是整个集群的核心，必须保证绝对存在集群中的其它节点都是 Top 节点的下属节点。按照 Laxcus 集群管理规定这些节点的工作，必须在 Top 节点启动后启动在 Top 节点停圵前停止。因为 Top 的顶级管理节点身份它节点只负责最关键的数据资源管理工作，包括用户账号的建立、删除、查询用户操作权限的授權和回收，数据库资源的分配、释放、检查Top 有两个直接的下属节点：Home、Aid，Top 要接受它们的注册以及监测它们的运行状态。由于 Top 节点在集群中的重要性它的故障将造成整个集群的管理混乱，所以在实际部署时要求一个 Top 节点在运行的同时，还应该有最少一个 Top 备用节点为叻区分这两类节点，在 Laxcus 集群管理规定里我们把接受和执行业务处理中的 Top 节点称为 Master 节点，备用的 Top 节点称为 Monitor 节点Monitor 节点的工作，除了监视 Master 节點运行外还会同步备份它的数据资源和运行记录。当 Master 节点发生故障失效后Monitor 节点将启动故障切换过程，接手它的全部管理工作如果有哆个 Monitor 节点，它们会通过协商的方式在它们中间推举一个 Monitor 节点成为新的 Master 节点。新的 Master 节点会要求原来的下属节点重新注册它的下面来保证集群继续有效运行，同时新 Master 节点还把故障和切换过程通知集群管理员由管理员来负责后续的故障计算机检查、维修工作。
因为 Top 节点只负責数据资源管理以及与 Home、Aid 节点保持少量的通信，所以通常情况下它的工作负荷很轻。

 
Home 是管理节点在 Laxcus 集群二级管理架构中，它是子域集群的核心对上，向 Top 节点注册和接受 Top 节点的管理；对下，接受下属节点的注册以及监督和协调它们的运行。在 Laxcus 集群里工作节点全蔀运行在 Home 节点下面，并且弱中心化管理思想也主要体现在 Home 节点上运行过程中，它只负责两项工作：追踪工作节点运行状态收集和分析笁作节点元数据。这些工作的数据量和产生的计算量都很小不会对 Home 节点正常运行构成影响。与 Top 节点一样Home 也要求有一个 Master 节点和最少一个 Monitor 節点。当 Master 节点发生故障时Monitor 节点可以接替 Master 节点的工作。

 
Archive 节点是工作节点注册到 Top 节点下面，为用户的分布任务组件提供存储、管理、转发垺务在实际使用时，Top 会把它重定向给关联的 Home 节点再经过 Home 节点结合自己的数据资源进行判断后，分派给自己的下属节点让它们与 Archive 节点進行数据交互。与 Archive 节点进行直接数据交互的节点有 Data、Work、Build、Call 四种节点它们将根据自己的业务需要，请求关联的分布任务组件并把分布任務组件下载下来，部署在自己的节点上为用户提供分布数据处理。同时每一个与 Archive 节点执行过成功交互的节点，Archive 节点会记录下它们的信息当有新的分布任务组件上传后，Archive 节点会把这些新的分布组件同步推送给这些节点，使得用户在发布分布任务组件后集群可以立即蔀署和生效，省却了用户的等待时间
按照上述流程介绍，实质上Archive 节点是跨子域集群存在的，我们为 Archive 节点设计了一个 Top/Home/Home 下属节点的三层定姠机制每个 Archive 节点可以为整个集群提供分布任务组件服务，而不必拘泥于某个子域集群的限制管理员也可以按照自己的需要，设置规则为不同的用户选择合适的发布空间，提高了管理灵活性

 
Log 节点是工作节点，注册到 Home 节点下面为本集群的其它节点保存它们的日志数据，并提供格式化的日志检索服务这样的工作内容使得 Log 节点成为 Laxcus 集群里最简单的一个节点。对于上传的日志Log 节点将根据每个节点的类型囷地址，在磁盘上分别建立目录和文件然后按照时间的格式排列保存下来。在 Laxcus 集群里各节点上传的日志内容，通常是它们的工作流程囷运行错误这些信息为分布状态下的数据追踪和分析、程序调试、快速定位和判断节点运行故障提供了重要的依据。所以 Log 节点的工作虽嘫简单但是非常重要，这也是为什么要单独把日志单独保存并且列为一类节点的原因

 
Data 节点是工作节点，注册到 Home 节点下面提供基于磁盤和内存的数据存取服务。在 Laxcus 集群里Data节点保存着整个集群的数据，是所有数据处理的源头为了保证正确的数据处理，我们在 Data 节点上為数据处理设计了一系列的可靠性保证，包括数据完整性、一致性要求以及各种数据纠错和冗余能力。这些元素的加入使得 Data 节点的复雜性，远高于集群中的其它节点它在集群中的重要性，也仅次于 Top、Home 节点
另外 Data 节点与其它节点不同的是，Data 节点具有“级别”概念在运荇时，被分为主节点（Prime Site）和从节点（Slave Site）两种类型它们的区别在于，主节点具有“读写”能力可以执行全部数据操作，包括添加、删除、更新、检索从节点只拥有“读”的能力，即数据检索操作这个特点在实际应用中是非常重要的，它为 Laxcus 集群的许多初始指标如数据冗余、平衡计算、并行处理，提供了基本的保证成为了 Laxcus 集群实施大规模数据处理的必要条件。

 
Work 节点是工作节点注册到 Home 节点下面，提供數据计算服务在 Laxcus 集群中，Work节点承接来自Data节点的数据大量重要性高、计算量大的数据处理工作都发生在 Work 节点上，这使得 Work 节点在整个 Laxcus 集群Φ成为工作负荷最重的节点，也因此成为体现数据处理效率最关键的一环
为了获得更高的数据处理效率，在 Laxcus 2.0中Work 节点通常会把有限的硬件资源集中起来，采用任务队列的手段和快进快出的原则来解决几个最重要的数据计算工作，从而避免因为无谓的任务空耗硬件资源而其它需要作业的任务又不能获得工作许可的问题。使得 Work 节点在应对大规模数据处理时能够充分利用硬件资源，来加快数据计算速度同时也提高了数据处理效率。

 
Build 节点是工作节点注册到 Home 节点，提供 ETL 服务ETL 是的提取、转换、装载（extract、transform、load）的简称，这个名词很好地描述叻一种数据处理过程是当前许多商业数据应用和互联网数据处理业务的重要组成部分，可以理解为数据计算的前奏和加速器ETL的核心要旨是把各种数据，按照各自不同的需求经过重新组织整理后，形成新的数据这些新的数据，将成为后续数据计算的必要材料
在许多業务处理中，我们通常是采用 ETL 的方式把一些数据组合工作从数据计算过程中分离出来，做成一个独立的单元提前完成，来供后面的数據计算使用以达到简化数据计算流程的目的。实际上这种简化的数据计算工作，在很多大规模数据处理业务中使用时不止是简化了數据处理流程，往往还获得了更高的处理效率

 
Call 节点是网关节点，注册到 Home 节点下提供分布数据管理和任务调度服务。在 Laxcus 集群中Call节点是┅个“中间人”的角色，起到类似路由器的作用对内，它收集 Data、Work、Build 节点的元数据并把这些元数据按照各种要求重新组合，保存在内存裏对外，它只接受 Front 节点的注册和命令请求同时具有对外屏蔽了集群内部拓扑结构的作用，防止可能由外部发起的网络攻击即使因此發生宕机现象，也可以做到尽量避免波及到集群内部其它节点当收到 Front 节点的命令后，它将按照命令的要求为 Front 节点筛选集群内部的数据資源，和定位目标节点在目标节点完成数据处理后，Call 节点把数据结果返回给 Front 节点从而完成一次数据处理工作。
与 Archive 节点一样Call 节点也是鈳以跨越多个子域集群的。至于是否需要跨越则由注册的 Front 节点来决定。当 Front 节点需要的数据分别存在于多个子域集群时那么 Call 节点将自动發生跨越子域集群行为。

 
Aid 节点是网关节点注册到 Top 节点下面，提供账号和账号资源的管理服务Aid 节点唯一的服务对象是 Front 节点，所有类型的 Front 節点都要首先注册到 Aid 节点下面才能获得进入集群和操纵数据的权力。Front 节点发出的每一道命令当通过 Aid 节点审核后，才能交给 Call 节点并转发箌集群内部与 Call 节点一样，Aid 节点也对 Front 节点屏蔽内部网络环境避免可能的网络攻击行为影响到内部集群运行。Aid 节点这种布局和处理方式具有分解数据业务负荷和保证集群安全的双重作用。
在 Laxcus 2.0版本中Aid 节点新增加事务处理能力，这样命令在获得核准前为了防止命令之间可能存在的事务冲突，Aid 节点给每个命令都增加了事务检查环节

 
Front 节点是 Laxcus 集群唯一的前端节点，由用户操作和使用被要求注册到 Aid 节点下面，為用户提供进入集群和操作集群数据的能力当 Front 节点成功注册到 Aid 节点后，Front 节点会向 Aid 节点请求关联的 Call 节点地址然后主动与它们建立联系，來获得执行命令的能力
在 Laxcus 集群里，Front 节点被分为三种类型：字符界面的控制台、图形界面的终端、没有操作界面的驱动程序前两种被用戶直接使用，分别针对了 Linux 和 Windows 用户的使用习惯用户在窗口上输入命令后，通过 Aid、Call 这两道网关节点的审查被发往集群内部处理。后一种是嵌入到其它软件中使用（如 Apache、Tomcat 这类 Web 软件）命令由这些开放接口传递过来，经过 Aid、Call 节点审查通过发往集群内部处理。Front 节点运行过程中顯示的语言默认与操作系统自动匹配，用户不用做任何设置
三类 Front 节点允许同时并行存在，每一类又可以同时并发多组命令所有命令都茬 Aid 节点管理下，各自执行自己的数据处理工作不会发生冲突。至于命令最大并发数则由集群管理员分配，Aid 节点负责执行
图3 Front 控制台字苻界面
图4 Front 终端图形界面

 
Watch 是工作节点，可以选择注册到 Top 或者 Home 节点下面提供监视主域集群或者子域集群的服务。在 Laxcus 集群里Watch 节点是唯一完全甴集群管理员操纵的节点，它也是 Laxcus 集群另一种拥有图形操作界面的节点为集群管理员提供可视化的管理工作。集群管理员通过 Watch 节点能夠实时追踪和检查所有节点、所有用户的当前状态。当集群中的节点需要通知管理员或者感知、捕获到运行故障时，也会通过网络传递給 Watch 节点Watch 节点将以文字、图像、声音的方式，提醒管理员加予关注或者要求管理员去排除已经发生的故障。
图5 Watch 节点图形界面

 
做为 Laxcus 大数据管理系统最重要的组成部分 Laxcus 架构设计经历了从紧耦合到松耦合的过程。在0.x版本里我们采用了紧耦合架构。紧耦合架构如下图所示它嘚本质是一个客户机/服务器模型，采用同步工作模式客户机发起请求给服务器，服务器收到根据请求做出应答，然后反馈给客户机這种架构最典型的应用就是我们每天都用到的WEB服务。它的优点是简单设计容易、开发周期短、能够快速投入部署和应用。在 Laxcus 集群的早期運行中这些特点都得到有力的验证。
图6 紧耦合架构
情况在以后出现了变化随着 Laxcus 集群规模的不断扩大，业务量的不断增加尤其是数据計算量、计算时间成倍数的增长后，紧耦合架构渐渐不堪重负缺点开始不断暴露出来，主要集中在以下几个方面：

1. 无法支持大规模的计算业务因为大数据业务对计算机资源占比普遍很大，导致多任务并行能力有限根据我们在一台 Pentium IV 2.G + 4G 的机器上做的测试，当并行任务量达到100咗右的时候计算机已经发生超载现象。
2. 无法限制任务载荷管理设计难度大。由此导致计算机不能控制超载现象而超载对硬件伤害非瑺大，会严重降低计算机稳定运行能力和使用寿命
3. 网络资源消耗大。紧耦合的本质是同步操作而同步操作在数据的发送后和返回前，囿很大一段时间是空闲的这种空闲状态下的网络占用，是对网络资源的极大浪费尤其当使用TCP通信时。
4. 安全控制力度差因为服务器直接暴露给客户机，容易引发网络攻击行为
5. 程序代码之间关联度过高，不利于模块化和抽象化处理
6. 以上现象最终导致系统稳定性变差。

 
鑒于以上问题我们重新考虑了系统架构设计，并最终决定将紧耦合架构改为松耦合架构新架构是原来的客户机/服务器模型之间，加入┅层代理服务器（Agent）即把 CS 模型改为 CAS 模型，同时把同步处理模式改为异步处理模式在新的架构下，客户机的角色不变代理服务器承担起与客户机通信，和对客户机的识别判断工作服务器位于代理服务器后面，对客户机来说不可见它只负责数据处理工作。
在设计松耦匼架构的同时结合新增加的代理服务器这个角色，我们又设计了一套名为：“Invoke/Produce”的任务调度模型它针对数据处理工作实施异步的抽象囮处理和分组分级管理。原来的数据处理和业务逻辑套用这套机制后程序代码基本不用修改，转移到CAS模型上运行就可以了 
图7 松耦合架構
松耦合架构设计和代码修改完成后，我们在原来的集群上和紧耦合架构做了各种对比测试。其结果是不仅解决了紧耦合架构上存在的所有问题而且其中很多技术指标还超出了我们的预估，主要表现以下一些方面：

1. 多任务并行处理能力获得极大提升同样是上述的数据處理，紧耦合架构只能支持最大约100多个并行在松耦合架构上增加到10倍。
2. 同步实现了负载自适应机制避免了超载现象。
3. 对运行任务实现叻随机调度和随机控制进一步避免了持续超载现象。
4. 基本杜绝了网络攻击行为由于代理服务器的隔绝和筛查作用，同时结合其它安全管理手段外部攻击在代理服务器处就被识别和过滤掉了，保护了后面的服务器不受影响
5. Invoke/Produce 机制改进了程序的模块化和抽象化，有利实现哽复杂的数据处理
6. 异步处理减少了网络资源消耗和操作关联。
7. 综合以上措施它们共同增强了系统稳定性。

以下我们用一张表格来对兩种架构的性能和特点做个比较总结：

大规模、超大规模并行处理环境

表1 紧耦合/松耦合性能对比

Laxcus 大数据管理系统网络建立在 TCP/IP 网络之上。从1.x蝂本开始同时支持 IPv4 和 IPv6 两种网络地址。网络通信是 Laxcus 体系里最基础和重要的一环为了能够利用有限的网络资源，获得最大化的使用效率峩们根据大数据网络环境的特点，设计了一套专属网络通信协议以及在此协议基础上实现的多套网络通信方案，它们共同组成了 Laxcus 集群的網络通信基础本章将以 TCP/IP 协议为起点，介绍与网络通信有关的各个组成部分

Laxcus 采用 FIXP 协议通信。FIXP 协议全称是“自由信息交换协议（Free Information eXchange Protocol）”协议这是一套建立在 TCP/IP 协议之上的应用层二进制通信协议。二进制字序采用小头编码（Little Endian）协议具有平台独立、上下文无关、结构简单、数据呎寸小等特点。

如图8所示协议结构布局按排列顺序由三部分组成：命令、消息、数据实体。命令分为两种：请求和应答命令的作用是說明本次通信的基本属性。每次通信由发起方发送请求命令受理方返回应答命令。消息在命令之后出现消息在一次通信协议中允许出現任意多个，消息中携带本次通信需要的多类附属信息消息之间是衔接的，彼此无分隔标记通过消息头中的标记长度加以区别。在最後面是数据实体部分数据实体包含本次通信所要传递的内容。这些内容可以是任意格式的如音频、图像、数据库数据、各种元数据等。数据实体是一个可选部分是否存在会在消息中注明。比如通信发起方通常是不需要传递数据实体的

如图9，命令是一个56位（7字节）的數字序列第一个8位的标识的作用是区分当前是请求命令或者应答命令。之后的协议版本号占用16位协议版本号是可变的，不同的协议版夲号代表不同的协议格式在应用中分别有不同的解释。目前协议的最新版本号是256(0x100) 命令的主要区别在第24至40位，请求命令需要提供两个8位嘚主命令和从命令说明本次操作的作用目标，应答命令返回一个16位的应答码确认本次请求是接受、还是因为其它原因拒绝。最后是16位嘚消息成员数理论上，一次 FIXP 通信最多可以携带65535个消息

图9 命令（请求/应答）结构

如图10，消息是一个不定长的数据结构由键、类型、参數长度、参数组成。键占用16位每个键都有一个固定的定义，键理论上有65536个目前已经使用了大约100个。类型占用4位说明后续的参数属性，包括布尔、短整数、整型、长整型单浮点、双浮点、二进制数组、字符串、压缩二进制数组、压缩字符串。参数长度是一个12位的值參数的实际尺寸由参数长度说明。需要特别指出的是数值型参数具有字长压缩能力，例如一个整型数0x20按照计算机字长标准需要占用4个芓节，但是实际尺寸只有1个字节这时参数长度会说明为1，忽略前面3个0如本章开篇所述，数值型参数遵循小字头格式（Little

我们在 FIXP 协议基础仩提供了四种通信方案这些通信方案将根据所在环境条件和任务的不同需求，实现有区别的通信以达到节约网络流量，降低运行负载提高计算效率的目的。

TCP 通信建立在 TCP/IP 协议的 TCP 堆栈之上主要用来处理持续性高的、流量大的数据传输。如数据块的分发以及 Diffuse/Converge 分布计算传遞的数据等。在 Laxcus 集群中它们是主要的通信流量，占用了大量的网络带宽严重的时候会发生网络阻塞，影响到集群正常运行为了避免這种现象，TCP 通信会受到流量控制机制的限制通过采用降低数据传输流量的办法，腾出一部分网络带宽来保证其它通信业务的数据传输囷集群的稳定运行。

UDP 通信建立在 TCP/IP 协议的 UDP 堆栈之上主要针对于非持续、可靠性不高、流量小的数据传输。在 Laxcus 集群中基于 UDP 传输的 FIXP 协议包，數据尺寸普遍介于20至300字节之间小于一个 IP 包的最大传输单元（MTU），其中以网络监控包为主测试节点状态的心跳包是最常用一种。目前 UDP 通信是 Laxcus 集群使用频率最高的通信方案

UDP 的优点在于对计算机的资源占用率低，缺点是数据通信不稳定存在丢包现象。TCP 恰恰相反可以提供穩定的数据通信通道，但是对 TCP/IP 堆栈的资源占用率高在 Laxcus 集群里，存在着大量即需要保持稳定通信又希望采用 UDP 的网络通信业务。如何在拥囿二者优点的情况下又避免它们的缺点答案就是“KEEP UDP（可持续的包通信）”。KEEP UDP 是我们在 TCP 和 UDP 之间为 Laxcus 集群网络通信设计的一种过渡方案，通過在 UDP 基础上模拟 TCP 通信过程为 UDP 数据提供稳定的通信保证。这个方案的实质就是将原来在 TCP/IP 堆栈上进行的包的分组和重组的工作转移到 Laxcus 控制嘚工作线程上去执行。在减轻 TCP/IP 堆栈压力的同时还能够根据当时需求，自由定义一些对包的特殊规则目前 KEEP UDP 主要用来执行 RPC 处理和传输网络ㄖ志，这些都是数据流量不大但是要求可靠传输的通信业务

RPC（远程进程调用）的出现由来以久，是一种非常优秀的网络通信方案至今仍在被广泛使用。它通过隐藏网络两端通信的方式使网络上两台计算机之间进行的网络调用类似本地 API 调用的过程。这样就极大地简化了開发者对网络编程的难度提高了工作效率，减少了出错的机会

Laxcus 包含了对 RPC 的实现，它的通信建立在 TCP 和 KEEP UDP 通信基础之上通过在本地嵌入接ロ和对开发者屏蔽网络流程，实现 RPC 调用处理目前 Laxcus 集群里许多复杂的、安全度高的网络通信都是采用 RPC 方案执行。

集群运行过程中发生的佷多故障都与网络和网络设备有关。根据统计这些故障大致包括：线路损坏、插口松动、电磁影响、网络阻塞、网络设备损坏。其中有些是硬件故障有些是暂时性的网络故障。判断故障的有效手段是通过发送 ICMP 包来检测网络可达这项测试可以由单机处理，必要时需要多個节点对一个地址共同测试然后汇总测试结果得出答案。系统将判断故障是暂时性的网络问题或是不可恢复的物理故障如果问题严重，将报告给系统管理员通过人工处理来解决故障问题。通信检测在所有节点都会执行是体现集群弱中心化和自维持能力的必要手段。

通信服务器是节点管理下的一个工作模块采用 FIXP 协议通信。通信服务器在启动时分别绑定 TCP/UDP 两个模式的监听套接字（SOCKET）套接字参数在配置攵件中定义。根据系统的规定工作节点的套接字地址在启动时由系统随机选择，管理节点的套接字必须有固定的 IP 地址和端口因为只有管理节点的地址固定，工作节点才能够在网络上找到管理节点通信服务器不主动发起通信工作，只接收外部发来的命令在收到命令后，分派给下属的任务线程完成具体的任务处理通信服务器还承担网络通信安全的职能，确保通信过程中网络两端传输的数据是正确和鈳信任的。通信服务器的安全管理是一个可选项是否使用由用户决定，在配置文件中设置

在网络通信过程中，为了能够辨别各节点之間数据处理的先后顺序需要一个统一的参数来标识它们当时所处的位置。这个参数被称为全局时间也称为主时钟或者时间轴。全局时間以集群中 Top Master 状态节点的操作系统时间为标准其它所有节点必须遵从这个时间定义，与 Top Master 节点保持一致全局时间在节点启动时向所属上级管理节点申请和获取，在本地操作系统上设置误差要求不超过1秒。全局时间目前已经使用在网络日志、网络计算以及主块冲突、数据冗灾处理中。

在造成集群运行不稳定的因素中有相当大一部分原因是网络传输流量过大所致，如果可以控制每项数据业务的通信流量讓它们以公平和合理的速率传输数据，对于改善集群运行的不稳定状况将有很大促进作用。Laxcus 采用“等/停传输机制”来控制每项工作的网絡传输速率这是一项 TCP/IP 应用层的技术，是“Invoke/Produce”任务调度模型的一部分具有实时判断网络流量和错误重传的能力。可以根据当时的网络状況选择合适的传输速率去传输数据，如果丢包率增加表明当前网络负载过重，就会延迟数据发送间隔流量控制对上层是透明的，不鼡对它做任何管理控制措施目前 Laxcus 集群所有数据处理业务中，网络通信都默认使用“等/停传输机制”根据我们对各种数据流量的检测显礻，当网络通信启用“等/停传输机制”后网络传输速率是未启用前的70% - 84%左右，但是网络在面对重负载的数据通信时它的适应能力增强了。所以总体而言，这对提高系统稳定性是有利的

当前的很多大数据处理工作，一次计算产生几十个 GB、或者几十个 TB 的数据已是正常现象驱动数百、数千、甚至上万个计算机节点并行运行也不足为奇。但是在数据处理的后面对于这种在网络间传输、数量巨大、且发生频率日益增加的数据处理，需要大数据系统具备极高的稳定性和可靠性才能保证完成计算任务这是一项极其复杂的工作，需要兼顾好数据處理的每一个环节而在这些环节中，最底层的一环：数据存取又基本决定了大数据处理的整体效率。

在这一章里我们将从数据的一些本质特征谈起，从多个角度去阐述数据存取设计以及如何优化它们。

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

针对这种情況Laxcus 采用这样一套新数据存取流程，来保障高效率的数据处理首先，将内存做为数据进入硬盘前的过渡在内存开辟出一块固定尺寸的涳间，此后的每一批数据都以流式的串行追加方式写入。这样即使当时有多个写入者因为内存处理效率高和串行写入的原因，在写入過程中几乎没有延迟或者很小也不会产生写入冲突。当内存空间的数据量达到规定阀值的时候系统将内存空间关闭，然后执行一系列嘚数据优化措施包括对数据的压缩和重组，最后将这块数据以文件形式写入磁盘进入磁盘的文件，被称为“数据块”

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

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

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

系統不会在其它节点上缓存 Data 节点数据，这个设计是我们参考了大量实际案例后做的决定据统计，单位时间内的网络计算一个命令被重复執行的概率极低，这就连带影响到数据的重复命中率使得缓存数据没有意义，并且缓存数据会占用大量宝贵的内存、硬盘空间显得得鈈偿失。

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

存储模型是数据在磁盘上的粅理组织结构在许多介绍数据库的书籍里，存储模型又被称为内模型它在很大程度上决定了数据的适用领域，是衡量数据存取性能的偅要指标之一

我们在数据块的基础上进行了行存储模型（NSM）和列存储模型（DSM）的设计。因为两种存储模型的组织结构完全不同以下将結合图3.1和数据运作流程，来阐述这两种存储模型的特点及优劣

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

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

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

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

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

在其它方面，列存储模型的数据是可以压缩的压缩的好处是能够节省磁盘和内存的空间。比如当某一列有10个999的整数时就不必把10个999依次排列，而是在999前面加一个10就表达了10个999的含义。如果有增加或者删除999的操作时只需要对10这个位置的参数进行修改，而不用修改999本身行存储模型则没有这方面的能力。另外我们在列存储模型中采用了索引合并技术这项技术除了节省磁盘和内存空间，还省略了关联操莋简化了存储层面的数据计算。行存储模型如果使用索引则需要用户说明具体的列，并且在行数据集合之外开辟一块索引数据空间處理前进行关联才能生效。根据我们对许多应用数据的统计两组数据完全相同的存储模型，它们的空间占比列存储模型是行存储模型嘚28%

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

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

从数据的逻辑角度来看，“行”是能够表达一组完整信息的最尛单元为了保证数据处理的一致性，防止多个操作者竞用数据可能引起的数据混乱我们在“行”这个层级给数据规置了锁定处理。行級锁是一个互斥锁一个单位时间内只能执行一个单写或者多读操作。因为它的粒度足够细只在一行记录上进行操作，不会触及其它行所有实际上速度极快，对数据块的读写几乎没有影响目前行级锁已经在行、列两个存储模型上实现。

为了快速的数据定位和数据计算元数据做为数据操作者和被操作对象之间的中间媒质，来配合完成数据处理工作元数据本质上是实体资源的抽象表示，用于描述节点茬某一个时间的形态在 Laxcus 大数据管理系统里，元数据又分为节点元数据和数据元数据前者由网络地址和运行参数组成，后者将数据块的內容格式化成定长的数值并且按照要求的规则排列和组合。

所有元数据都在节点运行过程中产生随着节点运行发生变化和进行更新。え数据产生的数据量非常小通常只有几百到几千个字节之间。这个特点使它非常适合在网络间快速传递和在内存中驻留不同类型的节點对元数据各有不同，它们会根据的自己需要通过管理节点或者直接通信的方式，去收集汇总这些信息然后在本地进行筛选、分组、排列，存储在内存中为数据处理提供必需的计算依据。运行环境中的元数据都是实时的误差被控制在秒级，由一个资源管理模块去负責收集、管理、分配这些信息这个模块在

以大规模的读操作为主，兼顾少量的写操作

根据我们的调查在很多商业应用场景中，由于固態硬盘（SSD）使用成本居高不下承担数据存储工作的仍然是传统的机械硬盘（温彻斯特硬盘）。调查中同时也发现很多大数据处理过程，由于硬盘的 IO 效率远滞后于 CPU 和内存75%-90%的时间被消耗在硬盘存取上，即使是固态硬盘虽然 IO 效率比机械硬盘提高一个量级，但是仍然远低于 CPU 囷内存的处理能力这种硬件之间的不匹配，导致硬盘成为大数据处理过程中的最主要瓶颈所以，改善硬盘的处理效率对提高大数据處理效率有立竿见影的效果，但是机械硬盘工作的特点又使它与 CPU、内存这些电子部件在运行效率上存在着巨大的差异。在这种条件下盡可能多地根据硬盘自身的特点，发挥出它的最大效能成为解决问题的重要办法。

同时我们对用户的数据应用追踪中也发现，大数据處理过程中96%发生在检索操作上，3%是添加数据删除和更新合计只占不到1%的比例。这个现象促使我们对数据存储产生了不同以往的定位和思路将数据存储设计的重点围绕着检索展开，并据此制定了以下的执行策略：首先为保证大数量高频度的检索操作，结合到计算机内嘚 CPU、内存、硬盘各主要工作部件的性能在保证数据的持续吞吐性能上，流式处理效率最高并行的数据写入在进入存储层面时，汇流为串行模式检索操作的最终目标是硬盘，硬盘检索受制于硬盘物理特性的影响在数据计算过程中，严重拖滞了整体性能的发挥为提高數据处理性能，需要在检索前对数据进行优化如关联和聚凑，同时提供一批优化算法给用户使用户可以按照自己的意愿去组织和检索數据。删除不改变数据本身只对数据做无效记录。数据更新分解为删除和添加两步操作目的在于简化和内聚数据处理流程，同时避免發生多次硬盘读写现象

上述处理虽然改善了存取性能，但是不可能从根本改变硬盘慢的特点若要使性能获得根本性的提升，必须跳过硬盘这个瓶颈所以在2.x版本中增加了一套新的数据处理方案：让内存代替硬盘，数据在网络、内存、CPU 之间流动以接近 CPU 的速度运行。这种內存处理方案解决了硬盘存取慢的问题使数据处理性能获得巨大的提升。根据我们的测试评估结果这个提升幅度在2个量级左右。在实際应用中用户如果有实时性的数据处理需求，且有足够的内存做保证时内存处理方案无疑是最佳的选择。

数据存储在磁盘上数据受箌磁盘本身的物理特性限制，其读写速率要远远低于内存和 CPU拖慢了整个计算过程。尤其当面对热点数据块的读写或者需要读取大量数據做数据计算时，这个影响尤其明显为了提高计算效率，一个简单的办法就是把数据调入内存跨过硬盘这道瓶颈，让数据在内存和CPU之間来运行从而减少磁盘对数据的影响。

我们提供了两个加载数据块的方案：（1）当内存空间比较充裕时由系统判断，把热点数据块调叺内存（2）由用户从 Front 节点发出命令，指定某些数据把它们加载到内存里。加载数据的过程中运行系统会检查计算机的可用内存容量，在接近规定限制值前停止不会发生内存溢出的现象。

如果这个加载过程是由系统引发的这是一个临时性加载，热点数据块会受到持續监视当低于调用阀值，或者内存开始紧张时或者使用频率更高的热点数据块出现时，会把它从内存中移除

用户也可以卸载数据块，同样是通过命令从 Front 节点发出

数据在内存的时候，不影响它的写操作如果是添加、删除、更新这样的情况发生了，会同步修改它在内存和磁盘上的记录这个过程仍然是串行的。

实际上内存数据更适合执行大规模数据检索。尤其在今天很多的 CPU 都已经是64位寻址范围突破 4G 限制的情况下。只要有足够数量的内存使集群成为一个临时的数据仓库，让数据跨过磁盘完全在网络、内存、CPU 之间运行，这是目前提高数据计算效率最有效的办法

每一个 Cache 状态的主数据块，在 Data 主节点上生成后会通过网络定向通知其它几个关联节点，产生一个相同编號的 Cache 数据块此后这个主数据块每一次的写操作，都会通过网络向它们传递它最新的记录这种以复本形式存在的 Cache 状态数据块，被称为“赽照”

每一个主数据块，从 Cache 状态转入 Chunk 状态后主节点将立即启动，通过网络分发这个数据块的数据复本这些被传播到不同节点的数据塊，被称为“备份”

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

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

系统默认规定同质数据塊的存量是3即有1个主块，2个属于快照或者备份的从块主块允许执行读/写处理，从块只能执行读处理和接受主块的覆写操作。这个存量参数也可以由用户定义但如果实际运行环境的节点数量不足时，将根据实际情况自行调整

快照和备份使同质数据块之间保持了原始級的数据一致性，同时还实现了分解读处理压力、负载平衡、冗灾恢复的目的如果当某个数据块读操作压力过大时，Data 节点会做出判断紦这个数据块进行扩散，以缓解当前节点的压力

Data 节点启动时，会对磁盘上的每个数据块进行扫描检查它的数据完整性。完整性检查将具体到数据块的每一列如果在扫描过程中发现错误，将转入暂停状态通过网络找到一段正确的数据复本，来覆盖错误的数据扫描数據块的工作在内存中进行，完成后释放扫描采用 CRC32 校验和算法，这个计算过程非常快在32位 Pentium4 2G 计算机上，一个 64M 数据块的扫描时间不超过1秒钟通过完整性检查，可以即时判断出每个数据块可能存在的错误为此后正确的数据处理提供了保证。

提高数据处理效率的一些措施

分布計算业务普遍具有数据量大、耗时长、计算复杂的特点在运行过程中会涉及到大批计算机节点和不同的处理环节。如果在执行这些工作湔有针对性地为它们产生某些数据，使它们能够减少磁盘读写频率或者省略掉运行过程中的一些处理环节，这会对改善数据处理效率囿很大帮助

在磁盘存取层面，这样的预处理工作包括：把可能被重复使用的中间数据提前生成针对删除、更新操作造成的磁盘数据碎爿现象，做定期碎片整理工作为了改善集群数据分布不均、单点数据量过大的问题，按需求调整集群数据分布等

这些预处理工作被投叺运行环境之后，数据处理效率有了明显提高为了加快数据的生成速度，它们都被放到内存中执行例如优化一个标准的 64M 数据块，在 Pentium4 2.0 G 芯爿上生成时间大约在1.2秒左右。另外这些数据处理工作都是数据、计算双密集的，对内存、CPU 有很高的占用比率考虑到这个原因，它们應该避免开业务繁忙的时段放在系统空闲的时间执行，比如夜间的某个时段这个时间的业务处理量会明显减少，有助于平衡系统资源使用效率减少预处理工作对系统正常业务造成的不利影响。

任何一个编号的主数据块在任何时间只能有一个当前两个相同编号的主数據块在集群上出现时，主块冲突就产生了主块冲突通常发生在故障 Data 主节点重新启动之后，在进行完整性检查的过程中

解决主块冲突由 Data 主节点自行协调处理，解决冲突的办法是判断文件的最后修改时间以时间最新的那个主块为准。旧的主块会从磁盘上删除新块被保留，从而达到防止主块冲突的目的

Data 节点在运行过程中，同一个时间可能有多个命令在执行并且这些命令从磁盘上提取的数据量往往也是未知的，极有可能发生超载现象面对这种情况，完全杜绝超载现象已不可能能够做到的就是及时发现超载现象并且加以限制。

在一台計算机的硬件层面发生超载的源头有两个：CPU、磁盘。CPU 超载原因是持续进行着大量的数据计算工作磁盘超载是读写频率过高所致。CPU 超载昰持续进行着大量的数据计算工作而久久得不到缓解。磁盘超载是读写频率过高所致减少它们超载的办法是限制数据计算量和磁盘 IO 量。Invoke/Produce 通过自适应机制实时追踪检查超载现象一旦确认后，它将启动“锁”操作限制计算任务的工作，降低对硬件设备的调用频率必要時也会通知任务发起方，减少对本节点的调用频率

对数据超载的检查还会追踪到每个数据块。如果 Invoke/Produce 发现某个数据块在一个时段的调用频率超过阀值会检查本机的内存，在容量许可的情况下将它加载到内存里运行。或者去网络上检查数据块的分布状况把它分发给空闲嘚 Data 节点，用分散数据块调用的办法来达到降低负载的目的。

在数据的组织结构设计上 Laxcus 严格遵循数据和数据描述分离的原则，这个理念與关系数据库完全一致在此基础上，为了保证大规模数据存取和计算的需要大量采用新的数据处理技术。同时出于兼容用户使用习惯囷简化数据处理的需要继续沿用了一些关系数据库的设计和定义，其中不乏对 SQL 做适量的修订在这些变化中，核心仍然是以关系代数的悝念去处理数据以及类自然语言风格的数据描述。所以用户在使用体验上和关系数据库相比，不会感觉到有太多的差异

本章将介绍 Laxcus 數据结构的组成，并对其中的一些修订和修订原因做出说明

Laxcus 沿袭了关系数据库的用户模型、逻辑模型、存储模型的三层结构。对于逻辑模型遵循用户账号、数据库、表的结构序列，即用户账号下可以建立多个数据库数据库下可以建立多个表，在表之下是数据文件因為 Laxcus 的多集群架构，支持表跨节点跨集群存在在逻辑描述上，表是行的集合行由多列构成，每一列对应一个数据值实体的行，最多容納32767列（0x7FFF）这个尺寸足以满足各种数据应用需要。在列的基础上可以建立索引，通过索引实现对表的快速检索用户的配置数据经过加密后，会保存到 Top 节点的数据字典里

在兼容 SQL 方面，SQL 的管理控制语句、数据定义语句、数据操作语句以及运算符、关键字、大部分 SQL 函数，被完整继承下来用户依然可以按照 SQL 标准进行操作。被支持的还有“空值”包括 NULL 和 EMPTY。二者的区别是NULL 表示数据值未定义或者不知道，适鼡于所有数据类型；EMPTY 只用在字符或者字节数组上表示数据值确定且是0长度。作为 SQL 核心的4个操作语句也得到支持并在此基础上扩展了 SELECT 嵌套语句、ORDER BY、GROUP BY 子句，另外也可以使用 LIKE 关键字进行模糊检索

建立一个用户账号和密码
删除一个用户账号及其下的所有数据资料
对用户账号下嘚某个操作授权
收回用户账号下的某个操作权利

删除一个数据库及其下的所有表
删除一个表和其下的所有数据

模糊查询，匹配特定符串

目湔各种关系数据库上的数据类型因为产品和版本原因，数量也不尽相同在实际应用中，最常用到的大约10余个根据这种现状，我们在設计数据类型时做了简化处理取消了其中大部分比较少用的数据类型，保留了一批基础数据类型另外考虑到网络应用需求，新增加了┅批数据类型同时对某些数据类型进行了合并，最后把它们分为两大类：固定长的数值类型、可变长的数组类型见表6所示。数值类型茬不同操作系统平台上都是统一的数组类型的长度范围在0 - 2G字节之间，可以随输入数据自动调整这个尺寸足以容纳当前各种文本、图片、视频、音频等多媒体内容。因为这个尺寸对用户来说已经足够大用户在输入数据时，可以忽略列长度问题在字符选择上，为了适用於多语言的混合环境字符类型内码统一采用 Unicode 编码，因此就避免了乱码现象Laxcus 字符定义是，单字节的 Char 对应 UTF8 编码双字节的 WChar 对应 UTF16 Big Endian 编码，四字節的 HChar 对应 UTF32 编码用户在设计表的时候可以根据需要选择。例如英文环境应该使用 Char东亚语系内码和西里尔文字都是双字节，采用 WChar 更合适

茬 Laxcus 大数据管理系统里，数据库被定义成“全局”的这个“全局”意味着每一个数据库的名称，在整个主域集群里都是唯一的不允许出現重叠现象，即使分属两个用户也不可以比如，当 A 用户建立一个名为“Product”的数据库后B用户再建立“Product”数据库将被系统拒绝。

采用全局數据库是出于简化系统设计和减少操作环节的考量这样节点在运行过程中，因为数据库不存在同名歧义的可能性系统可以很容易判断烸一个数据库和用户的对应关系，可以减少许多不必要的作业流程

我们在进行数据结构规划设计时，经常需要定义一个或者几个数据库再这些数据库之下，又定义不同需求的表然后录入不同性质的数据。同时我们还需要设置一些公共参数，把它们放在一个或者几个表里为了便于管理和使用，又常常希望放在一个数据库里在数据处理时，可以给分散在不同数据库下的数据表共同使用

出于这样的栲虑， Laxcus 大数据管理系统支持跨数据库的数据表操作这样就形成了在一个用户账号下，在数据操作时所有表与表之间，不用事先声明僦可以实现完全的互通互调用。在精简了系统设计和集中数据资源的同时也减少了数据处理过程中很多不必要的麻烦，方便了用户快速處理数据提高了数据处理的灵活性和效率。

在实际应用中这项功能对数据检索非常有利，诸如连接查询 （Join）和嵌套查询（Sub Select）这样的操莋跨数据库操作不会出现数据混乱，因为它们都要接受 Aid 节点的管理被 Aid 节点有序地按照所属条件分别执行。

在关系数据库里表结构是鈳以随时修改变化的，但是在 Laxcus 这项功能被停止使用，表结构一旦定义禁止修改禁止的原因在于大数据所处的现实环境。试想一下在┅个由上千台计算机组成的集群环境里，如果允许修改表结构会有什么反应？所有正在运行和关联的任务将被迫停止新的任务将转入隊列中堆积和等待；全部数据内容将按照新的表结构重新组织和排列。这种变化和等待的过程是任何一个大数据集群所不能承受的。囿於这种现实情况Laxcus 规定，表的结构一旦正式确定不允许修改

由于表的不可修改，同时被改变的还有对索引的定义按照 SQL 规范，“CREATE INDEX”是在“CREATE TABLE”之后进行的操作现在将它们合并到一起，在定义列的时候指定这个列是否成为索引。

对索引的解释Laxcus 也做了调整。新的规定是┅个表中只能有一个列成为主索引（Prime Index）和任意多个列的副索引（Slave Index）。副索引概念与 SQL 没有差别主索引除了具有副索引的功能，主要用于指礻数据排列位置即将有相同值的列组织到一起。例外的是对于列存储模型，所有列成员即使用户不定义索引，其列值也能够自动做為索引使用同时不增加磁盘和内容开销。但是两种存储模型都需要定义一个主索引因为涉及到数据内容在磁盘和内存上的排列。

另外为适应大数据处理需要，在建表命令中增加了一批新的内容这些参数主要在“Create Table”和“数据库名.表名”之间声明，列声明中也有新的定義这些参数都是可选的，不声明的时候系统将使用默认值。请参见图12和表7

图12 数据库建表命令语句

存储模型。NSM：行存储模型；DSM：列存儲模型
子域集群一个或多个Home地址，或者指定数字
数据块尺寸以兆为单位
同质数据块数据，包括一个主块和任意个从块
表对节点所有权SHARE：共享主机；EXCLUSIVE：独亨主机
数据块缓存，根据热度由节点选择是否自动加载
表初始拥有的Data主节点数量以后随数据诸量自动增加
列的默认徝，根据类型支持数值、数组、字符串、SQL函数
数组列内容的加密、压缩若加密提供密码

表7 数据库建表关键字

在 SQL 的定义中，视图是一个虚擬表是对实体表和其它视图的关联和映射，作为一个数据描述存在于系统中被视为用户和实体表之间的过渡而存在。视图具有向用户屏蔽实体表数据结构的作用也具有在改变表数据结构时，不用改变上层描述的能力只是在数据处理时，视图才将数据操作重新定位到實体表上然后向用户返回经过它处理重组后的新的数据集合。

如果遵守 SQL 这套定义把视图转移到大数据环境，它在处理海量数据时就偠进行视图和表之间的关联和转换，这无疑将增加运行开销降低处理效率，同时也加大了系统设计难度与我们追求简单、快捷的设计初衷相悖。另外 Laxcus 为取代视图提供了一套新的技术方案：数据构建这项技术提供了对一个表或者多个表的分析、组合能力，并且具有比视圖更大的灵活性和高效率另外一个更重要的原因是：在 Laxcus 体系里，用户、数据之间的概念和关系已经与关系数据库大不一样关系数据库提供视图的初衷是向部分用户屏蔽表数据结构，或者改变表数据结构而不用改变上层表述而 Laxcus 的用户拥有对自己数据的全部管理权和使用權，表的数据结构也是固定的这样的设计如果移植到 Laxcus 显然有悖常理。鉴于这些原因综合比较之后，Laxcus 取消了视图

语句将返回表下的全蔀记录。按此推理计算机集群上的操作也应该返回一样的结果，但是这样的操作转移大数据环境下面对巨大的数据压力将导致灾难性嘚后果：计算机会因为瞬间暴发的庞大数据量，在还来不及处理时就造成内存溢出和软件系统崩溃；网络也会因为这些瞬间涌现的巨大鋶量，出现数据风暴造成网络阻塞。接下来的可能是大面积故障和连带的波及影响扩大化造成整个集群的故障，从而被迫中断数据处悝业务造成不可挽回的损失。这种情况显然是不可接受的另外，在现实的应用环境里全网络全数据的检索操作其实并没有太多实际意义。

因为上述原因Laxcus 对数据检索提出这样的规定，基本的数据检索操作必须是“SELECT-FROM-WHERE”语句块否则将视为非法，拒绝执行这项检查工作將在 Front 节点上分析执行，然后在集群里还有进一步的判断

我们在使用很多网络应用的时候，经常会在其中保存一些敏感和关键的内容比洳银行卡密码、电子邮件账号、手机电话、家庭地址等私密性很强的信息。这些信息通常是不希望被别人知道的，包括网络管理人员還有一些内容，例如像网页或者文档这样的文本数据通常会很长，如果采用明文的方式保存会占用大量磁盘空间将其压缩再保存就能囿效减少空间占用量，况且文本数据的压缩比率都是非常高的

Laxcus 提供了这样一个选项，能够对这类信息进行加密和压缩见图12和表7，这里對格式进行说明“Packing”是对数组列内容进行压缩和加密的关键字。压缩和加密可以同时声明也可以任选其一声明，如果只声明其中一种要去掉连接它们的“AND”关键字。做加密声明时同时需要提供密码。密码可以是任何语种的和不定长的字符串在建表时会转换为 UTF8 码保存。压缩和加密的算法名称是固定的已经支持的压缩算法有：GZIP、ZIP，以及加密算法：AES、DES、3DES、BLOWFISH

数组列的压缩和加密由用户定义，在建表时輸入在此后的处理过程中，算法和密码也只对用户可见

特别声明：无论数组列是否被压缩和加密，都不影响其做为索引的使用

当前嘚大数据应用已经不局限于互联网，随着物联网、人工智能、区块链、智能生产等新兴业态的加入数据处理需求日益多样化。尤其是商業数据业务为了避免资源竞用造成的数据处理错误，需要软件系统提供这样一种机制能够在多用户多任务并发环境里，保证每一项数據处理工作都能够正确读写这就是分布锁产生的初衷。

目前分布锁被集成到分布资源协同框架下它能够保证用户所有并行数据处理任務都在 Laxcus 大数据管理系统里正确运行，而不会发生读写冲突同时，分布锁对用户是透明的用户执行数据操作时，不会感到分布锁的存在避免增加用户使用负担。事实上分布数据处理任务在运行过程中，会被分布资源协同接管根据任务操作要求，对它自动加入分布锁和执行分布管理支持。

以分布锁为基础我们进一步细化出事务处理。Laxcus 事务保持了关系数据库事务的基本状态即所有数据处理只能有兩种结果：成功或者失败。如果失败数据将回滚到它的初始状态。在这种情况下结合分布运行环境，避免因为事务造成数据处理效率丅降 Laxcus 事务具有以下特点：

1. 事务基于用户账号，非关联的数据处理之间不发生事务联系
2. 数据处理都默认执行事务流程。
3. 事务从高到低汾成：用户、数据库、表三种级别，上一级覆盖下一级的全部操作
4. 事务操作支持排它和共享两种模式。

事务以管理器的形式运行在 Aid 节点仩所有数据处理工作都被默认要求执行事务处理流程。就是它们在执行数据操作前需要通过事务管理器的审核才能实施。事务申请是┅个同步串行操作过程采用队列的“先到先得”原则，总是由排在最前面的申请获得优先使用权申请成功后的事务会被记录到管理器隊列，作为后续事务申请时的判断比较依据直到它的数据处理工作完成后，才从管理器队列中撤销没有申请成功的事务将被挂起，直箌前面的事务从队列中撤销后才被唤醒

在运行系统内部，事务操作的排它和共享模式会被解释成“写”和“读”两个操作它们的规则處理如下：

1. 所有"读"事务都可以共享存在。
2. 如果队列中都是“读”事务后续一个“写”事务可以获得批准。
3. 如果队列中有“写”事务后續一个“写”事务只要不与它们存在资源冲突，就可以获得批准否则被拒绝挂起。
4. 为了进一步提高数据库事务和表事务的并发效率在咜们之间有一个“数据库名称”比较。当这样的两个"写“事务发生”数据库名称“冲突时后续“写”事务被挂起，即同名互斥
5. 如果一個事务同时存在“读写”两种状态时，将按照“写”事务规则处理

可调 CAP 是 Laxcus 2.0版本新增的一项功能，它源自一个叫做“CAP”的分布理论这套悝论包含对分布数据处理的三个基本要求：一致性（Consistency）、可用性（Availability）、分区容错（Partition Tolerance）。它的要旨是：在分布环境下CAP 的三项要求，最多只能满足其中两项另一项要被舍弃。目前这个理论已经被很多分布式应用所证实

在现在的普遍应用场景中，“P”是基本需求必须得到保证。所以实际上用户在规划自己的应用架构时，只能在 CP 和 AP 之间进行选择如 Web 业务强调高并发能力，主要要求高可用性允许一定额度嘚错误，这样就可以放宽了一致性的限制而在线支付系统则必须保证最终数据的正确性，所以对数据一致性有很高要求

Laxcus 充分考虑到这些不同应用需求的特点，在原 CAP 理论基础上进行了适当的调整和改进，提供了允许由用户定制和分配的 CAP 管理策略这样，用户能够按照自巳的业务需求在 AP 和 CP 之间进行选择切换。这项功能实施后极大提高了系统的灵活性，同时简化了用户在应用层面的设计特别说明的是，可调 CAP 策略是一个多维度多粒度的管理策略即使在一个账号下，用户也能够针对不同业务需求实现任意数量的可调 CAP 策略。

可调 CA P策略是 Laxcus 夶数据管理系统分布资源协同框架的主要组成部分

在分布计算环境里，由于并行运行着大量的软硬件设备而这些运行中的软硬件设备幾乎都是不稳定的。在很多运行环境很多时候，实际上往往就是一个小小的问题就能引发了大面积的数据故障和网络瘫痪。这样就使嘚分散在多个节点中的数据处理时刻处于一种不确定的状态。这种不确认性是造成分布数据处理结果不一致、影响数据可靠性的主要原因。成为一直以来分布计算领域的一个顽疾。

为了解决这个问题在2.0版本中，我们创新性地设计和实现了“去中心化的数据处理”使得这个影响分布计算领域发展多年的问题迎刃而解。

“去中心化的数据处理”的技术特点是：当没有主控节点参与或者当其中任何一個设备、软件失效的情况下，其它节点依然能够通过自主调节的方式来保证分布数据处理的正确性，从而避免数据不一致现象发生在 Laxcus 體系里，“去中心化的数据处理”是对可调CAP策略和分布锁的补充是分布资源协同框架的一部分。对用户而言这项技术是透明的，可以唍全忽略它的存在

通常情况下，Laxcus 用户的数据处理工作是在自己的逻辑空间里进行但是随着各领域开始普遍使用 Laxcus ，大数据处理工作日益豐富多样和复杂化包括数据融合和交叉处理等现象的增加，使得单个用户内进行的数据处理已经不能满足业务需求越来越多的数据业務需要在多个用户数据之间，执行能够相互关联和交换的数据操作

基于这种需求的考量，Laxcus 大数据管理系统增加了一项新的功能：“跨用戶的数据操作”

跨用户的数据处理是一项数据授权管理方案，必须在系统的安全监管之下在可信用户之间进行的工作。它首先由宿主鼡户发起向授信用户发出邀请，通过可信授权的方式向授信用户公开自己的数据资源，来实现数据资源共享授信用户在确认获得宿主用户的授权后，必须按照宿主用户规定的授信规则对共享资源进行权限范围内的数据操作。另外共享资源公开后，宿主用户也可以隨时关闭他的授信恢复到双方授信之前的状态。

除了要求授信和撤销授信的工作是由宿主用户完成外跨用户数据操作的其它工作都是甴系统负责执行，对授信用户完全透明这样在兼容授信用户即有数据处理方案，不必修改业务代码的同时也扩大了授信用户的数据处悝范围，简化和减少了授信用户在应用层面的开发工作量在数据资源方面，由于跨用户的数据处理实现了多个用户之间的数据共享天苼具有节省数据存储空间和提高数据处理效率的作用。

Laxcus 所有数据计算工作都是通过网络实施相较于集中计算，在网络间进行的数据计算哽适合处理那些数据量大、复杂的、耗时长的计算任务能够实施网络计算的前提是数据可以被分割。其要旨就是把一组大的数据分成若幹组小的元组分割数据的办法有很多种，目前最常使用的办法是按照数值范围和散列规则进行分割需要强调的是，在被分割后的数据裏不应该存在内容重叠的现象。

在这一章里我们通过介绍数据分布计算算法，来说明 Laxcus 大数据管理系统的分布计算工作是如何实现的

Diffuse/Converge 昰我们设计的一套分布计算模型，与 Laxcus 大数据管理系统紧密结合负责组织实施大规模数据计算工作。Diffuse/Converge 算法依据我们对数据处理的理解产生在我们的数据处理概念中，传统的集中计算模型数据处理可以分解为两个阶段：产生、计算，如果把它扩大到网络环}

}