Compétences dbt-transformation-patterns
📦

dbt-transformation-patterns

Sûr

本番環境対応の dbt データ変換パイプラインを構築

Également disponible depuis: wshobson

分析チームは、一貫性のないデータモデルと不十分なドキュメンテーションに悩まされています。このスキルは、適切なテスト、ドキュメンテーション、増分処理を備えた dbt プロジェクトを構築するための実証済みのパターンを提供します。

Prend en charge: Claude Codex Code(CC)
🥉 74 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

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ûr
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
Fichiers analysés
585
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

変換パイプラインを構築するアナリティクスエンジニア

初日から適切なモデル整理、テスト、ドキュメンテーションを備えた新しい dbt プロジェクトをセットアップします。

モデル品質を向上させるデータチーム

既存の dbt モデルに包括的なテスト、ドキュメンテーション、鮮度監視を追加します。

増分ロードを最適化するエンジニアリングチーム

大規模ファクトテーブル向けの効率的な増分戦略を実装して、コンピューティングコストを削減します。

Essayez ces prompts

staging モデルの作成
[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 におけるメダリオンアーキテクチャとは何ですか?
メダリオンアーキテクチャは、モデルをレイヤーに整理します:staging(生データクリーニング)、intermediate(ビジネスロジック)、marts(最終分析テーブル)。この分離により、クリーンなデータがパイプライン全体に一貫して流れることが保証されます。
いつ増分マテリアライゼーションを使用すべきですか?
100 万行を超えるテーブル、またはソースデータが継続的に増加する場合に増分モデルを使用してください。増分モデルは新規または変更されたレコードのみを処理し、コンピューティング時間とコストを大幅に削減します。
モデルにどのようなテストを追加すべきですか?
すべての主キーに not_null と unique テストを、外部キーに relationship テストを、必須カラムに not_null を、ステータスまたはタイプカラムに accepted_values を追加してください。カスタム検証には dbt_utils.expression_is_true を使用します。
delete+insert と merge の増分戦略の間でどのように選択すればよいですか?
デフォルトとして、ほとんどのウェアハウスでは delete+insert を使用してください。遅れて到着するデータで既存のレコードを更新する必要がある場合は merge を使用します。BigQuery や類似のプラットフォームでのパーティションベースのワークフローには insert_overwrite を使用します。
エフェメラルモデルの目的は何ですか?
エフェメラルモデルは、テーブルとしてマテリアライズされない中間 CTE です。常に他のモデルから参照される再利用可能なロジックに使用し、ウェアハウス内のテーブル数を削減します。
dbt プロジェクトを効果的に文書化するにはどうすればよいですか?
YAML ファイルのすべてのモデルとカラムに説明を追加してください。description フィールドを使用して、ビジネスロジック、データソース、期待される値を説明します。dbt docs を生成して、チームが閲覧できるようにサーブします。

Détails du développeur

Structure de fichiers