文章中所有内容均为本人从事大数据行业以来，所遇到的数据资产管理中暴露出来的通用性问题以及思考后总结的一些解决思路，无关具体行业与业务。
希望自己的思考可以给各位同仁提供一些微不足道的参考。

一、痛点总结
1.1 元数据管理痛点

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

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




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

1.负责人不清晰

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

2.无业务描述

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

3.基础信息获取繁琐

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

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

4.ETL信息未记录

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

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

5.数据质量信息未知

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

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

6.数据使用情况未知

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

7.库表优先级未划分

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

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

8.数据变更未记录

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

字段增减
字段类型改变
表及字段的注释内容

1.2 数据血缘管理痛点

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

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

数据血缘用途：

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

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

1.字段级别依赖未知

数据流入/流出字段未知

2.表级别依赖未知

数据流入/流出表未知

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

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




4.数据价值未知

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

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

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

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

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

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

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

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

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




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

1.指标名称不规范

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

限定词/维度：对指标进行限定约束。比如：当天、本周、当月、平均、累计。
业务主题
业务主题：描述业务在哪个过程阶段。比如：打开页面、下单、点击支付、支付成功、支付失败。
可以帮助读者快速理解指标来源
指标名称：指标要统计的对象实体名称。比如：统计订单还是用户。
量化词：是对物理量的测定，通常以数字单位来表示。比如：金额、份额、次数、率。

2.数据来源不清晰

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

3.指标定义不明确

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

4.目标群体模糊

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

5.浏览次数未知

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

6.优先级未划分

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

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

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

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

当前业务路径
前置业务路径指标
后置业务路径指标

8.指标层级不明确

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

一级指标
二级指标
三级指标

1.4 调度层面痛点

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

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




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

1.调度平台未打通

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

2.调度依赖混乱

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

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

3.表与任务关系不明确

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

4.调度级别不明确

多个调度任务并行运行时，容易造成资源挤兑，需要根据级别来进行调度任务顺序的调整。
二、解决思路

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

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

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

4、梳理调度依赖关系并统一管理，减少因调度混乱出现的异常。
三、具体实现
3.1 数据字典

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

手动登记信息

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

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

自动获取信息

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

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

3.2 数据血缘

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

1.血缘信息获取

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

2.构建血缘关系表

表中包括以下信息：

当前表ID
前置节点
后置节点
头部节点
尾部节点

2.构建血缘统计表

表中包括以下统计信息：

直接前置节点数量
前置节点总数
直接后置节点数量
后置节点总数

3.血缘应用

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

3.3 打通调度

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

1.获取调度任务

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

2.任务与表绑定

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

3.表级调度启停

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

4.表级调度依赖

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

5.跨平台调度依赖

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

1.构建指标字典

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

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

2.报表页面埋点

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

3.重要程度划分

根据浏览人划分
根据埋点数据划分
自定义划分

4.构建用户旅程地图




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

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

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

梳理业务流程：梳理公司核心业务流程
绑定关键指标：将每个核心业务流程中，绑定其关键指标
影响分析：当前指标变化后，可以根据用户旅程地图快速的查看当前指标的变化原因和影响。主要根据其前置业务指标，后置业务指标进行分析。
————————————————
版权声明：本文为CSDN博主「李奇峰1998」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/mrliqifeng/article/details/124620282

免责申明：

本文系转载，版权归原作者所有，如若侵权请联系我们进行删除！

《数据治理行业实践白皮书》下载地址：https://fs80.cn/4w2atu

《数栈V6.0产品白皮书》下载地址：https://fs80.cn/cw0iw1

想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友，浏览袋鼠云官网：https://www.dtstack.com/?src=bbs

同时，欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术群」，交流最新开源技术信息，群号码：30537511，项目地址：https://github.com/DTStack