基于数据中台的数据资产管理体系①

崔恒志,王 翀,吴 健

1(国网江苏省电力有限公司,南京 211106)

2(国网江苏省电力有限公司 信息通信分公司,南京 211106)

3(江苏瑞中数据股份有限公司,南京 210012)

电力企业作为国家能源安全的重要一环,在经过多年的信息化沉淀后,已经积攒了海量的数据,而数据作为各种经营活动所不可缺少的关键信息,也让之成为现代社会最富含隐性价值的资产,随着大数据时代的来临,各行各业都开始对数据信息的价值进行深度挖掘[1-5].2019年起国网公司以《泛在电力物联网建设大纲》为基础,开展泛在电力物联网相关建设工作,其中一项关键核心目标为对内业务和数据共享,即开展企业级数据中台和客户服务、电网资源两类业务中台试点建设.国网公司明确以应用需求为导向,沉淀共性数据服务能力,打造“数据可见、组件成熟、体系规范”的数据中台,面向公司各专业、各基层单位和外部合作伙伴提供敏捷开放的数据分析和共享服务,提升公司智慧运营和新业务创新能力.

而在长期的信息化建设过程中,国网公司在数据资产方面尚未形成完善的企业级主数据管理体系,缺乏统一的数据质量管理体系,部分单位在数据质量检查工作中引入了数据检查工具,但数据质量评估体系及流程仍不完善.同样在数据资产管理工作过程中,缺乏对数据资产的全寿命管控,导致其价值被无端浪费.因此电力企业迫切需要通过切实可行的管理、分析运用源源不断产生的数据,挖掘其价值.数据资产管理体系是数据对外共享、提升数据质量、促进企业规模化运营的核心前提.

本文从数据资产全寿命管理建设、数据质量管理、数据资产共享服务建设3 个角度出发,对基于数据中台的资产管理体系的建设思路进行详细阐述.

1 数据资产管理

1.1 数据资产对象管理

数据资产管理过程中,主要涉及对实体表、指标模型、系统接口、外部应用、操作环境等对象的管理.实体表是计算存储过程中以数据库表结构展现的;系统接口是指依托数据中台组件,在数据接入上传环节生成的系统接口;外部应用是指在中台应用层所涉及到的应用;操作环境是指与数据资产管理相关联的操作系统信息、数据库版本等信息;指标模型是数据分析过程中产生的典型的数据衡量标准.

1.2 数据资产全生命周期管理

数据资产的全生命是指数据的接入、分析使用、后期维护、数据资源下架的整个过程[6,7].其中包含数据设计、数据采集、数据运行维护、数据分析利用、数据归档、数据迁移、数据资源下架等7 个阶段.结合电力企业的数据资产特点和大数据时代的发展前景,现代企业需要建立起完备的数据资产全生命周期管理体系,促进企业进行成本优化.

1.2.1 数据资产全生命周期管理现状

资产全生命周期管理工作是一项跨业务、跨部门的工作,有别于条块化的专业管理,具有很大的挑战性.国网公司为全面推进资产全生命周期管理工作,总部组织开展体系设计工作,形成了包括资产全生命周期管理规范、评价标准、数据全过程在线监测等在内的一系列成果;而各单位由于资产构成、管理基础、地域差异等因素,在前期的资产管理探索和实践中开展了各具特色的工作.为全面继承公司总部及各省(市)公司前期资产全生命周期管理工作成果,提升工作效率和管理水平,稳步推进资产全生命周期管理工作,亟需在原有的数据全生命管理基础上,另建立一个企业级资产全生命周期管理评价案例库,以便经验积累、资源共享和优势互补,促进各单位资产全生命周期管理工作开展.

1.2.2 资产全生命周期体系建设提升

构建资产全生命周期管理体系建设评价系统,实现公司针对各单位资产全生命周期管理体系建设工作的评价[8].评价管理体系的建立助于下属单位开展自评工作,帮助发现并解决资产管理进程中出现的疑难问题,为后续工作提供可靠的改进建议[9].同时助力于总部与受评单位的两级融会贯通,总部可依照该体系对下属单位的评价材料进行审核打分、评价分数的分析汇总、对审核人员的业务能力的评判等多维度审核.构建资产全生命周期评价案例库,固化体系设计成果及工作经验,通过整合电网不同企业、不同部门的评价案例资源入库,实现企业级别的案例共享.

1.2.3 评价案例系统业务架构

本系统所涵盖业务范围,根据需求分析可抽象、归纳、总结如图1所示.

图1 业务架构图

1.2.4 评价案例系统数据架构

根据资产全生命周期管理体系建设评价系统的应用功能定位,资产全生命周期管理体系建设评价系统实现对公司各单位资产全生命周期管理体系建设工作的评价及体系建设工作案例库的支撑.基于中台的总体数据架构图如图2所示.

实现资产全生命周期管理体系建设评价各类应用功能,需要不同类型数据的支撑[9].如管理全体业务所需的业务源系统数据,包含明细数据、指标模型数据、分析模型数据,由此类业务数据构成评价对象.另外包含支撑具体应用的功能性数据,如审核方式、审核对象、审核结果、评价案例级别代码、评价问题类型等.

为支撑资产全生命周期管理体系评价建设业务开展,可从以上两类数据的存储和管理需求出发,对数据架构进行设计,作为在后续设计过程中逻辑模型及物理模型设计的依据[9].

图2 数据架构图

2 数据质量监测

2.1 数据质量现状

现阶段国网公司建设的数据中台普遍采用OGG数据复制方式实现源端业务系统数据接入,但存在数据接入后与源端不一致的现象.综合分析存在以下几方面的问题:一是源端业务系统检修使得数据表结构发生变化后没有及时反馈数据中心进行联动处理,导致数据接入中断;二是部分源端业务系统OGG 配置进程仍由源业务系统运维厂家负责,数据中心无法对源端进程进行实时监控,一旦发生进程故障问题,无法及时准确定位,影响数据接入质量.且部分源端业务系统数据库并未对数据中心开放,数据接入后无法进行数据接入一致性、准确性核查.鉴于此情况在数据后续应用过程中,一旦发现跟源端生产库数据不一致情况,只能对源业务系统的数据重新接入,严重降低用户体验与数据共享应用水平[10-12].

除数据中台本身的问题,源端业务系统数据库在设计初期仅考虑满足本专业部门重点关注的数据信息,没有站在公司整体全局层面进行设计实现.随着公司业务的持续发展,大量业务数据的跨专业共享应用,源端数据库设计的不合理问题就显得愈发突出,公司其他专业关注的部分数据信息在源业务系统中可能尚未涉及,或者该部分数据信息为源业务部门不涉及的,从而导致数据质量差影响数据分析应用效果.另一方面,国网公司之前通过建设全业务统一数据中心实现数据的统一归集和共享应用,支撑了电力交易动态可视化系统、班组透视窗等一批创新应用的构建.但由于源端业务系统大量采用ORACLE 数据库设计实现,而数据中心贴源层采用的是基于MySQL 封装的SG-RDB实现,且SG-RDB 性能与稳定性较差,因此在数据统一汇聚过程中需要通过将存量历史数据和增量数据进行合并后以保证接入数据与源端数据的一致,由于数据库性能无法满足快速计算需求,只能支撑离线分析型业务应用的构建.而目前源端业务系统在数据库设计阶段存在大量无主键、无唯一键的数据表,因此在数据汇聚整合过程中需要耗费大量的时间和服务器资源进行数据同步与校验,数据数据接入的准确性与时效性无法保障.

2.2 数据质量体系优化

2.2.1 针对中台数据链路传输质量

从数据源端抓起,围绕应用场景需求,利用阿里数据中台DataWorks、DataQ 等组件的相关功能,对数据流转全过程进行监控,重点监控数据完整性、一致性、准确性、及时性等,制定并动态配置数据质量核查规则,逐步动态构建企业级数据质量核查规则库;同时利用DataWorks、DataQ 组件的相关功能,动态创建质量核查任务,根据调度策略,执行核查任务,生成数据质量分析报告和改进建议.通过对数据质量情况的定期通报,及各阶段数据质量问题的原因分析,动态更新数据校验规则,循序渐进地推进数据治理工作开展.

2.2.2 针对源端系统数据质量问题

针对于源端系统出现的数据质量问题,企业需充分调动部门的积极性,借助财务多维、供服指挥平台等跨专业应用应用、数据中台建设的机会对源端系统数据质量加以改进,确保源端防控.

2.3 数据质量提升落地实施方法

2.3.1 建立源端数据质量评价体系

1)收集各业务系统数据治理规则,形成数据核查规则库.

数据资产盘点成果涵盖了各业务系统元数据信息,即业务元数据(如字段业务描述)、技术元数据(如字段类型)、管理元数据(如数据产生岗位).下一步针对不同的数据对象,基于元数据配置数据质量规则,包括但不限于:数据唯一性、数据准确性、数据完整性、数据一致性、数据关联性、数据及时性等.通过收集、提炼、沉淀数据质量规则[13,14],形成数据核查规则库,在数据中台DataWorks 组件中配置数据质量检查任务,设置成手动执行或定期自动执行的系统任务,通过执行检查任务对存量数据和增量数据进行检查,形成数据质量问题清单.

其中治理规则的具体定义涉及到预警规则、接入规则、监测规则.监测规则是定义如何对数据进行质量监测的规则,完备的监测规则有助于研发人员发现可能出现问题的数据.研发人员可以在数据表中添加如监测对象类型、监测对象维度、监测规则名、规则概述、监测对象元数据名等字段,对数据监测加以辅助.预警规则是在数据分析处理阶段若出现数据异常情况,系统发出预警信息时所遵循的准则.接入规则是获取数据的方式方法,可分为常驻进程或者任务形式的调度.任务调度模式不需要额外配置,而常驻进程则需要配置服务器相关信息、数据接入时段、数据接入周期等.图3中在规则配置界面中配置质量监控的模板规则或自定义规则,具体可选择一致性监测、准确性监测等(本图所示为数据重复性监测规则配置).

2)按照数据责任清单,开展质量评价,推动源端数据治理.

通过数据资产盘点工作,已形成公司级数据责任清单,并在数据中台发布数据资源目录.可根据建立的数据校验规则库规则,对源端数据质量进行评价,结合数据责任清单形成数据质量评价报告,遵循“谁产生、谁提供、谁负责”的原则推动源端数据治理,进而全面提升公司数据质量.

图3 DataWorks 组件数据质量监控功能

2.3.2 数据源端治理

依托数据血缘图,开展数据流向倒查,追踪源头问题.通过对基于数据中台构建的业务应用开展评价反馈信息收集、数据质量问题分析等工作,从分析结果反向溯源,发现源头问题.业务方面主要关注数据的完整性、准确性和跨业务一致性,主要结合业务应用使用数据过程中出现的数据缺失、数据不准确等问题;技术方面结合DataWorks、Datahub、DataQ 等组件的数据流转链路台账,深挖造成数据质量问题的技术细节,进一步提升数据质量.

具体的链路分析方法采用解析MaxCompute 中Information Schema 提供的作业历史视图,查询到当前项目内的一段时间的作业历史信息,解析出对应的输入表和输出表以及对应的任务代码片段进行实现.

(1)输出结果表的编译与创建.

结果表部分编译代码如下:

CREATE TABLE `in_out_tb_relation` (

‘start_time’ datetime comment,

‘end_time’ datetime,

‘input_table’ string,

‘inst_id’ string,

‘output_table’ string,

‘operation_text’ string);

控制台创建该表如图4所示.

图4 创建输出结果表

(2)在创建完输出结果表,创建MaxComputer SQL任务,如图5所示.

结果表部分编译代码如下:

(3)查询输出结果

input_table和output_table 字段即为输入和输出表的数据链路,以此信息为基础进行表级别数据链路的分析工作,operation_text为执行的任务代码片段,通过解析代码片段,实现输入表字段和输出表字段字段级别的数据链路分析需求,达到数据血缘链路管控的目的.

图5 MaxComputer SQL 任务

3 数据资产共享服务体系构建

数据资产整合与服务的实现需经过源端数据接入、数据萃取融合、数据服务设计与发布等几个关键环节,实现数据中台的数据资产能力输出,对外提供基于指标、标签,画像、主题分析等数据服务.

3.1 数据溯源接入

数据中台数据溯源融合工作主要是明确分析主题需要的数据范围,数据处理要求,实现基于服务主题的数据按需完整接入与整合工作.历史数据采用一次性全量接入方式,增量数据接入可采用Ogg+Datahub+Maxcomputer 融合方式与数据集成方式.

3.1.1 Ogg+DataHub+MaxComputer 融合方式

本方法适用于Oracle 中数据表不带有增量数据标识符,对于增量数据不能很好的进行捕获的场景.文中遵循国网信息保密原则,部分表名用“--”隐性表示.SQL 代码部分省去了详细的字段代码部分.其中全量表与增量表的建表规则分别为:

(1)全量表:表名 ods_源表名_df 分区字段 ds 格式yyyymmdd 生命周期 7 天.

(2)增量表:表名 ods_源表名_di 分区字段 ds、hh、mm 格式 yyyymmdd、hh、mm (每5 分钟同步一次)生命周期永久.

使用场景1.Ogg+Datahub+Maxcomputer

1)假设日期号为X的当天数据库存储的为全量数据.

2)X+1 号抽取增量数据同步至增量表中.

3)在X+2 号凌晨开启定时任务融合X号当天的全量数据与X+1 号当天的增量数据.

4)查看表中是否存在主键,并找出主键字段名.

5)增量表中含有若干系统字段以及源数据主键复制字段,此类字段只负责处理逻辑,不参与融合操作.

6)新增和修改数据一起处理:先将增量表中的两部分数据使用ROW_NUMBER 函数融合提起当天最新修改的数据,然后和全量表数据融合提取最新数据.

部分SQL 代码如下:

3.1.2 数据集成方式

本方法适用于当数据现场状态处于离线且业务表中存在时间戳时,可以采用数据集成方式进行增全量同步与对应点融合任务.该方法下全量表与增量表的建表规则分别为:

(1)全量表:表名 ods_源表名_df 分区字段 ds 格式yyyymmdd 生命周期 7 天.

(2)增量表:表名 ods_源表名_di 分区字段 ds 格式yyyymmdd 生命周期 永久.

使用场景2.数据集成

1)假设日期号为X的当天数据库存储的为全量数据.

2)X+1 号抽取增量数据同步至增量表中.

3)在X+2 号凌晨开启定时任务融合X号当天的全量数据与X+1 号当天的增量数据.

4)查看表中是否存在主键,并找出主键字段名id.

5)本次业务场景中,增量表中create 字段用于抽取新增数据,modify 字段用于抽取修改数据,id 字段用于直接的数据比对融合.

部分数据融合代码如下:

3.1.3 方法对比与结论

本文通过对以上两种数据接入方式的实测比较,可得到以下结论,如表1所示.

3.2 数据萃取转换

资产数据萃取转换ETL 工作主要完成对接入数据的ETL 抽取设计及质量管理机制,按照SG-CIM 模型标准,通过数据集成组件对贴源层数据进行标准化模型转换以同步提高数据质量,将数据同步映射至共享层.

在SG_CIM 基础上(DWD)上构建DWS 形成宽表层,在汇总数据层,采取更多宽表化的手段构建公共指标数据层,提升公共指标的复用性,减少重复加工.在转换过程中,需要及时对不同数据库适配的数据类型进行修改.国网公司前期架构的全业务数据中心的标准库采用的为Gbase8A,现阶段基于数据中台架构的标准库为MaxComputer,在经过大量测试后,最终得出由Gbase8A 到MaxComputer的数据类型转换规则.如表2所示.

表1 两种接入方式比较

表2 数据类型转换规则

3.3 数据资产共享服务发布

数据中台使用DataWorks 统一管理对内对外的API 服务,数据服务及应用设计主要完成服务接口的封装和发布,实现与业务系统的对接,可以提供RESTful等各类形式的API 服务接口的统一注册、管理和调度,如图6所示.

图6 数据资产服务共享发布流程

1)数据服务支持将关系型数据库和noSQL 数据库的表(TB 级)通过向导模式生成数据API,也支持自定义SQL的脚本模式通过查询SQL 自行编写API.

2)数据服务支持MaxCompute Lightning 服务将项目表(GB 级)数据封装成API,支持以PostgreSQL 协议及语法连接访问Maxcompute 项目,通过向导模式,脚本模式快速获取以标准SQL 查询分析MaxCompute项目中的数据.

服务发布的技术实现(如图7至图12)如下:

(1)使用脚本模式生成API 后配置API 查询.

(2)配置参数与查询SQL.

(3)进行本地数据API 测试与发布.

返回数据结果并且状态返回SUCCESS 表明本地测试成功.

(4)API 信息查看与调用.

(5)使用Postman 工具调用接口进行验证,返回数据说明API 接口创建成功.

4 实验数据情况

基于本文提出的数据资产管理体系,利用数据质量治理、数据共享技术对公司的数据表进行监管,取合规上传率与时效合规率作为两个主要的评价指标,对系统中6 个自然日的数据表进行监测后(见表3),可明显发现数据表通过ETL 与相应的数据质量溯源治理后,数据表的上传合规性可大幅度提升.采用数据共享技术中的两种数据源端接入方式,也可大幅度提高数据表上传的时效性,除个别天数会存在负提升情况,其余时段合规率均维持在较高水平,由此可论证对数据资产进行有效管理可极大幅度提高业务运营效率.

图7 配置API 查询

图8 配置参数

图9 测试发布

图10 查看API 信息

图11 调用API

图12 查看数据返回情况

5 结束语

在电力企业数据资产管理流程体系中,以多维度管理、迭代优化、综合治理为中心思想,从数据资产全生命管理、数据资产质量管理、数据资产共享服务发布管理三个层面入手,对数据资产进行规范化管理,不断提高数据质量,在保障运维效率的前提下提高基于数据中台的服务质量[15,16],帮助企业精准预判数据资产的现有与未来价值,实现优势成本的合理化利用.

表3 6 个自然日数据表监管情况(%)