Calcite 只支持于关系型数据模型（不支持层次，网状，对象数据库的模型）

calcite 是一个能够连接异构数据源，并运行优化的查询计划的基础框架 。Cacite 提供查询处理需要的三大功能：查询语言，查询优化和查询执行。 但是calcite 并不想做这样“one size fit all " 的框架， 它提供足够灵活适配接口， 使外部系统 （数据源（或称存储系统），或查询处理系统）能够选择合适的场景与它适配 。calcite 支持的场景主要有两种， 如上图描述。

       在场景1中，calcite 作为独立运行的进程，后台通过适配器与外部的存储系统连接，前台通过JDBC 接口 使用SQL 语言通用户交互 。在这个场景里，calcite 作为一个中间件，为一些没有或缺乏友好的查询语言的存储系统（比如HBase, Cassandra, Kafka, ES, Redis） 提供查询语言（比如SQL）。 calcite在 内部将用户提交的查询优化并运行再自己的进程里，并在优化的过程中将适当的部分下推给存储系统 。比如Cassandra 有部分关系扫描（tableScan), 过滤（Filter), 投影（Proction) 和聚合（Aggregation）的能力， calcite 能将相应关系表达式翻译成Cassandra 的语言发送给它并返回结果。对于 Cassandra 不具备的能力，比如连接（ join），这部分关系表达式在calcite 里运行 。当然这儿场景并不是calcite 擅长的，因为query 执行不是它所擅长的。        在场景2中，calcite 作为嵌入式的组件运行在一个查询引擎里。这些查询引擎用自己的方式连接后台数据源，并使用自己的集群用分布的方式执行查询。  查询引擎善于获取数据和执行查询，需要calcite 提供查询语言和优化查询的能力 。 这个场景的例子有Hive , Flink, Drill , Storm 。 以 Flink 为例， 它的框架里有算子连接各样的异构数据源用于数据的获取和发布，无论是数据流还是数据集。  它也有丰富的算子将讲这些数据过滤、放大、缩小和变形用于各种各样计算需求。他需要一种对用户友好的， 对于批流数据语义统一的查询语言，以便于用户编排查询作业流程，经过优化器后后， 作业能够最小的代价运行在Flink集群中。 场景2是calcite 最受欢迎的和最擅长的场景， 相比查询执行, 连接数据源， calcite 更擅长的是制造查询语言，解析查询， 和查询优化 。为什么这么说呢 , 那就要看看 它的架构了。 绿色框框QueryOptimizer （优化器， 也称Planner, 比如HepPlanner, VolcanoPlanner)是calcite 的心脏和大脑，它接受查询计划，输出优化的查询计划 。      蓝色的框框是优化器的输入和输出和各种适配器，包括Opeator Expressions (输入的原始计划，中间结果和最后输出的计划）, MetadataProvider(提供元数据的组件，比如对优化规则用的统计信息（RowCount of table, Distinct RowCout/min/max of a column , etc )  还有pluggable Rules (优化规则, 利用关系代数或关系演算的等价关系，优化执行计划，使之更够最快速的执行)。这三个组件是calcite 可扩展部分，因此与外部系统有连接 。      黄色框框（Data Processing System， 简称DPS)与蓝色框框有虚线连接，是DPS 对calcite 的扩展部分。  这里的Data Processing System所指的就是场景2里的查询引擎。它通过扩展metadata provider 和 pluggable rules , 向优化器提供更准确的元数据信息，更适合的代价模型， 更高效的优化规则， 利用calcite 优化器产生最优化查询计划。SQL parser and validator, 是Calcite的SQL 语言的解释器， 它将用用户用SQL语言编写的查询解析称Opeator Expressions ， 并验证它的合法性 。          Opeator Expressions是一种用于表示关系代数表达式的树状数据结构。解释器将SQL 查询解释成关系代数表达式， 之后优化器调用规则将其修改为最优表达式。优化规则会根据有关系代数的等价原理将表达式变形从而使表达式的代价降低。但如何判断代价是否降低？ 办法有两种：一种是根据经验，一种是根据代价模型。根据经验学名称做启发式（Heuristic )模型, 根据代价模型估计的，学名叫火山模型。 相应的优化器也被称作启发式优化器和火山优化器（HepPlanner, VocanoPlanner)。         代价模型的量化计算是根据从metadata provider获取关系及关系运算的元数据，再辅以量化模型的计算。元数据通常指的是一个关系（table）和关系运算(projection, filter, join, aggregation, etc)产生关系的统计数据：如关系的row count, 某个分量的 distinct count， min, max 等 。DPS 会扩展Calcite 逻辑关系表达式产生“物理”关系表达式, 而这些扩展的表达式也会输入给优化器， 利用规则继续优化 。          Expression Builder 是一种绕过SQL解析，直接生成关系表达式的工具。 这种方式适用于单元测试，就不做展开展开介绍了。

标签：场景,支持,查询,表达式,SQL,Calcite,优化,calcite,数据模型
来源： https://www.cnblogs.com/timengmen/p/14487792.html