基于Kubernetes的花式并发遥感影像处理
虽然讲技术,但是咱也顺带过一下简单的科普入门。这样对为什么要做花式并发这种特性,有更好的理解。
1 什么是遥感影像?
就是各种地球自拍照,当然也有其他各种相关的传感器,比如测温度的,激光雷达什么的。
2 遥感影像要做哪些处理?
毕竟地球自拍照,总得美颜一下。比如照片是一张一张的,你要拼成完整大图(图像镶嵌)。比如拍的歪的,调正角度(正射校准)。颜色有深有浅,得美化一下(匀光匀色)。
以及其他各类的“美颜技术”:正射校准、影像配准、影像镶嵌,影像裁剪等。目的是得到类似DOM这种可以发圈的照片。
然后后期还有各类AI处理,比如自动识别地球自拍照里面的:汽车,建筑物,湖泊,农林耕草等各类AI场景。
除了智能分析静态的自拍照,还能自动分析目标是不是整形过(动态的):
总之,遥感影像图片,可以进行各种各样的“计算处理”。
3 并发处理是常态
遥感影像就是一张张的图片,很多算法都是针对每一张(简称:景)图片进行处理。例如:过滤筛选有效照片等,都是每一景影像单独处理的。
举例:假设某文件目录中有1万景影像,然后你自研了一个质检程序,用来判断图片是否满足要求。
你可以使用,(1)串行的方式,用程序不停的读取每一张图片进行处理,但是这样处理会很慢。所以你希望(2)并行启动多个质检程序,利用大规模分布式并行处理来加速整个质检步骤。 如:直接启动1万个质检实例,分别处理不同的照片,那么瞬间完成任务。
所以,在遥感影像处理中,由于数据量的巨大,并发处理是基本述求。如何花式并发,才是核心能力。
3.1 固定并发
所谓固定,就是提前知道怎么并发。比如今天任务是处理1万张图片,那么在投递任务的时候,将并发值直接设定为1万就行了。
我们称提前可以知道的并发数量,为固定并发。
3.2 动态并发
所谓的动态,是指运行过程中才能决定并发数量。比如跑完上一步,才能确定下一步的并发数量。
比如有一个流程:步骤1,是将1万张图片,进行质检处理(具体哪些照片能通过质检提前是不确定的)。 紧接着是步骤2,这一步是并发处理那些质检合格的图片。
那这里步骤2的并发数量,就是一个动态的值。完全由步骤1的结果决定。
3.3 花式并发
这里,总结一下并发的2种形态。
(1) 递进式并发
(2) 笛卡尔式并发
咱们以相亲为例(男生组100个人,女生组也是100人),将 “1男1女的一次交流”,作为一个“处理单元”,求总共需要多少一对一交流。
Ø 笛卡尔并发
那么最常见的“交流环节”当然就是两两交流啦。每个人和任意一位异性交流一次,这样一共需要进行 100 * 100 = 10000 场的对话交流。即 N * M 次交流,我们称 笛卡尔式。
Ø 递进式并发
有时候,主持人决定,只有编号相等的异性,才能进行一次交流。也就是男1号对女1号,只能这样匹配。这样一共需要进行 100 * 1 = 100 场的对话交流。即 N * 1 次交流,我们称 递进式。
下面以具体的实际场景来
3.3.1 递进式并发
场景介绍:
Ø 拍植物长得怎么样的传感器。(NDVI,学名:归一化植被指数)。
每个月拍一张的话,一年有12张图片。
根据这12张图,可以算出全年的:(1)平均植被 / (2)最秃程度 / (3)最茂盛程度。
Ø 拍温度热不热的摄像头。 (LST,学名:地表温度)。
每个月拍一张,一年有12张图片。
根据这12张图,可以算出全年的:(1)平均温度 / (2)最高温度 / (3)最低温度
OK,那当前咱们有12植被 + 12温度 = 24张图片。
开始花式并发的影像流程处理:比如算一算 干旱指数。
上图*号处,即步进式并发(流程指最后一步):要求1月份的植被照片,要和1月份的温度照片,一起计算。 然后2月的温植一起算。大家一起递进,如此进行并发。
好理解不,有点像男1号和女1号,然后按此顺序,大家组队完成任务这样子。
3.3.2 笛卡尔式并发
场景介绍:两个图层做相交查询。
例如,查询每个市的绿地覆盖情况。这个时候,就需要每个市,和其相交的瓦片层做关联查询。
这种情况下,就会有两两匹配执行计算的操作。
不过相对而言,遥感影像处理中,此类场景并不是太多。大多数的并发,只需要根据影像图片的数量就可以确定了。
4 总结
遥感影像处理领域,需要各种各样的并发处理逻辑。Kubernetes容器平台,使用Docker容器作为独立无依赖的运行单元,非常适合大规模遥感影像并发计算的底座。配合超强的Workflow流程引擎,可以满足各类花式并发的述求。相比GBDX的引擎能力(参见https://bbs.huaweicloud.com/blogs/208660)而言,华为云地理遥感解决方案打造的workflow能力可以说是领先一大截。实乃居家旅行,遥感影像处理的必备良药。
那么,你的地理遥感影像平台并发了没?
- 点赞
- 收藏
- 关注作者
评论(0)