2021-11-23 06:30 浏览量:1741
政务数据共享主要面向两类对象,一类是人,主要是指业务人员;一类是软件,主要是政务业务系统。面向业务系统的数据共享服务包含数据集服务和接口服务。面向业务人员的数据共享服务包含页面检索服务和自助分析服务等。数据共享服务架构图如下所示:
01 数据共享服务的原则
数据共享服务以数据为核心,解决如何将数据方便、高效、安全地共享出去,降低数据获取难度,提升数据需求体验和效率。通过平台能力的建设,提供不同的数据共享服务形式,满足不同类型的数据共享服务需求。
数据共享服务的建设主要有以下原则:
1、一致性原则。提供数据共享服务前,要确定每项数据的源头单位, 由源头单位对数据的准确性、一致性负责。减少数据“搬家”,从而减少向下游二次传递所造成的数据不一致问题。
2、黑盒原则。数据使用方不用关注技术细节,满足不同类型的数据共享服务需求。
3、敏捷响应原则。数据共享服务一旦建设完成,并不需要按数据使用方重复构建集成通道,而是通过“订阅”该数据共享服务快速获取数据。
4、自助使用原则。数据共享服务的提供者并不需要关心数据使用方怎么“消费”数据,避免了供应方持续开发却满足不了数据使用方灵活多变的数据使用诉求的问题。
5、可溯源原则。所有数据共享服务的使用都可管理,数据供应方能够准确、及时地了解“谁”使用了自己的数据,确保数据使用的合理。
02 数据集服务
一、数据集服务概述
数据集服务是由服务提供方提供相对完整的数据集合或文件,数据以数据库表或文件的形式进行交换。
数据集服务存在四种形式:
一是数据供应方直接通过传输系统将数据库表或文件传递到数据使用部门。
二是数据管理方直接将数据从不同的提供方传递到数据使用部门。
三是数据管理方对多个数据集进行简单拼接融合,但不改变数据后形成新的数据集,再传递到数据使用部门。
四是数据管理方对多个数据集进行融合,并按照业务规则对一个或多个字段的数据进行处理后形成新的数据集,再传递到数据使用部门。
对于业务规则是由多个数据集的数据供应方、数据集的需求单位、数据管理方共同协商确定,并固化在数据管理部门中,数据本身权责不变, 谁的数据共享出去谁负责。
其中,前两种形式是当前政务数据共享中最常用的形式,第三种和第四种是共享服务提升演进的形式。随着业务需求的变化,简单的将数据提供方的数据传递给数据使用部门,已经不能满足业务诉求,需要数据管理方将相关业务数据汇聚在数据底座,并对数据进行融合处理,按照业务相关部门共同协商的取数规则,确定最终对外共享的、唯一的数据,由数据共享平台对外提供数据。
二、数据集服务使用场景
主要使用场景1:对应形式一,如地方政府有关部门或人员直接访问统计局官网,获取第七次人口普查数据。
主要使用场景2:对应形式二,如数据管理方挂接卫健委等多部委的疫情防控信息的目录,并没有存储多部委数据。数据使用方向数据管理方提出多部门数据集使用申请,经数据管理方处理、数据供应方审批与授权后,数据使用方从管理方获取多部门数据。
主要使用场景3:对应形式三,如数据管理方汇聚市场监管局、税务局、住建、自然资源、水利、林业和草原等部门数据,通过数据集的方式,批量的获取数据,生态环境部可利用数据进行追溯污染原因,结合空气质量检测数据,以达到动态感知,及时精准的获取空气治理效果。
主要使用场景4:对应形式四,如招商引资时,税务部门、土地部门、环保部门、人力部门甚至教育部门都会招商企业有不同程度的优惠政策。数据管理方综合处理各单位的优惠政策及适用条件,经数据整合、计算形成新的数据集,将此数据集共享给决策部门,用来辅助招商引资。
三、数据集服务核心能力
根据支持数据共享服务的数据集有无关联处理,可将服务的能力分为无关联数据集服务能力、单一业务对象或资产的数据集服务能力和基于主题连接数据集服务能力。
1、无关联数据集服务能力
无关联数据集服务能力是指在数据进行结构化和标准化处理之后,数据质量尚可的情况下,业务对象之间无关联、主题之间无关联,将数据集直接对外提供服务。数据集可能直接从数据供应方到数据使用方,也可能由数据管理方传递给使用方。
2、基于数据湖的数据集服务能力
(1)将数据湖的同一个业务对象内的一个或多个资产封装为数据共享服务。在部分要求同一业务对象下多种数据的场景中,例如,政府投资项目管理时,业务对象是投资项目,该项目会包含若干个子项目及环评等项目,即可将子项目一、子项目二、子项目三的数据封装对外服务,形成可以支撑投资项目管理的数据集。
(2)将数据湖内单个资产及其关联对象数据合并封装为数据共享服务。在部分需求、同一业务对象、多种数据且数据分属不同管理部门的场景下,需要向数据使用方提供相对完整的对象信息,以便于数据使用方自助分析。例如,政府投资项目管理场景下,可能需要项目审批数据、项目招投标数据等。
由于分析服务面对的是具体的政府业务人员,而业务人员不可能读懂数据库中直接提取的项目ID等物理层主键或外键,并且没有必要让每个自助分析人员都重复进行共性数据联接。
因此,可以在数据分析服务封装时,将必要的数据联接在一起,比如将项目名称、项目编号和项目招投标数据合并封装为一个数据集服务。
3、基于主题联接数据集服务能力
(1)将单个主题联接的数据资产封装为一个或多个数据共享服务。数据共享服务在面对不同数据使用方的不同需求时,可以适当地拆分为多个数据共享服务,以便更好地提供给数据使用方,减少冗余数据,提升数据使用方体验。
例如,教育场景下,面对不同的政务业务人员,需要提供学历、学籍等不同层面的信息以及幼儿教育、中小学、高等教育、职业教育等不同细分领域的数据。比较恰当的方式是将多类需求分别封装为不同的数据共享服务,并确保这些数据共享服务的数据来源于同一个主题联接数据资产。
(2)将由多个主题联接数据资产组成的多维模型整体封装为一个数据共享服务。在部分情况下,主题联接数据资产并不是以宽表(宽表是指在一张表格内,囊括所有需要的数据字段或属性)的形式落地,而是以多维模型的形式存在,此时可以将多维模型整体封装为一个数据集服务。
例如,人社部的政务业务人员希望构建多角度分析的就业统计数据集时,就可能需要教育主题下的公民学历信息统计数据集、需要人口主题下的公民年龄或地域信息统计数据集、需要医疗主题下的公民健康情况统计数据集等。数据管理方将这些主题数据连接后,封装为一个新的数据集,满足数据使用方的就业统计需要。
4、数据集融合管理能力
融合管理能力包括数据汇聚处理能力、数据检查能力、规范设计能力:
(1)数据汇聚处理能力,该能力是指数据管理方将多部门多种类数据汇聚到自身后,需要从存储设施、网络网络、云、算力等多个层面构建硬件处理能力,和数据湖及主题关联能力。
(2)数据汇聚条件检查能力,涉及服务需求识别、数据资产检查、数据资产质量要求,具体如下:
服务需求识别:包括汇聚数据需要有明确的数据应用需求;汇聚数据前需要充分分析数据应用需求,包括但不限于识别数据内容、数据需求频率、数据用途;汇聚数据前需要做服务复用性检查,判断需求所需的数据共享服务是否已存在,是否可以多场景复用。
数据资产检查:包括要服务化的数据需要进入数据底座,且数据资产必须满足标准(任命数据责任人,发布数据标准、有初始源或可信源、定义数据密级、数据质量满足要求、元数据注册);封装成汇聚数据共享服务的数据,相关的汇聚逻辑,必须是由数据责任人提供。
数据资产质量要求:包括数据资产需要有主键、增量键字段或标识, 能够唯一识别资产中的数据记录及增量数据;数据资产要有需求所需的所有维度字段;数据资产需要具有能够进行数据安全性控制的维度字段,以便于数据共享服务提供时满足数据安全控制要求。
(3)数据融合管理属性设计能力规范,涉及明确数据融合责任人、明确数据融合安全策略、明确数据融合版本管理、明确数据融合SLA(服务标准)要求,具体如下:
明确数据融合责任人:数据融合的责任人取决于数据的责任人,跨业务域数据源封装的数据共享服务不改变原数据责任人的职责,大数据中心作为数据融合建设方,只承载汇聚逻辑的开发,汇聚逻辑由各数据责任人联席确认,共同作为该数据融合的责任人。
明确数据融合安全策略:包括数据融合要有明确的密级定义;数据融合的密级取决于数据共享服务中包含密级要求最高的数据项,数据融合的授权审批遵从整体的数据安全策略;基于外部公开、内部公开的数据资产封装的数据融合原则上不需要进行安全性审批。
明确数据融合版本管理:针对基于API形式提供的数据融合,如果不提供向后兼容功能,则需要提供版本控制能力。
明确数据融合SLA(服务标准)要求:即数据融合必须有明确的可用性、响应性等SLA要求。
03 接口服务
一、接口服务概述
接口服务是用API接口服务,根据数据量、计算规模的大小,实时或非实时地将数据推送给数据使用部门的服务。接口服务存在四种形式:
一是数据供应方直接通过接口将单条数据传递到数据使用部门。
二是数据供应方使用接头的方式,通过数据管理方挂接该接口,将单条数据传递到数据使用部门。
三是数据管理方通过接口形式,对多个部门的数据进行简单拼接融合,但不改变数据后形成新的接口,再传递到数据使用部门。
四是数据管理方通过接口对多个部门的数据进行融合,并按照业务规则对数据进行处理后形成新的最终对外共享的数据,再传递到数据使用部门。对于业务规则是由数据的多个数据供应方、数据的需求单位、数据管理方共同协商确定,并固化在共享平台中,对最终共享的数据权责不变, 谁的数据共享出去谁负责。
二、接口服务使用场景
主要使用场景1:对应形式一,如数据使用方通过国家卫健委官网, 直接调用某一接口用于日常卫生健康相关业务办理。
主要使用场景2:对应形式二,数据提供方以接口的方式,将单一数据接口挂在数据共享交换的地方(如共享平台)。数据使用方需要获取某一具体数据值时,通过共享平台进行接口调用。
如公安的人口数据、卫健委防疫数据、教育部的学历学籍数据、市场总局的企业数据均挂接于共享平台, 当数据使用部门通过共享平台获取相应的数据权限后,即可进行调用,不用再于各数据提供方网站一家一家找,编写一家一家的接口调用程序。
主要使用场景3:对应形式三,当数据供应方的多个独立的数据接口无法满足数据需求方的要求时,需要对多个数据供应方的业务相关性强的数据进行简单拼接融合成一个新的数据接口,但不改变数据本身的值,然后再传递给数据数据使用部门。
如数据管理方,汇聚扶贫主管部门的建档立卡贫困户信息、自然资源不动产登记信息、公安的户籍人口信息、死亡人员信息、车辆信息、残联的残疾人信息、市场监管局的工商注册信息等,通过身份证号等唯一标识字段进行关联,形成补贴发放人全景信息, 再通过社保卡与人进行关联,将汇聚后的信息,通过封装成新的接口的方式传递给财政部门,以供其将补贴发放到农民手中。
主要使用场景4:对应形式四,数据使用部门所需的数据涉及到多个来源,并且需要对多个来源的相关业务数据汇聚在数据底座,按照业务规则进行处理后,确定最终对外共享的、唯一的数据,封装成新的接口后再传递给数据数据使用部门。
如离婚状态信息,在民政部门、法院部门、公安部门等多个部门均存在,可能存在在同一时间点的离婚状态的值是不同的,而数据数据使用部门(如人社部门)在需要离婚状态信息时,需要一个确定、唯一、有效的数据,在此场景下,需要三个数据供应方、一个数据数据使用部门、数据管理方一起协商取数规则,并固化在共享平台中执行,以便满足人社部门准确的数据需求。
三、接口服务核心能力
1、常规的接口服务能力
资源提供方需在共享平台对接口进行注册、发布,核心能力包括服务注册、服务审核、服务撤销、服务变更、服务进度查看。数据需求方需在共享平台服务调用。
2、接口开发管理能力
接口开发包含数据API开发,函数API开发。
一是数据API开发是指通过编写SQL脚本的方式,将数据库提供的数据服务转换为API的能力。对数据提供方而言,对外开放其数据仓库的数据,使用更便捷的接口形态,提供业务增值能力,通过简单的操作,即可快速、低成本、低风险的开放数据或服务。对数据使用方而言,不再需要定制各种连接客户端,只需要使用一个简单的请求发送能力的客户端即可轻松驾驭各种数据仓库的能力。
二是函数API开发是指通过编写代码的方式,对多个API进行编排和适配,封装为一个新的API。对API数据使用方而言,通过将多个细颗粒度的API组合为一个特定场景功能的API,可以简化API数据使用方的开发难度,降低对 API的学习成本,降低开发成本,缩短业务应用开发和上线时间。当API有所变化时,可以通过函数API进行适配,尽可能保持提供给API数据使用方的API不发生变化,避免因为API变化而导致单个或多个API数据使用方的应用修改开发。
3、接口服务管理能力
数据接口服务包括管控平台、服务引擎、服务状态监控、可视化开发工具、传输代理、调度引擎、数据发布引擎、资源采集客户端等。
管控能力:数据共享服务统一管控,提供资源目录、数据开发、数据使用、服务引擎管理、调度计划、统计监控、服务权限配置等系列功能,对数据资源和服务资源统一注册管理等管控能力。
服务引擎:批量作业服务及文件传输服务引擎,负责批量作业模型解析、批量作业执行、文件传输服务;提供多协议、多数据源适配支持;为服务运行提供高性能、高可靠的运行环境。
服务状态监控:提供日志解析及监控能力,对事前预警、事中告警、事后统计分析等功能提供后台支撑。
调度引擎:作业调度引擎,支持作业与作业流的串行及并行调度,提供日历、频度、事件等多种规则的调度,为作业和作业流运行提供多样化的调度方式。
数据发布引擎:基于相关架构提供数据服务发布及数据访问能力,支持单表、结果集等形式的实时接口服务发布。
资源采集能力:实时采集各引擎所在物理机的CPU、内存、磁盘、网络等指标,并进行展示。
4、接口服务调用监控能力
共享平台对接口服务的调用进行监控,包括调用方、调用次数、接口服务的数据来源、服务质量等内容。
5、数据融合处理能力
与数据集服务中的数据融合处理能力类似,包括数据汇聚处理能力、数据检查能力、规范设计能力。
04 应用场景
按功能划分核心场景主要包括四个环节:资源目录生成、数据服务发布、数据服务消费、数据服务监控。
资源目录生成:提供数据资源目录与服务资源目录两种视图,数据资源目录通过自动化采集方式生成,对各种数据源(数据库、文件、大数据)的元数据信息进行展示;通过数据服务发布快速生成服务资源目录。
数据服务发布:基于数据资源目录可将共享区数据快速发布成实时服务(RESTful)和批量服务(File)。
数据服务消费:定义了从服务浏览、申请、审批、数据使用的详细流程,消费方通过订阅或者拉取的方式使用数据。
数据服务监控:对数据服务全生命周期管理与监控,对故障进行实时告警。
按角色进行功能场景划分,围绕核心场景定义了四类角色:数据管理员、数据开发人员、数据消费方、运维人员。
数据管理员:负责数据资源目录、服务目录的维护,参与数据服务的审批及授权。
数据开发人员:负责数据资源服务化前的转换、脱敏、核检,负责实时和批量服务的开发。
数据消费方:数据资源的使用方,通过资源目录查找相应的数据服务,向数据管理员提交数据服务申请使用数据。
运维人员:负责数据整体共享交换过程中数据资源的监控、统计分析及故障处理。
场景1:让用数据的所有人知道可以提供什么样的数据
通过资源目录提供技术元数据、业务元数据、服务元数据视图,使资源更容易发现,提供分区、分节点的体系化资源目录管理,保护数据安全,快速查找数据。通过自动化采集与解析手段获取元数据信息,建立技术、业务、服务元数据的注册输入,标明数据方位。
场景2:提供接口、文件、数据库三种服务类型对外进行共享
基于数据服务目录以接口、文件、数据库三种提供给数据使用方,数据消费方可通过申请的方式主动拉取数据,也可通过订阅的方式自动获取所需数据。
场景3:自助式数据问题追踪
消费方申请数据时通过血缘分析及级影响分析能够及时发现资源在使用过程中的质量问题 ,确认是否是自己想要的数据,验证开发正确性。
场景4:从全局了解企业数据服务应用情况
通过数据服务监控自动形成数据监控链路,提供数据服务共享的全貌地图,帮助企业了解数据共享交换的全貌及系统间数据关系,从全局了解企业的数据服务应用情况。
(本文部分文字摘自《政务数据开发利用研究报告》)