<h1 id="%E6%A6%82%E8%A6%81">
<a class="header-anchor-link" href="#%E6%A6%82%E8%A6%81" aria-hidden="true"></a> 概要</h1>
<ul>
<li>dbtと仲良くなりたい私</li>
<li>dbtを社内でも広めたい私</li>
<li>ディレクトリ構成とかどうしていけばいいか分からない私</li>
<li>よし、まずはdocsのbest practiceを読んでみよう</li>
<li>後に同僚にも読んでもらいやすようにまとめておこう</li>
</ul>
<p>ということでこれを読んでいきます<br>
しっかり公式のdocs読むこと大切よね</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__045d45af302cc" src="https://embed.zenn.studio/card#zenn-embedded__045d45af302cc" data-content="https%3A%2F%2Fdocs.getdbt.com%2Fdocs%2Fguides%2Fbest-practices" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://docs.getdbt.com/docs/guides/best-practices" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://docs.getdbt.com/docs/guides/best-practices</a></p>
<p>余計なお世話かもしれませんが、途中私が気になったことに対しては以下のようにコメント残していきます</p>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p>何より自分のためにコメントさせて！</p>
</div></aside>
<h1 id="best-practice-workflows">
<a class="header-anchor-link" href="#best-practice-workflows" aria-hidden="true"></a> Best practice workflows</h1>
<h2 id="version-control-your-dbt-project">
<a class="header-anchor-link" href="#version-control-your-dbt-project" aria-hidden="true"></a> Version control your dbt project</h2>
<ul>
<li>全てのdbtプロジェクトはバージョン管理しようね</li>
<li>新しい機能やバグの修正のためにはブランチを生やして作業しようね</li>
<li>全てのコードの変更はプルリク出して、同僚に(もしくは自分で)レビューしてもらおうね</li>
</ul>
<h2 id="use-separate-development-and-production-environments">
<a class="header-anchor-link" href="#use-separate-development-and-production-environments" aria-hidden="true"></a> Use separate development and production environments</h2>
<ul>
<li>dbtでは、プロファイル内のtargetを使用することで、本番環境と開発環境を別々に維持することが容易だよ</li>
<li>コマンドラインからdbtを実行する場合はdevターゲットを使用し、本番環境から実行する場合はprodターゲットに対してのみ実行することをお勧めするよ</li>
<li>環境の管理の詳細は<a href="https://docs.getdbt.com/docs/guides/managing-environments" target="_blank" rel="nofollow noopener noreferrer">こちら</a>
</li>
</ul>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p>自分の環境で動作確認しながら開発、プロダクションにデプロイ<br>
この両方を速度落とさずにやる方法を知りたい</p>
</div></aside>
<h2 id="use-style-guide-and-for-your-project">
<a class="header-anchor-link" href="#use-style-guide-and-for-your-project" aria-hidden="true"></a> Use style guide and for your project</h2>
<ul>
<li>SQLスタイル、フィールドの命名規則など、dbtプロジェクトのルールは体系化する必要があるよ</li>
<li>まずは<a href="https://github.com/dbt-labs/corp/blob/master/dbt_style_guide.md" target="_blank" rel="nofollow noopener noreferrer">dbtお勧めのスタイルガイド</a>から始めるといいよ</li>
</ul>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p>ディレクトリ構成まさに知りたかった！<br>
この部分が始めたばかりだと手も足も出なかった</p>
</div></aside>
<h1 id="best-practices-in-dbt-projects">
<a class="header-anchor-link" href="#best-practices-in-dbt-projects" aria-hidden="true"></a> Best practices in dbt projects</h1>
<h2 id="use-the-ref-function">
<a class="header-anchor-link" href="#use-the-ref-function" aria-hidden="true"></a> Use the ref function</h2>
<ul>
<li>dbtを最強たらしめるのは<code>ref</code>関数だ！</li>
<li>dbtは依存関係を推論し、モデルが正しい順序でビルドされることを保証するよ</li>
<li>現在のモデルが作業しているのと同じ環境の上流のテーブルやビューから選択されるようにするよ</li>
<li>他のモデルから選択するときは直接の参照を使うのではなく、常に<code>ref</code>関数を使うようにしなさい</li>
</ul>
<h2 id="limit-references-to-raw-data">
<a class="header-anchor-link" href="#limit-references-to-raw-data" aria-hidden="true"></a> Limit references to raw data</h2>
<ul>
<li>dbtプロジェクトはデータベースに保存されている生データに依存するよ(ｿﾘｬｿｳｼﾞｬ)</li>
<li>こういうデータは変更される可能性があるので、データソースへの参照を最小限にとどめるとモデルの更新が簡単に済むよ</li>
<li>v0.13.0では、生データ(データソース)をsourceとして定義し、直接参照を使用するのではなく、ソースから選択することを推奨してるよ、もはやdbtプロジェクトではどのモデルにも直接参照をしなくても済むよ(<a href="https://docs.getdbt.com/docs/building-a-dbt-project/using-sources" target="_blank" rel="nofollow noopener noreferrer">詳細はこちら</a>)</li>
</ul>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p>データベースの変更をいかに最小限に抑えるかは最初の方で意識しておきたい</p>
</div></aside>
<h2 id="rename-and-recast-fields-once">
<a class="header-anchor-link" href="#rename-and-recast-fields-once" aria-hidden="true"></a> Rename and recast fields once</h2>
<ul>
<li>生データは一般にソースに準拠した構造、つまりソースが定義するスキーマや命名規則に従って保存されるよ</li>
<li>この構造はソースごとに異なるだけでなく、分析に使用したい命名規則とも異なることがあるよ</li>
<li>dbtプロジェクトの最初のレイヤーは次のような振る舞いをするべき
<ul>
<li>1つのソースのみから選択する</li>
<li>例えば全てのタイムスタンプの名前を<code>&lt;event&gt;_at</code>にするなど、プロジェクト内で使用したい規則に合わせてフィールドやテーブルの名前を変更する、これらの規約はプロジェクトのコーディング規約で宣言すること</li>
<li>フィールドを正しいデータ型にキャストし直す、例えば日付をUTCに、価格を円に変更する</li>
</ul>
</li>
<li>これを最初にやっちゃえば、この後のモデルで重複するコードの量を減らせるよ</li>
</ul>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p>これdbtだけでなく、Lookerとかいろんなデータ周りにも通じるな</p>
</div></aside>
<h2 id="break-complex-models-up-into-smaller-pieces">
<a class="header-anchor-link" href="#break-complex-models-up-into-smaller-pieces" aria-hidden="true"></a> Break complex models up into smaller pieces</h2>
<ul>
<li>複雑なモデルでは複数のCTE(Common Table Expressions)を含むことがあるよ</li>
<li>dbtでは代わりにこれらのCTEを別々のモデルに分割して、その上に構築することができるよ</li>
<li>複雑なモデルを分割するのは、次のような場合によく行われるよ
<ul>
<li>CTEが２つのモデルで重複している場合、CTEを別のモデルに分割することで下流のモデルでそのモデルを参照できるようになり、コードの重複を減らせるよ</li>
<li>CTEは選択するデータの粒度を変更するよ、データの粒度を変更するようなテストをすることは有用だよ、CTEを別のモデルに分割することで、この変換をより大きなモデルから独立してテストすることができるよ</li>
<li>クエリのSQLには多くの行が含まれているよ、CTEを別のモデルに分割することで、他のdbtユーザー(もしくは未来の自分)がコードを見るときの認知負荷を軽減することができるよ</li>
</ul>
</li>
</ul>
<aside class="msg message"><span class="msg-symbol">!</span><div class="msg-content">
<p>CTEの部分はあんまりピンときていないけど、ephemeralを使って抽象化しようということの気がしている</p>
</div></aside>
<h2 id="group-your-models-in-directories">
<a class="header-anchor-link" href="#group-your-models-in-directories" aria-hidden="true"></a> Group your models in directories</h2>
<ul>
<li>
<code>models/</code>ディレクトリの中に任意の数のネストしたサブディレクトリを持つことができるよ</li>
<li>サブディレクトリを使って構造を整理していこう
<ul>
<li>
<code>dbt_projct.yml</code>ファイルで設定を指定し、モデルグループを構成する</li>
<li>
<a href="https://docs.getdbt.com/reference/node-selection/syntax" target="_blank" rel="nofollow noopener noreferrer">モデル選択構文</a>を使用して、DAGのサブセクションを実行しよう(?)</li>
<li>共同編集者とモデリングの手順を合意しよう</li>
<li>例えば、「martsディレクトリのモデルは、martsディレクトリの他のモデル、またはstagingディレクトリのモデルからしか選択できない」というように、モデルの上流依存関係を許容する規約を作成しよう</li>
</ul>
</li>
</ul>
<h2 id="add-tests-to-your-models">
<a class="header-anchor-link" href="#add-tests-to-your-models" aria-hidden="true"></a> Add tests to your models</h2>
<ul>
<li>dbtはモデルによって生成された結果に関するテストができるようになっているよ</li>
<li>プロジェクトにテストを追加することで次の2点を保証できるよ
<ul>
<li>自分が書いたSQLが期待通りの方法でデータを変換していること</li>
<li>ソースデータに期待する値が含まれていること</li>
</ul>
</li>
<li>スタイルガイドでは、全てのモデルが最低限primary keyがユニークであり、nullでないことを確認するためのテストを行うことを推奨しているよ</li>
</ul>
<h2 id="consider-the-information-architecture-of-your-data-warehouse">
<a class="header-anchor-link" href="#consider-the-information-architecture-of-your-data-warehouse" aria-hidden="true"></a> Consider the information architecture of your data warehouse</h2>
<ul>
<li>SQLクライアントでデータウェアハウスに接続した場合、ユーザーはスキーマ、リレーション、カラムの名前を頼りに表示されるデータを理解することがよくあるよ</li>
<li>データウェアハウスが持つこれらのメタデータを改善するために次のようなことを行っているよ
<ul>
<li>カスタムスキーマを使用して、リレーションを論理的なグループに分離したり、中間モデルを別のスキーマに隠したりするよ、一般的に、これらのカスタムスキーマは、モデルのグループ化に使用するディレクトリと一致し、<code>dbt_project.yml</code>ファイルから設定されるよ</li>
<li>テーブル名の接頭辞（例えば、<code>stg_</code>、<code>fct_</code>、<code>dim_</code>）を使用して、エンドユーザーが照会すべきリレーションシップを明示するよ</li>
</ul>
</li>
</ul>
<h2 id="choose-your-materializations-wisely">
<a class="header-anchor-link" href="#choose-your-materializations-wisely" aria-hidden="true"></a> Choose your materializations wisely</h2>
<ul>
<li>
<a href="https://docs.getdbt.com/docs/building-a-dbt-project/building-models/materializations" target="_blank" rel="nofollow noopener noreferrer">マテリアライゼーション</a>は設定によってモデルを構築する方法を決定するよ、一般的なルールとして、
<ul>
<li>ビューはテーブルと比較して、構築は高速ですが、クエリーは遅くなるよ</li>
<li>インクリメンタルモデルは、テーブルと同じクエリーパフォーマンスを提供し、テーブルのマテリアライゼーションと比較して構築は高速だけど、プロジェクトに複雑さをもたらすよ</li>
</ul>
</li>
<li>下記パターンを推奨しているよ
<ul>
<li>デフォルトでビューを使用する</li>
<li>エンドユーザーに公開されるべきでない軽量の変換には、エフェメラルモデルを使用する</li>
<li>BIツールで照会されるモデルにはテーブルを使用する</li>
<li>複数の子孫を持つモデルにはテーブルを使用する</li>
<li>テーブルモデルの構築時間が許容範囲を超えた場合、インクリメンタルモデルを使用する</li>
</ul>
</li>
</ul>
<h1 id="pro-tips-xxx">
<a class="header-anchor-link" href="#pro-tips-xxx" aria-hidden="true"></a> Pro-tips xxx</h1>
<p>pro tipsは現在の私の知りたいスコープとは外れるかなと思うので、強くなったらまた帰ってきます</p>
<hr>
<h1 id="%E6%9C%80%E5%BE%8C%E3%81%AB%E6%9C%AA%E6%9D%A5%E3%81%AE%E7%A7%81%E3%81%B8%E3%81%AE%E3%83%A1%E3%83%A2">
<a class="header-anchor-link" href="#%E6%9C%80%E5%BE%8C%E3%81%AB%E6%9C%AA%E6%9D%A5%E3%81%AE%E7%A7%81%E3%81%B8%E3%81%AE%E3%83%A1%E3%83%A2" aria-hidden="true"></a> 最後に未来の私へのメモ</h1>
<ul>
<li>
<a href="https://docs.getdbt.com/docs/guides/managing-environments" target="_blank" rel="nofollow noopener noreferrer">環境管理</a>についても知りたくなったよ</li>
<li>
<a href="https://github.com/dbt-labs/corp/blob/master/dbt_style_guide.md" target="_blank" rel="nofollow noopener noreferrer">dbtのスタイルガイド</a>も読んでみたいよね
<ul>
<li>
<a href="https://discourse.getdbt.com/t/how-we-structure-our-dbt-projects/355" target="_blank" rel="nofollow noopener noreferrer">dbtプロジェクトをどう構築していくか</a>も似た感じかも、目を通しておきたいね</li>
</ul>
</li>
</ul>


ベストプラクティスから読んで始めるdbt

Use separate development and production environments

Break complex models up into smaller pieces

Consider the information architecture of your data warehouse

Discussion