上文从宏观系统性了解数据中台建设的方法论、支撑技术和组织架构。
本文开始进入实现篇，微观带你具体分析数据中台的支撑技术，以电商场景为例，分别讲解元数据中心、指标管理、模型设计、数据质量等技术如何在企业落地。
数据中台的构建，要确保全局指标的业务口径一致，要梳理原口径不一致、重复指标，整合成一个统一的指标字典。这工作前提，是搞清这些指标的业务口径、数据来源和计算逻辑。这些数据都是元数据。
如无这些元数据，就没法梳理指标，更谈不上构建一个统一指标体系。当你看到一个数700W，如你不知这数对应指标是日活，就无法理解这数据的业务含义，也就无法整合这些数据。所以你要掌握元数据的管理，才能构建数据中台。
那么问题来了：元数据中心应该包括哪些元数据呢？ 什么样的数据是元数据？
元数据划为三类：数据字典、数据血缘和数据特征。
2.1 数据字典
dwd_trd_order_df 是一张订单交易明细数据，任务flow_dws_trd_sku_1d 读取这张表，按照sku粒度，计算每日sku的交易金额和订单数量，输出轻度汇总表dws_trd_sku_1d。
数据字典描述的是数据的结构信息，我们以dws_trd_sku_1d为例，数据字典包括：
2.2 数据血缘
一个表是直接通过哪些表加工而来，上例，dws_trd_sku_1d通过dwd_trd_order_df的数据计算而来，所以，dwd_trd_order_df是dws_trd_sku_1d的上游表。
数据血缘帮我们做影响分析和故障溯源。如有天，老板看到某指标数据违反常识，让你排查这指标计算是否正确，你先要找到这指标所在表，然后顺这表上游表逐个排查校验数据，才能找到异常数据根源。
2.3 数据特征
主要指数据的属性信息，以dws_trd_sku_1d为例：
元数据种类很多，为管理这些元数据，须构建元数据中心。
来看如何搭建一个元数据中心，打通企业的元数据。
学习业界优秀产品：
- Netflix的metacat、Apache Atlas
- 商业化产品Cloudera Navigator
来看metacat和Atlas这两款产品：
- 一个擅长管理数据字典
- 一个擅长管理数据血缘
了解这两款产品，更能深入理解元数据中心的设计。
3.1 metacat 多数据源集成型架构设计
metacat，多数据源的可扩展架构设计，对数据字典管理很重要。
一般公司中，数据源类型非常多，如Hive、MySQL、Oracle、Greenplum。支持不同数据源，建立一个可扩展的、统一的元数据层很重要的，否则你的元数据是缺失的。
metacat设计巧妙，没单独再存一份元数据，而是采取直连数据源拉的方式：
- 它不存在保存两份元数据一致性的问题
- 这种架构设计很轻量化，每个数据源只要实现一个连接实现类，扩展成本低
我称为集成型设计。对希望构建元数据中心的企业很有借鉴意义。
3.2 Apache Atlas 实时数据血缘采集
Apache Atlas，实时数据血缘采集的架构设计，它为解决血缘采集的准确性、时效性难题提供很多解决思路。
3.2.1 血缘采集方式
-
静态解析SQL，获得输入表和输出表
面临准确性的问题，因为任务没有执行，这个SQL对不对都是一个问题
-
实时抓取正在执行的SQL，解析执行计划
比较理想的实现方式，而Atlas 就是这种实现。
-
任务日志解析的方式，获取执行后的SQL
血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析大量的任务日志数据。
对于Hive 计算引擎，Atlas 通过Hook方式，实时地捕捉任务执行计划，获取输入表和输出表，推送给Kafka，由一个Ingest 模块负责将血缘写入JanusGraph图数据库中。然后通过API的方式，基于图查询引擎，获取血缘关系。对于Spark，Atlas 提供了Listener的实现方式，此外Sqoop、Flink 也有对应的实现方式。
这两款产品在设计网易元数据中心时，给了很多灵感，下面我就带你了解一下网易元数据中心的设计，以便你掌握一个元数据中心在设计时应该考虑哪些点。
4.1 元数据中须实现的关键目标：
① 多业务线、多租户支持
在网易，电商、音乐都是不同的业务线，同一个业务线内，也分为算法、数仓、风控等多个租户，所以元数据中心必须支持多业务线、多租户。
② 多数据源的支持
元数据中心必须要能够支持不同类型的数据源（比如MySQL、Hive、Kudu等），同时还要支持相同数据源的多个集群。为了规范化管理，还需要考虑将半结构化的KV也纳入元数据中心的管理（比如Kafka、Redis、Hbase等）。这些系统本身并没有表结构元数据，所以需要能够在元数据中心里定义Kafka每个Topic的每条记录JSON中的格式，每个字段代表什么含义。
③ 数据血缘
元数据中心需要支持数据血缘的实时采集和高性能的查询。同时，还必须支持字段级别的血缘。
什么是字段级别的血缘，我们来举个例子。
insert overwrite table t2 select classid, count(userid) from t1 group by 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可基于这标签，对拥有某个标签的一组表按相同权限授权。
这大幅提高权限管理效率。如对会员、交易、毛利、成本，可设定表的敏感等级，根据敏感等级，设定不同人的查看权限。
元数据中心作为基础元数据服务，包括自助取数分析系统，数据传输系统，数据服务，都应基于元数据中心提供的统一接口来获取元数据。
⑤ 数据标签
对表和表中的字段打标签，通过丰富的不同类型的标签，可完善数据中台数据的特征，如指标可作为一种类型的标签打在表上，主题域、分层信息都可作为不同类型的标签关联到表。
基于这几大因素设计的元数据中心：
这图按功能模块分为：
4.2 数据血缘
由采集端、MQ、消费端及血缘清理模块组成，基于Hive Hook，Spark Listener，Flink Hook ，可获取任务执行时输入表和输出表，推送给统一MQ（Kafka），然后消费端将血缘关系沉淀到图数据库。
图数据库选Neo4j，主要考虑性能快、部署轻量化、依赖模块少，开源Neo4j无高可用方案且不支持水平扩展，但因单业务活跃的表规模基本也就在几万，单机够用，高可用可双写来实现。
血缘还有个清理的模块，负责定时清理过期的血缘，一般把血缘的生命周期置7天。
4.3 数据字典
参考metacat实现，由统一的Connector Mananger负责管理到各数据源的连接：
- 对Hive、MySQL，元数据中心不会保存系统元数据，而是直接连数据源实时获取
- 对Kafka、Hbase、Redis等KV，在元数据中心里内置一个元数据管理模块，可在这模块中定义Value的schema信息
4.4 数据特征
主要是：
- 标签的管理
- 数据的访问热度信息
元数据中心内置不同类型的标签，同时允许用户自定义扩展标签类型。指标、分层信息、主题域信息都以标签形式存储在元数据中心的系统库，同时元数据中心允许用户基于标签类型和标签搜索表和字段。
元数据中心统一对外提供了API访问接口，数据传输、数据地图、数据服务等其他子系统都能通过API接口获取元数据。Ranger可基于元数据中心提供的API接口，获取标签对应的表，再根据标签更新表对应的权限，实现基于标签的权限控制。
元数据中心没有UI吗？用户咋用这元数据中心？
数据地图，基于元数据中心构建的一站式企业数据资产目录，可看作元数据中心的界面。
数据开发、分析师、数据运营、算法工程师可在数据地图完成数据检索，解决很多难题：
- 不知道有啥数据
- 到哪找数据
- 如何准确理解数据
数据地图提供多维度检索功能，使用者可按表名、列名、注释、主题域、分层、指标检索，结果按匹配相关度排序。考虑数据中台有一些表是数仓维护的表，有一些表数仓已不再维护，在结果排序时，增加了数仓维护的表优先展示的规则。数据地图还提供按主题域、业务过程导览，可帮助使用者快速了解当前哪些表可用。
当使用者定位到某个表打开时，会进入详情页，详情页中会展示表的基础信息，字段信息、分区信息、产出信息以及数据血缘。数据血缘可帮助使用者了解该表的来源和去向，这表可能影响的下游应用和报表，这个表的数据来源。
数据地图同时提供数据预览功能，考虑安全，只允许预览10条数据，用于判断数据是否符合使用者的预期。数据地图提供的收藏功能， 方便使用者快速找到自己经常使用的表。当数据开发、分析师、数据运营找到自己需要的表时，在数据地图上可以直接发起申请对该表的权限申请。
数据地图对于提高数据发现的效率，实现非技术人员自助取数有重要作用。经过我的实践，数据地图是数据中台中使用频率最高的一个工具产品，在网易，每天都有500以上人在使用数据地图查找数据。
本文以元数据作为起点，学习到：
- 元数据包括数据字典、数据血缘和数据特征
- 然后通过分析两个业界比较有影响力的元数据中心产品
- 结合国内的数据中台实践，给出元数据中心设计的关键特性和技术实现架构
- 最后介绍基于元数据中心之上的数据地图产品
最后强调：
- 元数据中心设计须注意扩展性，能支持多数据源，宜采用集成型设计
- 数据血缘需支持字段级血缘，否则影响溯源范围和准确性
- 数据地图提供一站式数据发现服务，解决检索数据，理解数据的“找数据的需求”
元数据中心是数据中台的基石，它提供了我们做数据治理的必须的数据支撑，在后续的章节中，我们将逐一介绍指标、模型、质量、成本、安全等的治理，都离不开元数据中心。
血缘采集的三种方式，并推荐了通过实时采集，但其实静态解析血缘也有优势应用场景，你能想到有啥？
静态解析血缘通常用于分析和理解已有的代码或数据流程，可以帮助开发人员更好地理解代码的结构和依赖关系，从而更好地维护和更新代码。