一种异构数据源的实体化方法及其引擎技术

本发明专利技术涉及计算机应用技术领域，特别涉及一种异构数据源的实体化方法及其引擎。本发明专利技术将分布式查询过程中产生在数据缓冲缓存区中的临时表转移到持久数据池中，其核心包括通道控制器、持久数据池两个部分。通道控制器负责管理数据从分布式查询引擎进入实体化引擎；持久化数据池提供数据最终的存储空间。本发明专利技术解决了云数据库系统查询过程中产生的中间结果持久化问题；可以用于云数据库系统查询数据的管理上。

【技术实现步骤摘要】
【专利摘要】本专利技术涉及计算机应用
，特别涉及一种异构数据源的实体化方法及其引擎。本专利技术将分布式查询过程中产生在数据缓冲缓存区中的临时表转移到持久数据池中，其核心包括通道控制器、持久数据池两个部分。通道控制器负责管理数据从分布式查询引擎进入实体化引擎；持久化数据池提供数据最终的存储空间。本专利技术解决了云数据库系统查询过程中产生的中间结果持久化问题；可以用于云数据库系统查询数据的管理上。【专利说明】一种异构数据源的实体化方法及其引擎
本专利技术涉及计算机应用
，特别涉及到一种异构数据源的实体化方法及其 引擎。
技术介绍
在企业信息化建设过程中，由于各业务系统建设和实施数据管理系统的阶段性、 技术性以及其它经济和人为因素的影响，导致企业在发展过程中积累了大量采用不同存储 方式的业务数据；包括采用的数据管理系统也大不相同，从简单的文件数据库到复杂的网 络数据库，构成了企业的异构数据源。这些分散的不同业务的数据管理系统虽然能够满足 业务数据存储和管理要求，但在许多情况下，企业领导要做出一项决策，往往需要查询多个 基于各种异构数据源的业务系统和外部系统，进行大量数据分析后才能做出决策。 因此，异构数据源的整合与集成是企业信息化建设过程经常遇到的一个现实问 题，也是制约企业各种应用信息系统建设和数据共享程度，以及信息化建设投资重复或负 担重的一个重要因素。 云数据库系统是进行异构数据源的整合与集成的重要方法。然而，如何云数据库 系统在查询过程中产生的中间结果持久化到一个存储空间中是一个关键问题。 【专利
技术实现思路
】 本专利技术解决的技术问题之一在于提供一种支持异构数据源实体化的方法，解决云 数据库系统在查询过程中产生的中间结果持久化到一个存储空间问题。 本专利技术解决的技术问题之二在于提供一种异构数据源的实体化引擎，解决云数据 库系统在查询过程中产生的中间结果持久化到一个存储空间问题。 本专利技术解决上述技术问题之一的技术方案是： 所述方法是将云数据库系统在分布式查询过程中产生在数据缓冲缓存区中的临 时表转移到持久数据池中，形成实体表；以保存一段相对较长的时间。 所述的云数据库系统可以是MySQL、Oracle、SQL Server、DB2,涉及的文件系统可 以是如Excel文件、KV文件，以及Web Service。 所述的方法对数据实体化过程全生命周期管理，包括创建实体表、数据载入、刷新 实体表、删除实体表，以及访问交互表。 所述的实体化在动态访问的过程中被系统自动实现，整个过程无需用户干预。 本专利技术解决上述技术问题之二的技术方案是： 所述的实体化引擎包括通道控制器、交换表和持久化数据池三个组成部分； 所述的通道控制器，负责管理数据从分布式查询引擎进入实体化引擎的通道； 所述的交换表，存储实体化引擎需要的一些元数据，包括实体表与虚拟表的映射 关系、实体表的创建时间、最近一次更新时间、访问次数等； 所述的持久化数据池，存储大量的实体表，是实体化过程中数据最终流向的目的 地。 所述的通道控制器包括数据的持久化以及实体表的生命周期管理。 本专利技术的方法和引擎具有以下有益效果： 1、可以使用存储空间的数据来响应后续的查询请求，从而大幅减少系统的响应时 间，提高系统的性能，降低底层数据源的处理压力。 2、可以利用存储空间中的数据提供数据分析以及数据挖掘的能力，支持迭代、回 归等算法，增强云数据库系统在OLAP (Online Analytical Processing)方面的能力。本发 明支持多种数据库系统（MySQL、Oracle、SQL Server、DB2)以及文件系统（Excel文件、KV 文件）。 【专利附图】【附图说明】 下面结合附图对本专利技术进一步说明： 图1是本专利技术的逻辑架构图； 图2是本专利技术的通道控制原理图。 【具体实施方式】 云数据库的分布式查询引擎在接收到一个查询请求时，会调用解析器（Query Parser)将请求解析成一个查询计划，然后调用优化器（Query Optimizer)对查询计划进 行优化，如过滤条件下推、虚拟索引、视图合并等优化策略，以提高查询计划的执行效率。在 执行查询计划的过程中，会将远程的各个数据源（Data Source)中的数据抽取到本地的数 据缓冲缓存区（Data Buffer Cache)中，进行计算处理，并返回最终的查询结果。因此，一 个查询计划中用到的虚拟表（视图）基本上会缓存到数据缓冲缓存区中，形成相应的临时 表（Temp Table)〇 实体化本质上是一个数据转移的过程，临时表可以作为实体化的数据来源。实体 化的过程就是将分布式查询过程中产生在数据缓冲缓存区（Data Buffer Cache)中的临时 表转移到持久数据池中，形成实体表的过程。 实体表和临时表有两个重要的区别： 1.生命周期：实体表是持久存在于存储空间中，生命周期较长，而临时表目的是 为了支持查询计划中某些计算必须要在一个集中的点完成，一个查询结束后，临时表的生 命周期也就结束了，因此生命周期较短； 2.存放位置：实体表存放在持久数据池中，而临时表存储在数据缓冲缓存区中； -次查询计划中，只有最顶层的虚拟表（实体）产生的临时表才可能用来作为实 体化。因为，系统会对查询计划进行优化，比如将一些过滤条件下推到子虚拟表（视图）上 去执行，此时，系统会在运行时改变虚拟表（视图）的定义。而最顶层的虚拟表（视图）的 定义在运行时，系统不会改变。 如图所示，为了提高组件的独立性，本专利技术在设计上将实体化的功能封装成一个 单独的服务组件-实体化引擎（Materialize Engine)。实体化引擎包括三个重要的组成 部分： 一、通道控制器（Channel Controller):负责管理数据从分布式查询引擎 (Distributed Query Engine)进入实体化引擎（Materialize Engine)的通道，具体来说 包括数据的持久化以及实体表（Entity Table)的生命周期管理；即通道控制器（channel Controller)用于管理虚拟表（视图）的数据从数据缓冲缓存区进出持久数据池的通道，负 责维护实体表的生命周期，主要提供的功能包括：创建实体表、数据载入、刷新实体表、删除 实体表，以及访问交互表。 通道控制器的逻辑架构图2所示，主要包括6个部分： 1. SQL-Based API :主要提供实体表的创建、数据载入、刷新、删除，提供的是SQL 的接口； 2. Meta API :提供获取实体表元数据的接口； 3. Load Worker :载入线程，负责将数据从分布式引擎中载入到持久化数据池中； 4. Swap Worker :交换线程，在检测到持久数据池中已用数据量达到一个阈值 (MAX_P00L_THRESH0LD)时，启动交换线程，根据LRU算法，删除那些很久没被访问过的"僵 尸实体表"； 5. Purge Worker :清理线程，定期扫描Swap Table,删除游离实体表，游离实体表 对应的虚本文档来自技高网...

【技术保护点】
一种异构数据资源的实体化方法，其特征在于：所述方法是将云数据库系统在分布式查询过程中产生在数据缓冲缓存区中的临时表转移到持久数据池中，形成实体表；以保存一段相对较长的时间。

【技术特征摘要】

【专利技术属性】
技术研发人员：谢毅，岳强，袁子牧，徐志伟，
申请(专利权)人：广东电子工业研究院有限公司，
类型：发明
国别省市：广东;44