dbt は『データエンジニアの GitHub Actions』
dbt は SQL ベースでデータ変換のロジックをコードとして管理する OSS で、データエンジニアリングの標準になりつつあります。本記事では編集部の視点で、実務での使い方を公開情報をもとに整理します。SQL チューニング もご参考に。
dbt の基本概念
(1) Model：SELECT 文の塊。(2) Source：生データ定義。(3) Test：データ品質チェック。(4) Macro：SQL 再利用。(5) Documentation：自動生成可能。SQL がそのままコード資産になります。
モデルの設計
(1) Staging Layer：raw データのクレンジング。(2) Intermediate Layer：複雑な計算。(3) Mart Layer：BI に渡す最終形。(4) 命名規約：stg_/int_/dim_/fct_ 等。(5) materialization：view/table/incremental。
テスト戦略
(1) Generic Tests：unique/not_null/relationships/accepted_values。(2) Singular Tests：1回限りのカスタムSQL。(3) Custom Generic Tests：再利用可能。(4) dbt-expectations：Great Expectations 風。(5) CI で実行：品質ゲート。
増分実行 (incremental)
(1) incremental materialization。(2) unique_key：マージキー。(3) is_incremental()：条件分岐。(4) merge vs delete+insert。(5) full refresh：定期的に全件再計算。大規模データで威力を発揮します。
Macro と再利用
(1) Jinja マクロ：SQL を関数化。(2) パッケージ：dbt-utils 等の共有ライブラリ。(3) 環境別の分岐：dev/prod。(4) seed：CSV データの取込。(5) hooks：実行前後の処理。
CI/CD 連携
(1) dbt build：parse+compile+test+run。(2) state:modified+：差分実行。(3) dbt Cloud / dbt Core：ホスト方式の選択。(4) GitHub Actions 連携。(5) Slim CI：変更差分のみテスト。CI/CD 実践 もご参考に。
失敗しがちなパターン
(1) 巨大モデル一つ：分割なし。(2) テスト不在：品質劣化。(3) full refresh 常用：コスト増。(4) 命名規約バラバラ：保守困難。(5) ドキュメント未活用。対策は、(1)階層化、(2)主要モデルにunique/not_null、(3)incremental、(4)Style Guide、(5)dbt docs serve、です。