本文转载自微信公众号「黑客下午茶」，作者很少。转载本文，请联系黑客下午茶微信官方账号。
Snuba 在 Clickhouse 提供丰富的数据模型和消费者的快速摄入(直接从 Kafka 获取数据)和查询优化器的服务。
Snuba 的最初开发目的是取代 Postgres 和 Redis 的组合是搜索和提供 Sentry 错误的聚合数据。从那时起，它已经演变成现在的形式，支持大多数与时间序列相关的 Sentry 功能。
功能
- 为 Clickhouse 分布式数据存储提供数据库访问层。
- 通过 提供图形逻辑数据模型SnQL 语言查询类似于 SQL 的功能。
- 多个单独的数据集支持单个安装。
- 提供基于规则的查询优化器。
- 将 提供一个迁移系统DDL 在单节点和分布式环境中改变 Clickhouse。
- 直接从 Kafka 摄取数据
- 支持时间点查询和流式查询。
Sentry 中的一些用例：
- events 数据集为 Issue Page 等功能提供支持。此处的搜索功能由 Snuba 以及所有的聚合物(aggregation)函数提供支持。
- discover 所有性能监测数据集(Performance Monitoring)支持相关功能。
- sessions 发布数据集(Releases)功能提供支持。具体来说，数据集会摄取大量数据点并存储预先聚合的数据，以便快速查询大量数据。
- outcomes 数据集为统计页面(Stats page)提供支持。
开始使用 Snuba
这是在 Sentry 在开发环境中快速启动 Snuba 的指南。
必要条件
Snuba 假设如下：
使这些服务运行的快速方法是设置 sentry，然后使用：
请注意，Snuba 假设一切都在 UTC 时间运行。否则，您可能会遇到时区不匹配的问题。
Sentry Snuba
在 ~/.sentry/sentry.conf.py 添加/更改以下行：
运行：
访问原始 clickhouse client(类似于 psql)：
数据写入表 sentry_local: select count() from sentry_local;
设置
设置可在 settings.py 中找到
- CLUSTERS：提供集群列表和运行的集群列表和主机名称(hostname)、端口(port)和存储集(storage sets)。每个集群也设置本地和分布式(Local vs distributed)。
- REDIS_HOST：redis 在这里运行。
Snuba 架构概述
Snuba 是由 Clickhouse 支持面向时间序列的数据存储服务，是列式存储分布式数据库，非常适合 Snuba 服务查询类型。
- https://clickhouse.tech/
数据完全存储在 Clickhouse 表和物化(materialized)在视图中，它通过输入流(目前只有 Kafka topic)并且可以通过时间点查询或流式查询(subscriptions)进行查询。
存储
选择 的原因Clickhouse 作为后备存储，是因为它在 Snuba 在实时性能、分布式和复制性能、存储引擎的灵活性和一致性之间提供了良好的平衡。
Snuba 数据存储在 Clickhouse 表和 Clickhouse 物化视图(materialized views)中间。根据表的目标使用多个 Clickhouse 存储引擎。
- https://clickhouse.tech/docs/en/engines/table-engines/
Snuba 数据组织集中在多个数据集中，表示数据模型的独立分区。Snuba 数据模型部分。
摄取
Snuba 不提供入行提供 api 端点(除非在调试模式下运行)。数据从多个输入流加载，由一系列消费者处理并写入 Clickhouse 表。
一个 consumer 消费一个或多个 topic 并写入一个或多个表格。到目前为止，还没有多个消费者写入表格。这允许以下讨论的一致性保证。
数据摄取(Data ingestion)最有效的批处理(对 Kafka 但特别是 Clickhouse)。我们的 consumer 支持批处理，确保从 Kafka 获得的一批事件至少传递给 Clickhouse 一次。通过正确选择 Clickhouse 表引擎删除重复数据，如果我们接受最终的一致性，我们可以实现正确的语义。
查询
最简单的查询系统是时间点。SnQL 语言(SnQL 查询语言)表示，作为 HTTP post 调用发送。查询引擎处理查询(Snuba 查询处理中描述的过程)并将其转换为 ClickHouse 查询。
流式查询(通过订阅引擎完成)允许客户端推送查询结果。在这种情况下，HTTP 端点允许客户注册流查询。然后订阅 Consumer 用于填充相关 Clickhouse 表更新 topic，定期查询查询引擎并订阅 Kafka topic 上生成结果。
数据一致性
不同一致性模型在 Snuba 并存提供不同的保证。
默认情况下，Snuba 是最是一致的。运行查询时，默认情况下不能保证单调读取(monotonic reads)，因为 Clickhouse 是多领导者(multi-leader)，查询可以命中任何副本，不能保证副本是最新的。另外，默认情况下，不能保证 Clickhouse 将自行达到一致状态。
通过强制 Clickhouse 在实施查询前达到一致性(FINAL keyword)，并强制查询命中 consumer 写的特定副本在特定查询中可以达到很强的一致性。本质上， Clickhouse，就像它是一个单一的领导体系(single leader system)，它允许顺序一致性(Sequential consistency)。
Sentry 部署中的 Snuba
这一节解释了 Snuba 显示主要数据流Sentry 部署中的角色。如果单独部署 Snuba，这对你没用。
Errors 和 Transactions 数据流
图表顶部的主要部分说明 Events 和 Transactions 实体的摄入过程。这两个实体是 Sentry 和整个 Performance 产品中的大多数问题/错误(issue/errors)相关功能提供服务。
只有一个 Kafka topic(events)在 errors 和 transactions 之间的共享条管道提供信息。topic 包含 error 消息和 transaction 消息。
Errors consumers 使用 events topic，在 Clickhouse errors 信息写在表中。提交后，还会产生 snuba-commit-log topic 的记录。
错误报警Errors Subscription Consumer 生成。这是同步消费者。(synchronized consumer)，同时消费者 events topic 和 snuba-commit-log topic，因此它可以与主 consumer 同步进行。
synchronized consumer 然后通过查询 Clickhouse 生成警报，并在 result topic 产生结果。
transactions 存在于同一但独立的管道中。
Errors 管道还有一个额外的步骤:写入 replacements topic。Sentry 在 events topic 上产生 Errors mutations(合并/取消合并/再处理/等)。Errors Consumer 把它们转发给 replacements topic，并由 Replacement Consumer 执行。
events topic 必须按 Sentry project id 语义上分区，允许项目中的事件按顺序处理。到目前为止，这是 alerts 和 replacements 的要求。
Sessions 与 Outcomes
Sessions 和 Outcomes 以非常相似和简单的方式工作。尤其是 Sessions 增强 Release Health 功能， Outcomes 主要向 Sentry 统计页面提供数据。
两条管道都有自己的 Kafka topic，Kafka consumer，它们在 Clickhouse 写下自己的表。
更改数据捕获管道
该管道仍在建设中。它使用 cdc topic 并填充 Clickhouse 两个独立表。