元数据系统的产品形态

上一篇 给初心者的数据仓库元数据系统开发指南 主要是描述了元数据的基本概念和典型需求。实际的开发和使用中，还有个基本问题容易被混淆，关于元数据的产品形态。

元数据门户

这是最直观的产品形态，可以让数据的开发者有个地方，可以集中查看数据仓库的基本信息，比如表结构、注释。这是个生产力工具，可以提升数据开发者的生产效率。多从数据开发者的使用角度思考，让他们用的爽，元数据门户的用户数自然而然就会提升。

这个门户可以是独立的域名和页面，也可以嵌入到开发环境里。比如著名的开源开发平台hue，就可以查看Hive表的基本信息，当然系统自带的功能比较弱，不足以提升生产效率。

开发的策略有两种

• 基于需求：作为数据仓库管理者，被用户吐槽或咨询最多的，就优先通过元数据的系统能力解决。
• 主动设计：数据开发者很难有全局和长远的视角，他们并不知道元数据可能的更大价值，可以主动设计元数据门户的功能，然后按照自己的节奏去开发。

快速找到想要的信息

为了更高效展示，元数据门户需要面向不同的用户，给出不同的检索方案

• 搜索：根据表名、字段名、注释、责任人，匹配到相应的数据仓库表。可以参考主流搜索引擎的高级搜索，提供更多维度的筛选，比如按业务域、大小、更新时间等筛选，以及更清晰的关键信息展示。
• 导航：搜索面向的是熟练开发者，他们知道自己要搜什么。对于小白用户，更好的寻找信息方式是导航，类似于hao123这样的网址导航。把数据仓库的信息归类展示，比如按多级的主题域，优先展示最常用的表。

血缘关系是另一种可以帮助用户找到信息的工具

• 表级血缘：实践证明，即便是熟练的开发者，也只能记住少量关键表，通过关键表的血缘关系，可以很快找到关联的其他表。
• 字段级血缘：可以更细粒度跟踪某个字段的上下游关系，比如修改一个字段，要观察影响到的下游任务。

上面都是从表的角度描述，另一种更贴近小白用户的是指标角度的描述。一个典型场景，产品经理想做用户画像，可能会拍脑袋决定需要用若干统计指标来衡量用户的购物偏好。如果有这么一个指标的导航系统，可以快速勾选数据仓库已经存在的指标，这个拍脑袋的过程就会很愉快。

元数据驱动数据仓库开发

怎么提升数据仓库管理员对系统的掌控力呢？把数据仓库规范落地到元数据里可以做到。部分能力与开发平台、调度系统的边界已经很模糊，要根据实际情况来决定在哪边实现，或者干脆只是一个系统。

• 开发时：命名规范、SQL规范、鉴权，这些能避免数据仓库被滥用。
• 运行时：数据质量校验，问题严重时需停止调度并告警；数据倾斜、异常任务检测等。运行时主要是能第一时间发现异常任务，并帮助及时解决。
• 运行后：通过数据质量事件，生成数据质量报告；通过运行时信息采集，生成性能消耗分析报表；通过血缘关系，做到数据质量事件的影响分析；通过审计，得到数据平台的使用情况报表。能做的事情还有很多。

这里的产品形态可以有两种

• 面向开发者的，需要与开发平台、调度系统结合，比如SQL规范的校验与错误提示。元数据系统作为强业务逻辑的子系统，可以实现大部分数据仓库的规范，并提供一系列接口给其他子系统使用，比如数据同步、调度、IDE、BI系统。
• 面向数据仓库管理者的，比如一系列分析报表，很可能是基于元数据的二次统计分析。

有的公司会把某个管理功能独立出子系统，比如数据质量，可能会有准确性校验的子系统，也可能有数据生成及时性的监控子系统。

系统背后的数据采集

要实现上述功能，首先是有这些元数据，需要从数据仓库里采集。可以有这么几种办法

• 通过脚本采集
• 后端服务提供接口，由外部调度系统触发采集
• 后端服务内部定时触发采集

建议尽量把采集功能在后端服务实现。脚本采集开发起来很快，但是维护较困难，一旦功能修改，服务端的采集和展示功能在一起，很容易保证一致性，而外部脚本修改会更困难。

小结

元数据系统的产品概况来说有这么几类

• 数据开发者可见
  • 元数据门户，提升开发者生产效率
  • 把数据仓库规范嵌入到开发平台，甚至作为独立子系统，保证数据开发可控
• 管理员可见：根据元数据，得到数据仓库的各种报表