本文转载自微信公众号《黑客下午茶》，作者寥寥。转载本文请联系黑客下午茶公众号。Snuba是一项在Clickhouse之上提供丰富数据模型的服务，以及快速摄取消费者（直接从Kafka获取数据）和查询优化器。Snuba最初是为了取代Postgres和Redis的组合而开发的，用于搜索和提供有关哨兵错误的聚合数据。从那时起，它已经演变成现在的形式，支持多个数据集上大多数与时间序列相关的哨兵功能。功能为Clickhouse分布式数据存储提供数据库访问层。提供客户端可以通过SnQL语言查询的图逻辑数据模型，提供类SQL功能。单个安装支持多个单独的数据集。提供基于规则的查询优化器。提供迁移系统以在单节点和分布式环境中将DDL更改应用于Clickhouse。直接从Kafka获取数据支持时间点查询和流式查询。Sentry中的一些用例：事件数据集支持IssuePage等功能。此处的搜索功能由Snuba以及所有聚合功能提供支持。发现数据集为所有性能监控相关功能提供支持。会话数据集为发布功能提供支持。具体来说，数据集摄取大量数据点并存储预先聚合的数据，以允许对大量数据进行快速查询。结果数据集为统计页面提供支持。Snuba入门这是在Sentry开发环境中快速启动Snuba的指南。先决条件Snuba假设如下：Clickhouse服务器端点位于CLICKHOUSE_HOST（默认本地主机）。在REDIS_HOST（默认本地主机）上运行的redis实例。在端口6379上。让这些服务运行的快速方法是设置哨兵，然后使用：sentrydevservicesup--exclude=snuba请注意，Snuba假设一切都在UTC时间运行。否则，您可能会遇到时区不匹配的问题。Sentry+Snuba在~/.sentry/snuba.py.snuba.SnubaEventStream中添加/更改以下行'run:sentrydevservicesupaccessrawclickhouseclient(类似于psql):dockerexec-itsentry_clickhouseclickhouse-clientdataiswrittentotablesentry_local:select来自sentry_local的count()；settings设置可以在settings.py中找到CLUSTERS：提供集群列表以及应该在每个集群上运行的主机名、端口和存储集。每个集群也设置为本地和分布式（本地与分布式）。REDIS_HOST：这里运行redis。Snuba架构概述Snuba是Clickhouse支持的面向时间序列的数据存储服务。是一个列式存储的分布式数据库，非常适合Snuba服务的查询类型。https://clickhouse.tech/数据完全存储在Clickhouse表和物化视图中，通过输入流（目前只有Kafka主题）摄取，可以通过时间点查询或流式查询（订阅）进行查询。存储之所以??选择Clickhouse作为后备存储，是因为它在实时性能、分布式和复制性、存储引擎方面的灵活性以及Snuba需要的一致性保证之间提供了很好的平衡。Snuba数据存储在Clickhouse表和Clickhouse物化视图中。根据表的目标使用多个Clickhouse存储引擎。https://clickhouse.tech/docs/en/engines/table-engines/Snuba数据组织在多个数据集中，代表数据模型的独立分区。有关详细信息，请参阅Snuba数据模型部分。IngestSnuba不提供用于插入行的api端点（除非在调试模式下运行）。数据从多个输入流加载，由一系列消费者处理并写入Clickhouse表。消费者消费一个或多个主题并写入一个或多个表。到目前为止，还没有多个消费者写入表。这允许下面讨论的一些一致性保证。数据摄取在批处理中最有效（对于Kafka但尤其是对于Clickhouse）。我们的consumer支持批处理，保证从Kafka获取的一批event至少一次投递到Clickhouse。通过正确选择Clickhouse表引擎对行进行重复数据删除，如果我们接受最终一致性，我们可以实现精确一次语义。查询最简单的查询系统是一个时间点。查询以SnQL语言（SnQL查询语言）表达，并作为HTTPpost调用发送。查询引擎处理查询（Snuba查询处理中描述的过程）并将它们转换为ClickHouse查询。流式查询（通过订阅引擎完成）允许客户端以推送方式接收查询结果。在这种情况下，HTTP端点允许客户端注册流式查询。然后订阅Consumer消费用于填充相关Clickhouse表的主题进行更新，通过查询引擎定期运行查询并在订阅的Kafka主题上生成结果。数据一致性不同的一致性模型在Snuba中并存，提供不同的保证。默认情况下，Snuba是最终一致的。在运行查询时，默认情况下，不保证单调读取（monotonicreads），因为Clickhouse是多领导者（multi-leader），查询可以命中任何副本，不保证副本是最新的.此外，默认情况下，无法保证Clickhouse会自行达到一致状态。通过强制Clickhouse在执行查询之前达到一致性（FINAL关键字），并强制查询命中消费者编写的特定副本，可以在特定查询上实现强一致性。这本质上将Clickhouse用作单个领导者系统，从而实现顺序一致性。Snuba在Sentry部署中本节解释Snuba在Sentry部署中扮演的角色，显示主要数据流。如果您单独部署Snuba，这对您没有用。错误和事务数据流图顶部的主要部分说明了事件和事务实体的摄取过程。这两个实体服务于Sentry和整体性能产品中大多数问题/错误相关的功能。只有一个Kafka主题（事件）在错误和事务之间共享，为该管道提供数据。本主题包含错误消息和事务消息。错误消费者使用事件主题并将消息写入Clickhouse错误表。提交后，它还会在snuba-commit-log主题上生成日志记录。错误警报由错误订阅消费者生成。这是一个同步消费者，它同时消费主事件主题和snuba-commit-log主题，因此它可以与主消费者同步进行。然后，同步的消费者通过查询Clickhouse生成警报，并在结果主题上生成结果。事务存在于相同但独立的管道中。错误管道有一个额外的步骤：写入替换主题。Sentry在事件主题上生成错误突变（合并/取消合并/重新处理/等）。错误消费者然后将它们转发到替换主题并由替换消费者执行。事件主题必须按Sentry项目ID进行语义分区，以允许在项目内顺序处理事件。到目前为止，这是警报和替换的要求。会话和结果会话和结果以非常相似和更简单的方式工作。特别是Sessions增强了ReleaseHealth功能，而Outcomes主要是为Sentry统计页面提供数据。两条管道都有自己的Kafka主题，即Kafka消费者，它们在Clickhouse中编写自己的表。更改数据捕获管道此管道仍在建设中。它使用cdc主题并在Clickhouse中填充两个单独的表。
