数据中台学习笔记-元数据管理，指标管理，数据模型
概述
上⼀篇⽂章主要介绍了数据中台的原理知识，现在开始介绍数据中台的实现篇章，主要从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、Apache Atlas；
商业化的产品有 Cloudera Navigator。
我今天重点想带你了解 Metacat 和 Atlas 这两款产品，⼀个擅长于管理数据字典，⼀个擅长于管理数据⾎缘，通过了解这两款产品，你更能深⼊的理解元数据中⼼应该如何设计。
Metacat 多数据源集成型架构设计关于Metacat，你可以在 GitHub 上到相关介绍，所以关于这个项⽬的背景和功能特性，我就不再多讲，我只想强调⼀个点，就是它多数据源的可扩展架构设计，因为这个点对于数据字典的管理，真的太重要！
在⼀般的公司中，数据源类型⾮常多是很常见的现象，包括 Hive、MySQL、Oracle、Greenplum 等等。⽀持不同数据源，建⽴⼀个可扩展的、统⼀的元数据层是⾮常重要的，否则你的元数据是缺失的。从上⾯ Metacat 的架构图中，你可以看到，Metacat 的设计⾮常巧妙，它并没有单独再保存⼀份元数据，⽽是采取直连数据源拉的⽅式，⼀⽅⾯它不存在保存两份元数据⼀致性的问题，另⼀⽅⾯，这种架构设计很轻量化，每个数据源只要实现⼀个连接实现类即可，扩展成本很低，我把这种设计叫做集成型设计。我认为这种设计⽅式对于希望构建元数据中⼼的企业，是⾮常有借鉴意义的。
Apache Atlas 实时数据⾎缘采集同样，关于Apache Atlas的背景和功能，我也不多说，只是想强调 Atlas 实时数据⾎缘采集的架构设计，因为它为解决⾎缘采集的准确性和时效性难题提供了很多的解决思路。⾎缘采集，⼀般可以通过三种⽅式：
通过静态解析 SQL，获得输⼊表和输出表；
通过实时抓取正在执⾏的 SQL，解析执⾏计划，获取输⼊表和输出表；
通过任务⽇志解析的⽅式，获取执⾏后的 SQL 输⼊表和输出表。
第⼀种⽅式，⾯临准确性的问题，因为任务没有执⾏，这个 SQL 对不对都是⼀个问题。第三种⽅式，⾎缘虽然是执⾏后产⽣的，可以确保是准确的，但是时效性⽐较差，通常要分析⼤量的任务⽇志数据。所以第⼆种⽅式，我认为是⽐较理想的实现⽅式，⽽ Atlas 就是这种实现。
对于 Hive 计算引擎，Atlas 通过 Hook ⽅式，实时地捕捉任务执⾏计划，获取输⼊表和输出表，推送给 Kafka，由⼀个 Ingest 模块负责将⾎缘写⼊ JanusGraph 图数据库中。然后通过 API 的⽅式，基于图查询引擎，获取⾎缘关系。对于 Spark，Atlas 提供了 Listener 的实现⽅式，此外 Sqoop、Flink 也有对应的实现⽅式。这两款产品在设计⽹易元数据中⼼时，给了很多灵感，下⾯我就带你了解⼀下其他元数据中⼼的设计，以便你掌握⼀个元数据中⼼在设计时应该考虑哪些点。
我设定了元数据中⼼必须实现的 5 个关键⽬标：
其⼀，多业务线、多租户⽀持。电商、⾳乐都是不同的业务线，同⼀个业务线内，也分为算法、数仓、风控等多个租户，所以元数据中⼼必须⽀持多业务线、多租户。
其⼆，多数据源的⽀持。元数据中⼼必须要能够⽀持不同类型的数据源（⽐如 MySQL、Hive、Kudu 等），同时还要⽀持相同数据源的多个集。为了规范化管理，还需要考虑将半结构化的 KV 也纳⼊元数据中⼼的管理（⽐如 Kafka、Redis、HBase 等）。这些系统本⾝并没有表结构元数据，所以需要能够在元数据中⼼⾥定义 Kafka 每个 Topic 的每条记录 JSON 中的格式，每个字段代表什么含义。
其三，数据⾎缘。元数据中⼼需要⽀持数据⾎缘的实时采集和⾼性能的查询。同时，还必须⽀持字段级别的⾎缘。什么是字段级别的⾎缘，我们来举个例⼦。
1 insert overwrite table t
2 select classid, count(userid) from t1 groupby classid;
t2 表是由 t1 表的数据计算来的，所以 t2 和 t1 是表⾎缘上下游关系，t2 的 classid 字段是由 t1 的 classid 字段产⽣的，count 字段是由 userid 经过按照 classid 字段聚合计算得到的，所以 t2 表的 classid 与 t1 的 classid 存在字段⾎缘，t2 表的 count 分别与 t1 表的 classid 和 userid 存在⾎缘关系。
字段⾎缘在做溯源的时候⾮常有⽤，因为⼤数据加⼯链路的下游是集市层，为了⽅便使⽤者使⽤，⼀般都是⼀些很宽的表（列很多的表，避免 Join 带来的性能损耗），这个表的上游可能是有⼏⼗个表产⽣的，如果不通过字段⾎缘限定溯源范围，就会导致搜索范围变得很⼤，⽆法快速地精准定位到有问题的表。另外，数据⾎缘还必须要⽀持⽣命周期管理，已经下线的任务应该⽴即清理⾎缘，⾎缘要保留⼀段时间，如果没有继续被调度，过期的⾎缘关系应该予以清理。
其四，与⼤数据平台集成。元数据中⼼需要与 Ranger 集成，实现基于 tag 的权限管理⽅式。在元数据中⼼中可以为表定义⼀组标签，Ranger 可以基于这个标签，对拥有某⼀个标签的⼀组表按照相同的
权限授权。这种⽅式⼤幅提⾼了权限管理的效率。⽐如，对于会员、交易、⽑利、成本，可以设定表的敏感等级，然后根据敏感等级，设定不同的⼈有权限查看。另外，元数据中⼼作为基础元数据服务，包括⾃助取数分析系统，数据传输系统，数据服务，都应该基于元数据中⼼提供的统⼀接⼝获取元数据。
其五，数据标签。元数据中⼼必须要⽀持对表和表中的字段打标签，通过丰富的不同类型的标签，可以完善数据中台数据的特征，⽐如指标可以作为⼀种类型的标签打在表上，主题域、分层信息都可以作为不同类型的标签关联到表。
基于这 5 个因素的考虑，我们设计了元数据中⼼。
这个图按照功能模块分为数据⾎缘、数据字典和数据特征。数据⾎缘由采集端、消息中间件、消费端以及⾎缘清理模块组成，基于 Hive Hook，Spark Listener，Flink Hook ，可以获取任务执⾏时输⼊表和输出表，推送给统⼀的消息中间件（Kafka），然后消费端负责将⾎缘关系沉淀到图数据库中。图数据库选择Neo4j，主要考虑是性能快、部署轻量化、依赖模块少，当然，开源的 Neo4j 没有⾼可⽤⽅案，并且不⽀持⽔平扩展，但是因为单个业务活跃的表规模基本也就在⼏万的规模，所以单机也够⽤，⾼可⽤可以通过双写的⽅式实现。⾎缘还有⼀个清理的模块，主要负责定时清理过期的⾎缘，⼀般我们把⾎缘的⽣命周期设置为 7天。数据字典部分，我们参考了 Metacat 实现，我们由⼀个统⼀的
navigator标签Connector Mananger 负责管理到各个数据源的连接。对于 Hive、MySQL，元数据中⼼并不会保存系统元数据，⽽是直接连数据源实时获取。对于 Kafka、HBase、Redis 等 KV，我们在元数据中⼼⾥内置了⼀个元数据管理模块，可以在这个模块中定义Value 的 schema 信息。数据特征主要是标签的管理以及数据的访问热度信息。元数据中⼼内置了不同类型的标签，同时允许⽤户⾃定义扩展标签类型。指标、分层信息、主题域信息都是以标签的形式存储在元数据中⼼的系统库⾥，同时元数据中⼼允许⽤户基于标签类型和标签搜索表和字段。元数据中⼼统⼀对外提供了API 访问接⼝，数据传输、数据地图、数据服务等其他的⼦系统都可以通过 API 接⼝获取元数据。另外 Ranger 可以基于元数据中⼼提供的 API 接⼝，获取标签对应的表，然后根据标签更新表对应的权限，实现基于标签的权限控制。元数据中⼼构建好以后，你肯定会问，这个元数据中⼼没有界⾯吗？它长什么样⼦？⽤户咋使⽤这个元数据中⼼？别急，我们接着往下看。
数据地图：元数据中⼼的界⾯
数据地图是基于元数据中⼼构建的⼀站式企业数据资产⽬录，可以看作是元数据中⼼的界⾯。数据开发、分析师、数据运营、算法⼯程师可以在数据地图上完成数据的检索，解决了“不知道有哪些数据？”“到哪⾥数据？”“如何准确的理解数据”的难题。
数据地图提供了多维度的检索功能，使⽤者可以按照表名、列名、注释、主题域、分层、指标进⾏检
索，结果按照匹配相关度进⾏排序。考虑到数据中台中有⼀些表是数仓维护的表，有⼀些表数仓已经不再维护，在结果排序的时候，增加了数仓维护的表优先展⽰的规则。同时数据地图还提供了按照主题域、业务过程导览，可以帮助使⽤者快速了解当前有哪些表可以使⽤。
当使⽤者定位到某⼀个表打开时，会进⼊详情页，详情页中会展⽰表的基础信息，字段信息、分区信息、产出信息以及数据⾎缘。数据⾎缘可以帮助使⽤者了解这个表的来源和去向，这个表可能影响的下游应⽤和报表，这个表的数据来源。
数据地图同时还提供了数据预览的功能，考虑到安全性因素，只允许预览 10 条数据，⽤于判断数据是否符合使⽤者的预期。数据地图提供的收藏功能，⽅便使⽤者快速到⾃⼰经常使⽤的表。当数据开发、分析师、数据运营到⾃⼰需要的表时，在数据地图上可以直接发起申请对该表的权限申请。数据地图对于提⾼数据发现的效率，实现⾮技术⼈员⾃助取数有重要作⽤。经过我的实践，数据地图是数据中台中使⽤频率最⾼的⼀个⼯具产品，在⽹易，每天都有 500 以上⼈在使⽤数据地图查数据。
数据指标规范
元数据在指标管理、模型设计、数据质量和成本治理四个领域都发挥着作⽤，⽽这些领域构成了数据中台 OneData 数据体系。从今天开始，我将带你逐⼀了解元数据在上述领域的应⽤，⾸先是指标管理。指标是⼀种特定类型的元数据，公司的运营会围绕它进⾏⼯作，可以说，它是业务和数据的交汇
点。指标数据能不能⽤，会影响他们的⽇常⼯作。来看⼀件我⾝边发⽣的事⼉。在电商业务中，新⽤户销售额是考核市场活动拉新效果的重要指标。马漂亮（化名）是市场部门的数据分析师，某⼀天，她要给 CEO 提供⼀份数据报告，报告中有⼀项指标是“新⽤户销售额”。孙美丽（化名）是会员中⼼的运营，她每天都会给 CEO 提供每⽇的新⽤户销售额数据。结果有⼀天，CEO 看了这两份报告后发现，同⼀⽇的新⽤户销售额数值相差很⼤，他判断数据出了问题，责令两个部门的负责⼈进⾏排查。排查后发现，市场部门对新⽤户⼝径的定义和会员中⼼不⼀样：
市场部门认定新⽤户是⾸次下单并完成⽀付的⽤户；
会员中⼼认定新⽤户是当⽇新注册⽤户。
也就是说，市场部门认定的新⽤户中，可能有之前注册但是没有下过单的客户；⽽会员中⼼只包括当⽇注册并完成下单⽀付的⽤户。其实，在⽇常⼯作中还有很多类似的问题。造成上述问题的根源是因为指标⼝径不⼀致，⽽你要构建全局⼀致的指标⼝径，输出企业的指标字典。
指标混乱现状
同名不同径，同径不同名。⼝径不清晰，⼝径有错误。命名难理解，计算不易懂。来源不清晰，同部不同径。
第⼀，相同指标名称，⼝径定义不同。我开篇说的就是这个问题，不同的部门对相同的“新⽤户销售额”，因为⼝径定义的差别，导致指标数值的不⼀致。⽽这种情况是指标管理中最容易出现的情况。⼝径不⼀致，数据也就没办法横向对⽐，失去了数据辅助商业决策的意义。
第⼆，相同⼝径，指标名称不⼀样。这种情况与上⾯相反，⽐如发放优惠券是电商常见的促销⼿段，现在你有两个数据产品：⼀个是经营⼤脑，主要展⽰的是企业⽇常经营活动健康度的核⼼指标，它有⼀个指标叫“优惠券抵扣⾦额”；⼀个是市场 360，主要是展⽰市场活动效果衡量的指标，它也有⼀个指标叫“优惠券消耗⾦额”。其实，两者的⼝径定义并没有区别，但是指标名称不同，这会让使⽤指标的⼈疑惑，是不是同⼀个指标，计算逻辑是否⼀致？数据是否可以横向对⽐？
第三，不同限定词，描述相同事实过程的两个指标，相同事实部分⼝径不⼀致。
第四，指标⼝径描述不清晰。在梳理过程中，我们还发现，有些报表上的指标⼝径描述的⽐较笼统。⽐如“关单⾦额”，⼝径描述“关闭订单的⾦额”。不同⼈的理解可能不⼀样，有的⼈会认为是⽀付成功后关闭订单；也有可能是⽀付完成前，取消订单。描述不清晰，就会让⼈们对数据的理解产⽣歧义。
第五，指标⼝径描述错误。在流量分析数据产品中，有“7 ⽇ uv”这个指标，⼝径的定义是 7 ⽇内⽇均 uv。根据⼝径描述的计算逻辑，应该是最近 7 ⽇，每⽇ uv 相加除以 7 取平均值。显然，这个定义在业务场景中是有问题的，正确的 7 ⽇ uv 的⼝径定义应该是 7 ⽇内有登录过，去重的⽤户数。
第六，指标命名难于理解。我们在梳理促销业务过程的指标时，有⼀个数据产品的指标名称是“ROI”，⼝径定义优惠券销售额 / 优惠券成本。ROI 其实是投资回报率的简称，在电商业务场景中，除了优惠劵，商品降价促销都可以计算 ROI，所以⽐较好的命名应该是（商品|类⽬|通⽤）优惠劵 ROI。所以，指标命名不规范的话，从指标名称中很难看出指标描述的业务过程。
最后，指标数据来源和计算逻辑不清晰。如果指标数据来源不清楚，⼀旦这个指标数据异常，就很难去做溯源。另外，有些指标的计算逻辑⽐较复杂，仅仅凭借业务⼝径⼀段描述，使⽤指标的⼈还是⽆法理解这个指标的计算逻辑，这个时候就需要有⼀些伪码或者 SQL 描述。
如何规范化定义指标
那么如果你⾯临这些问题，该如何规范化定义指标呢？我提供给你⼀些经验，希望你能从中学习到如何⾼效、规范化的管理指标。
为了提⾼指标管理的效率，你需要按照业务线、主题域和业务过程三级⽬录⽅式管理指标（业务线是顶级⽬录）。电商、游戏、⾳乐、传媒、教育都是不同的业务线。在业务线之下，是主题域，指标中的主题域与数仓中的概念是⼀致的，划分标准最好是跟数仓保持⼀致（数仓主题域的划分，我会在 06 讲详细讲述）。在主题域下⾯还有细分的业务过程，⽐如对于交易域，细分的业务过程有加⼊购物车、下单、⽀付。
其次，拆分原⼦指标和派⽣指标。为了解决前⾯提到的，“⿊卡购买⽤户数”和“⾮会员购买⽤户数”，这两个指标对购买⽤户数⼝径定义不⼀致的问题，我们需要引⼊原⼦指标和派⽣指标的管理⽅式。那么什么是原⼦指标，什么是派⽣指标呢？统计周期、统计粒度、业务限定、原⼦指标，组成派⽣指标，所以原⼦指标可以定义为不能够按照上述规则进⼀步拆分的指标。
在例⼦中，你可以这样理解：购买⽤户数是原⼦指标，原⼦指标的⼝径定义是“计算周期内去重的，下单并且⽀付成功的⽤户数量，包括关单”；⿊卡会员和⾮会员都可以认定为业务限定词；统计粒度是商
品粒度的；统计周期是 30 天。
这样 30 天内，商品维度的⿊卡会员购买⽤户数和 30 天内商品维度的⾮会员购买⽤户数就作为两个派⽣指标存在，但是他们继承⾃同⼀个原⼦指标。
除此之外，还需要指标命名规范。指标命名规范要遵循两个基本的原则：易懂，就是看到指标的名称，就可以基本判断这个指标归属于哪个业务过程；统⼀，就是要确保派⽣指标和它继承的原⼦指标命名是⼀致的。除此之外，指标应该有指标名称和指标标识（或者叫英⽂名）。
对于原⼦指标，指标名称适合⽤“动作 + 度量”的命名⽅式（⽐如注册⽤户数、购买⽤户数），标识的命名⽤英⽂简写或者汉语拼⾳缩写⽐较好。对于派⽣指标，指标名称应该严格遵循“时间周期 + 统计粒度 + 修饰词 + 原⼦指标”的命名⽅式，标识命名要⽤“修饰词 _ 原⼦指标 _ 时间周期”的⽅式。
第四，关联的应⽤和可分析维度。对于使⽤指标的⼈（运营、分析师）了解了这个指标的⼝径定义之后，下⼀步就是要看指标的数值。所以，在全局的指标字典中，还应该有指标被哪些应⽤使⽤，这样⽅便去对应的数据产品或者报表上查看指标的数值。除此之外，还应该有指标的可分析维度，⽅便分析师从不同的维度分析指标的变化趋势。
最后⼀个是分等级管理。那这么多指标，数据中台管的过来么？是的，确实管不过来，因为不仅仅是数据中台会产出⼀些公共核⼼指标，业务部门也会创建⼀些专属业务部门内的指标。那⾯对这么多指标，如何管理呢？以我的经验，你可以按照以下原则区分等级，来管理指标。⼀级指标：数据中台直接产出，核⼼指标（提供给公司⾼层看的）、原⼦指标以及跨部门的派⽣指标。⼆级指标：基于中台提供的原⼦指标，业务部门创建的派⽣指标。不同等级的指标意味着管理⽅式不同：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。