SQL 脚本元数据的更新方法、 装置及系统 【技术领域】
本发明涉及元数据管理领域， 具体涉及一种 SQL 脚本元数据的更新方法、 装置及系统。 背景技术 数据仓库领域的元数据管理需要确保元数据的及时更新， 以反映数据仓库系统的 最新情况。当抽取、 转换、 装载 ETL(Extract， transform， load， 简称 ETL) 和数据处理过程 的程序块发生修改后， 就需要更新该程序块相应的 SQL 脚本元数据。元数据更新过程可划 分为两个环节 ： 首先是一个自动解析的过程， 解析该程序块中包含的 SQL 脚本， 获取其数据 流语义并转换为元数据 ； 然后是一个元数据入库的过程， 将所生成的元数据按一定的规则 写入元数据存储库。
第一个环节的自动解析过程通过三个步骤来完成， 步骤一 ： 直接从 ETL 和数据处 理过程的程序代码中提取、 从数据库日志中提取或者从 ETL 和数据处理过程的运行日志中
提取 ETL 和数据处理过程的 SQL 脚本 ； 步骤二 ： 利用编译技术对这些 SQL 脚本进行词法、 语法和语义分析， 生成抽象语法树， 以此作为语义分析的基础 ； 步骤三 ： 对 SQL 脚本的抽象 语法树进行语义分析， 获取其数据流语义信息并转换成元数据。第二个环节是 SQL 脚本元 数据入库过程， 每个元数据对象入库时， 需要根据对象命名对元数据存储库中的对象进行 匹配 ； 如果找不到相同命名的对象， 则认为这是一个新增的对象， 将其添加到元数据存储库 中； 如果找到相同命名的对象， 则认为这是同一个对象， 这时需要考虑采用积极策略还是保 守策略来处理， 其中， 积极策略是以新生成的对象的所有属性值覆盖元数据存储库中的老 对象的属性值， 以新对象的关联关系替换老对象的关联关系， 保守策略则不改动老对象的 属性值和关联关系， 只填写老对象的空属性值并追加关联关系。
当新增程序块第一次运行时， 元数据存储库中并没有该程序块的 SQL 脚本元数 据。 该程序块所输出的 SQL 脚本经过解析处理后生成元数据， 并添加到元数据存储库中。 当 这些程序块重复运行时， 如果继续解析处理程序块运行所输出的 SQL 脚本， 则获取的元数 据在入库处理时就存在如何与存储库中已存在的元数据合并的问题。由于 SQL 脚本的元数 据对象并没有确定的命名方式可以对其进行唯一标识， 利用对象命名与存储库中已存在的 对象进行匹配是很不可靠的， 不能据此找到同一个 SQL 脚本元数据对象， 导致更新效率不 高。 如果程序块发生修改， 修改后的程序块需要进行元数据更新， 这些元数据入库时同样遇 到如何与元数据存储库中已有元数据合并的问题。 此外， 如果程序块存在多条运行路径， 当 次运行就只能输出了其中一条运行路径的 SQL 脚本， 使得解析这些 SQL 脚本所生成的元数 据并不能完整描述整个程序块中的 SQL 脚本数据流语义。
现有 SQL 脚本元数据更新方案存在如下不足 ：
(1) 在元数据入库时， 以对象命名进行匹配， 进而决定元数据是否入库， 难以确保 当 ETL 和数据处理过程程序块重复运行或者发生修改时元数据更新的质量， 更新效率不 高；(2) 当次运行只能输出了一条运行路径的 SQL 脚本记录在运行日志中， 且以对象 命名进行匹配， 导致根据运行日志获取 SQL 脚本时， 在程序块中存在分支、 循环的情况下很 难确保元数据更新的质量， 更新效率不高。 发明内容 本发明的第一目的是提出一种效率高的 SQL 脚本元数据的更新方法。
本发明的第二目的是提出一种效率高的 SQL 脚本元数据的更新装置。
本发明的第三目的是提出一种效率高的 SQL 脚本元数据的更新系统。
为实现上述第一目的， 本发明提供了一种 SQL 脚本元数据的更新方法， 包括 ： 解析 程序块中包含的 SQL 脚本， 获取元数据 ； 判断 SQL 脚本与元数据库已记录 SQL 脚本是否为同 一脚本 ； 在判定为不同脚本时， 将元数据更新至元数据库。
为实现上述第二目的， 本发明提供了一种 SQL 脚本元数据的更新装置， 包括 ： 解析 模块， 用于解析程序块中包含的 SQL 脚本， 获取元数据 ； 判断模块， 用于判断 SQL 脚本与元数 据库已记录 SQL 脚本是否为同一脚本 ； 处理模块， 用于在判定为不同脚本时， 将元数据更新 至元数据库。
为实现上述第三目的， 本发明提供了一种 SQL 脚本元数据的更新系统， 包括 ： 元数 据库， 用于记录 SQL 脚本的元数据及 SQL 脚本的修改信息 ； SQL 脚本元数据的更新装置， 用 于解析 SQL 程序块中包含的 SQL 脚本获取元数据 ； 并判断 SQL 脚本与元数据库已记录 SQL 脚本是否为同一脚本 ； 以及在判定为不同脚本时， 将元数据更新至元数据库。
本发明各个实施例中， 在判定是否为同一 SQL 脚本后进行元数据的更新操作， 避 免了现有技术中在元数据入库时以对象命名进行匹配而导致更新效率不高的不足， 提升更 新效率。
附图说明 附图用来提供对本发明的进一步理解， 并且构成说明书的一部分， 与本发明的实 施例一并用于解释本发明， 并不构成对本发明的限制。在附图中 ：
图 1 为本发明的 SQL 脚本元数据的更新方法的实施例一流程图 ；
图 2 为本发明的 SQL 脚本元数据的更新方法的实施例二流程图 ；
图 3 为本发明的 SQL 脚本元数据的更新装置的实施例结构图 ；
图 4 为本发明的 SQL 脚本元数据的更新系统的实施例结构图。
具体实施方式
以下结合附图对本发明的优选实施例进行说明， 应当理解， 此处所描述的优选实 施例仅用于说明和解释本发明， 并不用于限定本发明。
方法实施例
图 1 为本发明的 SQL 脚本元数据的更新方法的实施例一流程图。如图 1 所示， 本 实施例包括 ：
步骤 S102 ： 解析程序块中包含的 SQL 脚本， 获取元数据 ； 详细参见图 2 步骤 201 的 解释说明 ；步骤 S104 ： 判断 SQL 脚本与元数据库已记录 SQL 脚本是否为同一脚本 ； 详细参见 图 2 的解释说明 ；
步骤 S106 ： 在判定为不同脚本时， 将元数据更新至元数据库 ； 详细参见图 2 的解释 说明。
本实施例通过在判定是否为同一 SQL 脚本后进行元数据的更新操作， 避免了现有 技术中在元数据入库时以对象命名进行匹配而导致效率不高的不足， 提升更新效率。
图 2 为本发明的 SQL 脚本元数据的更新方法的实施例二流程图。如图 2 所示， 本 实施例包括 ：
步骤 201， 持续从 ETL 和数据处理过程每次运行所输出的运行日志中提取 SQL 脚 本， 获取元数据 ；
本领域技术人员可以理解， 一般可以通过如下三种方式提取 SQL 脚本 ： 直接从 ETL 和数据处理过程的程序代码中提取、 从数据库日志中提取或者从 ETL 和数据处理过程的运 行日志中提取 ； 以下各实施例仅以从 ETL 和数据处理过程的运行日志中提为例进行解释说 明；
步骤 201 中持续获取 SQL 脚本的元数据有利于实现多路径 SQL 脚本的元数据的完 整性 ； 步骤 202， 根据运行日志中记载的修改信息， 判断 SQL 脚本是否被修改， 在判定被 修改时， 将元数据更新至元数据库， 并覆盖 SQL 脚本修改前的元数据， 也就是说， 在判定被 修改时， 采用全量更新的方式， 即以一个程序块为单位， 将元数据库中该程序块的元数据全 部替换为解析该程序块的 SQL 脚本新生成的元数据， 在判定未被修改时， 执行步骤 203- 步 骤 205 的操作 ； 具体解释如下 ：
首先， 预先设置脚本程序在运行日志中写入脚本程序的修改信息， 如版本号和脚 本程序文件的最近修改时间 ； 具体操作时， 如果运行日志采用文本文件存储， 则该修改信息 可以写在文件头部分 ；
其次， 在处理完一个运行日志并将所生成的元数据写入元数据库时， 运行日志中 所记录的修改信息也一起写入元数据库中， 具体操作时， 在元数据库中， 版本号和最近修改 时间可以作为脚本程序对象的两个属性进行存储 ；
再次， 准备将生成的元数据写入元数据库时， 将当前处理的运行日志所记录的脚 本程序版本号和最近修改时间， 与元数据库中记录的对应脚本程序的版本号和最近修改时 间进行比较 ； 如果两者一致， 说明脚本程序在前后两次元数据自动获取之间没有做过修改， 需要采用增量入库方式处理 ( 详细参见步骤 205) ； 如果两者不一致， 说明脚本程序中前后 两次元数据自动获取之间做过修改， 需要采用全量入库方式处理， 即清除该脚本程序在元 数据库中的元数据， 然后将自动获取的元数据全量入库 ；
步骤 203， 判断元数据库中是否存在该 SQL 脚本的元数据， 具体可以采用步骤 205 中对于同一条 SQL 脚本的识别方法来判断 ；
步骤 204， 在判定不存在 SQL 脚本的元数据时， 将元数据更新至元数据库 ；
上述步骤 203 及 204 主要用于说明， 在自动获取某个脚本程序的元数据时， 如果元 数据库中没有该脚本程序的元数据， 则直接将自动获取的元数据全量入库， 无需考虑元数 据合并的问题 ；
步骤 205， 判断 SQL 脚本与元数据库已记录 SQL 脚本的逻辑或字段级依赖关系是否 相同， 其中， 逻辑包括 SQL 脚本访问的数据对象及操作逻辑， 操作逻辑包括投影操作、 连接 操作、 选择操作、 交并差操作、 分组操作及排序操作中的至少一个， 该字段级映射关系为 CWM 规范中的一个类， 这个类的类名 ： FeatureMap ； 具体解释如下 ：
首先， 脚本程序在前后两次自动获取元数据之间没有做过修改， 需要判断脚本是 否为同一条， 且在判定为不同时将后面获取的元数据入库， 本实施例中以 SQL 脚本的逻辑 或字段级依赖关系作为是否为同一条 SQL 脚本的判断标准， 即： 当两条 SQL 脚本的逻辑相同 或者结构相同时， 被识别为同一条 SQL 脚本， 其中， SQL 脚本的逻辑相同是指这些 SQL 脚本 所操作的数据对象完全相同以及对这些 SQL 脚本访问的数据对象的操作逻辑一致， 如下面 SQL 脚本的逻辑相同 ：
select ta.fl， ta.f2 from ta where ta.f3 ＝ 1000 ；
SELECT a.f1， a.f2 FROM ta a WHERE a.f3 ＝ 1000 ；
select(ta.f1)a， ((ta.f2))b from ta where ta.f3 ＝ 1000 ；
下 面 SQL 脚 本 也 是 逻 辑 相 同 的， 因 为 SQL 脚 本 中 的 ta_200905、 ta_200906、 ta_200907 在元数据中指的是同一个 SQL 脚本访问的数据对象 ： select a.f1， a.f2from ta_200905a ；
select a.f1， a.f2from ta_200906a ；
select a.f1， a.f2from ta_200907a ；
SQL 脚本的结构相同是指这些 SQL 脚本具有完全相同的字段级依赖关系， 例如 ：
select ta.f1， ta.f2from ta where ta.f3 ＝ 1000 ；
select ta.f1， a.f2from ta where ta.f4in(100， 500， 800)order by ta.f1 ；
具体操作时， 满足字段级依赖关系但投影逻辑、 where 子句、 order by 子句或者 group by 子句等存在差异的 SQL 语句也可以视为结构相同， 如：
select a.f1+a.f2， a.f1*a.f2from ta a ；
select a.f1-a.f2， a.f1/a.f2from ta a ；
然而， 下面这些 SQL 脚本具有不同的字段级数据对象投影关系， 他们之间的字段 级依赖分析结果是不一样的， 故二者是结构不相同的 SQL 脚本 ：
select a.f1， a.f2 from ta a ；
select a.f1+a.f2， a.f1*a.f2from ta a ；
步骤 206. 在判定逻辑或字段级依赖关系不同时， 将元数据更新至元数据库， 也就 是说， 当我们增量处理一个脚本程序的元数据时， 如果脚本程序中某条 SQL 脚本的元数据 已经在元数据库中存在， 则不需要将这条 SQL 脚本的元数据写入元数据库， 或者在写入时 覆盖这条 SQL 脚本对应的已经存在的元数据， 如果脚本程序中某条 SQL 脚本的元数据在元 数据库中不存在， 则直接将这条 SQL 脚本的元数据写入元数据库中。
上述步骤 205 及 206 主要用于解释在自动获取某个脚本程序的元数据时， 元数据 库中已经保存了该脚本程序上次自动获取的元数据， 而且脚本程序在前后两次自动获取元 数据之间没有做过修改的情况下采用增量更新元数据 ( 具体包括识别同一程序块内的同 一 SQL 脚本的流程 ) 的流程。本领域技术人员可以理解 ： 上述方法不仅可以使用于数据仓 库， 也可以应用于其他环境下的 SQL 脚本元数据的更新操作。
本实施例通过根据 SQL 脚本的逻辑或字段级依赖关系判断是否为同一 SQL 脚本， 进而进行元数据的更新操作， 避免了现有技术中在元数据入库时以对象命名进行匹配而导 致效率不高的不足， 提升更新效率 ； 同时， 通过持续处理 ETL 和数据处理过程每次运行所输 出的运行日志， 将每次处理所生成的元数据全量或增量写入元数据存储库， 实现将每条运 行路径的 SQL 脚本元数据整合在一起， 形成整个 ETL 和数据处理过程程序块的 SQL 脚本元 数据， 可以有效解决基于运行日志进行 SQL 脚本元数据自动获取时常见的多路径问题， 避 免自动获取的元数据只能覆盖 ETL 和数据处理过程的某条运行路径， 提升 SQL 脚本元数据 的自动获取质量。
装置实施例
图 3 为本发明的 SQL 脚本元数据的更新装置的实施例结构图。图 1 及 2 所示的各 方法实施例均可适用于本实施例。本实施例包括 ： 解析模块 31， 用于解析程序块中包含的 SQL 脚本， 获取元数据 ； 判断模块 32， 用于判断 SQL 脚本与元数据库已记录 SQL 脚本是否为 同一脚本 ； 处理模块 33， 用于在判定为不同脚本时， 将元数据更新至元数据库。
具体操作时， 该装置还可以包括 ：
修改处理模块 34， 用于根据运行日志中记载的修改信息， 判断 SQL 脚本是否被修 改； 并在判定被修改时， 将元数据更新至元数据库， 并覆盖 SQL 脚本修改前的元数据 ； ； 以及 判定未被修改时， 控制判断模块 32 进行操作 ； 分析模块 35， 用于判断元数据库中是否存在 SQL 脚本的元数据 ； 以及在判定不存 在 SQL 脚本的元数据时， 将元数据更新至元数据库， 具体操作时， 该分析模块 35 可以利用判 断模块 32 判断是否属于同一 SQL 脚本的方法进行判断， 详见步骤 203 及 204 的解释说明。
判断模块 32 可以包括判断子模块 ( 图未示 )， 用于判断 SQL 脚本与元数据库已记 录 SQL 脚本的逻辑或字段级依赖关系是否相同， 其中， 逻辑包括 SQL 脚本访问的数据对象及 操作逻辑， 操作逻辑包括投影操作、 连接操作、 选择操作、 交并差操作、 分组操作及排序操作 中的至少一个， 逻辑或字段级依赖关系相同时表征为同一脚本。
解析模块 31 可以包括 ： 提取子模块 312， 用于持续从 ETL 和数据处理过程每次运 行所输出的运行日志中提取 SQL 脚本 ； 解析子模块 314， 根据 SQL 脚本解析获取元数据。
本领域技术人员应当可以理解 ： 对应于图 2 中的解释说明， 解析模块 31、 判断模块 32、 处理模块 33 即可实现避免现有技术中在元数据入库时以对象命名进行匹配而导致效 率不高的不足， 其他的模块及子模块均为优选实施方式。
本实施例中， 判断模块 32 通过根据 SQL 脚本的逻辑或字段级依赖关系判断是否为 同一 SQL 脚本， 进而进行元数据的更新操作， 避免了现有技术中以对象命名进行匹配而导 致效率不高的不足， 提升更新效率 ； 同时， 提取子模块 312 通过持续处理 ETL 和数据处理过 程每次运行所输出的运行日志， 处理模块 33、 修改处理模块 34、 分析模块 35 将每次处理所 生成的元数据全量或增量写入元数据存储库， 实现将每条运行路径的 SQL 脚本元数据整合 在一起， 形成整个 ETL 和数据处理过程程序块的 SQL 脚本元数据， 可以有效解决基于运行 日志进行 SQL 脚本元数据自动获取时常见的多路径问题， 避免自动获取的元数据只能覆盖 ETL 和数据处理过程的某条运行路径， 提升 SQL 脚本元数据的自动获取质量。
系统实施例
图 4 为本发明的 SQL 脚本元数据的更新系统的实施例结构图。图 1 及 2 所示的各
方法实施例均可适用于本实施例。 本实施例包括 ： 元数据库 42， 用于记录 SQL 脚本的元数据 及 SQL 脚本的修改信息 ； SQL 脚本元数据的更新装置 44， 用于解析 SQL 程序块中包含的 SQL 脚本获取元数据 ； 并判断 SQL 脚本与元数据库已记录 SQL 脚本是否为同一脚本 ； 以及在判 定为不同脚本时， 将元数据更新至元数据库。其中， SQL 脚本元数据的更新装置 44 的详细 说明参见图 3 的解释说明。
本实施例中， SQL 脚本元数据的更新装置 44 通过根据 SQL 脚本的逻辑或字段级依 赖关系判断是否为同一 SQL 脚本， 进而进行元数据的更新操作， 避免了现有技术中以对象 命名进行匹配而导致效率不高的不足， 提升更新效率 ； 同时， 通过持续处理 ETL 和数据处理 过程每次运行所输出的运行日志， 将每次处理所生成的元数据全量或增量写入元数据存储 库， 实现将每条运行路径的 SQL 脚本元数据整合在一起， 形成整个 ETL 和数据处理过程程序 块的 SQL 脚本元数据， 可以有效解决基于运行日志进行 SQL 脚本元数据自动获取时常见的 多路径问题， 避免自动获取的元数据只能覆盖 ETL 和数据处理过程的某条运行路径， 提升 SQL 脚本元数据的自动获取质量。
最后应说明的是 ： 以上仅为本发明的优选实施例而已， 并不用于限制本发明， 尽管 参照前述实施例对本发明进行了详细的说明， 对于本领域的技术人员来说， 其依然可以对 前述各实施例所记载的技术方案进行修改， 或者对其中部分技术特征进行等同替换。凡在 本发明的精神和原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护 范围之内。