备注:文章内容借鉴了郭忆老师《数据中台》课程,想了解更多可以看这个课程哈、
目录：
一、元数据
1、数据字典
2、数据血缘
3、数据特征
二、指标管理
1、如何规范化定义指标
三、数据模型
1、我建模的方法
2、理想的数仓模型设计应该具备的因素
3、已经存在烟囱式开发，如何变成一个数据中台？
四、数据质量
1、如何提高数据质量
2、如何衡量数据质量
五、数据成本
1、有哪些成本的陷阱
2、如何实现精细化成本管理
3、治理效果评估
六、数据管理工具
不对学习的内容总结，总觉得自己没学习到。这10天在极客时间上面看了郭忆《数据中台》课程，里面的内容每一条都戳中工作遇见的问题，曾吐槽无数次的数据模型烟囱式开发、无数据指标管理、数据质量不能监控、无数据血缘关系分析，在这里都找到判断标准和解决思路了。
课程主要讲了数据只加工一次，数据服务统一的API接口。也就是阿里数据中台的onedate、oneservice的思想。onedate就是数据只加工一次，这是我工作中主要遇见的问题；数据服务的思想是第一次看见、相见恨晚又庆幸自己看见了、它帮我贯穿了数据体系。
数据加工和数据服务都非常重要，本篇文章是对onedate数据加工总结。onedata主要包括六个部分：元数据、指标管理、数据模型、数据质量、数据成本、「元数据、指标、数据模型、数据质量、数据成本」管理工具。
管理工具贯穿整个体系，每个阶段都需要工具管理。剩下的五个部分是独立的，可以逐个突破，除了首先得梳理元数据、剩下的模块可以选择重要的解决
onedata步骤
一、元数据
元数据中心是数据中台的基石，它提供了我们做数据治理必须的数据支撑。比如通过数据血缘：
- 可以根据数据血缘定位数据质量问题
- 可以根据数据血缘计算数据成本
- 可以根据数据血缘，对大数据平台上运行的任务和分析查询进行的统计
（每层表活跃数量、查询数量、每层查询任务目标表分层情况），判断模型好坏。
而数据指标是元数据中心的一部分，所以我们在做数据治理的时候第一步需要梳理元数据。
元数据描述是到每张表的，包括三个部分数据字典、数据血缘、数据特征。
1、数据字典：
数据字典包括表名、表注释、表产出、表英文字段、字段含义、字段类型
以前我以为数据字典就是字段注释，哈哈
2、数据血缘：
表通过哪些表加工而来，要到字段级别，字段通过哪些表加工而来。
数据血缘可以做影响分析和问题溯源。
3、数据特征：数据的属性信息
图片来自《数据中台》课程
数据特征包括存储空间大小，访问热度（每次n次）、分层、主题域、表关联的指标。表的主题域、分层、存储空间大小经常接触；表的访问热度和表关联指标需要理解一下。
第一次看见在描述表特征的时候，可以把表关联的指标列出来。关联上指标、后期在对指标搜索的时候，可以快速定位到某张表。
4、我的思考
元数据就3部分，比较容易理解，但是怎么管理元数据同样是我们关心的。比如我们天天说的数据血缘，数据血缘是怎么通过工具维护的。知道了方向要利用工具去实现还是挺难的，开发一个工具难、哈哈。
补充一下：可以去了解 Metacat 和 Atlas 这两款产品，一个擅长于管理数据字典，一个擅长于管理数据血缘。
Metacat数据字典维护：
Metacat多数据源的可扩展架构设计，它并没有单独再保存一份元数据，而是采取直连数据源拉的方式。想到在以前公司也会管理元数据、也是通过添加数据源、连接数据库、实时获取数据字典等信息
Apache Atlas 实时数据血缘采集
血缘采集，一般可以通过三种方式：
- 通过静态解析 SQL，获得输入表和输出表；
- 通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表；
- 通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。
第一种方式，面临准确性的问题，因为任务没有执行，这个 SQL 对不对都是一个问题。第三种方式，血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析大量的任务日志数据。所以第二种方式，是比较理想的实现方式，而 Atlas 就是这种实现。
郭忆老师课程中的回复
二、指标管理
指标常见问题，图片来自极客时间
指标划一般分为原子指标、派生指标、衍生指标。我接触到的是指标通常是由两个指标相除计算而来；一个指标对应一个需求、一长段的描述。
刚开始我还没迫切想对指标分类，最让头痛是指标重复计算，相同指标结果不一样。看课程才知道原来指标也需要管理的，但对于已经存在的指标梳理，是很难的工作，主要是领导没意识，没人去推动这项工作吧。
虽然没接触规范的指标，但可以学习如何管理它，还是可以一起了解下
1、如何规范化定义指标
1）按照按照业务条线、主题域、业务过程管理指标
2）按原子指标、派生指标、复合指标管理
2.1) 原子指标就是基于业务过程的度量值，比如订单金额。也可以把原子指标定义为不能够按照（统计周期、统计粒度、业务限定词）进一步拆分的指标
2.2) 派生指标 = 统计周期（近30天）+ 统计粒度(商品) + 业务限定（黑卡会员/非会员） + 原子指标（购买用户数）。
现在容易把统计粒度和业务限定词给记混了
粒度：就比如统计销售额的时候会按照，省、市、县、区、商品大类、商品小类等统计。
修饰词：就是维度的属性值，就比如商品大类的属性值可以划分为
蔬菜、水果、饮料
2.3)复合指标:两个或者多个指标，通过一定规则，计算出来的，即为复合指标
3）指标命名规范
指标命名规范要遵循两个基本的原则：
易懂，就是看到指标的名称，就可以基本判断这个指标归属于哪个业务过程；
统一，就是要确保派生指标和它继承的原子指标命名是一致的
4）关联的应用和可分析维度
指标对应的报表
指标可分析维度
5）分等级管理指标
指标那么多，数据中台管理不过来，可以把指标区分等级，来管理指标
一级指标：数据中台直接产出，核心指标（提供给公司高层看的）、原子指标以及跨部门的派生指标。
二级指标：基于中台提供的原子指标，业务部门创建的派生指标。
为什么要区分原子指标和派生指标呢？ 全当原子指标，不就好了，这样能确保每个指标的业务口径都在指标系统里面强管理。
但是这样的后果，是指标的管理工作量太大了，而且整个数据分析的瓶颈会压在指标的管理上。所以就想出来一个方法，能不能把原子指标中，不涉及口径的指标，可以拆出来，而这些就是派生指标。
2、思考
对于经常变化的业务可以先不梳理指标，对于已经稳定不变化的业务需要梳理指标、统一指标的业务计算口径。
其实指标管理目前工作中不怎么用，可以先了解扩充知识。
三、数据模型
不知道规范的模型应该是怎样的，看得最多的就是基于业务过程进行维度建模。在《数据中台》课程中，主要是评价模型好坏的思路，并没有讲dwd、dws、ads如何建模及案例等。
1、我建模的方法
总结下我dwd、dws建模的思想，我认为不完善、没借鉴意义。先简单记录下。在网上看的建模案例比较少，而且针对dws层建模思路都是每日的汇总表，在工作中，我觉得dws建成覆盖小业务过程的大宽表更好使用
1)DWD
维度建模一般按照以下四个步骤：
选择业务过程→声明粒度→确认维度→确认事实。
目前我们的业务过程都是根据需求来的，所以我在dwd层建模一般是：根据需求所涉及的业务过程------》在业务系统中找到对应的表-----》建模：dwd的模型结构可以跟业务库中表结构一样，只是会存在数据清洗、及维度退化。
最近dwd层经常在加字段，主要是流程的开始时间和流程的审批通过时间,应该还是业务不熟悉
2)DWS
总线矩阵
听见最多的就是dws层是汇总层、大宽表。建一些大宽表还是比较适用的。比如我们可以一个大的业务过程、或者一个大的主题域建宽表明细表、和宽表汇总表。
2、理想的数仓模型设计应该具备的因素
一个理想的数仓模型设计应该具备的因素，那就是“数据模型可复用，完善且规范”。
1）DWD 层完善度
ODS 层有多少表被 DWS/ADS/DM 层引用。因为** DWD 以上的层引用的越多，就说明越多的任务是基于原始数据进行深度聚合计算的，明细数据没有积累，无法被复用，数据清洗、格式化、集成存在重复开发**
跨层引用率：ODS 层直接被 DWS/ADS/DM 层引用的表，占所有 ODS 层表（仅统计活跃表）比例。
2)DWS/ADS/DM 层完善度
考核汇总数据的完善度，我认为主要看汇总数据能直接满足多少查询需求
汇总数据查询比例：DWS/ADS/DM 层的查询占所有查询的比例。
跟跨层引用率不同，汇总查询比例不可能做到 100%，但值越高，说明上层的数据建设越完善，对于使用数据的人来说，查询速度和成本会减少
3）模型复用度
数据中台模型设计的核心是追求模型的复用和共享。
模型引用系数：一个模型被读取，直接产出下游模型的平均数量。
比如一张** DWD 层**表被 5 张 DWS 层表引用，这张 DWD 层表的引用系数就是 5。dwd的表被ads层的表引用可以算引用系数吗？。DWD 层表平均模型引用系数，一般低于 2 比较差，3 以上相对比较好（经验值）
5）规范度
规范的表命名应该包括主题域、分层、表是全量快照，还是增量等
更好管理数据模型，可以看每层表活跃表数据量、被读表数量、被写表数量、读表任务数量、写表任务数量。根据各层数量、可以看出模型建设的完善度。
比如：ODS：DWD：DWS：ADS 的读取任务分别是 1072：545：187：433，直接读取 ODS 层任务占这四层任务总和的 47.9%，这说明有大量任务都是基于原始数据加工，中间模型复用性很差。
3、已经存在烟囱式开发，如何变成一个数据中台？
- 1）接管 ODS 层，控制源头
- 2）划分主题域，构建总线矩阵
- 3）构建一致性维度
- 4）事实表整合
- 5）模型开发
关于数据模型，课程给了检验模型的指标。至于如何建模，还需要学习。
四、数据质量
学了之后，发现数据质量都是相通，需要添加数据质量稽核规则，以前的添加的稽核规则是及时性、一致性、规范性；有些规则在数据中台中也可以使用。
来自《数据中台》课程
1、如何提高数据质量
要想提升数据质量，最重要的就是“早发现，早恢复”
- 早发现，是要能够先于数据使用方发现数据的问题，尽可能在出现问题的源头发现问题，这样就为“早恢复”争取到了大量的时间。
- 早恢复，就是要缩短故障恢复的时间，降低故障对数据产出的影响
1）添加稽核校验任务
在数据加工任务中，对产出表按照业务规则，设计一些校验逻辑，确保数据的完整性、一致性和准确性
- 完整性规则。主要目的是确保数据记录是完整的，不丢失.常见的稽核规则:表数据量、表主键
- 一致性规则：解决相关数据在不同模型中一致性的问题
- 准确性规则：解决数据记录正确性的问题。常见的稽核规则有，一个商品只能归属在一个类目，数据格式是不是正确的 IP 格式，订单的下单日期是还没有发生的日期等等。
2）通过智能预警，确保任务按时产出
2、如何衡量数据质量
- 4 点半前数据中台核心任务产出完成率
- 基于稽核规则，计算表级别的质量分数
- 需要立即介入的报警次数，通常以开启循环报警的电话报警次数为准
-
数据产品上所有指标有没有在 9 点产出
课程中的图片
元数据中心、指标管理、数据模型、数据质量，越了解到后面越感受到数据治理很难，研发管理工具难、知道原理方法实施难。不过如果自己深入其中肯定会成长不少，这些点也是提升的方向。
五、数据成本
数据成本是在《数据中台》课程中，才了解到。以前没想过数据还需要计算成本。
郭忆老师在课程里说过：数据像手机中的图片，我们总是不断地拍照，生成图片，却懒得清理，最终手机里面的存储经常不够用。对于30天内没使用的表可以下线。
1、有哪些成本的陷阱
1）数据上线容易下线难
我们可以统计最近30天表使用情况，做成上图所似的数据
2） 低价值的数据应用消耗了大量的资源
数据看上去每天都在被访问，但究竟产出了多少价值，投入和产出是否匹配？这个我们需要思考。
3）烟囱式的开发模式
烟囱式的开发不仅会带来研发效率低的问题，同时因为数据重复加工，还会存在资源浪费的问题
4）数据倾斜
数据倾斜会让任务性能变差，也会浪费大量的资源
5）数据未设置生命周期
原始数据和明细数据，会保留完整的历史数据，汇总层、应用层、集市层，考虑导数据存储成本，数据按照生命周期管理。
大表未设置生命周期、会造成浪费存储资源。
思考：比如我们公司汇总层的数据从上线开始，每天的数据都保存下来。这样就很浪费资源
6）调度周期不合理
7）任务参数配置
8）数据未压缩
2、如何实现精细化成本管理
1)全局资产盘点
图片来自课程
根据数据血缘关系，可以得到末端数据的成本和价值。
**这张报表的成本 **=3 个任务加工消耗的计算资源成本 +6 张表消耗的存储资源的成本
3)数据价值
3、治理效果评估
省了多少钱
- 下线了多少任务和数据
- 这些任务每日消耗了多少资源
- 据占用了多少存储空间
成本治理不是一劳永逸的工作，需要持之以恒，不断发现问题，然后治理优化
关于数据成本我目前是学习里面的思想。我认为自己目前能接触并且重要的是数据模型。以及相关的技术也需要提升。
六、数据管理工具
数仓onedate最后一步就是数据工具管理，如果是购买的平台这些工具都是有的，如果是自己研发可以参考已经有的开源工具。
总结
写到最后脑袋是懵的，不过在复习一篇《数据中台》建设方法任然收获很多。
在附上数据开发职业规划：熟练的使用数据中台支撑技术体系内的工具，熟悉数据中台模式下数据研发的流程，对指标定义、维度建模、数据质量稽核监控、成本的管理、数据安全、数据服务化等内容要有深入的掌握。
网友评论