针对射电天文数据密集型科学运算的数据处理系统及方法

文档序号:30515438发布日期:2022-06-25 03:10阅读:138来源:国知局
1.本发明属于射电天文数据处理技术、数据密集型科学运算、大数据、高性能计算领域,具体涉及一种针对射电天文数据密集型科学运算的数据处理系统及方法。
背景技术
::2.随着先进的天文学观测设备的新建和运行,天文学界面临超大规模数据以及数据密集型科学运算的挑战。比如,全球合作的平方公里阵列(squarekilometrearray,简称ska)望远镜是国际天文界计划建造的最大的天文观测设备,是中国参加的天文学领域最大的国际合作大科学计划。ska将大量小口径天线汇聚实现综合孔径射电干涉成像,其总接收面积高达一平方公里,比目前最大射电望远镜灵敏度提高50倍、巡天速度提高10000倍,将为人类认知宇宙提供重大机遇。第一阶段(2021-2029年)完工后,ska的科学数据存储规模预计高达每年710petabyte(1pb=1024tb=超一百万gb),用于计算和存储这些科学数据的国际ska区域中心数据处理系统需拥有300pflops(每秒30亿亿次浮点数运算)算力的处理平台即ska区域中心,其中至少有20pflops的算力用于后续科学分析,各个国家的区域中心节点之间的数据交换需具有平均100gbps(100吉比特以太网)的稳定网速。预计到2029年,国际ska区域中心的数据总储存量高达2eb(1eb=1024pb)。现有超算平台均无法实现此规划目标,为此ska国际组织正在研发先进的数据处理平台。3.超大规模数据(pb量级)的分析处理是天文学界和计算机学界面临的共同挑战,大数据驱动的ska望远镜的成败也取决于其区域中心解决这一世界难题的能力。ska科学数据的处理过程是典型的数据密集型计算任务,其业务模式与基于计算密集型业务的传统超算有很大不同。4.传统超算平台的本地存储小,共享内存容量低,数据调用耗时长,系统构架单一,不适应对这种新兴的超大规模数据进行流水线式处理。此外,传统的超算平台在存储架构上严重依赖共享文件系统,在ska规模的数据处理上将会出现较高的系统故障率甚至系统瘫痪。ska项目的全球化多用户应用场景也将大大影响科学用户在传统的超算平台上的科研工作。5.在大数据和人工智能时代,计算密集型向数据密集型转化的趋势日益明显。如何快速处理数据结构复杂、数据类型多元化、多维度、大尺寸的海量数据,是以天文大数据为代表的数据密集型科学运算的核心关键。技术实现要素:6.本发明的目的在于提供一种针对射电天文数据密集型科学运算的数据处理系统及方法,以提高数据密集型科学运算的数据处理速度。7.为了实现上述目的,本发明提供一种针对射电天文数据密集型科学运算的数据处理系统,包括至少一个数据星座,每个数据星座为一个安装在一个机柜上或相邻的多个机柜上的且可扩展的综合数据单元,其均由一个可扩展的分布式的存储系统、混合异构的计算节点系统和网络系统组成;每个计算节点与其对应的超大容量内存和闪存类型的本地存储单元在物理上集成在一起,且所述存储系统由位于每个计算节点所对应的本地存储单元和由各个存储节点组成的分布式文件系统组成;每个数据星座拥有独立的分布式文件系统。8.混合异构的计算节点系统至少包含x86cpu架构、arm架构和x86cpu+gpu架构。9.当计算节点为arm架构时,其总访问带宽为80gb/s;当计算节点为cpu+gpu架构时,其访问带宽为2tb/s。10.每个计算节点的超大容量内存的总内存容量为1tb~2tb,每个计算节点的超大容量内存的总内存容量根据cpu的内核数相应调整,每个内核对应的内存容量不低于32gb。11.对于具备32个内核的计算节点,其总内存容量至少为1tb。12.所述本地存储单元采用nvmessd,所述存储节点采用hdd。13.所述分布式文件系统采用完全分布式的架构和全对称分布式架构。14.所所述的网络系统包括与所有计算节点和存储节点均相连的多个ib交换机,与所有计算节点、存储节点、后台存储节点、管理节点均相连的网络交换机,以及通过因特网与管理节点连接的多个用户登录节点。15.另一方面,本发明提供一种针对射电天文数据密集型科学运算的数据处理方法,包括:16.s0:提供根据上文所述的针对射电天文数据密集型科学运算的数据处理系统;17.s1:原始数据通过ib交换机送入当前的计算节点的超大容量内存,以作为超大内存缓存;18.s2:当前的计算节点处理任务,并判断得到的是中间数据还是最终数据;如果是中间数据,则继续执行步骤s3;如果是最终数据,则将最终数据被保存至计算节点的超大容量内存或本地存储单元,并通过ib交换机写回存储节点的分布式文件系统来保存,并结束流程;19.s3:当前的计算节点根据存储需求将得到的中间数据存入超大容量内存或闪存类型的本地存储单元,以作为超大内存缓存或闪存缓存;20.s4:与当前的计算节点不同架构类型的计算节点通过ib交换机读取当前的计算节点的超大内存缓存或ssdcache来进行计算节点之间的中间数据交互,随后作为新的当前的计算节点,回到步骤s2。1.本发明的针对射电天文数据密集型科学运算的数据处理系统应对天文大数据,提出“数据星座架构”,每个数据星座拥有独立的共享文件系统,既能够满足天文大数据计算和存储的需求,又能够大大减少全局文件系统(传统超算的架构设计)带来的影响。同时,这种设计理念能够对不同处理任务分配不同型号处理器的设备,按需定制高效利用本地存储和网络。2.本发明的针对射电天文数据密集型科学运算的数据处理系统针对天文大数据的超大数据量而设计,由物理上安装在一起的混合异构的计算节点系统、高性能存储系统和高速网络系统组成,采用数据星座架构,改变了传统超算中这三个系统各自独立的设计方案,能够根据计算任务的需求灵活分配资源,可由一个数据星座或者多个数据星座完成,满足多个科学数据处理流程、多类用户需求、不同计算规模和分布式任务等多种应用场景。(2)本发明的数据处理系统的单个节点上的大内存容量解决了处理单个大尺寸数据文件的难题,避免或减少了数据切割、数据移动和空置等待的时间成本。此外,大内存有能力让一些需要多次读取的文件长期驻留在内存中,被多个节点访问,从而大大减少了频繁读入和读出这些文件造成的时间消耗,加快了数据处理流程。(3)本发明的数据处理系统的混合异构计算架构通过将流程中的计算密集型、内存密集型和数据密集型任务合理分配到对应的计算设备,有效地解决了复杂的天文数据处理流程、多数据文件和高并行性的挑战,提高了整个集群的效率,有效节约了运行成本。(4)本发明的数据处理系统的包含sdd和hdd的多层级混合存储系统确保了高性能读写,可满足高性能计算、高数据i/o和多负载任务等广泛的应用需求。此外,分布式存储架构提供了高吞吐量、高并发和高扩展性的存储机制,确保在数据中心为满足不断增加的科学用户的需求而扩大规模时,性能仍能接近线性增长。(5)本发明的数据处理系统的为混合异构计算节点设计的高达200gbps的高速网络系统及其拓扑结构,连接计算、存储和管理设备,解决了数据密集型计算中最严重的数据i/o瓶颈问题,确保了节点内部和节点之间的数据交换顺畅,不仅降低了数据流的延迟,而且降低了网络流量导致的系统崩溃的风险。附图说明3.图1为根据本发明的一个实施例的针对射电天文数据密集型科学运算的数据处理系统的系统架构示意图。4.图2为根据本发明的一个实施例的针对射电天文数据密集型科学运算的数据处理系统的工作流程图。5.图3是根据本发明的一个实施例的针对射电天文数据密集型科学运算的数据处理系统的网络系统的连接示意图。6.图4是根据本发明的一个实施例的针对射电天文数据密集型科学运算的数据处理系统的工作流程图。7.图5是根据本发明的另一个实施例的针对射电天文数据密集型科学运算的数据处理系统的工作流程图。8.图6是根据本发明的再一个实施例的针对射电天文数据密集型科学运算的数据处理系统的工作流程图。具体实施方式9.下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整的描述。10.本发明提供一种针对射电天文数据密集型科学运算的数据处理系统,该数据处理系统适用于射电天文数据。此外,该系统也可能适用于天文学其他领域以及基因、生物、医药等领域的大数据处理。11.如图1所示为根据本发明的一个实施例的针对射电天文数据密集型科学运算的数据处理系统,其包括至少一个数据星座。单个数据星座的规模和配置可以根据实际需求进行调整,也可以由多套数据星座通信连接组合成一个更加强大的集群。12.每个数据星座为一个安装在一个机柜上或相邻的多个机柜上的且可扩展的综合数据单元,其均由一个可扩展的分布式的存储系统100、混合异构的计算节点系统200和超高速低延迟的网络系统300组成。13.如图1所示,混合异构是指计算架构的混合和异构,每个计算节点200既可以采用x86架构、arm架构和gpu架构中的一个,也可以采用x86架构、arm架构和gpu架构中的多个的组合,其组合可以自由灵活地定制,以适应不同类型的天文数据(如,连续谱可见度数据、时域数据、谱线数据)和不同计算需求(例如,数据密集型、计算密集型、内存密集型等),以及同一流水线中不同处理步骤的不同处理需求,也更好地满足数据处理过程中不同阶段的特定任务(如计算密集型、数据密集型、内存密集型),进而满足多种应用场景的天文数据处理的需要。在本实施例中,混合异构的计算节点系统200至少包含x86cpu架构、arm架构和x86cpu+gpu架构(简称gpu架构)三种系统架构。其中,同时采用x86和gpu的是异构计算节点,混合异构是同时采用多种不同架构类型的异构的计算节点和传统的cpu计算节点的混合组合。14.在本实施例中,x86架构的计算节点由英特尔x86gold6132cpu节点组成,每个计算节点有两个主频为2.6ghz的cpu,共有28个计算内核,理论峰值为18万亿次浮点运算,每个计算节点配置1tb内存和4tb闪存(ssd),是大型巡天数据成像任务的理想选择。arm架构的计算节点由10个华为鲲鹏920计算节点组成,每个计算节点有96个内核,主频2.6ghz,理论计算峰值为10万亿次浮点运算,每个计算节点配置总共1tb的内存和600gb的闪存,适合于多谱线通道的高度并行处理任务。cpu+gpu架构的计算节点是由x86cpu+gpu组成的异构系统,配置36个cpu内核,8个nvidiateslav100卡,理论峰值为62.4万亿次浮点运算,1tb内存,7.7tb闪存,适用于时域数据的数字波束合成、成像数据过程中的天文搜索步骤、人工智能相关的科学应用等。计算节点为arm架构时,其总访问带宽为80gb/s;计算节点为cpu+gpu架构时,其访问带宽为2tb/s。15.每个数据星座分别具有一个对应的分布式存储系统100安装在数据星座所在机柜,并存放所需的原始文件。不同数据星座的分布式存储系统100是独立的,通过超高速低延迟的网络系统300相互连接。16.每个计算节点与其对应的超大容量内存和闪存(ssd)类型的本地存储单元在物理上集成在一起,且所述存储系统100由位于每个计算节点所对应的本地存储单元101和由各个存储节点组成的分布式文件系统102组成;每个数据星座拥有独立的分布式文件系统102。由此,存储系统100的本地存储单元和分布式文件系统配合每个计算节点上的超大容量内存(单个计算节点的超大容量内存的总内存容量为1tb~2tb,且计算节点的总内存容量/计算节点的内核数》32gb,比如计算节点的内核数为32,则需要其总内存容量大于1tb)以发挥数据i/o带宽性能,从而有效利用计算节点间的数据交互,降低计算节点与存储系统100的数据交互瓶颈。数据交互是指数据星座之间、数据星座内部的多个计算节点之间以及单个计算节点内部发生的超大带宽数据流。计算节点上的本地存储单元采用nvme闪存(ssd),用于计算节点中的数据快速交换和缓存。存储节点则采用常规的hdd。根据处理过程中不同阶段对带宽的需求和数据的特征,分布式文件系统采用完全分布式的架构和全对称分布式架构,具有高速读写性能和大规模扩展性。17.如图3所示,所述的网络系统300由两部分组成,一个是与所有计算节点和存储节点均相连的多个infiniteband网络系统(简称ib交换机,带宽为100gbps,部分节点之间的带宽达到了200gbps),一个是连接到世界其他大洲的数据中心的以太网(最大带宽为10gbps),该以太网包括与所有计算节点、存储节点、后台存储节点、管理节点均相连的网络交换机,以及通过因特网与管理节点连接的多个用户登录节点。18.多个计算节点与多个存储节点类似于星座中的一个个星系,多个计算节点和多个存储节点中的任意两个之间通过所述网络系统300连接在一起。19.下面具体说明本发明的针对射电天文数据密集型科学运算的数据处理系统的工作流程以及该数据处理系统相比于传统的超级计算机的优点。20.在传统的超级计算机中,计算节点、存储系统和网络系统这三个系统在物理上是分开的,例如,一排机柜为计算节点,一排机柜为存储系统,一排机柜为网络系统。这种设计对于计算密集型的业务模式是很方便的,但是在数据密集型的业务中,这种设计变得非常低效,因为数据量非常大,数据移动成为最大的瓶颈,而且,当数据没到位的时候,计算节点处于闲置等待状态,造成运行成本的极大浪费。21.本发明采用了数据星座,其改变了传统超算中这三个系统在物理上各自分离的设计思想。数据星座设计背后的想法是将这三个系统有机地整合在一起,使计算更接近数据,最大限度地减少数据移动的成本。根据计算任务的需求还可以灵活分配资源,可由一个数据星座或者多个数据星座完成,从而能够满足多个科学数据处理流程、多类用户需求、不同计算规模和分布式任务等多种应用场景。按照本发明设计,绝大多数的数据处理可以在一个数据星座内完成,从而避免了传统超算系统中独立计算节点与独立外置存储节点之间的大量数据交换,不仅大幅度降低了能耗(比传统超算平台节省了约1/3~1/2的数据运算成本),而且还节省了一部分网络设备,节省了数据中心的整体建造成本。22.射电天文数据处理过程中的关键程序需要调用内存中的数据进行读写操作,所以内存的容量决定了数据处理流程的性能。读入系统的数据包括但不限于来自ska望远镜观测的原始数据,该原始数据通常是标准的天文fits(flexibleimagetransportsystem)格式或ms(measurementsets)格式,但也可以使用其他天文数据格式。来自ska先导望远镜的单个原始数据通常有几十g字节(1gb=1024mb)甚至几十tb字节(1tb=1024gb)大小。23.传统的以计算为主的超级计算中心的一个计算节点一般只有64gb或者128gb的内存,显然,计算系统不能一次性读入观测数据。射电天文领域的单核串行处理程序或方式是不适合于大量观测数据处理的。尤其是像来自ska望远镜的这样具有最多65000多个频率通道的原始数据,每一个通道的数据独立处理后合并写入一个文件,然后进行逆傅立叶变换将可见度数据转化成为图像。在此过程中,大量的数据交互是在内存中进行的。在传统的超算中,单个计算节点的数据处理一般使用共享内存,而多个计算节点的数据处理使用分布式内存。但分布式内存需要有限的一次性读取,而当单个数据文件的尺寸超过一定规模后,无法一次性完成计算,在实际操作中,天文学家采用的是切割数据方案;即,先按照时间顺序把数据切成几块,然后依次读入并处理每一块数据。经验表明,切分数据和把切分的数据加载到内存的过程,会消耗大量的运行时间。切片的数目越少,整体的时间消耗就越低。此外,使用分布式内存并将计算部署在多个计算节点进行并行处理并不能有效解决这个问题,因为把计算任务分布在多个计算节点上,也就意味着需要把数据传输或者复制到多个计算节点上,这样一来,在不同的计算节点上移动数据就会花费额外的时间,耗时反而更多。总之,传统的计算平台应用于计算密集型应用场景,牺牲了访问时间,以达到成本和效益的平衡,对于天文学中的数据密集型应用场景,将是相当耗时和耗力的。24.本发明针对天文观测数据等数据密集型科学运算的特点设计了内存方案。具体来说,在本发明中,在每个数据星座内为每个计算节点分配大容量的内存,从而尽可能一次性完成一个数据文件的处理,或者尽量减少数据切片的数量。在本方案的具体实施中,单个计算节点的超大容量内存的总内存容量约为1tb~2tb,因此对于大小为100gb左右的射电天文数据,能够在一个计算节点一次性完成处理,大小为数百gb的数据文件,也仅需要先切分成几块。25.本发明的内存方案不仅体现在计算节点的总内存容量大,更重要的是体现在每个计算节点(即x86/arm/gpu处理器)的单个内核可分配的内存量大,即“计算节点的总内存容量/计算节点的内核数”大于32gb,比如节点内核数32,需要总内存容量大于1tb。因为现代望远镜观测的大数据处理基本上是通过并行处理得到加速的,并行化过程中的每个线程由一个x86/arm/gpu处理器的内核控制,而这个线程所能执行的数据处理任务量受到分配的内存量的限制。传统的超级计算平台,以计算为主要业务,由于数据量小,追求尽可能多的计算核心,而不需要分配太多的内存,因此一个计算节点的多个内核通常使用共享内存,标准配置是64gb或128gb,一个计算节点的多达44个(如,英特尔至强gold6152)或者68个内核(如,英特尔至强phi7250)甚至96个内核(华为鲲鹏920),每个内核平均只分配到1.88gb内存。然而,如上文所述,在运行数据密集型任务时,不可能将数据切得太细(否则会增加数据处理的总时间),这只会牺牲多个计算核的优势。举个例子,一个100gb的文件,按照时间序列切成5个部分并分配给传统超算的一个计算节点,只能使用该计算节点中的68个内核中的20个(每个线程1gb的内存)。换句话说,虽然计算节点有68个内核,但实际上,一半以上的内核是闲置的,并没有有效地利用系统的性能。26.为了解决这个问题,本发明采用了一种兼顾计算节点的总内存容量和计算节点的单核平均内存的设计方案。根据本发明的一个实施例,采用英特尔6132作为至少一个计算节点,该计算节点中有28个计算内核,共有1tb内存,平均每个核有36.6gb内存。对于一个100gb的文件,完全没有必要进行切割,并且它能够使用全部28个计算内核(输入数据只占分配给每个核的内存的10%),完美地解决了数据流程的并行加速。27.总之,单个计算节点上的大内存容量解决了处理单个大尺寸数据文件的难题,避免或减少了数据切割、数据移动和空置等待的时间成本,大大提高了数据星座的运行效率。28.数据密集型计算流程的一个关键制约因素是数据i/o限制,它与计算密集型的高性能计算(hpc)的根本区别在于,前者适应于大数据的存储、管理、获取和处理,大部分处理时间消耗在i/o以及数据的移动和复制上。数据密集型计算任务的并行处理通常采用将数据切成小块的单元,每个单元可以独立执行相同的应用,需要专门设计整个数据处理系统,使得并行程度可以随着数据量的增加而扩展。29.图2为根据本发明的一个实施例的针对射电天文数据密集型科学运算的数据处理系统的工作流程图。如图2所示,针对射电天文数据密集型科学运算的数据处理方法包括:30.步骤s0:提供上文所述的针对射电天文数据密集型科学运算的数据处理系统;31.步骤s1:原始数据通过ib交换机送入当前的计算节点的超大容量内存,以作为超大内存缓存(cache);32.步骤s2:当前的计算节点处理任务,并判断得到的是中间数据还是最终数据;如果是中间数据,则继续执行步骤s3;如果是最终数据,则将最终数据被保存至计算节点的超大容量内存或闪存类型的本地存储单元,并通过ib交换机写回存储节点的分布式文件系统来保存,并结束流程;33.步骤s3:当前的计算节点根据存储需求将得到的中间数据存入超大容量内存或闪存类型的本地存储单元,以作为超大内存缓存(cache)或闪存缓存(ssdcache);34.其中,根据数据处理流水线不同阶段对数据i/o的不同要求,存储系统采用超大容量内存和闪存类型的本地存储单元作为多级混合介质存储,兼具安全、高速读取、快速可恢复重建等功能,能够实现数据在全生命周期的存储、管理、调用和复用,可以满足高性能计算、高数据i/o和多负载任务等多种应用要求。35.步骤s4:与当前的计算节点不同架构类型的计算节点通过ib交换机读取当前的计算节点的超大内存缓存或ssdcache来进行计算节点之间的中间数据交互,随后作为新的当前的计算节点,回到步骤s2。36.在本发明所述的数据处理系统中,解决i/o约束是通过将计算节点的超大容量内存、高性能的存储系统和高速低延时网络系统共同优化设计来实现的。37.1)首先,内存容量为1tb~2tb的超大容量内存是访问和交互最频繁的部件,在此基础上,本发明所述的计算节点在选型时优先考虑访问带宽指标,以arm架构类型的计算节点为例,集成8通道ddr4和支持pcie的100g以太网卡,总访问带宽可达80gb/s。以cpu+gpu架构类型的计算节点为例,访问带宽可以扩展到2tb/s,由此通过设计的超大容量内存和高性能(即高访问带宽)的处理器方案,与没有针对数据i/o约束做优化设计的商业服务器相比,内存带宽增加了46%,总i/o带宽增加了66%。38.2)其次,本发明中的存储系统采用高性能的分布式存储,使用计算节点的本地存储单元的ssd+存储节点的hdd的混合存储介质,兼顾高性能和性价比,组建成共享的分布式缓存(cache)资源池,供所有业务系统共同使用分布式缓存(cache)资源池;并且,通过分层读缓存机制(第一层为内存cache,第二层为ssdcache),缩短数据访问时间,对于常见的4k数据读写,平均时延保持在1ms左右。本发明通过dht(distributedhashtable,分布式哈希表)算法结合对高性能硬件(全nvmessd配置时)快速兼容,缩短数据读写时间,最大并发用户数由400增加至1000,完全满足高性能计算、高数据i/o和多负载任务等广泛的应用需求。39.3)最后,如图3所示,本发明通过为混合异构的计算节点系统和分布式的存储系统设计的高达200gbps的高速网络系统及其拓扑结构,通过大吞吐、低时延的ib交换机做内部组网,连接计算节点、存储节点和管理设备,解决了数据密集型计算中最严重的数据传输瓶颈问题,确保了计算节点内部和节点之间的数据交换顺畅,不仅降低了数据流的延迟,而且降低了网络流量导致的系统崩溃的风险。计算节点内部都是计算机本身的接口连接,比如nvme存储采用m.2接口。系统节点内部数据交换带宽由nvmessdcache带宽约束,进一步大幅提升i/o性能。目前,单节点实测最大的i/o吞吐率为7.4吉字节/秒,而理论峰值为8.5吉字节/秒,i/o利用率高达94%,超过高性能计算服务器的常规标准。此外,整个系统通过中国科研领域最高水平的洲际以太网(高达10gbps)与全球其他ska数据中心直接相连,最大限度地支持天文大数据的传输、计算和管理。40.本发明的存储系统100与传统san架构存储的核心区别在于扩展能力。传统的san存储采用控制器堆叠的方式进行扩展:双控制器或多控制器堆叠,最多可达几十个控制器,再通过在控制器后端垂直堆叠磁盘架(scale-up)来实现容量和性能的提升,但在达到一定规模后会遇到瓶颈:增加硬盘可以增加总容量,但受限于控制器架构,性能无法再线性提升。本发明中,存储系统100的分布式文件系统采用一个完全分布式的架构,支持扩展到288个存储节点(数百pb存储容量),高速读写性能随着节点数量的增加而线性增加,完全满足射电天文望远镜(比如平方公里阵列)不断增长的数据需要。分布式存储架构提供了一个高吞吐量、高并发和高可扩展的存储机制,确保存储性能随着规模的扩大而接近线性增长。另外,所述的分布式架构的存储系统,在保证高可扩展性的同时,还可以保证数据的安全可靠性。由于数据处理系统时刻都在记录着各种天文数据,这些天文数据不仅需要及时处理,还需要保存在文件系统中在一段时间内不断复用和数据挖掘,因此存储设备在保障优异的性能同时还需要具备极高的可靠性,全天候可访问,并有一定容错能力。所述存储系统的分布式文件系统还采用了全对称分布式架构,不仅能够提供超大容量的单一文件系统,而且还提供了一种冗余备份和数据快速重建的机制,最大程度上提供了可靠性。在数据存储时,同一个文件数据会被打散切片分布在不同存储节点的不同硬盘上,而且还会对这些切片数据产生一至多份的冗余数据来保证数据可靠性。用户可以根据数据的重要性、性能等进行灵活的冗余配置。在发生故障的情况下,系统会自动使用冗余备份数据进行数据重构,达到1小时重构2tb数据的速度,完全不影响用户的使用。41.图4中示出了根据本发明的一个实施例的针对射电天文数据密集型科学运算的数据处理系统的工作流程,即ska先导望远镜连续谱巡天gleam-x项目数据的处理流程,该流程根据需要使用上述三种架构类型的计算节点来进行数据处理。该项目的总数据量很大(2pb),文件传输操作占了处理时间的很大比例(40%)。在处理数据时,每个全天扫描观测都要占用100gb的存储空间,包括可见度数据、图像和元数据。鉴于gleam-x巡天的丰富性,数据处理所需内存cache高达3tb,直接在内存上对其进行数据处理的操作,以避免频繁地移动数据。42.具体来说,在步骤s1中,原始数据通过ib交换机送入多个arm架构的计算节点的超大容量内存,以作为超大内存缓存(cache);在步骤s2和步骤s3中,当前的计算节点利用超大内存缓存完成流程中的计算密集型任务,将得到的中间数据被存入闪存类型的本地存储单元以作为闪存缓存(ssdcache);在步骤s4中,与当前的计算节点不同架构类型的多个x86架构的计算节点通过ib交换机读取当前的计算节点的ssdcache来进行计算节点之间的中间数据交互,随后作为新的当前的计算节点,回到步骤s2以完成数据密集型与内存密集型任务,并将得到的中间数据被存入超大容量内存,以作为超大内存缓存;最后,与当前的计算节点不同架构类型的1或多个cpu+gpu架构的计算节点通过ib交换机读取当前的计算节点的超大内存缓存来进行计算节点之间的中间数据交互,随后作为新的当前的计算节点,完成超大计算密集型任务,得到最终数据,并将最终数据被保存至计算节点的闪存类型的本地存储单元,并通过ib交换机写回存储节点的分布式文件系统来保存。在arm架构的计算节点为10个,x86架构的计算节点为23个,且cpu+gpu架构的计算节点为2个时,在原型机平台测试后验证该混合异构的计算节点系统对ska先导望远镜产生的海量连续谱数据成像方面相较于传统平台性能提升2.23倍。43.图5示出了根据本发明的另一个实施例的针对射电天文数据密集型科学运算的数据处理系统的工作流程,即ska先导望远镜谱线数据成像流程,该流程主要利用7个x86架构的计算节点并行处理7段频率通道的数据并成像,是天文科学运算中典型的分布式处理任务,也是数据密集型计算任务。具体来说,在步骤s1中,原始数据通过ib交换机送入7个x86架构的计算节点的超大容量内存,以作为超大内存缓存(cache);随后,当前的计算节点利用超大内存缓存完成流程中的计算密集型任务,将得到的最终数据被存入闪存类型的本地存储单元以作为闪存缓存(ssdcache),并通过ib交换机写回存储节点的分布式文件系统来保存。44.图6示出了根据本发明的再一个实施例的针对射电天文数据密集型科学运算的数据处理系统的工作流程,即ska先导望远镜的mwa脉冲星搜寻流水线。mwa(澳大利亚默奇森宽视场射电望远镜阵)脉冲星搜寻项目,其为典型的天文时域数据处理流程,其原始数据小(tb级)、中间数据大、文件数量多(pb级,百万文件数)且无需保存(数据量太大,都保存下来会消耗太多存储),如果全部通过分布式存储进行数据交互会产生严重i/o瓶颈。45.本发明的针对射电天文数据密集型科学运算的数据处理系统的工作流程包括:原始数据通过ib交换机送入多个cpu+gpu架构的计算节点的超大容量内存,以作为超大内存缓存(cache);当前的计算节点利用超大内存缓存对原始数据进行数字波束合成(数字波束合成为一种超大计算密集型任务),产生的中间数据为海量波束文件,每个节点生成约1~2千个地址的目录,每个目录含约两百个文件,每个目录容量在300gb左右。该中间数据通过当前的计算节点内的本地存储单元进行缓存,得到ssdcache;与当前的计算节点不同架构类型的多个arm架构的计算节点通过ib交换机并行读取当前的计算节点的ssdcache的多个目录,从而实现计算节点之间的中间数据交互,并进行目录的并行搜寻以完成计算密集型任务,搜索得到的最终数据作为arm计算节点的内存cache,最终数据量比较小(tb量级),因此通过ib交换机写回存储节点的分布式文件系统来保存。46.因此,混合异构计算平台分别适应不同的科学应用场景以及单一流程中的不同步骤,不仅是射电天文也是其他科学运算领域值得借鉴的一个方案,也为未来大规模扩展射电天文领域的数据中心积累了运行经验。47.以上所述的,仅为本发明的较佳实施例,并非用以限定本发明的范围,本发明的上述实施例还可以做出各种变化。凡是依据本发明申请的权利要求书及说明书内容所作的简单、等效变化与修饰,皆落入本发明专利的权利要求保护范围。本发明未详尽描述的均为常规技术内容。当前第1页12当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1