移动省级NG2-BASS3.0_技术规范_元数据管理.doc

qb-j-xxx-xxxx 中国移动通信企业标准qb-j-xxx-xxxx中国移动省级ng2-bass技术规范元数据管理分册（征求意见稿）the metadata management fascicule of new generation business analysis support system版本号：3.0.02010-xx-xx实施2010-xx-xx发布中国移动通信有限公司 发布目录1.范围12.规范性引用文件13.术语、定义和缩略语14.经营分析系统元数据概述34.1.经营分析系统元数据的概念34.2.经营分析系统的元数据管理34.2.1.元数据管理的目标34.2.2.元数据管理的范畴44.3.经营分析系统元模型54.3.1.经营分析系统元模型概述54.3.2.cwm概述64.3.3.经营分析系统元模型与cwm的关系94.3.4.经营分析系统核心元模型概述95.元数据管理体系结构105.1.功能结构105.2.技术结构126.元数据管理功能要求136.1.元数据获取136.1.1.元数据获取方式136.1.2.元数据自动获取管理功能156.2.sql脚本自动解析166.2.1.运行日志的输出要求186.2.2.sql词法语法分析266.2.3.sql语义分析与元数据生成276.2.4.元数据入库处理476.2.5.sql脚本上下文处理486.2.6.多路径问题和信息丢失问题的处理536.3.tcl脚本自动解析536.4.元数据存储556.4.1.元数据存储内容556.4.2.元数据存储方式626.5.元数据基本功能636.5.1.元数据维护636.5.2.元数据变更管理636.5.3.元数据查询636.5.4.元数据统计646.5.5.元数据使用情况统计646.6.元数据分析功能646.6.1.血缘分析646.6.2.影响分析656.6.3.数据地图展现656.6.4.实体关联分析726.6.5.实体差异分析726.6.6.主机拓扑分析726.6.7.指标一致性分析736.7.元数据质量管理736.7.1.元数据质量检查概述736.7.2.元数据一致性检查736.7.3.元数据关系健全性检查766.7.4.元数据属性检查776.8.元数据服务接口776.8.1.元数据服务接口概述776.8.2.元数据封装技术实现786.8.3.元数据封装服务原语796.8.4.元数据封装接口应用846.9.元数据权限管理947.元数据应用要求947.1.指标库管理957.1.1.指标库管理内容957.1.2.指标库规范化要求957.1.3.指标库管理功能957.2.业务术语自助学习967.2.1.本地自助学习967.2.2.在线自助学习977.3.维表库管理977.3.1.管理范围987.3.2.功能要求987.3.3.管理场景1067.4.接口管理1077.4.1.管理范围1087.4.2.功能要求1087.5.两级经营分析系统元数据互通1117.5.1.整体架构1117.5.2.元数据互通内容1127.5.3.元数据互通接口标准1137.5.4.功能要求1137.6.辅助应用优化1147.6.1.应用开发与上线阶段1147.6.2.应用评估与优化阶段1147.6.3.应用退出与恢复阶段1167.7.辅助安全管理1167.7.1.数据敏感度管理1167.7.2.敏感度服务接口1187.7.3.客户隐私信息管理1217.7.4.客户隐私信息服务接口1217.8.基于元数据的开发管理1227.8.1.开发过程与元数据的关系1237.8.2.开发过程各阶段功能1257.9.数据质量管理1318.元数据变更流程管理1328.1.元数据变更流程定义1328.2.元数据变更流程管理的功能要求1338.3.元数据变更流程的执行1348.3.1.指标库管理中的元数据变更流程1348.3.2.开发过程中的元数据变更流程1349.系统技术要求1359.1.元数据管理遵循标准的要求1359.2.元数据质量管理要求1359.2.1.元数据库中的数据质量要求1359.2.2.元数据获取过程的质量要求1369.3.元数据管理工具的要求1369.3.1.元数据抽取工具1379.3.2.元数据展示及分析工具1379.3.3.元数据维护工具1379.4.元数据存储与备份要求1379.4.1.元数据库存储要求1389.4.2.元数据库备份要求1389.4.3.元数据文件存储要求13910.编制历史139附录：工程实施指导144前言本规范的制订是为了更好地实现元数据的管理，为包括数据质量管理子系统和经营分析系统的各类基础技术和应用提供支撑，加强经营分析系统数据的管控力度，支撑经营分析系统与源系统数据质量协同，增强系统自身管理能力。本规范主要包括以下几方面的内容：经营分析系统元数据概述、元数据管理体系结构、元数据功能、元数据应用、元数据变更流程管理和系统技术要求。在元数据功能部分，着重描述了元数据获取、元数据质量管理和元数据服务接口等功能。在元数据应用部分，重点介绍了两级经营分析系统元数据互通、维表库管理和接口管理等应用。本标准的附录一为规范性附录。本标准由中移有限业 xx 号文件印发。本规范由中国移动通信有限公司业务支撑系统部提出并归口。本规范由归口部门负责解释。本规范起草单位：中国移动通信有限公司。本标准主要起草人：段云峰、何鸿凌、付峰、汪峰、尚晶、张韬、易剑光、杨秋雁、崔洪涛、陈涛、曾成、金骏、朱伟胜、秦晓飞、赵静、徐少飞、邓青、赵洪松、李倩、谢志崇、田长江、余疆、陶涛、肖建明、张红星、魏春辉。iii1. 范围本标准规定了中国移动省级经营分析系统元数据管理的建设内容，供中国移动内部和厂商共同使用；适用于中国移动各省（直辖市、自治区）公司省级经营分析系统元数据管理的建设。2. 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是标注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准。然而，鼓励根据本标准达成协议的各方对是否使用这些文件的最新版本进行研究。凡是不标注日期的引用文件，其最新版本适用于本标准。1中国移动省级ng2-bass技术规范总册（v3.0）中国移动通信有限公司2中国移动省级ng2-bass技术规范数据质量管理子系统分册（v3.0）中国移动通信有限公司3. 术语、定义和缩略语下列术语、定义适用于本标准：字母名词解释ccwmcwm标准是omg组织定义的数据仓库和相关系统的国际元数据标准，cwm标准的目的在于使得数据仓库和商业智能软件的元数据在分布异构的数据分析工具，数据仓库平台，元数据存储等系统之间交互。eetl特指从数据源系统到经营分析系统的数据抽取、转换和加载。g管理元数据描述经营分析系统中管理领域相关概念、关系、规则的数据，主要包括人员角色、岗位职责、管理流程等信息。h核心元模型经营分析系统核心元模型是指以cwm元模型为基础扩展而成的，针对经营分析系统进行精确定义的元模型规范，是企业级的元模型规范。j技术元数据描述经营分析系统中技术领域相关概念、关系、规则的数据。主要包括对数据结构、数据处理方面的特征描述，覆盖经营分析系统数据源接口、数据仓库、etl、olap、数据挖掘、前端展现等全部数据处理环节。s数据处理过程包含了从数据源系统到经营分析系统，以及经营分析系统数据仓库内部的数据抽取、转换和加载。s数据质量监控自动获取经营分析系统各环节的数据质量信息，结合元数据库中的有关检查规则，对数据质量情况进行诊断，并及时向数据质量监控人员报告。s省公司中国移动通信集团各省移动通信有限责任公司。ssql脚本自动解析经营分析系统的sql脚本中所含的数据处理元数据属于技术元数据。sql脚本自动解析指通过对sql脚本的词法、语法和语义分析，自动生成满足cwm规范要求的数据处理元数据的功能。y业务元数据描述经营分析系统中业务领域相关概念、关系、规则的数据。主要包括业务术语、信息分类、指标定义（指标口径）、业务规则等信息。y元模型元模型是构建模型的公共语义基础，元模型必须达到一定的语义要求，以确保它能对问题领域的各个方面进行建模。必须遵循一系列已有的规则（抽象语言）来构建元模型，以保证经营分析系统中的各个软件产品和工具对元模型具有相同的理解。对于所有希望用元模型解释共享元数据的产品和工具来说，元模型的含义必须是一致的。y元数据元数据（meta data）泛指描述领域概念（domain concepts）、领域关系（domain roles）、领域规则（domain rules）的数据，其中，领域语义（semantics）和知识（knowledge）也属于元数据的范畴。下列略缩语适用于本标准：缩写英文描述中文描述astabstract syntax tree抽象语法树bossbusiness operation support system业务运营支撑系统odsoperational data store操作型数据存储cwmcommon warehouse metamodel公共仓库元模型etlextraction transformation loading抽取、转换和加载olapon-line analysis process在线分析处理xmixml metadata interchangexml元数据交换bibusiness intelligence商务智能restrepresentational state transfer表述性状态转移4. 经营分析系统元数据概述本章概要介绍了经营分析系统元数据的概念和管理要求，并介绍了经营分析系统中元数据的基本模型。4.1. 经营分析系统元数据的概念元数据（meta data）泛指描述领域概念（domain concepts）、领域关系（domain roles）和领域规则（domain rules）的数据。领域语义（semantics）和知识（knowledge）也属于元数据的范畴。经营分析系统元数据泛指描述中国移动经营分析领域中的概念、关系和规则的数据。4.2. 经营分析系统的元数据管理4.2.1. 元数据管理的目标为增强元数据管理模块的基础支撑能力，助力经营分析系统提升数据质量管控能力，ng2-bass3.0经营分析系统元数据管理的建设目标是：l 建立经营分析系统核心元模型，规范数据处理过程的结构化描述根据经营分析系统的技术特点和实际建设需要，对cwm标准定义的元模型进行扩充和细化，建立经营分析系统核心元模型，细化对数据处理过程的结构化描述，优化sql脚本自动解析技术，进一步提升数据处理过程元数据的自动获取能力。l 实现两级经营分析系统元数据互通，促进重点接口数据处理过程规范化加强对省级经营分析系统生成一级经营分析系统重点接口的数据处理过程元数据的管理，基于互通元数据接口标准实现重点接口元数据的下发和重点接口数据处理过程元数据的上传，促进两级系统对重点接口统一理解和数据处理过程规范化。l 为经营分析系统基础技术模块提供支撑，扩充元数据服务接口元数据管理模块为数据封装和安全管理等经营分析系统的基础技术模块提供支撑，存储数据封装、数据敏感度和客户隐私信息等相关元数据内容，扩充元数据对外服务接口内容，向外部模块或子系统提供元数据内容和元数据分析服务。l 服务经营分析系统数据质量管理子系统，为源系统联动机制提供基础支撑 基于元数据管理模块统一管理指标、接口单元和维表等关键数据对象，建立相关应用和管理维护机制，提升关键数据对象的元数据质量，为数据质量管理子系统以及源系统协同管理提供元数据内容支撑和应用功能支撑。4.2.2. 元数据管理的范畴中国移动经营分析领域可宏观划分为三个子领域：技术子领域、业务子领域和管理子领域。相应地，经营分析领域的元数据可以划分为三类元数据：技术元数据、业务元数据和管理元数据。这三种元数据的具体描述如下：l 技术元数据 技术元数据是描述经营分析系统中技术领域相关概念、关系和规则的数据，主要包括对数据结构、数据处理方面的特征描述，覆盖经营分析系统数据源接口、数据仓库与数据集市存储、etl、olap、数据封装和前端展现等全部数据处理环节；l 业务元数据 业务元数据是描述经营分析系统中业务领域相关概念、关系和规则的数据，主要包括业务术语、信息分类、指标定义和业务规则等信息；l 管理元数据 管理元数据是描述经营分析系统中管理领域相关概念、关系和规则的数据，主要包括人员角色、岗位职责和管理流程等信息。经营分析系统元数据用于支持经营分析系统的技术活动、管理活动和业务活动，其应用覆盖经营分析系统技术、管理和业务等各个方面，如图 41所示。图 41经营分析系统元数据管理范畴4.3. 经营分析系统元模型本节介绍经营分析系统元模型的内容，具体内容参见附件一：中国移动省级ng2-bass技术规范元模型规范。4.3.1. 经营分析系统元模型概述经营分析系统元模型是经营分析系统元数据管理模块建设的基础，用于规范元数据库内部对象、关系、规则和操作等多方面的内容，其主要包括四个层面：基础层元模型、获取层元模型、数据层元模型和访问层元模型。此外，根据情况还可以包括可选元模型。经营分析系统元模型需满足以下要求：l 开放性 经营分析系统元模型以cwm作为基础模型，能够与其他各类it系统进行互操作；l 适用性 经营分析系统元模型支持在cwm基础上进行扩展，从而描述经营分析系统自身特有的内容；l 标准性 面向两级经营分析系统元数据互通的需要，以cwm为基础建立经营分析系统核心元模型，形成关键元数据对象的统一元数据标准。经营分析系统元模型组成关系示意如图 42所示。图 42 经营分析系统元模型组成和关系以下分别介绍cwm、经营分析系统元模型与cwm的关系，以及经营分析系统核心元模型。4.3.2. cwm概述公共仓库元模型（cwm: common warehouse metamodel）是为数据仓库及商业智能环境间方便地交换元数据而制定的一个标准，其主要目的是在异构环境下，实现不同的数据仓库工具、平台和元数据知识库之间的元数据交换。cwm标准为数据仓库和商业智能（bi）工具之间共享元数据，制定了一整套关于语法和语义的规范，它主要包含以下四个方面的内容： l cwm（metamodel）：描述数据仓库元数据的模型； l cwm xml：cwm元数据的xml表示； l cwm dtd：用来验证cwm xml文档；l cwm idl：dw/bi共享元数据的应用程序访问接口（api）。4.3.2.1. 规范涉及的业界标准cwm标准是omg组织定义的数据仓库和相关系统的国际元数据标准，目的在于使数据仓库和商业智能软件的元数据在分布异构的数据分析工具、数据仓库平台、元数据存储等系统之间进行交换。目前，这个元数据标准得到了ibm、unisys、ncr、oracle和sas等厂商的支持。cwm1.1标准涉及以下几个国际标准：l xmi 1.1；l mof 1.4；l uml 2.0。uml用来描述元模型本身和一些对象元数据，cwm中，和元数据相关的类定义是借助uml语言进行表述的。mof用来定义cwm的体系结构和元模型语言的语义。xmi是xml形式的元数据接口定义语言，它是元数据管理体系中默认的元数据交换文件形式。4.3.2.2. cwm结构cwm的体系结构如图 43所示，包括五个层次：对象模型层、基础层、资源层、分析层和管理层。图 43 cwm体系结构l 对象模型层（object core）：构造和描述其它cwm包中的元模型类。 l 基础层（foundation）: 包括表示cwm概念和结构的模型元素，这些模型元素又可被其他cwm包所共享，它由以下六个子包组成： 业务信息（business information）包：包括表示模型元素业务信息的类与关联； 数据类型（data types）包：包括表示建模者可以用来创建所需数据类型的结构的类与关联； 表达式（expressions）包：包括表示表达式树的类与关联； 键和索引（keys and indexes）包：包括表示键和索引的类与关联； 软件部署（software deployment）包：包括软件如何在数据仓库中发布的类与关联； 类型映射（type mapping）包：包括表示不同系统之间数据类型映射的类与关联。 l 资源层（resource）：用于描述数据资源的包，它包括以下四个子包： 对象（object）包：包括表示其他类型数据资源的元数据的类与管理； 关系（relational）包：包括表示关系型数据资源的元数据的类与关联； 记录（record）包：包括表示记录型数据资源的元数据的类与关联； 多维（multidimensional）包：包括表示多维数据资源的元数据的类与关联； xml包：包括表示xml数据资源的元数据的类与关联。 l 分析层（analysis）：它由以下五个子包组成： 转换（transformation）包：包含表示数据抽取和转换工具的元数据的类和关联； olap包：包含表示olap工具的元数据的类与关联； 数据挖掘（data mining）包：包含表示数据挖掘工具的元数据的类与关联； 信息可视化（information visualization）包：包含表示信息可视化工具的元数据的类与关联； 业务术语（business nomenclature）包：包括表示分类业务的元数据的类与关联。 l 管理层（management）：用于描述数据仓库管理的包，它包括以下两个子包： 仓库过程（warehouse process）包：包括表示仓库过程的元数据的类与关联； 仓库操作（warehouse operation）包：包括表示仓库操作结果的元数据的类与关联。cwm作为数据仓库领域的元模型标准，在元数据的集中管理、元数据互操作和元数据交换方面发挥重要作用。但是cwm作为一个国际性、厂商无关、平台无关的规范，只提供一个公共的元模型框架，将数据仓库领域的公共特性纳入元模型中。cwm对于物理实现精确定义的细化程度不足，而且对业务和管理信息的描述无法满足经营分析系统实际建设需要。因此，经营分析系统元数据管理模块需要对cwm元模型进行扩展，形成精确的物理实现语义描述能力和业务及管理信息的描述能力。4.3.3. 经营分析系统元模型与cwm的关系经营分析系统元模型以cwm为基础，可以面向省级经营分析系统的建设和运维管理需要进行扩展。表 4-1显示了经营分析系统元模型与cwm中的包的对应关系。表 4-1 经营分析系统元模型与cwm的对应关系经营分析系统元模型cwm的包基础层元模型对象模型包，业务信息包，数据类型包，表达式包，键和索引包，类型映射包，软件部署包获取层元模型转换包数据层元模型关系模型包，仓库过程包，仓库操作包访问层元模型olap模型包，数据挖掘模型包，信息可视化包可选元模型业务术语包，xml包，记录包，多维包，对象数据库包4.3.4. 经营分析系统核心元模型概述经营分析系统核心元模型以cwm元模型为基础扩展而成，是面向两级经营分析系统元数据互通的实际需要对关键元数据对象进行精确定义的元模型规范。经营分析系统核心元模型是经营分析系统元模型的子集，在经营分析系统元模型中选择关键元数据对象，具体包括：数据仓库、数据处理过程、接口单元和维度。对于数据处理过程类元模型，基于cwm规范以派生的方法进行扩展，对于其他类元模型，基于cwm规范进行属性精简和调整。经营分析系统核心元模型的主要内容如表 4-2所示。表 4-2 经营分析系统核心元模型列表元模型层次元模型主题元模型对象数据层元模型数据仓库catalog（目录）schema（模式）table（库表）view（视图）column（字段）获取层元模型数据处理过程transformationtask（etl任务）transformationmap（sql脚本）classifiermap（转换处理）relationaloperator（关系型操作）relationalprojection（投影操作）relationaljoin（连接操作）relationalcombination（交并差集合操作）relationalrename（改表名操作）relationalselection（选择操作）relationalgroupby（分组操作）relationalorderby（排序操作）featuremap（字段级映射）可选元模型接口单元interfaceunit（接口单元）field（接口单元字段）可选元模型维度dimension（维度）dimensionedobject（维度成员）5. 元数据管理体系结构本章首先从功能结构和技术结构两个方面简单介绍了元数据管理模块的体系结构，然后分别介绍了各功能层次，以及各层次包含的具体功能。5.1. 功能结构元数据管理模块功能结构如图 51所示。图 51 经营分析系统元数据管理功能结构图元数据管理模块体系结构主要有以下四层：l 元数据获取层元数据获取层位于整个体系架构的最底层，元数据获取层抽象概括了元数据获取的各种途径。业务和管理元数据通常以手工方式获取，技术元数据覆盖数据源系统以及经营分析系统数据的整个生命周期，要求以自动方式获取，如数据字典和数据模型等。l 元数据存储层存储层定义了元数据存储所遵循的元模型，规范从获取层得到的各类元数据的属性要求和存储格式要求，包括业务元数据、技术元数据和管理元数据。经营分析系统核心元模型对经营分析系统的关键数据对象进行模型定义和规范。l 元数据功能层元数据功能层为前端元数据应用提供了基本的功能支撑，主要包括元数据基本功能、元数据分析功能、元数据质量管理、元数据服务接口和元数据权限管理五个部分。其中，元数据基本功能包括元数据维护、元数据查询、变更管理、元数据统计和元数据使用情况统计；元数据分析功能包括血缘分析、影响分析、数据地图展现、实体关联分析、实体差异分析、主机拓朴分析和指标一致性分析；元数据质量管理包括一致性检查、关系健全性检查和元数据属性检查；元数据服务接口包括数据封装元数据服务接口和数据地图访问服务接口。l 元数据应用层在元数据管理模块功能层的支持下，元数据应用层通过调用功能层的功能，对元数据管理的实际问题提供应用解决方案，主要包括指标库管理、业务术语自助学习、维表库管理、接口管理、两级经营分析系统元数据互通、辅助应用优化、辅助安全管理、基于元数据的开发管理和数据质量管理等。5.2. 技术结构元数据管理模块的技术结构对内要求具有良好扩展性，以及能力公开的特性。对外要求提供方便的集成方式，其前端界面需要集成到经营分析门户中。元数据管理模块的技术结构如图 52所示。图 52 经营分析系统元数据管理模块技术结构图在图 52中，元数据、元模型和相关配置信息统一存储在关系数据库中。其中的元数据信息通过数据对象映射，转换成满足cwm规范的数据对象，为元数据获取组件和功能组件提供面向对象的数据存取服务。元数据获取的数据源包括数据处理过程、er逻辑模型、olap对象和数据库对象等。元数据获取组件为元数据自动获取提供了一个可扩展的框架。在该框架中，可以针对每种不同的数据源，提供专用的元数据获取适配器。例如，对于数据处理元数据，可以提供sql脚本解析器。元数据功能组件包括元数据的管理和应用的基础功能组件。例如对血缘分析、影响分析、元数据检索和差异比较等功能。元数据功能组件为元数据应用所调用，同时通过rest风格的web服务实现元数据访问接口的封装，对外能力公开元数据访问能力。元数据应用可以通过portlet和iframe等方式集成到经营分析门户中。此外，元数据管理模块还要包括调度控制、流程控制和权限管理等基础控制功能，为元数据应用组件、功能组件和获取组件的有机配合提供支持。例如，对元数据变更流程的支持和对元数据定时自动获取的支持。6. 元数据管理功能要求本章说明元数据管理模块的获取层、存储层和功能层的各项功能要求。6.1. 元数据获取本节针对经营分析系统元数据管理范畴中所涉及的各类元数据，明确其获取方式、获取时效性、准确性、粒度和相关管理功能支持等方面的要求，确保以各种获取方式进入存储库的元数据能够满足元数据规范化管理的需要。6.1.1. 元数据获取方式经营分析系统的元数据获取方式划分为两类：l 自动获取 在经营分析系统中有部分实体能提供专用的或者标准的元数据获取接口，例如数据仓库和etl工具等，元数据管理模块可以利用这些接口自动抽取元数据。对于数据处理过程中的sql脚本和tcl脚本等数据处理过程脚本程序，元数据管理模块可以通过编译技术自动获取数据处理元数据；l 手工获取 对于无法通过获取接口或者编译技术进行自动获取的元数据，需要通过手工整理的方式进行处理。元数据自动获取和手工获取两种方式都可以将元数据写入到xmi或excel文件，再将这些文件提交到元数据变更管理流程中；也可以直接将元数据变更内容提交到元数据变更管理流程中，示例如图 61所示。元数据变更管理流程的详细内容参见第8章。图 61 元数据获取方式示例元数据管理模块需要针对各类元数据提供相应的元数据导入文件模板。在导入文件模板中规定元数据类型、属性和关系等信息的填写格式，以及新增、修改和删除操作的标记方法。元数据管理模块应支持xmi文件和excel文件两种导入文件模板。采用手工获取方式获取的元数据，元数据模块需要提供根据各自元数据的特征提供相应的元数据手工录入功能。对于采用自动获取方式获取的元数据，元数据管理模块需要提供相应的自动获取功能。这些自动获取功能可以划分为如下几类：l 通过遵守cwm规范的xmi接口自动获取元数据对于datastage和powercenter等etl工具，ibm db2 warehouse manager,oracle warehouse builder repository等数据仓库管理工具，oracle olap server等olap工具和其它兼容cwm的前端展现工具可以通过xmi接口自动获取元数据。l 通过sql解析和tcl脚本解析等脚本解析方法自动获取元数据对于datastage中的源定义sql语句，essbase中的rule文件映射sql语句和数据处理运行日志中的sql语句，都可以通过sql自动解析的方式获取元数据。而tcl脚本程序可以通过tcl脚本自动解析的方式获取元数据。l 通过数据库访问接口（如odbc/jdbc等）自动获取元数据对于数据库对象，例如oracle等dbms中的数据库表、视图、字段和存储过程等，可以通过odbc/jdbc等数据库访问接口自动获取元数据。l 通过其他工具专业api接口自动获取元数据对于erwin、powerdesigner等建模工具，business object reporter等前端展现工具，essbase/ibm db2 olap server、db2 cube views、cognos和sas olap server等olap工具，可以使用该工具特定的元数据访问接口自动获取元数据。6.1.2. 元数据自动获取管理功能元数据自动获取的数据来源分布在数据源系统、数据处理过程、数据仓库、数据集市、olap工具和前端展示工具等实体中。为了加强对元数据自动获取的管理，元数据管理模块需要提供元数据自动获取管理的功能支持。元数据自动获取管理应涵盖五个方面的功能：l 元数据自动获取数据源管理要求元数据管理模块对元数据获取数据源以及这些数据源之间的关系进行集中登记管理，形成自动获取数据源的全局视图，以促进元数据自动获取日常管理的规范化。l 元数据获取能力管理元数据管理模块需要建立元数据获取能力的扩展框架。在该框架下，可以针对经营分析系统中各种元数据获取数据源的特点，通过增加元数据获取适配器的方式，扩展相应的元数据自动获取能力。l 元数据自动获取调度管理要求元数据管理模块对元数据的自动获取提供持续稳定的调度支持，能够按预设的调度策略触发相应的元数据自动获取过程。要求提供元数据自动获取调度策略的统一配置管理功能，以满足元数据自动获取在时效性和获取时机等方面的需要。调度策略应支持时间周期触发和事件触发两种方式。例如，在每周星期一凌晨00:00到01:00之间触发数据仓库元数据的自动获取过程，或者在数据处理程序更新后12小时内触发相应的映射关系元数据自动获取过程。l 元数据生成和入库策略管理元数据的自动生成和入库需要满足以下要求： 元数据命名策略应确保元数据命名的确定性和唯一性； 元数据组织方式应确保元数据关联关系和存放路径的合理性； 元数据入库策略应确保自动生成的元数据与存储库中元数据之间不会出现错误的覆盖和冗余。要求元数据管理模块提供元数据命名策略、组织方式、增量入库和全量入库策略的配置管理支持。l 元数据自动处理过程和相关日志的管理元数据自动处理过程和日志管理功能需要满足以下要求： 能够为各种元数据自动获取数据源配置适应的处理流程和环节； 各个环节的处理关键信息和异常信息需要写入元数据获取日志。要求提供日志查阅和审计功能，并对异常信息提供告警功能。6.2. sql脚本自动解析sql脚本元数据用于结构化描述etl和数据处理过程脚本程序的数据流语义信息，是经营分析系统技术元数据的一部分，为构建经营分析系统数据地图、形成元数据辅助分析能力提供重要支撑。建设sql脚本自动解析功能的目的，是为了确保sql脚本元数据的及时更新，降低管理成本，提高管理效率，为各种辅助分析应用提供高质量的元数据。sql脚本自动解析获取元数据的过程可以分为数据处理日志生成、运行日志获取、sql词法语法分析、sql语义分析生成元数据和sql脚本元数据入库五个环节，如图 62的绿色虚线框所示。通过这五个环节的自动处理，将脚本程序的变化及时传递到应用端，使应用分析的结果能够反映etl和数据处理过程的最新情况。图 62 sql脚本自动解析获取元数据过程其中，输出运行日志环节要求etl和数据处理过程在每次运行时，按指定方式输出运行日志，将提交执行的sql脚本以及必要的上下文信息写入运行日志中。该运行日志起删繁就简的作用，将脚本程序中的数据流语义信息，通过sql脚本及其上下文信息记录下来，传递到下一环节，而脚本程序中的无关信息则屏蔽在该环节之外，简化后续环节的处理。运行日志获取环节定期扫描etl和数据处理过程所输出的日志，提取未经处理的运行日志并触发解析处理过程。sql词法语法分析环节利用编译技术对运行日志中的脚本进行词法语法分析，生成抽象语法树（ast）。其处理过程可分为词法分析和语法分析两个步骤。在第一个步骤，解析程序根据预先定义的sql词法文法，对sql脚本的字符流进行分词处理，输出sql关键字、常量、变量、操作符等分词序列（token）。在第二个步骤，解析程序根据预先定义的sql语法文法，对分词序列进行语法分析，建立层次化的抽象语法树。在sql语义分析生成元数据环节，该环节对各sql脚本的抽象语法树进行语义分析，并结合sql脚本之间上下文相关信息的处理，实现sql脚本语义的元数据结构化描述。这本质上是一种语义翻译，将sql文法表述的语义转换为元模型表述的语义。在这个过程中，sql脚本语义所包含的关系代数操作，如连接、选择和投影等，分别抽象为一个元数据对象，并建立这些对象之间的数据流关系。相关元模型说明参见附件一：中国移动省级ng2-bass技术规范元模型规范v3.0。在sql脚本元数据入库环节，将自动解析所获取的sql脚本元数据写入元数据存储库中。这里需要考虑全量更新与增量更新的问题，确保所获取的元数据能够与存储库中已经存在的元数据融合起来，形成一个整体。6.2.1. 运行日志的输出要求在经营分析系统中，所有需要通过sql脚本自动解析功能获取元数据的数据处理过程，包括数据库存储过程、数据库函数、shell脚本程序、proc脚本程序和java程序等，都需要将提交到数据库执行的所有sql语句按规定格式写入数据处理日志。经营分析系统可以采用如下两种方式存储数据处理日志：l 日志文件方式，以文本文件存放日志内容；l 日志表方式，以数据库表存放日志内容。数据处理日志需要确保足够长的存储周期，以满足sql脚本自动解析的处理需要。6.2.1.1. 日志内容要求在经营分析系统中，要求脚本程序在运行时输出到日志的内容包括：l 提交到数据库执行的sql脚本l 创建数据库链接的相关参数l 文件导入导出操作（import/export/load/unload）这三部分内容必须在日志中以规定方式标记其在程序中的执行顺序。下面分别说明这三部分内容的详细要求。6.2.1.1.1. sql脚本要求脚本程序中所有提交到数据库执行的sql脚本都要完整写入日志中。这些sql脚本应该是数据库服务器可以直接执行的，不能包含脚本程序变量等非数据库语法单元（存储过程除外）。图 63是一个tcl脚本程序样本，其中的sql脚本包含有很多脚本程序变量，如$month、$lastday、$strtab_ods_dcolorringnew_ymd等。脚本程序必须先将所有这些变量置换成具体的变量值，才能将sql脚本输出到日志中，否则sql词法语法分析阶段将该sql脚本识别为存在语法错误。图 63 包含脚本程序变量的sql脚本示例而存储过程写入日志中的sql脚本则可以包含存储过程变量。图 64是一个存储过程样本，其中的sql脚本包含一些存储过程变量，例如:dt_dealdate、:step、:activity_count等。该sql脚本可以直接写入日志中，不需要事先将这些变量置换为变量值。图 64 包含存储过程变量的sql脚本6.2.1.1.2. 数据库连接如果在脚本程序中存在多次创建数据库连接，分别向不同schema提交sql脚本的情况，则必须将创建连接的信息（包括数据库服务器、用户名等）按规定格式写入日志中，以便sql解析器据此确定后续执行的sql脚本的缺省schema是什么。6.2.1.1.3. 文件导入导出操作如果脚本程序中存在以export/import/unload/load命令执行的文件导入导出操作，则必须将这些命令完整输出到日志中。与sql脚本类似，在输出日志前，应该首先将这些命令中的脚本程序变量置换成变量值。一个shell脚本程序示例图 65，其中大量采用export命令将数据从库表导出到文件中。这些export命令，包括select部分，需要完整输出到日志中。图 65 文件导入导出操作样本6.2.1.1.4. 游标操作经营分析系统中游标操作在所有数据操作中所占比例不超过1%，这类操作有大量的数据处理逻辑和相关的上下文信息不包含在sql脚本中，而且这些信息很难在日志中描述。由于这类操作所占比例很小，而且目前所找到的样本都是用于对一些参数进行操作，未发现使用游标对业务事实数据进行操作的情况。基于简化日志输出的考虑，可以忽略游标操作的相关信息，不要求将游标操作的内容写入日志中。但是，创建游标的select语句、将游标fetch出来的数据经过处理后写入数据库的insert语句都需要作为其中一类sql脚本写入日志中。6.2.1.2. 日志格式要求运行日志可以采用日志文件或者日志表两种存储方式。其中日志文件方式采用文本文件记录日志内容，而日志表方式采用数据库表记录日志内容。下面分别说明日志文件和日志表的格式要求。6.2.1.2.1. 日志文件格式每个脚本程序在中运行日志区中都有一个固定的日志文件输出目录。不同脚本程序可以共用一个日志文件输出目录。脚本程序每次运行时，都需要在该目录下输出一个独立的日志文件。这些日志文件应具有明确的文件命名规则，以便sql解析器确定运行日志与脚本程序的对应关系。写入日志文件中的文本所采用的字符集应该与utf-8和gbk兼容。日志文件的内容划分文件头、文件体和文件结束标志三个部分。这三个部分必须按先后顺序依次写入日志文件。如图 66所示。图 66 日志文件内容6.2.1.2.1.1. 文件头格式要求文件头必须依次写入如下内容：l 脚本程序名格式：proc脚本程序名/proc其中的脚本程序名是指脚本程序的文件名。为避免在不同路径下出现重名脚本程序名的情况，这里的文件名应包括文件路径。l 脚本程序版本号格式：version脚本程序版本号/version其中的脚本程序版本号是一个字符串，格式不限。l 脚本程序最近修改时间格式：modify date脚本程序最近修改时间/modify date其中的脚本程序最近修改时间是指脚本程序文件最后一次更新的时间，可以采用操作系统中记录的文件修改时间。时间格式：yyyy-mm-dd hh24:mi:ssl 脚本程序本次运行的输入参数格式：para参数描述串/para其中的参数描述串用于记录脚本程序本次运行时，从外部传进来的参数值。参数描述串的格式：“参数名1=参数值1;参数名2=参数值2;”。l 脚本程序本次运行的启动时间格式：begin time脚本程序本次运行的启动时间/begin time时间格式：yyyy-mm-dd hh24:mi:ss6.2.1.2.1.2. 文件体格式要求文件体记录脚本程序运行时提交到数据库执行的所有sql脚本、创建数据库连接的相关参数以及文件导入导出操作命令。这些内容必须按脚本程序运行的先后顺序写入文件体中。l 提交到数据库执行的sql脚本格式：sqlsql脚本/sql其中sql脚本是指一条可执行的sql语句，具体要求参见第6.2.1.1.1节。sql脚本的起止标志sql和/sql必须分别独占一行。而sql脚本可以占一行或者多行。l 创建数据库链接的相关参数如果在脚本程序中存在建立数据库连接的操作，则相关的数据库连接参数（密码除外）需要以连接串的方式写入日志文件。格式：conn 数据库连接串 /conn其中的数据库连接串应采用如下格式的字符串进行记录：“参数名1=参数值1参数名2=参数值2;”。这些参数应包括：数据库类型、数据库所在主机、数据库实例名和连接用户等内容。l 文件导入导出操作（import/export/load/unload）格式：sql文件导入导出操作命令/sql其中的文件导入导出操作命令是指一条import/export/load/unload命令的完整文本，具体要求参加第6.2.1.1.3节。6.2.1.2.1.3. 文件结束标志文件结束标志用于sql解析器确认一个日志文件的完整性，避免日志文件在输出过程还没完全结束时就被sql解析器提取出来处理。文件结束标志格式：end time 脚本程序本次运行的结束时间/end time时间格式：yyyy-mm-dd hh24:mi:ss6.2.1.2.1.4. 日志文件样例符合日志格式的日志文件样例示意，如图 67所示。图 67所示。图 67所示。图 67所示。图 67 日志文件样例示意6.2.1.2.2. 日志表格式如果在运行日志区中采用数据库表来存储运行日志的内容，则这组日志表的表结构和数据格式必须遵守日志表的格式要求。日志表由如下两张数据库表组成：运行日志总体表：sqlparser_log_general运行日志明细表：sqlparser_log_detail日志表结构如图 68所示。图 68 日志表结构每个脚本程序的每次运行输出一个运行日志。运行日志总体表中的每条记录对应一个运行日志，而运行日志的详细信息写入运行日志明细表中。下面详细说明日志表的填写要求。6.2.1.2.2.1. 运行日志总体表填写要求表 6-1列出运行日志总体表的填写要求：表 6-1运行日志总体表填写说明要求字段名字段内容数据类型说明log_sn运行日志序号number关键字，每个运行日志对应一个唯一的运行日志序号。该序号按运行日志生成的先后顺序递增。prog_name脚本程序名varchar2