元数据系统的产品形态

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

元数据门户

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

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

开发的策略有两种

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

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

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

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

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

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

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

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

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

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

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

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