专栏首页黑客下午茶Sentry 监控 - Snuba 数据中台架构(Query Processing 简介)

Sentry 监控 - Snuba 数据中台架构(Query Processing 简介)

Snuba 有一个查询处理管道,首先将 Snuba 查询语言( legacySnQL)解析为 AST,然后在 Clickhouse 上执行 SQL 查询。在这两个阶段之间,在 AST 上执行几次传递以应用查询处理转换。

处理管道有两个主要目标:优化查询并防止对我们的基础设施构成危险的查询。

在数据模型上,查询处理流水线分为逻辑部分,进行产品相关处理,物理部分专注于优化查询。

逻辑部分包含查询验证等步骤,以确保它与数据模型匹配或应用自定义函数。物理部分包括诸如提升标签(promoting tags)和选择预聚合视图(pre-aggregated view)来为查询提供服务等步骤。

查询处理阶段

本节介绍了上述各阶段的代码和示例,并提供了一些提示。

Legacy 和 SnQL 解析器

Snuba 支持两种语言,传统的基于 JSON 的语言和新的名为 SnQL 的语言。除了传统语言不支持的连接和复合查询之外,查询处理管道不会更改是否使用一种或另一种语言。

Snuba 支持两种语言,一种是基于 JSON 的旧语言,另一种是名为 SnQL 的新语言。除了遗留语言不支持的连接和复合查询之外,无论使用哪种语言,查询处理管道都不会改变。

它们都生成一个逻辑查询AST,该查询由下面数据结构表示。

  • https://github.com/getsentry/snuba/tree/master/snuba/query

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

  • https://github.com/getsentry/snuba/blob/master/snuba/query/parser/__init__.py

SnQL 解析器:

  • https://github.com/getsentry/snuba/tree/master/snuba/query/snql

查询验证(Query Validation)

此阶段确保可以运行查询(大多数情况下,我们还没有捕获所有可能的无效查询)。这个阶段的职责是在无效查询的情况下返回一个 HTTP400,并向用户提供适当的有用消息。

这分为两个子阶段:一般验证(general validation)和实体特定验证(entity specific validation)。

一般验证由一组检查组成,这些检查在解析器生成查询之后立即应用于每个查询。这在 QueryEntity 函数中发生。这包括防止别名阴影(alias shadowing)和函数签名验证(function signature validation)等验证。

  • QueryEntity:https://github.com/getsentry/snuba/blob/master/snuba/query/parser/__init__.py#L91

每个实体也可以以必需列的形式提供一些验证逻辑。这发生在 class Entity(Describable, ABC):。这允许查询处理拒绝在 project_id 上没有条件或没有时间范围的查询。

  • https://github.com/getsentry/snuba/blob/master/snuba/datasets/entity.py#L46-L47

逻辑查询处理器(Logical Query Processors)

查询处理器是无状态转换,接收查询对象(及其 AST)并就地转换。这是为逻辑处理器实现的接口。在逻辑阶段,每个实体提供按顺序应用的查询处理器。常见的用例是像 apdex 这样的自定义函数,或者像时间序列处理器(time series processor)那样的计时。

  • apdex: https://github.com/getsentry/snuba/blob/10b747da57d7d833374984d5eb31151393577911/snuba/query/processors/performance_expressions.py#L12-L20
  • time series processor:https://github.com/getsentry/snuba/blob/master/snuba/query/processors/timeseries_processor.py

查询处理器不应该依赖于在之前或之后执行的其他处理器,并且应该彼此独立。

存储选择器(Storage Selector)

如 Snuba 数据模型中所述,每个实体可以定义多个存储。多个存储代表多个表,并且出于性能原因可以定义物化视图(materialized views),因为某些视图可以更快地响应某些查询。

在逻辑处理阶段(完全基于实体)结束时,存储选择器可以检查查询并为查询选择合适的存储。存储选择器在实体数据模型中定义并实现此接口。一个例子是 Errors 实体,它有两个存储,一个用于一致查询(它们被路由到写入事件的相同节点),另一个只包括我们没有写入的副本来服务大多数查询。这减少了我们写入的节点上的负载。

  • https://github.com/getsentry/snuba/blob/master/snuba/datasets/storage.py#L155-L165

查询转换器(Query Translator)

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

选择 storage 后,需要将查询转换为物理查询。Translator 是一个基于规则的系统,规则由实体(针对每个 storage)定义并按顺序应用。

与查询处理器相反,翻译规则在查询上没有完整的上下文,只能翻译单个表达式。这使我们能够轻松地编写翻译规则并跨实体重用它们。

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

  • https://github.com/getsentry/snuba/blob/master/snuba/datasets/entities/transactions.py#L33-L81

物理查询处理器(Physical Query Processors)

与逻辑查询处理器相比,物理查询处理器的工作方式非常相似。它们的接口非常相似,语义相同。不同之处在于它们对物理查询进行操作,因此,它们主要是为优化而设计的。例如,该处理器在标签上找到相等条件,并将它们替换为标签哈希图(有布隆过滤器索引)上的等效条件,从而使过滤操作更快。

  • https://github.com/getsentry/snuba/blob/master/snuba/query/processors/mapping_optimizer.py

查询拆分器(Query Splitter)

通过将某些查询拆分为多个单独的 Clickhouse 查询并组合每个查询的结果,可以以优化的方式执行某些查询。

两个例子是时间拆分和列拆分。两者都在下面这个文件中。

  • https://github.com/getsentry/snuba/blob/master/snuba/web/split.py

时间拆分(Time splitting)将一个查询(不包含聚合且已正确排序)在一个可变的时间范围内拆分为多个查询,该时间范围的大小逐渐增大,并在得到足够的结果后按顺序停止执行。

列拆分(Column splitting)拆分筛选和列获取。它对最少数量的列执行查询的筛选部分,以便 Clickhouse 加载较少的列,然后通过第二个查询,仅为第一个查询筛选的行获取缺少的列。

查询格式化器(Query Formatter)

该组件只是将查询格式化为 Clickhouse 查询字符串。

复合查询处理

上面的讨论仅适用于简单查询、复合查询(连接和包含子查询的查询遵循稍微不同的路径)。

上面讨论的简单查询管道不适用于连接查询或包含子查询的查询。为了使这项工作发挥作用,每个步骤都必须考虑连接的查询和子查询,这会增加过程的复杂性。

为了解决这个问题,我们将每个连接查询转换为多个简单子查询的连接。每个子查询都是一个简单的查询,可以通过上述管道进行处理。这也是运行 Clickhouse 连接(join)的首选方式,因为它允许我们在连接之前应用过滤器。

此类查询的查询处理管道由与上述内容相关的几个附加步骤组成。

子查询生成器(Subquery Generator)

该组件采用一个简单的 SnQL 连接查询,并为连接中的每个表创建一个子查询。

表达式下推(Expressions Push Down)

上一步生成的查询将是一个有效的连接,但效率极低。这一步基本上是一个连接优化器(join optimizer),它将所有可以成为子查询一部分的表达式下推到子查询中。这是一个独立于子查询处理的必要步骤,因为 Clickhouse join 引擎不执行任何表达式下推,所以它由 Snuba 来优化查询。

简单查询处理管道(Simple Query Processing Pipeline)

这与上面讨论的从逻辑查询验证到物理查询处理器的管道相同。

连接优化(Join Optimizations)

在处理结束时,我们可以对整个复合查询应用一些优化,例如将 join 转换为 Semi Join

本文分享自微信公众号 - 黑客下午茶(hi-weishao),作者:为少

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-10-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Sentry 监控 - Snuba 数据中台架构(Data Model 简介)

    本节介绍数据在 Snuba 中的组织方式以及面向用户的数据如何映射到底层数据库(如: Clickhouse)。

    为少
  • Sentry 监控 - Snuba 数据中台架构简介(Kafka+Clickhouse)

    Snuba 是一种在 Clickhouse 之上提供丰富数据模型以及快速摄取消费者(直接从 Kafka 获取数据)和查询优化器的服务。

    为少
  • Snuba:Sentry 新的搜索基础设施(基于 ClickHouse 之上)

    Sentry 已经在名为 Search,Tagstore(用于事件标签)和 TSDB(时间序列数据库,为大多数图形提供动力)的抽象服务接口上运行。这些服务中的每...

    为少
  • 抓 Bug 神器的工作原理——聊聊 Sentry 的架构

    Sentry 是什么?这是一个用于错误上报的服务中心,使用近乎一致的 API 设计,统一了不同语言生产环境代码异常上报的难题。

    benny
  • 抓 Bug 神器的工作原理——聊聊 Sentry 的架构

    Sentry 是什么?这是一个用于错误上报的服务中心,使用近乎一致的 API 设计,统一了不同语言生产环境代码异常上报的难题。

    FesonX
  • Sentry(v20.12.1) K8S云原生架构探索,玩转前/后端监控与事件日志大数据分析,高性能高可用+可扩展可伸缩集群部署

    Sentry 算是目前开源界集错误监控,日志打点上报,事件数据实时分析最好用的软件了,没有之一。将它部署到 Kubernetes,再搭配它本身自带的利用 Cli...

    为少
  • Sentry 10 K8S 云原生架构探索,Vue App 1 分钟快速接入

    Sentry 10 算是目前开源界集错误监控,日志打点上报,事件数据实时分析最好用的软件了,没有之一。将它部署到 Kubernetes,再搭配它本身自带的利用 ...

    为少
  • Apache Sentry实战之旅(一)—— Impala+Sentry整合

    Impala默认是以impala这个超级用户运行服务,执行DML和DDL操作的,要实现不同用户之间细粒度的权限控制,需要与Sentry整合。Sentry是Apa...

    九州暮云
  • 基于 Vue 和 TS 的 Web 移动端项目实战心得

    来源:https://juejin.im/post/5d759f706fb9a06afa32adec

    coder_koala
  • 移动 web 最佳实践(干货长文)

    https://juejin.im/post/5d759f706fb9a06afa32adec

    前端迷
  • 移动 Web 最佳实践(干货长文,建议收藏)

    https://juejin.im/post/5d759f706fb9a06afa32adec

    coder_koala
  • 基于 Vue 和 TS 的 Web 移动端项目实战心得

    来源:https://juejin.im/post/5d759f706fb9a06afa32adec

    ConardLi
  • Sentry(v20.12.1) K8S 云原生架构探索,JavaScript 性能监控之管理 Transactions

    @sentry/tracing 包提供了一个 BrowserTracing 集成,以添加 automatic instrumentation 来监视浏览器应用程...

    为少
  • 学习 sentry 源码整体架构,打造属于自己的前端异常监控SDK

    这是学习源码整体架构第四篇。整体架构这词语好像有点大,姑且就算是源码整体结构吧,主要就是学习是代码整体结构,不深究其他不是主线的具体函数的实现。文章学习的是打包...

    若川
  • 如何使用Sentry为Solr赋权

    Fayson
  • Cloudera Streams Management正式GA

    上个月Cloudera发布Cloudera Stream Processing,这个解决方案让所有Cloudera客户都能获得最新的,安全版本的Apache K...

    Fayson
  • 使用Sentry对前端进行实时js错误监控

    Sentry 为一套开源的应用监控和错误追踪的解决方案。这套解决方案由对应各种语言的 SDK 和一套庞大的数据后台服务组成。应用需要通过与之绑定的 token ...

    常见_youmen
  • 从架构角度来看 Java 分布式日志如何收集

    本文来自作者 张振华 在 GitChat 上分享 「从架构角度来看 Java 分布式日志如何收集」

    CSDN技术头条
  • Sentry 监控 - Distributed Tracing 分布式跟踪

    分布式跟踪(Distributed tracing)通过捕获软件系统之间的交互来提供相关错误和事务的连接视图。通过跟踪,Sentry 可以跟踪您的软件性能并显示...

    为少

扫码关注云+社区

领取腾讯云代金券