Trench

Trench

Frigade · 程式設計

Trench 是 Frigade 推出的免費開源分析基礎架構,在 ClickHouse 與 Kafka 上即時追蹤事件,設計上不需 Cookie 就能運作。

Trench 的介面預覽

關於 Trench

What Is Trench

Trench 是一套事件追蹤系統,由你自己架設,也留在你自己的帳號底下。它記錄使用者在你的應用程式裡做了什麼,像是註冊、完成付款或開啟某個功能,之後讓你用 SQL 或 REST 端點即時查詢這些資料。底層用 Apache Kafka 承接湧入的事件流,用 ClickHouse 快速回答查詢。

Frigade 團隊打造它是為了撐起自家規模化的事件管線,之後以開源形式釋出。如果你曾盯著某個託管分析工具的帳單,納悶為什麼追蹤自己的使用者要花這麼多錢,那這件事就有意義。Trench 鎖定的是想用 Segment 那種追蹤方式、又不想把每個事件送往別人伺服器的開發者。

有兩點決定了你拿到什麼。第一,Trench 遵循 Segment API,所以你已經寫好的 track、identify 與 group 呼叫,通常換個端點就能用。第二,它以單一 Docker 映像檔交付,Kafka 與 ClickHouse 都包在裡面,架設步驟因此變短,但也代表你得自己維運一套真正的資料庫。正式環境的節點至少要準備 4 GB 記憶體與 4 個 CPU 核心。

Getting Started

  1. 複製 FrigadeHQ/trench 儲存庫,開啟 apps/trench 資料夾。
  2. 複製範例環境檔,用 Docker Compose 啟動整套服務,本機的 Kafka 與 ClickHouse 會一起跑起來。
  3. 開啟 4000 埠的伺服器,在環境檔裡找到你的公開金鑰與私密金鑰。
  4. 對 events 端點送出事件,帶上 userId、像是 track 的 type,以及 properties 物件。
  5. 透過 events 端點讀回資料,或用 queries 端點執行 SQL 語句。

產品資訊

快速了解 Trench 的定價、支援平台與效能。

免費方案是
付費方案Usage-based Cloud, custom Enterprise
平台Web (self-hosted) and Cloud
開發者Frigade
類別程式設計
發布日期Nov 2024
最近更新Apr 2026
網站訪問量73
網站全球排名N/A
API 提供狀態是

適合對象

這項工具最適合的使用者、任務與情境。

使用者

  • 想用 Segment 那套追蹤、又不想付託管費的開發者:Trench 說的是同一套 API,你手上既有的 track 與 identify 呼叫通常只要換端點就能沿用。
  • 資料規範嚴格團隊:每個事件都留在你自己的 ClickHouse 執行個體裡,這點與 GDPR 相符,因為原始資料不落在第三方手上。
  • 已經在跑 Kafka 的工程師:整套架構建立在熟悉的工具上,所以你能用調整其他管線的方式來調校吞吐量。

任務

  • 追蹤產品事件:送出 userId、事件名稱與屬性,幾秒後就能用查詢讀回來。
  • 用 SQL 查行為:對 ClickHouse 儲存層下語句,統計註冊數或彙整活動,不必把資料匯出到別處。
  • 把事件送往其他工具:把 webhook 指向另一個服務,讓新事件落到團隊原本工作的地方。

情境

  • 打造產品分析儀表板:把原始事件拉進自己的介面,不必為每個被追蹤的使用者付費。
  • 讓合規審查者放心:證明個人資料從不離開你掌控的基礎架構。
  • 試作需要使用者脈絡的語言模型流程:查詢已存放的事件,餵給你原本就在跑的檢索步驟。

主要功能

相容 Segment 的追蹤 API

Trench 在 track、identify 與 group 呼叫上遵循 Segment API。如果你的應用程式已用這種格式送出事件,只要把它指向 Trench 的端點,就能保留現有程式碼。這份相容性,正是搬遷只需幾小時、而非重寫的主要原因。

單一 Docker 映像檔部署

整套系統以一個可上線的 Docker 映像檔交付,Kafka 與 ClickHouse 都包含在內。你跑一行 Compose 指令就有一套能動的服務,不用手動串起三個元件。代價是硬體:正式環境的節點至少要有 4 GB 記憶體與 4 個核心。

建立在 Kafka 與 ClickHouse 上的即時吞吐

Kafka 承接湧入的事件流,ClickHouse 回答查詢。單一節點就能撐住每秒數千個事件,而同樣這兩套工具正為 Airbnb、Spotify 等公司追蹤數兆筆事件。對獨自開發的人或小團隊來說,一個節點能撐很久,之後才需要擴充。

SQL 與 REST 查詢

你不必另開一套 BI 工具才能讀資料。events 端點以 JSON 回傳已存放的事件,queries 端點則對 ClickHouse 儲存層執行原始 SQL。統計每日活躍使用者或依屬性彙整事件,都只是一句簡短語句,不是一份匯出工作。

Webhook 目的地

設有流量調節的 webhook 會把新事件推往其他服務。這讓 Trench 坐落在整條管線的中間,接住事件再轉送到 CRM、資料倉儲或告警工具。你就不必為了搬動資料而另寫一個轉送器。

優缺點

優點

  • 以 MIT 授權開源,程式碼任你閱讀與修改。
  • 自行架設免費且沒有用量上限,省掉依事件計費的開銷。
  • 遵循 Segment API,既有追蹤程式碼通常能繼續運作。
  • 資料留在你自己的 ClickHouse 執行個體,對 GDPR 有幫助。
  • 單一 Docker 映像檔整合 Kafka 與 ClickHouse,精簡架設步驟。

缺點

  • 你要維運 Kafka 與 ClickHouse,正式環境節點至少得準備 4 GB 記憶體與 4 個核心。
  • 沒有內建儀表板:想看圖表得自己接 Grafana 或自建介面。
  • 自己維運就代表更新、備份與可用性都要自己扛。
  • 託管的 Cloud 方案雖然存在,卻沒有公布固定價格,需要另外詢價。

常見問題

Trench 追蹤你自己產品裡的事件,並存放起來供即時分析。你透過一套遵循 Segment 規格的 API 送出事件,再用 SQL 或 REST 呼叫查詢,看看使用者做了什麼。