文本描述
下载APP 04 | 元数据中心的关键目标和技术实现方案 2020-04-10 郭忆 数据中台实战课 进入课程 讲述：郭忆 时长 20:02大小 18.35M 你好，我是郭忆。 在上一节课程中，我从宏观的角度，系统性地带你了解了数据中台建设的方法论、支撑技术 和组织架构，从这节课开始，我们正式进入实现篇，我会从微观的角度出发，带你具体分析 数据中台的支撑技术，以电商场景为例，分别讲解元数据中心、指标管理、模型设计、数据 质量等技术如何在企业落地。 这节课，咱们来聊聊元数据。 为什么要先讲元数据呢？我来举个例子。在原理篇中，我提到数据中台的构建，需要确保全 局指标的业务口径一致，要把原先口径不一致的、重复的指标进行梳理，整合成一个统一的 指标字典。而这项工作的前提，是要搞清楚这些指标的业务口径、数据来源和计算逻辑。而 这些数据呢都是元数据。 你可以认为，如果没有这些元数据，就没法去梳理指标，更谈不上构建一个统一的指标体 系。当你看到一个数 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，解析执行计划，获取输入表和输出表； 通过任务日志
==>> 点击下载文档
