下载掌阅APP，畅读海量书库
立即打开
因为元数据中心是数据中台的基础设施，其他系统都需要以它为基础搭建，所以它需要能够支持不同的结构化数据源，如MySQL、Hive、Oracle等，还需要能够支持半结构化的数据源，如Kafka、Redis、HBase等，并且要考虑不同数据源的不同集群。
通过配置定时采集器的方式，对数据进行采集，如图2-2所示。
图2-2
采集器有以下两种采集计划。
（1）场景采集：根据实际的业务场景，在业务需要时才进行采集。
（2）周期采集：按照时间周期，如月采集，在每月的特定时间进行采集，还有周采集、天采集、时采集等。周期采集设置如图2-3所示。
图2-3
数据管理就是管理数据中台所有的元数据，元数据即描述数据的数据。这个概念其实不难理解，我们举一个电影的例子来说明：要判断一部电影是否热门，我们可以用一些指标来描述它，如购票人数、退票人数、上座率、排片率等。这些都是描述电影本身的数据。但除了这些数据，还有另外一些数据，如统计周期、产出时间、计算逻辑等，这些数据不是描述电影的，而是描述购票人数这个指标的，所以它们是关于电影的数据的数据，即电影的元数据。
在数据中台中，元数据的类型有很多，如以下几类。
（1）数据表的名称、关系、字段、约束、存储位置等。
（2）数据表与字段之间的流程依赖关系。
（3）事实逻辑表、维度表、属性、层次的描述信息等。
（4）指标的生成逻辑、数据流向，物理表与逻辑表之间的映射关系等。
（5）调度系统的相关调度配置、调度周期等。
（6）哪些表何时被人访问、何时被稽查、何时被人调用、调用情况等。
针对不同类型的元数据，我们可以把它们组织起来分为3组：数据属性、数据字典、数据血缘。下面用一个实际的例子来详细说明这3组元数据的来源、内容与实现方式。
如图2-4所示，这是一个订单数据的开发流程，订单交易明细表（dwd_goods_order_df）通过一个任务（task_dws_goods_sku_1d），按照SKU（库存量单位）的粒度，计算每日SKU的交易金额和订单数量，最终输出到SKU每日汇总表（dws_goods_sku_1d）中。
图2-4
数据属性主要是关于数据本身的描述，就好比我们描述用户，我们会用年龄、性别、身高等属性来描述用户，这些属性可以勾勒出用户的基础印象。我们也可以用一些基础的数据来描述数据属性。这些数据有几种类型：基础信息、标签信息、业务信息、技术信息、权限信息。
以图2-4中的SKU每日汇总表（dws_goods_sku_1d）为例。
基础信息如图2-5所示。
图2-5
标签信息如图2-6所示。
图2-6
标签的维护是靠基于元数据中心的各个数据中台支撑产品下沉到元数据中心上的。例如，指标系统创建了一个指标，在模型设计中，我们会为某个表的某个字段关联一个指标，之后指标和表就产生了关联关系，关联关系就会下沉到元数据中心，以标签的形式存在。
技术信息如图2-7所示。
图2-7
权限信息与业务信息整合在一起，如下。
项目：dataplatform_dev。
数仓层级：dwd。
主题域：交易域。
权限状态：无权限。
数据字典与数据属性有些相似，但是它主要描述数据的结构信息。其主要的数据来源是数仓模型中心的数据表的相关配置、调度系统等，如图2-8所示。
图2-8
对数据属性与数据字典的内容进行组织后，其展示效果如图2-9所示。
图2-9
数据血缘主要描述表与表之间的关系。其主要的数据来源是数仓模型中心的调度依赖配置、数据指标中心的指标生产逻辑、数据服务中心的逻辑表配置信息等。
数据血缘是元数据建设中最重要的一个模块，对于后续的数据问题排查与数据资产评估都具有非常大的作用。数据血缘的作用主要体现在如下几个方面。
1）问题定位排查
在实际的业务场景中，我们如果发现某个数据应用或程序出现故障，就可以通过数据血缘进行排查，以快速定位相关故障节点。
2）指标波动分析
当某个指标出现误差或者出现不正常的波动时，我们可以通过数据血缘进行溯源分析，判断是哪条数据开发链路出现了问题。
3）数据预警与产出保障
对数据加工链条的所有节点进行监控，对下游任务的产出时间进行预测，一旦发现下游任务无法按时产出，就及时报警。并且当某些节点出现问题时，我们需要确保高资产等级的整条数据链路能够有较高的优先级，优先调度并占用数据资源，确保高资产等级的数据能够被准时、准确地产出。
在明确数据产品的价值之后，我们可以通过数据血缘反溯数据加工链路，判断数据的重要性，并且从调用频率、数据热度等不同的维度对数据进行评估，从而判断数据的价值，进行资产定级。
通过血缘关系的调度依赖分析，我们可以获得数据的整体情况，如集中度、冗余度、计算成本、存储成本等，从各个方面对数据进行衡量，以便能持续对数据进行优化。
关于血缘关系的实现方式，业内已经有一些成熟的框架，如Druid，内部已经实现了大部分的解析功能，但是它的缺点是只能解析SQL，无法兼容Spark SQL、Hive SQL等其他模块的语法，所以会导致解析不完全。更好的解决方法是，通过Spark/Hive/Flink本身提供的Listener/Hook机制，解析调度依赖中的FROM、CREATE、INSERT等语句，获取输入节点与输出节点，生成血缘关系，就可以解析除SQL之外的其他语法。
在明确了实现方式后，就要考虑计划执行时机了。执行时机主要有3个。
（1）在运行前通过解析静态的SQL，获取依赖的输入节点与输出节点。
（2）在运行中实时截取动态的SQL，获取依赖的输入节点与输出节点。
（3）在运行后通过解析任务日志，获取依赖的输入节点与输出节点。
在这3个时机中，时机（1）因为没有执行代码，所以无法保证可以正常运行，时机（3）则比较后置，没有时效性，所以最合适的是时机（2），在运行中解析SQL，能够实时获取输入与输出表，并且当依赖关系改变时也能实时变更。但是时机（2）也有一个缺点，那就是当数据表开发完成但还没有被执行时，就无法获取血缘关系，这时就需要通过解析静态SQL的方式，建立跟其他表的依赖关系。最终存储效果如图2-10所示。
图2-10
（注：这里是为了直观展示而采用了关系型数据的形式，实际应该用图形数据库存储。）
因此，对于数据血缘的实现，可以简要概述为：首先，通过Spark Listener/Hive Hook/Flink Hook，解析调度依赖中的FROM、CREATE、INSERT等语句获取输入节点与输出节点，生成血缘关系并推送给消息中间件（Kafka）；其次，消费端负责将血缘关系沉淀到图形数据库（Neo4j）中；最后，通过图计算引擎在前端以图形的方式将其展示出来。最终展示效果如图2-11所示。
图2-11
另外，还需要补充一点，在生产过程中会生成很多临时表，这些表是不能被写入血缘关系的。因此，我们需要对这些表执行一个规则，如以t_开头，在后续执行解析任务时，一旦遇到这些表，系统就会自动优化这些表，避免弄脏血缘关系。
数据地图是基于所有元数据搭建起来的数据资产列表，如图2-12所示。我们可以将数据地图看作将所有元数据进行可视化呈现的系统。它不仅能够解决有什么数据的问题，还能够进行检索，解决数据在哪里的问题。
图2-12
数据地图提供了多维度的检索功能，使用者可以按照表名、列名、注释、主题域、分层、指标进行检索，结果按照匹配相关度进行排序。考虑到数据中台中有一些表是数仓维护的表，有一些表数仓已经不再维护，因此在结果排序时，我们增加了数仓维护的表优先展示的规则。数据地图还提供了按照主题域、业务过程导览功能，可以帮助使用者快速了解当前有哪些表可以使用。
当使用者定位到某个表被打开时，会进入详情页，详情页中会展示表的基础信息：字段信息、变更记录、产出信息、分区信息及数据血缘，如图2-13所示。数据血缘可以帮助使用者了解这个表的来源和去向、这个表可能影响的下游应用和报表、这个表的数据来源。
图2-13
元数据中心是数据中台最基础的系统，是所有数据中台系统的基石，后续的数仓开发、指标开发、数据治理、成本治理等都需要元数据中心的支持。