CN103324724B - 数据处理方法及装置 - Google Patents
数据处理方法及装置 Download PDFInfo
- Publication number
- CN103324724B CN103324724B CN201310260406.9A CN201310260406A CN103324724B CN 103324724 B CN103324724 B CN 103324724B CN 201310260406 A CN201310260406 A CN 201310260406A CN 103324724 B CN103324724 B CN 103324724B
- Authority
- CN
- China
- Prior art keywords
- plan
- cost
- subquery
- query
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明涉及一种数据处理方法及装置，所述方法包括：获取数据查询请求，根据所述数据查询请求生成查询计划；将所述查询计划分解成多个子查询计划；根据子计划数据库中已保存的子查询计划的信息，确定所述多个子查询计划的查询代价；将所述多个子查询计划中查询代价满足预设条件的子查询计划对应的数据存储于缓存中。本发明提供的数据处理方法及装置，能够充分利用缓存存储数据，让缓存带来最大的价值，提高了缓存数据的有效性和命中率，从而提高OLAP的查询响应速度及查询性能。
Description
技术领域
本发明涉及计算机技术领域，尤其涉及一种数据处理方法及装置。
背景技术
联机分析处理（On-Line Analytical Processing，OLAP）是一种可以为管理、分析人员提供多维度信息的快速、一致交互式存取，从而获得对数据更深入分析的软件工具，主要应用于各种商业智能分析领域。联机分析处理逻辑系统包括源数据的读取、立方体建模分析处理和用户展现三部分。联机分析处理的数据源可以来自多种不同的物理存储介质：如集群的数据仓库、本地硬盘，闪存或者固态硬盘。联机分析处理系统处理用户查询请求的流程：（1）首先从存储介质中加载原始数据；（2）将加载的数据通过多维度立方体的建模；（3）再根据用户的查询请求对数据进行扫描、维度聚合、过滤等处理后将结果以报表、仪表盘、图例等方式展现给用户。
基于内存的联机分析处理（In Memory OLAP）是现有联机分析处理方法中普遍采用的一种方法，其利用内存读写速度快的优点，通过将部分的数据缓存在内存中，可以有效提高用户查询的处理性能，缩短响应时间，充分发挥了缓存的优势，并通过周期的刷新缓存数据内容，提高缓存的命中率。
现有In Memory OLAP的实现方式主要包括：固定缓存和基于LRU（Least RecentlyUsed）最近最少使用原则的缓存两种实现方式。
固定缓存的In Memory OLAP方法，是系统开发人员根据以往相关经验固化一些数据信息缓存在内存中。这种方法存在两个缺点：（1）缓存数据仅凭开发人员的经验选择，并未考虑数据被查询频度和层次化的数据查询复杂度等因素，缓存数据的有效性和缓存命中率低；（2）缓存数据被固化在内存中，缓存数据不能灵活更新，系统的灵活性和可扩展性差。
基于LRU缓存的In Memory OLAP方法，其思想是将最近一段时间查询较少的数据从缓存中搬出来，而将最近被频繁查询的数据保留在内存中。然而，基于LRU缓存的InMemory OLAP方法并没有针对OLAP多维分析的特性，考虑数据聚合统计的计算规模、响应时间和数据存储的物理介质等更多的因素。在查询频度较平均的场景中，缓存数据的有效性较低，查询性能也并不理想。
随着移动互联网和个人消费领域的不断发展扩大，一方面每天都有海量的TB，PB级新数据被灌入数据仓库，而另一方面运营商渴望通过对生成的数据进行深入分析以支持精细化的管理决策。当前已有的In Memory OLAP技术在海量数据面前效果并不理想，主要问题在于系统响应慢、实时性不理想。因此如何进一步提高In Memory OLAP数据查询的实时性是当前业务发展，市场拓展面临的主要技术问题。
发明内容
本发明的目的是提供一种数据处理方法及装置，能够充分利用缓存存储数据，可以提高缓存数据的有效性和命中率，从而提高In Memory OLAP的查询响应速度及查询性能。
为实现上述目的，本发明第一方面提供了一种数据处理方法，所述方法包括：
获取数据查询请求，根据所述数据查询请求生成查询计划；
将所述查询计划分解成多个子查询计划；
根据子计划数据库中已保存的子查询计划的信息，确定所述多个子查询计划的查询代价；
将所述多个子查询计划中查询代价满足预设条件的子查询计划对应的数据存储于缓存中。
结合第一方面，在第一方面的第一种可能的实施方式中，所述根据子计划数据库中已保存的子查询计划的信息，确定所述多个子查询计划的代价成本，包括：
根据代价模型计算得到所述多个子查询计划的查询代价，所述代价模型为所述子计划数据库中已保存的子查询计划的信息中的代价因素的计算表达式。
结合第一方面的第一种可能的实施方式，在第一方面的第二种可能的实施方式中，所述代价因素包括以下所列中的一种或任意结合：
数据规模、查询频度、计算规模、存储介质和算法执行时间。
结合第一方面的第二种可能的实施方式，在第一方面的第三种可能的实施方式中，所述根据代价模型计算得到所述多个子查询计划的查询代价，包括：
根据以下计算公式分别计算得到每一个所述子查询计划的查询代价：
Query_Cost=a*查询频度+（1-a）*计算规模，其中，Query_Cost表示查询代价，a表示预设的加权因子。
结合第一方面的第二种可能的实施方式，在第一方面的第四种可能的实施方式中，所述根据代价模型计算得到所述多个子查询计划的查询代价，包括：
根据以下计算公式分别计算得到每一个所述子查询计划的查询代价：
Query_Cost=数据规模+（存储介质+计算规模）*查询频度，其中，Query_Cost表示查询代价。
结合第一方面，在第一方面的第五种可能的实施方式中，所述查询代价满足预设条件包括：
所述查询代价排在前N个，N为预设正整数；
或者，所述查询代价超过预设代价阈值。
结合第一方面，在第一方面的第六种可能的实施方式中，在将所述多个子查询计划中查询代价满足预设条件的子查询计划对应的数据存储于缓存中之后，还包括：
将所述多个子查询计划的信息更新或存储到所述子计划数据库中；
所述多个子查询计划的信息包括以下所列中的一种或任意结合：
所述子查询计划、所述子查询计划对应数据的键key索引、所述子查询计划的查询代价、所述子查询计划的代价因素、所述子查询计划对应的数据的存储位置，以及所述子查询计划与其他子查询计划的依赖关系。
结合第一方面的第六种可能的实施方式，在第一方面的第七种可能的实施方式中，所述子计划数据库以树形结构或列表形式存储所述子查询计划的信息。
结合第一方面，在第一方面的第八种可能的实施方式中，在将所述查询计划分解成多个子查询计划之后，还包括：
确定所述多个子查询计划对应数据的存储位置，从所述存储位置中获取对应数据，生成数据处理结果。
第二方面，本发明还提供了一种数据处理装置，所述装置包括：查询计划处理器、查询计划解析器、子计划管理器、代价管理器和数据管理器；
所述查询计划处理器，用于获取数据查询请求，根据所述数据查询请求生成查询计划；
所述查询计划解析器，用于将所述查询计划处理器生成的所述查询计划分解成多个子查询计划；
所述子计划管理器，用于将子查询计划的信息存储于子计划数据库中；
所述代价管理器，用于根据所述子计划管理器的子计划数据库中已保存的子查询计划的信息，确定所述查询计划解析器得到的所述多个子查询计划的查询代价，并将所述多个子查询计划的查询代价存储于所述子计划数据库中；
所述数据管理器，用于将所述代价管理器得到的所述多个子查询计划中查询代价满足预设条件的子查询计划对应的数据存储于缓存中。
结合第二方面，在第二方面的第一种可能的实施方式中，所述代价管理器具体用于根据代价模型计算得到所述子查询计划的查询代价，所述代价模型为所述子计划管理器的子计划数据库中已保存的子查询计划的信息中的代价因素的计算表达式。
结合第二方面的第一种可能的实施方式，在第二方面的第二种可能的实施方式中，所述代价因素包括以下所列中的一种或任意结合：
数据规模、查询频度、计算规模、存储介质和算法执行时间。
结合第二方面的第二种可能的实施方式，在第二方面的第三种可能的实施方式中，所述代价管理器具体用于根据以下计算公式分别计算得到每一个所述子查询计划的查询代价：
Query_Cost=a*查询频度+（1-a）*计算规模，其中，Query_Cost表示查询代价，a表示预设的加权因子。
结合第二方面的第二种可能的实施方式，在第二方面的第四种可能的实施方式中，所述代价管理器具体用于根据以下计算公式分别计算得到每一个所述子查询计划的查询代价：
Query_Cost=数据规模+（存储介质+计算规模）*查询频度，其中，Query_Cost表示查询代价。
结合第二方面，在第二方面的第五种可能的实施方式中，所述查询代价满足预设条件包括：
所述查询代价排在前N个，N为预设正整数；
或者，所述查询代价超过预设代价阈值。
结合第二方面，在第二方面的第六种可能的实施方式中，所述子计划管理器还用于更新或存储所述多个子查询计划的信息到所述子计划数据库中；
所述多个子查询计划的信息包括以下所列中的一种或任意结合：
所述子查询计划、所述子查询计划对应数据的键key索引、所述子查询计划的查询代价、所述子查询计划的代价因素、所述子查询计划对应的数据的存储位置，以及所述子查询计划与其他子查询计划的依赖关系。
结合第二方面的第六种可能的实施方式，在第二方面的第七种可能的实施方式中，所述子计划管理器将所述子查询计划的信息以树形结构或列表形式存储到所述子计划数据库。
结合第二方面，在第二方面的第八种可能的实施方式中，所述数据管理器还用于确定所述多个查询计划解析器得到的所述子查询计划对应数据的存储位置，从所述存储位置中获取对应数据，生成数据处理结果。
本发明提供的数据处理方法及装置，通过引入代价模型评估子查询计划的查询代价，根据查询代价选择合理的数据存储于缓存中，能够充分利用缓存存储数据，让缓存带来最大的价值，提高了缓存数据的有效性和命中率，从而提高OLAP的查询响应速度及查询性能。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的带有联机分析处理设备的组网图；
图2为本发明实施例一提供的数据处理方法流程图；
图3为本发明实施例一采用树形结构的子计划数据库的示意图；
图4为本发明实施例二提供的数据处理装置示意图；
图5为本发明实施例三提供的联机分析处理设备的结构示意图。
具体实施方式
下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
图1是本发明实施例提供的带有联机分析处理（On-Line AnalyticalProcessing，OLAP）设备的OLAP系统组网图，如图1所示，该OLAP系统包括：联机分析处理设备1、数据仓库2和客户端3，客户端3通过网络4与联机分析处理设备1连接，联机分析处理设备1与数据仓库2相连接，数据仓库2中存储大量数据，联机分析处理设备1利用数据仓库2中的数据进行处理用户的处理请求。例如，数据仓库2中记录XX公司各年各月的销售额数据，用户可以在客户端3上通过联机分析处理设备1查询具体年、月、子公司、部门的销售额，也可以查询年度、季度、子公司的累积结果等等。
具体联机分析处理的过程包括：（1）客户端3接收联机分析处理请求；（2）客户端3将处理请求通过网络4传递给联机分析处理设备1；（3）联机分析处理设备1处理客户端3的处理请求，得到分析处理结果；（4）联机分析处理设备1将分析处理结果通过网络4回传到客户端3；（5）客户端3将处理结果展现给用户。
本发明实施例提供的数据处理方法和装置，适用于带有联机分析处理设备的系统，例如上述OLAP系统，使得基于内存的联机分析处理设备的缓存在空间有限的条件下得到充分合理的利用，具有较好的查询性能。
实施例一
图2是本实施例提供的基于上述OLAP系统的数据处理方法流程图，如图2所示，本发明的数据处理方法包括：
S101、获取数据查询请求，根据所述数据查询请求生成查询计划。
每一个数据查询请求对应为一个查询计划。例如，用户请求查询的数据为子公司Axx年的销售额，则联机分析处理设备接收到该数据查询请求，生成对应的查询计划为：子公司A xx年的销售额。
对于数据仓库中已有的用户查询数据，通过本实施例的方法逐一对已有的用户查询数据进行处理，每一个数据查询请求对应为一个查询计划。
S102、将所述查询计划分解成多个子查询计划。
将查询计划的中间结果数据对应为子查询计划，将查询计划分解为若干子查询计划。例如，查询计划为子公司A二、三季度销售额比，可以分解为：子公司A每个月的销售额、子公司A二季度销售额以及子公司A三季度销售额。
S103、根据子计划数据库中已保存的子查询计划的信息，确定所述多个子查询计划的查询代价。
子计划数据库中已保存的子查询计划的信息可以但不限于包括：所述子查询计划、所述子查询计划对应数据的键key索引、所述子查询计划的查询代价、所述子查询计划的代价因素、所述子查询计划对应的数据的存储位置，以及所述子查询计划与其他子查询计划的依赖关系。
确定所述多个子查询计划的查询代价，具体包括：根据代价模型计算得到所述子查询计划的查询代价。
所述代价模型为代价因素的计算表达式，所述代价因素可以但不限于包括：数据规模、查询频度、计算规模、存储介质和算法执行时间等。其中，数据规模是子查询计划对应的数据量，查询频度是子查询计划累计的被查询次数，计算规模是得到子查询计划对应的数据所需的下一层数据的数量，存储介质是子查询计划对应的数据的存储位置，算法执行时间是得到子查询计划对应的数据所需的时间。利用这些代价因素确定代价模型，通常还需要对非数值型的代价因素进行权值的量化设定。
以存储介质这一代价因素为例，一般来说，不同存储设备的数据读写速度的关系通常是Memory>FLASH>SSD>Disk>数据仓库，在Memory中的读写速度最快，在数据仓库的最慢，因而，设定量化的权值如下表1所示：
表1
| 存储介质 | 代价 |
| 数据仓库 | 10 |
| 本地磁盘Disk | 6 |
| 固态硬盘SSD | 4 |
| 闪存FLASH | 3 |
| 缓存Memory | 0 |
相类似的，也可以对其他非数值型的代价因素进行权值的量化设定，用以通过代价模型的计算表达式计算得到查询代价的数值。
可选的，根据实际应用场景选择需要考虑的代价因素，以构成的查询代价的计算表达式，用来衡量子查询计划的查询代价成本。
另外，还可以提供开放的代价模型配置接口，以供用户灵活调整代价模型的计算表达式和代价因数。例如，可以选择所要考虑的代价因素或调整代价因素的权重，以修改代价评估标准形成合理的代价模型，从而调整缓存数据刷新结果。
S104、将所述多个子查询计划中查询代价满足预设条件的子查询计划对应的数据存储于缓存中。
将子查询计划的查询代价与缓存中已存储的子查询计划的查询代价进行排序，将查询代价满足预设条件的子查询计划对应的数据存储于缓存中，将剩余的所述查询代价不满足预设条件的子查询计划对应的数据存储到外部数据仓库中。
所述查询代价满足预设条件包括：所述查询代价排在前N个，N为预设正整数；或者，所述查询代价超过预设代价阈值。
将高代价的子查询计划对应的数据缓存在内存中，而将低代价的子查询计划对应的数据从缓存中移除。
可选的，在S104之后，还包括：将所述多个子查询计划的信息更新或存储到子计划数据库中。
其中，子查询计划的信息可以但不限于包括：所述子查询计划、所述子查询计划对应数据的键key索引、所述子查询计划的查询代价、所述子查询计划的代价因素、所述子查询计划对应的数据的存储位置，以及所述子查询计划与其他子查询计划的依赖关系等等。
子计划数据库可以但不限于以树形结构或列表形式等存储子查询计划的信息。
利用子计划数据库来管理和记录每个子查询计划对应数据的key索引、查询代价、代价因素和数据是否缓存，并维护子计划之间的依赖关系，用以根据保存的子查询计划的查询代价等信息，决定对应的数据是否存储于缓存中，在进行联机分析处理时，能够减少在查询代价高的子查询计划对应的数据上所花的数据读写时间，提高查询性能。
举个例子，利用查询频度和计算规模这两个代价因素建立代价模型，可以通过以下计算公式分别计算得到每一个所述子查询计划的查询代价：
Query_Cost=a*查询频度+（1-a）*计算规模，其中，Query_Cost表示查询代价，a表示预设的加权因子。例如，a=0.4。即，查询代价=0.4*查询频度+0.6*计算规模。
在数据仓库中记录XX公司各年各月的销售额数据，记录的数据如表2-表4所示：
表2
| 时间编号 | 年度 | 季度 | 月份 |
| 20120106 | 2012 | 2012.1 | 2012.1 |
| 20120107 | 2012 | 2012.1 | 2012.1 |
| … | … | … | … |
| 20121226 | 2012 | 2012.4 | 2012.12 |
表3
| 产品编号 | 子公司 | 部门 |
| 9-002 | Co.A | Dep.A |
| 9-003 | Co.B | Dep.B |
| … | … | … |
| 9-012 | Co.H | Dep.J |
表4
| 时间编号 | 产品编号 | 销售额 |
| 20120106 | 9-002 | 100.00 |
| 20120107 | 9-003 | 120.00 |
| … | … | … |
| 20121226 | 9-012 | 122.00 |
用户可以查询具体年、月、子公司、部门的销售额，也可以查询年度、季度、子公司的累积结果等等。
图3是采用树形结构的子计划数据库的示意图，如图3所示，用树形结构的每个节点代表一个子计划，树形结构中上层节点所代表的查询计划的计算规模依赖于其下层节点的数目。图中最上层节点Y表示年度统计的总销售额，第二层节点表示按季度统计的总销售额，第三层节点表示按月统计的销售额。以Q1节点为例，其结果需要从M1、M2、M3的月度销售结果聚合得到因此Q1的计算规模等于3，同理Y节点和Q、M等其他节点。
子查询计划可以采用如图3所示的树形结构来管理子计划数据库，对于子查询计划Y为按年度统计总销售额，计算规模为4，子查询计划Q为按季度统计总销售额，计算规模为3，子查询计划M为按月统计总销售额，计算规模为30。假设子计划数据库中记录的子查询计划Y、Q、M的查询频度分别为10、3和1。根据公式：查询代价=0.4*查询频度+0.6*计算规模，可以计算得到子查询计划Y的查询代价是6.4，子查询计划Q的查询代价是3，子查询计划M的查询代价是18.4。
根据计算得到的查询代价，选择较高的子查询计划M和Q对应的数据存储于缓存中，即将下表5和表6的数据存储于缓存中。
表5
| 年度 | 销售额 |
| 2012 | 2300.00 |
表6
| 月度 | 销售额 |
| 2012.1 | 450.00 |
| 2012.2 | 550.00 |
| 2012.3 | 550.00 |
| … | … |
| 2012.12 | 350.00 |
再举个例子，利用数据规模、存储介质、计算规模和查询频度这几个代价因素建立代价模型，可以通过以下计算公式分别计算得到每一个所述子查询计划的查询代价：
Query_Cost=数据规模+（存储介质+计算规模）*查询频度，其中，Query_Cost表示查询代价。
在数据仓库中记录XX公司各年各月的销售额数据如表7所示，在闪存Flash中记录的数据如表8所示：
表7
| 月度 | 子公司A销售额 |
| 2012.1 | 450.00 |
| 2012.2 | 550.00 |
| … | … |
| 2012.12 | 850.00 |
表8
| 时间编号 | 子公司 | 销售额 |
| 1 | B | 98 |
| 2 | B | 108 |
| … | … | … |
| 12 | G | 230 |
用户输入的查询计划如下表9所示：
表9
| 用户查询计划 |
| 1、子公司A销售额超过100的月份 |
| 2、子公司A二、三季度销售额比 |
| 3、4月份各子公司的销售额 |
将查询计划分成若干个子查询计划，例如，对于查询计划1：子公司A销售额超过100的月份，可以分解为子查询计划（a）子公司A每个月的销售额。查询计划2：子公司A二、三季度销售额比，可以分解为：子查询计划（a）子公司A每个月的销售额、（b）子公司A二季度销售额和（c）子公司A三季度销售额。查询计划3：4月份各子公司的销售额，分解为：子查询计划（a）子公司A每个月的销售额和（d）其他子公司各月份的销售额。
进而确定各子查询计划的查询代价。根据已保存的子计划数据库中子查询计划的信息以及代价模型计算得到各子查询计划的查询代价。
子计划数据库可以采用列表形式存储子查询计划的信息。采用列表形式的子计划数据库如下表10所示：
表10
通过计算可以得到，子查询计划a的查询代价是42、子查询计划b的查询代价是13、子查询计划c的查询代价是13、子查询计划d的查询代价是39。
将查询代价较高的子查询计划a和d对应的数据存储在缓存中，如下表11和表12所示：
表11
| 季度 | 子公司A销售额 |
| 2 | 890.00 |
| 3 | 950.00 |
表12
| 月度 | 子公司A销售额 |
| 2012.1 | 450.00 |
| 2012.2 | 550.00 |
| … | … |
| 2012.12 | 850.00 |
另外，在进行联机分析处理过程时，在S104之后，本发明数据处理方法还包括返回查询数据的步骤，具体包括：确定所述多个子查询计划对应数据的存储位置，从所述存储位置中获取对应数据，生成数据处理结果。
从所述存储位置中获取对应数据，包括：从外部数据仓库或者缓存或其他存储介质中获取对应数据。
本发明实施例提供的数据处理方法，通过引入代价模型评估子查询计划的代价成本，根据代价成本选择可以带来最大收益的缓存数据，可以提高了缓存数据的有效性和命中率，从而提高了In Memory OLAP的查询性能。
以上是对本发明所提供的数据处理方法进行的详细描述，下面对本发明提供的数据处理装置进行详细描述。
实施例二
图4是本实施例提供的数据处理装置示意图，如图4所示，本发明的数据处理装置包括：查询计划处理器101、查询计划解析器102、子计划管理器103、代价管理器104和数据管理器105。
查询计划处理器101用于获取数据查询请求，根据所述数据查询请求生成查询计划。
查询计划处理器101为数据处理装置的输入端，接收用户通过用户数据查询接口输入的数据查询请求。每一个数据查询请求对应为一个查询计划。例如，用户请求查询的数据为子公司A xx年的销售额，则联机分析处理设备接收到该数据查询请求，生成对应的查询计划为：子公司A xx年的销售额。
查询计划处理器101对于数据仓库中已有的用户查询数据，也可以利用本实施例的装置逐一对已有的用户查询数据进行处理，每一个数据查询请求对应为一个查询计划。
查询计划解析器102用于将查询计划处理器101生成的所述查询计划分解成多个子查询计划。
查询计划解析器102将查询计划的中间结果数据对应为子查询计划，将查询计划分解为若干子查询计划。例如，查询计划为子公司A二、三季度销售额比，可以分解为：子公司A每个月的销售额、子公司A二季度销售额以及子公司A三季度销售额。
子计划管理器103用于将子查询计划的信息存储于子计划数据库中。
子计划数据库中保存的子查询计划的信息可以但不限于包括：所述子查询计划、所述子查询计划对应数据的键key索引、所述子查询计划的查询代价、所述子查询计划的代价因素、所述子查询计划对应的数据的存储位置，以及所述子查询计划与其他子查询计划的依赖关系。
代价管理器104用于根据子计划管理器的子计划数据库中已保存的子查询计划的信息，确定查询计划解析器102得到的所述多个子查询计划的查询代价，并将所述子查询计划的查询代价存储于所述子计划数据库中。
代价管理器104根据代价模型计算得到所述多个子查询计划的查询代价。
所述代价模型为代价因素的计算表达式，所述代价因素可以但不限于包括：数据规模、查询频度、计算规模、存储介质和算法执行时间等。其中，数据规模是子查询计划对应的数据量，查询频度是子查询计划累计的被查询次数，计算规模是得到子查询计划对应的数据所需的下一层数据的数量，存储介质是子查询计划对应的数据的存储位置，算法执行时间是得到子查询计划对应的数据所需的时间。利用这些代价因素确定代价模型，通常还需要对非数值型的代价因素进行权值的量化设定。
以存储介质这一代价因素为例，一般来说，不同存储设备的数据读写速度的关系通常是Memory>FLASH>SSD>Disk>数据仓库，在Memory中的读写速度最快，在数据仓库的最慢，因而，设定量化的权值如下表1所示。相类似的，也可以对其他非数值型的代价因素进行权值的量化设定，用以通过代价模型的计算表达式计算得到查询代价的数值。
可选的，代价管理器104根据实际应用场景选择需要考虑的代价因素，以构成的查询代价的计算表达式，用来衡量子查询计划的查询代价成本。
另外，代价管理器104还可以通过代价模型配置接口接收用户配置的信息，以供用户灵活调整代价模型的计算表达式和代价因数。例如，可以选择所要考虑的代价因素或调整代价因素的权重，以修改代价评估标准形成合理的代价模型，从而调整缓存数据刷新结果。
子计划管理器103将代价管理器104子得到的查询计划的信息更新或存储到子计划数据库中。
其中，子查询计划的信息可以但不限于包括：所述子查询计划、所述子查询计划对应数据的键key索引、所述子查询计划的查询代价、所述子查询计划的代价因素、所述子查询计划对应的数据的存储位置，以及所述子查询计划与其他子查询计划的依赖关系等等。
子计划管理器103中的子计划数据库可以但不限于以树形结构或列表形式等存储子查询计划的信息。
子计划管理器103利用子计划数据库来管理和记录每个子查询计划对应数据的key索引、查询代价、代价因素和数据是否缓存，并维护子计划之间的依赖关系，用以根据保存的子查询计划的查询代价等信息，决定对应的数据是否存储于缓存中，在进行联机分析处理时，能够减少在查询代价高的子查询计划对应的数据上所花的数据读写时间，提高查询性能。
数据管理器105用于将所述多个子查询计划中查询代价满足预设条件的子查询计划对应的数据存储于缓存中。
数据管理器105将子计划管理器103中子查询计划的查询代价与缓存中已存储的子查询计划的查询代价进行排序，将查询代价满足预设条件的子查询计划对应的数据存储于缓存中，将剩余的所述查询代价不满足预设条件的子查询计划对应的数据存储到外部数据仓库中。
所述查询代价满足预设条件包括：所述查询代价排在前N个，N为预设正整数；或者，所述查询代价超过预设代价阈值。
数据管理器105将高代价的子查询计划对应的数据缓存在内存中，而将低代价的子查询计划对应的数据从缓存中移除。
数据管理器105还用于确定查询计划解析器102得到的所述子查询计划对应数据的存储位置，从所述存储位置中获取对应数据，生成数据处理结果。
从所述存储位置中获取对应数据，包括：从外部数据仓库或者缓存或其他存储介质中获取对应数据。
利用子计划数据库来管理和记录每个子查询计划对应数据的key索引、查询代价、代价因素和数据是否缓存，并维护子计划之间的依赖关系，用以根据保存的子查询计划的查询代价等信息，决定对应的数据是否存储于缓存中，在进行联机分析处理时，能够减少在查询代价高的子查询计划对应的数据上所花的数据读写时间，提高查询性能。
本发明实施例提供的数据处理装置，通过引入代价模型评估子查询计划的代价成本，根据代价成本选择可以带来最大收益的缓存数据，可以提高了缓存数据的有效性和命中率，从而提高了In Memory OLAP的查询性能。
实施例三
图5是本实施例提供的联机分析处理设备的结构示意图，如图5所示，本发明联机分析处理设备包括：处理器501、网络接口502、内存503、其他存储设备504以及用于连接和通信的数据总线505。
处理器501可能为单核或多核中央处理单元（Central Processing Unit，CPU），或者为特定集成电路（Application Specific Integrated Circuit，ASIC），或者为被配置成实施本发明实施例的一个或多个集成电路。
网络接口502用于与数据仓库或网络进行交互。
其他存储设备504可以但不限于包括：闪存FLASH、硬盘Disk、固态硬盘SSD等。其他存储设备504或内存503中具有软件模块和设备驱动程序。软件模块能够执行本发明上述方法的各种功能模块；设备驱动程序可以是网络和接口驱动程序。
在启动时，这些软件组件被加载到其他存储设备504或内存503中，然后被处理器501访问并执行如下指令：
获取数据查询请求，根据所述数据查询请求生成查询计划；
将所述查询计划分解成多个子查询计划；
根据子计划数据库中已保存的子查询计划的信息，确定所述多个子查询计划的查询代价；
将所述多个子查询计划中查询代价满足预设条件的子查询计划对应的数据存储于内存503中。
具体地，本发明的联机分析处理设备还根据所述指令执行实施例一中所述的数据处理方法，具体在此不再赘述。
本发明提供的数据处理方法及装置，通过考虑子查询计划数据的存储介质、查询频度和计算规模等因素，评估子查询计划的代价成本，在缓存空间有限的情况下，选择高代价查询计划对应的数据缓存在内存中，可以带来最大收益的缓存数据，可以提高了缓存数据的有效性和命中率，从而提高了In Memory OLAP的查询性能。
专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (14)
1.一种数据处理方法，其特征在于，所述方法包括：
获取数据查询请求，根据所述数据查询请求生成查询计划；
将所述查询计划多层次分解为多个子查询计划；
根据子计划数据库中已保存的子查询计划的信息，确定所述多个子查询计划的查询代价；
将所述多个子查询计划中查询代价满足预设条件的子查询计划对应的数据存储于缓存中；
其中，所述根据子计划数据库中已保存的子查询计划的信息，确定所述多个子查询计划的查询代价，包括：
根据代价模型计算得到所述多个子查询计划的查询代价，所述代价模型为所述子计划数据库中已保存的子查询计划的信息中的代价因素的计算表达式；
所述代价因素包括以下所列中的一种或任意结合：
数据规模、查询频度、计算规模和存储介质。
2.根据权利要求1所述的方法，其特征在于，所述根据代价模型计算得到所述多个子查询计划的查询代价，包括：
根据以下计算公式分别计算得到每一个所述子查询计划的查询代价：
Query_Cost＝a*查询频度+(1-a)*计算规模，其中，Query_Cost表示查询代价，a表示预设的加权因子。
3.根据权利要求1所述的方法，其特征在于，所述根据代价模型计算得到所述多个子查询计划的查询代价，包括：
根据以下计算公式分别计算得到每一个所述子查询计划的查询代价：
Query_Cost＝数据规模+(存储介质+计算规模)*查询频度，其中，Query_Cost表示查询代价。
4.根据权利要求1所述的方法，其特征在于，所述查询代价满足预设条件包括：
所述查询代价排在前N个，N为预设正整数；
或者，所述查询代价超过预设代价阈值。
5.根据权利要求1所述的方法，其特征在于，在将所述多个子查询计划中查询代价满足预设条件的子查询计划对应的数据存储于缓存中之后，还包括：
将所述多个子查询计划的信息更新或存储到所述子计划数据库中；
所述多个子查询计划的信息包括以下所列中的一种或任意结合：
所述子查询计划、所述子查询计划对应数据的键key索引、所述子查询计划的查询代价、所述子查询计划的代价因素、所述子查询计划对应的数据的存储位置，以及所述子查询计划与其他子查询计划的依赖关系。
6.根据权利要求5所述的方法，其特征在于，所述子计划数据库以树形结构或列表形式存储所述子查询计划的信息。
7.根据权利要求1所述的方法，其特征在于，在将所述查询计划分解成多个子查询计划之后，还包括：
确定所述多个子查询计划对应数据的存储位置，从所述存储位置中获取对应数据，生成数据处理结果。
8.一种数据处理装置，其特征在于，所述装置包括：查询计划处理器、查询计划解析器、子计划管理器、代价管理器和数据管理器；
所述查询计划处理器，用于获取数据查询请求，根据所述数据查询请求生成查询计划；
所述查询计划解析器，用于将所述查询计划处理器生成的所述查询计划分层次分解为多个子查询计划；
所述子计划管理器，用于将子查询计划的信息存储于子计划数据库中；
所述代价管理器，用于根据所述子计划管理器的子计划数据库中已保存的子查询计划的信息，确定所述查询计划解析器得到的所述多个子查询计划的查询代价，并将所述多个子查询计划的查询代价存储于所述子计划数据库中；
所述数据管理器，用于将所述多个子查询计划中查询代价满足预设条件的子查询计划对应的数据存储于缓存中；
其中，所述代价管理器具体用于根据代价模型计算得到所述子查询计划的查询代价，所述代价模型为所述子计划管理器的子计划数据库中已保存的子查询计划的信息中的代价因素的计算表达式；
所述代价因素包括以下所列中的一种或任意结合：
数据规模、查询频度、计算规模和存储介质。
9.根据权利要求8所述的装置，其特征在于，所述代价管理器具体用于根据以下计算公式分别计算得到每一个所述子查询计划的查询代价：
Query_Cost＝a*查询频度+(1-a)*计算规模，其中，Query_Cost表示查询代价，a表示预设的加权因子。
10.根据权利要求8所述的装置，其特征在于，所述代价管理器具体用于根据以下计算公式分别计算得到每一个所述子查询计划的查询代价：
Query_Cost＝数据规模+(存储介质+计算规模)*查询频度，其中，Query_Cost表示查询代价。
11.根据权利要求8所述的装置，其特征在于，所述查询代价满足预设条件包括：
所述查询代价排在前N个，N为预设正整数；
或者，所述查询代价超过预设代价阈值。
12.根据权利要求8所述的装置，其特征在于，所述子计划管理器还用于更新或存储所述多个子查询计划的信息到所述子计划数据库中；
所述多个子查询计划的信息包括以下所列中的一种或任意结合：
所述子查询计划、所述子查询计划对应数据的键key索引、所述子查询计划的查询代价、所述子查询计划的代价因素、所述子查询计划对应的数据的存储位置，以及所述子查询计划与其他子查询计划的依赖关系。
13.根据权利要求12所述的装置，其特征在于，所述子计划管理器将所述子查询计划的信息以树形结构或列表形式存储到所述子计划数据库。
14.根据权利要求8所述的装置，其特征在于，所述数据管理器还用于确定所述查询计划解析器得到的所述多个子查询计划对应数据的存储位置，从所述存储位置中获取对应数据，生成数据处理结果。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310260406.9A CN103324724B (zh) | 2013-06-26 | 2013-06-26 | 数据处理方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310260406.9A CN103324724B (zh) | 2013-06-26 | 2013-06-26 | 数据处理方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103324724A CN103324724A (zh) | 2013-09-25 |
| CN103324724B true CN103324724B (zh) | 2017-02-08 |
Family
ID=49193467
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201310260406.9A Active CN103324724B (zh) | 2013-06-26 | 2013-06-26 | 数据处理方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103324724B (zh) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9092482B2 (en) | 2013-03-14 | 2015-07-28 | Palantir Technologies, Inc. | Fair scheduling for mixed-query loads |
| US8504542B2 (en) | 2011-09-02 | 2013-08-06 | Palantir Technologies, Inc. | Multi-row transactions |
| CN103729471B (zh) * | 2014-01-21 | 2017-03-08 | 华为软件技术有限公司 | 数据库查询方法和装置 |
| CN103995879B (zh) * | 2014-05-27 | 2017-12-15 | 华为技术有限公司 | 基于olap系统的数据查询方法、装置及系统 |
| CN104408065A (zh) * | 2014-10-29 | 2015-03-11 | 中国建设银行股份有限公司 | 一种联机查询交易信息的方法及装置 |
| CN106156162A (zh) * | 2015-04-15 | 2016-11-23 | 阿里巴巴集团控股有限公司 | 数据库查询量统计方法和设备 |
| US10031940B2 (en) | 2015-09-24 | 2018-07-24 | Futurewei Technologies, Inc. | System and method for database query |
| CN106708838A (zh) * | 2015-11-12 | 2017-05-24 | 华为技术有限公司 | 用于流数据查询的方法和装置 |
| CN107025240A (zh) * | 2016-02-01 | 2017-08-08 | 国家超级计算深圳中心(深圳云计算中心) | 一种语义网络中本体查询的缓存方法及系统 |
| CN107402926B (zh) * | 2016-05-18 | 2021-02-23 | 华为技术有限公司 | 一种查询方法以及查询设备 |
| CN108664516A (zh) * | 2017-03-31 | 2018-10-16 | 华为技术有限公司 | 查询优化方法及相关装置 |
| CN109241093B (zh) * | 2017-06-30 | 2021-06-08 | 华为技术有限公司 | 一种数据查询的方法、相关装置及数据库系统 |
| CN107729500B (zh) * | 2017-10-20 | 2021-01-05 | 锐捷网络股份有限公司 | 一种联机分析处理的数据处理方法、装置及后台设备 |
| CN110196863B (zh) * | 2018-05-04 | 2022-10-18 | 腾讯科技（深圳）有限公司 | 数据处理方法、装置、计算设备及存储介质 |
| CN110737727B (zh) * | 2018-07-19 | 2023-09-29 | 华为云计算技术有限公司 | 一种数据处理的方法及系统 |
| CN110263105B (zh) * | 2019-05-21 | 2021-09-10 | 北京百度网讯科技有限公司 | 查询处理方法、查询处理系统、服务器和计算机可读介质 |
| WO2021007816A1 (en) * | 2019-07-17 | 2021-01-21 | Alibaba Group Holding Limited | Method and system for generating and executing query plan |
| CN111143464B (zh) * | 2019-12-10 | 2023-07-18 | 北京字节跳动网络技术有限公司 | 数据获取方法、装置和电子设备 |
| CN111666279B (zh) * | 2020-04-14 | 2022-04-29 | 阿里巴巴集团控股有限公司 | 查询数据处理方法、装置、电子设备及计算机存储介质 |
| CN113656437B (zh) * | 2021-07-02 | 2023-10-03 | 阿里巴巴新加坡控股有限公司 | 用于预测参照执行代价稳定度的模型构建方法 |
| CN113946600A (zh) * | 2021-10-21 | 2022-01-18 | 北京人大金仓信息技术股份有限公司 | 数据查询方法、装置、计算机设备和介质 |
| CN116662449A (zh) * | 2023-06-14 | 2023-08-29 | 浙江大学 | 基于广播子查询缓存的olap查询优化方法及系统 |
| CN117390064B (zh) * | 2023-12-12 | 2024-03-19 | 天津南大通用数据技术股份有限公司 | 一种基于可嵌入子图的数据库查询优化方法 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6601062B1 (en) * | 2000-06-27 | 2003-07-29 | Ncr Corporation | Active caching for multi-dimensional data sets in relational database management system |
| CN1588358A (zh) * | 2004-08-26 | 2005-03-02 | 陈红 | 对mdx多维数据查询语句的处理方法和系统 |
| US6898603B1 (en) * | 1999-10-15 | 2005-05-24 | Microsoft Corporation | Multi-dimensional data structure caching |
| CN101008954A (zh) * | 2007-01-30 | 2007-08-01 | 金蝶软件（中国）有限公司 | 联机分析处理系统中多维表达式数据缓存的方法和装置 |
| CN101093501A (zh) * | 2007-07-31 | 2007-12-26 | 武汉大学 | 一种高效、透明的分布式空间数据库查询方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9135299B2 (en) * | 2009-09-01 | 2015-09-15 | Teradata Us, Inc. | System, method, and computer-readable medium for automatic index creation to improve the performance of frequently executed queries in a database system |
-
2013
- 2013-06-26 CN CN201310260406.9A patent/CN103324724B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6898603B1 (en) * | 1999-10-15 | 2005-05-24 | Microsoft Corporation | Multi-dimensional data structure caching |
| US6601062B1 (en) * | 2000-06-27 | 2003-07-29 | Ncr Corporation | Active caching for multi-dimensional data sets in relational database management system |
| CN1588358A (zh) * | 2004-08-26 | 2005-03-02 | 陈红 | 对mdx多维数据查询语句的处理方法和系统 |
| CN101008954A (zh) * | 2007-01-30 | 2007-08-01 | 金蝶软件（中国）有限公司 | 联机分析处理系统中多维表达式数据缓存的方法和装置 |
| CN101093501A (zh) * | 2007-07-31 | 2007-12-26 | 武汉大学 | 一种高效、透明的分布式空间数据库查询方法 |
Non-Patent Citations (2)
| Title |
|---|
| Cost-Aware Strategies for Query Result Caching in Web Search Engines;FIFAT OZCAN等;《ACM Transactions on the Web》;20110531;第1-25页 * |
| 基于语义缓存的并行查询技术的设计与实现;孟清;《中国优秀硕士学位论文全文数据库》;20060415;第2.2-2.3、4.1节 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN103324724A (zh) | 2013-09-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103324724B (zh) | 数据处理方法及装置 | |
| Mozafari et al. | Performance and resource modeling in highly-concurrent OLTP workloads | |
| CN104781810B (zh) | 将行和对象数据库活动跟踪到块级热图中 | |
| Liu et al. | Understanding data characteristics and access patterns in a cloud storage system | |
| CN103782295B (zh) | 分布式数据管理系统中的查询说明计划 | |
| CN110362566B (zh) | 分层htap数据库的混合数据布局中的数据布置 | |
| CN107291806A (zh) | 一种Web可视化环境中的数据视图副本迭代方法 | |
| CN102857560B (zh) | 一种面向多业务应用的云存储数据分布方法 | |
| CN104951462B (zh) | 用于管理数据库的方法和系统 | |
| CN108536692A (zh) | 一种执行计划的生成方法、装置及数据库服务器 | |
| US8849744B2 (en) | Inconsistency robustness in scalable OLAP cubes | |
| CN104978324A (zh) | 一种数据处理方法和装置 | |
| Hoque et al. | Disk layout techniques for online social network data | |
| CN106355031A (zh) | 基于层次分析法的数据价值度计算方法 | |
| Amossen | Vertical partitioning of relational OLTP databases using integer programming | |
| CN104035807A (zh) | 一种云存储系统的元数据缓存替换方法 | |
| CN107301249A (zh) | 一种文件访问信息记录方法、系统及分布式集群系统 | |
| That et al. | TRIFL: A generic trajectory index for flash storage | |
| On et al. | FD-Buffer: A cost-based adaptive buffer replacement algorithm for flashmemory devices | |
| US7117218B2 (en) | System and method for expressing and calculating a relationship between measures | |
| CN106354433B (zh) | 分布式内存存储系统的热点数据挖掘方法及装置 | |
| JP2005018751A5 (zh) | ||
| Bullat et al. | Dynamic clustering in object databases exploiting effective use of relationships between objects | |
| Li et al. | Optimizing nonindexed join processing in flash storage-based systems | |
| Bonnet et al. | System co-design and data management for flash devices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |