[レポート] Dagsterでdbtをオーケストレーションする #dbtcoalesce

大阪オフィスの玉井です。

12月7日〜11日の間、Fishtown Analytics社がcoalesceというオンラインイベントを開催していました（SQLを触っている方はピンとくるイベント名ではないでしょうか）。

「Fishtown Analytics社って何やってる会社？」という感じですが、dbtというツールを開発しているベンダーです。dbtについては、下記をご覧ください。

今回は、その中からOrchestrating dbt with Dagsterというセッションを受講したので、レポートを記します。

イベント概要

公式

• Coalesce 2020 online - December 7-11, 2020
  • Orchestrating dbt with Dagster - Coalesce 2020 online - December 7-11, 2020

概要

You probably have customer data in your data warehouse — it's a must-have for understanding a business. However, this data almost definitely includes personally identifiable information (PII), which shouldn't be shared with the entire organization. In this session, we'll learn how JetBlue approaches the problem of masking PII at scale by leveraging some Snowflake features straight from their dbt project.

私なりの要約

dbtやPythonスクリプトなど、データ処理を行うツールやサービスは多岐に渡ります。そういった色々なツールが連なったデータ分析のシステムがあって、そこのどこかで何らかの問題が起きた場合、データアナリストだけだと対応が難しい場合が多いです。そういうときのために、Dagsterというツールで、データ分析の関する処理をオーケストレーションすることで、データアナリストがセルフサービスでデータ処理の運用を行うことができます。

このセッションでは、そんなDagsterというツールの紹介とデモが行われます。

セッションレポート

アジェンダ

• Dagsterというツールについて話す
  • デモもやる
• Dagsterとdbtの関係について質問を受けることが多い
  • 「どちらを使うべきか？」など
  • 両方ともDAG（有向非巡回グラフ）があるので、質問する動機は理解できる
• 我々は両者を補完的なツールとして認識している
• Modern Data Platformにおける両者の役割についても話す

なぜDagsterが必要なのか

Dagsterは（dbtの観点から見て）誰がどういう時に使うツール？

• どういう時に使うか
  • dbtのオペレーションとデプロイが必要な時にDagsterを使う
  • 特に、他のツールも合わせてオーケストレーションする必要がある場合
• 使う人
  • アナリティクスエンジニア
    • データ分析はできるが、それを伴うインフラをセルフで運用する必要があるとき
    • データサイエンティストなどは、別途Pythonスクリプトを運用する必要があったりする
  • データプラットフォームエンジニア
    • アナリティクスエンジニアをサポートする人
    • 現在増えてきているロール

なぜオーケストレーションが必要なのか？

• 新しいデータ分析チームが立ち上がった時、多くの場合、下記のような流れになる
  • FivetranやStitch等でデータの取込を行う
  • Snowflake、Redshift、BigQueryなどのDWHにデータをレプリケーションする
  • アナリティクスエンジニアはdbtでテンプレート化されたSQLを記述し、下流用のデータを作成する
  • BIツールで可視化する
• ここで一つ興味深い疑問が出てくる
  • 私達は前述で登場したサービス群を「Modern Analytics Stack」と考えている
  • これらのサービス群に「オーケストレーション」は必要なのか？
  • なぜなら、これらクラウドサービスは、運用管理する必要がないから

• 先程の図は、私達が見ている全てではない
  • 実際は、各企業毎に異なるデータプラットフォームが存在する
  • 各企業の独自のドメインに合わせて、クラウドサービス群を超えたカスタマイズがなされている
• カスタマイズの例を紹介する
  • レガシーなデータレイクがあったとする（S3）
  • それをデータエンジニアがSparkで処理している
  • ここに「Modern Analytics Stack」を入れたいとする
  • FivetranとSnowflakeを導入する
  • この場合、古いデータレイクとSnowflakeの間に、インターフェースを実装する必要が出てくる（Pythonスクリプトなど）
• dbtを使うと、BIツール等の下流側に最適なデータを用意できる
  • しかし、データサイエンティスト等は、DWHのデータを使って別途機械学習パイプラインを構築したい場合もある
  • 少数のデータサイエンティスト用に別途サービスを提供しているアーキテクチャはよくある
  • そういうアーキテクチャは、大規模な組織になると、複雑さが爆発する

• 私達はオーケストレーションが（このようなデータプラットフォームの）心臓部であると考えている
• オーケストレーターは全ての分析処理を管理する
  • つまり、オーケストレーターは全ての分析ツールと相互作用する
  • だから、オーケストレーターは独自の場所に配置することができる
  • 全ての関係者はオーケストレーターを直接来または間接的に使用する
  • そして、色々なインタラクションや新たなデータ分析を引き起こし、データストアにデータを格納する
  • これらはデータプラットフォーム全体で必要なこと
• 私達は、これらのオーケストレーションに適しているのはDagsterであると考えている

Dagsterでデータプラットフォーム開発をオーケストレーションする

• Dagsterを一言でいうと「信頼されたデータを生成するためのオーケストレーションプラットフォーム」
  • キーワードは「信頼性」
  • 信頼性を実現するのは非常に難しい
  • アプリケーションのライフサイクル全体について考えて、モデル化して、管理する必要がある

データプラットフォーム開発における3ステップ

• 1: 開発とテスト
  • 構造化されたテスト可能な計算を効率的に構築できるようにしたいと考える
  • テストを効率よく行うためには、設計時点で考える必要がある
• 2: デプロイと実行
  • 開発したデータ処理を実行、デバッグ、コントロールする
  • 処理の多くは再実行可能できることを保証する
• 3: 監視と観察
  • 最終目標は「データアセット」を生成すること、そのデータが下流のステークホルダーによって消費されること
  • オーケストレーターが、そのデータを観測できる能力をもつのは自然なこと
• 最終成果（データアセット）は、全てのステップが相互に結びついて出来ることに注意する
  • テスト可能なデータ処理があるからこそ、信頼できるデータ処理が実現できる
  • データを意識したプログラミングモデルとAPIを持つことで、統合されたデータ観測機能を有効にすることができる

Dagsterでどうやるか

• ステップ1
  • DagsterはPython用のAPIがある
  • システム上のローカルテストを実行できる
  • テストの設計ができる
  • DagsterはローカルPCでも動作する
• ステップ2
  • Dagsterは（あまり）場所を問わず動作させることができる
  • 何らかのCI/CDシステム等と連携して実行できる
  • Kubernetesを使ってデプロイすることもできる（必須ではない）
• ステップ3
  • データアセットカタログのような機能がある
  • データ処理で生成されたデータアセットを追跡できる

• ここであなたはスライドのようなことを思うかも知れない
• 「dbtはどこに出てくるの？」

アナリティクスエンジニアから見たDagster + dbt

• 改めて、dbtは非常に便利である
  • ローカルで実行できる
  • Jinjaが書ける
  • SQLも使える
  • 自動テストができる
  • DAGが作成できる
  • ...なぜDagsterは必要なのか？
• ステップ1はdbtでもできるが…
  • dbtはSQLオンリーの変換処理
  • Dagsterは色々な方法で計算処理が書ける（Python, Pandas, Sparkなど）
• デプロイ〜運用監視
  • Dagsterの焦点は「アナリティクスエンジニアのようなロールの人が、何かがうまくいかなかった場合に、セルフサービスでオペレーションを行えるようにすること」
  • メンバーの作業を滞りなく実施させるために、本番システムと対話する必要があるから

デモ

デモでやること

• Googleフォームの設問に回答する
• Googleスプレッドシートにデータが入る
• スプレッドシートのデータをPython（Pandas）で処理して、Snowflakeにロードする
  • タイムスタンプを操作したいから
  • SQLでこれをやるのは面倒
• Snowflakeに入れたデータをdbtで集計処理する
• そのデータをpapermillで処理する
  • （パラメータ化されたJupyter Notebook）
  • GitHub - nteract/papermill: ? Parameterize, execute, and analyze notebooks
  • Introduction to Papermill. How to transform your Jupyter Notebook… | by Gabriel dos Santos Goncalves | Towards Data Science
• プロットを作成して、Slackチャネルに投稿する
  • 「SnowflakeとS3に保存された日付」を表示する
• これらの処理をDagsterでオーケストレーションする

実演

• Googleスプレッドシートのデータ取込を行っている
  • DataFrameとして吐き出している
• メタデータも豊富
  • ユーザー定義のDescription
  • データ型
  • …など
• 全てのノードが入力と出力をもつ
  • 安定性を評価するのに役立つ
• この処理は型づけされている
  • 自己記述的になる
  • 信頼性が高くなる

• DataFrameをDWHに入れる
• dbtモデルを実行するノード

• Notebookを実行するノード
• Notebook自体を閲覧することも可能

• 一連の処理を実行する
  • パラメータを設定してテストモードを用意している（この場合、Slackのテスト用プライベートチャネルに投稿される）
  • これらのパイプラインは色々なカスタマイズが可能

• 実行処理の状態がライブで分かる
  • 各ステップ毎に固有のプロセスをスピンアップさせる

• 構造化されたイベントログ

• 流れているデータのプレビューも閲覧できる

• 処理結果の確認
• 履歴も確認可

• 投稿できた

デモで実演した内容の詳細など

• 一連の処理構造

• Dagsterでは、この一連の処理をパイプラインと呼ぶ
  • 全て入力と出力がある
• Pythonの構文を使って、このパイプラインにデータを流すだけ
  • とても直感的

• これはsolid
  • 実際の計算処理を行うリーフノードのようなもの
  • スライドに載っているコードの処理内容は、DataFrameを取得→計算→再度DataFrameとして出力
  • Pandasの日付時間形式を推論する機能を使用している

• dbtと統合できるライブラリがある
  • コミュニテイ主導でできた
  • 「David Wallaceさんありがとう」
• dbt_cli_runをプロジェクトやプロファイルにもってくるだけ

データプラットフォームとオーケストレーション

dbtとDagsterの違いまとめ

• 処理の記述
  • dbt
    • SQL
    • Jinja
  • Dagster
    • Pythonなど
• 計算（関数）と依存関係
  • dbt
    • SELECT文で定義できるモデル間で依存関係をもつ（関数のような形）
  • Dagster
    • 純粋なビジネスロジックを書くsolid
    • 論理的な入力と出力があるが、これはdbtのモデルと似ている
• ワークフロー開発
  • （時間が足りなくなってきたのでスキップされた）

データ分析プラットフォーム全体の話

• 「人々は自らが次々に作り出す道具によって形成される」
  • マーシャル・マクルーハン - Wikipedia
• 私たちがツールを作ると、それが人々の働き方に影響を及ぼす
  • それはすなわち、彼らのキャリアパスに影響を与える
  • 彼らの組織構造にも影響を与える

• dbtが登場する前のデータエンジニアやアナリスト
  • アナリストは、データアセットを作成するため、データエンジニアと会話する必要があった
  • この形態を「データブレッドライン」と呼ぶ人もいる

• これは、パンを待つ人の大行列です（ブレッドライン）

• データエンジニアは画像の右側のどこかにいる
• アナリストやビジネスユーザーは行列の中のどこかにいる
• この状態で、アナリストが力を発揮できていると思うか？

• dbtはアナリストをアナリティクスエンジニアにする
  • すると、データエンジニアはインフラ等に集中できる
  • アナリティクスエンジニアはDWH内のデータ全てを担当できる
• （一見、これでうまくいきそうだが）まだ完成していない

• データ分析では様々な役割がある
  • ITエンジニアはツール自体やインフラ等に責任をもつ
  • アナリティクスエンジニアはDWH内のデータ（データマートとか）に責任がをもつ
  • データサイエンティストは作成したMLモデルに責任をもつ
• 新しい役割として「データプラットフォームエンジニア」があると思う
  • 前述した人々が滞りなく役割を果たせるようにすることに責任をもつ

オーケストレーションの重要性

• 先程のパン行列の話に戻る
  • 「ブレッドライン」はデータアセットそのもの（テーブルとかカラムとか）
• これらとは別に、全体的な別の領域（プロジェクトとか案件とか）がある
  • プロジェクト（作戦）にはレッドラインというものがある
  • 何かがうまくいかなくなった瞬間にアナリストやビジネスユーザーは崖から転落する
  • アナリストやビジネスユーザーは、データエンジニアと会話する必要がある
• Dagsterは「作戦」という次元での力を与えてくれる
  • どういったパイプライン処理が行われたのか調べることができる

• M1のMacの登場にめっちゃテンション上がってるので、これで例えていく
• 計算処理をオーケストレーションするマシンがある（とする）
  • 専用のコアプロセッサがたくさんある
• これが今日のデータの世界で起きていること
  • データプラットフォーム→マシン
  • dbt→（データ分析の）GPU
• これらのコアプロセッサは非常に重要な処理を実行する
  • しかし、それはドメイン固有の強力なもの
  • 全てはオーケストレーターによって良いものでなければならない
• スライドにはdbtとSnowflakeが表示された
  • 他にもコアプロセッサの宇宙のような領域がある
  • どのような理由であれ、他の色々なツールが存在している

まとめ

• dbtとDagsterは補完しあう
  • dbtはPCでいうデータ分析用GPUである
• Dagsterはアナリストがオペレーションを自分たちでやれるようにする
  • フレンドリーなUIや、パラメータ化により、アナリストが扱っていたりデバッグしていたりするデータを素早く調査できるから
• Dagsterはエンジニアが素晴らしいデータパイプラインを構築できるようにする
  • テスト可能なように設計されている

おわりに

dbtを含んだ、データ分析関係のツール全てをオーケストレーションする存在が必要ということはすごく伝わってきました。ただ、Dagsterが実際に動く環境がイマイチわからなかったので、そこは実際に試してみたいと思います。

あと、これは海外カンファレンス全てにいえることですが、このセッションでも、FivetranやSnowflakeを使うことは「ごく普通なこと」として扱われていることに驚きました（日本はこれから名を広めていくという段階なので）