基于OpenStack的海量影像入库方案-研究院内部分享

基于OpenStack的

海量影像入库方案超图研究院SuperMapGISTechnologyInstitute研究所

李少华第一部分第二部分开始结束第三部分分布式系统特点更多海量影像数据导入数据组织导入方案消息队列效率对比内容概要分布式系统分布式系统的特点业务规模不断增大业务变得越来越复杂并发用户请求越来越多处理的数据也越来越多可扩展性让多台服务器协同工作，完成单台服务器无法处理的任务，尤其是高并发或者大数据量的任务分布式系统的特点1、分布式系统对服务器硬件要求很低对服务器硬件可靠性不做要求，允许服务器硬件发生故障，硬件的故障由软件来容错。所以分布式系统的高可靠性是由软件来保证。对服务器的性能不做要求，不要求使用高频CPU、大容量内存、高性能存储等等。因为分布式系统的性能瓶颈在于节点间通讯带来的网络开销，单台服务器硬件性能再好，也要等待网络IO。传统数据中心Pets模式竖井式硬件现代数据中心Cattle模式通用硬件VS.分布式系统的特点1、分布式系统对服务器硬件要求很低Google对于数据中心的成本控制做到了极致：所有服务器一律不要机箱；主板完全定制，只要最基本的组件，早期的定制主板连电源开关和USB接口都不要；在主板上加装隔离带把CPU单独隔出来，让冷风只吹CPU，不吹内存、硬盘等不需要降温的组件，最大限度降低冷却电力消耗。分布式系统的特点2、分布式系统强调横向可扩展性塔式架构Scale-Up横向扩展Scale-Out天花板CPU内存硬盘云平台资源横向扩展…提升每台服务器性能进而提升集群整体性能通过增加服务器数量来提升集群整体性能分布式系统的特点2、分布式系统强调横向可扩展性比如有10台服务器组成的集群，横向扩展为100台同样服务器的集群，那么整体分布式系统性能会提升为接近原来的10倍。传统数据中心Pets模式竖井式硬件横向扩展困难现代数据中心Cattle模式通用硬件横向扩展VS.分布式系统的特点3、分布式不允许单点失效单点失效（Single

Point

Failure）是指，某个应用服务只有一份实例运行在某一台服务器上，这台服务器一旦挂掉，那么这个应用服务必然也受影响而挂掉，导致整个服务不可用。廉价服务器不可靠随时发生故障提供高可靠服务分布式系统里运行的每个应用服务都有多个运行实例跑在多个节点上，每个数据点都有多个备份存在不同的节点上.KeepAlivedHaproxy…分布式系统的特点3、分布式不允许单点失效用户WebServerGISServerDBServer心跳线心跳线心跳线心跳线心跳线心跳线负载均衡Web集群GIS集群DB集群共享存储VIPKeepAlivedHaproxy分布式系统的特点3、分布式不允许单点失效通常情况，不要让服务器满负荷运行，服务器长时间满负荷运行的话，出故障的概率显著升高。所以分布式系统采用一大堆中低性能的PC服务器，尽可能把负载均摊到所有服务器上，让每台服务器的负载都不高，保证集群整体稳定性。分布式系统的特点4、分布式系统尽可能减少节点间通讯开销分布式系统由独立的服务器通过网络松散耦合组成的。每个服务器都是一台独立的PC机，服务器之间通过内部网络连接，内部网络速度一般比较快。因为分布式集群里的服务器是通过内部网络松散耦合，各节点之间的通讯有一定的网络开销，因此分布式系统在设计上尽可能减少节点间通讯。此外，因为网络传输瓶颈，单个节点的性能高低对分布式系统整体性能影响不大。分布式系统的特点4、分布式系统尽可能减少节点间通讯开销如前所述，分布式系统的整体性能瓶颈在于内部网络开销。目前网络传输的速度还赶不上CPU读取内存或硬盘的速度，所以减少网络通讯开销，让CPU尽可能处理内存的数据或本地硬盘的数据，能显著提高分布式系统的性能。典型的例子就是Hadoop

MapReduce，SuperMapiServer并行切图等把计算任务分配到要处理的数据所在的节点上运行，从而避免在网络上传输数据。分布式系统的特点5、分布式系统应用服务最好做成无状态的应用服务的状态是指运行时程序因为处理服务请求而存在内存的数据。有状态，一旦服务器宕机就会使得应用服务程序受影响而挂掉，那存在内存的数据也就丢失了.无状态，让程序把需要保存的数据都保存在专门的存储上内存Data存储Data内存Empty存储Data宕机重启基础理论目标本测试是基于OpenStack环境和消息队列，将海量影像数据导入到集中关系型数据库，实现导入方式的并行性处理和自动化处理，体现云环境为GIS应用带来的价值。数据概述数据情况全球影像数据数据格式TIF数据量2.67TB数据分为南北半球，各占1-60分带，大小在200MB~7GB不等数据概述其他说明该数据为分带数据N-02-00.tifN-02-15.tifN-02-20.tifN-03-15.tifN-03-00.tifN-03-45.tifWGS_1984_UTM_zone_2NWGS_1984_UTM_zone_3N环境OpenStack：icehouseGIScript：2005Python3RabbitMQ：3.2.4PikaforPythonUbuntu：15.04SuperMap：iDesktop7.1.2Oracle：11.2.0.4原理通过消息队列，将所有影像数据按照带号进行逻辑划分，带号可以从tif影像的文件名称获得，然后将每个带号下的tif影像的路径写到一个job文本文件中，通过消息服务发出这些工作请求，python服务器接收相关的job文件，然后读取job里面的tif文件，进行创建影像数据集和影像导入追加镶嵌，创建金字塔工作。02.Job04.Job05.Job/temp/data/geotiff/N-04-15.tif/temp/data/geotiff/N-04-25.tif分带投影文件流程Geotiff*.dbfRedhatGeotiff：/data/geotiffOracleMQ（VM）Python（VM）Python（VM）物理刀片存储挂载Data：/temp/data/geotiffMQ：/temp/job/doing|done|todo/temp/tempmountmount02.Job04.Job05.Job/temp/data/geotiff/N-04-15.tif/temp/data/geotiff/N-04-25.tif分带投影文件04.job02.job0、接收消息分发任务1、创建影像数据集a.读取N-02*.tif

b.获得参数及范围

c.创建2、导入并追加镶嵌影像3、继续接收消息任务存储层刀片层虚拟机层关于数据和路径首先为数据库服务器挂载约3TB的存储，映射路径为/data/geotiff，然后消息队列虚拟机和Python虚拟机通过mount命令将数据挂载到虚拟机本地，确保两者的路径信息完全一样，这样可以保证消息队列分配的任务，python机器可以访问同样的路径获得数据。GeotiffRedhatGeotiff：/data/geotiffOracleMQPythonPython物理刀片存储挂载Data：/temp/data/geotiffMQ：/temp/job/doing|done|todo/temp/tempmountmount导入策略-1导入并镶嵌影像数据集Tif影像投影转换创建金字塔Tif影像Tif影像创建全球影像数据集直接创建一个全球地理坐标系，然后将tif文件进行投影转换，再导入或者追加镶嵌到全球影像数据集，最后创建金字塔。优势：投影一致，如果对全球影像数据进行分布式集群切图效率会很高。问题：目前我们的GIScript2005程序还没有将投影转换功能集成过来。导入策略-2分幅影像数据集Tif影像Tif影像创建金字塔分幅影像数据集Tif影像Tif影像创建金字塔创建分幅投影的影像数据集，在创建影像数据集时需要注意获得所包含tif文件的最大最小范围，然后比较后获得一个包络矩形范围，这样才能保证所有的tif影像可以导入并镶嵌到该影像数据集内。优势：任务切分逻辑明显，金字塔操作也可以归类到不同的Python虚拟机执行。缺点：如果最终需要切图，因为需要创建一个全球地图投影的地图，然后其他影像数据集进行动态投影到一幅全球影像地图，对影响切图效率。创建影像数据集读取影像获得影像参数WidthHeightPixelFormatBound（L、T、B、R）BandCountBlockHeightBlockWidth影像列表循环比较影像Bounds获得Min(left)Max(top)Max(right)Min(bottom)创建影像数据集消息队列关于消息队列使用了RabbitMQ作为消息服务器，根据相关原理介绍，将相关文件按照分带进行job文件的生成，然后发送到消息队列中，针对消息的处理，划分四个维度。将处理的任务（todo）、正在处理的任务（doing）、已经完成处理的任务（done）、出错的任务（error），也就是创建四个文件夹，Python客户端接收任务时根据处理的情况，将job文件存放在不同的操作目录中。Error消息队列关于消息队列使用了RabbitMQ作为消息服务器，根据相关原理介绍，将相关文件按照分带进行job文件的生成，然后发送到消息队列中，针对消息的处理，划分四个维度。将处理的任务（todo）、正在处理的任务（doing）、已经完成处理的任务（done）、出错的任务（error），也就是创建四个文件夹，Python客户端接收任务时根据处理的情况，将job文件存放在不同的操作目录中。结果展示结果展示入库效率对比方案1：使用一体机刀片服务器入库，刀片服务器配置32个CPU核心，128GB内存，将整个北半球的影像（1.95TB）入库共花费时间约23.77小时。而且入库过程中造成了资源利用率低下，浪费了大量的计算资源。入库效率对比方案2：可以将同资源的的刀片进行虚拟化，基于OpenStack的私有云技术，然后生成两种虚拟机类型，消息服务器虚拟机和Python工作虚拟机。……OpenStackRabbitMQServerPythonWorker入库效率对比Python工作虚拟机可以根据资源情况虚拟多台，例如本次设置的Python虚拟机的云主机配置类型为4个vCPU和4GB内存，但是在入库过程中发现，其实虚拟机的CPU利用率并不高。本次测试开启了1个消息服务器，和18个Python工作服务器，导入时间约5小时（由于不同的虚拟机接到的job的工作量不一样），以最后一个导入完毕计算结束时间。

入库效率对比

单个刀片单个虚拟机（4核/4GB）单个tif(4-5GB)240s300-600s批量导入56GB约40分钟41GB约112分钟可见虚拟化对资源的损耗还是比较明显的，但是考虑到整个程序对整体的资源利用率不高，所以通过资源池化管理，进行分布式导入，完全可以提高相关的导入效率，如果Python的虚拟机再开启更多，导入效率会更