v2.6

文档

Laxcus大数据管理系统

第一章 基础概述

第二章 数据组织

第三章 数据存储

第四章 数据计算

第五章 数据构建

第六章 网络通讯

第七章 网络通讯

第八章 安全

第九章 容错

第十章 运行

总结

后记

参考文献

  • 内容

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

     如图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.10节所提的中数据数据写入接口(MidWriter),每个Data.From存储100M数据的位置,由默认的硬盘改为内存,省略了写/读硬盘过程,这样SortBenchmark整个处理流程不再接触硬盘,成为一次流式排序操作,排序结果明显比基于硬盘的排序方式快了很多。

回到顶部

联系方式

  • 服务电话 15210289253
  • 联系邮箱 laxcus@163.com
  • 版权所有 Laxcus大数据实验室    京ICP备17069115号

更多资讯请关注官方公众号