译文：Apache Calcite：一个为异构数据源的优化查询处理而生的基础框架（2）

原文：https://arxiv.org/pdf/1802.10233.pdf

7 扩展CALCITE

正如我们在前面部分中提到的，Calcite不仅适用于SQL处理。实际上，Calcite通过其他数据抽象（例如半结构化，流式传输和地理空间数据）为SQL表达查询提供扩展。其内部运营商适应这些查询。除了SQL的扩展，Calcite还包括一种语言集成的查询语言。我们在本节中描述了这些扩展，并提供了一些示例。

7.1 半结构化数据

Calcite支持几种复杂的列数据类型，可以将关系数据和半结构数据的混合存储在表中。具体而言，列可以是 ARRAY
， MAP
或 MULTISET
类型。此外，这些复杂类型可以嵌套，比如具有值类型为ARRAY的MAP。可以使用[ ]运算符提取ARRAY和MAP列（以及其中的嵌套数据）中的数据。无需预定义存储在任何这些复杂类型中的特定类型的值。

例如，Calcite包含MongoDB的适配器，这是一个文档存储，用于存储由大致相当于JSON文档的数据组成的文档。要将MongoDB数据公开给Calcite，将为每个文档集合创建一个表，其中包含一个名为_MAP的列：从文档标识符到其数据的映射。在许多情况下，可以预期文档具有共同的结构。表示邮政编码的文档集合可以包含具有城市名称，纬度和经度的列。将此数据公开为关系型的表非常有用。在Calcite中，这是通过在提取所需值并将它们转换为适当类型后创建视图来实现的：

SELECT CAST(_MAP['city'] AS varchar(20)) AS city,
CAST (_MAP['loc'][0] AS float) AS longitude,
CAST (_MAP['loc'][1] AS float) AS latitude
FROM mongo_raw.zips ;
复制

通过以这种方式定义的半结构化数据的视图，与关系数据一起操纵来自不同半结构化源的数据变得更容易。

7.2 流

Calcite基于对标准SQL的一组特定于流的扩展提供了对流式查询的很好的支持，即流扩展，窗口扩展，通过连接中的窗口表达式对流的隐式引用等。这些扩展的灵感来自连续查询语言，同时也尝试有效地与标准SQL集成。主要扩展，STREAM指令告诉系统用户对传入记录感兴趣，而不是现有记录。

SELECT STREAM rowtime, productId, units
FROM Orders
WHERE units > 25;
复制

在查询流时缺少STREAM关键字时，查询将成为常规关系查询，示意系统应处理已从流接收的现有记录，而不是传入的记录。

由于流的固有无界特性，窗口用于除去阻塞运算符，例如聚合和连接。Calcite的流扩展使用SQL分析函数来表示滑动和级联窗口聚合，如以下示例所示。

SELECT STREAM rowtime,
productId,
units,
SUM(units) OVER (ORDER BY rowtime
  PARTITION BY productId
  RANGE INTERVAL '1' HOUR PRECEDING) unitsLastHour
FROM Orders;
复制

滚动、跳跃、会话窗口在 TUMBLE
, HOPPING
, SESSION
函数和相关的实用程序函数（如 TUMBLE_END
和 HOP_END
）中被启用，它们可以分别在 GROUP BY
子句和投影中使用。

SELECT STREAM
TUMBLE_END(rowtime, INTERVAL '1' HOUR) AS rowtime,
productId,
COUNT(*) AS c,
SUM(units) AS units
FROM Orders
GROUP BY TUMBLE(rowtime, INTERVAL '1' HOUR), productId;
复制

涉及窗口聚合的流式查询要求在GROUP BY子句或ORDER BY子句中存在单调或准单调表达式，以防滑动和级联窗口查询。

可以使用JOIN子句中的隐式（时间）窗口表达式来表示涉及更复杂的流到流连接的流式查询。

SELECT STREAM o.rowtime, o.productId, o.orderId,
s.rowtime AS shipTime
FROM Orders AS o
JOIN Shipments AS s
ON o.orderId = s.orderId
AND s.rowtime BETWEEN o.rowtime AND
o.rowtime + INTERVAL '1' HOUR;
复制

在隐式窗口的情况下，Calcite的查询计划器验证表达式是单调的。

7.3 地理空间查询

地理空间支持是Calcite的初步支持，但正在使用Calcite的关系代数实现。此实现的核心在于添加一个新的GEOMETRY数据类型，该数据类型封装了不同的几何对象，如点，曲线和多边形。预计Calcite将完全符合OpenGIS Simple Feature Access规范，该规范定义了用于访问地理空间数据的SQL接口标准。示例查询查找包含阿姆斯特丹市的国家/地区：

SELECT name FROM (
SELECT name,
ST_GeomFromText('POLYGON ((4.82 52.43, 4.97 52.43, 4.97 52.33,
4.82 52.33, 4.82 52.43))') AS "Amsterdam",
ST_GeomFromText(boundary) AS "Country"
FROM country
) WHERE ST_Contains ("Country", "Amsterdam");
复制

7.4 Java的语言集成查询

除了关系数据库之外，Calcite还可用于查询多个数据源。但它的目的还不仅仅是支持SQL语言。尽管SQL仍然是主要的数据库语言，但许多程序员都喜欢LINQ等语言集成语言。与Java或C++代码中嵌入的SQL不同，语言集成查询语言允许程序员使用单一语言编写所有代码。Calcite提供Java语言集成查询（简称LINQ4J），它严格遵循Microsoft的.NET语言LINQ规定的约定。

8 INDUSTRY AND ACADEMIA ADOPTION

Calcite广泛采用，特别是在工业中使用的开源项目中。由于Calcite提供了一定的集成灵活性，因此这些项目选择（i）将Calcite嵌入其核心，即将其用作库，或（ii）实现适配器以允许Calcite联合查询处理。此外，我们看到研究界越来越关注使用Calcite作为数据管理项目开发的基石。在下文中，我们将描述不同系统如何使用Calcite。

8.1 嵌入Calcite

表1提供了lib中包含Calcite的软件列表，包括（i）他们向用户公开的查询语言接口，（ii）他们是否使用Calcite的JDBC驱动程序（称为Avatica），（iii）他们是否使用SQL 解析器和验证器包含在Calcite中，（iv）他们是否使用Calcite的查询代数来表示他们对数据的操作，以及（v）他们依赖执行的引擎，例如他们自己的本机引擎，Calcite的运算符（称为可枚举 ），或任何其他项目。

表1：嵌入Calcite的系统列表

Drill是一个灵活的数据处理引擎，基于Dremel系统，内部使用无架构的JSON文档数据模型。Drill使用自己的SQL方言，包括表达半结构化数据查询的扩展，类似于SQL++。

Hive首先是作为在MapReduce编程模型之上的SQL接口流行起来的。它已经成为一个交互式SQL查询应答引擎，采用Calcite作为其规则和基于成本的优化器。Hive不是依赖于Calcite的JDBC驱动程序，SQL解析器和验证器，而是使用它自己的这些组件的实现。然后将查询转换为Calcite运算符，优化后将其转换为Hive的物理代数。Hive操作符可以由多个引擎执行，最流行的是Apache Tez和Apache Spark。

Apache Solr是一个流行的全文分布式搜索平台，建立在Apache Lucene库之上。Solr向用户公开了多个查询接口，包括类似REST的HTTP/XML和JSON API。此外，Solr与Calcite集成以提供SQL兼容性。

Apache Phoenix和Apache Kylin都在Apache HBase之上工作，这是一个以Bigtable为模型的分布式键值存储。特别是，Phoenix提供了一个SQL接口和业务流程层来查询HBase。Kylin专注于OLAP风格的SQL查询，构建被声明为物化视图并存储在HBase中的多维数据集，因此允许Calcite的优化器重写要使用这些多维数据集应答的查询。在Kylin中，使用Calcite原生运算符和HBase来联合执行查询计划。

近年来，Calcite在流处理系统中也很受欢迎。Apache Apex，Flink，Apache Samza和Storm等项目选择与Calcite集成，使用其组件为其用户提供流式SQL接口。最后，其他商业系统采用了Calcite，如MapD，Lingual和Qubole Quark。

8.2 Calcite适配器

其他系统不是使用Calcite作为库，而是通过读取数据源的适配器与Calcite集成。表2提供了Calcite中可用适配器的列表。实现这些适配器的主要关键组件之一是转换器，负责将代数表达式转换为系统支持的查询语言推送到系统。表2还显示了Calcite为每个适配器转换的语言。

JDBC适配器支持生成多种SQL方言，包括流行的RDBMS（如PostgreSQL和MySQL）支持的方言。反过来，Cassandra的适配器生成自己的类SQL语言，称为CQL，而Apache Pig的适配器生成以Pig Latin表示的查询。Apache Spark的适配器使用Java RDD API。最后，通过REST HTTP API请求查询Druid，Elasticsearch和Splunk。Calcite为这些系统生成的查询以JSON或XML表示。

表2：Calcite的适配器列表

8.3 研究中的使用

在研究环境中，Calcite被认为是作为精确医学和临床分析方案的多元替代品。在这些情景中，异质医学数据必须在逻辑上组装和对齐，以基于综合病史和患者的基因组谱来评估最佳治疗。数据来自代表患者电子病历的关系源，结构化和半结构化来源代表存储在科学数据库中的各种报告（肿瘤学，精神学，实验室测试，放射学等），成像，信号和序列数据。在这些情况下，Calcite凭借其统一的查询界面和灵活的适配器架构代表了一种良好的基础，但正在进行的研究工作旨在（i）引入阵列和文本源的新适配器，以及（ii）支持有效加入 异构数据源。

9 展望

Calcite的未来工作将集中在新功能的开发和适配器架构的扩展上：

• 
  

  对Calcite设计的增强，以进一步支持其使用独立引擎，这需要支持数据定义语言（DDL），物化视图，索引和约束。

• 
  

  对计划器的设计和灵活性进行持续改进，包括使其更加模块化，允许用户Calcite提供计划程序（组织成规划阶段的规则集合）以供执行。

• 
  

  将新的参数方法纳入优化器的设计中。

• 
  

  支持一组扩展的包括完全符合OpenGIS的SQL命令，函数和实用程序。

• 
  

  用于非关系数据源的新适配器，例如用于科学计算的阵列数据库。

• 
  

  性能提升。

9.1 性能测试和评估

虽然Calcite包含性能测试模块，但它不会评估查询执行。评估使用Calcite构建的系统的性能会很有用。例如，我们可以将Calcite的性能与类似的框架进行比较。不幸的是，可能很难进行公平的比较。例如，像Calcite一样，Algebricks优化了对Hive的查询。Borkar等人将Algebricks与Hyracks调度程序与Hive版本0.12（不含Calcite）进行了比较。Borkar等人的工作先于将重要的工程和架构变为Hive之前。在计时方面以公平的方式比较Calcite与Algebricks似乎不可行，因为人们需要确保每个使用相同的执行引擎。Hive应用程序主要依赖Apache Tez或Apache Spark作为执行引擎，而Algebricks则依赖于自己的框架（包括Hyracks）。

此外，为了评估基于Calcite的系统的性能，我们需要考虑两个不同的用例。实际上，方解石可以用作单个系统的一部分 - 作为加速这种系统构建的工具 - 或者用于组合几个不同系统的更困难的任务 - 作为公共层。前者与数据处理系统的特性有关，并且因为Calcite非常通用和广泛使用，所以需要许多不同的基准。后者受到现有异构基准测试的限制。BigDAWG 已被用于将PostgreSQL与Vertica集成，并且在标准基准测试中，在整个表从一个系统复制到另一个系统以回答特定查询的情况下，可以得出集成系统优于基线。根据实际经验，我们认为集成多个系统可以实现更宏伟的目标：它们应该优于其各个部分的总和。

10 结论

新兴的数据管理实践和相关的数据分析继续朝着日益多样化和异构的方案范围发展。同时，通过SQL访问的关系数据源仍然是企业如何使用数据的重要手段。在这个有点二分的空间中，Calcite在传统的传统数据处理以及对其他数据源（包括半结构化，流媒体和地理空间模型）的支持方面发挥着独特的作用。此外，Calcite的设计理念侧重于灵活性，适应性和可扩展性，这是Calcite成为最广泛采用的查询优化器的另一个因素，用于大量开源框架。Calcite的动态和灵活的查询优化器及其适配器架构允许通过各种数据管理框架（如Hive，Drill，MapD和Flink）有选择地嵌入它。Calcite对异构数据处理以及扩展的关系函数集的支持将在功能和性能方面继续得到改进。