LAXCUS 大数据集群操作系统:一个分布式分时共享 E 级系统软件(五)

用户头像
陈泽云
关注
发布于: 2020 年 10 月 26 日
LAXCUS 大数据集群操作系统:一个分布式分时共享 E 级系统软件(五)

第四章数据组织

在数据的组织结构设计上,Laxcus大数据集群操作系统严格遵循数据和数据描述分离的原则,这个理念与关系数据库完全一致。在此基础上,为了保证大规模数据存取和计算的需要,采用了大量新的数据处理技术。同时出于兼容用户使用习惯和简化数据处理的需要,继续沿用了一些关系数据库的设计和定义,其中不乏对SQL做适量的修订。在这些变化中,核心仍然是以关系代数的理念去处理数据,以及类自然语言风格的数据描述。在设计索引矩阵时,表象仍然是关系查询,但是隐性融合了动态关系、图论、键值对技术。所以用户在使用体验上,与关系数据库相比,并不会感觉到有太多的差异。

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

4.1基础

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

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



4.2数据类型

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



4.3全局数据库

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

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

4.4跨数据库操作

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

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

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

4.5固定表

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

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

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

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





4.6取消视图

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

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

4.7带Where子句的Select检索

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

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

4.8数组列的压缩和加密

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

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

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

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

4.9分布锁和事务 

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

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

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

1.事务基于用户账号,非关联的数据处理之间不发生事务联系。

2.数据处理都默认执行事务流程。

3.事务从高到低,分成:账号、数据库、表、行四个级别,上一级覆盖下一级的全部操作。

4.事务操作支持排它和共享两种模式。

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

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

1.所有"读"事务都可以共享存在。

2.如果队列中都是“读”事务,后续一个“写”事务可以获得批准。

3.如果队列中有“写”事务,后续一个“写”事务只要不与它们存在资源冲突,就可以获得批准,否则被拒绝挂起。

4.为了进一步提高数据库事务和表事务的并发效率,在它们之间有一个“数据库名称”比较。当这样的两个"写“事务发生”数据库名称“冲突时,后续“写”事务被挂起,即同名互斥。

5.如果一个事务同时存在“读写”两种状态时,将按照“写”事务规则处理。



4.10可调CAP策略

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

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

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

可调CAP策略是Laxcus大数据集群操作系统分布资源协同框架的主要组成部分。

4.11去中心化的数据处理

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

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

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

4.12跨用户的数据操作

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

基于这种需求的考量,Laxcus大数据集群操作系统增加了一项新的功能:“跨用户的数据操作”。

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

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



发布于: 2020 年 10 月 26 日 阅读数: 16
用户头像

陈泽云

关注

陈泽云 2020.10.09 加入

LAXCUS人工智能技术实验室系统工作师,八年分布系统研发经历,目前参与LAXCUS大数据集群操作系统的集群管理模块和小样本深度学习(DFL3)的开发工作.

评论

发布
暂无评论
LAXCUS 大数据集群操作系统:一个分布式分时共享 E 级系统软件(五)