标签：
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集群里，大量计算机被用来执行数据处理工作，管理节点做为集群的核心，起着监督和协调的作用。如果管理节点的工作内容过多或者复杂，势必将增加管理计算机的工作负荷，降低处理效率，延长处理时间，不能对下级节点的请求及时做出反馈，减弱对集群的监督和协调作用。在此前的几个运行环境，上述情况都分别发生过，是造成系统稳定性变差，影响集群正常运行的重要原因。所以，进一步分散管理节点的工作内容，减少计算开销，降低工作负荷，是提高集群稳定性的主要办法。“弱中心化”思想即由此衍生而来。
鉴于此前的教训，通过对1.x版本的运行统计和评估，在2.0版本中，管理节点的工作被压缩到只有两项内容：监听节点心跳、记录节点元数据。这两项工作由子节点上传，管理节点负责汇总和分析，网络通信量极少，内容简单，计算量非常少，并且只有计算内存里存储和执行，不存在计算瓶颈和计算压力，管理节点的工作负荷因此大幅度减少，从而提高了集群的稳定性。目前因为管理节点问题造成的故障已经基本消失。
Laxcus被设计为松耦合架构，与之对应的，我们提出了“系统群”（group of systems）的概念。“系统群”可以理解为：在松耦合架构下为适应复杂分布运行环境而组织起来的工作模块。这样，在松耦合架构和系统群之下，所有运行中的数据处理业务被视为服务，可以自由地加入和退出，分别以离散、独立、弱依赖的形态存在。从人机交互界面开始，用户的操作请求通过语句化的操作命令，被解释成各种数据处理业务，业务的内容和含义由通信双方决定。集群内的数据处理，采取按需分配的原则，根据不同的属性分别建立，并遵循查找、发现、关联、绑定、执行、撤销的流程运行。集群内的数据管理业务，也遵循同样的流程，并且与数据处理业务保持非关联和独立性。
由于松耦合和系统群的这些特点，使Laxcus在应对越来越复杂的数据业务时，仍然具有极好的灵活性和敏捷性。能够在不影响既有业务的情况下，快速建立新的业务。在保持强大处理能力的同时，还有足够的裕度来满足未来扩展的需要。另外，松耦合和系统群也降低Laxcus系统设计的复杂性和风险，对开发这种复杂的大型软件系统助益甚多。
命令驱动是松耦合架构下的一个“系统群”子集，Laxcus数据处理都采用命令驱动的方式进行。系统运行过程中，当收到用户或者系统自身发出的任务请求时，这些请求被转换为相应的命令。命令根据任务提出的处理需求，结合集群环境做出解释，分散作用到集群的不同节点上，执行数据处理操作。在表现形式上，命令通过网络在各节点之间传递，形成一条前后关联的命令链。在执行过程中，每道命令链都是独立的，严格按照预定的工作轨迹运行。当它们出现在计算机里的时候，实质是一个个对内存占用很小的“程序片段”，而命令链之间处于完全隔离的状态。这种“被隔离”和内存占用小的特点使它们之间没有干扰，同时又允许大量存在，即使某一条命令链在运行过程中发生故障，产生的影响也只限于这个命令链本身，不会出现波及效应。并且这种方式对排查故障原因和故障源头十分方便。尤其重要的是，因为命令链的独立性，在编写代码的时候，每条命令链可以按照其自身的需求，被设计得非常细致和有针对性。这些特点，使它在保证系统稳定运行的过程中，起到重要的作用。
命令被用来执行一道道具体的数据处理工作，分配、管理、监督这些命令运行的是“Invoke/Produce”任务调度模型。这是一种集成了多种软硬件控制功能的委托管理模型，能够对计算机运行过程中的各种资源，包括网络流量、适配器、数据、CPU、内存、硬盘，进行实时的监督和随机的调节。在命令执行过程中，“Invoke/Produce”将持续检查它们的运行状态和对资源的使用情况，当任何一项硬件资源的使用比率达到峰值或者接近临界点时，危机管理机制就被启动，依次对影响最大的执行任务采取限制措施，包括暂停或者休眠这样的处理，以及要求它们释放硬件资源等手段，来达到降低系统载荷的目的。而所有这一切工作的目的，都以保障系统稳定运行为核心，尽可能多地通过软硬件的结合，为每一道命令在它的运行过程中，实现数据处理效率的最大化。
我们已经部署了多个Laxcus系统，这些系统在运营过程中，我们通常不限制用户发出的命令数量，这种忽略经常导致集群的某个节点涌现大量的计算任务，发生超载现象。例如在此前的一次例行检测时，就发现有一个计算节点并行着8000多个计算任务。面对如此庞大的计算压力，如果任由这些现象持续下去而不加以控制，计算机宕机现象随时可能发生。
在1.x版本中，负载控制是由管理节点来监视和协调控制的。在实地运行中显示，这种处理方式虽然达到了协同节点工作和平衡集群负载的目的，但是也存在很多隐忧，主要体现以下几个方面：
1.每个节点的负载情况都被反馈到管理节点上，增加了管理节点的数据存储量和计算量，不利于管理节点的弱中心化管理。
2. 负载的平衡和分配调度依赖于网络通信，当发生大面积超载时，往往也意味着网络中存在大量数据传输，这时的通信成功率会直线下降。实际上为了保证通信成功，就需要进一步加大了管理节点通信量和工作负担，这种情况对管理节点稳定运行有巨大影响。
3. 负载控制要求实时处理，如果管理节点汇聚了大量任务请求，很难做到实时处理，延时将不可避免发生。同时下属的节点收不到指令，超载会持续下去，宕机的可能性大幅增加。
4. 整套过载处理机制过于复杂，管理成本颇高，不符合简单化的设计原则。
鉴于以上问题，2.0版本的负载控制，取消了以管理节点为中心的协同处理方式，改为分散到每个节点的自适应调节。这样，当节点在执行计算任务的时候，也监视自己的运行负载。如果发生超载现象，可以立即做出反应，停止分配新的计算任务，或者根据运行任务的权重和资源占用比率，有选择地要求某些任务进入暂停、休眠状态，以达到即时发现即时处理，降低运行负载的目的。原来管理节点承担的平衡运行负载的工作，交给网关节点来协调解决。新的负载处理方式避免了上述1.x版本的问题，同时简化了负载管理的处理流程，提高了运行系统的稳定性。
在我们试验室的集群中，由于固态硬盘（SSD）使用成本居高不下，承担数据存储工作的仍然是传统的机械硬盘（温彻斯特硬盘）。根据我们的调查，这种情况在很多运营的集群中也同样存在。另外我们对多个集群上的数据应用追踪调查也显示，由于硬盘的处理效率远远滞后于CPU和内存，整个数据处理过程中，75%-90%的时间被消耗在硬盘存取上，即使是固态硬盘，也仅比机械硬盘提高一个量级，仍然远低于CPU和内存的处理能力。这种硬件之间的不匹配，导致硬盘成为大数据处理过程中的最主要瓶颈。所以，改善硬盘的处理效率，对提高大数据处理效率有立竿见影的效果，但是机械硬盘工作的特点，又使它与CPU、内存这些电子部件在运行效率上存在着巨大的差异。在这种条件下，尽可能多地根据硬盘自身的特点，发挥出它的最大效能，成为解决问题的重要办法。
与此同时，我们对许多用户的数据应用追踪中也发现，大数据处理过程中，96%发生在检索操作上，3%是添加数据，删除和更新合计只占不到1%的比例。这个现象促使我们对数据存储产生了不同以往的定位和思路，将数据存储设计的重点围绕着检索展开，并据此制定了以下的执行策略：首先，为保证大数量高频度的检索操作，结合到计算机内的CPU、内存、硬盘各主要工作部件的性能，在保证数据的持续吞吐性能上，流式处理效率最高。并行的数据写入在进入存储层面时，汇流为串行模式。检索操作的最终目标是硬盘，硬盘检索受制于硬盘物理特性的影响，在数据计算过程中，严重拖滞了整体性能的发挥，为提高数据处理性能，需要在检索前对数据进行优化，如关联和聚凑，同时提供一批优化算法给用户，使用户可以按照自己的意愿去组织和检索数据。删除不改变数据本身，只对数据做无效记录。数据更新分解为删除和添加两步操作，目的在于简化和内聚数据处理流程，同时避免发生多次硬盘读写现象。
上述处理虽然改善了存取性能，但是不可能从根本改变硬盘慢的特点。若要使性能获得根本性的提升，必须跳过硬盘这个瓶颈，所以在2.0版本中增加了一套新的数据处理方案：让内存代替硬盘，数据在网络、内存、CPU之间流动，以接近CPU的速度运行。这种内存处理方案解决了硬盘存取慢的问题，使数据处理性能获得巨大的提升。根据我们的测试评估结果，这个提升幅度在2个量级左右。在实际应用中，用户如果有实时性的数据处理需求，且有足够的内存做保证时，内存处理方案无疑是最佳的选择。
以上只是针对硬盘存取做的优化，如果根据数据业务不同的需求特点，提供有针对性的数据存储方案，数据处理效率还能够获得进一步的提升。
达成这个目标的办法是实现两套数据存储方案：以“行”为数据单元的行存储模型（NSM），和以“列”为数据单元的列存储模型（DSM）。前者将数据处理的重点放在“行”上，每次操作的假定对象是一行中的多列数据，这方面有代表性的就是目前普遍使用的数据库业务。后者的数据处理重点是“列”，其特点是可以对单一数据进行大批量的读取操作，比如当前火热的互联网数据和数据仓库应用。前者的数据操作量普遍不多，而后者的数据操作量则非常巨大。在使用时，用户可以根据自己的业务需求任意选择。根据我们对现有用户的追踪调查，在他们的数据应用中，普遍是采取混合使用两种存储模型的办法来提高数据存取效率的。
由于硬盘本身物理性能与内存、CPU之间存在的巨大差异，在数据处理过程中，实际上无论给硬盘做怎么样的优化设计，都只能减少而不能避免这种差异所造成的影响。要想完全突破硬盘性能滞后所造成的数据处理效率低下的问题，唯一的解决办法就是跳过硬盘这道瓶颈，只使用内存做数据存取，让数据象“水流”一样，在集群的各节点的内存、CPU之间流动，使它们接近匹配的速率，进行传递、转换、处理。这就是流式处理的由来。
在Laxcus 1.x版本中，流式处理是一项内测功能。在版本发布后，收到越来越多用户的快速处理要求，所以重新考虑后，在原来流式处理基础上，经过调整修改，现在在2.0版本，把它正式公布出来。兼顾到原来的数据处理方案，流式处理要求用户在使用前显示指定，系统会根据当时每台计算机的资源使用情况，有选择地进行分配。这样，当用户要求流式处理的时候，数据处理过程将忽略掉硬盘，完全在集群的网络、内存、CPU之间进行。
流式处理主要针对一些快速检索和计算业务（数据存储操作仍然要写入硬盘，不在此列），典型如在线分析 、实时计算这类业务。根据我们对多种流式处理的实地测试显示，相较于基于硬盘的数据处理，基于内存的流式处理可带来数十倍的效率提升。这种巨大的提升，将使一些用户的数据处理业务发生根本性的改变。
数据即时存取即通常所称的“所存即所得”，这是衡量大数据系统能否支持实时处理的关键性标志。其表现就是当数据保存到数据系统的分布存储环境后，能够立即生效并且可以使用，而不是之后的某一个时段才能生效和使用。数据即时存取在Laxcus 0.1版本已经实现，又分别在1.0和2.0版本中进行优化，性能获得进一步提升。由于实现了即时存取，可以保证对整个主域集群数据执行无遗漏的检索，使Laxcus达到通常关系数据库才具有的响应能力。即时存取非常重要，尤其是商业用户，是他们许多数据业务必须满足的一项功能。
现在的大数据应用已经不局限于互联网，尤其是随着商业和科研行业的加入，开始呈现出需求多样化的趋势。其中有很多商业处理业务，为了防止资源竞用造成的数据错误，越来越需要获得事务支持。顺应这一发展潮流，经过我们仔细分析研究和设计，从Laxcus 2.0版本开始，提供事务处理能力。
Laxcus事务保持了数据库对事务定义的基本原貌，即所有数据处理只能有两种结果：成功或者失败。如果失败，数据将回滚到它的开始状态。在此基础上，结合大数据运行环境，避免因为事务造成数据处理效率下降，Laxcus事务具有以下特点：
1. 事务基于账号。
2. 数据处理默认执行事务流程。
3. 事务分成用户、数据库、表三种类型。
4. 事务操作分为排它和共享两种。
更多关于事务的说明请见第二章的介绍。
在Laxcus体系里，命名是一组由文字和数字组成的有意义的字符串，是网络设备、分布目录、任务接口、数据资源等各种实体资源抽象化的表示，被应用在所有与数据处理有关环节上。通过命名，系统在运行过程中，屏蔽了数据处理环节，与网络地址、数据定位、数据检索有关的工作，简化了分布计算方法和计算流程，使复杂的网络运行环境变得简单，同时减少和避免了因为网络拓扑和数据分散可能导致的错误和漏洞。命名只在系统运行过程中产生，被存储在内存里，在节点之间分发，可能随时间和节点发生变化。每个命名在系统中都是唯一的，不允许出现重叠现象。因为命名只用于系统内部环境，所以它对用户是透明的，用户不必在意，也无需了解它的使用、执行情况。
设计命名，对简化系统架构设计，提高系统稳定性、保障系统安全有重要作用。
在当今社会，因为信息产业的快速发展和信息安全管理的相对滞后，由网络安全和数据安全引发的一系列重大事件可谓是层出不穷。当前大数据正在快速融入现代社会，如何保护好这些数据，保证数据只被它的持有人使用，而不会受到非法的监视和窃取，就益发显得重要了。基于这样的理念，又鉴于集群的复杂运行环境，如果只是做局部的改善，那么将无法满足整体的安全需要，我们从Laxcus 2.0版本开始，纳入了全体系的安全管理设计和技术实现。它从用户操作界面开始，一直延伸到数据存取层面，贯穿系统的每一个环节，形成一道完整的安全屏障。在这道安全屏障后面，用户执行安全的数据处理成为可能。
不过任何事情都有它的两面性。换一个角度实事求是地说，我们虽然实现了全体系的安全管理设计，但是这个安全管理的取得是以牺牲集群总体计算性能为代价的。实际上，现在IT行业所有高安全度的技术实现背后，都存在着一个使用CPU进行密集计算的处理过程。尤其对于也是数据密集和计算密集的大数据来说，会严重影响到CPU处理数据业务的能力，增加业务处理时间。考虑到这样的情况，我们在进行安全设计时，对系统的不同环节进行了不同的安全管理规划，设置了不同的安全等级，提供了不同的安全管理策略，其中大部分的安全管理工作，我们都以配置文件的形式提供给集群管理者，由他们根据自己业务需求做出取舍。但是不管怎么样，事实是，这套安全措施启动后，无论是做为私有云还是公有云部署时，Laxcus都已经可以承担了。
Laxcus虽然提供了一个分布的数据处理环境，但是大量个性化、与用户业务有关的数据处理工作仍然需要用户来完成。要达成这个目标，就需要程序员来编写代码，然后放到计算机集群上去运行。分布任务组件就是为完成这个工作而设计的。
在1.x版本中，分布任务组件只是一个集成了中间件和分布计算技术，提供了热发布能力，在Laxcus架构下运行的模块。在2.0版本中，我们对分布任务组件进行了大规模的调整修缮，重新定义了操作规范和API接口，增加了开发、部署、运行、管理等一系列功能，并且从原来的框架下剥离出来，已经独立发展成为一个完整的子系统，实现了全方位的数据处理和管理服务。
从设计上来说，Laxcus 2.0版本的分布任务组件确实比1.x版本复杂了很多，但是对程序员来说则变得简单了。在新的框架下，原来需要由程序员负责的网络通信、远程存取、分布操作等代码被全部屏蔽掉，归并到系统管理范围内。新架构只留下了数据输入输出接口给程序员，程序员可以不必再去考虑复杂的分布处理流程，只需要遵循开发规范，调用API接口，象操作本地方法一样，专注于自己的业务功能实现就可以了。通过本次对分布任务组件的简化修改完善，我们希望在减少程序员工作量和运行错误的同时，也能够为程序员快速开发和部署分布任务组件提供帮助。
出于简化数据处理过程、提高数据处理效率、使人机交互界面更加友好等原因，我们设计和开发了分布描述语言（Distributed Description Language）。这是一种专门针对大数据用户和集群管理者设计的类自然语句高阶语言，由许多命令组成。命令采用英文语句的语法风格，由使用者通过终端输入，也可以嵌入到驱动程序里使用，语法解释器负责解释，转换成计算机指令后，分发到集群上执行。分布描述语言的核心要旨是简单，我们希望能够借助分布描述语言，使用户在不必了解复杂的分布计算体系和计算流程的前提下，通过简单的交互语句，就能够获得管理和操纵大数据的能力。这种简化所带来的效果，对所有使用者，无论是集群管理者还是普通的大数据用户来说，都是非常重要的。同时，做为对大数据的补充，也为了方便用户从数据库转向大数据环境，我们在分布描述语言里面全面兼容SQL，包括SQL语言最主要的“INSERT、SELECT、DELETE、UPDATE”语句，以及JOIN语句、SQL函数、SQL数据类型、和其它的管理语句等。截止到目前，Laxcus分布描述语言仍在发展中，我们希望通过与大家的努力，共同完善它。
Laxcus大数据管理系统（3）- 第一章 基础概述 1.2 产品特点
标签：
原文地址：http://www.cnblogs.com/laxcus/p/5347813.html
