(云南电网有限责任公司大理供电局 云南大理 671000)
摘要：大理供电局多年来建设了很多业务系统，各业务系统相互孤立应用。随着企业的信息化建设的深入及普遍存在大量的Word、Excel和PDF等文档数据，这些数据是企业生产经营最主要、最普遍的数据组织管理内容，企业众多的生产、经营决策及日常管理也主要依赖这些文档数据开展，员工们查找数据信息极为不便。建设面向整个电网公司的分布式非结构化数据检索平台，该平台在Linux计算机集群上部署OpenStack Swift开发框架以及Solr式全文检索系统，将各业务系统中的非结构化数据进行集中式的存储、管理，并且提供统一的搜索服务，使得企业相关人员能够高效、便捷地检索出所需的数据。实现知识服务无处不在，为员工工作提供帮助，为企业提供决策支持, 以供参考。
关键词：非结构化数据; 分布式；Solr；检索；OpenStack；
一、引言
数据资产是电力企业的宝贵资产，按类型可分为一种是以各类生产系统为代表的结构化数据，另一种是以Word、Excel、PDF、视频、图片文件为代表的非结构化数据。非结构化数据缺乏管理规范，企业内部海量的非结构化数据没有按照各个业务板块的内在联系将其有序规范梳理和存放，数据孤岛现象明显，同时与现存业务系统之间无法有效整合。
另一方面，企业中的文档、视频等非结构化数据在高速增长，根据IDC的调查报告，企业中80%的数据都是非结构化数据，这些数据每年都按指数增长100%，另一方面，非结构化数据管理存在难度高、操作复杂的难题；如何在保障数据安全性、可管理性的前提下，提升文档的使用效率，从而促进企业的安全生产和提升日常办公效率，是摆在供电企业面前的一道难题。
Apache Solr是目前流行的开源搜索服务器，现已能够在计算机集群上提供海量数据的检索服务。在此构建基于OpenStack Swift和Solr的企业级分布式非结构化数据检索平台，企业只需在少量服务器上部署这两种软件框架，就可用较低的成本迅速开始进行大数据集的处理，随后可根据业务需求逐步将集群扩展到更多节点。该平台利用OpenStack上的分布式对象存储系统 Swift以及Solr检索系统实现对海量非结构化数据的分布式存储和检索。
二、企业非结构化数据检索平台架构
企业非结构化数据体量巨大、数据类型繁多，很容易超过单机承载能力，为此搭建起基于OpenStack Swift和Solr的分布式对象存储、检索平台。首先在廉价的PC服务器群上安装Linux操作系统，然后在Linux环境下并行部署 OpenStack Swift以及Solr开发框架，进而设计和开发出该平台。系统集群中，企业非机构化数据分布式存储在 OpenStack Swift的对象存储系统中，相应的检索索引数据则分布在Solr搜索引擎的索引库中。平台解决的主要问题是海量非结构化数据的检索，其特点是文件及其索引信息存储在相同集群不同的逻辑存储结构中。平台的框架结构如图１所示。
图1非结构化数据检索平台框架结构图
用户在相应的客户端中上传文件到平台的分布式对象存储系统 （Swift） 后，Solr的索引处理模块在计算机节点上为大量文件并行创建索引，并将索引及其存储在相应的索引库中。用户在系统中执行搜索操作时，通过平台的负载均衡策略随机登录到分布式云存储中任何一台可用服务器，通过搜索引擎将检索结果合并汇总，最终通过登录到的服务器节点反馈给用户。
三、平台功能及特点
（一）、海量非结构化数据的集中存储
针对大理供电局大量分散的非结构化数据存储的现状，建设该非结构化数据集中存储及检索平台，首先实现分散的非结构化数据的集中存储。企业内非结构化数以及分散在各个员工终端、文件服务器以及各业务系统中。为实现企业非结构化数据的统一管理，平台为不同类型的业务系统提供了具体有效的接入方案，满足多类型业务系统的接入需求，构建起企业级的非结构化数据存储中心，数据的存储结构如图２所示。平台采用OpenStack的Swift集中存储企业非结构化数据，各用户可以对非结构化数据进行共享协作及访问业务系统中的非架构化数据，打破了原来业务系统管理各自非结构化数据的瓶颈，促进了系统间的信息交互。Swift是一个采用层次数据模型，共设三层逻辑结构：Account/Container/Object(账户/容器/对象)。每层节点数均没有限制，可以任意扩展。这里的账户和个人账户不是一个概念，可理解为租户，用来做顶层的隔离机制，可以被多个个人账户所共同使用；容器类似文件夹，代表封装一组对象；对象由元数据和数据两部分组成。
Swift组件包括：
代理服务(ProxyServer)：Swift通过Proxy Server向外提供基于HTTP的REST服务接口，会根据环的信息来查找服务地址并转发用户请求至相应的账户、容器或者对象，进行CRUD(增删改查)等操作。由于采用无状态的REST请求协议，可以进行横向扩展来均衡负载。在访问Swift服务之前，需要先通过认证服务获取访问令牌，然后在发送的请求中加入头部信息 X-Auth-Token。代理服务器负责Swift架构的其余组件间的相互通信。代理服务器也处理大量的失败请求。例如，如果对于某个对象PUT请求时，某个存储节点不可用，它将会查询环可传送的服务器并转发请求。对象以流的形式到达(来自) 对象服务器，它们直接从代理服务器传送到(来自)用户—代理服务器并不缓冲它们。
认证服务(AuthenticationServer)：验证访问用户的身份信息，并获得一个对象访问令牌(Token)，在一定的时间内会一直有效；验证访问令牌的有效性并缓存下来直至过期时间。
缓存服务(Cache Server)：缓存的内容包括对象服务令牌，账户和容器的存在信息，但不会缓存对象本身的数据；缓存服务可采用Memcached集群，Swift会使用一致性哈希算法来分配缓存地址。
账户服务(AccountServer)：提供账户元数据和统计信息，并维护所含容器列表的服务，每个账户的信息被存储在一个SQLite数据库中。
容器服务(ContainerServer)：提供容器元数据和统计信息(比如对象的总数，容器的使用情况等)，并维护所含对象列表的服务。容器服务并不知道对象存在哪，只知道指定容器里存的哪些对象。 这些对象信息以SQLite数据库文件的形式存储，和对象一样在集群上做类似的备份。
对象服务(ObjectServer)：提供对象元数据和内容服务，可以用来存储、检索和删除本地设备上的对象。在文件系统中，对象以二进制文件的形式存储，它的元数据存储在文件系统的扩展属性(xattr)中，建议采用默认支持扩展属性(xattr)的XFS文件系统。每个对象使用对象名称的哈希值和操作的时间戳组成的路径来存储。最后一次写操作总可以成功，并确保最新一次的对象版本将会被处理。删除也被视为文件的一个版本(一个以".ts"结尾的0字节文件，ts表示墓碑)。
复制服务(Replicator)：会检测本地分区副本和远程副本是否一致，具体是通过对比哈希文件和高级水印来完成，发现不一致时会采用推式(Push)更新远程副本：对于对象的复制，更新只是使用rsync同步文件到对等节点。帐号和容器的复制通过HTTP或rsync来推送整个数据库文件上丢失的记录；另外一个任务是确保被标记删除的对象从文件系统中移除：当有一项(对象、容器、或者帐号)被删除，则一个墓碑文件被设置作为该项的最新版本。复制器将会检测到该墓碑文件并确保将它从整个系统中移除。
更新服务(Updater)：当对象由于高负载或者系统故障等原因而无法立即更新时，任务将会被序列化到在本地文件系统中进行排队，以便服务恢复后进行异步更新；例如成功创建对象后容器服务器没有及时更新对象列表，这个时候容器的更新操作就会进入排队中，更新服务会在系统恢复正常后扫描队列并进行相应的更新处理。
审计服务(Auditor)：在本地服务器上会反复地爬取来检查对象，容器和账户的完整性，如果发现比特级的错误，文件将被隔离，并复制其他的副本以覆盖本地损坏的副本；其他类型的错误(比如在任何一个容器服务器中都找不到所需的对象列表)会被记录到日志中。
账户清理服务(AccountReaper)：移除被标记为删除的账户，删除其所包含的所有容器和对象。删除账号的过程是相当直接的。对于每个账号中的容器，每个对象先被删除然后容器被删除。任何失败的删除请求将不会阻止整个过程，但是将会导致整个过程最终失败(例如，如果一个对象的删除超时，容器将不能被删除，因此账号也不能被删除)。整个处理过程即使遭遇失败也继续执行，这样它不会因为一个麻烦的问题而中止恢复集群空间。账号收割器将会继续不断地尝试删除账号直到它最终变为空，此时数据库在db_replicator中回收处理，最终移除这个数据库文件。
图1非结构化数据存储结构图
（二）、非结构化数据搜索引擎服务器Solr中的关键技术
Solr是基于Lucene的开源搜索引擎，它填补了Lucene仅作为开发工具包的遗憾，开箱即用，是一个完整的全文检索服务器。Solr底层的核心技术是使用Lucene实现的，它封装了Lucene定义文档对象、描述文档属性、分析处理文档、索引生成、索引存储等整个索引建立的流程。其主要功能包括强大的全文检索功能，高亮显示检索结果，电子文档（Word、Excel、PDF等）的处理，Solr易于安装和配置。
Solr服务器采用高效的倒排索引组织结构。倒排索引采用面向单词的索引机制，它建立关键词到文件的映射，每个关键词都有一个置入列表来记录该词在所有文档中出现的编号、位置、频率等信息。每个字或词对应的文档是动态变化的，导致倒排索引的建立和维护都较为复杂，但是由于一次查询可以得到包含关键字的所有文档，所以效率较高。在全文检索中，检索的快速响应是最为关键的性能，而索引建立在后台进行，不会影响整个搜索引擎的效率。
Solr/Lucene采用的是一种反向索引，所谓反向索引：就是从关键字到文档的映射过程，保存这种映射这种信息的索引称为反向索引。
字段串列表和文档编号链表两者构成了一个字典。现在想搜索”lucene”，那么索引直接告诉我们，包含有”lucene”的文档有：2，3，10，35，92，而无需在整个文档库中逐个查找。如果是想搜既包含”lucene”又包含”solr”的文档，那么与之对应的两个倒排表去交集即可获得：3、10、35、92。
相关度排序是指通过搜索引擎服务器进行检索后返回结果的排序，检索结果的排序直接反映出相关文档信息与查询条件的相关程度。Solr搜索引擎对查询语句与文档之间的相关性进行打分，分数高的搜索结果相关性好，就应该排在前面。
四、结语
大理供电局公司的非结构化数据迅速膨胀，形成了信息孤岛，人员查找数据极为不便。建设面向整个公司的企业级非结构化数据检索平台，该平台充分利用OpenStack Swift以及Solr两种分布式架构的优越性能，Swift实现了各业务系统海量非结构化数据的集中存储，Solr搜索引擎使得用户可以在统一的资源库中并行索引和搜索文件。提高了文件索引、搜索时的效率，故障转移、数据副本等机制使得平台具有良好的可靠性，且平台扩展性良好，只需简单配置就即可加入新的服务器节点。
参考文献:
[1对象存储 object storage ．TechTarget存储[引用日期2015-05-18].
[2] Solr使用入门指南 ．CSDN.NET[引用日期2014-08-26].
[3]王小森．基于Ｓｏｌｒ的搜索引擎的设计与实现［Ｄ］．北京：北京邮电大学.
论文作者:徐源
论文发表刊物:《电力设备》2018年第25期
论文发表时间:2019/1/21
标签：数据论文; 对象论文; 结构化论文; 索引论文; 容器论文; 文档论文; 平台论文; 《电力设备》2018年第25期论文;