数据仓库元数据管理系统

罗小洪

摘要：本文首先对元数据的基本概念和作用进行了介绍，然后对元数据系统的软件架构进行了设计，并对用到的关键技术进行了说明，用到的关键技术包括：“血缘关系”，元数据抽取、转换、加载以及SQL数据的埋点、采集等。实现了将数据界面化展示，可完成数据字典查询、表对象查询等，使用户可以很轻松的获取想要的数据，大大地提高了开发的效率。

关键词：元数据;元数据系统;数据仓库hive;大数据

ABSTRACT：Abstract：This paper first introduces the basic concepts and functions of metadata， and then designs the software architecture of the metadata system， and introduces  key technologies such as“blood relationship”， metadata extraction， metadata conversion， metadata loading， as well as the burying and collecting of SQL data， the article also realizes the interface display of data， it can complete data dictionary query， table object query， etc.， so that users can easily obtain the desired data， greatly improving the developments efficiency.

Keywords：metadata，Metadata System，data warehouse hive，big data

引言

元数据是描述数据的数据，在数据仓库的建设中，是不可忽略的一环。其作用在于对数据的治理、提高数据使用效率和数据管理效率，到达数据利用的准确及高效[1]。由于数据的海量性，数据的管理需要借助一个可视化的界面供开发人员的使用，为此需要建立一个可视化的元数据原理系统来帮助使用者开发、维护、使用、管理元数据。

元数据打通了数据源、数据仓库、数据应用，记录了数据从产生到消费的完整链路。元数据包含：静态的表、列、分区信息（也就是MetaStore）;动态的任务、表依赖映射关系;数据仓库的模型定义、数据生命周期;以及ETL任务调度信息、输入输出等

元数据是数据管理、数据内容、数据应用的基础。例如可以利用元数据：构建任务、表、列、用户之间的数据图谱;构建任务DAG依赖关系，编排任务执行序列;构建任务画像，进行任务质量治理;数据分析时，使用数据图谱进行字典检索;根据表名查看表详情，以及每张表的来源、去向，每个字段的加工逻辑;提供个人或BU的资产管理、计算资源消耗概览等。

在业务量并不是很大的时候，对应的开发者对业务较为熟悉，查看元数据信息都是通过访问元数据库进行查询，但当并非专业人士，如数据分析师需要查看元数据信息时，就困难重重，尤其是当业务数据不断扩张时，即便是专业的开发者想要随时拿到想要的数据也并不容易，所以元数据系统应运而生。

1.软件架构设计

·DB保存任务的sql数据、任务基础信息、执行引擎上下文信息

·Extract循环抽取sql并解析成表、列级血缘Lineage

·DataSet包含Lineage关系数据+任务信息+引擎上下文

·将DataSet数据集保存到Neo4j，并提供关系查询;保存ES，提供表、字段等信息检索

2.关键技术

2.1血缘关系

“表”是元数据系统的后台逻辑核心，数据仓库是构建在Hive之上的，而Hive元数据来自于生产系统，也可能会把计算的结果导出到外部存储。Hive表、mysql表、hbase表、BI报表都是“表”，这些“表”间关系是一个DAG，也就是血缘关系。

2.2 SQL埋点、采集

sql数据，以执行中采集为主+保存前submit为辅。因为任务的sql可能包含一些时间变量，比如dt、hour，以及任务可能是天调度、小时调度。执行中采集sql实时性更高，也更容易处理EDW是任务调度系统，类比开源的AirFlow，调度系统执行任务，并将任务相关的信息比如appId、jobId、owner、sql等信息存入DB。

计算引擎实现相关的监听接口，比如Hive实现Execute WithHookContext接口;Spark实现SparkListener接口;Presto实现EventListener接口。将计算引擎相关的上下文Context、元数据MetaData、统计Statistics等信息存入DB。

解析sql的方案，以hive为例。先定义词法规则和语法规则文件，然后使用Antlr实现sql的词法和语法解析，生成AST语法树，遍历AST语法树完成后续操作。

但对于SELECT*、CTAS等操作，直接遍历AST，不去获取Schema信息来检查表名、列名，就无法判定sql的正确性，从而导致数据污染。

综上所述，本系统的SQL解析方案，直接参考Hive的底层源码实现。经过SemanticAnalyzerFactory类进行语法分析，再根据Schema生成执行计划QueryPlan。关于表、列的血缘，可以从LineageInfo、LineageLogger类中获得解决方案。