公共数据治理运营项目实施技术投标方案
目录
第一章
项目总体概况
7
第一节
项目背景
7
第二节
建设内容
8
第三节
建设目标
8
第二章
项目技术方案
10
第一节
模型设计思路及规范
13
第一条
数据模型分层设计
13
第二条
数据模型分域设计
16
第三条
物理模型设计
17
第四条
逻辑模型设计
20
第二节
人口库法人库数据采集
23
第一条
数据采集执行过程
23
第二条
数据采集管理
31
第三条
数据源采集监控
34
第三节
人口库数据资源整合
37
第一条
数据整合
37
第二条
功能拓展
38
第三条
人口全息档案
40
第四条
人口关系图谱
76
第五条
人口全息视图
80
第六条
人口信息统计
81
第七条
人口信息查询
84
第八条
人口信息空间化
86
第四节
法人库数据资源整合
88
第一条
数据整合
89
第二条
功能扩展
91
第三条
法人多维画像
92
第四条
法人统一视图
110
第五条
法人信息统计
112
第三章
信息安全方案
113
第一节
安全原则
113
第二节
安全服务
115
第一条
安全集成服务
115
第二条
安全评估服务
116
第三条
等保测评支持服务
116
第三节
安全措施
116
第一条
网络通讯安全
116
第二条
安全准入
117
第三条
建立用户认证
118
第四条
项目信息数据安全
118
第五条
数据交换安全
119
第六条
操作系统安全措施
119
第七条
系统边界防护
120
第八条
防病毒系统设计
120
第九条
整体备份机制
121
第十条
应用和管理安全
122
第十一条
程序代码安全
123
第四章
项目组织方案
123
第一节
项目组织
123
第一条
项目人力资源管理机制
123
第二条
项目人员组织结构
124
第三条
机构中人员构成与职责
125
第二节
过程管理
129
第一条
实施流程
129
第二条
项目启动阶段
130
第三条
需求分析阶段
131
第四条
需求规格阶段
132
第五条
设计阶段
133
第六条
开发阶段
134
第七条
测试阶段
135
第八条
试运行阶段
137
第九条
验收阶段
138
第十条
项目维护阶段
139
第三节
项目质量及保证措施
140
第一条
质量管理体系标准
140
第二条
质量控制过程
140
第三条
质量评定计划
141
第四条
质量管理措施
141
第五条
软件质量控制
142
第四节
项目风险管理
145
第一条
风险定义
145
第二条
风险管理
146
第五节
项目文档
151
第一条
项目技术文档
151
第二条
项目管理文档
152
第五章
项目实施方案
153
第一节
项目实施原则
153
第二节
项目实施策略
155
第三节
项目管理机制
156
第一条
项目进度控制
156
第二条
项目人员控制
157
第三条
项目质量控制
158
第四条
项目后勤保障
158
第五条
项目培训
159
第四节
系统安装及调试
163
第五节
系统测试
163
第一条
测试原则
163
第二条
测试目的和任务
164
第三条
测试的阶段
165
第四条
测试内容
165
第六节
系统验收及试运行
194
第六章
项目验收方案
194
第一节
系统验收流程
194
第二节
验收准则
195
第三节
提交技术文件
197
第四节
验收合格条件
198
第五节
验收方法
198
第七章
项目运维服务方案
199
第一节
运维服务承诺
199
第二节
技术支持服务方案
202
第一条
项目规划阶段
203
第二条
项目实施阶段
204
第三条
项目验收阶段
206
第四条
项目维护阶段
206
第五条
长期技术支持
206
第六条
其他技术支持
207
第三节
售后服务方案
209
第一条
服务机构
209
第二条
维护人员配备
210
第三条
维护工具配备
212
第四条
服务管理体制
212
第五条
售后服务方式
215
第六条
服务响应时间
218
第七条
保修期内服务
218
第八条
保修期后服务
219
第九条
应急服务响应措施
219
第八章
类似项目的成功案例
223
第一节
业务重点领域数据分析项目
223
第一条
业务调研咨询方案
225
第二条
项目成果
255
第二节
5G 应用市场发展数据分析项目
255
第一条
项目背景与需求分析
255
第二条
整体思路与框架
257
第三条
业务研究与咨询方案
258
第四条
项目成果
273
项目总体概况
项目背景
近年来,H市立足于建设卓越全球城市,率先实现政府治理能力现代化的目标,在公共数据管理和互联网政务服务方面采取了一系列改革举措,积累了一定的实践经验,同时也面临一些困难和问题。根据《公共数据和一网通办管理办法》要求,需要进一步促进公共数据资源整合和利用,推进政务服务“一网通办”等电子政务发展,加快智慧政府建设,提升政府治理能力和公共服务水平。
为深入贯彻党的十九大关于建设人民满意的服务型政府的要求,坚持以人民为中心的发展思想,适应政府管理和服务现代化发展需要,深化改革,进一步优化营商环境,提升群众和企业获得感,H市通过大数据资源平台的建设,将“四大库”、“市级统建系统”、“各市级委办”、“各行政区”的数据汇聚成了市级数据湖,并以市级数据湖为基础,通过数据的集成与治理,构建了市级数据库,推动跨地区、跨层级、跨部门数据共享交换和应用,为后续公共数据的进一步整合、共享、开放提供了一定的工作基础。
建立统一的公共数据平台,全面实现H市政务“一网通办”,是贯彻党中央、国务院决策部署,深入推进“放管服”改革,持续优化营商环境,切实提升群众和企业获得感的重要举措。市委市政府已经明确,2018年建成H市政务“一网通办”总门户;到2020年,H市要形成整体协同、高效运行、精准服务、科学管理的智慧政府基本框架。
建设内容
基于大数据资源平台,通过对“四大库”、“市级统建系统”、“各市级委办”、“各行政区”的数据等相关信息的采集、梳理、交换、整合、扩展,构建H市统一的基础信息数据库。
建设完善市级数据库:通过人口、法人、空间地理库数据源整合开发,并对接电子证照库。实现对人口、法人、空间地理信息、证照等的接入、整合、开发、利用。结合H市实际,构建公共主题库及专题库,为应用提供安全高质的专题数据服务。
通过对工商、税务、质监、民政等法人相关信息的采集、梳理、交换、整合、扩展,构建H市统一的法人基础信息数据库。
建设目标
通过对公安、卫计、社保、民政等人口相关信息的采集、梳理、整合、扩展,构建H市统一的人口基础信息数据库。人口库以公安部门的户籍和暂住人口基础信息为基础、以身份证或护照号码以及居住性质为唯一标识,以其他部门人口信息为动态补充。
通过本次H市大数据资源平台公共数据运营支撑项目的建设,完善市级数据库的建设,将“四大库”、“市级统建系统”、“各市级委办”、“各行政区”的数据汇聚成了市级数据湖,并以市级数据湖为基础,初步构建基础的H市大数据资源平台,实现面向各需求单位部门进行数据共享、分析和利用、以及面向社会进行数据开放的目的,支撑智慧政府的改革。
通过数据的集成与治理,构建了市级数据库,利用H市大数据资源平台公共数据运营支撑项目的能力和服务,开展数据的管理、处理、分析与可视化等工作,支撑各类业务应用。
在本次项目中完成以下四个部分:
1、完善公共数据逻辑模型、物理模型的设计规范并确定公共数据库存储原则基层上,利用中心所建设的平台工具对进入市级数据湖的数据进行清洗、分层与转化,形成市级数据库。
2、完成对人口库数据资源的接入、整合、开发、利用。
3、完成对法人库数据资源的接入、整合、开发、利用。
本项目为构建H市大数据资源平台公共数据提供运营支撑,需要梳理并编制各部门政务信息资源目录体系,实现数据管理、交换、共享等基础功能。按照统一、集约、高效的数据开发利用理念,通过研究建立多级交换管理体系,形成政务信息资源物理分散、逻辑集中的信息共享模式,满足政府部门多方位、多层次的数据需求,为跨地域、跨部门、跨平台不同应用系统、不同数据库之间的数据交换与管理服务。
制定相关标准规范及管理制度,通过相应平台工具汇聚区内各单位公共数据及市级落地数据资源,形成区级数据池,同时经过数据清洗、转换、融合、治理后高质量的公共数据资源,形成公共数据资源中心。
项目技术方案
2.1整体技术方案
为建设统一的数资源中心,加强数据资源整合:制定相关标准规范及管理制度,通过相应平台工具汇聚区内各单位公共数据及市级落地数据资源,形成数据池,同时经过数据清洗、转换、融合、治理后高质量的公共数据资源,形成数据资源中心。本次项目完善公共数据逻辑模型、物理模型的设计规范并确定公共数据库存储原则基层上,利用中心所建设的平台工具对进入市级数据湖的数据进行清洗、分层与转化,形成市级数据库。并完成对人口、法人、空间地理库数据资源的整合开发,实现对人口、法人、空间地理信息的接入、整合、开发、利用,结合H市实际,构建公共主题库,为应用提供安全高质的公共数据服务。
本次公共数据存储模型设计实施项目的框架如下图所示:
(1)业务信息数据整合
整合政务数据(国家、市级、区)、公共事业数据、行业数据(金融、电信)、物联网数据(气象、摄像头…),实现内外部数据融合。
●采集人口数据:通过公安口、民政口、人社口、卫计口等来源数据,采集人口出生、死亡、婚姻、社保、户籍等信息。
●采集法人数据:通过工商口、税务口、质检口、民政口等来源数据,采集法人登记、税务、工商登记等信息。
●采集空间地理数据:采集地图、街道、区域、小区、楼宇、景点等地名、类型、经纬度等信息。
(2)数据抽取/数据交换
数据采集模块采用集中化多租户ETL平台进行数据采集、转换、稽核工作,完成数据标准化、集中化,实现数据脉络化、关系化,实现统一的数据处理加工,包括:离线采集、实时采集、准实时采集、流媒体采集、数据导入上报。
(3)基础库
按照人、地、事、物、组织等对象方式对数据进行建模,形成全区统一共用的基础数据库。典型的基础数据库包括人口库、法人库、空间地理信息库。
●人口库:构建全市统一的、以公民身份号位为唯一标识的、可共享的综合人口信息资源库。基于综合人口库,实现全市人口信息的汇聚治理、共享交换和应用服务,为开展跨部门、跨业务、跨区域的人口应用服务和数据共享,以及人口大数据分析、辅助决策等,提供全方位的人口信息支撑。
●法人库:促进相关部门有关法人单位业务信息的关联汇聚,丰富法人单位信息资源。支撑法人单位信息资源的分布查询和深化应用。通过公共数据开放网站,分级、分类安全有序开放综合法人信息,促进社会化创新应用。
●空间地理库:基于规划、国土资源等部门提供的GIS地图服务基础上,构建自然资源和空间地理基础信息,并将遥感影像、地址数据、政务信息图层等,与人口信息、法人单位、宏观经济、社会信用进行整合,形成本市空间地理基础信息资源库,为全市政府部门和企事业单位提供统一的地理空间信息服务。
模型设计思路及规范
数据模型分层设计
对数据模型进行分层能对管理数据有一个更加清晰的掌控,主要有体现清晰数据结构、数据血缘追踪、减少重复开发、复杂问题简单化、屏蔽原始数据异常、屏蔽业务的影响。
每个数据分层都有它的作用域,在使用表的时候能更方便地定位和理解。规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。便于维护数据的准确。
本次建设公共数据模型从层次上分为ODS、DW与ST层,即:数据运营层、数据仓库层和数据应用层。
数据应用层
数据仓库层
数据运营层
ODS层数据为近源层数据,数据源中的数据,经过ETL抽取、洗净、传输之后,装入本层。在源数据装入这一层时,要进行诸如去噪
、
去重、提脏、业务提取、单位统一、砍字段、业务判别等多项工作。
DW层数据为数据仓库层数据,ODS层数据经过整合,针对不同实体进行汇总后的数据进入该层。
ST层为数据应用层,数据更灵活,更贴近实际应用,用于数据展现。
1.数据来源层→ODS层
数据主要会有两个大的来源:
(1)业务库,使用sqoop来抽取,每天定时抽取一次。在实时方面,考虑用canal监听mysql的binlog,实时接入。
(2)埋点日志,线上系统会打入各种日志,日志以文件的形式保存,选择用flume定时抽取,或sparkstreaming、storm来实时接入,kafka也会是一个关键的角色。
据应用层
据仓库层
据运营层
据来源层
在ODS层中要进行数据清洗,比如异常字段的处理、字段命名规范化、时间字段的统一等。
2.ODS层→DW层
通过对ODS层数据进行整合,设计通用的数据仓库层,减少数据模型冗余度。规范仓库层模型,将有效提升数据模型重用度,好的DW层模型可以大大提升运营效率和数据一致性。
3.DW→ST层
ST层为数据应用层,将DW层数据根据不同需求进行多维度汇总、统计,对数据完成汇总、切片、钻取统计,为不同场景设计数据应用层模型。
数据模型分域设计
数据仓库中的数据是面向主题组织的,主题是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念,每一个主题基本对应一个宏观的分析领域。公共数据库资源模型设计分域情况如下:
主题域
主题域缩写
相关内容
人口域
PRTY
个人基本信息
法人域
GRP
法人基本信息
事件域
EVT
出生、死亡、诉讼
资源域
RES
空间资源、服务资源、公共资源、网 络资源
账务域
ACC
消费记录、纳税记录
关系域
REL
就职记录、婚姻关系
根据对人口、法人、空间地理库数据信息的特征,将对人口、法人、空间地理结合H市实际,构建数据模型三大公共主题域,为应用提供安全高质的公共数据服务。
人口主题域:收集城市各职能局的业务数据,对数据进行清洗、比对、关联,获得人口空间数据,建立人口库数据资源。
法人主题域:收集城市各职能局的业务数据,对数据进行清洗、比对、关联,获得法人空间数据,建立法人库数据资源。
资源主题域:通过收集城市各职能局的空间地理资源,结合业务数据,对数据进行清洗、比对、关联,获得空间地理数据,建立空间地理库数据资源。
主题域通常是联系较为紧密的数据主题的集合。可以根据业务的关注点,将这些数据主题划分到不同的主题域(也说是对某个主题进行分析后确定的主题的边界。)
模型设计示例如下:
物理模型设计
依据数据仓库建模理论,结合实际经验,物理模型设计时需确定数据模型在分布式系统中的存储形态,综合考虑Hadoop、MPP、一体机数据库、内存数据库四种形态各自特点,结合数据按照粒度不同、周期不同、主题不同形成的数据热度,制定数据的存储分布。
2.2.3.1分表规则
根据情况,将公共数据模型按照如下规则进行设计:
表命名
类型名称
说明
YYYYMMDD
日表
存放当天数据
YYYYMM
月表
存放月末数据,或当月累计数 据
DM
多周期日表
存放多个周期的日数据
DM_YYYYMM
多周期日表累计的 月表
存放多个周期的日数据,每月 分表
DM_YYYY
多周期日表累计的 年表
存放多个周期的日数据,每年 分表
MM
多周期月表
存放多个周期的月数据
DS
当周期表
当周期最新的数据
DT_YYYYMMDD
累计日表
当月累计数据
2.2.3.2表命名规则
基于分主题分层的原则命名:层_主题域_表名_表类型_分表规则例如:
人口表DWD_PRTY_INDIV_YYYYMMDD法人表DWD_PRTY_GRP_YYYYMMDD
2.2.3.3字段命名原则
为了保证数据定义和数据自身质量,以提高处理效率,字段设计建议遵循以下原则:
●相同字段设计命名一致性,对于多个表均有的字段,设计为统一的名称
●对于表间关联常用的字段,各表应该设计成同样的字段类型。
●避免对Hash键值字段进行数据的处理。
字段名称
字段命名
字段类型
枚举值
个人姓名
INDIV_NAME
VARCHAR(32)
个人证件号 码
INDIV_CERT_CODE
VARCHAR(32)
个人证件类 型
INDIV_CERT_TYPE
INT
0身份证; 1工 商登记证; 10 港澳居民来往 内 地 通 行 证;11台胞;12 外籍人士; 13 个体工商户营
业执照;14聚 类 ; 15特殊客 户;3军人证;5 企业代码证;9 单位证明; 99 其它证件
个人证件地 址
INDIV_CERT_ADDRES
S
VARCHAR(256 )
2.2.3.4数据处理原则
对于数据加工处理,应该尽量在小表内进行,对于局部的数据加工处理为了不影响基础大表,应建立临时表作为工作空间。
对于年汇总、月汇总等粗粒度类数据汇总处理,应该在基于事先建立的日汇总等低粒度结果(包括用户、产品等维度上汇总)基础上进行,这种处理可减少上级统计对明细层数据的重复性读取。
逻辑模型设计
逻辑模型设计是对概念模型设计的进一步细化,根据数据的产生频率及访问频率等因素综合考虑,确定数据热度和数据关系等规则。作为概念模型到物理模型转换的中间过程,逻辑模型设计时兼顾业务理解和系统实现。
2.2.4.1数据有效性策略
模型中设计的字段属性都应是具有分析价值的,对于无效性字段属性,应予以裁剪:
剔除:对源系统提供的仅用作生产使用,无分析价值的字段属性进行剔除;对源系统中的无效字段(如全为空值、全为Z等)进行剔除。
合并:对内容重复,同名异义、同义异名、同名同义不同值、反复存储的字段信息进行归并。
2.2.4.2数据关系定义
概念模型设计的字段属性,与源系统相应实体的字段属性存在一定的映射关系,在逻辑模型设计时,应建立与源系统字段定义间的映射关系定义。通常的映射关系有:
源系统单张表,在概念模型设计时也为单个模型的,应针对概念模型中每个字段,建立其对应的源系统字段属性映射;
源系统多表,在概念模型设计时合并为单个模型,需要针对每个数据源表与当前模型分别映射,且每个模型的每个字段属性都应有相应的映射关系;
源系统单张表,在概念模型设计时拆分为多个模型,需将每个模型与源系统的标进行分别映射,且每个模型的每个字段属性都应有相应的映射关系。
2.2.4.3维值定义规则
统一采用维表方式定义静态的维值,例如证件类型,用户状态等字段。
维值
维值名称
枚举
值
枚举值中文
生效时间
失效时
间
CERT_TYPE
证件类型
0
身份证
1900/1/1
2099/1/1
CERT_TYPE
证件类型
1
工商登记证
1900/1/1
2099/1/1
CERT_TYPE
证件类型
10
港澳居民来往内地通 行证
1900/1/1
2099/1/1
CERT_TYPE
证件类型
11
台胞
1900/1/1
2099/1/1
CERT_TYPE
证件类型
12
外籍人士
1900/1/1
2099/1/1
CERT_TYPE
证件类型
13
个体工商户营业执照
1900/1/1
2099/1/1
CERT_TYPE
证件类型
14
聚类
1900/1/1
2099/1/1
CERT_TYPE
证件类型
15
特殊客户
1900/1/1
2099/1/1
CERT_TYPE
证件类型
3
军人证
1900/1/1
2099/1/1
CERT_TYPE
证件类型
5
企业代码证
1900/1/1
2099/1/1
CERT_TYPE
证件类型
9
单位证明
1900/1/1
2099/1/1
CERT_TYPE
证件类型
99
其它证件
1900/1/1
2099/1/1
人口库法人库数据采集
数据采集执行过程
本项目需采集的数据分为两部分,数据湖中的人口数据和法人数据。
数据采集方式有两种:
◆通过数据数据湖中的数据需要经过一系列治理后,形成高质量的数据入库。
◆通过各部门政务应用系统与数据资源池的直接双向交互,无需通过数据湖进行中转,通过平台的调度引擎可进行交
换链路的灵活设置。抽取流程如下图:
为适应大数据中心多类型数据源采集的需要,事件数据需支持多种类型的数据采集方式,数据采集可采用多种丰富的数据源接口,包括:
●常用标准协议接口如Socket等
●FTP文件接口
●JDBC/ODBC接口
●消息队列(KAFKA)接口
●Hadoop生态圈的开源技术Flume
2.3.1.1数据抽取方式
数据抽取主要采用自动采集的方式,支持全量抽取和增量抽取。
●全量抽取:数据湖或源系统的某个数据表或文件,全量进行抽取。
●条件抽取:数据湖或源系统的某个数据表或文件,可根据预设条件进行数据抽取
●增量抽取:监测数据湖或源系统的某个数据表或文件,仅针对增量部分进行抽取。
源数据库支持如下三种方式,根据需要进行抽取:
■文件
■数据库■流数据
市级数据湖归集的数据处理办法:
(1)批数据处理:
各类批数据通过数据采集功能进入数据支撑平台,经过存储、清洗、汇总和关联汇总等,产生应用数据,并实现数据共享或开放。
(2)流数据处理:
流数据通过数据采集功能进入数据支撑平台后,根据不同需求,可实现实时数据计算后的开放,也可实现通过实时数据分析后汇总产生应用数据,进而实现数据共享或开放。
2.3.1.2自动入库
从数据湖和特殊应用的数据库自动采集法人数据,使用中间数据库的方式接收源端(数据湖等)按照要求提供的数据,当系统时钟到预设的自动读取中间数据库时间时,计算机自动读取中间数据库中的数据,也可以手工启动读取数据。调度可设置前置条件及时间调度方式,自动入库时间调度方式:
●每月●每日
●每小时
如遇到采集失败或前置时间不满足,则设置不同优先级的轮询方式:
●高优先级:10分钟轮询一次,最长36小时
●中优先级:30分钟轮询一次,最长24小时
●低优先级:60分钟轮询一次,最长24小时
2.3.1.3全量抽取
对采集的数据进行全量抽取,不设置抽取条件,全量抽取源表数据。能够在系统初始化时,将数据湖和其他应用中已有的信息数据全部抽取到本系统,建立汇聚库的初始化原始数据。
2.3.1.4条件抽取
对采集的数据进行条件抽取,配置抽取条件,抽取源表数据中符合条件的数据。配置后,可按照小时、日、月自动抽取入库。
●条件设置
可以设置原子条件,比如,抽取创建时间为当日的数据。
●条件组合
可以将原子条件进行逻辑组合,例如:同时符合条件A、条件B的数据。
2.3.1.5增量检查
增量抽取可以有效减少数据抽取的数量,减少对源数据库的压力,避免影响现有业务,提高数据抽取效率。以下方法可以实现准确快速的捕获变化的数据,进行增量抽取。增量数据抽取中有多种方式支持增量检查的方法有以下几种:
1、触发器方式
触发器方式是普遍采取的一种增量抽取机制。该方式是根据抽取要求,在要被抽取的源表上建立插入、修改、删除3个触发器,每当源表中的数据发生变化,就被相应的触发器将变化的数据写入一个增量日志表,ETL的增量抽取则是从增量日志表中而不是直接在源表
中抽取数据,同时增量日志表中抽取过的数据要及时被标记或删除。
为了简单起见,增量日志表一般不存储增量数据的所有字段信息,而只是存储源表名称、更新的关键字值和更新操作类型(insert
、
update或delete),ETL增量抽取进程首先根据源表名称和更新的关键字值,从源表中提取对应的完整记录,再根据更新操作类型,对目标表进行相应的处理。
对从数据湖和其他应用中抽取的信息数据进行增量检查或时间戳比对,并对增量数据进行标记,以方便增量抽取。
2、时间截方式
时间戳方式是指增量抽取时,抽取进程通过比较系统时间与抽取源表的时间戳字段的值来决定抽取哪些数据。这种方式需要在源表上增加一个时间戳字段,系统中更新修改表数据的时候,同时修改时间戳字段的值。
有的数据库(例如SqlServer)的时间戳支持自动更新,即表的其它字段的数据发生改变时,时间戳字段的值会被自动更新为记录改变的时刻。在这种情况下,进行ETL实施时就只需要在源表加上时间戳字段就可以了。对于不支持时间戳自动更新的数据库,这就要求业务系统在更新业务数据时,通过编程的方式手工更新时间戳字段。
使用时间戳方式可以正常捕获源表的插入和更新操作,但对于删
除操作则无能为力,需要结合其它机制才能完成。
3、全表比对方式
全表比对即在增量抽取时,ETL进程逐条比较源表和目标表的记录,将新增和修改的记录读取出来。
优化之后的全部比对方式是采用MD5校验码,需要事先为要抽取的表建立一个结构类似的MD5临时表,该临时表记录源表的主键值以及根据源表所有字段的数据计算出来的MD5校验码,每次进行数据抽取时,对源表和MD5临时表进行MD5校验码的比对,如有不同,进行update操作:如目标表没有存在该主键值,表示该记录还没有,则进行insert操作。然后,还需要对在源表中已不存在而目标表仍保留的主键值,执行delete操作。
4、日志表方式
对于建立了业务系统的生产数据库,可以在数据库中创建业务日志表,当特定需要监控的业务数据发生变化时,由相应的业务系统程序模块来更新维护日志表内容。增量抽取时,通过读日志表数据决定加载哪些数据及如何加载。日志表的维护需要由业务系统程序用代码来完成。
5、系统日志分析方式
该方式通过分析数据库自身的日志来判断变化的数据。关系犁数
据库系统都会将所有的DML操作存储在日志文件中,以实现数据库的备份和还原功能。ETL增量抽取进程通过对数据库的日志进行分析,提取对相关源表在特定时间后发生的DML操作信息,就可以得知自上次抽取时刻以来该表的数据变化情况,从而指导增量抽取动作。
有些数据库系统提供了访问日志的专用的程序包(例如Oracle的LogMiner),使数据库日志的分析工作得到大大简化。
2.3.1.6增量抽取
能够在监控到数据湖和其他应用的数据库的数据更新后,从库中抽取更新的基础数据。捕获变化数据,仅对自上次导出之后变化数据(增、删、改)进行抽取,并对更新的数据进行增量检查和增量抽取。增量抽取后,进行基础表更新。
对捕获增量的方法有两点要求
1、准确
2、不要对业务系统造成太大压力
2.3.1.7数据校验
支持系统自动校验和人工校验方式。
自动校验:针对每个抽取配置可以设置自动校验规则。系统自动对采集的数据进行数据项完整性、数据值合理性、合法性、有效性
、
规范性、一致性、正确性等一系列检查和处理。对采集的数据一般采用系统自动校验方式进行校验。
自动校验规则可配置:
1、条数阈值检查
2、空值数量阈值检查
3、日期等其他自定义规则检查
人工校验:采用人工的方式对采集的数据进行格式、编码、内容方面的校验等的检查和处理。一般是对重要的数据或自动校验出现异
公共数据治理运营项目实施技术投标方案(273页)(2024年修订版).docx