👏

【Medium】Lessons learned when scaling dbt models quickly.

2022/10/25に公開

dbtdbt

tech

がく＠ちゅらデータエンジニア　です。
※2022年9月よりちゅらデータ株式会社にJoinしました

データエンジニアリングな話題などをMediumで毎朝、サジェストされるんですが、これちゃんと読んでいかんとなーということで、読んだメモなどを残しておこうと思って書いて行こうと思います。

概要

今日はこちら
「Lessons learned when scaling dbt models quickly.: dbtを迅速に拡張する際に学んだこと」

という記事をよみました。（Twitterのフォロワーさんの ken さんが　熱い！っと）

◯　properlyに構築する：
❌　right正しく構築する
Peoperlyにパイプラインを構築するということは
- ベストプラクティスに沿って構築する
- 一貫したスタイルガイドを適用して構築する
- 読みやすいSQL
Rightにパイプラインを構築するということ
- 今あるデータ変換パイプラインだけでなく、以下を考慮し、新しい変更があるたびに見直さなくてもいいようにしたい。（「こんな事もあろうかと・・・・」的な）
- 将来的な拡張性
- コード再利用性

今回は、なぜわたしたちが正しい(right）作り方ではなく、早くモデルを作ることにこだわるのか・・・を述べたいと思います。

（田代コメント）
理想的なものを作るのに検討に検討を重ねて、手戻りをすることをおそれて・・・よりは、ざざっとプロトタイプを作って改良していく（＝Properly）のほうがいいよ！ってことかな。
ウォーターフォールとアジャイルの違いみたいだ

Context: fast execution projects.（コンテクスト：高速実行プロジェクト）

最近、弊社では第3四半期末までに完了させるべき優先順位の高いプロジェクトを何十個も立ち上げました。あるプロジェクトはプッシュ通知のクリック率を最適化するもので、アナリストのJames（本名ではない）が簡単なダッシュボードを設定するよう命じられました。プッシュ通知イベントを取り込むパイプラインを構築している間、他のアナリストはこのパイプラインが将来的に他のユースケースにも有用であることに気づき、Jamesに将来のユースケースに対応するための追加変換を含めるよう助言しました。

もし、James氏が計画や追加要求の検討に時間をかけて*正しく（right）*構築した場合、完成時期が数週間遅れる可能性があり、今の洞察に依存するプロジェクトの実行計画に影響を与える。

ジェームズはスピードを選択した。パイプラインは、彼のプロジェクトの最小限の要件を満たすために、すぐに完成した。しかし、1週間後、彼はより複雑な新しい要求事項を受け取った。彼は、この要求が最後になるのか、それともこれから出てくる多くの要求のうちの1つになるのか分かりません。パイプラインの構造を堅牢にするためには、さらに時間がかかるかもしれない。そこで彼は、とにかくパイプラインの構築を進め、ロジックを一つずつ積み上げていった。

Jamesが休暇中に他の誰かが一時的にプロジェクトを担当する場合、その人はリファクタリングをぜず、文書化もしないで変換ロジックを追加することで、仕事を終わらせる最も早い方法を選ぶかもしれません。
これがどのような結末になるかを知っています。

ここまでで、パイプラインを素早く構築し、正しく(right)構築することは、それなりの効果と欠点があることは明らかです。
（田代コメント）
仕事にスピードをもとめる・・・のに、リファクタリングもしないで文書化もしないってのは、スピード優先とは言わないと思う。やるべきことをやっていないだけ

Why did we choose speed over robustness? （なぜ、堅牢性よりスピードを選んだのか？）

どの方法を選んでもデメリットはある
企業が現在置かれているデータの成熟段階に関わらず、ビジネスのコンテクストが大きくなるにつれて、パイプラインの複雑さは進化していく
データアナリストは、会社のニーズに対応するため、迅速なイテレーションサイクルを維持する必要があり
パイプラインをより明確にするためにどうすればよいかを考え直しました。

Document method AND context.(ドキュメントメソッド AND コンテキスト。)

私たちは通常、モデルやモデル記述にコメントを追加することで、処理方法を文書化する
コンテキストを文書化することで、そもそもなぜその列が処理されたのかを明確にできる
「リリースノート」形式のように行われた変更のリストをモデルの説明をすすめる

以下は、モデルint_orders の.ymlの例です。

int_orders.yml

- name: int_orders
  meta:
    owner: somedude@domain.com
    model_maturity: in prod
  description: >-
    ### Summary
    This is a short description about int_orders model. We usually describe it and clarify
    unique rows within 2-3 sentences.
    
    ### Airflow
    [Link to Airflow DAG](http://airflow.com/dag)
    
    ### Product Release
    #### April 2022, Adjusted GMV (Gross Merchandise Value).
    
    Based on a forecast analysis, 20% orders are rejected weekly. The Finance team provided
    a formula to adjust total GMV into a new column: adjusted_gmv to give us a more accurate
    representation of upcoming GMV figures.
    
    ❗️ Only use adjusted_gmv column for all GMV related calculations.
    
    #### Feb 2022, Validated/Rejected orders.
    
    We've added a new column: is_valid_orders to filter non-rejected orders for financial
    reporting.
    
    ❗️ All analyses must include validated orders only.

上記は、ビジネス上の意思決定につながる事象を記述しており、それに応じてモデルが更新される。上記を読んだアナリストは知ることができる。

adjusted_gmvの列は、計算するために他のモデルからのデータが必要である。
GMVデータを報告するすべての下流モデルは、adjusted_gmvを使用しなければならず、それ以外のものは使用できません。

Pipeline owners set the rules.(パイプラインのオーナーがルールを決める)

基本的なレポーティングで満足する人もいれば、予測などのより複雑な処理を必要とする人もいるように、データの需要はチームによって異なります。
しかし、ビジネスの状況を最もよく理解しているのはアナリストやパイプライン・オーナーであり、パイプラインの設計をどの程度精巧にするかは彼らの判断に委ねられています。

パイプラインの反復が早くなりすぎて混乱した場合、Jamesのようなアナリストはパイプラインのリファクタリングを始めるべきかどうかを判断します。また、アナリストは、いつビルドしてはいけないかを知っているはずで、私たちの頭痛の種を取り除くことができるかもしれません。アナリストはビジネスパートナーと密接に仕事をすることを考えると、インパクトを与える要件と虚栄心の強い指標を見分けることができ、重要でない要求を慎重に回避することができるはずです。

Allow cross-checks and prioritise them.(クロスチェックを可能にし、優先順位をつける。)

パイプラインの所有者を信頼するということは、ガイドラインを完全に無視して、好きなものを作ることができるということでもあるのです。もし、モデルのロジックがあまりにも混乱していて、ドキュメントが助けにならないなら、私たちはそれを提起する必要があります。

他のアナリストがパイプラインオーナーのモデルを再利用する必要があり、その複雑な変換が明確でない場合、モデルの簡略化やリファクタリングなど、オーナーに即時の対応を要求することができます。彼らは、なぜそれが重要なのか、つまり他のチームにもたらす価値を述べ、協力して問題を解決するための時間を割くべきである。

このことは、「ビジネス要件Yを満たすためには、問題Xを解決しなければならない」というブロッカーとして、すべてのステークホルダーに伝達されます。目標は、リファクタリングや負債を解消しなければならない場合、それはすぐに「問題を回避」できるものではなく、「バックログに入れる」ものでもないことを、全員（データおよびデータ以外の人々）が明確に理解できるようにすることである。

When do we NOT scale models quickly?(モデルを素早くスケールアップしないのはどんなとき？)

もちろん、すべてのパイプラインを迅速に拡張するわけではありません。ここでは、私たちがどのようにパイプラインの設計を正しく行うかについて、時間をかけて議論する価値があると考えるいくつかの例を紹介します。

個人情報のようなセンシティブなデータを扱う場合、 そのようなデータを露出して自分たちを危険にさらすようなパイプラインは設定したくありません。緊急の必要性があれば、より安全性の高いプロセスを検討するのが筋だろう。
企業レベルの指標は、2回測定し、1回カットするのがベストです。重要なメトリクスを迅速に計算するパイプラインを構築し、その後、我々がエラーを起こしたためにそれを撤回するのは気まずいでしょう。私は、パイプラインでコミットする前に、ステークホルダーと一緒に各メトリクスの意図を確認するために、より多くの時間を投資することを希望します。

Closing Thoughts

"スケーラビリティとは、使用量が増えるほど使用量あたりのコストを下げること"- 私たちのデータ責任者

私たちの迅速なアプローチは、ビジネス要件を満たすためにパイプラインを構築し、会社の日々の決定を妨げないようにするためのものでした。このアプローチでは、dbtプロジェクトにいくつかの問題が生じます。特に、プロジェクトが制御不能なほど成長し、厄介で混乱したパイプラインを解読するために時間を浪費するなど、無形のコストが発生する可能性があるのです。

そのようなコストを削減する方法を、上記を応用して学びました。私たちのdbtプロジェクトはまだ混沌としていますが、アナリストはその混乱の中で道を切り開くことができます。

パイプラインのスケーラビリティは、その使用量が増えるほど重要になります。ビジネス要件を満たす完璧なデータパイプラインを長い時間をかけて構築しても、誰もそのデータを使わなかったり、ビジネスコンテキストが変わったりすれば、せっかくの努力が無駄になります。そのような場合は、迅速に構築して出荷し、より多くの関係者がデータを使用するようになったら最適化に取り組み、誰も使用しなくなったら中止するようにします。