|
前文再续，书接上一回。 上一节我们讲了在ES里面怎么使用空间数据，以及空间数据的优化策略，这一节我们来讲讲元数据和数据治理的原则。 首先我们都知道，我们需要检索的内容，有很多实际上是对数据的描述信息，比如我要查询拍摄有某条街的视频信息，或者在某个时间拍摄的某栋大楼的图片。还有可能是查询某个时间段修过的文档文件。 这些信息，就不是数据本身的内容，而是属于描述这个数据的信息，这些描述数据的数据，就是所谓的元数据。 元数据主要是描述了数据的属性信息，用来标识这个数据的如存储位置、历史版本、资源查找、文件记录等，特别是一些无法直接通过计算机解析的非结构化数据（如视频、图片、音频等），元数据就更加重要了。 下面我举几个场景： 首先一个场景是，比如我们查询命中了某个文件里面的某条信息，发现这个文件是我工作中需要了，自然就涉及到可能还需要获取到这个文件，如果系统提供了下载的权限，就可以通过元数据去直接获取到整个原始的数据文件了。 或者有这样的场景，我们有一份非常庞大的数据文件，比如记录了某个危化品运输车辆一个月的LBS信息（位置服务），那么查询到任何一个点或者任何一条记录，对于这个车辆都没有多大意义，我们很多时候需要整体查询这个车辆的信息，比如总里程，比如平均时速或者一些统计值，这些数据在原始数据中是不存在的，而需要通过技术和描述才能反映出来，这样的数据，也是元数据。  在构建全文索引库的时候，在库里面放什么样的数据，是全文检索系统好不好用的关键问题之一。我曾经在一次数据中心的研讨会议上和一些一线架构师们聊过这个问题，当时有个同学就说，我可用把我的数据库里面全部数据进行开放，构建一套具备本底数据库全部能力的全文检索系统，二者间只需要简单的同步就可以了。 那么我们来想想这几个问题： 首先，是不是所有的数据都是用户需要查询的？ 答案肯定不是，系统数据库里面的数据，有大量的数据都不是为了人类读取识别用的，是为系统管理服务存在的，比如ID（有系统甚至是UUID），还有一些空白的数据，或者是其他表格里面关联数据，这些都是识别意义的。 然后再想想，仅仅是系统库里面的数据，就够了么？ 传统数据库里面具备很强的结构化分析能力，通过SQL语句几乎能够完成数据挖掘的工作，所以很多数据不需要存储，而是动态的进行分析和检索。比如空间数据里面的方向、范围、周长、面积等等。但是有些利用空间数据引擎能够很容易做到的事情，全文检索引擎就未必能够很容易的实现了。 那么我们构建检索查询的原则是什么？ 我这里认为，原则就是两个： 1、并非所有数据都需要提供查询检索。 2、一些隐性的数据需要显性的表达。 首先，哪些数据需要提供查询检索呢？原则如下： 1、脱离了上下文，依然有意义的数据，比如名称，比如面积。与之相对的，那些离开了系统就没有意义的编码、ID、外键，直接就不需要提供了。 2、直接使用数据字典里里面的值，而不是用KEY，比如地类图斑里面，地类编码存储的就是012，实际上对于用户来说，认知应该是“水田”，012对于客户来说基本上没有啥意义。 3、对于外键关联里面的数据，直接用数据，比如权属单位编码，这里就一串数字，但是后面还可能会有这个权属单位的全部信息。 其次，哪些隐性的数据，需要进行显性表达呢？ 1、需要使用空间引擎计算的数据，比如空间数据中的位置、方向、范围、周长、面积、要素类型等物理的几何信息。 2、空间关系与拓扑关系的描述信息（如果需要的话） 3、重构真实数据的序列化数据（比如投影坐标系信息串）。 综上所述，我们可以看出，我们用于支持全文检索的全文索引库，只是我们用于存档管理数据的本底数据的一个子集（当然，也有可能是超集），而且全文库中的所有记录，都保有能直接关节到本底库中的原始数据上的关联。  这里说一个题外话，数据的怎么用的问题。这是我以前做系统架构交流时候的一个观点（题外话中的题外话：关于这个系统架构的交流，以后我会找机会放出）。我们怎么设计我们的数据使用方法？正如最前面一个一线架构师说的，我们的查询，给出全库的信息，那么你想查啥就能查啥了…… 这种架构可行么？我可用负责任的告诉大家，不但可行，而且是绝大部分（并发要求低、用户量少、使用频率低）的电子政务系统的主流架构，直接把底层数据库的查询接口暴露出来，或者把查询服务的数据源直接搭在底层核心数据库上…… 优点就是架构师这个活很好干，程序员的工作也很好干，维护的人活也很好干。总之一句话，简单明了，容易实现，而且效果还很不错哦……（领导，你想啥啥都行，直接输入就好了……什么？您要搜的东西没有？哦，那是咱们的数据库里面没有这个数据，不是我们的错） 这种架构设计（如果管这种也能叫架构设计的话），设计一个十个八个用户的系统，或者总共也就百八十万数据的小型系统，当然是没问题，但是如果是一个大中型系统，马上就会死的挺挺的了。 受过最基本的架构设计科普（都不能叫做训练，只要了解过架构设计这个一概念）的同学都知道，如果要提高数据库的效率，最简单好用的方法就是读写分离（负责查询的库和负责写入的库分开，两个库之间通过同步机制完成数据同步），使用一个库来全部支撑整个系统，不是不行，只是没法支撑更复杂的场景而已……比如数据量再大一点，或者需要有全文检索这种需求，单个库的设计，就会直接扛不住了。 所以在全文检索系统的设计中，分离机制是最基础的机制，我把这个叫做取管分析。管，指的是数据的归档和管理，也可以叫做“本底数据库”，我们需要关注这个底层库的一些诸如严密性、持久性、一致性、事务性、安全性等需求，而取（也可以叫做查），我们仅需要关注便捷性和高效性，那些严密性啥的，可以把不由它来负责。二者之间，通过同步机制来继续信息同步。 一句话，叫做“把专业的事情，交给专业的模块来做”  说到这里，有同学说这样的设计虽然提高了系统能力，但是也提高了系统的复杂度，因为从本底库到查询库之间的同步，也增加了系统的一系列风险…… 实际上，这都不是问题，假设你把你的本底库直接开放了，你能控制用户对你的库做啥操作了？写入啥，读取啥？ 而你本底库到查询库之间的同步程序，是你自己写的，哪些需要拉取，哪些不碰，都是既定，这样难道不比不可预测的用户操作安全无数倍么。 在全文索引的数据来源中，我们除了可以管理数据库里面的信息以外，还可以把大量的文件数据也继续管理，针对文件信息，就可以分为内容可解析和内容不可解析。 顾名思义，内容可以解析，就是指文件里面的内容，可以通过计算机编码解读和查询的，比如矢量数据（以Shapefile、GDB、MDB、CAD等为载体的信息），属性数据（dbf、excel、csv等为载体的信息），文本文件数据（word、txt、xml、json等）。 不可解析，自然就是无法通过计算机进行解码和查询的，比如图片（图片里面的信息，比如是个猫还是个兔子，还是个人，计算机无法直接识别……深度学习的问题我们另说，这里指的是一般情况下）、视频、音频等。  那么对于内容可以解析的数据，我们在全文索引库中通过标准模板对信息进行解析和存储，一般来说，可以存储如下内容： 1、元数据 2、解析之后的详细信息 3、文件（或者信息、表、图层）的摘要、预览或者是简介信息。这些信息并非元数据信息，也不是数据本身存在的，很多可能需要通过模型分析或者处理，也可能需要人工方式编写的。 4、静态关联的信息，这个问题后面我们还会详细说明。  而内部不可解析的数据，比如图片、视频这种非结构化的数据，在全文库中保留的数据可以是下面这些： 1、元数据（这个是标准的，任何数据进来都需要有元数据） 2、预览信息（可以通过算法自动实现，比如带有坐标系的图片、九连拍的视频等） 3、关键信息（这个数据可以关联到那些空间或者属性数据上，比如有些图片是带有GPS的） 4、描述信息（同内容可解析的数据的说明）。  最后，在数据中，需要保留一个特有的结构，就是检索权重，这个权重是用来控制查询的时候，信息排序的。 我们进行搜索的时候，同一条件，可能会得到很多信息，哪些信息在前面展现，哪些在后面展现呢？这就需要通过这个权重来控制了。 初始的时候，肯定效果不好，但是随着系统的使用，可以通过访问量、点赞数、描述信息、tag等多种方式，来不断的调整权重，检索的效果也会越来越好。 说到这里，提一个题外话，权重控制信息排序，这个功能在ES的设计中是一个比较重要的功能，当然，不管是不是用ES，我们知道大量信息的分页是开销很大的操作……在ES里面，分页的开销也是很大的，而且越往后翻页，开销越大，所以尽快在前面比较浅的页面上发现需要的数据，是一个提升系统性能的有效方式。  预知后事如何，请听下回分解。 最后还是广告： 有需要的详细咨询了解其中的一些关键的技术细节的同学，可以与虾神单独联系。 联系方式：关注公众号，然后发送2，获取虾神的个人邮箱。 |
|
|
