基于OSS、NFS构建高性能可扩展的遥感智能解译系统实践之路-阿里云开发者社区

[toc]

前言

架构的演进从来不是一撮而就的，也不是一成不变的，从来就没有所谓的最NB的的架构，只有最适合的架构。我们说架构的演进，都是根据业务场景，从实际情况出发来谈的，脱离了业务场景空谈架构，都是耍流氓。综观哪些伟大的公司的伟大的产品，他们的技术架构也不是一步到位的，而是在业务需要的倒逼下，一步一步发展起来的。《淘宝技术这十年》这本书就深刻的阐述了上面的这个道理，没有最NB的架构，只有合适的架构。下面我就结合我工作中的一个真实的业务场景，来学习一下我们是怎么一步一步的构建了高性能可扩展的遥感智能解译系统的。

一、业务场景

下面我从三个方面说明下我们在构建系统之初的一些规划，我会分别从项目背景，产品设计以及技术栈三个维度分别进行介绍。

1.背景介绍：

我们的主要服务对象是地理信息行业，主要的业务是根据地理信息行业的业务场景提供具体的技术解决方案，地理信息行业又可以细化为遥感测绘、地图服务、导航定位服务、地理信息系统等等，我们主要面向的遥感测绘行业，主要的数据类型包括遥感影像数据，雷达数据，卫星影像数据，矢量数据，点云数据等等。遥感影像数据，雷达数据，卫星影像数据有一个共同的特点是：单文件非常大，最大可以达到TB级数据，最小的也有几十G左右，还有就是影像数据分辨率特别高，可达亚米级别。我们要做的事情，就是基于这些数据，根据遥感中心的业务需求，给出响应的技术解决方案。

随着WEB3.0时代的到来，带来了各行各业都得到了快速的发展，地理信息行业同样也在时代的浪潮中滚滚向前，他们面对的是海量的遥感数据，灵活多变的业务需求也需要迫切的展开，他们急需一套完整的数据管理系统来帮助他们快速的构建他们的业务，管理他们的数据。正是在这样的背景下，遥感数据管理平台应用而生。

2.系统设计：

遥感数据管理平台旨在打造一套从数据生产到数据应用的全生命周期管理的数据资产底座，形成了全流程、自动化、智能化、模块化的业务生产服务能力；形成数据贯通、资源共享、功能集成、服务响应的服务能力，为行业应用提供基础数据、要素产品、数据智能分析、空间分析、二、三维展示等数据保障和多元化技术支撑。

因为系统供应商不同，以及系统本身技术复杂度等原因，遥感数据管理平台被设计由俩部分组成，为数据湖及遥感智能解译系统组成。数据湖系统负责整个平台的数据管理，业务应用，数据治理等业务。遥感智能解译系统则主要负责遥感数据的智能解译相关的功能，包括模型的管理，数据集的管理，模型训练及数据解译等工作。

数据湖具体产品架构设计如下：

从上图可知，数据湖整体上分为应用层，支撑层，存储层和存储平台等：

业务层：主要为用户提供业务所求，包含数据展示，遥感监测，数据统筹，专项监测等等，
支撑层：主要负责系统的正确运行，包含用户认证，系统监测，任务调度，大屏管理等核心功能，
存储层：主要负责底层数据的管理，包括数据的采集，入库，存储，治理等等。
平台：系统存储平台涉及NFS网络共享存储，对象存储，数据库存储技术及内存数据库的。

遥感智能解译系统架构如下所示：

遥感智能解译系统同样包含应用层，支撑层，存储层和存储平台：

应用层：主要为用户提供业务功能，包含地物分类，道路检测，水体检测等功能。
支撑层：为遥感智能解译系统提供业务支撑功能，包括遥感数据的处理及遥感数据训练等能力
存储层：主要存储遥感数据的各种形态数据，包括模型数据，数据集，瓦片数据，遥感数据等。
存储平台：主要指系统的运行环境及数据库的存储平台，包含本地文件系统，数据库系统和共享网络文件系统等

3.技术栈设计：

微服务搭建：基于Spring Boot Alibaba 技术栈进行微服务搭建。
大数据计算：基于Spark进行离线数据计算
大数据调度系统：基于Azkaban构建任务调度系统
海量数据存储：基于对象存储OSS进行数据存储
遥感数据解译：基于人工智能-计算机视觉模型（RCNN，YOLO）进行遥感影像数据的智能解译。

二、初代遥感智能解译

在项目的初期，我们首先解决的是有无的问题，我们需要根据项目需求和业务场景为用户提供系统产品，这也是用户最迫切需要的。

1.目标设定

数据湖实现数据管理基本功能，智能解译系统实现数据解译等工作。同时，能够从数据湖中进行遥感数据的下载，然后在智能解译系统中实现遥感数据的解译。有些人可能要问，为什么不直接把数据放在智能解析系统，对于这个问题，我们的回答是：我们对俩个系统的定位不同，遥感智能解译系统我们更多的理解它为一个工具，不涉及数据的大规模存储，数据湖才是项目的主体和底座，所有的业务及功能应该是围绕着数据湖来展开。

2.架构设计

项目的架构设计图如下，我们分别实现了数据湖功能和智能解译系统，对于数据湖与智能解译之间的数据串联，我们主要还是通过人工的方式进行，主要原因是产品有俩个项目组独立负责，同时也有项目周期，项目人员，项目排期等原因。

3.成果及比较

基于上述的产品架构，我们基本上完成了项目的主要功能，数据湖实现了遥感数据的基础管理，智能解译系统能够实现遥感数据智能化管理。

4.缺陷或不足：

因为篇幅和本章主题的原因，我们这里只讨论数据湖到智能解译系统相关的问题，其他问题不是本文的重点。我们目前主要的问题是数据同步效率低下，项目需要专业的业务人员根据业务场景和数据特性进行数据筛选，然后进行数据下载到客户端，通过U盘或者硬盘同步数据到智能解析系统，实现数据的存储，入库成功之后才能够进行数据解译，几点整理如下：

数据筛选困难，需要专业人员进行数据筛选
数据同步慢，需要业务人员进行数据下载，数据上传等操作，而且无法同步进行
数据回传慢，对于数据解译成功的数据，业务人员需要再次进行数据导出，数据入库，整个流程非常的缓慢。

智能解译系统处理一幅500G大小的影像数据，需要差不多8个小时的工作，效率非常的低下。在业务量大的时候，是很难满足要求的。

三、自动化遥感智能解译

1.问题分析：

针对上述问题，我们分析了整个链条，总共涉及了7个步骤，如下图：

其中数据传输时间占了1.5小时，数据解译等占了2小时，数据等待4个小时，占了整个用时的50%，我们需要自动化的数据下载，上传等功能来简化和优化数据的解译流程，重新设计数据的解译流程：

我们分别完善数据湖功能和智能解译系统功能，实现了数据湖的自动下发，智能解译数据的自动接入，解译完成之后的数据自动上传到数据湖等工作。

2.目标设定

优化原有数据湖功能和智能解析系统功能，使之支持数据湖数据自动下发，自动入湖操作。
优化智能解译系统，使之能够自动数据接入，解译完之后的数据自动上传入湖。

3.架构设计

我们完善了原有的设计架构，在数据湖中增加了消息推送模块，在智能解译系统中增加了数据接收模块，架构图设计如下:

和初代的相比，我们在数据湖中加入了消息推送模块，主要服务入湖消息，下载消息的逻辑处理，智能解译系统增加了数据接受模块，主要负责数据湖数据的下载及本地解译数据的上传工作，几点整理如下：

数据湖-消息推送：数据入库，数据下发消息通知
智能解译-数据接收：数据湖数据下载，解译数据数据湖上传

3.技术方案：

针对对象存储OSS中存储的数据，我们使用的是对象存储OSS JDK进行编程的，对于本地系统数据的下载上传，我们使用的是JAVA JDK 构建。

对象存储-数据下载上传：基于OSS JDK实现对象存储数据的下载上传，
本地系统-数据下载上传：基于Java 实现本地数据的下载上传

4.成果及比较

通过对人工进行数据传输模块的优化，我们实现了从数据湖到遥感智能接系统之间，数据的自动流转工作，效率得到了大大的提升，大大降低了人工的参与，整个过程，时间由8小时降到了4小时一下，整体速度提升了进一倍。

5.缺陷或不足

虽说从8小时到4小时有了一倍的性能提升，但是，对于用户来说，没有最好，只有更好。因为自动化的引入，同时也暴露出来一些不足：

效率：8小时变为4小时对于此时的用户来说，还是觉得时间有点长
稳定性：因为自动化的引入，增加了系统的不稳定性，系统在数据的传输过程中，因为网络的问题有时存在传输错误等问题，数据丢失等问题
传输速率：自动化数据下载上传时的网络传输速率在200M/s左右，速度有点慢，远远没有达到网络带宽的限制