分析チームは、一貫性のないデータモデルと不十分なドキュメンテーションに悩まされています。このスキルは、適切なテスト、ドキュメンテーション、増分処理を備えた dbt プロジェクトを構築するための実証済みのパターンを提供します。
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "dbt-transformation-patterns". Stripe payments ソース用の staging モデルを作成
Résultat attendu:
- payments テーブルスキーマとテストを含むソース定義 YAML
- CTE ベースの変換を含む stg_stripe__payments.sql
- 命名規則に従ったカラムのリネーム(id を payment_id に、amount in cents を dollars に)
- unique_key と updated_at フィルターを含む増分設定
Utilisation de "dbt-transformation-patterns". 支払いメトリクスを含むカスタマーディメンションを構築
Résultat attendu:
- 顧客と支払いの intermediate モデルを結合する dim_customers.sql
- dbt_utils を使用したサロゲートキー生成
- ライフタイムバリューに基づくカスタマーティアセグメンテーションロジック
- カラムの説明とテストを含む YAML ドキュメンテーション
Audit de sécurité
SûrThis 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.
Score de qualité
Ce que vous pouvez construire
変換パイプラインを構築するアナリティクスエンジニア
初日から適切なモデル整理、テスト、ドキュメンテーションを備えた新しい dbt プロジェクトをセットアップします。
モデル品質を向上させるデータチーム
既存の dbt モデルに包括的なテスト、ドキュメンテーション、鮮度監視を追加します。
増分ロードを最適化するエンジニアリングチーム
大規模ファクトテーブル向けの効率的な増分戦略を実装して、コンピューティングコストを削減します。
Essayez ces prompts
[source_name] [table_name] テーブル用の dbt staging モデルを作成してください。カラムの説明を含むソース定義、適切な命名規則によるリネームを含む staging SQL モデル、および主キーと not-null 制約のための基本的なテストを含めてください。
[business_process] を追跡する fct_[name] という名前の dbt 増分ファクトテーブルモデルを作成してください。[strategy] で増分マテリアライゼーション用に設定し、unique_key を定義し、is_incremental() を使用した増分フィルターロジックを含めてください。
この dbt モデル SQL をレビューし、対応する YAML ドキュメンテーションファイルを生成してください。存在するカラムに基づいて、モデルの説明、カラムの説明、および適切なテスト(unique、not_null、relationships、accepted_values)を含めてください。
[domain] 分析ワークフロー用の dbt モデル構造を設計してください。[sources] に必要な staging モデル、ビジネスロジック用の intermediate モデル、および最終出力用の mart モデル(ディメンションとファクト)を定義してください。各レイヤーの命名規則とマテリアライゼーション戦略を含めてください。
Bonnes pratiques
- すべてのソースデータに staging レイヤーを使用 - 1 回クリーニングして、どこでも再利用
- すべてのキーで not_null、unique、relationship テストを積極的に実施
- 下流ユーザーのために、すべてのモデルとカラムにビジネスコンテキストを文書化
Éviter
- staging レイヤーをスキップして marts でソースを直接クエリすると技術的負債が生じる
- 設定に dbt 変数を使用する代わりに、日付や値をハードコードする
- 再利用可能なマクロに抽出する代わりに、モデル間でビジネスロジックを繰り返す
Foire aux questions
dbt におけるメダリオンアーキテクチャとは何ですか?
いつ増分マテリアライゼーションを使用すべきですか?
モデルにどのようなテストを追加すべきですか?
delete+insert と merge の増分戦略の間でどのように選択すればよいですか?
エフェメラルモデルの目的は何ですか?
dbt プロジェクトを効果的に文書化するにはどうすればよいですか?
Détails du développeur
Auteur
sickn33Licence
MIT
Dépôt
https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/dbt-transformation-patternsRéf
main
Structure de fichiers