数据中台学习笔记-元数据管理，指标管理，数据模型.pdf

数数据据中中台台学学习习笔笔记记-元元数数据据管管理理，，指指标标管管理理，，数数据据模模型型

概概述述

上⼀篇⽂章主要介绍了数据中台的原理知，现在开始介绍数据中台的实现篇章，主要从3个⽅⾯来说明，第⼀个是元数据的管理，第⼆个是指标的规范的管理，

第三个是数据模型的建⽴。

元元数数据据

在原理篇中，我提到数据中台的构建，需要确保全局指标的业务⼝径⼀致，要把原先⼝径不⼀致的、重复的指标进⾏梳理，整合成⼀个统⼀的指标字典。⽽这项⼯

作的前提，是要搞清楚这些指标的业务⼝径、数据来源和计算逻辑。⽽这些数据呢都是元数据。你可以认为，如果没有这些元数据，就没法去梳理指标，更谈不上

构建⼀个统⼀的指标体系。当你看到⼀个数700W，如果你不知道这个数对应的指标是每⽇⽇活，就没办法理解这个数据的业务含义，也就⽆法去整合这些数据。

所以你必须要掌握元数据的管理，才能构建⼀个数据中台。

那么问题来了：元数据中⼼应该包括哪些元数据呢？什么样的数据是元数据？

元元数数据据分分类类

结合我的实践经验，我把元数据划为三类：数据字典、数据⾎缘和数据特征。我们还是通过⼀个例⼦来理解这三类元数据。

在这个图中，dwd_trd_order_df是⼀张订单交易明细数据，任务flow_dws_trd_sku_1d读取这张表，按照sku粒度，计算每⽇sku的交易⾦额和订单数量，输出轻

度汇总表dws_trd_sku_1d。数据字典描述的是数据的结构信息，我们以dws_trd_sku_1d为例，数据字典包括：

数据⾎缘是指⼀个表是直接通过哪些表加⼯⽽来，在上⾯的例⼦中，dws_trd_sku_1d是通过dwd_trd_order_df的数据计算⽽来，所以，dwd_trd_order_df是

dws_trd_sku_1d的上游表。数据⾎缘⼀般会帮我们做影响分析和故障溯源。⽐如说有⼀天，你的⽼板看到某个指标的数据违反常，让你去排查这个指标计算是

否正确，你⾸先需要找到这个指标所在的表，然后顺着这个表的上游表逐个去排查校验数据，才能找到异常数据的根源。⽽数据特征主要是指数据的属性信息，我

们以dws_trd_sku_1d为例：

通过这个例⼦，你了解了元数据了吗？不过元数据的种类⾮常多，为了管理这些元数据，你必须要构建⼀个元数据中⼼。那么接下来，我们就来看看如何搭建⼀个

元数据中⼼，打通企业的元数据。

业业界界元元数数据据中中⼼⼼产产品品

我做系统设计这么些年，⼀直有⼀个习惯，是先看看业界的产品都是怎么设计的，避免关门造车。业界的⽐较有影响⼒的产品：

开源的有Netflix的Metacat、ApacheAtlas；

商业化的产品有ClouderaNavigator。

我今天重点想带你了解Metacat和Atlas这两款产品，⼀个擅长于管理数据字典，⼀个擅长于管理数据⾎缘，通过了解这两款产品，你更能深⼊的理解元数据中⼼

应该如何设计。

Metacat多数据源集成型架构设计关于Metacat，你可以在Gitub上找到相关介绍，所以关于这个项⽬的背景和功能特性，我就不再多讲，我只想强调⼀个点，就

是它多数据源的可扩展架构设计，因为这个点对于数据字典的管理，真的太重要！

在⼀般的公司中，数据源类型⾮常多是很常见的现象，包括ive、MySQL、Oracle、Greenplum等等。⽀持不同数据源，建⽴⼀个可扩展的、统⼀的元数据层是

⾮常重要的，否则你的元数据是缺失的。从上⾯Metacat的架构图中，你可以看到，Metacat的设计⾮常巧妙，它并没有单独再保存⼀份元数据，⽽是采取直连数

据源拉的⽅式，⼀⽅⾯它不存在保存两份元数据⼀致性的问题，另⼀⽅⾯，这种架构设计很轻量化，每个数据源只要实现⼀个连接实现类即可，扩展成本很低，我

把这种设计叫做集成型设计。我认为这种设计⽅式对于希望构建元数据中⼼的企业，是⾮常有借鉴意义的。

ApacheAtlas实时数据⾎缘采集同样，关于ApacheAtlas的背景和功能，我也不多说，只是想强调Atlas实时数据⾎缘采集的架构设计，因为它为解决⾎缘采集的

准确性和时效性难题提供了很多的解决思路。⾎缘采集，⼀般可以通过三种⽅式：

通过静态解析SQL，获得输⼊表和输出表；

通过实时抓取正在执⾏的SQL，解析执⾏计划，获取输⼊表和输出表；

通过任务⽇志解析的⽅式，获取执⾏后的SQL输⼊表和输出表。

第⼀种⽅式，⾯临准确性的问题，因为任务没有执⾏，这个SQL对不对都是⼀个问题。第三种⽅式，⾎缘虽然是执⾏后产⽣的，可以确保是准确的