CN110414259B - 一种构建数据类目、实现数据共享的方法及设备 - Google Patents

Abstract

本申请提供了构建数据类目及实现数据共享的方案，该方案在构建数据类目时，并非基于特定的业务应用，而是基于内容信息来面向开放的、不确定的需求，同时包含了数据表之间的关联关系，因此能够形成全量的数据类目，并可以用于分析数据血缘，从而打通城市数据各方的数据孤岛。此外，基于数据类目实现业务数据共享时，可以避免了盲目的数据需求申请，并且由于数据无需由数据提供方推送到前置机，整个过程均可以在一个设备中完成，能够保证所有数据遵循同一的标准进行处理，提高了数据的质量。

Description

一种构建数据类目、实现数据共享的方法及设备

技术领域

本申请涉及信息技术领域，尤其涉及一种构建数据类目、实现数据共享的方法及设备。

背景技术

随着信息化的发展，大部分城市的政务、公共服务等部门都有数据共享开放的需求，例如政府部门A在其某项业务中需要使用到政府部门B的数据，此时就需要政府部门B能够将相关的数据共享给政府部门A使用。其中，城市的政务、公共服务等部门在实现政务、公共服务等业务处理时使用的数据可以称为城市数据。

由于城市数据对于保密性、数据安全等因素有较高的要求，当前普遍采用的共享方案如图1所示，当数据需求方(例如政府部门A)有明确的业务应用时，先初步提出数据需求，例如需要关于本市各个区县的居民个人所得税的平均缴纳数据)。需要由协调部门(如电子政务办)协调数据提供方(例如政府部门B)沟通具体数据需求，例如政府部门B只有本市居民个人所得税的实际缴纳额的数据，通过三方沟通协调之后，由政府部门B提供需要有政府部门B对数据进行加工，然后推送到政府部门B的前置机，再统一由协调部门同步到数据的归集库中，并构建数据类目供政府部门A使用。政府部门A在需要使用数据时从归集库获取需要的数据。

现有的共享方案是在数据需求方有明确的业务应用后，才发起数据需求申请、明确数据需求，然后再针对本次的业务应用来开发数据、构建数据类目。每次构建的数据类目均与本次的业务应用相关，是无法形成全量的数据类目。同时，前置机、数据需求方、数据提供方、数据的归集库都不在同一套平台内，无法打通元数据、分析数据血缘，对后续的数据使用情况、产生的价值无法评估。由此，数据共享时，没有全量的数据类目，且无法分析数据血缘，各方之间容易形成数据孤岛，不利于构建完整的数据体系。

申请内容

本申请的一个目的是提供一种构建数据类目以及实现数据共享的方案，用以解决城市数据共享时无全量数据类目、无法分析数据血缘，容易形成数据孤岛的问题。

本申请提供了一种构建数据类目的方法，该方法包括：

从数据源获取数据表的元数据和日志数据；

解析所述数据表的日志数据，获取所述数据表之间的关联关系；

获取所述元数据对应的内容信息；

根据数据表之间的关联关系以及数据表中的元数据对应的内容信息，构建关于数据表的数据类目。

本申请还提供了一种实现数据共享的方法，该方法包括：

向数据需求方提供数据类目，其中，所述数据类目用于描述数据源中数据表之间的关联关系以及数据表中元数据对应的内容信息；

获取数据需求方基于所述数据类目确定的数据权限申请请求；

根据数据权限申请请求中所需求的数据表，从对应的数据源获取关于该数据表的业务数据；

向所述数据需求方开放所述业务数据的权限。

基于本申请的另一方面，还提供了一种构建数据类目的设备，该设备包括：

数据归集装置，用于从数据源获取数据表的元数据和日志数据；

数据解析装置，用于解析所述数据表的日志数据，获取所述数据表之间的关联关系，以及获取所述元数据对应的内容信息；

类目构建装置，用于根据数据表之间的关联关系以及数据表中的元数据对应的内容信息，构建关于数据表的数据类目。

本申请还提供了一种实现数据共享的设备，该设备包括：

交互装置，用于向数据需求方提供数据类目，获取数据需求方基于所述数据类目确定的数据权限申请请求，以及向所述数据需求方开放业务数据的权限，其中，所述数据类目用于描述数据源中数据表之间的关联关系以及数据表中元数据对应的内容信息；

数据归集装置，用于根据数据权限申请请求中所需求的数据表，从对应的数据源获取关于该数据表的业务数据。

此外，本申请还提供了一种构建数据类目的设备，包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行前述构建数据类目的方法。

本申请提供方案中，可以从数据源获取数据表的元数据和日志数据，例如所有能够作为数据提供方的对象均可以成为本方案中的数据源，统一获取这些数据源的元数据以及日志数据，然后解析其中数据表的日志数据，获取所述数据表之间的关联关系，同时获取所述元数据对应的内容信息，进而根据数据表之间的关联关系以及数据表中的元数据对应的内容信息，构建关于数据表的数据类目。由于在构建数据类目时，并非基于特定的业务应用，而是基于内容信息来面向开放的、不确定的需求，同时包含了数据表之间的关联关系，因此能够形成全量的数据类目，并可以用于分析数据血缘，从而打通城市数据各方的数据孤岛。

此外，在构建数据类目之后，通过想数据需求方提供这些数据类目，并且可以根据数据需求方的要求开放相应业务数据的使用权限，通过向数据需求方展示来自各个数据源的数据类目，数据需求方能清楚地了解各个数据提供方的数据，再通过数据类目申请具体需要的数据，由此避免了盲目的数据需求申请，减少沟通次数，减轻各方的工作量，减少了各方配合的成本。数据需求方在查看数据类目之后，若需要获得其中某些数据的使用权，可以申请数据权限，从而获得特定数据使用权限。并且由于数据共享的过程中，数据无需由数据提供方推送到前置机，整个过程均可以在一个设备中完成，可以统一整个过程的平台、监控、运维体系，能够保证所有数据遵循同一的标准进行处理，提高了数据的质量。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为现有的城市数据共享方案的原理示意图；

图2为本申请实施例提供的一种构建数据类目的方法的处理流程图；

图3为本申请实施例中生成的关联图谱的示意图；

图4为本申请实施例的方案在构建数据类目以及数据共享时的拓扑结构图；

图5为本申请实施例中对日志数据的处理过程示意图；

图6为本申请实施例提供的一种构建数据类目的设备的结构示意图；

图7为本申请实施例提供的另一种构建数据类目的设备的结构示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的装置或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请实施例提供了一种构建数据类目的方法，该方法在构建数据类目时，并非基于特定的业务应用，而是基于内容信息来面向开放的、不确定的需求，同时包含了数据表之间的关联关系，因此能够形成全量的数据类目，并可以用于分析数据血缘。在实际场景中，该方法的执行主体可以包括但不限于网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

图2示出了本申请实施例提供的一种构建数据类目的方法，该方法至少包括如下处理步骤：

步骤S201，从数据源获取数据表的元数据和日志数据。其中，所述数据源可以是数据提供方的数据库，例如在城市数据共享的场景下，所述数据源可以是政府部门B、政府部门A等各类部门的数据库，数据库存储了各类相关业务的数据表以及对记录了数据表操作的日志数据。数据表中的元数据用于描述数据表的属性，例如以关于公交车运行情况的数据表为例，元数据可以是公交车编号、公交车车牌号等数据。在本申请的一些实施例中，日志数据可以是数据库查询日志(query日志)，记录了对数据表的操作。

步骤S202，解析所述数据表的日志数据，获取所述数据表之间的关联关系。由于在构建数据类目时，并非基于特定的业务应用，而是基于内容信息来面向开放的、不确定的需求，同时包含了数据表之间的关联关系，因此能够形成全量的数据类目，并且该数据类目可以用于分析数据血缘。

例如，以政府部门B的数据库作为数据源，其数据库中可以包括公交车运行情况表、公交车司机考勤表、公交车车辆情况表等数据表，这些数据表中会有通过某些键(字段)来关联，例如上述数据表中均包含公交车编号，通过公交车编号可以使得上述三个数据表存在关联关系。

在实际场景中，由于数据库的日志数据记录了每一次数据库操作，这些操作中可能会同时涉及到数据库中多个数据库，例如SQL语句中的包含的join等即一次操作涉及到多个数据表。若两个数据表在一次数据库操作中同时涉及，则采用如下形式记录该次涉及的数据：table1,table2,key1,key2，即表table1和表table2基于table1的键key1和table2的键key2关联于本次操作。如对于如下SQL语句“select*from a joinb on a.aid＝b.bidjoin c on c.cid＝b.bid”，可以确定数据表a和数据表b，基于键aid和键bid关联于本次select操作，数据表c和数据表b，基于键cid和键bid关联于本次select操作，由此可以获得如下的解析结果：a,b,aid,bid；b,c,bid,cid。

对预设时间段的解析结果进行统计，可以得到判断两个数据表是否存在关联关系的指标，例如可以是avg_day_cnt(日均关联次数)和last30d_day_cnt(最近30天关联天数)，在判断关联关系时，若avg_day_cnt>N&last30d_day_cnt>M，则表示两个数据表存在关联关系。以政府部门E数据库中的两个数据表为例，N>50，M>20则表示两个数据表之间存在关联关系。由此可以确定的关联关系可以采用如下的形式表示：table_name1,table_name2,join_key(key1,key2)，table_name1和table_name2为存在关联关系的两个数据表的名称，join_key为构建两个数据表的关联关系的键。

步骤S203，获取所述元数据对应的内容信息。由于元数据是用于描述数据属性的数据，可以描述数据表的某些属性，因此可以作为数据类目的内容信息，从而表示数据类目的所包含内容。

在获取所述元数据对应的内容信息时，若数据表包含完整的注释信息，则可以直接使用注释信息来作为内容信息。在实际场景中，数据表的注释信息往往会有缺失，对于缺失的部分可以基于元数据字段的内容进行识别，以自动补全注释信息。由此，本申请的一些实施例中，在获取所述元数据对应的内容信息时，可以先查看元数据的字段是否存在对应的注释信息，若所述元数据的字段存在对应的注释信息，则将所述注释信息确定为所述元数据对应的的内容信息；若所述元数据的字段不存在对应的注释信息，则基于识别规则对所述字段的内容进行识别，获取所述字段的注释信息，作为所述元数据对应的内容信息。

由于大部分的数据都存在相应的标准，如身份证号、手机号、邮编、工商注册号、企业名称、姓名、邮箱等，因此对于特定类型的元数据可以设定对应的识别规则从而实现内容识别。以邮箱为例，识别规则采用正则表达式[/^([a-zA-Z0-9_-])+@([a-zA-Z0-9_-])+(.[a-zA-Z0-9_-])+/]来描述，即由字母、数字下划线组成的邮箱名，连接@符号，再连接域名。满足以上规则的，则是一个标准的邮箱。通过维护高效、准确的识别规则库，是快速补全注释信息的有效途径，下面列出一些常见的识别规则库：

a)基本规则库

身份证、手机号、邮编、姓名、邮箱、住址、时间

b)组织机构规则库

企业名称、统一信用号、注册号、企业类型、工商登记号、学校名称、医院名称.

c)医疗卫生规则库

普通疾病、药品、科室、药方、症状

d)道路交通规则库

道路、车品牌、车零部件、交通规则、建筑物、地形、景点、车牌

e)食品

菜名称、原材料、零食名称、口味、菜谱、餐馆

在实际的数据库开发过程中，同一个数据库中往往会有表结构近似或者一致的数据表，例如测试表、分表、备份表，这些表结构是一致的，这些数据表的元数据对应的内容信息可以相互补充使用。由此，该方法还可以比较第一数据表的元数据和第二数据表的元数据的字段内容相似程度。若字段内容相似程度大于预设值，则将所述第一数据表和第二数据表确定为相似数据表；对于两个相似数据表，可以根据所述第一数据表的字段，确定所述第二字段表对应字段的注释信息。

其中，字段内容相似程度可以采用相同的字段数量来表示，例如若两个数据表的元数据中，字段数量分别大于N，且相同字段的数量占比>M，则认为两个表是相似的。通过识别相似数据表，使得数据表之间的注释信息能够相互补充，助于减少获取内容信息时的工作量。

步骤S204，根据数据表之间的关联关系以及数据表中的元数据对应的内容信息，构建关于数据表的数据类目。在实际场景中，数据类目可以采用各类方式向用户展示，例如可以生成关于所述数据类目的关联图谱，其中，所述关联图谱包括点(node)和连线(relation)，如图3所示，所述点表示核心数据表，可以采用前述的table_name作为其属性，所述连线表示核心数据表之间的关联关系，可以采用前述的table_name1,table_name2,join_key作为其属性。

此外，为了使得数据需求方能够直观的了解数据表的内容，可以通过添加标注信息的方式，在关联图谱中标记每个数据表的内容信息，例如直接在表示数据表的点附近添加标注信息，或者可以在用户选中某一个点之后，显示对应的标注信息。

在构建城市数据的数据类目时，由于各个数据源的数据量十分庞大，若将数据源中的所有数据表都构建数据类目，会造成数据类目过于庞大，对于不利于数据需求方的使用。因此，可以在每个数据源中选取一些重要性较高的数据表来构建数据类目，以此精简数据类目，方便数据需求方使用。由此，本申请的一些实施例中，在解析所述数据表的日志数据时，还可以获取所述数据表的访问操作信息，然后根据所述访问操作信息，在所述数据表中确定核心数据表。

访问操作信息是指对特定数据表的具体操作，例如可以基于SQL语句中的insert、update、select等相关内容进行统计获取，以SQL语句“select*from a join b on a.aid＝b.bid join c on c.cid＝b.bid”为例，包含了对数据表a、b和c的一次操作。在实际场景中，访问操作信息可以采用统计数据表的形式，该统计数据表包括以下字段：sql_id、table_name、active_time、data_num。其中，sql_id为数据库标识信息，table_name为数据表名称，用于识别操作所涉及的数据表，active_time为操作时间，用于对数据库的访问操作，data_num为数据表的数据量。

通过上述信息，可以计算判断指标，以实现核心数据表的判断，例如判断指标可以包括单位时间的平均访问次数、预设时间内的活跃访问时间和表数据的数据增长率。由此，在根据所述访问操作信息，在所述数据表中确定核心数据表时，可以将数据表的所述平均访问次数、预设时间内的活跃访问时间和表数据的数据增长率分别与对应的判断阈值比较，若符合预设规则，则确定所述数据表为核心数据表。在本实施例中，判断指标可以是：avg_day_query(日平均访问次数)、last30d_visit_day_cnt(最近30天访问天数)和data_add_rate(表数据增长率)。判断的预设规则可以是：

avg_day_query>N1&last30d_visit_day_cnt>M 1&data_add_rate>H1或

avg_day_query>N 2&last30d_visit_day_cnt>M 2&data_add_rate<H2

由于在实际场景中，数据表可能分为业务数据表和代码数据表，其中业务数据表中记录的数据主要包括数据表对应的业务应用实际产生的数据，例如公交车运行情况表、公交车司机考勤表等，数据表大部分的操作都是数据插入操作，因此访问频繁，并且数据量增长较快。而代码数据表中记录的数据主要包括业务应用中的基础数据，例如记录有公交车站台信息的站台表，由于站台信息不太会发生变化，此类数据表大部分的操作都是数据读取操作(例如查询站台对应的地址、编号等)，很少会有修改或者插入的操作，因此虽然访问频繁，但是数据量增长较慢。由此，基于上述规则可以识别出实际场景中的两类核心数据表。

进而在构建数据类目时，可以仅针对核心数据表，而非所有数据表，即根据核心数据表之间的关联关系以及核心数据表中的元数据对应的内容信息，构建关于核心数据表的数据类目。在此场景下，在获取元数据对应的内容信息，也可以仅获取核心数据表中元数据对应的内容信息。

本申请实施例还提供了一种实现数据共享的方法，该方法包括如下处理步骤：

首先，向数据需求方提供数据类目。其中，所述数据类目用于描述数据源中数据表之间的关联关系以及数据表中元数据对应的内容信息，该数据类目可以采用前述构建数据类目的方法生成。并且提供数据类目的方式可以是生成并展示前述的关联图谱，以使数据需求方可以直观了解数据类目中每个项目对应的数据表内容及其关联关系。

然后，获取数据需求方基于所述数据类目确定的数据权限申请请求。例如，政府部门A在查看展示的关联图谱之后，认为其某一项业务应用中需要使用来自于政府部门B的数据库中的数据表table1，则可以发送关于该table1的数据权限申请请求，请求获得table1的使用权限。

进而，可以根据数据权限申请请求中所需求的数据表，从对应的数据源获取关于该数据表的业务数据。在获取业务数据时，也可以为每个数据源创建对应的项目空间，并从对应的数据源获取该数据表的业务数据，存储于对应的项目空间。在实际场景中，由于获取元数据以及日志数据时，也可以为每个数据源创建相应的项目空间，在从同一数据源获取业务数据时，可以使用为元数据和日志数据创建的同一项目空间。

在获取业务数据之后，可以向所述数据需求方开放所述业务数据的权限。此时，数据需求方就拥有了特定业务数据(如table1中的业务数据)的使用权限，由此可以是随时获取并使用这些业务数据，从而实现了数据共享。在获取业务数据，并开放权限之前，可以业务数据进行数据清洗、标准化等处理，使得数据需求方在使用业务数据时能够更加高效。

在本申请的另一些实施例中，可以采用如图4所示的拓扑结构，由构建数据类目的设备410实现前述构建数据类目的功能，并完成数据共享，该设备410可以依赖于云计算平台。数据需求方420和数据提供方430可以通过对应的客户端或者浏览器与设备实现数据交互。设备进行数据类目构建以及数据共享时的处理流程包括如下步骤：

步骤S401，设备从数据源获取数据表的元数据和日志数据。其中，设备可以为每个数据源创建对应的项目空间，从数据源获取数据表的元数据和日志数据后，存储于对应的项目空间中。例如，针对政府部门B、政府部门C、政府部门D、政府部门E的数据库，分别设定各自的项目空间，设备从政府部门B数据库中的获取数据之后，会存储于政府部门B的项目空间中，以此类推每个数据源的数据都会被保存于各自项目空间中。由此，各个城市数据对应的各个部门接入方便，若需要有新的部门的数据库接入，为其设置对应的项目空间即可。

步骤S402，归集元数据和日志数据，对其进行数据清洗、标准化等处理。

步骤S403，设备解析所述数据表的日志数据，获取核心数据表和核心数据表之间的关联关系，并且获取所述元数据对应的内容信息，并据此构建关于核心数据表的数据类目。在解析日志之前，可以对日志进行清洗，剔除无关的日志数据。图5示出了日志数据的处理过程，首先根据不同类型的数据库(例如oracle、sqlserver、mysql等)配置不同的同步任务，采集这些数据库中的日志数据。然后，对日志数据进行清洗，并在清洗完成之后对日志数据进行解析，以获取核心数据表和关联关系。

步骤S404，设备提供数据类目，然后获取数据需求方基于所述数据类目确定的数据权限申请请求。提供方式可以是生成并展示前述的关联图谱，以使数据需求方可以直观了解数据类目中每个项目对应的数据表内容及其关联关系。

步骤S405，设备根据数据权限申请请求中所需求的数据表，从对应的数据源获取关于该数据表的业务数据。例如，作为数据需求方的政府部门C需要政府部门B的公交车运行情况表中数据的使用权限，则设备会从政府部门B的数据库中定向归集该数据表的业务数据。其中，业务数据是指该数据表对应的业务应用在实际运行过程中所产生的数据。由于设备为每个数据源创建了对应的项目空间，在获取业务数据时，也可以从数据源获取该数据表的业务数据，存储于对应的项目空间。

步骤S406，对于归集得到的业务数据，设备可以对其进行标准化处理、建设数据仓库、数据主题等。

步骤S407，设备向所述数据需求方开放所述业务数据的权限。

步骤S408，数据需求方在获得权限后，在设备的项目空间中就具有了数据使用的权限，就可以获取这些数据应用于数据需求方的业务应用。

在图1所示的数据共享方案中，由于数据提供方要参与前期数据需求沟通，并且由于保密、数据安全等因素，无法直接开放数据提供方的数据库，而是需要根据需求，做相应的数据加工，再从数据库将数据推送到前置机，这些过程要耗费大量资源来配合。并且，数据是由数据提供方推送到前置机的，这过程没有统一的平台、监控、运维体系，不同的数据提供方会有不同的处理标准，无法保障数据的质量。

而本申请实施例中的方案中，通过向数据需求方展示来自各个数据源的数据类目，数据需求方能清楚地了解各个数据提供方的数据，再通过数据类目申请具体需要的数据，由此避免了盲目的数据需求申请，减少沟通次数，减轻各方的工作量，减少了各方配合的成本。数据需求方在查看数据类目之后，若需要获得其中某些数据的使用权，可以申请数据权限，从而获得特定数据使用权限。并且由于数据共享的过程中，数据无需由数据提供方推送到前置机，整个过程均可以在一个设备中完成，可以统一整个过程的平台、监控、运维体系，能够保证所有数据遵循同一的标准进行处理，提高数据安全、数据质量提高了数据的质量。

基于同一发明构思，本申请实施例中还提供了构建数据类目的设备，所述构建数据类目的设备对应的构建数据类目的方法是前述实施例中的方法，并且其解决问题的原理与该方法相似。

本申请实施例提供的一种构建数据类目的设备，该设备在构建数据类目时，并非基于特定的业务应用，而是基于内容信息来面向开放的、不确定的需求，同时包含了数据表之间的关联关系，因此能够形成全量的数据类目，并可以用于分析数据血缘。在实际场景中，该设备的具体实现可以包括但不限于网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

图6示出了本申请实施例提供的一种构建数据类目的设备，包括数据归集装置610、数据解析装置620和类目构建装置630。所述数据归集装置610用于从数据源获取数据表的元数据和日志数据。其中，所述数据源可以是数据提供方的数据库，例如在城市数据共享的场景下，所述数据源可以是政府部门B、政府部门A等各类部门的数据库，数据库存储了各类相关业务的数据表以及对记录了数据表操作的日志数据。数据表中的元数据用于描述数据表的属性，例如以关于公交车运行情况的数据表为例，元数据可以是公交车编号、公交车车牌号等数据。在本申请的一些实施例中，日志数据可以是数据库查询日志(query日志)，记录了对数据表的操作。

数据解析装置620用于解析所述数据表的日志数据，获取所述数据表之间的关联关系。由于在构建数据类目时，并非基于特定的业务应用，而是基于内容信息来面向开放的、不确定的需求，同时包含了数据表之间的关联关系，因此能够形成全量的数据类目，并且该数据类目可以用于分析数据血缘。

例如，以政府部门B的数据库作为数据源，其数据库中可以包括公交车运行情况表、公交车司机考勤表、公交车车辆情况表等数据表，这些数据表中会有通过某些键(字段)来关联，例如上述数据表中均包含公交车编号，通过公交车编号可以使得上述三个数据表存在关联关系。

在实际场景中，由于数据库的日志数据记录了每一次数据库操作，这些操作中可能会同时涉及到数据库中多个数据库，例如SQL语句中的包含的join等即一次操作涉及到多个数据表。若两个数据表在一次数据库操作中同时涉及，则采用如下形式记录该次涉及的数据：table1,table2,key1,key2，即表table1和表table2基于table1的键key1和table2的键key2关联于本次操作。如对于如下SQL语句“select*from a joinb on a.aid＝b.bidjoin c on c.cid＝b.bid”，可以确定数据表a和数据表b，基于键aid和键bid关联于本次select操作，数据表c和数据表b，基于键cid和键bid关联于本次select操作，由此可以获得如下的解析结果：a,b,aid,bid；b,c,bid,cid。

对预设时间段的解析结果进行统计，可以得到判断两个数据表是否存在关联关系的指标，例如可以是avg_day_cnt(日均关联次数)和last30d_day_cnt(最近30天关联天数)，在判断关联关系时，若avg_day_cnt>N&last30d_day_cnt>M，则表示两个数据表存在关联关系。以政府部门E数据库中的两个数据表为例，N>50，M>20则表示两个数据表之间存在关联关系。由此可以确定的关联关系可以采用如下的形式表示：table_name1,table_name2,join_key(key1,key2)，table_name1和table_name2为存在关联关系的两个数据表的名称，join_key为构建两个数据表的关联关系的键。

数据解析装置620还用于获取所述元数据对应的内容信息。由于元数据是用于描述数据属性的数据，可以描述数据表的某些属性，因此可以作为数据类目的内容信息，从而表示数据类目的所包含内容。

在获取所述元数据对应的内容信息时，若数据表包含完整的注释信息，则可以直接使用注释信息来作为内容信息。在实际场景中，数据表的注释信息往往会有缺失，对于缺失的部分可以基于元数据字段的内容进行识别，以自动补全注释信息。由此，本申请的一些实施例中，数据解析装置在获取所述元数据对应的内容信息时，可以先查看元数据的字段是否存在对应的注释信息，若所述元数据的字段存在对应的注释信息，则将所述注释信息确定为所述元数据对应的的内容信息；若所述元数据的字段不存在对应的注释信息，则基于识别规则对所述字段的内容进行识别，获取所述字段的注释信息，作为所述元数据对应的内容信息。

由于大部分的数据都存在相应的标准，如身份证号、手机号、邮编、工商注册号、企业名称、姓名、邮箱等，因此对于特定类型的元数据可以设定对应的识别规则从而实现内容识别。以邮箱为例，识别规则采用正则表达式[/^([a-zA-Z0-9_-])+@([a-zA-Z0-9_-])+(.[a-zA-Z0-9_-])+/]来描述，即由字母、数字下划线组成的邮箱名，连接@符号，再连接域名。满足以上规则的，则是一个标准的邮箱。通过维护高效、准确的识别规则库，是快速补全注释信息的有效途径，下面列出一些常见的识别规则库：

a)基本规则库

身份证、手机号、邮编、姓名、邮箱、住址、时间

b)组织机构规则库

企业名称、统一信用号、注册号、企业类型、工商登记号、学校名称、医院名称.

c)医疗卫生规则库

普通疾病、药品、科室、药方、症状

d)道路交通规则库

道路、车品牌、车零部件、交通规则、建筑物、地形、景点、车牌

e)食品

菜名称、原材料、零食名称、口味、菜谱、餐馆

在实际的数据库开发过程中，同一个数据库中往往会有表结构近似或者一致的数据表，例如测试表、分表、备份表，这些表结构是一致的，这些数据表的元数据对应的内容信息可以相互补充使用。由此，数据解析装置还可以比较第一数据表的元数据和第二数据表的元数据的字段内容相似程度。若字段内容相似程度大于预设值，则将所述第一数据表和第二数据表确定为相似数据表；对于两个相似数据表，可以根据所述第一数据表的字段，确定所述第二字段表对应字段的注释信息。

其中，字段内容相似程度可以采用相同的字段数量来表示，例如若两个数据表的元数据中，字段数量分别大于N，且相同字段的数量占比>M，则认为两个表是相似的。通过识别相似数据表，使得数据表之间的注释信息能够相互补充，助于减少获取内容信息时的工作量。

类目构建装置630用于根据数据表之间的关联关系以及数据表中的元数据对应的内容信息，构建关于数据表的数据类目。在实际场景中，数据类目可以采用各类方式向用户展示，例如可以生成关于所述数据类目的关联图谱，其中，所述关联图谱包括点(node)和连线(relation)，如图3所示，所述点表示核心数据表，可以采用前述的table_name作为其属性，所述连线表示核心数据表之间的关联关系，可以采用前述的table_name1,table_name2,join_key作为其属性。

此外，为了使得数据需求方能够直观的了解数据表的内容，可以通过添加标注信息的方式，在关联图谱中标记每个数据表的内容信息，例如直接在表示数据表的点附近添加标注信息，或者可以在用户选中某一个点之后，显示对应的标注信息。

在构建城市数据的数据类目时，由于各个数据源的数据量十分庞大，若将数据源中的所有数据表都构建数据类目，会造成数据类目过于庞大，对于不利于数据需求方的使用。因此，可以在每个数据源中选取一些重要性较高的数据表来构建数据类目，以此精简数据类目，方便数据需求方使用。由此，本申请的一些实施例中，在解析所述数据表的日志数据时，还可以获取所述数据表的访问操作信息，然后根据所述访问操作信息，在所述数据表中确定核心数据表。

访问操作信息是指对特定数据表的具体操作，例如可以基于SQL语句中的insert、update、select等相关内容进行统计获取，以SQL语句“select*from a join b on a.aid＝b.bid join c on c.cid＝b.bid”为例，包含了对数据表a、b和c的一次操作。在实际场景中，访问操作信息可以采用统计数据表的形式，该统计数据表包括以下字段：sql_id、table_name、active_time、data_num。其中，sql_id为数据库标识信息，table_name为数据表名称，用于识别操作所涉及的数据表，active_time为操作时间，用于对数据库的访问操作，data_num为数据表的数据量。

通过上述信息，数据解析装置可以计算判断指标，以实现核心数据表的判断，例如判断指标可以包括单位时间的平均访问次数、预设时间内的活跃访问时间和表数据的数据增长率。由此，在根据所述访问操作信息，在所述数据表中确定核心数据表时，可以将数据表的所述平均访问次数、预设时间内的活跃访问时间和表数据的数据增长率分别与对应的判断阈值比较，若符合预设规则，则确定所述数据表为核心数据表。在本实施例中，判断指标可以是：avg_day_query(日平均访问次数)、last30d_visit_day_cnt(最近30天访问天数)和data_add_rate(表数据增长率)。判断的预设规则可以是：

avg_day_query>N1&last30d_visit_day_cnt>M 1&data_add_rate>H1或

avg_day_query>N 2&last30d_visit_day_cnt>M 2&data_add_rate<H2

由于在实际场景中，数据表可能分为业务数据表和代码数据表，其中业务数据表中记录的数据主要包括数据表对应的业务应用实际产生的数据，例如公交车运行情况表、公交车司机考勤表等，数据表大部分的操作都是数据插入操作，因此访问频繁，并且数据量增长较快。而代码数据表中记录的数据主要包括业务应用中的基础数据，例如记录有公交车站台信息的站台表，由于站台信息不太会发生变化，此类数据表大部分的操作都是数据读取操作(例如查询站台对应的地址、编号等)，很少会有修改或者插入的操作，因此虽然访问频繁，但是数据量增长较慢。由此，基于上述规则可以识别出实际场景中的两类核心数据表。

进而在构建数据类目时，可以仅针对核心数据表，而非所有数据表，即根据核心数据表之间的关联关系以及核心数据表中的元数据对应的内容信息，构建关于核心数据表的数据类目。在此场景下，在获取元数据对应的内容信息，也可以仅获取核心数据表中元数据对应的内容信息。

本申请实施例还提供了一种实现数据共享的设备，该设备包括交互装置和数据归集装置。在实现数据共享时，首先，由交互装置向数据需求方提供数据类目。其中，所述数据类目用于描述数据源中数据表之间的关联关系以及数据表中元数据对应的内容信息，该数据类目可以采用前述构建数据类目的方法生成。并且提供数据类目的方式可以是生成并展示前述的关联图谱，以使数据需求方可以直观了解数据类目中每个项目对应的数据表内容及其关联关系。

然后，交互装置获取数据需求方基于所述数据类目确定的数据权限申请请求。例如，政府部门A在查看展示的关联图谱之后，认为其某一项业务应用中需要使用来自于政府部门B的数据库中的数据表table1，则可以发送关于该table1的数据权限申请请求，请求获得table1的使用权限。

进而，数据归集装置可以根据数据权限申请请求中所需求的数据表，从对应的数据源获取关于该数据表的业务数据。在获取业务数据时，也可以为每个数据源创建对应的项目空间，并从对应的数据源获取该数据表的业务数据，存储于对应的项目空间。在实际场景中，由于获取元数据以及日志数据时，也可以为每个数据源创建相应的项目空间，在从同一数据源获取业务数据时，可以使用为元数据和日志数据创建的同一项目空间。

在获取业务数据之后，交互装置可以向所述数据需求方开放所述业务数据的权限。此时，数据需求方就拥有了特定业务数据(如table1中的业务数据)的使用权限，由此可以是随时获取并使用这些业务数据，从而实现了数据共享。在获取业务数据，并开放权限之前，可以业务数据进行数据清洗、标准化等处理，使得数据需求方在使用业务数据时能够更加高效。

在本申请的另一些实施例中，构建数据类目的设备还可以包括一交互装置，用于提供所述数据类目，获取数据需求方基于所述数据类目确定的数据权限申请请求，以及向所述数据需求方开放所述业务数据的权限。此外，其数据归集装置还用于根据数据权限申请请求中所需求的数据表，从数据源获取关于所述数据表的业务数据。图4示出了由构建数据类目的设备410实现前述构建数据类目的功能，并完成数据共享时的拓扑结构，设备410可以依赖于云计算平台。数据需求方420和数据提供方430可以通过对应的客户端或者浏览器与设备实现数据交互。设备进行数据类目构建以及数据共享时的处理流程包括如下步骤：

步骤S401，设备从数据源获取数据表的元数据和日志数据。其中，设备可以为每个数据源创建对应的项目空间，从数据源获取数据表的元数据和日志数据后，存储于对应的项目空间中。例如，针对政府部门B、政府部门C、政府部门D、政府部门E的数据库，分别设定各自的项目空间，设备从政府部门B数据库中的获取数据之后，会存储于政府部门B的项目空间中，以此类推每个数据源的数据都会被保存于各自项目空间中。由此，各个城市数据对应的各个部门接入方便，若需要有新的部门的数据库接入，为其设置对应的项目空间即可。

步骤S402，归集元数据和日志数据，对其进行数据清洗、标准化等处理。

步骤S403，设备解析所述数据表的日志数据，获取核心数据表和核心数据表之间的关联关系，并且获取所述元数据对应的内容信息，并据此构建关于核心数据表的数据类目。在解析日志之前，可以对日志进行清洗，剔除无关的日志数据。图5示出了日志数据的处理过程，首先根据不同类型的数据库(例如oracle、sqlserver、mysql等)配置不同的同步任务，采集这些数据库中的日志数据。然后，对日志数据进行清洗，并在清洗完成之后对日志数据进行解析，以获取核心数据表和关联关系。

步骤S404，设备提供数据类目，然后获取数据需求方基于所述数据类目确定的数据权限申请请求。提供的方式可以是生成并展示前述的关联图谱，以使数据需求方可以直观了解数据类目中每个项目对应的数据表内容及其关联关系。

步骤S405，设备根据数据权限申请请求中所需求的数据表，从对应的数据源获取关于该数据表的业务数据。例如，作为数据需求方的政府部门C需要政府部门B的公交车运行情况表中数据的使用权限，则设备会从政府部门B的数据库中定向归集该数据表的业务数据。其中，业务数据是指该数据表对应的业务应用在实际运行过程中所产生的数据。由于设备为每个数据源创建了对应的项目空间，在获取业务数据时，也可以从数据源获取该数据表的业务数据，存储于对应的项目空间。

步骤S406，对于归集得到的业务数据，设备可以对其进行标准化处理、建设数据仓库、数据主题等。

步骤S407，设备向所述数据需求方开放所述业务数据的权限。

步骤S408，数据需求方在获得权限后，在设备的项目空间中就具有了数据使用的权限，就可以获取这些数据应用于数据需求方的业务应用。

在图1所示的数据共享方案中，由于数据提供方要参与前期数据需求沟通，并且由于保密、数据安全等因素，无法直接开放数据提供方的数据库，而是需要根据需求，做相应的数据加工，再从数据库将数据推送到前置机，这些过程要耗费大量资源来配合。并且，数据是由数据提供方推送到前置机的，这过程没有统一的平台、监控、运维体系，不同的数据提供方会有不同的处理标准，无法保障数据的质量。

而本申请实施例中的方案中，通过向数据需求方展示来自各个数据源的数据类目，数据需求方能清楚地了解各个数据提供方的数据，再通过数据类目申请具体需要的数据，由此避免了盲目的数据需求申请，减少沟通次数，减轻各方的工作量，减少了各方配合的成本。数据需求方在查看数据类目之后，若需要获得其中某些数据的使用权，可以申请数据权限，从而获得特定数据使用权限。并且由于数据共享的过程中，数据无需由数据提供方推送到前置机，整个过程均可以在一个设备中完成，可以统一整个过程的平台、监控、运维体系，能够保证所有数据遵循同一的标准进行处理，提高了数据的质量。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一些实施例包括一个如图7所示的设备，该设备包括存储有计算机可读指令的一个或多个存储器710和用于执行计算机可读指令的处理器720，其中，当该计算机可读指令被该处理器执行时，使得所述设备执行基于前述本申请的多个实施例的方法和/或技术方案。

此外，本申请的一些实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (19)

1.一种构建数据类目的方法，其中，该方法包括：

从数据源获取数据表的元数据和日志数据；所述元数据用于描述所述数据表的属性；

解析所述数据表的日志数据，获取所述数据表之间的关联关系；

获取所述元数据对应的内容信息；

根据数据表之间的关联关系以及数据表中的元数据对应的内容信息，构建关于数据表的数据类目；

其中，从数据源获取数据表的元数据和日志数据，包括：

为每个数据源创建对应的项目空间，

从数据源获取数据表的元数据和日志数据，并存储于对应的项目空间。

2.根据权利要求1所述的方法，其中，该方法还包括：

解析所述数据表的日志数据，获取所述数据表的访问操作信息；

根据所述访问操作信息，在所述数据表中确定核心数据表。

3.根据权利要求2所述的方法，其中，所述访问操作信息包括单位时间的平均访问次数、预设时间内的活跃访问时间和表数据的数据增长率；

根据所述访问操作信息，在所述数据表中确定核心数据表，包括：

将数据表的所述平均访问次数、预设时间内的活跃访问时间和表数据的数据增长率分别与对应的判断阈值比较，若符合预设规则，则确定所述数据表为核心数据表。

4.根据权利要求2所述的方法，其中，根据数据表之间的关联关系以及数据表中的元数据对应的内容信息，构建关于数据表的数据类目，包括：

根据核心数据表之间的关联关系以及核心数据表中的元数据对应的内容信息，构建关于核心数据表的数据类目。

5.根据权利要求2-4中任一项所述的方法，其中，该方法还包括：

生成关于所述数据类目的关联图谱，其中，所述关联图谱包括点和连线，所述点表示核心数据表，所述连线表示核心数据表之间的关联关系。

6.根据权利要求1所述的方法，其中，获取所述元数据对应的内容信息，包括：

若所述元数据的字段存在对应的注释信息，则将所述注释信息确定为所述元数据对应的的内容信息；

若所述元数据的字段不存在对应的注释信息，则基于识别规则对所述字段的内容进行识别，获取所述字段的注释信息，作为所述元数据对应的内容信息。

7.根据权利要求6所述的方法，其中，该方法还包括：

比较第一数据表的元数据和第二数据表的元数据的字段内容相似程度；

若字段内容相似程度大于预设值，则将所述第一数据表和第二数据表确定为相似数据表；

根据所述第一数据表的字段，确定所述第二数据表对应字段的注释信息。

8.根据权利要求1所述的方法，其中，该方法还包括：

提供所述数据类目；

获取数据需求方基于所述数据类目确定的数据权限申请请求；

根据数据权限申请请求中所需求的数据表，从对应的数据源获取关于该数据表的业务数据；

向所述数据需求方开放所述业务数据的权限。

9.一种实现数据共享的方法，其中，该方法包括：

向数据需求方提供数据类目，其中，所述数据类目用于描述数据源中数据表之间的关联关系以及数据表中元数据对应的内容信息；

获取数据需求方基于所述数据类目确定的数据权限申请请求；

根据数据权限申请请求中所需求的数据表，从对应的数据源获取关于该数据表的业务数据；

向所述数据需求方开放所述业务数据的权限；

其中，从对应的数据源获取关于该数据表的业务数据，包括：

为每个数据源创建对应的项目空间；

从对应的数据源获取该数据表的业务数据，并存储于对应的项目空间。

10.一种构建数据类目的设备，其中，该设备包括：

数据归集装置，用于从数据源获取数据表的元数据和日志数据；所述元数据用于描述所述数据表的属性；

数据解析装置，用于解析所述数据表的日志数据，获取所述数据表之间的关联关系，以及获取所述元数据对应的内容信息；

类目构建装置，用于根据数据表之间的关联关系以及数据表中的元数据对应的内容信息，构建关于数据表的数据类目；

其中，所述数据归集装置，用于为每个数据源创建对应的项目空间，以及从数据源获取数据表的元数据和日志数据，并存储于对应的项目空间。

11.根据权利要求10所述的设备，其中，所述数据解析装置，还用于解析所述数据表的日志数据，获取所述数据表的访问操作信息；以及根据所述访问操作信息，在所述数据表中确定核心数据表。

12.根据权利要求11所述的设备，其中，所述访问操作信息包括单位时间的平均访问次数、预设时间内的活跃访问时间和表数据的数据增长率；

所述数据解析装置，用于将数据表的所述平均访问次数、预设时间内的活跃访问时间和表数据的数据增长率分别与对应的判断阈值比较，若符合预设规则，则确定所述数据表为核心数据表。

13.根据权利要求11所述的设备，其中，所述类目构建装置，用于根据核心数据表之间的关联关系以及核心数据表中的元数据对应的内容信息，构建关于核心数据表的数据类目。

14.根据权利要求11-13中任一项所述的设备，其中，所述类目构建装置，还用于生成关于所述数据类目的关联图谱，其中，所述关联图谱包括点和连线，所述点表示核心数据表，所述连线表示核心数据表之间的关联关系。

15.根据权利要求10所述的设备，其中，所述数据解析装置，用于在所述元数据的字段存在对应的注释信息时，将所述注释信息确定为所述元数据对应的的内容信息；以及在所述元数据的字段不存在对应的注释信息时，基于识别规则对所述字段的内容进行识别，获取所述字段的注释信息，作为所述元数据对应的内容信息。

16.根据权利要求15所述的设备，其中，所述数据解析装置，还用于比较第一数据表的元数据和第二数据表的元数据的字段内容相似程度；若字段内容相似程度大于预设值，则将所述第一数据表和第二数据表确定为相似数据表；根据所述第一数据表的字段，确定所述第二数据表对应字段的注释信息。

17.根据权利要求10所述的设备，其中，该设备还包括：

交互装置，用于提供所述数据类目，获取数据需求方基于所述数据类目确定的数据权限申请请求，以及向所述数据需求方开放业务数据的权限；所述数据归集装置，还用于根据数据权限申请请求中所需求的数据表，从数据源获取关于所述数据表的业务数据。

18.一种实现数据共享的设备，其中，该设备包括：

交互装置，用于向数据需求方提供数据类目，获取数据需求方基于所述数据类目确定的数据权限申请请求，以及向所述数据需求方开放业务数据的权限，其中，所述数据类目用于描述数据源中数据表之间的关联关系以及数据表中元数据对应的内容信息；

数据归集装置，用于根据数据权限申请请求中所需求的数据表，从对应的数据源获取关于该数据表的业务数据；

其中，所述数据归集装置，用于为每个数据源创建对应的项目空间，以及从对应的数据源获取该数据表的业务数据，并存储于对应的项目空间。

19.一种电子设备，包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述电子设备执行权利要求1至9中任一项所述的方法。