Snuba 有一个查问处置管道，首先将 Snuba 查问言语( legacy 和 SnQL)解析为 AST，而后在 Clickhouse 上口头 SQL查问。在这两个阶段之间，在 AST 上口头几次传递以运行查问处置转换。

处置管道有两个关键目的：优化查问并防止对咱们的基础设备导致风险的查问。

在数据模型上，查问处置流水线分为逻辑局部，启动产品关系处置，物理局部专一于优化查问。

逻辑局部蕴含查问验证等步骤，以确保它与数据模型婚配或运行自定义函数。物理局部包括诸如优化标签(promotingtags)和选用预聚合视图(pre-aggregated view)来为查问提供服务等步骤。

查问处置阶段

本节引见了上述各阶段的代码和示例，并提供了一些揭示。

Legacy 和 SnQL 解析器

Snuba 支持两种言语，传统的基于 JSON 的言语和新的名为 SnQL的言语。除了传统言语不支持的衔接和复合查问之外，查问处置管道不会更改能否经常使用一种或另一种言语。

Snuba 支持两种言语，一种是基于 JSON 的旧言语，另一种是名为 SnQL的新言语。除了遗留言语不支持的衔接和复合查问之外，无论经常使用哪种言语，查问处置管道都不会扭转。

它们都生成一个逻辑查问AST，该查问由上方数据结构示意。

基于 JSON 的言语旧解析器源码：

SnQL 解析器：

查问验证(Query Validation)

此阶段确保可以运转查问(大少数状况下，咱们还没有捕捉一切或许的有效查问)。这个阶段的职责是在有效查问的状况下前往一个HTTP，并向用户提供适当的有用信息。

这分为两个子阶段：普通验证(general validation)和实体特定验证(entity specific validation)。

普通验证由一组审核组成，这些审核在解析器生成查问之后立刻运行于每个查问。这在 QueryEntity 函数中出现。这包括防止别名阴影(aliasshadowing)和函数签名验证(function signature validation)等验证。

每个实体也可以以必需列的方式提供一些验证逻辑。这出当初 class Entity(Describable, ABC):。这准许查问处置拒绝在project_id 上没有条件或没有期间范畴的查问。

逻辑查问处置器(Logical Query Processors)

查问处置器是有形态转换，接纳查问对象(及其 AST)并就地转换。这是为逻辑处置器成功的接口。在逻辑阶段，每个实体提供按顺序运行的查问处置器。经常出现的用例是像apdex 这样的自定义函数，或许像期间序列处置器(time series processor)那样的计时。

查问处置器不应该依赖于在之前或之后口头的其余处置器，并且应该彼此独立。

存储选用器(Storage Selector)

如 Snuba 数据模型中所述，每个实体可以定义多个存储。多个存储代表多个表，并且出于性能要素可以定义物化视图(materializedviews)，由于某些视图可以更快地照应某些查问。

在逻辑处置阶段(齐全基于实体)完结时，存储选用器可以审核对询并为查问选用适合的存储。存储选用器在实体数据模型中定义并成功此接口。一个例子是 Errors实体，它有两个存储，一个用于分歧查问(它们被路由到写入事情的相反节点)，另一个只包括咱们没有写入的正原本服务大少数查问。这缩小了咱们写入的节点上的负载。

查问转换器(Query Translator)

不同的 storage 有不同的 schema(这些反映了 clickhouse 表或视图的schema)。它们通常都与实体模型不同，最显着的例子是用于标签 tags[abc] 的可下标表白式，它在 clickhouse 中不存在，其中访问标签看起来像tags.values[indexOf(tags.key, 'abc')]。

选用 storage 后，须要将查问转换为物理查问。Translator 是一个基于规定的系统，规定由实体(针对每个storage)定义并按顺序运行。

与查问处置器相反，翻译规定在查问上没有完整的高低文，只能翻译单个表白式。这使咱们能够轻松地编写翻译规定并跨实体重用它们。

这些是 transactions 实体的转换规定。

物理查问处置器(Physical Query Processors)

与逻辑查问处置器相比，物理查问处置器的上班方式十分相似。它们的接口十分相似，语义相反。不同之处在于它们对物理查问启动操作，因此，它们关键是为优化而设计的。例如，该处置器在标签上找到相等条件，并将它们交流为标签哈希图(有布隆过滤器索引)上的等效条件，从而使过滤操作更快。

查问拆分器(Query Splitter)

经过将某些查问拆分为多个独自的 Clickhouse 查问并组合每个查问的结果，可以以优化的方式口头某些查问。

两个例子是期间拆分和列拆分。两者都在上方这个文件中。

期间拆分(Timesplitting)将一个查问(不蕴含聚合且已正确排序)在一个可变的期间范畴内拆分为多个查问，该期间范畴的大小逐渐增大，并在失掉足够的结果后按顺序中止口头。

列拆分(Column splitting)拆分挑选和列失掉。它对起码数量的列口头查问的挑选局部，以便 Clickhouse加载较少的列，而后经过第二个查问，仅为第一个查问挑选的行失掉缺少的列。

查问格局化器(Query Formatter)

该组件只是将查问格局化为 Clickhouse 查问字符串。

复合查问处置

上方的讨论仅实用于便捷查问、复合查问(衔接和蕴含子查问的查问遵照稍微不同的门路)。

上方讨论的便捷查问管道不实用于衔接查问或蕴含子查问的查问。为了使这项上班施展作用，每个步骤都必定思考衔接的查问和子查问，这会参与环节的复杂性。

为了处置这个疑问，咱们将每个衔接查问转换为多个便捷子查问的衔接。每个子查问都是一个便捷的查问，可以经过上述管道启动处置。这也是运转 Clickhouse衔接(join)的首选方式，由于它准许咱们在衔接之前运行过滤器。

此类查问的查问处置管道由与上述内容关系的几个附加步骤组成。

子查问生成器(Subquery Generator)

该组件驳回一个便捷的 SnQL 衔接查问，并为衔接中的每个表创立一个子查问。

表白式下推(Expressions Push Down)

上一步生成的查问将是一个有效的衔接，但效率极低。这一步基本上是一个衔接优化器(joinoptimizer)，它将一切可以成为子查问一局部的表白式下推到子查问中。这是一个独立于子查问处置的必要步骤，由于 Clickhouse join引擎不口头任何表白式下推，所以它由 Snuba 来优化查问。

便捷查问处置管道(Simple Query Processing Pipeline)

这与上方讨论的从逻辑查问验证到物理查问处置器的管道相反。

衔接优化(Join Optimizations)

在处置完结时，咱们可以对整个复合查问运行一些优化，例如将 join 转换为 Semi Join。