CN110704421A - 数据处理方法、装置、设备和计算机可读存储介质 - Google Patents
数据处理方法、装置、设备和计算机可读存储介质 Download PDFInfo
- Publication number
- CN110704421A CN110704421A CN201810650269.2A CN201810650269A CN110704421A CN 110704421 A CN110704421 A CN 110704421A CN 201810650269 A CN201810650269 A CN 201810650269A CN 110704421 A CN110704421 A CN 110704421A
- Authority
- CN
- China
- Prior art keywords
- data
- retrieval
- basic data
- basic
- index
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种数据处理方法、装置、设备和计算机可读存储介质，该方法包括：根据用于检索的索引数据的元数据的结构定义，生成组件包；从原始数据中提取用于检索的基础数据；按基础数据的对象粒度将基础数据存储到预设的数据库中；从数据库中按对象粒度提取基础数据，根据组件包创建基础数据的索引数据，设置索引数据之间的关联关系后，置入预设的全文检索引擎。根据本发明的技术方案，能够大幅减少数据准备入大数据检索引擎前，数据预处理阶段的工作量。
Description
技术领域
本发明涉及计算机技术领域，尤其涉及一种数据处理方法、装置、设备和计算机可读存储介质。
背景技术
各种社会行业领域的组织，如政府的职能部门，积累了社会上各种行业的数据。随着社会信息化程度的提高，数据种类、数据量增长非常迅速，整个社会都已经进入了大数据时代。面对各类纷繁芜杂的数据查询分析，传统的人力处理已经远远不能满足效率要求，全面信息化的需求越来越强烈。
发明内容
本发明的主要目的在于提出一种数据处理方法、装置、设备和计算机可读存储介质，旨在克服行业检索中数据量巨大、种类众多、分析困难的问题。
为实现上述目的，本发明提供了一种数据处理方法，包括：根据用于检索的索引数据的元数据的结构定义，生成组件包；从原始数据中提取用于检索的基础数据；按所述基础数据的对象粒度将所述基础数据存储到预设的数据库中；从所述数据库中按所述对象粒度提取所述基础数据，根据所述组件包创建所述基础数据的所述索引数据，设置所述索引数据之间的关联关系后，置入预设的全文检索引擎。
为实现上述目的，本发明提供了一种数据处理装置，包括：业务模型构建模块，根据用于检索的索引数据的元数据的结构定义，生成组件包；数据采集模块，从原始数据中提取用于检索的基础数据；大数据计算模块，按所述基础数据的对象粒度将所述基础数据存储到预设的数据库中，以及从所述数据库中按所述对象粒度提取所述基础数据，根据所述组件包创建所述基础数据的所述索引数据，设置所述索引数据之间的关联关系后，置入预设的全文检索引擎。
为实现上述目的，本发明提供了一种数据处理设备，所述数据检索设备包括处理器、存储器和通信总线；所述通信总线用于实现处理器和存储器之间的连接通信；所述处理器用于执行存储器中存储的数据检索程序，以实现前述的数据检索方法的步骤。
为实现上述目的，本发明提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现前述的数据连锁方法的步骤。
根据以上技术方案，可知数据处理方法、装置、设备和计算机可读存储介质至少具有以下优点：
根据本发明的技术方案，在从原始数据中提取出基础数据后，按照基础数据的粒度将基础数据导入数据库，并基于组件包创建数据库中基础数据的索引数据，设置索引数据的关联关系，则在用户进行检索时，可按关联关系查找索引数据，而不需要如现有技术方案对关联的索引数据进行打包，相比于现有技术方案大幅减少了计算量。
附图说明
图1是根据本发明的一个实施例的数据处理方法的流程图；
图2是根据本发明的一个实施例的数据处理系统的流程图；
图3是根据本发明的一个实施例的数据结构的示意图；
图4是根据本发明的一个实施例的数据处理具体实施案例的示意图；
图5是根据本发明的一个实施例的数据处理装置的框图；
图6是根据本发明的一个实施例的数据处理设备的框图。
本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身没有特有的意义。因此，“模块”、“部件”或“单元”可以混合地使用。
如图1所示，本发明的一个实施例中一种数据处理方法，包括：
步骤S110，根据用于检索的索引数据的元数据的结构定义，生成组件包。
在本实施例中，根据各地定制的行业的业务模型，并按照对象的方式构建全文检索索引，支持用户按照对象进行全文检索的需求。业务模型是各地的行业的定制化组件包，根据行业的真实数据模型现场定制，是配置和脚本文件的集合，所以此类定制可落在现场实施阶段，在无需修改系统功能框架的情况下，接入现场组件包，达到适配各地业务模型的目标。
步骤S120，从原始数据中提取用于检索的基础数据。
在本实施例中，以公安行业为例，原始数据包括公安内部各部门的数据、社会数据、运营商数据等，种类众多，是需要综合检索的数据源头。在本实施例中，行业模型是从各类原始数据中总结提炼出来的，需要对原始数据做部分数据清洗整合，由于数据来源于不同的应用系统，所以需要同时负责与各个系统接口适配，以完成数据采集。
步骤S130，按基础数据的对象粒度将基础数据存储到预设的数据库中。
在本实施例中，对对象的粒度大小不进行限制，一般地，对象的粒度取决于对象本身的结构，例如，某对象具有多个维度，则可以按维度设置粒度大小，每个维度下有多个属性，也可以按属性设置粒度大小。在本实施例中，采用的数据库通常为列式数据库，也可以是其他适用于大数据检索的数据库。
步骤S140，从数据库中按对象粒度提取基础数据，根据组件包创建基础数据的索引数据，设置索引数据之间的关联关系后，置入预设的全文检索引擎。
在本实施例中，为支持全文检索需要引入全文检索引擎，为支持对象全文检索需要引入列式数据库，本实施例的技术方案基于大数据集群实现，采集的基础数据可存储在大数据集群中。
使用所述全文检索引擎，根据检索关键词查找具有关联关系的索引数据，将查找结果对应的基础数据作为检索结果。
在本实施例中，可根据各个行业的用户使用习惯，总结出来可供用户使用的、根据个人需求进行个性化定制的功能，包括查询方案配置、属性枚举配置、属性排序配置、异常标签配置、自定义标签配合以及部分“定制化检索功能”，对用户的检索行为实现定制化。在本实施例中，为满足各地用户的使用习惯差异，检索引擎要与“用户定制”结合使用，可达到满足用户各类需求的目标。
根据本实施例的技术方案，在从原始数据中提取出基础数据后，按照基础数据的粒度将基础数据导入列式数据库，并基于组件包创建列式数据库中基础数据的索引数据，设置索引数据的关联关系，则在用户进行检索时，可按关联关系查找索引数据，而不需要如现有技术方案对关联的索引数据进行打包，相比于现有技术方案大幅减少了计算量。
如图2所示，本发明的一个实施例中一种数据处理方法，包括：
步骤S210，根据元数据的结构定义、元数据的对象与要素之间的关系、元数据的对象与数据表之间的关系，生成组件包。
基于本实施例的技术方案，可以实现一种检索系统。在本实施例中，
定义各地组件包。以公安领域为例，一个地方的公安版本，包含唯一的组件包加系统框架构成。组件包中定义的内容如下：
1)检索引擎所需的索引数据元数据结构定义。检索引擎中的数据以doc(文档)的方式存储在全文检索引擎中，例如在公安领域，对应的是公安各地的真实数据结构，遵循公安厅标准又高于标准，包含地方特有的数据结构，具体如图3所示。索引元数据文件要求：
a)用户提供现场实际数据结构定义，作为局方办公人员，提供的形式为excel、word(不限于以上文档格式)办公软件编辑的文档资料，需按一定模板结构提供。
b)通过预设的独立的工具读取数据模板，生成索引元数据文件，存在形式为结构化的xml、json(不限于以上脚本格式)脚本文件。
c)索引元数据文件系统在启动时加载，并提供热加载功能，注入到系统中实时生效。
d)遵循检索引擎的平铺存储定义，将多数据源进行平铺定义，为支持后续的数据源的对象关联，在文件定义中定义功能字段作为对象分类标识。
e)需定义对应原始数据源级别的field(即字段)字段、归一字段，归一字段是各个field字段的复制并拼接，也是实现全文检索的必须字段。
2)要素-对象定义，要素是对象的大的归类，用于更好地管理对象，例如在公安领域内通常分为公安五要素：人员、物品、案件、机构、地址。
规则定义描述：
a)同样通过xml格式(不限于xml格式)等类型的脚本文件体现，本装置以xml文件格式进行体现。
b)主要元素包含elements、element、object(不限于此名称)三层，分别对应要素、单个要素、对象三层定义。
c)element(不限于此名称)：要素定义。定义elementType(不限于此名称)：要素的种类，按照五要素的定义，取值为1～5；每种要素在在后续的对象组织阶段的列式数据库系统中中对应一个唯一的数据库，定义dbname(不限于此名称)用来描述数据库名称。
d)object(不限于此名称)：对象定义。定义schematype(不限于此名称)用来描述对象的唯一标识，定义describeName(不限于此名称)为对象描述。对象由多个基础数据表组成，majorTableName(不限于此名称)为对象主表，在对象主表中，一个对象是唯一存在的。
3)对象-数据表定义，一个对象是多个基础数据表的集合，区分主表和子表，在对象子表中，一个对象可存在多条数据记录。
规则定义描述：
a)同样通过xml格式(不限于xml格式)等类型的脚本文件体现，本装置以xml文件格式进行体现。
b)主要元素包含objrelations、objrelation、relationTable、relfield(不限于此名称)四层，分别对应对象集、对象、数据表、管理属性三层描述。
c)objrelation(不限于此名称)：对象存储和主表定义。定义dbname(不限于此名称)标识对象所归属的数据库，定义Majortablename(不限于此名称)为对象的主表标识。
a)relationTable(不限于此名称)：定义对象包含的基础数据表列表。定义dbname(不限于此名称)标识了原始表所在的数据库，通常与对象主表所在的数据库一致，定义tablename(不限于此名称)唯一标识归属该对象的基础数据表，表名全局唯一。
b)relfield(不限于此名称)：为数据表之间的关联字段定义，数据表要能归为一类对象，定义srcfield(不限于此名称)标识本数据表中用于关联的关键字，定义descfield(不限于此名称)标识主表被关联的字段。数据表间支持多关键字，多relfield(不限于此名称)关联，为获取更高的关联效率，推荐采用单关键字，多关键字到单关键字的转换可在ETL(抽取、交互转换、加载)阶段进行预处理。
4)查询方案配置定义：包括对象组织所需的列式数据库定义分区定义，可根据数据量进行分区数的动态调整。用户在查询时，在用户查询时返回的主子表顺序定义，单个对象主子表的排序字段，日期等特殊字段的页面显示格式等，用于提升用户查询的体验。
a)本装置以数据库表(不限于数据库表)的方式定义体现。
b)定义byorder(不限于此名称)字段用于基础数据表之间的排序。
c)定义object-regions(不限于此名称)用于标识各个对象表的分区，可根据现场实际情况调整定义。
步骤S220，通过预设的规则，对原始数据进行清洗转换，得到基础数据。
在本实施例中，数据采集ETL是与各个业务系统对接的前端数据采集组件。输入是各业务系统，所以要求系统提供丰富的数据采集接口。输出是本系统所需的基础数据表，要求对从业务系统采集的原始数据进行清洗转换，所以要求提供丰富的数据转换组件，对来自各个分散业务系统的数据进行清洗转换，生成符合系统需要的基础数据。
1)根据组件包中的定义，数据采集ETL定制清洗转换规则，输出的数据文件结构和业务包中的索引文件元数据定义中的字段保证对应关系。
2)支持本系统需要的通用清洗规则，包括(不限于以下规则)：
a)字段名称转换，将源数据表中的字段名输出为与业务包中的字段定义，相同含义的字段统一字段名输出。
b)统一日期格式，转换为搜索引擎可识别的日期格式，为后续的日期检索准备好原始数据。
c)主表数据抽取，保证对象的唯一性，进行数据清洗，清除非法数据。
d)子表的抽取与主表关联抽取，如子表中缺少关键字段，需关联主表查询，进行关联字段反填输出到子表文件中。
e)回车换行，空行的预处理，保证符合特定的操作系统要求。
步骤S230，将基础数据存储到预设的大数据集群的文件系统中。
在本实施例中，通过ETL清洗转换后的数据，输出至大数据集群的文件系统(HDFS或类似的大数据文件存储系统)，保证在存储上的可扩展性、后续的系统处理的时效性。与组件包中的定义对应，输出的文件有统一的目录规划，目录规划为/地方名称/要素。每个要素在后续的列式数据库系统中对应唯一数据库。
步骤S240，从大数据集群的文件系统中提取基础数据，并根据组件包中索引数据的元数据的结构定义，按基础数据的对象粒度导入数据库中。
步骤S250，从数据库中按对象粒度提取基础数据，根据组件包创建基础数据的索引数据，设置索引数据之间的关联关系后，置入预设的全文检索引擎。
在本实施例中，从业务包中加载元数据定义，再从大数据文件系统中加载基础数据，两边对应进行分布式计算，完成从基础数据到全文检索组件的索引创建功能。本装置采用MR(不限于MR，还可采用Spark，均为计算框架)计算框架完成从基础数据—对象存储—对象索引整个索引创建过程。
在本实施例中，计算框架第一步计算，是将基础数据按照原始数据库表粒度逐一入列式数据库。
1)本系统采用分布式列式HBASE(不限于HBASE，可采用其他开源或者闭源数据库)列式数据库组织对象，
2)以基础数据表的粒度创建独立的任务，将对象关联的所有基础数据，逐一入库。
3)结合HBASE的多version特性，存储归属于指定对象在某个基础数据子表中的多条记录。
4)列式数据库的存储特性，可在对象的规模有变更时，在原有对象的基础上进行增量变更，不影响既有对象已入库的数据，系统提供增量索引创建任务满足此类需求。变更分为两种：
a)元数据变更，例如在公安领域尤其是对象的数据表和字段有增加，这个涉及到组件包的增量变更。
b)数据变更，例如在公安领域内的好多数据是增量数据，如某个人的火车出行、飞机出行记录。
在本实施例中，基于全文检索引擎的平铺特性，在查询时也是以平铺doc的结构返回检索结果。如需要返回某个对象，针对全文检索引擎就转换为返回多个关联的doc，要达成这个目标，必须在索引创建时，将关联的doc打包创建索引。但是在海量数据的情况下，一个对象涉及的数据表成百上千，无法通过传统手段完成的。而在本实施例中，对象已经在列式数据库中准备完成，调用计算框架进行第二步计算，从列式数据库中按照对象粒度提取数据集，结合读取业务包中的索引元数据定义，将基础数据入全文检索引擎，创建索引。
a)列式数据库(本系统为HBASE)中唯一的rowkey(列式数据库中的一项数据)能够标识唯一对象，大数据计算框架从HBASE中获取某个rowkey的数据集，能够提取单个对象的全部数据集；
b)按照对象粒度组织数据集，入全文检索引擎SOLR(不限于SOLR，还可采用ElasticSearch，均为搜索引擎)创建索引，每个基础数据表的一条记录，对应索引中的一个doc，通过全文检索引擎为每个doc新增一个属性，作为doc间的关联属性，通过该关联属性将多个doc关联起来，保证在全文检索引擎中多个doc的关联关系。
使用所述全文检索引擎，根据检索关键词查找具有关联关系的索引数据，将查找结果对应的基础数据作为检索结果。
在本实施例中，全文检索引擎入库时保证了对象的完整性，在检索时，按照doc关联语法能够提取归属某个对象的唯一档案。用户使用对象检索，输入要检索的文本，会提取匹配的归一化的对象列表，即用户输入自己关心的任何信息，都可以作为检索关键字提取到归一化的对象列表。点击唯一的对象，可进一步查看归属该对象的全景档案，档案中全面展示了对象的所有信息，即该对象全景档案，档案中包含了该对象相关的所有的基础数据。进一步地，本实施例提供方案配置功能，在方案配置中，如用户感觉某些信息字段不关注，或者特别关注某些信息字段，可通过方案配置为动态调节，刷新网页即可更新。
本实施例的技术方案，与现有技术相比：
1)解决了海量数据对象检索的难题，采用全文检索引擎组件，此类组件为达成高效的检索效率，数据在物理存储上是平铺结构，在不改变物理存储的同时，在逻辑上能够按照对象检索。根据各个大数据组件的特性，有效组合，完成海量数据下的对象档案一张图一键检索的功能。
2)具有高实用性和灵活性，框架主流程和业务包分离，即流程系统和业务数据分离。业务包包含了业务数据，属于各个实施地特性化的部分，通过配置和脚本实现，注入流程系统后立即生效，在现场实施阶段即可完成。在框架主流程不变的情况下，只需注入不同的业务包，可快速适配当地业务需求。
3)具有很高的横向扩展性，基于大数据技术组件实现，检索效率更高，大数据本身的分布式扩展特性，数据量的现有容量和扩展性都能兼顾到。
4)功能上检索更精准。可推广性高，基于标准提取公安行业模型，贴近行业业务场景下的检索，检索更精准。
5)具有可推广性，除公安领域外，可扩展到有类似需求(在海量、种类繁多的数据中按照对象逻辑一键提取对象档案)的其他行业领域。
基于本实施例技术方案的一个具体示例如图4所示：
1、首先永州组件包，并设置要素-对象关系定义、对象-数据表定义。
2、进行数据采集ETL(Extract-Transform-Load，抽取、交互转换、加载)，采集常住人口表的规则总结如下：
1)子表原始字段SFZH修改为GMSFHM，统一公民身份证号码字段含义；
2)按照SFZH去空；
3)人员基本信息表，作为人员主表，按照SFZH去重，保留最新登记的记录，清洗掉过期记录；
4)日期字段格式转为yyyy-MM-dd HH:mm:ss，BigNumber和Integer字段格式为#；
3、进行基础数据存储。
4、进行大数据计算组件，根据调用MR(映射归约)大数据计算组件，设定几类计算任务：
1)import任务：单个基础数据表粒度，从提取HDFS(Hadoop分布式文件系统)上的数据集，入HBASE。
2)indexingFromHBase任务：单个基础数据入库，从HBASE中按照对象粒度提取数据集入SOLR，创建数据索引。
3)indexingAllFromHBase任务：全量数据入库，在单表数据入库的基础上改造，加快索引创建效率，适用于已经准备好所有的基础数据，需要批量创建索引文件的场景。
4)Increment任务：增量任务，用于触发某个基础数据表的数据量随着时间粒度有增量需求的场景。如某个车辆的过卡口情况，能达到分钟级的更新，需要保证对已创建索引的数据无影响的情况下，为这些增量数据创建增量索引。
5、框架调用组件包中的定义，触发通用的MR任务。
6、如用户检索“G302车次”想获取跟这辆火车相关的人员对象，输入检索关键字G302，实现对象检索。
7、用户输入关键字查询后，则可查到乘坐该车次的人员列表，检索出100个人员对象乘坐过该车次，关注其中某个身份证编号为“430404196807******”的人员对象，进一步点击查看档案，可查看该人员的全景档案，包括人员的基本信息、婚姻状况、同户人员、乘车记录等全景档案。如用户对提取出的人员基本信息中的监护人姓名字段不关注，则在方案配置中配置为隐藏，刷新页面即可看到该信息已隐藏。
通过上述示例，可知本实施例的技术方案有利于解决行业检索中，数据量巨大，种类众多，分析困难、经验无法积累的问题。具备以下特点：
1)根据行业标准规范(例如在公安领域，要求按照公安标准行业规范)，并丰富标准规范，引入了一套要素-对象-数据表-属性的多层管理模型；
2)由于各地行业的标准，基于基础标准，又有各自的特色业务，业务模型以独立的组件包方式存在，组件包中包含了模型的元数据、数据表关系、对象主键等构建对象需要的各类定义，通过各地适配的组件包，系统框架可达到在各地快速适配和复制的目标。
3)基于大数据技术实现基于大数据的特性实现，可满足如公安行业的大数据量和高效处理的目标；
4)模型分标准化部分和特性化部分，支持修正和灵活扩展，迭代修正以更好的满足各地特色业务。
5)按照模型组织的对象提供通用的对外服务，可提供给第三方系统使用。
当前，海量数据的处理必然依赖大数据技术，例如在公安领域，行业的特性决定了针对具体业务，必须基于大数据又高于大数据，每个大数据组件都有自己的使用场景，对象的概念是在传统关系数据库分析领域是比较普遍的解决方案，但也正是这种复杂的对象组合限制了传统数据库的检索效率，本实施例的技术方案将数据之间的关系平铺处理，以便达到更高的检索效率。作为行业需求，既要业务模型(即数据间的关系)，又要兼顾检索效率。本实施例的技术方案，还提供了业务组件包和框架分离的方式，通过业务组件包进行数据注入，保证主框架的稳定性的情况下，提供多种业务场景的适配。
如图5所示，本发明的一个实施例中一种数据处理装置，包括：
业务模型构建模块510，根据用于检索的索引数据的元数据的结构定义，生成组件包。
在本实施例中，根据各地定制的行业的业务模型，并按照对象的方式构建全文检索索引，支持用户按照对象进行全文检索的需求。业务模型是各地的行业的定制化组件包，根据行业的真实数据模型现场定制，是配置和脚本文件的集合，所以此类定制可落在现场实施阶段，在无需修改系统功能框架的情况下，接入现场组件包，达到适配各地业务模型的目标。
数据采集模块520，从原始数据中提取用于检索的基础数据。
在本实施例中，以公安行业为例，原始数据包括公安内部各部门的数据、社会数据、运营商数据等，种类众多，是需要综合检索的数据源头。在本实施例中，行业模型是从各类原始数据中总结提炼出来的，需要对原始数据做部分数据清洗整合，由于数据来源于不同的应用系统，所以需要同时负责与各个系统接口适配，以完成数据采集。
大数据计算模块530，按基础数据的对象粒度将基础数据存储到预设的数据库中，从数据库中按对象粒度提取基础数据，根据组件包创建基础数据的索引数据，设置索引数据之间的关联关系后，置入预设的全文检索引擎。
在本实施例中，为支持全文检索需要引入全文检索引擎，为支持对象全文检索需要引入列式数据库，本实施例的技术方案基于大数据集群实现，采集的基础数据可存储在大数据集群中。
使用所述全文检索引擎，根据检索关键词查找具有关联关系的索引数据，将查找结果对应的基础数据作为检索结果。
在本实施例中，可根据公安行业的用户使用习惯，总结出来可供用户使用的、根据个人需求进行个性化定制的功能，包括查询方案配置、属性枚举配置、属性排序配置、异常标签配置、自定义标签配合以及部分“定制化检索功能”，对用户的检索行为实现定制化。在本实施例中，为满足各地用户的使用习惯差异，检索引擎要与“用户定制”结合使用，可达到满足用户各类需求的目标。
根据本实施例的技术方案，在从原始数据中提取出基础数据后，按照基础数据的粒度将基础数据导入列式数据库，并基于组件包创建列式数据库中基础数据的索引数据，设置索引数据的关联关系，则在用户进行检索时，可按关联关系查找索引数据，而不需要如现有技术方案对关联的索引数据进行打包，相比于现有技术方案大幅减少了计算量。
如图5所示，本发明的一个实施例中一种数据处理装置，包括：
业务模型构建模块510，根据元数据的结构定义、元数据的对象与要素之间的关系、元数据的对象与数据表之间的关系，生成组件包。
基于本实施例的技术方案，可以实现一种检索系统。在本实施例中，
定义各地组件包。以公安领域为例，一个地方的公安版本，包含唯一的组件包加系统框架构成。组件包中定义的内容如下：
1)检索引擎所需的索引数据元数据结构定义。检索引擎中的数据以doc(文档)的方式存储在全文检索引擎中，例如在公安领域，对应的是公安各地的真实数据结构，遵循公安厅标准又高于标准，包含地方特有的数据结构，具体如图3所示。索引元数据文件要求：
a)用户提供现场实际数据结构定义，作为局方办公人员，提供的形式为excel、word(不限于以上文档格式)办公软件编辑的文档资料，需按一定模板结构提供。
b)通过预设的独立的工具读取数据模板，生成索引元数据文件，存在形式为结构化的xml、json(不限于以上脚本格式)脚本文件。
c)索引元数据文件系统在启动时加载，并提供热加载功能，注入到系统中实时生效。
d)遵循检索引擎的平铺存储定义，将多数据源进行平铺定义，为支持后续的数据源的对象关联，在文件定义中定义功能字段作为对象分类标识。
e)需定义对应原始数据源级别的field(即字段)字段、归一字段，归一字段是各个field字段的复制并拼接，也是实现全文检索的必须字段。
2)要素-对象定义，要素是对象的大的归类，用于更好地管理对象，例如在公安领域内通常分为公安五要素：人员、物品、案件、机构、地址。
规则定义描述：
a)同样通过xml格式(不限于xml格式)等类型的脚本文件体现，本装置以xml文件格式进行体现。
b)主要元素包含elements、element、object(不限于此名称)三层，分别对应要素、单个要素、对象三层定义。
c)element(不限于此名称)：要素定义。定义elementType(不限于此名称)：要素的种类，按照五要素的定义，取值为1～5；每种要素在在后续的对象组织阶段的列式数据库系统中中对应一个唯一的数据库，定义dbname(不限于此名称)用来描述数据库名称。
d)object(不限于此名称)：对象定义。定义schematype(不限于此名称)用来描述对象的唯一标识，定义describeName(不限于此名称)为对象描述。对象由多个基础数据表组成，majorTableName(不限于此名称)为对象主表，在对象主表中，一个对象是唯一存在的。
3)对象-数据表定义，一个对象是多个基础数据表的集合，区分主表和子表，在对象子表中，一个对象可存在多条数据记录。
规则定义描述：
a)同样通过xml格式(不限于xml格式)等类型的脚本文件体现，本装置以xml文件格式进行体现。
b)主要元素包含objrelations、objrelation、relationTable、relfield(不限于此名称)四层，分别对应对象集、对象、数据表、管理属性三层描述。
c)objrelation(不限于此名称)：对象存储和主表定义。定义dbname(不限于此名称)标识对象所归属的数据库，定义Majortablename(不限于此名称)为对象的主表标识。
a)relationTable(不限于此名称)：定义对象包含的基础数据表列表。定义dbname(不限于此名称)标识了原始表所在的数据库，通常与对象主表所在的数据库一致，定义tablename(不限于此名称)唯一标识归属该对象的基础数据表，表名全局唯一。
b)relfield(不限于此名称)：为数据表之间的关联字段定义，数据表要能归为一类对象，定义srcfield(不限于此名称)标识本数据表中用于关联的关键字，定义descfield(不限于此名称)标识主表被关联的字段。数据表间支持多关键字，多relfield(不限于此名称)关联，为获取更高的关联效率，推荐采用单关键字，多关键字到单关键字的转换可在ETL(抽取、交互转换、加载)阶段进行预处理。
4)查询方案配置定义：包括对象组织所需的列式数据库定义分区定义，可根据数据量进行分区数的动态调整。用户在查询时，在用户查询时返回的主子表顺序定义，单个对象主子表的排序字段，日期等特殊字段的页面显示格式等，用于提升用户查询的体验。
a)本装置以数据库表(不限于数据库表)的方式定义体现。
b)定义byorder(不限于此名称)字段用于基础数据表之间的排序。
c)定义object-regions(不限于此名称)用于标识各个对象表的分区，可根据现场实际情况调整定义。
数据采集模块520，通过预设的规则，对原始数据进行清洗转换，得到基础数据。
在本实施例中，数据采集ETL是与各个业务系统对接的前端数据采集组件。输入是各业务系统，所以要求系统提供丰富的数据采集接口。输出是本系统所需的基础数据表，要求对从业务系统采集的原始数据进行清洗转换，所以要求提供丰富的数据转换组件，对来自各个分散业务系统的数据进行清洗转换，生成符合系统需要的基础数据。
1)根据组件包中的定义，数据采集ETL定制清洗转换规则，输出的数据文件结构和业务包中的索引文件元数据定义中的字段保证对应关系。
2)支持本系统需要的通用清洗规则，包括(不限于以下规则)：
a)字段名称转换，将源数据表中的字段名输出为与业务包中的字段定义，相同含义的字段统一字段名输出。
b)统一日期格式，转换为搜索引擎可识别的日期格式，为后续的日期检索准备好原始数据。
c)主表数据抽取，保证对象的唯一性，进行数据清洗，清除非法数据。
d)子表的抽取与主表关联抽取，如子表中缺少关键字段，需关联主表查询，进行关联字段反填输出到子表文件中。
e)回车换行，空行的预处理，保证符合特定的操作系统要求。
步骤S230，将基础数据存储到预设的大数据集群的文件系统中。
在本实施例中，通过ETL清洗转换后的数据，输出至大数据集群的文件系统(HDFS或类似的大数据文件存储系统)，保证在存储上的可扩展性、后续的系统处理的时效性。与组件包中的定义对应，输出的文件有统一的目录规划，目录规划为/地方名称/要素。每个要素在后续的列式数据库系统中对应唯一数据库。
大数据计算模块530，从大数据集群的文件系统中提取基础数据，并根据组件包中索引数据的元数据的结构定义，按基础数据的对象粒度导入数据库中，以及从数据库中按对象粒度提取基础数据，根据组件包创建基础数据的索引数据，设置索引数据之间的关联关系后，置入预设的全文检索引擎。
在本实施例中，从业务包中加载元数据定义，再从大数据文件系统中加载基础数据，两边对应进行分布式计算，完成从基础数据到全文检索组件的索引创建功能。本装置采用MR(不限于MR，还可采用Spark，均为计算框架)计算框架完成从基础数据—对象存储—对象索引整个索引创建过程。
在本实施例中，计算框架第一步计算，是将基础数据按照原始数据库表粒度逐一入列式数据库。
1)本系统采用分布式列式HBASE(不限于HBASE，可采用其他开源或者闭源数据库)列式数据库组织对象，
2)以基础数据表的粒度创建独立的任务，将对象关联的所有基础数据，逐一入库。
3)结合HBASE的多version特性，存储归属于指定对象在某个基础数据子表中的多条记录。
4)列式数据库的存储特性，可在对象的规模有变更时，在原有对象的基础上进行增量变更，不影响既有对象已入库的数据，系统提供增量索引创建任务满足此类需求。变更分为两种：
a)元数据变更，例如在公安领域尤其是对象的数据表和字段有增加，这个涉及到组件包的增量变更。
b)数据变更，公安领域内的好多数据是增量数据，如某个人的火车出行、飞机出行记录。
在本实施例中，基于全文检索引擎的平铺特性，在查询时也是以平铺doc的结构返回检索结果。如需要返回某个对象，针对全文检索引擎就转换为返回多个关联的doc，要达成这个目标，必须在索引创建时，将关联的doc打包创建索引。但是在海量数据的情况下，一个对象涉及的数据表成百上千，我们是无法通过传统手段完成的。而在本实施例中，对象已经在列式数据库中准备完成，调用计算框架进行第二步计算，从列式数据库中按照对象粒度提取数据集，结合读取业务包中的索引元数据定义，将基础数据入全文检索引擎，创建索引。
a)列式数据库(本系统为HBASE)中唯一的rowkey(列式数据库中的一项数据)能够标识唯一对象，大数据计算框架从HBASE中获取某个rowkey的数据集，能够提取单个对象的全部数据集；
b)按照对象粒度组织数据集，入全文检索引擎SOLR(不限于SOLR，还可采用ElasticSearch，均为搜索引擎)创建索引，每个基础数据表的一条记录，对应索引中的一个doc，通过全文检索引擎为每个doc新增一个属性，作为doc间的关联属性，通过该关联属性将多个doc关联起来，保证在全文检索引擎中多个doc的关联关系。
使用所述全文检索引擎，根据检索关键词查找具有关联关系的索引数据，将查找结果对应的基础数据作为检索结果。
在本实施例中，全文检索引擎入库时保证了对象的完整性，在检索时，按照doc关联语法能够提取归属某个对象的唯一档案。用户使用对象检索，输入要检索的文本，会提取匹配的归一化的对象列表，即用户输入自己关心的任何信息，都可以作为检索关键字提取到归一化的对象列表。点击唯一的对象，可进一步查看归属该对象的全景档案，档案中全面展示了对象的所有信息，即该对象全景档案，档案中包含了该对象相关的所有的基础数据。进一步地，本实施例提供方案配置功能，在方案配置中，如用户感觉某些信息字段不关注，或者特别关注某些信息字段，可通过方案配置为动态调节，刷新网页即可更新。
本实施例的技术方案，与现有技术相比：
1)解决了海量数据对象检索的难题，采用全文检索引擎组件，此类组件为达成高效的检索效率，数据在物理存储上是平铺结构，在不改变物理存储的同时，在逻辑上能够按照对象检索。根据各个大数据组件的特性，有效组合，完成海量数据下的对象档案一张图一键检索的功能。
2)具有高实用性和灵活性，框架主流程和业务包分离，即流程系统和业务数据分离。业务包包含了业务数据，属于各个实施地特性化的部分，通过配置和脚本实现，注入流程系统后立即生效，在现场实施阶段即可完成。在框架主流程不变的情况下，只需注入不同的业务包，可快速适配当地业务需求。
3)具有很高的横向扩展性，基于大数据技术组件实现，检索效率更高，大数据本身的分布式扩展特性，数据量的现有容量和扩展性都能兼顾到。
4)功能上检索更精准。可推广性高，基于标准提取公安行业模型，贴近行业业务场景下的检索，检索更精准。
5)具有可推广性，除公安领域外，可扩展到有类似需求(在海量、种类繁多的数据中按照对象逻辑一键提取对象档案)的其他行业领域。
基于本实施例技术方案的一个具体示例如图4所示：
1、首先永州组件包，并设置要素-对象关系定义、对象-数据表定义。
2、进行数据采集ETL，采集常住人口表的规则总结如下：
1)子表原始字段SFZH修改为GMSFHM，统一公民身份证号码字段含义；
2)按照SFZH去空；
3)人员基本信息表，作为人员主表，按照SFZH去重，保留最新登记的记录，清洗掉过期记录；
4)日期字段格式转为yyyy-MM-dd HH:mm:ss，BigNumber和Integer字段格式为#；
3、进行基础数据存储。
4、进行大数据计算组件，根据调用MR大数据计算组件，设定几类计算任务：
1)import任务：单个基础数据表粒度，从提取HDFS上的数据集，入HBASE
2)indexingFromHBase任务：单个基础数据入库，从HBASE中按照对象粒度提取数据集入SOLR，创建数据索引。
3)indexingAllFromHBase任务：全量数据入库，在单表数据入库的基础上改造，加快索引创建效率，适用于已经准备好所有的基础数据，需要批量创建索引文件的场景。
4)Increment任务：增量任务，用于触发某个基础数据表的数据量随着时间粒度有增量需求的场景。如某个车辆的过卡口情况，能达到分钟级的更新，需要保证对已创建索引的数据无影响的情况下，为这些增量数据创建增量索引。
5、框架调用组件包中的定义，触发通用的MR任务。
6、如用户检索“G302车次”想获取跟这辆火车相关的人员对象，输入检索关键字G302，实现对象检索。
7、用户输入关键字查询后，则可查到乘坐该车次的人员列表，检索出100个人员对象乘坐过该车次，关注其中某个身份证编号为“430404196807******”的人员对象，进一步点击查看档案，可查看该人员的全景档案，包括人员的基本信息、婚姻状况、同户人员、乘车记录等全景档案。如用户对提取出的人员基本信息中的监护人姓名字段不关注，则在方案配置中配置为隐藏，刷新页面即可看到该信息已隐藏。
通过上述示例，可知本实施例的技术方案有利于解决行业检索中，数据量巨大，种类众多，分析困难、经验无法积累的问题。具备以下特点：
1)根据行业标准规范(例如在公安领域，要求按照公安标准行业规范)，并丰富标准规范，引入了一套要素-对象-数据表-属性的多层管理模型；
2)由于各地行业的标准，基于基础标准，又有各自的特色业务，业务模型以独立的组件包方式存在，组件包中包含了模型的元数据、数据表关系、对象主键等构建对象需要的各类定义，通过各地适配的组件包，系统框架可达到在各地快速适配和复制的目标。
3)基于大数据技术实现基于大数据的特性实现，可满足如公安行业的大数据量和高效处理的目标；
4)模型分标准化部分和特性化部分，支持修正和灵活扩展，迭代修正以更好的满足各地特色业务。
5)按照模型组织的对象提供通用的对外服务，可提供给第三方系统使用。
当前，海量数据的处理必然依赖大数据技术，例如在公安领域，行业的特性决定了针对具体业务，必须基于大数据又高于大数据，每个大数据组件都有自己的使用场景，对象的概念是在传统关系数据库分析领域是比较普遍的解决方案，但也正是这种复杂的对象组合限制了传统数据库的检索效率，本实施例的技术方案将数据之间的关系平铺处理，以便达到更高的检索效率。作为行业需求，既要业务模型(即数据间的关系)，又要兼顾检索效率。本实施例的技术方案，还提供了业务组件包和框架分离的方式，通过业务组件包进行数据注入，保证主框架的稳定性的情况下，提供多种业务场景的适配。
如图6所示，本发明的一个实施例中一种数据处理设备，数据检索设备包括处理器610、存储器620和通信总线630；通信总线610用于实现处理器610和存储器620之间的连接通信；处理器610用于执行存储器620中存储的数据检索程序，以实现以下的步骤：
根据用于检索的索引数据的元数据的结构定义，生成组件包。
在本实施例中，根据各地定制的行业的业务模型，并按照对象的方式构建全文检索索引，支持用户按照对象进行全文检索的需求。业务模型是各地的行业的定制化组件包，根据行业的真实数据模型现场定制，是配置和脚本文件的集合，所以此类定制可落在现场实施阶段，在无需修改系统功能框架的情况下，接入现场组件包，达到适配各地业务模型的目标。
从原始数据中提取用于检索的基础数据。
在本实施例中，以公安行业为例，原始数据包括公安内部各部门的数据、社会数据、运营商数据等，种类众多，是需要综合检索的数据源头。在本实施例中，行业模型是从各类原始数据中总结提炼出来的，需要对原始数据做部分数据清洗整合，由于数据来源于不同的应用系统，所以需要同时负责与各个系统接口适配，以完成数据采集。
按基础数据的对象粒度将基础数据存储到预设的数据库中。
从数据库中按对象粒度提取基础数据，根据组件包创建基础数据的索引数据，并设置索引数据之间的关联关系后，置入预设的全文检索引擎。
在本实施例中，为支持全文检索需要引入全文检索引擎，为支持对象全文检索需要引入列式数据库，本实施例的技术方案基于大数据集群实现，采集的基础数据可存储在大数据集群中。
使用所述全文检索引擎，根据检索关键词查找具有关联关系的索引数据，将查找结果对应的基础数据作为检索结果。
在本实施例中，可根据公安行业的用户使用习惯，总结出来可供用户使用的、根据个人需求进行个性化定制的功能，包括查询方案配置、属性枚举配置、属性排序配置、异常标签配置、自定义标签配合以及部分“定制化检索功能”，对用户的检索行为实现定制化。在本实施例中，为满足各地用户的使用习惯差异，检索引擎要与“用户定制”结合使用，可达到满足用户各类需求的目标。
根据本实施例的技术方案，在从原始数据中提取出基础数据后，按照基础数据的粒度将基础数据导入列式数据库，并基于组件包创建列式数据库中基础数据的索引数据，设置索引数据的关联关系，则在用户进行检索时，可按关联关系查找索引数据，而不需要如现有技术方案对关联的索引数据进行打包，相比于现有技术方案大幅减少了计算量。
本发明的一个实施例中还提供一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行以下的步骤：
根据用于检索的索引数据的元数据的结构定义，生成组件包。
在本实施例中，根据各地定制的行业的业务模型，并按照对象的方式构建全文检索索引，支持用户按照对象进行全文检索的需求。业务模型是各地的行业的定制化组件包，根据行业的真实数据模型现场定制，是配置和脚本文件的集合，所以此类定制可落在现场实施阶段，在无需修改系统功能框架的情况下，接入现场组件包，达到适配各地业务模型的目标。
从原始数据中提取用于检索的基础数据。
在本实施例中，以公安行业为例，原始数据包括公安内部各部门的数据、社会数据、运营商数据等，种类众多，是需要综合检索的数据源头。在本实施例中，行业模型是从各类原始数据中总结提炼出来的，需要对原始数据做部分数据清洗整合，由于数据来源于不同的应用系统，所以需要同时负责与各个系统接口适配，以完成数据采集。
按基础数据的对象粒度将基础数据存储到预设的数据库中。
从数据库中按对象粒度提取基础数据，根据组件包创建基础数据的索引数据，设置索引数据之间的关联关系后，置入预设的全文检索引擎。
在本实施例中，为支持全文检索需要引入全文检索引擎，为支持对象全文检索需要引入列式数据库，本实施例的技术方案基于大数据集群实现，采集的基础数据可存储在大数据集群中。
使用所述全文检索引擎，根据检索关键词查找具有关联关系的索引数据，将查找结果对应的基础数据作为检索结果。
在本实施例中，可根据公安行业的用户使用习惯，总结出来可供用户使用的、根据个人需求进行个性化定制的功能，包括查询方案配置、属性枚举配置、属性排序配置、异常标签配置、自定义标签配合以及部分“定制化检索功能”，对用户的检索行为实现定制化。在本实施例中，为满足各地用户的使用习惯差异，检索引擎要与“用户定制”结合使用，可达到满足用户各类需求的目标。
根据本实施例的技术方案，在从原始数据中提取出基础数据后，按照基础数据的粒度将基础数据导入列式数据库，并基于组件包创建列式数据库中基础数据的索引数据，设置索引数据的关联关系，则在用户进行检索时，可按关联关系查找索引数据，而不需要如现有技术方案对关联的索引数据进行打包，相比于现有技术方案大幅减少了计算量。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。
上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。
Claims (10)
1.一种数据处理方法，其特征在于，包括：
根据用于检索的索引数据的元数据的结构定义，生成组件包；
从原始数据中提取用于检索的基础数据；
按所述基础数据的对象粒度将所述基础数据存储到预设的数据库中；
从所述数据库中按所述对象粒度提取所述基础数据，根据所述组件包创建所述基础数据的所述索引数据，设置所述索引数据之间的关联关系后，置入预设的全文检索引擎。
2.根据权利要求1所述的方法，其特征在于，所述根据对用于检索的索引数据的元数据结构定义，生成组件包，包括：
根据所述元数据的结构定义、所述元数据的对象与要素之间的关系、所述元数据的对象与数据表之间的关系，生成所述组件包。
3.根据权利要求1所述的方法，其特征在于，在所述按所述基础数据的粒度将所述基础数据存储到预设的数据库中之前，还包括：
将所述基础数据存储到预设的大数据集群的文件系统中；
所述按所述基础数据的粒度将所述基础数据存储到预设的数据库中，包括：
从所述大数据集群的文件系统中提取所述基础数据，并根据所述组件包中所述索引数据的元数据的结构定义，按所述基础数据的所述对象粒度导入所述数据库中。
4.根据权利要求1所述的方法，其特征在于，所述从原始数据中提取用于检索的基础数据，包括：
通过预设的规则，对所述原始数据进行清洗转换，得到所述基础数据。
5.一种数据处理装置，其特征在于，包括：
业务模型构建模块，根据用于检索的索引数据的元数据的结构定义，生成组件包；
数据采集模块，从原始数据中提取用于检索的基础数据；
大数据计算模块，按所述基础数据的对象粒度将所述基础数据存储到预设的数据库中，以及从所述数据库中按所述对象粒度提取所述基础数据，根据所述组件包创建所述基础数据的所述索引数据，设置所述索引数据之间的关联关系后，置入预设的全文检索引擎。
6.根据权利要求5所述的装置，其特征在于，
所述业务模型构建模块根据所述元数据的结构定义、所述元数据的对象与要素之间的关系、所述元数据的对象与数据表之间的关系，生成所述组件包。
7.根据权利要求5所述的装置，其特征在于，所述大数据计算模块将所述基础数据存储到预设的大数据集群的文件系统中，以及从所述大数据集群的文件系统中提取所述基础数据，并根据所述组件包中所述索引数据的元数据的结构定义，按所述基础数据的所述对象粒度导入所述数据库中。
8.根据权利要求5所述的装置，其特征在于，
所述数据采集模块通过预设的规则，对所述原始数据进行清洗转换，得到所述基础数据。
9.一种数据处理设备，其特征在于，所述数据检索设备包括处理器、存储器和通信总线；
所述通信总线用于实现处理器和存储器之间的连接通信；
所述处理器用于执行存储器中存储的数据检索程序，以实现权利要求1至4中任一项所述的数据检索方法的步骤。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现权利要求1至4中任一项所述的数据连锁方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810650269.2A CN110704421A (zh) | 2018-06-22 | 2018-06-22 | 数据处理方法、装置、设备和计算机可读存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810650269.2A CN110704421A (zh) | 2018-06-22 | 2018-06-22 | 数据处理方法、装置、设备和计算机可读存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110704421A true CN110704421A (zh) | 2020-01-17 |
Family
ID=69192119
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810650269.2A Pending CN110704421A (zh) | 2018-06-22 | 2018-06-22 | 数据处理方法、装置、设备和计算机可读存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110704421A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113656469A (zh) * | 2020-05-12 | 2021-11-16 | 北京市天元网络技术股份有限公司 | 大数据处理方法及装置 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6094649A (en) * | 1997-12-22 | 2000-07-25 | Partnet, Inc. | Keyword searches of structured databases |
| CN103886011A (zh) * | 2013-12-30 | 2014-06-25 | 安徽讯飞智元信息科技有限公司 | 一种基于索引文件的社会关系网络创建与检索系统及方法 |
| CN104850601A (zh) * | 2015-05-04 | 2015-08-19 | 科技谷（厦门）信息技术有限公司 | 基于图数据库的警务实时分析应用平台及其构建方法 |
| CN105468671A (zh) * | 2015-11-12 | 2016-04-06 | 杭州中奥科技有限公司 | 实现人员关系建模的方法 |
-
2018
- 2018-06-22 CN CN201810650269.2A patent/CN110704421A/zh active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6094649A (en) * | 1997-12-22 | 2000-07-25 | Partnet, Inc. | Keyword searches of structured databases |
| CN103886011A (zh) * | 2013-12-30 | 2014-06-25 | 安徽讯飞智元信息科技有限公司 | 一种基于索引文件的社会关系网络创建与检索系统及方法 |
| CN104850601A (zh) * | 2015-05-04 | 2015-08-19 | 科技谷（厦门）信息技术有限公司 | 基于图数据库的警务实时分析应用平台及其构建方法 |
| CN105468671A (zh) * | 2015-11-12 | 2016-04-06 | 杭州中奥科技有限公司 | 实现人员关系建模的方法 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113656469A (zh) * | 2020-05-12 | 2021-11-16 | 北京市天元网络技术股份有限公司 | 大数据处理方法及装置 |
| CN113656469B (zh) * | 2020-05-12 | 2024-01-05 | 北京市天元网络技术股份有限公司 | 大数据处理方法及装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108509547B (zh) | 一种信息管理方法、信息管理系统及电子设备 | |
| CN102054025B (zh) | 交通信息资源整合处理方法及系统 | |
| US7464084B2 (en) | Method for performing an inexact query transformation in a heterogeneous environment | |
| US8862566B2 (en) | Systems and methods for intelligent parallel searching | |
| CN113836131B (zh) | 一种大数据清洗方法、装置、计算机设备及存储介质 | |
| CN112685433B (zh) | 元数据更新方法、装置、电子设备及计算机可读存储介质 | |
| CN110532309B (zh) | 一种高校图书馆用户画像系统的生成方法 | |
| CN106503274A (zh) | 一种数据整合与搜索方法及服务器 | |
| CN108319608A (zh) | 访问日志存储查询的方法、装置及系统 | |
| Das et al. | A study on big data integration with data warehouse | |
| Niinimäki et al. | An ETL process for OLAP using RDF/OWL ontologies | |
| EP2506162A1 (en) | Finding a data item of a plurality of data items stored in a digital data storage | |
| CN116795859A (zh) | 数据分析方法、装置、计算机设备和存储介质 | |
| Calì et al. | IBIS: Semantic data integration at work | |
| CN114066533A (zh) | 产品推荐方法、装置、电子设备及存储介质 | |
| CN110704421A (zh) | 数据处理方法、装置、设备和计算机可读存储介质 | |
| Cybula et al. | Query optimization through cached queries for object-oriented query language SBQL | |
| US8504552B2 (en) | Query based paging through a collection of values | |
| Sala et al. | Midas for government: Integration of government spending data on Hadoop | |
| CN102799645B (zh) | 安全搜索装置和安全搜索方法 | |
| CN115713118A (zh) | 一种电网运维岗位知识推送方法及系统 | |
| CN111143329B (zh) | 一种数据处理方法及装置 | |
| Ziegler et al. | PAL: toward a recommendation system for manuscripts | |
| CN113177150A (zh) | 出版物资源整合方法与出版物资源整合系统 | |
| Xu et al. | From XML Schema to Relations: A Incremental Approach to XML Storage |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |