很多時候，事件本身攜帶的資料仍不足以提供完整的分析資訊。

例如我們發送了訂單事件，但事件內不見得包含完整的商品清單。這時就可以利用資料來源（Data Sources）功能，混合不同來源的資料。

除了工程師常用的資料庫以外，PostHog 還支援非常多常見的資料來源，在這邊就不一一列舉。

以 Postgres 為例，可以設定資料庫的連線資訊以及 SSH Tunnel。不過這邊要求你直接填入 Private Key，而不是提供 Public Key 讓你登記，個人使用時會有一點怕。

三種模式中，我認為 Sync to warehouse 是比較好用的選項，但它採用定時同步，因此除非啟用 CDC，否則會有一定的資料延遲。

Query directly 無法和 PostHog 本身的數據結合使用，因此我認為適用場景比較少。

Sync and query live 看似兼顧兩者，不過以 SQL Insight 的運作方式來看，應該無法完全享受到即時查詢的優勢。實際使用時可以依需求選擇。

下一個畫面會讓你選擇要同步進 PostHog 的表格。每個月可以免費同步 100 萬筆紀錄（第一次連接時的初始導入不計費；未升級到 Pay-as-you-go 方案時則限制最多 1 億筆），後續每 100 萬筆為 $15。

同步方式分為三種：Incremental、Append-Only、Full Refresh。

Incremental 會記錄最後一次查詢時參考欄位的最大值，下一次同步時，只會拉取參考欄位大於該值的紀錄並更新，適合使用更新時間戳記等欄位。

Append-Only 的方式類似，但只會插入、不會更新。因此如果資料庫中的既有紀錄被修改，新的版本會再被插入一次。

Full Refresh 則會在每次同步時重新抓取整張表，比較適合資料量非常少且通常會全部一起更新的表格。

預設同步週期是六小時，可以視需求調整，後續也可以增加新的同步表格或關閉既有同步。

完成後，我們就可以回到 SQL Editor 裡面使用這些資料。

如此一來，像是前面提到的「從訂單事件查詢商品資料」案例，就可以透過 SQL 的關聯查詢來達成。

SELECT
    AVG(items.price) AS avg_order_value
FROM events
JOIN postgres.public__order_items ON events.properties.order_id = postgres.public__order_items.order_id
JOIN postgres.public__items ON postgres.public__order_items.item_id = postgres.public__items.id
WHERE events.event = 'submit_order'

或更進一步，我們可以在 PostHog 建立 Model。

和 SQL Insight 不同，Model 會把查詢結果變成一個可以再次利用的資料模型，並且能夠使用在上一篇文提到的預設分析圖表中。

以我自己的使用場景來說，我們有前述的多表格關聯查詢需求，但最終希望搭配 Bar Chart 與 Breakdown 來呈現結果，此時 SQL Insight 就無法完全滿足需求。

另一方面，我們也有許多基於相同關聯邏輯的分析需求。透過 Model，可以將這些資料整理邏輯集中在同一個地方，減少每個 Insight 分別維護查詢的麻煩。

到這裡，我們已經不再受限於事件本身攜帶的資料。從 SQL Expression、SQL Insight，到外部 Data Sources 與 Model，大部分想分析的資料都已經有辦法整理成適合觀察的形式。

不過，能建立 Insight 並不代表我們會持續去看它。實際上，許多產品問題也很難只靠單一 Insight 判斷，我們通常需要同時關注多個指標、圖表與補充資訊，才能掌握產品目前的狀況。

因此，下一篇文將介紹儀錶盤 Dashboard，看看如何把多個 Insight 與輔助資訊整合在一起，讓一次次的分析變成更容易持續進行的觀察。

如果你願意花 30 秒留下回饋，我會用這些意見來調整後續文章：分享你的意見