蘑菇街元数据管理系统实践

因为数据仓库分层，而且数据表和字段众多，计算逻辑复杂，通过人的记忆难以管理规范。就需要通过一个系统来管理，用什么系统的话，可以购买第三方的，也可以自己公司开发。如果自己公司开发，首先你的使用过。数据管理平台为用户提供高质量、准确、易于管理的数据，它贯穿数据中心构建、运行和维护的整个生命周期。同时，在数据中心构建的整个过程中，数据源分析、ETL过程、数据库结构、数据模型、业务应用主题的组织和前端展示等环节，均需要通过相应的元数据的进行支撑。元数据管理的生命周期包括元数据获取和建立、元数据的存储、元数据浏览、元数据分析、元数据维护等部分。
通过元数据管理，形成整个系统信息数据资的准确视图，通过元数据的统一视图，缩短数据清理周期、提高数据质量以便能系统性地管理数据中心项目中来自各业务系统的海量数据，梳理业务元数据之间的关系，建立信息数据标准完善对这些数据的解释、定义，形成企业范围内一致、统一的数据定义，并可以对这些数据来源、运作情况、变迁等进行跟踪分析。完善数据中心的基础设施，通过精确把握经营数据来精确把握瞬息万变的市场竞争形式，使企业在市场竞争中保持优势。

蘑菇街大数据平台的元数据管理系统，大体的体系架构思想和上述系统也比较类似，不过，客观的说我们的系统的开发是一个伴随着整体开发平台的需求演进而渐进拓展的过程，所以从数据管理的角度来说，没有上述两个系统那么关注数据格式类型系统的普遍适用性。比如Schema这部分信息的管理，就主要侧重于表格类信息的管理，比如Hive，HBase等，而非完全通用的类型系统。但相对的，在对外服务方面，我们也会更加注重元数据管理系统和业务系统应用需求的关联，架构大同小异，下面主要简单介绍一下产品交互形态和一些特殊的功能特效设定等。

如图所示，是我们的元数据管理系统的产品后台针对Hive表格元数据信息的部分查询界面，主要为用户提供表格的各种基础schema信息，业务标签信息，血缘关系信息，样本数据，以及底层存储容量星系，权限和读写修改记录等审计信息。

除了表格元数据信息管理以外，我们的元数据管理系统主要的功能之一是“业务组”的管理，业务组的设计目标是贯穿整个大数据开发平台的，做为大数据开发平台上开发人员的自主管理单元组织形式。将所有的数据和任务的管理工作都下放到业务组内部由业务组管理员管理。

从元数据管理系统的角度来说，业务组的管理，包括数据和任务与业务组的归属关系映射，业务组内角色的权限映射关系等，此外，为了适应业务的快速变化，也给用户提供的数据资产的归属关系转移等功能。

总体来说，业务组的管理功能，更多的是需要和大数据开发平台的其它组件相结合，比如和集成开发平台IDE相结合，在开发平台中提供基于业务组的多租户开发环境管理功能，再比如与调度系统相结合，根据任务和数据的业务组归属信息，在任务调度时实施计算资源的配额管理等。

最后，关于数据的血缘关系跟踪，再多说两句。在Atlas和navigator中，主要通过计算框架自身支持的运行时hook来获得数据相关元数据和血缘相关信息，比如hive的hook是在语法解析阶段，storm的hook是在topology  submit阶段。

这么做的优点是血缘的追踪分析是基于真实运行任务的信息进行分析的，如果插件部署全面，也不太会有遗漏问题，但是这种方式也有很多不太好解决的问题，比如

• 如何更新一个历史上有依赖后来不再依赖的血缘关系

• 对于一个还未运行的任务，不能提前获取血缘信息

• 临时脚本或者错误的脚本逻辑对血缘关系数据的污染

  
  

简单总结一下，就是基于运行时的信息来采集血缘关系，由于缺乏静态的业务信息辅助，如何甄别和更新血缘关系的生命周期和有效性会是一个棘手的问题，一定程度上也限制了应用的范围。

我们的做法是，血缘信息的采集不是在运行时动进行的，而是在脚本保存时进行的。由于开发平台统一管理了所有用户的任务脚本，所以，我们可以对脚本进行静态的分析，加上脚本本身业务信息，执行情况和生命周期对开发平台是可知的。所以一定程度上能解决上述提到的几个问题。

当然，这种方案也有自己的短板需要克服，比如：如果脚本管控不到位，血缘关系分析可能覆盖不全；血缘关系是基于最新的脚本的静态的逻辑关系，无法做到基于某一次真实的运行实例进行分析。不过，这些短板对我们来说从需求的角度来说都不是很核心的问题，又或者通过周边系统的配套建设可以在一定程度上加以解决克服的。