一般我们认为遥感数据要么存储于磁盘文件,要么加载到内存中。通常内存资源总是紧缺和有限的,所以大都以磁盘(外存)为主,处理时将需要的数据加载到内存,处理完毕再写回到外存。实际上有些软件就是这样工作的,甚至加载磁盘文件的部分数据,部分处理部分写出,呈流水线式处理流程。
不都是这样处理吗?不,也有不是按照这种逻辑关系处理的。比如RSD就采用了完全不同的处理方案。
RSD为处理和管理超大规模和范围的遥感数据,精心设计了基于网络的分布式处理架构。
RSD首先假设有一个虚拟的2维超大的数据空间(也可以认为是大虚拟内存或大图),这个大图覆盖在局域网(LAN)上。这个LAN也特别设计为一个2维节点机的集群,特意与2维地理空间对应。每个节点机负责(不限)对应的大图的部分区域。每个节点机上的存储空间(磁盘)与计算机内存建立一种虚拟映射关系。
因为最终是建立了与节点机内存的映射关系,是不是也可以认为我们有了一个大内存,只不过有时是在物理内存里面,有时是映射到硬盘上的虚拟内存。这都没有关系,RSD有一套自动维护的机制。
最后落实到单个的节点机上,是磁盘存储空间与内存的映射。RSD开始工作时需要多少空间就申请多少。小规模数据时可能就是临时文件,数据规模大了可能就是TFS(Tile
File System,RSD自己定义的瓦块文件系统)。
举一个例子,创建一个中国内陆全国10m的任务。(打开任务模板文件 中国大陆-Albers-10m.tpl创建)
图1 中国内陆10m任务框架
这个任务创建了一个有520000*420000像元的任务框架。观察RsdTmp目录,建立了一大堆的文件(图2)。一共42行*44列,加元数据等共1850个文件。
可能有人会问了,在磁盘上开辟上千个文件几百个G的数据量是不是需要很多时间?不用担心,由于是和内存的映射,这里是秒开。至于后面加载遥感数据集那就没有办法了,还是要依靠磁盘传输的。
图2 中国内陆10m任务框架创建的TFS文件
没有加载任何文件就占用磁盘空间610G,这还是图像处理的基本需求。这也是RSD经常被吐槽占用磁盘过多的原因。不过处理这样超大规模数据也需要花点成本的,看看下面的例子,GF6
WFV通常被认为太大不容易处理,图3是在一个16m框架加载的2个GF6 WFV,加载几十景就可以铺满全国。RSD专门为处理大规模数据设计,有极强的数据处理能力。
图3中国内陆16m任务框架加载2景GF6 WFV
这些在RsdTmp里面的磁盘映射在进程结束后就自动清理了,这样就引出了一个问题。处理这样庞大规模的数据通常需要很长时间。大一些的项目需要处理一个月或者更长时间也是有的。关机就清理了或者遇到异常宕机丢失了下次总不能从头再来吧?RSD的另一个技术——
任务目录 即为解决这一问题而设计。
RSD的任务目录可以被看做是一个数据仓库。RSD任务建立后,可以据此创建自己的任务目录(有菜单命令)。创建后在RsdMdx路径可以看见一个(任务名).mdx
的文件和一个用任务名命名的子目录。这个任务目录可以进行打开保存等操作。关于任务目录的导入导出和数据安全数据管理等详见RSD使用说明。
这里示例说明一下数据目录的应用意义。比方上述图3的任务,已经处理了10景的GF6
WFV数据,并且早已创建了任务目录,现在需要下班关机。这时点击保存任务目录即可,而且是秒存。第二天上班打开任务目录,尽管有10景的GF6
WFV,仍然是秒开。接上一天的工作继续处理数据。并且可以在任何时候导出常用的交换格式的数据或者保存任务目录的全部、部分或者单独某层甚至某层一个任意裁剪区域的数据。当然也可以随时加载任何数据到当前任务。
任务目录支持安全、灵活、快捷的数据处理和管理功能。
加QQ群136965427,这里发布和讨论有关RSD技术问题。
加企鹅758461012,原来的满了。