🏙

dbtのdatabaseオプションとともに送る幸せな日々

2022/09/12に公開

要約

dbtの開発していく上で、データレイクに対してこんな悩みがありました

production環境(以下prod環境)と開発環境(以下dev環境)でプロジェクトを分けて運用している
- dev環境からはprod環境のテーブルのReadのみができる
動作確認のためのデータレイク相当のものはdev環境にはない
- staging環境も存在はするのですが、どうしてもソフトウェアの動作確認、テスト環境用であって、データ基盤のデータの整合性までは考えられていないので、ログなどでしばしばデータ不整合が起きてしまう
動作確認のためにはprod環境のテーブルをコピーして使っていた
PIIを含む情報を別の環境に移すのはデータガバナンスの観点からとても危険でやりたくない
- でも、どうしてもやらなきゃいけないときは自社のデータに絞ってとるなどしてやりくりしている
- コピーしたはいいけど、消すのは人間が頑張って覚えて消すしかないので運用から漏れることがある(人間だもの)
個人情報でフィルターをかける際にはDDLで記述するが、prod環境のテーブルと違うものを生み出してしまうことがある
- パーティションが切ってあって、パーティションフィルター必須の設定などを見落とすとprod環境と違う条件のテーブルで動作確認してしまい、本番で落ちてしまう

version: 2

sources:
  - name: dataset_hoge
    tables:
      - name: table_a

version: 2

sources:
  - name: dataset_hoge
    database: tenajima-prod
    tables:
      - name: table_a

sourceにdatabaseオプションを付けるのは毒にも薬にもならないので、入れてもなんの問題もないと思っています
ただ、僕自身は自分のチームで使い始めたばかりなのでまだ合意形成フェーズです
なので、今は#TODO: 後で消すのコメントとともにdatabaseプロパティを使って開発、動作確認しています
- もし消し忘れてもプルリクでレビュアーに指摘してもらえるようになってます
上記で書いたように毒にも薬にもならないなら、開発のしやすさ、データガバナンスの観点からdatabaseプロパティつけたほうがいいよねって合意をとっていこうと思っています
データ基盤にPIIを含むものを扱う際は、違う環境にPIIが漏れるのはやはり良くないと思います
- 弊チームのデータ基盤はPIIを一切取り込まないとして作っています
  - 識別子として必要な際はハッシュ化して取り込んでいます
- この点を指して「用法用量を守ってね」と書いています

(最後に改めて)