技能 dbt-transformation-patterns
📦
分析團隊常難以應對不一致的資料模型和糟糕的文件。此技能提供經過驗證的模式，用於組織具有適當測試、文件和增量處理的 dbt 專案。
支援: Claude Codex Code(CC)
1
下載技能 ZIP
2
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
3
開啟並開始使用
測試它
正在使用「dbt-transformation-patterns」。 為 Stripe 付款來源建立 staging 模型
預期結果:
- 具有付款表格結構和測試的來源定義 YAML
- 使用 CTE 基礎轉換的 stg_stripe__payments.sql
- 遵循命名慣例的欄位重新命名（id 改為 payment_id，金額從分改為元）
- 使用 unique_key 和 updated_at 篩選的增量設定
正在使用「dbt-transformation-patterns」。 建立具有付款指標的客戶維度
預期結果:
- dim_customers.sql 連結客戶和付款 intermediate 模型
- 使用 dbt_utils 產生代理鍵
- 基於終身價值的客戶分層邏輯
- 具有欄位說明和測試的 YAML 文件
安全審計
安全v1 • 2/24/2026
This skill is safe for publication. Static analysis detected 70 patterns that are all false positives - the flagged content consists of SQL/YAML code examples in markdown documentation, not executable code. The skill provides reference patterns for dbt (data build tool) analytics engineering workflows.
2
已掃描檔案
585
分析行數
0
發現項
1
審計總數
未發現安全問題
審計者: claude
品質評分
38
架構
100
可維護性
87
內容
50
社群
100
安全
91
規範符合性
你能建構什麼
分析工程師建構轉換管線
從第一天起就設定具有適當模型組織、測試和文件的新 dbt 專案。
資料團隊提升模型品質
為現有的 dbt 模型新增全面的測試、文件和新鮮度監控。
工程團隊優化增量載入
為大型 fact 表格實作高效的增量策略以降低運算成本。
試試這些提示
建立 staging 模型
為 [source_name] [table_name] 表格建立 dbt staging 模型。包含帶有欄位說明的來源定義、具有適當重新命名慣例的 staging SQL 模型，以及主鍵和非空約束的基本測試。
建構增量 fact 表格
建立一個名為 fct_[name] 的 dbt 增量 fact 表格模型，追蹤 [business_process]。將其設定為增量 materialization 並使用 [strategy] 策略，定義 unique_key，並使用 is_incremental() 包含增量篩選邏輯。
新增測試和文件
檢視此 dbt 模型 SQL 並產生對應的 YAML 文件檔案。包含模型說明、欄位說明，以及基於現有欄位的適當測試（unique、not_null、relationships、accepted_values）。
設計完整的模型層
為 [domain] 分析工作流設計 dbt 模型結構。定義 [sources] 所需的 staging 模型、用於商業邏輯的 intermediate 模型，以及用於最終輸出的 mart 模型（dimensions 和 facts）。包含每一層的名稱慣例和 materialization 策略。
最佳實務
- 對所有來源資料使用 staging 層 - 清理一次，到處重複使用
- 積極測試，對所有鍵使用 not_null、unique 和 relationship 測試
- 為每個模型和欄位記錄商業背景資訊供下游使用者參考
避免
- 跳過 staging 層並在 marts 中直接查詢來源會造成技術債
- 硬編碼日期或值而非使用 dbt 變數進行設定
- 在多個模型中重複商業邏輯而非提取到可重複使用的 macros
常見問題
什麼是 dbt 中的 medallion 架構？
medallion 架構將模型組織成層：staging（原始資料清理）、intermediate（商業邏輯）和 marts（最終分析表格）。這種分離確保乾淨的資料在您的管線中一致地流動。
我應該何時使用增量 materialization？
對於超過 100 萬列的表格或當來源資料持續增長時，使用增量模型。增量模型只處理新的或變更的記錄，顯著減少運算時間和成本。
我應該為我的模型新增哪些測試？
在所有主鍵上新增 not_null 和 unique 測試，在外鍵上新增 relationship 測試，在必要欄位上新增 not_null，在狀態或類型欄位上新增 accepted_values。使用 dbt_utils.expression_is_true 進行自訂驗證。
如何在 delete+insert 和 merge 增量策略之間選擇？
對於大多數倉儲，預設使用 delete+insert。當您需要使用延遲到達的資料更新現有記錄時使用 merge。對於 BigQuery 或類似平台的分區基礎工作流，使用 insert_overwrite。
ephemeral 模型的目的是什麼？
Ephemeral 模型是不會 materialize 為表格的中間 CTEs。將它們用於總是會被其他模型參考的可重複使用邏輯，減少倉儲中的表格數量。
如何有效地為我的 dbt 專案建立文件？
在 YAML 檔案中為每個模型和欄位新增說明。使用 description 欄位解釋商業邏輯、資料來源和預期值。產生 dbt docs 並為您的團隊提供瀏覽服務。
開發者詳情
作者
sickn33授權
MIT
儲存庫
https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/dbt-transformation-patterns引用
main
檔案結構