Sentry 監控 - Snuba 資料中臺架構(Data Model 簡介)

為少發表於2021-10-10
架構

系列

本節介紹資料在 Snuba 中的組織方式以及面向使用者的資料如何對映到底層資料庫（如： Clickhouse）。

Snuba 資料模型橫向分為邏輯模型(logical model)和物理模型(physical model)。邏輯資料模型是 Snuba 客戶端通過 Snuba 查詢語言可見的。此模型中的元素可能會也可能不會 1:1 對映到資料庫中的表。相反，物理模型將 1:1 對映到資料庫概念（如表和檢視）。

這種劃分背後的原因是，它允許 Snuba 通過邏輯資料模型公開一個穩定的介面，並在內部執行復雜的對映，對不同的表(物理模型的一部分)執行查詢，以一種對 client 透明的方式提高效能。

本節的其餘部分概述了組成兩個模型的概念以及它們如何相互連線。

下面描述的主要概念是資料集(dataset)、實體(entity)和儲存(storage)。

資料集

Dataset 是 Snuba 資料的名稱空間。它提供了自己的 schema，並且在邏輯模型和物理模型方面都獨立於其他資料集。

資料集的示例是 discover(發現)、outcomes(結果)、sessions(會話)。他們之間沒有任何關係。

資料集可以看作是定義其抽象資料模型及其具體資料模型的元件的容器，如下所述。

實體和實體型別

Snuba 向客戶端公開的邏輯資料模型的基本塊(fundamental block)是實體。在邏輯模型中，實體表示抽象概念（如 transaction 或 error）的例項。在實踐中，Entity 對應於資料庫表中的一行。Entity Type 是實體的類（如 Errors 或 Transactions）。

邏輯資料模型由一組 Entity Types 及其 relationships 組成。

每個 Entity Type 都有一個 schema，該模式由具有相關抽象資料型別的欄位列表定義。 Dataset 的所有 Entity Types（可以有多個）的 schema 組成了對 Snuba client 可見的邏輯資料模型，Snuba 查詢根據該模型進行驗證。 不應該暴露較低階別的概念。

Entity Types 明確包含在 Dataset 中。一個 Entity Type 不能出現在多個資料集中。

實體型別之間的關係

資料集中的實體型別在邏輯上是相關的。支援兩種型別的關係：

  • 實體集關係(Entity Set Relationship)。這模仿了外來鍵。這種關係旨在允許實體型別之間的連線。 目前它只支援一對一和一對多的關係。
  • 繼承關係(Inheritance Relationship)。這模仿了名義上的子型別(subtyping)。 一組實體型別可以共享一個父實體型別。子型別從父型別繼承 schema。 從語義上講，父實體型別必須表示其型別從其繼承的所有實體的聯合。還必須能夠查詢父實體型別。這不能僅僅是一種邏輯關係。

實體型別和一致性

Entity Type 是 Snuba 可以提供一些強大的資料一致性保證的最大單元。具體來說，可以查詢期望 Serializable Consistency(可序列化的一致性) 的實體型別。這不會擴充套件到跨越多個實體型別的任何查詢，在這種情況下，我們最多將具有最終的一致性。

這也會對訂閱查詢(Subscription queries)產生影響。 這些一次只能對一種實體型別起作用，否則，它們將需要實體型別之間的一致性，而我們不支援這種一致性。

請注意!

準確地說，一致性單位（取決於 Entity Type）甚至可以更小，並且取決於資料攝取主題(data ingestion topics)的分割槽方式（例如 project_id），實體型別是 Snuba 允許的最大值。

儲存

Storage 表示並定義 Dataset 的物理資料模型。每個 Storage 表示在物理資料庫概念中具體化，如表或具體化檢視。因此，每個儲存都有一個由欄位及其型別定義的 schema，該欄位反映了 storage 對映到的 DB table/view 的物理模式，並且能夠提供生成 DDL 語句的所有詳細資訊，以在資料庫上構建表。

Storage 能夠將上面討論的邏輯模型中的邏輯概念對映到資料庫的物理概念，因此每個 Storage 都需要與一個 Entity Type 相關聯。具體來說：

  • 每個 Entity Type 必須由至少一個 Readable Storage（我們可以在其上執行查詢的 Storage）支援，但可以由多個 Storage（例如預聚合物化檢視pre-aggregate materialized view）支援。每個 Entity Type 的多個 Storage 旨在允許查詢優化。
  • 每個 Entity Type 必須由一個且僅一個用於攝取資料和填充資料庫表的 Writable Storage 支援。
  • 每個 Storage 僅支援一種 Entity Type。

示例

本節提供了一些示例，說明 Snuba data model 如何表示一些現實世界模型。

這些案例研究不一定反映當前的 Sentry production model，也不一定是同一部署的一部分。它們必須被視為孤立的例子。

單一實體資料集

這看起來像 Sentry 使用的 Outcomes 資料集。這實際上並沒有反映截至 2020 年 4 月的 Outcomes。儘管設計 Outcomes 應該朝著這個方向發展。

該 Dataset 只有一種 Entity Type，代表資料集攝取的單個 Outcome。查詢 raw Outcome 非常緩慢，所以我們有兩個 Storage。一個是反映我們攝取的資料的 Raw storage 和一個計算每小時聚合的 materialized view，查詢效率更高。Query Planner 將根據查詢是否可以在聚合資料上執行來選擇 storage。

多個實體型別資料集

此資料集的典型示例是 Discover 資料集。

這具有三種 Entity Type。Errors、Transactions 並且它們都繼承自 Events。 這些形成了邏輯資料模型，因此查詢 Events Entity Type 給出了 Transactions 和 Errors 的聯合，但它只允許查詢中存在兩者之間的公共欄位。

出於效能原因，Errors Entity Type 由兩個 Storage 支援。 一個是用於攝取資料的主要 Errors Storage，另一個是read only view(只讀檢視)，在查詢時對 Clickhosue 的負載較少，但提供較低的一致性保證。 Transactions 只有一個 storage，並且有一個 Merge Table 來為 Events 提供服務（本質上是兩個表聯合的檢視）。

連線實體型別

這是一個簡單的資料集示例，其中包含可以在查詢中連線在一起的多個實體型別。

GroupedMessage 和 GroupAssingee 可以是帶有 Errors 的 left join 查詢的一部分。其餘部分與前面示例中討論的內容類似。

相關文章