数据仓库元数据管理系统

数据仓库元数据管理系统作者：罗小洪来源：《神州·中旬刊》2019年第06期摘要：本文首先对元数据的基本概念和作用进行了介绍，然后对元数据系统的软件架构进行了设计，并对用到的关键技术进行了说明，用到的关键技术包括：“血缘关系”，元数据抽取、转换、加载以及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.软件架构设计元数据系统采用B/S（浏览器/服务器）架构，访问者可以通过浏览器访问web页面，通过页面操作与服务器交互，前端技术基于freemaker的图形渲染框架。

基于jQuery框架的javascript与服务端进行交互，服务端采用springboot与mybatis框架，以提高开发效率，用mysql存儲hive元数据信息。

·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类中获得解决方案。

针对部分类型sql设置HiveConf，比如“开启动态分区非严格模式”。

对于CTAS类型，需要设置Context。

通过对EDW系统的HIVE SQL任务解析，获取到任务与表的关系。

通常一个任务可以解析出上游若干张表，这些表是任务的来源表，一个任务同样会产生若干张表，这些就是任务的目标表，从而形成一个血缘关系，会发现一个表的来源可能会有多个任务，以此类推，可以得到一个错综复杂的血缘关系，通过存储过程的计算，再加上前端框架的渲染，可以得到一个血缘关系图。

2.3 元数据抽取、转换、加载在数据仓库中抽取（extract）、转换（transform）、加载（load）这一系列的流程简称为ETL。

元数据信息由调度中的任务脚本的不断执行而不断产生，这一过程中，为了方便第一时间查看到新产生的元数据信息，采用以阿里巴巴开源项目canal进行实时数据同步。

其原理是：canal自身伪装为mysql Master的一个slave从库。

Slave 上面的IO线程连接上 Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容;Slave 上面的IO线程连接上 Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容;Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO 线程，根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。

返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary Log 中的位置;Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的Relay Log文件（mysql-relay-bin.xxxxxx）的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master所需要的bin-log位置;Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容，成为在 Master 端真实执行时候的那些可执行的 Query 语句，并在自身执行这些 Query。

这样，实际上就是在 Master 端和 Slave 端执行了同样的 Query，所以两端的数据是完全一样的。

本系统独立开发出canal客户端，可对bin-log日志定制化解析，过滤掉查询产生的日志，因为查询日志对元数据的更新没有意义，只针对增删改的元数据进行解析，解析出的数据以json格式保存并向指定的kafka topic发送，通过对元数据信息的实时跟踪、实时解析计算，实时的向kafka发送，再通过flink stream sql实时流处理框架将数据load至元数据系统的数据库中，至此，完成了元数据信息的抽取、转换、加载。

2.4 系统设计在2.3中讲解了后端数据的加载处理方式，但是如何将数据界面化展示也是本系统难点之一，本系统实现了数据字典查询、表对象查询。

顾名思义，数据字典，就是描述每一个字段的信息，它在哪张表中，含义是什么，当前是否有效，数据属于哪个业务模块、是否分区字段等等信息，通过对hive元数据表COLUMN表的数据解析即可获得这些信息。

而表对象信息存储了血缘关系、表中的字段信息、DDL语句、产生该表的任务脚本信息、开发负责人、已经更新时间等等信息。

同时，为了保证数据的安全性，还需要通过数据权限验证，这样可以使得查询人员只能看到自己有权限看到的schema信息，而不能大而全的看到整个数据仓库的信息。

用户通过web页面查询到的这些信息，可以很轻松的获取想要的数据，大大地提高了开发的效率。

3.结语元数据信息治理是一个涉及多个系统及技术方案的闭环系统，它需要依赖任务调度系统、离线计算、实时计算等多个环节，数据展示使用到了经典的spring框架及mybatis框架，以及前端的bootstrap、jQuery、freemaker。

对于数据治理，apache官方有一个altas的开源管理方案，本系统参考了该技术实现的部分思想，完成了一个可定制化的数据仓库元数据管理系统。

参考文献：[1]曹昊嘉，李冰.元数据管理系统设计及其关键技术[J].信息技术与标准化，2016（10）.[2]孫安健.通用ETL工具的研究与设[D].复旦大学，2012。