【思考】数据资产管理痛点以及解决思路

本文涉及的产品
数据管理 DMS,安全协同 3个实例 3个月
推荐场景:
学生管理系统数据库
简介: 文章中所有内容均为本人从事大数据行业以来,所遇到的数据开发-数据仓库-数据管理方向所暴露出来的通用性问题以及思考后总结的一些解决思路,无关具体行业与业务。希望自己的思考可以给各位同仁提供一些微不足道的参考。一、痛点总结1.1 元数据层面目前很多公司亦或是不重视或是不存在元数据层面的管理,殊不知作为大数据中老生常谈的内容,其存在的必要性以及其对数据管理的有效性。元数据作为记录数据的数据,随着公司数据资产的增加,需要对其进行有效的管理,从而能够快速获取到数据的相关信息并进行使用。包括数据在哪里.
​文章中所有内容均为本人从事大数据行业以来,所遇到的数据资产管理中暴露出来的通用性问题以及思考后总结的一些解决思路,无关具体行业与业务。
希望自己的思考可以给各位同仁提供一些微不足道的参考。

一、痛点总结

1.1 元数据管理痛点

目前很多公司或是同仁几乎不存在或是不重视元数据层面的管理,但是作为大数据建设中不可或缺的一环,我们需要意识到其对数据管理的重要性。

元数据作为记录数据的数据,随着公司数据资产的增加,需要对其进行有效的管理,从而能够快速获取到数据的相关信息并进行使用。
其中包括包括数据在哪里、由谁负责,数据中的值意味着什么,数据的生命周期是什么,哪些数据安全性和隐私性需要保护,以及谁使用了数据,用于什么业务目的,数据的质量怎么样,等等。上述问题都可以通过元数据管理解决,缺乏有效的元数据管理,企业的数据资产可能会变成拖累企业运营的“包袱”。

元数据的重要性

以下内容为本人总结的元数据管理相关痛点

1.负责人不清晰

数据使用过程中,在对数据产生疑惑时,通常需要在群里询问当前库表的负责人/抽取者/维护者/业务数据方

2.无业务描述

当前数据表示的具体业务描述;

3.基础信息获取繁琐

在查看数据库表基础信息时,步骤繁琐,无法自动获取。其中包括以下内容

  1. 表字段信息:物理数据库表名称、列名称、字段长度、字段类型、约束信息、数据依赖关系等
  2. 存储信息:包括当前库表的物理地址,占用空间,文件格式(textfile,sequencefile,rcfile,orcfile),压缩类型(gzip,lzo,bzip2,snappy),分区数量,文件数量等
  3. 数据总量:当前表中数据总量以及各分区中数据总量
  4. 权限信息:当前表对应各个用户的权限信息

4.ETL信息未记录

在数仓建设过程中,几乎每张表都需要进行ETL操作,但是其相关的ETL操作信息却没有进行统一记录,而是存在与各调度平台以及SQL语句中。其中包括:

  1. 抽取时间:抽取任务的运行时间
  2. 抽取频率:周/天/小时/分钟/自定义
  3. 抽取逻辑:增量抽取/全量抽取/拉链表/覆盖/新增
  4. 抽取依赖:前置抽取节点与后置抽取节点不清晰,无法确定当前抽取任务的影响范围。

5.数据质量信息未知

在对数据进行数据质量监测的时候,以下数据质量信息孤立存在,未与表及字段进行绑定。

  1. 表级异常规则:对当前表进行数据质量检测中产生的异常规则
  2. 字段级异常规则:对当前表中具体字段进行数据质量检测中产生的异常规则
  3. 告警方式:邮箱/钉钉/企业微信/短信/手机等

6.数据使用情况未知

对于当前表的使用情况,引用频率,对接的报表数量,热点字段的使用都未统计。

7.库表优先级未划分

并未对库表优先级进行划分,在数据任务运行密集的时间段,可能导致资源挤兑,从而导致任务失败。
划分优先级可统筹集群资源使用情况,对数据任务进行批次划分并运行。
库表优先级可根据以下情况进行划分

  1. 根据血缘依赖关系划分:血缘依赖节点较多的表,优先级高
  2. 根据业务划分:重要业务相关表,优先级高
  3. 自定义划分:手动指定库表优先级

8.数据变更未记录

数据变更记录不明确,主要包括以下内容:

  1. 字段增减
  2. 字段类型改变
  3. 表及字段的注释内容

1.2 数据血缘管理痛点

数据血缘属于元数据管理层面,但是由于其重要性,所以将其单独列出详细讲解。

数据血缘是元数据管理、数据治理、数据质量监测的重要一环,用于追踪数据的来源、处理、出处,对数据价值评估提供依据。

数据血缘用途:

  1. 追踪数据溯源:当数据发生异常,帮助追踪到异常发生的原因;影响面分析,追踪数据的来源,追踪数据处理过程。
  1. 评估数据价值:从数据受众、更新量级、更新频次等几个方面给数据价值的评估提供依据。
  2. 数据归档、销毁的参考:如果数据没有了受众,就失去了使用价值。从数据的血缘关系图上看,最右边没有了数据节点,就可以去评估主节点所代表的数据是否要归档或者销毁了。
  3. 数据质量评估:从数据的血缘关系图上,可以方便的看到数据清洗的路线,反映了对数据质量的要求。

以下内容为本人总结的数据血缘管理相关问题

1.字段级别依赖未知

数据流入/流出字段未知

2.表级别依赖未知

数据流入/流出表未知

3.使用结构化数据库存储血缘

结构化数据库无法快速对血缘关系进行可视化展示,数据不够直观。推荐使用图数据库进行数据血缘的存储。

neo4j图数据库

4.数据价值未知

在血缘关系图上,当前节点的数据受众、更新量级,更新频率越多,说明数据使用较为频繁,以此可以推断出当前数据的价值。

  1. 数据流出情况:在血缘关系图上,数据流出节点表示受众,为数据需求方,数据需求方越多表示数据价值越大;
  2. 更新量级:数据血缘关系图中,数据流转线路的线条越粗,表示数据更新的量级越大,从一定程度上反映了数据价值的大小;
  3. 更新频率:数据更新越频繁,表示数据越鲜活,价值越高。在血缘关系图上,数据流转线路的线段越短,更新越频繁。

5.数据质量要求难以评估

从数据的血缘关系图上,可以方便的看到数据清洗的路线,反映了对数据质量的要求。

6.无法对数据归档、销毁提供参考

如果数据没有了受众,就失去了使用价值。从数据的血缘关系图上看,最右边没有了数据节点,就可以去评估主节点所代表的数据是否要归档或者销毁了。

1.3 指标体系管理痛点

可能很多数据开发的同学觉得无需对指标体系进行重点关注,毕竟这项工作的责任边界偏向于BI报表团队,但是我们在进行数仓dws层和ads层开发的时候,也需要对数据进行汇总并提供各种通用性指标,一个好用的指标体系会大大提高数仓建设效率,并且也能更好地为BI部门提供服务。

数据指标体系是对业务指标体系化的汇总,用来明确指标的口径、维度、指标取数逻辑等信息,并能快速获取到指标的相关信息。一个好用的指标体系可以做到以下几点:

  1. 统一指标口径。同一个指标在不同部门的口径定义是不一样的,如果每个部门各说各话,会产生误差从而影响效率。统一口径可以避免定义模糊和逻辑混乱,从而影响业务开展和数据质量
  1. 了解业务现状:指标可以量化业务情况,清楚了解业务现状,定位问题及改善方向
  2. 科学决策业务:一个相对全面的数据指标体系,可以让管理层从数据层面对公司的发展有一个比较客观的认识,让每一次决策都有足够的证据支撑
  3. 主动发现问题:有了数据指标体系,我们可以清晰的看到各种指标的上升或者下降,能够通过多个维度完全量的流程来帮我们分析,也可以帮助我们主动发现问题

为什么需要数据指标体系

以下内容为本人总结的指标体系相关问题

1.指标名称不规范

一个规范的指标名称需要包含以下四个方面:

  1. 限定词/维度:对指标进行限定约束。比如:当天、本周、当月、平均、累计。

业务主题

  1. 业务主题:描述业务在哪个过程阶段。比如:打开页面、下单、点击支付、支付成功、支付失败。

可以帮助读者快速理解指标来源

  1. 指标名称:指标要统计的对象实体名称。比如:统计订单还是用户。
  2. 量化词:是对物理量的测定,通常以数字单位来表示。比如:金额、份额、次数、率。

2.数据来源不清晰

其中包括当前指标所用到的来源表与来源字段

3.指标定义不明确

  1. 业务表述:当前指标所描述的具体业务是什么。
  2. 统计口径:统计的维度和单位都需要标明。
  3. 计算逻辑:当前指标的计算逻辑
  4. 限定标准:当前指标内有无限定条件,例如城市、日期等。
  5. 指标变化:指标变化所表达的业务含义,以及可能带来的影响或者后果有哪些。
  6. 指标异常的判定条件:当前指标的异常波动阈值或判定条件

4.目标群体模糊

哪些人员需要重点关注,可以添加指标异常后的邮件告警。

5.浏览次数未知

每个指标的浏览次数未知,无法对指标的重要程度进行划分以及留存进行判定。
可以通过添加埋点的方式计算指标页面的点击率等,从而辅助判断指标的重要程度。
对于浏览频率低的指标可以进行存档后下架。

6.优先级未划分

无法根据重要程度划分指标需要的计算资源,容易产生资源挤兑,造成指标计算异常。
指标优先级可根据以下情况进行划分

  1. 自定义划分:手动指定指标优先级
  2. 根据浏览人划分:领导关注的指标需要提高优先级
  3. 根据埋点数据划分:高频指标提高优先级

7.业务路径/用户旅程地图未知

目前指标所标识表示的业务,其在用户旅程地图中的业务位置如何。
如果当前指标发生变化,其变化的原因可以根据前置业务指标去查找,变化的影响可以从后置业务指标去查看。可以根据数据域去划分当前业务路径,并且指定每个业务路径中的所属指标。

  1. 当前业务路径
  2. 前置业务路径指标
  3. 后置业务路径指标

8.指标层级不明确

没有对指标进行层级划分,无法对指标进行重点关注以及影响关系分析。

  1. 一级指标
  2. 二级指标
  3. 三级指标

1.4 调度层面痛点

目前业内调度组件众多,且侧重点不同,常见的有airflow,azkaban,dolphinscheduler,xxl-job,crontab,datax-web,tableau,BI自带调度,自研调度组件等。大数据平台的建设往往需要用到多种调度工具,每种调度工具侧重点不同,例如

  1. ods层需要用到datax-web或者crontab调度sqoop,
  2. 数仓建设需要用到dolphinscheduler,airflow,azkaban等
  3. 指标以及报表的建设需要用到tableau或者商业BI自带的调度功能。

DolphinScheduler

Airflow

多个调度组件之间相互独立,无法形成任务之间的有效依赖。且单个调度组件内部的依赖关系也较为混乱,这样会导致以下问题:

1.调度平台未打通

无法协调多个组件之间的调度关系,目前只有通过时间顺序进行调整。例如ods层调度时间 > 数仓层调度时间 > 指标层调度时间。

2.调度依赖混乱

工作流与工作流之间,表与表之前的依赖关系混乱。这样在发生调度故障时,主要有以下三个困难:

  1. 无法快速定位错误节点,包括其前置节点与后置节点
  2. 无法进行影响分析
  3. 后续受影响的调度节点无法自动化重启

3.表与任务关系不明确

很多调度组件中,一个调度任务可以包含多张表,如果不加以记录管理,就会导致后续同事在使用的时候,无法定位到表的具体任务。

4.调度级别不明确

多个调度任务并行运行时,容易造成资源挤兑,需要根据级别来进行调度任务顺序的调整。

二、解决思路

1、构建数据管理平台,对目前涉及的库表,指标进行纳管。通过平台代替人工管理,减少重复劳动,提高管理效率。

2、通过构建数据字典与指标体系,打通企业内部数据分享壁垒,提高数据利用效率。

3、通过构建数据血缘关系,追溯数据使用情况及影响分析。

4、梳理调度依赖关系并统一管理,减少因调度混乱出现的异常。

三、具体实现

3.1 数据字典

通过数据字典的方式记录元数据信息并管理,以表为管理单位,字段为最细粒度存储单位。
数据字典中的信息分为手动登记信息、自动获取信息、脚本触发信息

手动登记信息

手动登记信息既为需要数据管理者手动填写的纳管库表的相关信息,主要包括以下方面:

  1. 库表名
  2. 数据库类型:Hive、Hbase、CK、Doris、ES等
  3. 负责人
  4. 业务描述
  5. 数据抽取语句
  6. 抽取逻辑:增量抽取/全量抽取/拉链表/覆盖/新增等
  7. 抽取时间
  8. 抽取频率
  9. 当前库表的优先级
  10. 数据质量信息:表级异常规则、字段级异常规则、告警方式等

自动获取信息

可以通过脚本或者代码的形式获取当前库表的元数据信息并进行纳管。

  1. 表字段信息:列名称,字段长度,字段类型,约束信息等
  2. 数据总量:总表数量,分区数量
  3. 存储信息:物理地址,占用空间,文件格式,压缩类型,分区数量,文件数量等
  4. 权限信息
  5. 变更记录:字段增减,类型修改,注释修改等
  6. 数据使用情况:报表使用,血缘依赖,应用开发等

3.2 数据血缘

通过建设数据血缘,并采用图数据库进行存储,便于进行数据关系的可视化展示与追踪溯源。

1.血缘信息获取

  1. SQL解析:通过当前表的sql抽取语句解析当前表的流入节点,并且将其流入关系存储至图数据库中。
  2. 手动指定:对于无法使用sql解析的语句,可以采取手动指定的方式指定当前表的流入节点和流入字段。

2.构建血缘关系表

表中包括以下信息:

  1. 当前表ID
  2. 前置节点
  3. 后置节点
  4. 头部节点
  5. 尾部节点

2.构建血缘统计表

表中包括以下统计信息:

  1. 直接前置节点数量
  2. 前置节点总数
  3. 直接后置节点数量
  4. 后置节点总数

3.血缘应用

  1. 血缘可视化:通过图数据库实现。
  2. 节点定位:根据字段名称或者表名称可以直接查看当前节点的血缘关系。
  3. 影响分析:在对某字段进行修改后,可查看当前字段的后置节点,并对其进行修改。
  4. 数据销毁参考:可对冷门节点进行删除操作,节省资源。
  5. 数据质量评估:从数据的血缘关系图上,可以方便的看到数据清洗的路线,反映了对数据质量的要求。

3.3 打通调度

通过API的方式打通各调度平台中的调度任务,并对调度依赖进行重新梳理

1.获取调度任务

通过API的方式获取所有调度平台中的任务并进行存储

2.任务与表绑定

将调度任务与数据字典中的表绑定。

3.表级调度启停

可以直接在数据字典页面对当前表进行调度的启停。

4.表级调度依赖

根据血缘关系,关联当前表的后置节点表,并可进行统一调度。

5.跨平台调度依赖

目前存在多个调度平台,平台间调度主要依靠时间顺序进行前后置依赖。
打通跨平台调度后,可构建跨平台依赖关系,故障恢复更便捷。

3.4 指标体系

1.构建指标字典

通过构建指标字典,规范存储指标的信息,从而让使用者可以快速的获取并理解指标定义,其中指标字典包括以下信息:

  1. 指标名称:包括:限定词/维度、业务主题、指标名称、量化词
  2. 指标层级:一级指标、二级指标、三级指标
  3. 数据来源:来源表、来源字段
  4. 指标定义:业务表述、统计口径、计算逻辑、限定标准、指标变化含义、指标异常的判定条件
  5. 目标人、需求方

2.报表页面埋点

在报表系统中构建页面埋点,统计每个报表的pv,nv等信息,从而可以直观的看出每个报表的使用情况,并且作为指标销毁的参考。

3.重要程度划分

  1. 根据浏览人划分
  2. 根据埋点数据划分
  3. 自定义划分

4.构建用户旅程地图

用户旅程地图

用户旅程地图作为对公司核心业务的拆解,形成一个个具体的,有先后顺序的业务流程,从而体现出用户的行为路径。

在此之上对用户的每一个行为路径进行分析,了解每个阶段中用户的行为、以及业务目标。

构建指标用于查看业务目标是否达成,从而发现各阶段中产品的痛点和机会点。并且在指标变动过程中可以定位影响分析。

  1. 梳理业务流程:梳理公司核心业务流程
  2. 绑定关键指标:将每个核心业务流程中,绑定其关键指标
  3. 影响分析:当前指标变化后,可以根据用户旅程地图快速的查看当前指标的变化原因和影响。主要根据其前置业务指标,后置业务指标进行分析。
相关实践学习
数据库实验室挑战任务-初级任务
本场景介绍如何开通属于你的免费云数据库,在RDS-MySQL中完成对学生成绩的详情查询,执行指定类型SQL。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
6月前
|
数据采集 存储 监控
一个平台搞定数据治理,让数据资产发挥价值
本文将为大家解析如何通过袋鼠云数据治理中心进行企业数据多维度治理,实现数据资产的最大化利用和价值发挥。
60 0
|
3天前
|
开发框架 运维 供应链
如何进行资产梳理(上)
本文介绍了资产梳理的重要性,特别是对于蓝队成员在护网行动中的准备工作。资产梳理包括安全防护设备、对外开放服务项目和项目外包业务流程的详细信息整理,如设备型号、版本、责任人等。此外,还提到了两种资产梳理方式:一是关注业务资源、设备资产和第三方服务信息;二是识别和管理账号权限、互联网风险、后台目录风险、旁站风险、C段风险和端口风险。文章强调了暴露面收敛的重要性,如关闭非必要服务和端口,以降低安全风险。最后,作者总结了资产梳理的步骤,认为这与Web信息收集类似,是蓝队防御的关键环节。
|
3月前
DataphinV3.14全新升级:数据研发突破全域覆盖,资产治理更加灵活可控
DataphinV3.14全新升级:数据研发突破全域覆盖,资产治理更加灵活可控
214 0
|
4月前
|
数据采集 存储 监控
《数据资产管理实践》方法论梳理
《数据资产管理实践》方法论梳理
139 1
|
7月前
|
数据采集 数据建模 BI
数据中台实战(05)-如何统一管理纷繁杂乱的数据指标?
数据中台实战(05)-如何统一管理纷繁杂乱的数据指标?
203 1
|
9月前
|
数据采集 人工智能 数据管理
数据资产化的前提-浅谈数据治理体系的建设
数据资产化的前提-浅谈数据治理体系的建设
|
数据采集 传感器 架构师
谈谈数据资产管理晓知识
数据是组织的一种战略性商业资产,也是组织拥有的最有价值的资源之一。但它的价值取决于质量、相关性和范围。
谈谈数据资产管理晓知识
|
数据采集 监控 Oracle
谈谈如何构建基于业务价值驱动的数据治理运营模式
成功的组织有各种各样的规模。这些公司的共同特点是,在优化业务流程执行的同时,通过最大化客户服务来挖掘其全部潜力。
谈谈如何构建基于业务价值驱动的数据治理运营模式
|
数据采集 存储 监控
电商项目之数据治理流程分析|学习笔记
快速学习电商项目之数据治理流程分析
179 0
电商项目之数据治理流程分析|学习笔记
|
监控 网络协议 Python
笔记-资产监控拓展
资产监控拓展
314 0
笔记-资产监控拓展