CN114925086A - 自服务数据平台 - Google Patents

Abstract

本发明公开了一种自服务数据平台，包括由服务器计算机(或集群)执行的方法，所述的方法包括接收查询并基于接收到的查询定义查询计划。查询计划是指数据源中包含的数据集；还包括基于包含在存储器中的优化数据结构确定接收到的查询可以被加速，其中优化数据结构是从查询计划中引用的数据集导出的；还包括修改查询计划以包括优化的数据结构，并且执行修改的查询计划以通过读取优化的数据结构代替从数据源读取至少一些数据来获得满足接收到的查询的查询结果。本发明使用户能够发现、管理、加速和分析来自一个或多个数据源的数据。

Description

自服务数据平台

技术领域

本发明涉及的是及一种数据平台，具体涉及一种自服务数据平台，更具体地是涉及一种自助数据平台。

背景技术

传统的数据分析系统可以收集、分析和处理已经包含的数据数据。数据源可以是与数据分析系统相关的内部、外部、本地或远程计算设备。例如，外部远程数据源可以是通过计算机网络连接到数据分析系统的服务器。现有的数据分析系统有许多缺点。它们专为信息技术(IT)专业人士而非最终用户设计。系统的职责是使用提取、转换和加载(ETL)管道从数据源中提取数据，并将提取的数据存储到集中的数据仓库或数据湖中去。这些系统是不够的，因为它们只提供部分和陈旧的数据用于查询和分析。

分析师通常花费大量时间来收集和准备数据，而不是使用商业智能(BI)工具去分析数据。具有分析或可视化功能的BI工具示例包括TABLEAU、POWER BI、R或PYTHON。这些工具主要对驻留在单个小型关系数据库中的数据进行操作。但是，现代组织使用非关系数据源，例如HADOOP、云存储(例如S3、阿里云OSS)和NOSQL数据库(例如MONGODB、ELASTICSEARCH)。

此外，数据通常分布在不同的数据源上，使得用户不能简单地将BI工具连接到任意数据源组合。连接机制往往太慢，查询经常失败，原始数据量太大或太复杂，数据往往是混合类型的。此外，寻求灵活访问数据分析系统的用户通常会绕过安全措施，将数据下载或提取到不安全、不受监管的系统中(如电子表格、独立数据库和BI服务器)以便进行后续分析。因此，用户寻求访问、探索和分析来自分布式数据源的大量混合数据的能力并且不受主要面向IT专业人士的僵化数据分析系统的束缚。

发明内容

针对现有技术上存在的不足，本发明目的是在于提供一种自服务数据平台，使用户能够发现、管理、加速和分析来自一个或多个数据源的数据。

为了实现上述目的，本发明是通过如下的技术方案来实现：自服务数据平台，包括由服务器计算机(或集群)执行的方法，所述的方法包括接收查询并基于接收到的查询定义查询计划。查询计划是指数据源中包含的数据集；还包括基于包含在存储器中的优化数据结构确定接收到的查询可以被加速，其中优化数据结构是从查询计划中引用的数据集导出的；还包括修改查询计划以包括优化的数据结构，并且执行修改的查询计划以通过读取优化的数据结构代替从数据源读取至少一些数据来获得满足接收到的查询的查询结果。

所述的方法还包括：在接收查询之前，生成优化的数据结构包括至少一个数据集的原始数据，生成优化的数据结构包括数据列的聚合至少一个数据集的数据结构，生成优化的数据结构包括至少一个数据集的数据列的排序、分区或分布式数据中的至少一种，和/或生成优化的数据结构包括从至少一个数据集中采样的数据。

所述的接收到的查询是第二查询并且查询结果是第二查询结果；所述的方法还包括：在接收第二查询之前，基于满足第一查询的第一查询结果生成优化数据结构；查询计划是第二查询计划，并且第一查询计划被定义为具有比获得满足第一查询的查询结果所需的范围更广的范围，使得生成的优化数据结构比基于查询计划生成的优化数据结构更广；基于查询计划的范围，该范围至少足以获得满足第一个查询的查询结果。

所述的查询结果是在不读取数据源中包含的任何数据集的情况下获得的，或者除了读取优化的数据结构之外，还通过读取数据源中包含的至少一些数据集来获得查询结果。

所述的方法还包括在确定接收到的查询可以被加速之前自主决定生成优化的数据结构。在一些实施例中，生成优化数据结构的决定基于由服务器计算机(或集群)接收的查询的历史和/或基于读取优化数据结构代替来自数据源的至少一些数据，从而优化和提升系统的工作负载。

所述的方法还包括，在接收查询之前，接收用户对数据集的一个或多个数据集的加速查询需求，并响应接收到的需求生成优化的数据结构。

所述的方法还包括，在接收查询之前，接收定义从数据源中包含的物理数据集导出的虚拟数据集的用户输入，其中数据集包括虚拟数据集。

所述的修改的查询计划仅由计算机服务器(或集群)的分布式查询引擎执行。

所述的自服务数据平台还包括计算机系统，计算机系统包括处理器和指令存储器，当由处理器执行这些指令时，这些指令会使计算机系统连接到包含物理数据集的数据源，并显示可视化数据集编辑器，并允许用户通过使用可视化数据集编辑器创建从物理数据集派生的虚拟数据集来整理数据，而无需创建整理数据的任何物理副本。

所述的虚拟数据集被公开为客户端应用程序中的虚拟表，使计算机系统允许用户通过可视化数据集编辑器共享虚拟数据集。

所述的可视化数据集编辑器包括控件，当用户选择该控件时，该控件使计算机系统打开连接到虚拟数据集的客户端应用程序。

所述的计算机系统显示物理数据集和虚拟数据集之间的关系的可视化。

所述的计算机系统基于数据源中包含的物理数据集自主地决定生成优化的数据结构，并将优化的数据结构存储在存储器中，其中，优化的数据结构加速了查询的执行，该查询涉及物理数据集或从物理数据集派生的虚拟数据集。

本发明的有益效果：本发明能够使得用户寻求访问、探索和分析来自分布式数据源的大量混合数据的能力并且不受主要面向IT专业人士的僵化数据分析系统的束缚。

附图说明

下面结合附图和具体实施方式来详细说明本发明；

图1A、图1B、图1C为本发明从数仓系统到自助服务分析系统的演进框架图；

图2为本发明用于执行数据分析的自助数据平台的特征的框图；

图3为本发明的用于自助数据平台的高级数据流的框图；

图4为本发明的基于查询、虚拟数据集和物理数据集之间的关系图；

图5为本发明的自助服务平台的过程的流程图；

图6为本发明的自助数据平台的加速系统的框图；

图7A为本发明的用于自助数据平台交互显示的视图；

图7B为本发明的用于自助数据平台交互显示的另一视图；

图8为本发明的用于加速查询执行过程的过程流程图；

图9为本发明的计算机系统的示意图。

具体实施方式

为使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合具体实施方式，进一步阐述本发明。

参照图1A、图1B图1C，本具体实施方式采用以下技术方案：自服务数据平台：图1A到图1B展示了数据分析系统从以IT为中心到自助服务系统的演进的框图。图1A，以IT为中心的架构包括提取、转换和加载(ETL)工具，从数据源提取数据并将提取的数据存储在数据仓库中，并可使用商业智能(BI)工具来查询数据仓库。图1B，修改图1A的中间架构，将图1A数据仓库改为数据仓库和数据湖(例如HADOOP或云存储)，中间架构包括一个ETL工具，但为最终用户提供自助服务BI工具，而不是专门为IT人员提供的BI工具。最后，图1C展示了从图1B的中间架构修改而来的自助服务架构，它通过使用自助数据平台替换ETL工具和数据仓库或替代存储。

本具体实施方式的自助服务数据平台，具有用于在不同环境中使用的自助服务分析能力。该平台使实体(例如，组织、用户、分析师、数据科学家)能够随时发现、管理、探索和分析来自不同数据源的不同数据，避免花费过多时间收集或准备数据。图2展示了用于执行数据分析的平台的特征框图。如图2所示：平台耦合了众多数据源和分析/可视化工具。在此示例中，该平台在1-1,000+台服务器上运行，将分析和可视化工具连接到众多数据源。数据源的例子包括NOSQL源(如MONGODB、CASSANDR)、搜索源(如ELASTICSEARCH)、文件存储源(如HDFS、NAS、LINUX CLUSTER、EXCEL/CSV)、云计算(如、IaaS、PaaS、SaaS)源(例如，ALI OSS、AMAZON S3、ICEBERG)、关系源(例如，MySQL、SQL server)和SaaS源(例如，GITHUB等)。分析或可视化工具的示例包括分析中心(例如，自助服务门户)、通过ODBC/JDBC的BI工具(例如，SMART BI、TABLEAU、POWER BI)、数据科学工具(例如，R、PYTHON)和通过REST的自定义应用程序。因此，分析/可视化工具的用户可以很容易地查询和分析来自众多数据源的数据。

如图3所示的平台的高级数据流300的框图。数据流开始于连接过程302，该连接过程将平台连接到获得数据的数据源。所获得的数据经过数据准备/预处理过程304。在某些情况下，获得的数据可以经过管理或探索过程，允许用户管理、探索和/或共享准备好的数据。此外，平台可以根据获得的数据创建优化的数据结构。下面进一步提供优化数据结构的描述，用户可以使用管理和探索过程304来编辑优化的数据结构以改进后续查询执行，准备好的数据可以响应于查询执行而经历分析或可视化过程306。例如，可以使用BI工具来做查询数据的可视化，在一些情况下，后续的查询执行可以经历加速过程308以基于优化的数据结构快速获得查询结果，数据流可以根据需要在准备过程304、分析或可视化过程306与加速过程308之间循环，以优化平台执行的数据分析的结果。

平台的自助服务功能可以提高用户体验。自助服务功能的示例涉及数据管理和准备、与不同数据源的集成、处理动态模式、数据集命名空间和路径结构、展示数据集信息、数据智能、用户定义的数据安全性、用于加速查询执行的内存管理以及BI工具启动器，下面更详细地描述了该平台的自助服务功能。

平台可以处理来自多种数据源的多种数据类型。例如，该平台可以连接到非关系数据源、关系数据库、数据仓库和电子表格来收集数据以响应查询。例如，平台可以连接到传统无法查询的数据源，包括NOSQL数据库(例如MONGODB、ELASTICSEARCH)、云存储(例如，AMAZON S3、ALI OSS)和HADOOP(例如HDFS)。该平台可以连接到这些数据源的组合，并同时或异步查询来自这些数据源的数据。

平台可以具有灵活的数据连接能力。它不需要定义模式、数据模型或ETL来查询数据源。在此使用的模式可以是整个数据存储的逻辑视图的结构。它定义了数据的组织方式以及数据之间的关系如何关联。如这里所使用的，数据模型可以指在数据库管理系统中引入抽象的基本实体，数据模型可以定义数据如何相互连接以及它们如何在系统内处理和存储。这里使用的ETL是指从源系统中提取数据并将其放入数据仓库或任何其他系统的过程。

平台支持全范围的结构化查询语言(SQL)命令。SQL是一种特定语言，通常用于与数据库管理系统进行交互。在这种情况下，可以使用SQL命令来指定所需的查询，SQL命令的示例包括复杂连接、相关子查询和窗口函数。

平台知道数据源和它们的自身能力，使得它可以采用数据源的查询过程。例如，平台可以将自由文本搜索下推到ELASTICSEARCH，因为它知道此特定数据源支持自由文本搜索。平台可启用TABLEAU、EXCEL、R等工具查询数据源中的数据。

该平台可以具有广泛的数据准备能力。例如，该平台可以使用实时数据或虚拟数据进行实时数据准备。该平台还可以包括一个虚拟数据集编辑器，使最终用户能够准备虚拟数据集。与现有系统不同，平台准备好的数据存在于虚拟数据集中，因此不需要数据集的物理副本。

该平台可以提供企业级的安全和治理能力，以及消费者级的易用性。这包括多功能和直观的访问控制机制。例如，用户可以决定谁可以在粒度级别访问哪些数据。用户甚至可以对用户或组隐藏一些数据。该平台还可以保持血缘分析能力。也就是说，数据集是连接或处理的，用户可以浏览每个数据集和列的祖先和后代。该平台还可以具有审计功能，允许用户监控谁正在访问数据并确定数据被访问的时间。在一些实施例中，该平台可以生成实时报告，例如显示给定数据集的前10名用户或在非工作时间访问数据集。

该平台可以提供更好的性能和可扩展性。该平台可以允许用户与来自不同数据源的各种类型和任何规模的数据进行交互。平台可以通过使用优化的数据结构来加速查询执行，这里也称为反射，其可以驻留在内存中或持久存储上。因此，与现有系统相比，该平台可以提供数量级的查询加速和生产系统隔离。该平台还可以执行列式内存分析，包括列式执行、字节码重写和运行时编译。在一些实施例中，这种分析是在APACHEARROW中实现的。

该平台可以支持多种计算设备。例如，该平台可以使用一个服务器集群，该集群可以扩展到数千台服务器并在本地和/或云中运行。该平台可以集成任意数量的分布式数据存储的数据源。该平台了解数据的分布，并具有查询每个数据源的能力。这最大化有利于SQL下推(例如，RDBMS、MONGODB、ELASTICSEARCH)并允许从分布式数据存储并行读取数据。

管理与准备：本具体实施方式的平台可以被配置为连接到不同的数据源。例如，用户可以为每个数据源输入连接信息。连接信息的示例包括IP地址或域名以及能够访问数据源中包含的数据的凭证。然后平台可以使用连接信息连接到数据源并对数据源的任何数据集运行查询。任何查询都可能包括多个数据集和数据源。

该平台使用户能够发现数据、管理数据、加速查询以及与其他用户共享数据源的数据。该平台可以包括一个统一的数据目录，供用户发现和探索物理或虚拟数据集、数据源以及它们之间的关系。如这里所使用的，“物理数据集”可以指连接到平台的数据源中包含的原始数据。该平台使最终用户能够与这些数据源中包含的物理数据集进行交互。物理数据集可能属于数据源公开的命名空间层次结构。包括关系表、MONGODB集合、文件或文件目录，或者ELASTICSEARCH索引或类型。例如：一个MONGODB数据源可以有一个简单的层次结构，形式如：<cluster>.<database>.<collection>。

该平台使用户能够通过创建虚拟数据集来管理数据。如本文所用，“虚拟数据集”是指由平台用户定义的数据集。虚拟数据集可以源自物理数据集或其他虚拟数据集。平台不需要保存虚拟数据集的实际数据(例如，内容)。相反，平台只需要保存虚拟数据集的定义(例如，类似于数据库视图的SQL中的“SELECT”语句)。

因此，最终用户只需要关心数据集——物理的和虚拟的。该平台可能支持多种点击式转换，用户可以利用SQL语法(或其他支持的语言)来定义更复杂的转换。在执行查询时，平台了解数据，使其能够推荐各种转换，例如连接和数据类型转换。当新添加数据源以及数据源或数据集发生变化时，可以自动更新数据目录。所有元数据都可以在高性能、可搜索的索引中编入索引，并通过平台的门户界面向用户公开。例如，用户可以浏览数据图以了解数据集之间的关系并监控用户对特定数据集的操作。

与直接查询包含在数据源中的数据集相比，该平台可以将查询执行加速几个数量级。例如，平台可以基于物理或虚拟数据集创建优化的数据结构(即反射)。优化后的数据结构可以驻留在内存中，也可以驻留在持久存储上。可以使用优化的数据结构代替直接查询数据源。优化的数据结构可以由平台自主创建、由平台用户手动创建、或者两者结合。也就是说，用户可以手动指定要加速的数据集和/或系统可以决定基于过去的查询和处理查询的工作负载自主创建哪些优化的数据结构。

在一些实施例中，优化的数据结构被锚定到至少一个物理或虚拟数据集。在查询时，使用优化的数据结构可以加速针对任何底层源数据集的查询。在一些实施例中，优化的数据结构基于APACHE PARQUET OR ORC，具有各种周边优化，例如列级统计。优化的数据结构可以基于按特定列排序、分区和分布的数据。

优化的数据结构是存储在平台的自主内存中的对象、物化、数据片段等。内存被称为“自主”是因为平台可以自主决定生成优化的数据结构，这些数据结构存储在自主内存中以用于加速查询。在寻求查询数据源时，最终用户不需要考虑任何优化的数据结构或知道它们的存在。相反，平台使用优化的数据结构来加速查询对用户是透明的。例如，当收到来自BI工具的查询时，平台的“优化器”会确定最佳查询执行计划。

优化的数据结构可以包含任何类型或大小的数据。平台知道优化数据结构的定义，这允许平台刷新优化数据结构的数据的同时，并在查询时确定优化数据结构是否可以加速查询的计算结果。例如，当收到查询时，平台通常必须执行大量的计算工作。满足查询的查询结果不一定存在于数据源或优化的数据结构中。在非加速情况下，从原始数据开始计算并得出最终的查询结果。当存在一种基于优化数据结构计算查询结果的方法时，平台的优化器可以识别并利用优化数据结构的机会。

平台可以基于用户输入或其组合来决定是否自主地生成(即，创建)优化的数据结构。例如，为了便于管理，平台可以将每个优化的数据结构锚定到特定的数据集(物理或虚拟)。这有助于管理员理解优化数据结构包含的内容，并有助于识别数据集上执行速度太慢的查询，以便用户创建执行效率更高的优化数据结构。

本实施例可以包括不同类型的优化数据结构。例如，锚定到单个数据集的优化数据结构可以是原始反射或聚合反射。原始反射包含数据集中的所有记录，但可能只有其中一些数据列，按特定列排序、分区和分布。聚合反射类似于具有维度和度量的OLAP多维数据集的聚合(即汇总)。聚合反射可用于加速聚合查询。

当基于接收查询定义或修改查询计划时，平台确定是否利用优化的数据结构。例如，平台可以编译从客户端设备接收到的SQL命令以定义查询计划。查询计划描述了查询将如何执行，包括计算查询结果所需的所有操作。当平台确定可以使用一个或多个优化的数据结构来加速查询时，平台可以生成查询计划或修改生成的查询计划以利用优化的数据结构而不是直接查询数据源。

该平台可以使用户能够与其他用户和组安全地共享数据(例如，虚拟数据集或查询结果)。例如，一组用户可以在将用于特定分析工作的虚拟数据集上进行协作。或者，用户可以上传自己的数据，例如EXCEL电子表格，以加入其他数据集。在一些实施例中，创建虚拟数据集的用户可以确定哪些其他用户可以查询或编辑这些虚拟数据集。

图4是本实施例的查询402、虚拟数据集404和物理数据集406之间的关系400的框图。物理数据集不能有父数据集，但可以是虚拟数据集的父数据集。一个虚拟数据集也可以是另一个虚拟数据集的父级或子级。该平台知道任何数据集之间的关系，并且可以使用该知识来确定要创建和维护哪些优化的数据结构。因此，这些关系可用于加速查询执行过程。

图4的箭头示出了如何从虚拟数据集404和/或物理数据集406的组合中处理查询402。虚拟数据集404-1是从物理数据集406-1和虚拟数据集404-2的组合中导出的，并且虚拟数据集404-2源自物理数据集406-2和406-3。这样，查询402-1可以从虚拟数据集404-1得到满足。查询402-2可以从虚拟数据集404-1和物理数据集406-3得到满足。最后，可以从虚拟数据集404-2满足查询402-3。

在客户端设备上运行的应用程序可以通过ODBC、JDBC、REST或其他API向平台发出查询。查询可以包括驻留在不同数据源中的一个或多个数据集。例如，查询可能是一个HIVE

表、ELASTICSEARCH索引和几个ORACLE表之间的连接。对数据集的查询通常会通过使用锚定到数据集的优化数据结构来加速。如上所述，优化的数据结构可能涉及原始反射或聚合反射。原始反射可以包括数据集的一列或多列的投影。数据可以排序、分区或分布在数据集的不同列中。聚合反射可以包括数据集的列的聚合。聚合数据集由维度和度量定义，并包含每个度量的聚合级别数据，例如计数、总和、最小值和最大值。数据可以排序、分区和分布在数据集的不同列中。

如上所述，虽然平台可以自主决定并自动生成优化的数据结构，但可能存在用户希望创建自定义优化的数据结构的情况。在这种情况下，该平台允许用户使用SQL命令简单地创建新的优化数据结构，例如，创建包含特定数据集所有列的单个原始反射。

优化数据结构的内容可以被刷新以更新数据或移除陈旧数据。可以手动或自动刷新内容以确保最新数据可用于查询。可以根据完全或增量刷新过程来刷新优化的数据结构。

平台可以维护有向无环图(DAG)，其定义优化的数据结构被刷新的顺序。依赖关系可以从关系代数计算，实际刷新开始时间可以并入至完成刷新周期所需的预期时间量。这种方法减少了端到端的循环时间，以及完成循环所需的计算资源。此外，通过利用一个优化的数据结构来刷新另一个优化的数据结构，平台可以避免在一个刷新周期中多次访问操作数据库。

在一些实施例中，用户可以指定允许在优化的数据结构中使用数据的相对陈旧性。该指定可以是限制相关查询结果数据的阈值。因此，平台可以基于阈值自动确定何时刷新自主存储器中的每个优化数据结构。例如，用户可以通过UI指示相关查询结果最多可以保留8小时。

平台可以考虑将数据结构间的关系带入刷新顺序，以确认哪个数据结构应该被刷新。例如，如果优化的数据结构Y是从优化的数据结构X导出的，则优化的数据结构X可以在优化的数据结构Y之前刷新。此外，平台可以允许用户限制总数、速率、和刷新优化数据结构的时间。例如，可以将刷新操作设置为特定时间窗口(例如，仅夜间)。在一些实施例中，用户可以指定用于刷新优化数据结构的时间表。

在一些实施例中，平台可以基于对数据源做出的任何改变来持续地保持自主存储器是最新的。平台监控新数据的文件目录，或者在数据源运行一个查询，返回新的或更新的记录，这都可以通过使用数据库日志来完成。

平台可以使用多种技术来减少获得查询结果所需的时间和资源。例如，平台可以考虑特定数据源的能力和查询特定数据源的相对计算成本。在一些实施例中，平台可以定义在数据源或平台的分布式执行环境中执行的查询计划，以实现最高效的执行。在另一个示例中，为了生成最有效的整体查询计划，平台可以通过将自主存储器中可用的优化数据结构用于查询的部分来加速查询执行。在很多情况下，查询优化的数据结构比直接查询数据源的查询执行计划有巨大的效率提升。

平台能够将处理下推到关系和非关系数据源中。非关系数据源通常不支持SQL，并且执行能力有限。例如，文件系统不能应用谓词或聚合。另一方面，MONGODB可以应用谓词和聚合，但不支持所有连接。优化器会考虑每个数据源的功能，因此，平台会在最高效的时候将尽可能多的查询推送到底层源，并在其自己的分布式执行引擎中执行其余的查询。

平台可以卸载和保护运营中的数据库。大多数运营中的数据库都是为写优化的工作负载而设计的。此外，部署必须满足严格的服务级别协议(SLA)，任何停机或性能下降都会对业务产生重大影响。因此，操作系统经常与处理分析查询隔离开来。在这些情况下，平台可以使用优化的数据结构来执行分析查询，从而提供最高效的查询处理，同时最大限度地减少对源系统的影响。

本实施例包括用于用户与平台交互的门户。门户可以是用户界面(UI)的网络门户，可以方便用户的数据管理和准备操作。例如，用户可以使用门户的可视化数据集编辑器创建虚拟数据集。门户的示例，例如显示图形UI(GUI)的Web浏览器，包括用于用户提交查询、访问数据集、准备虚拟数据集、接收查询结果等的图形控件。例如，GUI可以包括指向物理数据集和按钮的可点击链接，以启动基于其他数据集的虚拟数据集的创建。

因此，门户可以使用户能够操纵数据集。此外，门户可以显示类似于图4所示的交互式数据图。例如，数据图中的每个节点都可以代表一个数据集，虚拟数据集可以同时具有传入和传出边，而物理数据集只有传出边，因为任何物理数据集都在数据源中。

在一些实施例中，用户可以从数据图中选择节点以编辑底层数据集。例如，用户可以更改列的数据类型、展平嵌套结构、重命名列或将列的一部分提取到新列中。

此外，用户可以选择其他数据集与当前数据集组合。每个这样的转换都会更新转换后的虚拟数据集的定义。在一些实施例中，虚拟数据集的定义可以表示为SQL的“SELECT”语句，用户可以直接编辑定义。一旦用户对生成的数据集感到满意，用户就可以通过为该数据集指定名称和在分层命名空间中的位置来保存虚拟数据集。从那时起，可以从命名的虚拟数据集派生其他虚拟数据集。

在一些实施例中，除了驻留在诸如数据库和文件系统之类的数据源中的物理数据集之外，用户还可以将文件上传到平台。例如，用户可以上传EXCEL电子表格，然后将其作为平台的数据集存储和公开。例如，假设平台连接到具有超大数据集的NOSQL数据库或HADOOP集群。用户可能想要替换一列中的特定值(例如，为了解决数据质量问题)。用户可以上传分别包含旧值和新值两列的EXCEL电子表格，然后创建一个虚拟数据集作为大数据集和EXCEL电子表格之间的连接。

因此，平台的管理和准备特征被设计成使得用户能够自助服务以创建和修改虚拟数据集和/或创建的优化数据结构，而无需专门的技术知识或技能并且无需定义模式.在一些实施例中，用户可以简单地在类似电子表格的界面中进行数据交互。此外，多个用户可以通过建立彼此的虚拟数据集来进行协作。

数据整合：平台可以协调跨越包括本地和远程数据源的不同数据源的查询执行操作。此外，该平台可以访问分布在多个数据源(包括关系和非关系数据源)上的数据。例如，平台可以从不同的数据源中检索数据，并结合这些数据满足最终的查询结果。

平台可以具有向外扩展的架构。它可以从一台服务器扩展到单个集群中的数千台服务器。该平台可以部署在专用硬件或共享基础架构上，例如HADOOP集群、私有云或公共云。例如，使用平台在HADOOP中分析数据时，可以将平台部署在HADOOP集群上。这使平台能够实现原始数据的本地化和包含的优化数据结构在自有内存中。

平台集群具有两个不同的角色：协调者和执行者。每个角色都可以独立扩展。协调器是负责协调查询执行、管理元数据和服务门户的节点。客户端应用程序(例如BI工具)连接到协调器并与之通信。协调器可以扩展以满足更多客户端请求。执行器是负责查询执行的节点。客户端应用程序不直接连接和访问执行器，执行器可以扩展以处理更大的数据量和更多的并发执行工作。

当在HADOOP上运行平台时，可以将协调器部署在边缘节点上，以便诸如BI工具之类的外部应用程序可以连接到它们。此外，无需在HADOOP集群上手动部署平台，因为协调器可以直接发布为YARN应用，并使用YARN提供的计算资源。为了最大化性能，集群中的每个节点都可能有一个执行器。

图5是根据本公开的一些实施例的平台的过程的流程图。在步骤502中，平台连接到一个或多个数据源。在步骤504中，在用户设备的显示器上显示平台的自助服务门户。例如，在步骤502，用户可以打开由平台管理的门户网站，该门户网站使用户能够查询连接到平台的数据源。在步骤506，用户可以使用门户的可视化数据集编辑器来创建虚拟数据集和/或与其他用户共享虚拟数据集。

在步骤503中，平台可以接收数据源的统计信息。统计信息可用于制定最佳的查询计划。在一些实施例中，平台获得统计信息并存储在本地存储器中，当需要定义查询计划时，平台可以从本地存储器中检索并获取统计信息，优化和生成最终的查询计划。

在步骤508中，平台生成优化的数据结构，生成优化数据结构的决定可以是自主的，生成的过程可以是自动的。在一些实施例中，生成优化数据结构的决定可以基于用户输入。在一些实施例中，用于生成优化数据结构的决定和/或过程可以基于自主、手动或自动步骤的组合。

在步骤510中，平台从用户设备接收查询。该查询可以指物理数据集和/或虚拟数据集。可以通过耦合到平台的协调器的网络从客户端设备接收查询。在一些实施例中，通过ODBC、JDBC或REST接收查询。

在步骤512中，平台执行过程基于接收到的查询来定义查询计划。例如，查询计划可以定义构成查询计算的运算符。查询计算的运算符指数据源能够支持的操作。例如，NOSQL数据库和查询引擎仅支持实现复杂查询所需的操作符子集。例如，MONGODB可以执行聚合但不能执行连接。在某些情况下，数据源的可执行操作取决于数据源如何组织数据。例如，ELASTICSEARCH无法对已标记的字段执行相等过滤器。

查询计划可能包含特定数据源的交互代码的生成。例如，所公开的平台可以利用NOSQL数据库的可扩展性机制。当与ELASTICSEARCH集群交互时，查询的部分可能被编译成GROOVY或PAINLESS脚本，这些脚本被注入到ELASTICSEARCH查询中。当与MONGODB集群交互时，查询的部分可能被编译成在MONGODB的MAPREDUCE框架中运行的JavaScript代码。

执行速度是指数据源可以执行运算符的速度。也就是说，某些数据源可能比其他数据源更快地执行某些运算符。查询计划可以选择在更快执行某些运算符的数据源上执行相应的操作符，以提高整个查询的执行速度。

数据分布可以指数据如何跨数据源分布。也就是说，利用数据源中数据的组织方式来配置查询计划。例如，ELASTICSEARCH父子关系可以搭配来自不同数据集的匹配记录，这样两个数据集之间的连接就不需要任何数据混洗。因此，查询计划可能更倾向于在数据源上执行查询的一部分，从而避免在不需要混洗的数据源上进行数据混洗，从而减少查询时间。

网络吞吐量和延迟的考虑是指网络吞吐量和延迟是否影响查询结果的获取过程。例如，查询计划可能会在更大程度上优先在数据源本地执行查询操作。例如，如果某个数据源的网络较慢，则可以配置查询计划，将操作下推到数据源，并在执行下推操作后传输查询结果。例如，与在数据源处聚合数据相比，平台通常能够在本地更快地聚合数据。在正常网络条件下，最好从数据源接收数据并在平台本地聚合数据。但是，在较慢的网络条件下，最好在数据源聚合数据并通过网络传输聚合数据，而不是传输未聚合的数据由平台聚合。另一方面，如果平台的守护进程与数据源位于同一位置，则传输数据的成本相对较低，因此聚合数据的位置不会对查询执行产生负面影响。

数据源SLA考虑是指由SLA强加的约束。例如，用户可能希望最小化数据库上的查询负载以避免违反SLA。在这些情况下，平台可以决定将查询的哪个部分应用于数据库以避免违反其SLA考虑。

在一些实施例中，查询计划可以被定义为以分布式模式执行操作。查询的各个部分可以跨多个节点执行，并且可以分阶段执行。因此，跨非关系数据源分布的操作可以分阶段并行化。例如，查询可以包括聚合操作。平台的查询优化器可以确定该聚合可以应用于MONGODB数据库。查询计划可能会要求每个MONGODB节点(即MONGOD守护进程)对单个数据分片执行本地聚合，而不是请求MONGODB数据库执行整个聚合，并且这些本地聚合中的每一个都返回到可能不同的平台集群中的线程，这允许在集群中并行继续执行。

平台可以基于关系模型和其他考虑来定义查询计划。例如，查询计划可以基于收集到的信息来定义，包括数据源的功能能力和本公开其他地方描述的其他参数。例如，查询计划可以在查询计划阶段、优化阶段或查询执行阶段使用数据源的执行能力。

在步骤516中，查询计划被修改以利用优化的数据结构代替直接查询数据源以获得查询结果。在一些实施例中，用于定义查询计划的初始过程可以考虑任何可用的优化数据结构，包括它们的排序、分区和分布。在其他实施例中，如果可以加速查询执行的优化数据结构已经被识别，则定义的查询计划会被重新定义。在一些实施例中，查询计划可以被扩展、修改以使用优化的数据结构和/或修改以使用在步骤503中获得的性能统计。

在步骤518中，修改的查询计划的执行开始于执行器从数据源获取数据到缓冲区中，执行器可以读取远程数据源中包含的物理数据集和/或自主存储器中包含的优化数据结构，在使用平台和/或数据源的分布式查询引擎执行修改后的查询计划时读取数据。

在步骤520中，平台获取满足接收到的查询的查询结果。此外，可以并行和/或分阶段执行从多个数据源获取查询结果。数据可以从自主存储器(例如，PARQUET文件)和/或底层数据集中的优化数据结构获得。从数据源读取时，执行器可以提交由优化器在规划阶段确定的本地查询(例如，MONGODB查询语言、ELASTICSEARCH查询DSL、MICROSOFTTRANSACT-SQL)。

在一些实施例中，从数据源和/或自主存储器获得的中间查询结果被组合以产生满足查询的最终查询结果。例如，一个执行器可以合并来自其他执行器的数据以产生最终的查询结果，合并的数据可以作为最终查询结果以流式传输到平台的协调器。

在一些实施例中，平台可以使用APACHE ARROW(内存中的列)和APACHE PARQUET(磁盘上的列)驱动的高性能列存储。APACHE ARROW是一个开源项目，支持列式内存数据处理和交换。在一些实施例中，平台的执行引擎可以使用APACHE ARROW。内存中的数据可以以ARROW格式维护，并且可能有一个API将查询结果作为ARROW内存缓冲区返回。APACHEPARQUET

是一个开源项目，它支持列式数据存储。它已成为HADOOP和云计算生态系统中常见的柱状格式。与针对内存存储和CPU高效处理进行优化的APACHE ARROW不同，PARQUET针对磁盘存储进行了优化。例如，它利用编码和压缩方案(例如字典和游程编码)来最小化占用空间和I/O。该平台可能包括一个高性能的PARQUET读取器，它可以将PARQUET格式的数据从磁盘读取到内存中的ARROW格式的数据中。PARQUET阅读器可以快速处理原始数据以及缓存中的反射。此外，它还包括智能谓词下推和页面修剪、无需解压缩数据的就地操作和零内存副本等功能。

在步骤522中，客户端设备从平台接收最终查询结果。最终查询结果可以被呈现为文本或可视化、持久化或者可以对最终查询结果执行计算(例如，步骤526)。用户还可以操作与平台相连的门户来查看、操作和分析最终的查询结果。

在步骤524中，平台可以基于最终查询结果而不是数据源的数据集来生成优化的数据结构。生成优化数据结构的决定可以是自主的或基于用户的输入。此外，用于生成优化数据结构的过程可以是自动的。新创建的数据结构可用于后续接收到的查询，以加速后续查询执行。

虽然图5显示了特定的一系列步骤，但本公开不限于此。相反，上面描述的许多步骤可以以不同的顺序发生或被省略。例如，用户设备不需要如步骤526所示将查询结果可视化并且平台不需要基于查询结果生成任何优化的数据结构。进一步讲，平台可以随时接收到步骤503的性能统计数据，也可能根本不获取这些统计数据。

动态和未知模式：平台的实施例可以处理动态模式和模式不确定性。动态模式是指更改的数据源或包含混合数据类型的数据源的模式。动态模式在非关系数据存储中很常见。例如，像MONGODB这样的数据源可能只有一个列，其中包含不同数据类型(例如，varchar、map、integer)的值。

平台可以处理数据源的混合数据类型。例如，平台可以确定列或字段具有混合数据类型。如果是这样，它可以导致向用户显示可视指示符并且使用户能够通过修改列以包括单一数据类型或将列分成具有相应数据类型的多个列来解决该情况。然后，该平台可以支持BI工具和其他需要每列具有单一数据类型的基于SQL的应用程序。因此，公开的平台为用户提供了一种使用BI工具准备数据进行分析的方法。

这种“单一数据类型”方法将混合数据类型转换成单一数据类型。用户可以指定所需的数据类型，平台要么删除具有无法转换为指定数据类型的值的条目，要么将这些值替换为指定值，例如“NULL”。另一方面，“按数据类型拆分”方法将具有混合数据类型的列拆分为每个数据类型的列。例如，如果列foo混合了map和text，则该列将拆分为foo_map列和foo_text列。平台可以使用值NULL代替每列中的缺失值。

模式不确定性指的是尝试查询该数据源的系统不知道数据源的模式的情况。例如，可能没有为数据源显式定义模式。因此，在对数据源执行查询操作之前，平台无法知道数据源中包含的数据集的结构。因此，平台必须在模式不确定的情况下运行。

现有系统可以假设所有数据都具有明确定义的模式，尤其是在数据虚拟化的方法中。这个假设在处理关系数据源时成立，但在处理非关系数据源(如NOSQL数据库和文件)时不成立。对于此类数据源，现有方法依赖于管理员在查询数据之前手动指定模式，或者检查存储在数据存储中的数据样本以近似模式。

平台可以通过“模式学习”或“模式传递”来补偿模式不确定性。也就是说，平台可以处理数据源不通告供平台使用的模式的情况。例如，MONGODB集合和JSON文件实际上是无模式的。此外，当查询文件目录时(例如，在S3、HDFS中)，即使每个文件都具有定义的模式，文件也会被添加到目录中或从目录中删除，从而整个模式可能会发生变化。

在模式学习中，平台可以自动学习数据集的模式。最初，平台根据来自数据源的样本数据估计模式。当样本不能反映所有数据的模式时，它可能是不完整的。因此，不能保证估计的模式是准确或完整的。当平台执行查询时，查询执行引擎观察到与当前假定模式不匹配的数据时，会更新当前模式。在某些情况下，查询执行可能无法继续，因为查询最初是基于假定的模式编译的。在这些情况下，平台会自动重新编译查询并使用新学习的模式重新开始执行。

在模式传递中，平台可以用动态模式传播数据集的变化。例如，用户可能希望将计算字段作为新的虚拟列添加到MONGODB集合中。在这种情况下，虚拟数据集应该包括MONGODB

集合中的所有字段以及附加的计算字段。如果将新字段添加到MONGODB集合中，则虚拟数据集可以反映添加内容。为了启用模式传递，平台可以支持一种方法来执行虚拟数据集中列的通配符选择。例如，“SELECT*,eval_scores+10FROMmongo.trip.business”向父数据集(mongo.trip.business)中的所有列(*)添加了一个额外的列。在某些情况下，用户可以转换一列，同时允许任何其他列通过，而不是添加列。例如，查询可以是“SELECT*EXCEPT city,UPPERCASE(city)AS city FROM mongo.trip.business”。表达式“*EXCEPTcity”是指除city之外的所有列。查询也可以是：“SELECTUPPERCASE(city)AS city,...FROM mongo.trip.business”，其中“...”代表除与明确提到的名称相同的列之外的所有列。还有许多其他语法可用于允许传递未显式调用的列。表示除与明确提及的名称相同的列之外的所有列。

命名空间与路径结构：平台的实施例包括用于物理或虚拟数据集的分层命名空间。数据集位置的路径用路径名表示，路径名包括由点或斜线分隔的路径组件。例如，web_access.access_path.user_clicks可以指名为“user_clicks”的MONGODB集合，该集合存储在名为“web_access”的MONGODB集群中名为“access_path”的MONGODB数据库中。“web_access”可以由用户在与该数据源建立连接时定义，“access_path”和“user_clicks”可以从MONGODB集群中获取。

基于文件的数据源(例如，HDFS和S3)的数据集的路径可以包括可变数量的路径组件。这种源中的数据集可以反映单个文件或类似结构文件的目录(例如，日志文件的目录)。例如，如果与HADOOP集群的连接是使用名称datahouse建立的，则HADOOP集群中

/path/to/clicks中的文件或目录的路径可能是datahouse.path.to.clicks。

当连接到数据源时，平台可以公开数据集信息。例如，公开的平台必须向基于SQL的客户端(例如TABLEAU)公开元数据信息，例如模式和表，这需要了解所有可以查询的数据集。对于数据库格式的数据源(例如，ORACLE、MONGODB或ELASTICSEARCH)，可查询的数据库元素是已知的。反映可查询数据集的此类元素的示例包括ORACLE表、MONGODB集合和ELASTICSEARCH类型等，它们可以提供检索列表的快速方法。

识别基于文件的数据源(例如，HDFS、S3)中的可查询数据集可能具有挑战性，因为每个文件或目录不一定是可查询的。例如，基于文件的数据源中的图像和视频文件不能作为数据集进行查询。此外，检索所有可查询文件的列表的快速方法通常不存在。因此，该平台必须遍历整个文件系统，这在计算上是令人望而却步的，因为它可能包含数百万或数亿个文件。

为了克服这些挑战，平台可以随着时间的推移了解文件系统中的哪些数据可以被视为可查询数据集。平台不知道数据源中的文件或目录，因为平台的元数据存储中没有文件或目录的记录。因此，数据源的所有文件或目录最初都可以假定为不可查询的数据集。

文件系统可以接收外部查询，例如通过引用不可查询的数据集文件或目录的第三方客户端应用程序提交的查询。如果平台能够读取该文件或目录中的数据，则此后将其视为可查询数据集。这可能包括基于文件扩展名(例如“.csv”)和数据分析的文件格式的智能自动识别。如果平台无法读取该文件或目录中的数据，则会向客户端应用程序返回错误，并且该文件或目录仍然是不可查询的数据集。

如果平台通过其自己的门户接收到引用不可查询的数据集文件或目录的查询，则平台可以提示用户指定格式选项(例如，在文本文件的情况下，行和字段定界符)并且可以运行查询。如果文件或目录是自描述的并且不需要任何格式选项，平台可以决定不提示用户。一旦用户提供格式选项，文件或目录就被视为可查询数据集。在一些实施例中，用户可以通过其自己的门户或API明确地将文件或目录标记为可查询数据集。此外，特定交互(例如单击门户中的文件)也可能具有将不可查询数据集变为可查询数据集的效果。在一些实施例中，用户还可以将文件或目录转换为不可查询的数据集。

平台可以随着时间的推移获悉数据源的哪些文件或目录表示可查询的数据集。任何文件或目录(包括不可查询的数据集)都可以随时通过SQL查询进行查询。但是，在返回到外部客户端应用程序的元数据中只公布已知的可查询数据集。例如，TABLEAU用户只能在TABLEAU UI中选择已知的可查询数据集，尽管用户能够使用TABLEAU的自定义SQL功能来查询甚至不可查询的数据集文件或目录。

数据安全与数据治理：安全性和数据治理对任何企业都是至关重要的。然而，数据的复杂性和需求的增加往往会导致数据的蔓延，从而带来重大的安全风险。该平台使用户能够发现、管理、加速和共享的数据，而无需将数据副本导出到不受管理的系统，包括断开连接的电子表格、BI服务器和私有数据库。这降低了未经授权的数据访问和数据盗窃的风险。特别是，该平台提供了一个具有安全和治理功能的虚拟安全层，包括沿袭、身份验证、访问控制、审计和加密。平台可以维护每个数据集的谱系记录，包括用户个人的所拥有的。因此，管理员可以轻松确定数据集的创建、转换、连接和共享方式，以及数据集之间这些步骤的完整沿袭。也就是说，数据集是连接的，管理员(或任何其他允许的用户)可以浏览每个数据集和列的祖先和后代。

平台可以支持多种认证模式。例如，可以在平台内部以嵌入式模式管理用户帐户。相比之下，该平台还可以连接到现有的基于LDAP的目录服务，例如Active Directory。该平台可以依靠目录服务在LDAP/Active Directory模式下验证凭据和检查组成员身份。

平台还可以支持粒度访问控制，包括控制哪些用户和/或组可以查询特定物理数据集的物理数据集权限，以及控制哪些用户和/或组可以查询特定虚拟数据集的虚拟数据集权限。访问控制可能包括列级权限，用于限制特定用户对数据集中敏感列的访问。可以通过SQL或UI设置列级权限。访问控制还可能包括行级权限，可用于限制特定用户对数据集中记录子集的访问。也可以通过SQL或UI设置行级权限。

用户还可以通过创建虚拟数据集在列或行级别设置访问控制。例如，数据库的所有者可以创建到数据库的连接。然而，所有者可以派生限制物理数据集暴露的虚拟数据集，而不是允许其他人查询该数据库的物理数据集。例如，所有者可以创建仅包括物理数据集的列或行的子集的衍生虚拟数据集。所有者可以拒绝访问物理数据集，同时允许访问派生的虚拟数据集。因此，派生的虚拟数据集有效地限制了对物理数据集的数据的访问。此外，屏蔽指令可以操作屏蔽数据集的特定列或行。

平台可以使用户能够协作并选择性地共享或准许对数据的访问。数据集的用户(例如，所有者或管理员)可以指定能够查询该数据集的用户或组。平台可以根据访问控制设置透明地构造复杂的SQL语句，使得返回给不同用户的数据可能因用户的身份而异。例如，UI可以使物理或虚拟数据集的所有者能够为不同的用户或组设置对该数据集的访问级别。例如，用户可以指定属于营销部门组的用户只能看到满足特定条件的记录或只能看到信用卡列的屏蔽版本。

所述的访问控制能力可以包括用户模拟以使得能够控制哪些用户可以查询特定数据集。特别是，可以在所有者模式或模拟模式下设置数据源或虚拟数据集。在所有者模式下，使用数据源或数据集所有者的身份。在模拟模式中，使用最终用户的身份。在一些实施例中，模拟模式可以支持使用被查询的子数据集的身份(其进而可以处于所有者或模拟模式)。

当以所有者模式建立数据源时，对数据源的访问可能需要数据源的所有者(即，定义该数据源的任何人)提供主凭证。但是，在模拟模式下建立数据源时，所有者不需要提供主凭据来访问数据源，因为访问数据源是使用最终用户的身份。虽然一些数据源(例如，HADOOP)允许通过信任关系在没有任何凭证的情况下进行模拟，但是一些数据源(例如，MONGODB、S3)需要凭证。对于需要凭据的源，有两种方法可以获取所需凭据以将用户模拟到数据源。

在一个实施例中，每个会话可以获得并维护所需的凭证。如果平台确定需要访问具有最终用户身份的数据源，则平台可能能够在通过平台的UI登录或连接BI工具时使用用户向平台进行身份验证的凭据.这些凭据由平台在用户与系统会话的上下文中维护，不需要长期保留。

在另一个实施例中，可以在钥匙串中获得和维护所需的凭证。用户连接平台的密码不一定适用于某些数据源。例如，S3使用随机生成的密钥而不是密码，这样用户的密码和用户名就无法访问S3中的文件。在一些实施例中，平台将多用户钥匙串维护为稀疏矩阵，该矩阵保存每个<数据源，用户>元组的凭证。当平台寻求使用特定用户的身份查询数据源时，它会查询钥匙串以查看钥匙串是否包含该数据源和用户的凭据。如果没有，平台可以提示用户输入该数据源的凭据。

平台可以具有审计能力。这允许用户监控谁正在访问特定数据并识别数据被访问的时间。在一些实施例中，该平台可以生成实时报告，例如显示给定数据集的前10名用户在非工作时间访问。该平台可以跟踪和记录用户活动，包括所有查询执行。这用作显示谁正在访问哪些数据的单一视图。例如，用户界面的作业部分可以提供所有查询执行的详细信息，使IT专业人员能够监控系统的可疑活动并识别未经授权的数据访问实例。

平台可以具有加密能力。对于在线加密，该平台可以同时利用TLS(SSL)和KERBEROS。对于每个数据源，平台都可以支持源系统的相应级别的加密方案。例如，当连接到安全的HADOOP集群时，平台可以通过KERBEROS安全地与HADOOP服务通信。对于静态加密，平台可以利用自主内存(例如HDFS、AMAZON S3)的加密功能。当自主内存位于直接连接的存储(即集群的本地磁盘)上时，可以通过自加密驱动器或操作系统级别的加密来提供加密。

自主内存：如上所述，所公开的实施例包括被配置为具体化数据源的数据的自主存储器也称为反射数据存储)。物化数据可以使平台能够从数据源生成查询结果，而无需连接到数据源。因此，反射数据存储包含优化的数据结构，这些结构在查询时可用，而不是仅依赖于数据源。

在一些实施例中，反射数据存储是用于加速查询执行的持久高速缓存。缓存可以存在于HDFS、云存储(例如S3)或直连存储(DAS)上。缓存大小可以超过物理内存的大小。这种架构能够以更低的成本缓存更多数据，与传统的纯内存架构相比，缓存命中率更高。

图6是平台602的加速系统的框图。加速系统可以包括被配置用于加速查询执行过程的自主存储器608。在一些实施例中，平台602可包括自主存储器608或与自主存储器608分开，加速系统可包括平台602、可包括在平台602中或可与平台602分开。

平台602通信方式耦合到一个或多个数据源604和一个或多个用户设备606。自主存储器608通信方式耦合到数据源604和平台602。自主存储器608可以包括集群的内存存储、磁盘存储、分布式文件系统(例如HDFS)、blob或对象存储(例如AMAZON S3)或数据库或组合。自主存储器608包含优化的数据结构610。

通过使用自主存储器608，可以更快速地获得查询的查询结果，因为其优化的数据结构610针对来自诸如关系和非关系数据源604的数据集的复杂查询进行了优化。此外，自主存储器608可以是平台602的本地存储器，以避免诸如瓶颈、延迟等的网络问题。相对于将查询排他地应用于数据源604，获得查询结果的过程被加速。特别地，在接收到对包含在数据源604中的数据的查询时，可以查询自主存储器608而不是查询数据源604。因此，因为平台604可以避免查询远程数据源，所以加速了获取查询结果的过程。

涉及自主存储器608的查询操作对于提交查询的用户设备606的用户是透明的。相比之下，用于提高查询性能的已知技术(例如，OLAP多维数据集、聚合表和BI提取)需要用户明确连接到优化的数据。因此，用户设备606的用户可以向平台602提交查询，平台602可以通过使用自主存储器608中可用的任何优化数据结构610来自动且透明地加速查询执行。

图7A是在用户设备606上呈现的700的视图。如图所示，展示700具有数据集设置窗口702，其包括允许用户设备606的用户管理优化数据结构(例如，反射)的设置的控件(例如，控件704)。如图所示，数据集设置窗口702由运行在用户设备606上的浏览器706呈现，该用户设备606通过诸如因特网之类的网络连接到平台602。数据集设置窗口702示出了原始反射708。用户设备606的用户可以通过使用经由700的控制来查看或修改原始反射708，在这种情况下，改变后的原始反射708会创建并存储在自主存储器608上，供后续查询期间使用。

图7B是在用户设备606的显示器上呈现的700的另一视图。如图所示，显示700具有数据集设置窗口710，其包括允许用户设备606的用户管理优化数据结构的设置的控件(例如，控件712)。如图所示，数据集设置窗口710由运行在通过诸如因特网的网络连接到平台602的用户设备606上的浏览器706呈现。数据集设置窗口710显示聚合反射714。用户设备606的用户可以通过显示700使用控件来查看或修改聚合反射714，在这种情况下，改变后的聚合反射714会创建并存储在自主存储器608上，供后续查询期间使用。

如上所述，该平台可以包括优化器，该优化器被配置为优化定义查询执行的查询计划。优化器可以探索利用包含在自主内存中的优化数据结构的机会，而不是在查询时处理数据源中的原始数据。在一些实施例中，可以从自主存储器而不是从数据源更快地获得满足查询的查询结果。此外，通过使用自主内存代替数据源降低了计算成本。因此，优化器可以在接收到新查询时考虑自主存储器中的所有优化数据结构，并在可能的情况下自动定义查询计划以利用优化数据结构。

在一些实施例中，优化器可以包括两阶段算法。在修剪阶段，优化器忽略自主内存中任何不相关的优化数据结构，因为它们的逻辑计划与查询的逻辑计划没有共同的物理数据集。换句话说，任何不基于查询范围内的物理数据集的优化数据结构都被排除在查询计划之外。在子图匹配阶段，优化器使用分层图算法将查询逻辑计划的子图与任何剩余优化数据结构的逻辑计划进行匹配。

图8是用于加速查询执行的过程800的流程图。可以通过使用包含在自主存储器(即反射数据存储)中的优化数据结构(即反射)来加速查询执行。因此，在步骤802中，自主存储器根据算法或者用户输入的优化数据结构来生成最终的具体化数据。例如，算法可以确定要在自主存储器中具体化的数据和/或可以基于明确指示要具体化什么的用户输入来具体化数据。在其他地方描述了用于决定和生成物化数据的过程。

在步骤804中，平台从客户端设备接收查询。例如，平台可以接收涉及数据源的数据集和/或从数据源的数据集导出的虚拟数据集的查询。在步骤806中，平台根据接收到的查询命令来定义查询计划。查询计划可以参考物理和/或虚拟数据集。

平台可以根据虚拟数据集的定义对其进行扩展，从而生成仅引用物理数据集的查询计划。

在步骤808中，平台确定是否可以通过使用自主存储器的优化数据结构来加速查询执行。在一些实施例中，平台检查自主存储器中是否存在未过期且可用于部分或完全满足查询的优化数据结构。例如，假设自主内存包含一个优化的数据结构X，它对应于“SELECTname,city FROM mongo.trip.business”。如果平台执行查询`SELECT name FROMmongo.trip.business`，平台会识别并使用优化数据结构X。同样，如果平台执行查询`SELECT name,COUNT(*)

FROM mongo.trip.business GROUP BY name`，平台会识别并使用优化数据结构X。在这种情况下，平台可以依靠X执行聚合(按名称分组)查询。

在步骤808中，如果查询执行可以被加速，则平台确定查询结果是否可以完全从自主存储器中获得。在步骤810，如果查询可以完全基于自主存储器中的反射计算，则修改查询计划以包括自主存储器的优化数据结构并且平台不需要访问数据源。

在步骤812中，平台利用自主存储器来计算满足查询的结果。在步骤814，结果被返回到客户端设备。

在步骤810中，如果查询执行不能被加速，则查询计划被定义为从数据源读取数据以计算查询结果。查询执行仍然可以在没有自主内存好处的情况下得到改进。例如，查询计划的范围可以包括分布式执行，以在从RDBMS或NOSQL数据源查找数据时利用列式内存处理和下推到底层数据源。

在步骤812中，如果可以加速查询执行，则用选定的优化数据结构修改查询计划以促进加速。在步骤814中，平台判断修改后的查询计划是只需要读取选择的优化数据结构就可以得到查询结果，还是需要再读取数据源中包含的数据才可以满足查询结果。

在步骤816中，如果可以通过从自主存储器和数据源读取数据来获得查询结果，则修改查询计划以包括自主存储器中包含的优化数据结构和数据源中包含的数据集的组合，这也可能发生在平台确定通过使用数据源降低查询的整体计算成本时，例如，当数据源具有索引时，平台会下推到数据源去执行SQL查询。

平台查询自主存储器以获得中间查询结果，并查询数据源以获得剩余的中间查询结果。在一些实施例中，在从自主存储器获得中间查询结果之前，会先从数据源获得中间查询结果。在一些实施例中，可以从自主存储器和数据源并行地获得中间查询结果。

在步骤818中，如果可以通过从自主存储器中读取来排他地获得查询结果，则修改查询计划以仅包括所选择的优化数据结构。因此，通过在执行查询时仅读取优化的数据结构来加速查询执行。最后，在步骤820中，将从自主存储器和/或数据源读取得到的数据(即中间查询结果)进行合并、定型，作为满足接收到的查询的最终查询结果返回给用户。

该平台可以智能地决定何时生成优化的数据结构，以及数据源的哪些数据将在自主内存中具体化。例如，平台可以基于用户输入和/或考虑各种因素或约束的算法进行确定。例如，算法的输入可以包括与历史查询、历史查询模式或会话、实时或当前查询、显式投票相关的信息。平台还可以考虑由管理员设置的物理约束(例如，可用内存、资源消耗和期望的查询运行时间)和策略约束。下面是物化数据的几个考虑事项。

平台可以自动地将频繁查询的数据或与其相关的数据具体化为自主存储器中的优化数据结构。具体来说，该平台可以确定哪些数据和查询比其他数据和查询更常见。该平台可以将频繁查询的数据或与其相关的数据物化，相比直接访问数据源，更能提高查询能力。

如上所述，平台还可以根据用户提示具体化数据。用户提示可以是明确的指令，用于加速对特定物理或虚拟数据集的查询。例如，用户可以通过创建锚定到特定数据集的优化数据结构来请求加速对特定数据集的查询。在这种情况下，优化的数据结构源自特定数据集，以便对该数据集的查询可以应用于自主内存而不是数据源。

平台可以基于数据集之间的关系来具体化数据。该平台知道任何数据集之间的关系，并且可以使用此信息来确定要创建的优化数据结构。特别是，虚拟数据集和物理数据集之间的关系会影响平台将要创建的优化数据结构。该平台可以使用基于成本的因素或启发式方法。例如，如果动态计算数据的成本很低(例如，快速执行)，则可以应用最小成本阈值来避免物化数据。例如，如果底层数据集被物化并且可以基于底层数据集以足够低的成本计算派生数据集，那么即使用户请求将派生数据集物化，派生数据集也不会被物化。增量具体化是指虚拟数据集的大部分数据与另一个已具体化的物理或虚拟数据集相同。如果是这样，平台可能决定仅实现两个数据集之间的差异(即增量)。例如，如果A已经具体化并且B与A相同加上额外的列，则平台将仅实现B中的额外列以加速B。

共同祖先物化是指为多个需要加速的虚拟数据集或即席查询自动检测共同祖先，并假设从祖先计算这些数据集或查询的成本相对较小。例如，用户可能要求加速B和C，而不是A。平台可能会确定B和C可以以足够低的计算成本从A派生，因此决定实现A而不是B或C。

共同祖先不必是实际命名的数据集；相反，它可以是任意的中间数据集。例如，假设B是`SELECT COUNT(*)FROM business GROUP BY state HAVING state＝"CA"，C是`SELECT COUNT(*)FROM business GROUP BY state HAVING state＝"HN"。在这种情况下，系统可能会决定不实现B和C，而是实现等效于“SELECT

state,COUNT(*)FROM business GROUP BY state”的中间数据集就足够了，因为B和C可以基于廉价计算在这个中间数据集上。

中间物化是指不仅识别可以加速的显式数据集，而且还可以概括数据集或创建以前不存在的中间数据集以提供理想的加速候选。考虑到诸如结果执行工作量、集群大小以及提高自主内存命中率的期望等因素，这可以实现物化覆盖率和大小与所需延迟之间的平衡。

自动分区和排序具体化技术是指自动识别最佳物理数据布局，包括分区、字典编码和排序，以减少具体化维护成本和提升结果执行性能。列感知加速是指平台利用列存储格式的性质来加速替代数据集。这允许平台减少数据集重复并最小化磁盘读取开销。

基于CPU消耗和大小的分层物化技术是指实现在多种存储设备(包括旋转磁盘、SSD、压缩内存、扩展内存以及持久性内存等更新技术的硬件设备)上进行数据物化。在每种情况下，该平台都允许用户对执行性能与系统容量之间进行权衡，以提供最佳规模或性能的平衡。

OLAP类型模式的自动识别技术是指识别通过SQL或第三方工具完成的常见分析模式的群集，以及数据剖析，以便平台可以确定可能的关系，包括表关系、星型模式和维度测量并使用这些来生成更好的物化覆盖率，并支持自动数据集识别和在自主内存中缓存。

辅助存储冗余技术是指保持与主要数据源的连接，以通过对主要数据集可用性的强感知来最大限度地减少出于冗余目的的重复。

商业智能工具启动器:在一些实施例中，用户能够通过虚拟数据集协同管理和准备数据。通过利用平台的SQL执行引擎和客户端驱动程序，任何基于SQL的应用程序(例如BI工具)都可以连接到平台并对物理和虚拟数据集发出查询。

平台可以包括使用户能够从平台的UI内的数据准备跳转到使用基于SQL的应用程序进行分析的能力。此功能可称为BI工具启动器。用户可以选择所需的应用程序并单击按钮以启动该应用程序。数据不会从平台中提取或导出到BI工具中。相反，应用程序是使用与平台建立实时直接连接所需的参数启动的。

BI工具可以使用不同的技术集成到平台中。例如，可以将自动生成的连接文件下载到平台。自动生成的连接文件可以通过直接连接来初始化BI工具。当用户单击按钮(或链接)时，浏览器会收到连接信息并启动BI工具，平台也可以使用直接链接或API调用。对于服务器端或基于Web的BI工具，可以将用户重定向到包含连接信息的特殊URL。或者，平台可以使用BI工具的API来配置连接。

计算机系统：图9是可用于实现某些特征的计算机系统900的框图。计算机系统900可以是服务器计算机、客户端计算机、个人计算机(PC)、用户设备、平板PC、便携式、移动、手持设备或任何能够执行一组指令(顺序或其他)的机器，这些指令指定该机器要采取的行动。

计算系统900可以包括一个或多个中央处理单元902、存储器904、输入/输出设备906，例如键盘和定点设备、触摸设备、显示设备、存储设备908，例如磁盘驱动器以及连接到互连912的网络适配器910，例如网络接口。互连912被图示为代表任何一个或多个单独的物理总线、点对点连接或两者都由适当的桥接器、适配器、或控制器。因此，互连912可包括例如系统总线、外围组件互连(PCI)总线或PCI-Express总线、小型计算机系统接口(SCSI)总线,通用串行总线(USB)。

存储器904和存储设备908是可以存储实现各种实施例的至少一部分的指令的计算机可读存储介质。此外，数据结构和消息结构可以通过数据传输介质例如通信链路上的信号来存储或传输。可以使用各种通信链路，例如因特网、局域网、广域网。因此，计算机可读介质可以包括计算机可读存储介质，例如非暂时性介质，以及计算机可读传输介质。

存储在存储器904中的指令可以实现为软件和/或固件以对处理器902进行编程以执行上述动作。在一些实施例中，这样的软件或固件可以通过计算系统900从远程系统下载它，并在初始提供给处理系统900，或经由网络适配器910提供给处理系统900。

以上显示和描述了本发明的基本原理和主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (10)

1.自服务数据平台，包括由服务器计算机或集群执行的方法，其特征在于，所述的方法包括接收查询并基于接收到的查询定义查询计划；查询计划是指数据源中包含的数据集；还包括基于包含在存储器中的优化数据结构确定接收到的查询可以被加速，其中优化数据结构是从查询计划中引用的数据集导出的；还包括修改查询计划以包括优化的数据结构，并且执行修改的查询计划以通过读取优化的数据结构代替从数据源读取至少一些数据来获得满足接收到的查询的查询结果。

2.根据权利要求1所述的自服务数据平台，其特征在于，所述的方法还包括：在接收查询之前，生成优化的数据结构包括至少一个数据集的原始数据，生成优化的数据结构包括数据列的聚合至少一个数据集的数据结构，生成优化的数据结构包括至少一个数据集的数据列的排序、分区或分布式数据中的至少一种，和/或生成优化的数据结构包括从至少一个数据集中采样的数据。

3.根据权利要求1所述的自服务数据平台，其特征在于，所述的接收到的查询是第二查询并且查询结果是第二查询结果；所述的方法还包括：在接收第二查询之前，基于满足第一查询的第一查询结果生成优化数据结构；查询计划是第二查询计划，并且第一查询计划被定义为具有比获得满足第一查询的查询结果所需的范围更广的范围，使得生成的优化数据结构比基于查询计划生成的优化数据结构更广；基于查询计划的范围，该范围至少足以获得满足第一个查询的查询结果。

4.根据权利要求1所述的自服务数据平台，其特征在于，所述的查询结果是在不读取数据源中包含的任何数据集的情况下获得的，或者除了读取优化的数据结构之外，还通过读取数据源中包含的至少一些数据集来获得查询结果。

5.根据权利要求1所述的自服务数据平台，其特征在于，所述的方法还包括在确定接收到的查询可以被加速之前自主决定生成优化的数据结构，生成优化数据结构的决定基于由服务器计算机(或集群)接收的查询的历史和/或基于读取优化数据结构代替来自数据源的至少一些数据，从而优化和提升系统的工作负载。

6.根据权利要求1所述的自服务数据平台，其特征在于，所述的方法还包括，在接收查询之前，接收用户对数据集的一个或多个数据集的加速查询需求，并响应接收到的需求生成优化的数据结构。

7.根据权利要求1所述的自服务数据平台，其特征在于，所述的方法还包括，在接收查询之前，接收定义从数据源中包含的物理数据集导出的虚拟数据集的用户输入，其中数据集包括虚拟数据集。

8.根据权利要求1所述的自服务数据平台，其特征在于，所述的修改的查询计划由计算机服务器或集群的分布式查询引擎执行。

9.根据权利要求1所述的自服务数据平台，其特征在于，所述的自服务数据平台还包括计算机系统，计算机系统包括处理器和指令存储器，当由处理器执行这些指令时，这些指令会使计算机系统连接到包含物理数据集的数据源，并显示可视化数据集编辑器，并允许用户通过使用可视化数据集编辑器创建从物理数据集派生的虚拟数据集来整理数据，而无需创建整理数据的任何物理副本；所述的可视化数据集编辑器包括控件，当用户选择该控件时，该控件使计算机系统打开连接到虚拟数据集的客户端应用程序；所述的计算机系统显示物理数据集和虚拟数据集之间的关系的可视化；所述的计算机系统基于数据源中包含的物理数据集自主地决定生成优化的数据结构，并将优化的数据结构存储在存储器中，其中，优化的数据结构加速了查询的执行，该查询涉及物理数据集或从物理数据集派生的虚拟数据集。

10.根据权利要求1所述的自服务数据平台，其特征在于，所述的虚拟数据集被公开为客户端应用程序中的虚拟表，使计算机系统允许用户通过可视化数据集编辑器共享虚拟数据集。

Images