你的位置:首页 > 数据库

[数据库]Laxcus大数据管理系统2.0(12)


第十章 运行

  本章将介绍一些Laxcus集群基本运行、使用情况,结合图片和表格表示。地点是我们的大数据实验室,使用我们的实验集群。数据来自于我们的合作伙伴,软件平台混合了Windows和Fedora Linux两个操作系统,硬件因为一直以来的测试需要,显得参差不齐,从10年前的旧机器到今天最新的设备都有。这样的环境虽然不足以反映目前商业运营的集群现实状况,但是在反映Laxcus集群和集群基础硬件性能参数时,仍然具有一定的代表性。为了更好反映测试结果,我们将多用户多集群的Laxcus部署成单用户单集群环境(一个主域集群加一个子域集群和一个注册用户)。网络传输都按照默认规定,采取了流量控制措施。

10.1 配置

  首先介绍这个实验集群的基本情况,我们把配置分成两部分:硬件的计算机、软件的节点,用两张表说明,可以从中一窥集群的端倪。因为Data/Work节点要执行数据存储和计算工作,所以大量计算机分配给它们。本次测试没有数据构造业务,Build节点就只保留一台做为冗余。在这个集群里,因为每台计算机的硬件配置很不相同,数据也不是平均分布的,这直接导致Data节点产生的数据量不一致,和Work节点的计算时间长短不一,Call节点做为它们的协调者,会尽量去平衡这种不平均现象。其它不怎么产生计算压力的节点就用一台,或者合用一台计算机。

 

部件

类型数据

CPU

Pentium III、Pentium IV、CORE、ATOM、ARM32

内存

512M - 4G

硬盘

20G - 2TB,IDE/STTA/SSD,Data、Work、Build、Call节点会部署多个硬盘

网卡

100M/1G

带宽

1G

表10.1.1 硬件情况

节点

说明

Top

1个,与HOME/TASK/AID合用1台物理计算机

Home

1个,与Top共享使用

Task

1个,与Top共享使用

Aid

1个,与Top共享使用

Log

1个,独立使用1台物理计算机

Call

3个,部署在3台物理计算机上

Data

24个,部署在24台物理计算机上

Work

20个,部署在20台物理计算机上

Build

3个,部署在3台物理计算机上

Watch

2个,共享1台物理计算机,分别监视TOP/HOME两个集群

Front

8个,部署在2台物理计算机上。

表10.1.2 节点情况

10.2 管理

  管理是Laxcus集群一项基础服务。它包含两个部分:管理员对集群的管理,用户对所拥有数据的管理。集群的管理,由管理员通过Watch站点实施。用户对自己数据的管理,由用户通过Front节点实施。所有管理工作都是通过命令实施,其中有些命令可以被管理员和用户共用。另外为减少管理员的工作负担,部分由管理员实施的工作也可以指定某个用户代为处理,如对用户账号授权这样的管理工作。但是大部分命令都有它们明确的操作归属,不允许随意使用,即使被错误发出,也不会被集群接受。

 

图10.2.1 拥有管理员权限的注册用户,对另一个注册用户授权

 

图10.2.2 显示数据块的分布节点和数据量 (管理员操作)

 

图10.2.3 显示用户分布任务组件的分布节点和全部组件命名(管理员操作)

 

图10.2.4 显示全部在线用户数(管理员操作)

 

图10.2.5 加载数据块索引到内存(用户操作,提高检索速度)

 

图10.2.6 加载数据块到内存(用户操作,实现内存计算)

 

图10.2.7 统计数据库

(共用,管理员返回下属表名、节点地址、数据块数、尺寸,用户没有节点地址)

 

 

图10.2.8 统计数据表

(共用,管理员返回节点地址、数据块数、尺寸,用户没有节点地址)

10.3 元数据

  在Laxcus集群运行过程中,元数据是一项很重要的参考指标,它大体反映了每一个节点的当前的负载和运行情况。如果把这些元数据综合起来,可以进一步获得一个集群的运行信息。或者按照不同要求,对不同的元数据进行分类、对照、聚合、比较,又可以反映出集群某一局部的运行状态。

  Laxcus集群的元数据只对集群管理员开放,用户不具备这项权利。在实际的集群管理维护中,管理员通过Watch节点向集群发出命令来获得元数据,使管理员可以快速了解集群运行情况,是管理员工作的重要辅助手段。通过元数据管理员可以很快检查、发现集群可能存在的运行问题,或者在实施一项工作前,通过元数据获得必要的预判,再决定接下来的工作是否处理和处理方向。

  目前元数据都是以文字和表格的形式显示出来,下一步将提供图表化和图像化的显示方案,这样管理员将获得更丰富和直接的显示效果。这项改进工作已经在项目日程中。

 

图10.3.1 显示全部运行节点元数据

 

图10.3.2 显示用户数据产生的全部元数据

 

图10.3.3 显示数据库元数据和它的部署节点、数据量

 

图10.3.4 显示数据表元数据和它的部署节点、数据量

 

节点类型

节点数量

元数据尺寸

关联数据尺寸

Top

1

0.372M

-

Home

1

0.692M

-

Task

1

1.731M

-

Aid

1

0.053M

-

Watch

1

1.528M

-

Log

1

0.339M

-

Data

24

5.712M - 28.729M

623.182GB - 4.851TB

Work

20

0.131M - 0.257M

-

Build

1

0.180M

-

Call

3

1.361M - 6.749M

8.302TB - 47.276TB

表10.3.1 测试集群元数据列表

10.4 数据操作

  在Laxcus大数据系统中,数据操作被归为用户使用部分。现在主要通过Conduct 、Establish两个命令来实现大规模数据处理。另外考虑到用户的使用习惯,我们还完整兼容了SQL四个主要命令:Insert、Select、Delete、Update。在实际应用中,由于直接操作Select会产生巨量数据,给Front节点带来雪崩现象,造成Front节点瘫痪,所以极少被直接使用,而是把它嵌入到Conduct、Establish命令中组合使用。

  Front节点是用户操作数据的入口。在很多运营环境中,大多数时候,它被用户做为驱动程序,嵌入到其它软件中使用,其中使用最多的SQL命令是Insert。图形界面和字符界面的Front节点起着辅助作用,主要是用在用户的数据管理上。

 

图10.4.1 检索数据

10.5 Sort Benchmark测试

  我们设计了一个Sort Benchmark测试,通过一个分布环境下的数据排序工作,追踪数据的产生、写入、读取、传输、计算这一系列执行流程。在考察一个集群的数据处理能力的同时,也对集群中的CPU、硬盘、内存、网络设备等主要硬件部件进行性能考核。测试使用一套分布任务组件展开,组件名称是“SortBenchmark”。按照Laxcus大数据系统要求,这个命名在整个主域集群是唯一的,现在已经检查通过,并且发布到集群上。SortBenchmark基于Diffuse/Converge算法,对应操作命令是Conduct。为了防止多并发竞用影响观察效果,集群里只运行一个任务。我们用一个Front节点发送命令,它会把命令先发送给Aid节点,再转发到其中一个Call节点上。这个Call节点会根据命令的参数,检查和分配后续数据处理工作,并监管整个工作直到完成。Front节点将等待Call节点的反馈结果,然后撤销Aid节点上的记录,并把测试数据打印了计算机屏幕上。

10.5.1 排序测试

  如图10.5.1.1所示,测试从Front节点开始,图形窗口上,Conduct命令中的关键字被高亮显示。其中"sites"表示要求的节点数,"writeto"表示测试报告被写入的本机磁盘文件。"from、to、put"都是Conduct命令的阶段类型关键字,其它是自定义参数关键字,此次排序操作被要求按照升序排序,中间数据写入硬盘,SortBenchmark默认产生的随机数是64位长整型long。

  整个命令的表述是:SortBenchmark组件要求产生2000M的随机数排序,分给20个Data.From阶段任务去执行。每个Data.From阶段任务负责产生100M的随机数,随机数将按照Work.To阶段任务的20个节点数要求,把100M数据切割成20个5M数据,每个5M数据会有一个对应的“模”值。之后把数据写入硬盘,并把20个5M的数据映像成一组元数据,返回给Call节点。Call节点将对20个Data节点的元数据进行平衡计算,通过拆分重组后,对应Work.To的20个节点数,产生20组新的元数据(这些元数据中指明了Data节点地址和数据位置),分配给Work节点。如果所有Data.From阶段任务产生的随机数是完全平均的(这是理想状态,现实中不会有绝对的平均),那么每个Work.To阶段任务,将启动20个连接,去20个Data.From阶段任务中,拿走其中一个5M数据,并把20个5M数据在本地内存重新合并成100M的数据。这时,按照Call节点给每个Work.To的编号排列,每个Work.To阶段任务中保存的随机数,它们之间已经形成链接关系(当前Work.To阶段任务保存的最后一个排序数字,总比下个任务第一个排序数字大)。此时再对100M数据进行升序排序,就产生了最后的计算结果。

  出于对Front节点计算机性能考虑,2000M的数据量实在太大,接收下来要花很长一段时间,这将影响到统计总计算时间,况且也没有必要接收这些数据,所以在Work.To排序后,数据将丢弃,只返回一个排序测试报告(实际是SortBenchmark自定义自解释的元数据)给Front节点。

  图10.5.1.1是基于硬盘的排序,Data.From将随机数据生成后,写入到硬盘,然后在Work.To请求下,又从硬盘读出。我们前面多次提到过,硬盘是数据处理过程中的最大瓶颈,会消耗很多输入输出时间,所以在图10.5.1.2中,我们调用7.8节所提的中数据数据写入接口(MidWriter),每个Data.From存储100M数据的位置,由默认的硬盘改为内存,省略了写/读硬盘过程,这样SortBenchmark整个处理流程不再接触硬盘,成为一次流式排序操作,排序结果明显比基于硬盘的排序方式快了很多。

 

图10.5.1.1 基于硬盘的Sort Benchmark排序

 

图10.5.1.2 基于内存的Sort Benchmark排序

 

节点

节点工作说明

节点数

连接数

数据量

平均单位量

最大用时(毫秒)

最小用时(毫秒)

平均用时(毫秒)

Data

产生随机数

20

-

100M

5M

3862

1351

1703

数据写入硬盘

20

-

100M

5M

1538

327

1021

从硬盘读数据

20

-

100M

5M

1095

177

692

Call

平均分配数据

1

-

-

-

1

-

-

Work

网络传输

20

20

100M

5M

214

196

202

排序

20

-

100M

-

23724

12731

16198

Front

执行和等待

1

1

2000M

-

30771

-

-

表10.5.1.1 基于硬盘的Sort Benchmark排序

节点

节点工作说明

节点数

连接数

数据量

平均单位量

最大用时(毫秒)

最小用时(毫秒)

平均用时(毫秒)

Data

产生随机数

20

-

100M

5M

3831

1369

1707

数据写入硬盘

-

-

-

-

-

-

-

从硬盘读数据

-

-

-

-

-

-

-

Call

平均分配数据

1

-

-

-

0

-

-

Work

网络传输

20

20

100M

5M

229

193

205

排序

20

-

100M

-

24061 

12577

16430

Front

执行和等待

1

1

2000M

-

28527

-

-

表10.5.1.2 基于内存的Sort Benchmark排序

10.5.2 排序分析

  从上述两组对比测试数据可以看出,数据的产生、传输、排序阶段,它们的平均处理时间是接近的。但是同一阶段的并行任务之间,它们的处理时间差距则很大,这是由于硬件配置不一致所造成。这种最快和最慢之间的差距,是导致数据排序木桶短板现象的直接原因。造成下一阶段的等待时间,由上一阶段的最慢那个线程决定,如此迭代下去,将严重影响整体排序处理效果。这是目前很多大数据处理普遍存在的现象。所以在运营的集群环境中,负责数据处理工作同一类型的节点,如果能够使用相同的硬件配置,将有效减少这种拖滞问题。

  为了达到快速的数据处理效果,把存储中间数据的位置,从硬盘改为内存,这是流式处理的基本原理。这种方案带的好处就是数据处理速度确实加快了,但是缺点也很明显:提供云计算或者集群服务的运营商要采购更多内存,这样就增加了设备投入成本,对运营商来说是一件“奢侈”的服务方案。另外根据我们的市场调查,目前需要快速数据处理业务方案的用户比例并不高。

10.5.3 排序优化

  上述排序仍然存在一个问题:100M的数据量,对于一台计算机来说,计算量实在不小,这从Work.To阶段任务的排序时间就可以看出。如果能让Work.To把每次的数据量变得更小一些,分成多个批次排序,这样总数据量没有变,但是总计算时间会相应缩短。再采用衔接的办法,把数据按照“模”方式串联起,会得到和上述一样的排序结果。

  这个测试很容易,有兴趣的读者可以在自己的计算机上尝试一下,看看1个10M的数据排序时间,和10个1M数据排序的时间,它们有多少差别。

  图10.5.3.1展示了这样一个改进,在Conduct命令的From阶段增加一个“next_split(int)=5”自定义参数。这样就把在原来每个5M基础上的数据,再分成5份,实际上形成了100个1M的数据单元。Data.From每次产生的随机数,被分到100个1M单元中的一个,返回的模值,也由原来100/20的关系,变成100/100的关系。在Work.To阶段,相应需要启动100个连接,每个连接拿加加属于自己的一块数据,再按照20*1M,分成5个20M的数据,每个20M的数据为一个单位进行排序,5次排序后,再按照它们的模值串联起来,形成最后的排序结果。

  如果希望将总处理时间进一步提高,“next_split(int)=5”这个参数还可以再增加,使得Work.To单次排序数据量更小,然后再结合“模”衔接,得到更快的排序效果。另外现在的计算机已经普遍使用多核CPU,这样在排序时,同一时间可以并发多个线程,将使得总排序时间获得进一步改善。

  需要说明一点,这里忽略了socket问题。因为本次排序,集群中只有一个任务,单机并发100个连接和产生的流量尚在可接受范围内,但是在实际的运营环境中,这种并发连接可能会产生很大的数据流量,按照Laxcus流量控制机制的规定,超过环境条件许可的连接和流量将受到限制,所以实际效果可能并不如意,这一点用户应该注意。

 

图10.5.3.1 基于内存的细分排序