Hi 朋友，上期分享了云智慧的实践案例，下面让我们来看一看本期内容“中国光大银行之运维数据治理案例分享”。

 

引言

 

2021年12月央行发布《金融科技发展规划(2022—2025年) 》指出数字技术的快速演进为金融领域数字化转型注入充沛活力，金融科技逐步迈入高质量发展的新阶段。中国光大银行积极拥抱数字化转型，全力打造基于以数据为核心的智能运维体系建设。

 

建设背景

 

随着业务的发展，运维数据的规模也成几何级数地增长。数据来源方面，既有机房环境监控设备、服务器设备、网络设备等硬件，也有应用服务、数据库及中间件实例、操作系统等软件。数据类型方面也存在诸如日志、指标、告警、拓扑、工单等多种形态。通过对这些海量运维数据的挖掘分析，我行建设了诸如异常指标分析、根因定位、应用画像、容量预测等智能化场景，这些智能化场景对数据质量、跨领域数据关联分析等有极高的要求，然而传统运维模式下的运维工具建设及数据组织形式难以支撑以上场景的建设，极大影响了智能化场景的建设效果。

 

结合我行的实际情况，分析得出在传统的运维模式下存在如下问题：

• 运维工具系统的建设总是以运维领域划分，为满足单一领域的运维需求而搭建。在数据模型设计时忽略与其他领域的数据关联，同时各个系统间使用不同的数据标准、术语定义、数据库技术等，逐步形成了一个个数据孤岛。

 

• 不同工具系统间的技术架构互相独立，系统间的关联均需要独立开发接口，由此造成了系统间关联的技术壁垒；

 

• 大量系统、功能、应用重复建设，造成了计算存储资源及人力资源的浪费。

 

为了解决上述问题，建立全局规划及管理运维数据的能力，我行参考业务数据治理方法论设计了运维数据治理体系。

 

• 通过分层分域的数据架构建设标准化运维数据仓库，将不同工具系统及生产环境产生的运维数据接入数仓，同时将数据标准落实在数仓建模过程中，使得全局性的运维数据标准得以落实，打破各工具系统间的数据壁垒，解决数据孤岛问题；

 

• 提供数据加工服务，各类数据可以在此进行数据加工并提供标准化数据服务供其他工具系统使用，打破了工具系统之间的技术壁垒；

 

• 通过一体化的数据计算及数据服务能力建设，减少各类数据需求的重复建设，进一步节约成本，提升效能。

 

 

 

图1 数据治理体系

 

在我行数据治理体系中，分层分域的数据架构思想是运维数据仓库建设的指导，决定了海量运维数据在数据仓库中的组织形式；数据质量管理为上层数据服务效果提供有力支撑，是数据服务的重要保障；数据治理要定期进行经验总结及成果总结发布，为数据治理落实情况进行跟踪、评估，形成闭环管理，逐渐提升数据治理的效果。

 

下文将重点围绕分层分域运维数据架构、数据质量规则体系的设计及功能建设、以及数据治理成果总结三方面介绍。

 

分层分域的运维数据架构

 

在运维数据大集中的思想下，为了更好的进行运维数据组织，我行设计了分层分域的运维数据架构，并以此架构为思想建设了我行运维数据仓库。横向分为ODS贴源层、DWD明细层、DIM维度层、DWS轻度汇总层、ADS集市层；纵向将数据划分为资源对象域、生产运行域、运维活动域三大主题域；同时将元数据管理、数据生命周期管理、数据质量管理、数据安全管理等数据治理能力融入数仓建设中。以解决在数据使用过程中的数据血缘调用混乱，数据边界模糊，模型复用度低，重复建设等问题。

 

 

 

图2 分层分域的运维数据架构

 

PART 01 运维数据主题域划分

 

运维业务主要是运维人员通过特定的运维活动，保障承载业务的各类资源对象的健康状态，进而确保能有效支持业务的平稳运行及发展。主题域的划分既需要涵盖当前所有的运维数据领域所产生的数据，又能在新运维数据接入时进行合理的归纳。基于对运维业务的理解，结合主题域的划分的原则，我们将运维数据主题域划分为资源对象域、生产运行域、运维活动域三个主题域。以下将从定义、识别、示例三个方面介绍各数据主题域。

 

资源对象域

 

1）定义：运维领域的对象实体数据。

 

2）识别：各运维专业领域所管理的对象均可作为资源对象纳入该数据域，建议以最小运维管理单元为最细粒度资源对象。

 

3）示例：应用运维领域资源对象包括应用系统、应用服务（应用交易是否划分为资源对象视在运维业务需要而定）；系统运维领域运维对象包括逻辑服务器（CPU、内存不是最小运维管理单元，不建议作为资源对象，逻辑服务器与操作系统实例为一对一关系，且逻辑服务器定义范围大于操作系统实例，操作系统实例也不建议作为资源对象）。

 

生产运行域

 

1）定义：资源对象在生产运行过程中产生，可以体现资源对象在某时刻的客观健康状态数据。

 

2）识别：本主题域内以指标、告警、日志数据为主。

 

• 指标类数据主要包括：
• --资源对象生产运行过程中产生资源消耗；
• --资源对象生产运行中承载的业务明细的统计；
• --资源对象当前运行状态等。

 

• 告警类数据主要包括：
• --资源对象按照运维人员通过“监控”的运维活动定义的规则产生的自身健康状态异常的信息；
• --包括指标监控（基于为单一指标的固定阈值制定的监控规则）及智能分析监控（基于多指标组合分析或其他算法统计分析来设置监控规则）产生的告警信息。

 

• 日志类数据主要包括：
• --资源对象及其包含组件在其运行过程中产生的文本信息，包括但不限于运行记录、访问记录、错误记录等。

 

3）示例：

 

• 指标数据示例：
• --资源消耗类指标如逻辑服务器资源对象的CPU利用率指标、文件空间使用率；
• --业务明细统计类指标如应用系统资源对象的TPS、TPM；存储类资源对象的IOPS；交换机等网络类资源对象提供数据传输服务，bps属于其业务明细统计指标；
• --运行状态类指标如应用服务的启动、停止状态。

 

• 告警数据示例：
• --指标类告警如文件空间使用率超阈值告警等；
• --智能分析类告警如全局性系统交易基线告警等。

​​​​​​​​​​​​​​

• 日志数据示例：
• --应用系统资源对象应用日志；
• --中间件实例资源对象产生的中间件日志，如nginx的access.log。

 

运维活动域

 

1）定义：运维人员对资源对象所进行的一系列运维活动所产生的数据。

 

2）识别：以行内ITIL流程数据为主。

 

3）示例：包括监控、变更、容量、事件、问题、整改、巡检、切换、数据备份恢复等活动中产生的工单数据及操作数据等。

 

PART 02 运维数据仓库分层

 

数仓对数据进行分层管理，有以下几个好处：

 

1 数据结构更加清晰：数据分层很清晰的将各数据表在数仓中的所处的阶段区分开来，可以根据数据表所在的分层很清晰的理解该表的所处的定位及其标准化程度，便于选取和使用数据；

 

2 数据血缘管理方便：上层应用场景使用的数据表可能经过多个数据表的多次加工生成，数据分层使得数据血缘关系查找更加方便，当使用场景的数据表出现问题，能够快速定位根源表并分析受影响范围；

 

3 数据复用程度提高：数据分层中会设计一些中间层数据，如汇总层数据，在为上层场景服务时减少极大的重复计算，提升服务交付效率；

 

4 复杂问题拆解方便：每个数据分层都有自己的功能定位及作用范围，较为复杂的数据处理任务可以根据每层的功能定位进行拆分，每个数据分层负责其中一部分功能。

 

贴源层｜ODS

 

用以储存贴源数据，主要完成对运维各来源系统结构化和半结构化数据数据的引入。我行各工具系统接入及生产环境采集的数据均会通过kafka每日全量同步到ODS层中，作为源端数据的备份，同时为下游的数据清洗加工做准备。该层主要完成各类结构化和半结构化的运维数据引入到数据仓库，保留原始数据，包括增量和全量明细。我行目前已接入CMDB配置数据、业务交易指标数据、告警数据、系统性能数据共计28个topic源，均通过kafka实时同步到数仓贴源层中。

 

明细事实层/公共明细层｜DWD

 

DWD层主要对ODS层数据进行规范化编码转换，清洗，统一格式，脱敏等，不做数据表的横向整合。主要包括：

• 单位统一，比如金额单位统一为元；
• 字段类型统一；
• 注释补全；
• 空值用默认值或者中位数填充；
• 时间字段格式统一，如 2021-03-08,2021/03/08,20210308 统一格式为 2021-03-08；
• 过滤没有意义的数据等。

 

经过上述步骤最终形成标准数据模型。我行目前已经完成60余配置项数据及交易性能数据、告警数据、系统性能数据等标准化建模并接入DWD层。

 

维度层｜DIM

 

维度建模从分析决策的需求出发构建维度模型，为数据分析需求服务。因此它重点关注用户如何更快速地完成数据分析需求，同时具有较好的大规模复杂查询的响应性能。维度模型则是对明细事实层模型中事件的要素的描述信息，维度模型所包含的表示维度的列，称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。例如，在逻辑服务器数据模型中，可以将该表常用的查询约束、分组条件如所属应用系统、是否虚拟化、服务器类型等字段提取出来进行维度建模，这样运维人员可以很方便的通过维度模型统计某应用系统下的所有服务器生成报表。我行目前已经对60余个配置数据模型生成了资源对象维度。

 

轻度汇总层｜DWS

 

DWS层主要负责对DWD层明细事实表进行汇总，也称为汇总事实表。即新建立一个事实表，它的维度表是比DWD层维度表要少，或者某些维度表是原维度表的子集，如用月份维度表代替日期维度表；事实数据是相应事实的汇总，即求和或求平均值等。可以大幅的提升查询性能，但增加了存储成本，且限制了用户的自定义查询。如果发生与之关联的纬度发生缓慢变化，可能需要重刷聚集事实的所有分区；我行结合某系统多维度交易指标分析的需求，已完成对交易性能数据相关轻度汇总模型的设计，待后续功能上线后进行数据服务提供。

 

应用层｜ADS

 

应用层数据提供直接面向运维场景的数据。为方便实现数据应用、数据消费、数据订阅的诉求，按照需求进行数据的组装，进行面向应用逻辑的数据加工处理。我行目前数据应用场景主要包括大屏展示、交易指标分析等。

 

 

 

图3 数据使用场景：异常指标分析

 

 

 

图4 数据使用场景：大屏视图设计

 

数据质量规则体系的设计及功能建设

 

PART 01 质量检查规则库设计

 

数据质量直接影响后续的数据服务能力，为进一步提升运维数据质量，我行建立了数据质量检查规则库。按照质量规则是否与数据业务含义相关，可将其分为技术类质量检查规则、业务类质量检查规则两类。业务类质量检查规则由各运维领域管理员根据数据含义按需设置，持续根据具体实施情况补充完善规则列表；按照质量规则的作用范围分类，可以分为单列、跨列、跨行、单表、跨表五类质量检查规则。

 

 

 

图5 数据质量规则库设计

 

单列类规则主要包括非空字段检查、语法约束、格式规范、长度约束、值域约束、值域缺失、事实参照标准；跨列类规则主要包括时效性、等值一致约束、逻辑一致约束；跨行类规则主要包括记录唯一、层级结构一致约束；单表类规则主要包括记录数；跨表类规则主要包括外关联约束、跨表等值一致约束、跨表逻辑一致约束。所有的数据表均根据自身特性选择性实施质量检查规则，质量检查规则库在实施过程中也不断的根据具体情况进行丰富和完善。

 

PART 02 质量检查功能建设

 

我行在科技运营数据平台中实现了质量检查配套功能支撑，用户可以在首页看到质量检查总览；可以在质量检查配置功能对数据表进行灵活的质量检查配置，包括检查周期、执行策略、抽样条件等；还提供质量检查报告功能，可以查看并导出明细的数据质量检查结果。

 

目前已经在平台上实施了空值校验、日期格式校验、值域校验、枚举值校验、IP地址校验、端口校验、目录校验、数值校验、重复值校验，表记录数校验等规则，并按周生成质量检查报告。

 

 

 

图6 质量检查总览

 

 

 

图7 质量检查任务配置

 

 

 

图8 质量检查报告

 

数据治理经验成果总结

 

为进一步总结数据治理工作的经验及成果，为数据后续对数据治理效果的跟踪评估提供，我行从数据治理概述、数据治理方法论、数据治理结果输出、数据建模规范等方面总结数据治理的经验及产物《科技运营数据治理白皮书》，为数据质量及数据服务能力的提升奠定基础。

 

白皮书第一章为数据治理概述，主要介绍了运维数据治理的背景意义；第二章为术语定义；第三章介绍了分层分域的数据治理架构，是数据治理方法论介绍的主要章节；第四章为数据质量检查规则库设计；第五章为运维数据资产清单，介绍了各类运维数据的元数据信息；第六章为运维数据质量检查报告，实时记录数据质量情况。附录为数据建模规范，包含了各类数据标准等。随着数据治理工作的进一步推进，还将继续优化和完善白皮书内容。

 

 

 

图9 科技运营数据治理白皮书

 

总结与展望

 

未来，我行将围绕数仓建设进一步推进运维数据治理，一方面围绕数据标准化模型推广及数据质量检查进一步推进数据质量提升，另一方面还将探索多样、便捷的数据服务形式，通过优质的数据服务提升运维工作数字化水平。另外，随着云原生、分布式等技术架构转型，对运维数据治理甚至是运维工作模式都带来巨大影响，我行将进一步深入探讨新运维模式下运维数据治理的新方法，新思路。

 

“实践案例分享-光大银行”编委介绍

 

 

 

 

精彩预告

 

下期将分享擎创科技的实践案例之“与某国有大行共探数字化发展，迈向一体化数智运维阶段”，详情敬请关注“双态IT论坛BOA”公众号！