空间属性一体化全文检索方案：2.总体架构设计
前文再续，书接上一回。
今天是空间属性一体化全文检索系统的第二节，主要来讲讲系统的总体架构设计，包括了系统架构和数据架构。
整个系统的架构分成五层自下而上分别是：
数据及存储管理层
系统功能层
服务层
API网关层
业务功能层
下面详细介绍一下每一层的具体设计和功能。
首先最底层肯定是数据以及存储管理层，因为说到底，全文检索系统是为数据治理体系服务的系统，所以最关键的就是设计和处理好统一存储管理与数据资源框架。
一般来说，一个单位内部的数据存储大多数都是由以上结构所组成的。
首先基于块存储的数据库系统，所谓的块存储指在一个RAID（独立磁盘冗余阵列）集中，在一个控制器中加入一组磁盘驱动器，然后提供固定大小的RAID块作为LUN（逻辑单元号）的卷。可以直接理解为我们的电脑硬盘使用方式即可。一般来说，块存储直接给客户提供的是面向裸磁盘空间的映射，然后操作系统将这些空间划分成逻辑单元号（比如在windows系统上的C盘、D盘、E盘这种）。然后我们可以把数据库系统安装在你的逻辑单元上。只不过个人电脑一般是一个物理硬盘，而当然作为RAID，在物理上可以是若干个盘，不过用户不用需要关心而已。
传统上，大部分单位的做的业务系统，所进行持久化数据存储，都是直接使用结构化数据库来存储，特别是GIS企业，核心的数据模型都会要求采用空间数据库来进行存储。所以第一部分，也是最核心的部分，自然就是由结构化属性数据库和结构化空间数据库组成的RDBMS（关系型数据库管理系统）+ SDE（空间数据引擎）所组成的传统数据存储模式。
然后就是对象存储系统，对象存储将内部所有的存储单位（例如单个文件），视为一个独立的对象，与文件系统的树形结构所不同的是，对象存储没有层级（不像传统文件系统，由：磁盘——文件夹（多级文件夹）——文件这种层级的树形结构所表示），对象存储是一个扁平的池化存储系统，所有的对象都是平级的，不会出现一个对象是另外一个对象的下级（类比传统文件系统，一个文件可能是某个文件夹的下级）。目前对象存储在云存储系统里面使用得非常广泛，一般我们天天使用的云盘系统，就是一种对象存储系统。
在我们的系统设计里面，我们可以把大量的需要存档的文件，使用对象存储管理起来，比如图片、文档、视频、音频、压缩包以及GIS体系里面的栅格、原始的shapefile、CAD、工程文件、地图包等，都存放在对象存储中，提供有需求下的文件上传下载。
第三就是以HDFS（Hadoop Distributed File System）为代表的分布式文件存储系统，HDFS是一个高度容错性的系统，它非常适合部署在廉价的机器上。而且HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。是目前主流的作为大数据基础数据存放标准的文件系统。我们再次可以用它来存储用于离线分析的庞大数据，以及各种流式数据（比如系统运行中的用户行为数据）。
第四是共享文件存储系统。也就是传统意义上的文件存储系统了，一般来说，用来存放整个系统所需要的支撑文件，比如配置文件、系统文件，以及各种缓存文件等。通常来说，我们系统里面需要在客户端上展现的web系统相关的文件，都可以存在在共享文件存储系统上，比如地图数据、切片缓存、系统缓存等。
最后就是整个全文检索系统承上启下的核心部分，索引存储系统了，因为在全文检索系统中，我们会把所有的信息都解析成为索引文档（Index document，Elasticsearch的专有术语，文档是es最基础的组成单元，在后面我们会详细说明），所以索引库可能极其庞大，超过十亿级数、存储达到PB级，也是很有可能的。所以索引存储是决定我们整个系统成败的关键节点。
数据存储管理之上，是系统功能层，主要是支撑整个系统的基础软件做组成的。
首先第一个，就是全文检索系统，我们在这里的设计中，选用的Elasticsearch（文中以下会简称为ES），这是目前最流行，也是实际上的业界全文检索系统的主流代表。ES是一个以Lucene 为基础开发出来的开源的、分布式、高可扩展的全文检索、数据分析引擎，它对外提供Restful风格的API，并且具有实时、稳定、可靠、快速、安装使用方便等多种特性。
PS：ES有个很鸡贼的地方，就是它本身虽然是开源免费的（ES遵循Apache 协议，这是最宽泛的开源协议可以随意修改、复用、打包、出售，仅需要在代码里面加上一句Apache 2 license 声明即可），但是ES里面有很多插件是收费，比如对于企业化应用至关重要的安全插件。当然，也有很多第三方的插件，比如Esri把ES打包成了ArcGIS Datastore的一部分，也提供了相关安全插件。
第二个就是地理信息系统（GIS），我们的这个系统称之为：空间属性一体化全文检索，所以GIS系统自然是必须的，GIS为我们提供了地图、空间分析引擎、（空间）数据处理与管理等功能，而且我们一些高级的空间属性一体化检索功能，也需要GIS提供相关扩展。
以上两个系统都是比较成熟的商业化系统，我们仅需要在其上做二次开发和调用即可。
第三个就是数据处理系统，这个系统是我们空间属性一体化全文检索系统的基础。我们需要使用数据处理系统，对我们现存的数据进行清洗、转换、解析、处理，来变成全文检索引擎可以使用的标准文档，这里就包括了对传统的属性数据和空间数据的处理，还包括对于CAD、栅格、多媒体数据、压缩包的处理，以及元数据的处理。
架构在系统功能层上面的就是我们的对外服务层了，要实现整个系统，就需要对外提供这些服务。
以上服务在后面的关键技术实现中，我们还会详说。
我们对所有的服务，提供的都是restful风格的标准API服务，所以在服务层上面，提供了API网关层，这些网关都是传统的微服务架构中提供的组件。
所谓的API网关就是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
在API网关之上，就是我们的业务系统层了。业务系统可以分为以下三类：
因为全文检索系统可以作为任意业务系统的一个组成部分，因此它并不需要涉及到专门的业务，所以我们可以搭建通用的全文检索系统，这个系统能够涵盖所有的数据，仅提供检索功能，不用嵌入业务流程。
当然，我们也可以把这个全文检索系统作为标准业务系统的一部分，嵌入到我们已有或者要建设的业务系统中，作为标准的检索服务。还可以专门定制一个专用的检索系统。只要我们的API服务编写得足够精炼和优化，即可按需去搭建任意的系统或者是组件。
以上是系统总体架构设计，下面我们看看数据结构的设计架构。
首先就是我们的数据来源。全文检索的信息可以来自于任意的数据结构，总体而言，主要是以下三类：
1、结构化的数据，比如我们的表格、结构化矢量数据、元数据等
2、半结构化的数据，比如文档数据、统计数据、代码、模型描述等
3、非结构化的数据，比如栅格、模型、多媒体、图件等
所有的数据，首先需要设计索引和检索内容，然后是元数据和目录管理，最后通过归类与信息提取，按照既定的索引模板，导入到全文检索引擎里面，作为我们的全文检索数据源。
不同的数据结构，处理的方式不尽相同。一般来说，能解析的尽量进行解析，不能解析的，进行描述。
对于结构化数据，是最容易的处理的，可以直接解析和处理成为全文检索库可以直接应用的信息。而对于半结构化数据，就稍微麻烦一点，不过全文检索引擎本来就是针对海量文本来设计的，所以半结构化数据也好办，解析之后，把有检索意义的数据直接导入到全文检索库中，需要注意的是还需要保留半结构化数据的反序列化能力，也就是把信息再次组合成对象的能力。
对于非机构化数据，因为没有办法对内部信息进行解析，所以我们需要处理它们的描述信息（比如空间数据的范围、空间参考、类型、时间），以及元数据，还可以制作相关的预览模型（比如带有空间位置的缩略图等），当然还有与实体数据相关联的管理。
关于数据的详细处理，我们在关键技术一节还会继续详说。
最后就是关于各种数据的流向。
1、结构化的属性数据和空间数据，会直接存储在关系型数据库中，并且抽取需要进行全文检索的信息，存放到索引库中。
2、半结构化数据可以将对象实体存储在HDFS和NAS中，然后将解析出来的信息按照一定的规则，存储到索引库中，作为检索内容。
3、非结构化的数据，是最麻烦的一类数据：
首先它的一些数据可以存入关系型数据库中，比如栅格数据管理用的镶嵌数据集信息，可以直接放到SDE里面，他的元数据信息可以存放到属性数据库中。
其次它的实体文件，可以存放在对象存储里面，提供实体文件下载功能，也可以存放在HDFS里面，作为分析和存档数据。
第三它的一些预览和缓存数据，可以直接放置在NAS上，比如CAD数据的缩略图、多媒体文件的预览等。
最后，这些信息，都可以作为需要检索的条件，导入到索引库中。这样就完成了全文索引系统对于非结构化数据的检索能力。
预知后事如何，请听下回分解。
插播广告
有需要的详细咨询了解其中的一些关键的技术细节的同学，可以与虾神单独联系。