Classi開発者ブログ

教育プラットフォーム「Classi」を開発・運営するClassi株式会社の開発者ブログです。

Airflowの処理の一部をdbtに移行しようとして断念した話

データエンジニアリング

こんにちは、データプラットフォームチームでデータエンジニアをやっている滑川(@tomoyanamekawa)です。

以前紹介したデータ分析基盤であるソクラテスの改善のためにCloud Composer(Airflow)で行っている処理のdbtへの置き換えを検討しましたが、導入を見送りました。 調べてみてdbtに対するわかりみも深まったので、その供養のために検討内容を公開します。 同じように検討している方の参考になれば幸いです。

dbtとは

DWH(Data Ware House)でのquery管理やデータの品質、データリネージの問題を解決してくれるツールです。 すでに先人たちがいろいろな記事を公開してくれているので、詳細は説明しませんがこちらの文がdbtをよく表しています。

ELTの「T」を担当するツール データの前処理における作業をELT（Extract、Load、Transform）と呼称することがありますが、それの「T（変換）」を担当します。E（抽出）やL（ロード）はやりません。
(データ変換処理をモダンな手法で開発できる「dbt」を使ってみた)

dbtは「T」を担当するツールといってもqueryの実行だけでなく、値のテスト（ユニークか、想定した範囲の値に収まっているか）やデータ間の参照・依存関係の解決、メタデータ管理や可視化までをサポートしています。 テンプレートエンジンのJinjaを使ってSQLを動的に生成することも可能です。 また、Airflowとの連携や動的なSQLのコンパイルだけをして持ち出すことなどもでき、ロックインされにくく扱いやすいです。 実際にデータ分析基盤を運用しはじめて次のステップでぶつかるであろう課題を解決してくれる、データエンジニアのためのツールです。

その他の記事では、Ubieさんが実際に導入した上での知見をまとめてくれているのでとても参考になりました。

データパイプラインの現状と課題

  • 現状

    • データ分析基盤を開発・運用するデータエンジニアは3人
    • DWHのqueryはデータエンジニア以外にデータサイエンティストやビジネス側のメンバーもPull Requestを出している

  • 課題

    • DAG（処理の依存関係）が適切に狭められておらず、直接関係がない処理のエラーに引きずられて止まってしまう部分がある
    • DWHのqueryの依存関係定義が人力になっていて、数が増えるにつれて複雑になりスケールできない
    • DWHのメタデータ管理が徹底できておらず、テーブルの仕様が誰でも理解できる状態になっていない

まとめると、ある程度チーム開発できる体制になっていて、データ分析基盤の運用自体も軌道に乗り、データを利用するだけでなく整備側に回ってくれるメンバーも増えました。 その一方で運用のステップでぶつかる課題が顕在化してきたという状態でした。

詳細は下記の記事をご参照ください

検討のきっかけ

データ分析基盤の課題を洗い出して、どのように解決するかをチームで話していたときにデータエンジニア全員の頭に浮かんだのがdbtでした。 デモなどを軽くみた結果イケてそうで、我々の課題ともマッチしていそうということで真面目に検討を開始しました。 （正直、話題のツールを実環境で使ってみたいというミーハーな部分もありました。）

f:id:tomoyanamekawa:20210818174834p:plain
dbtの機運が高まっていく様子

Dataformやtroccoなど他のツールもありますが、今回はdbtのみに絞って検討しました。
※Dataformは上記の記事や以前自分で触ったときの印象、GCPへの統合の途中で落ち着いていないことなどから選びませんでした。

dbtの契約方法を決める

dbtを利用する上ではSaaS版とOSS版の2パターンの利用方法があります。 SaaS版では3種類のプランがあります。

SaaS版とOSS版の一番大きな違いは開発のインターフェイスとしてWebUIがあるかどうかです。 SaaS版ではテーブルやテストの作成、GitHubとの連携などをWebUI経由でできますが、OSS版では全てCLIのみです。
※データの説明やデータの依存関係の可視化はOSS版でも可能です。

機能仕様と社内基準を加味して検討した結果、OSS版をまずは試してみようということになりました。

dbt(OSS版)で実際にDWHを作ってみて検証

実際のTransform処理の一部と同等の処理をdbtで実装し、使い勝手を検証しました。

魅力的な点

「dbtとは」で紹介した機能のほかにも、細かいところですが下記のような点も魅力的でした。

  • モデル（テーブル）の説明、データ間の依存関係などをまとめたページを静的ファイルで書き出してくれる
    OSS版ではCLIのみですが、この書き出し機能はあるので、この静的ファイルをホスティングすることで社内ユーザーに提供することが可能です。

  • seed機能によりマスターデータも管理できる
    queryだけでは依存関係に含めることが出来なかったcsvで存在するマスターデータやEnumもseedとして読み込むことでまとめて管理できます。

  • コミュニティが活発
    GitHub上のissueはもちろん、その他にSlackとディスカッションフォーラムが存在しています。 dbtは名前的にも検索しづらいですが、こちらのコミュニティで大体の疑問が解決します。

  • メタデータやスキーマの定義、BigQueryからのimportができる

  • 課題に対して適切なアプローチを取れているツール
    データ分析基盤を実際に運用した上で生じる課題に注目していて、筋のいい技術的な解決方法を示しているツールだと感じられてとても好印象です。

使い勝手が悪かった点

  • そもそもdbtが1プロジェクト:1データベース:複数テーブルの発想になっていて、BigQueryのデータセットという階層にマッチしていない
    dbtではプロジェクト>スキーマ（データベースやデータセット）>モデル（テーブルやテスト）の3階層の抽象化がされています。 しかし、前述のとおり1プロジェクト:1データベースがデフォルトになっています。 custom schemaを使うことで1プロジェクト:複数データベース(データセット)にすることはできますが、データセット名を自由に決めたい場合などは裏側で使っているmacroを上書きする必要があります。

  • モデル名はプロジェクト内でユニークでなければならない
    これが一番大きい問題でした。 1プロジェクト:1データベースである前提に合わせて、モデル名はプロジェクト内でユニークである必要があり、モデル名=queryのファイル名=BigQueryでのテーブル名になります。 つまり「別データセットで同名のテーブルがある」というケースに対応できません。 これの回避策や根本解決のためのissueもありますが、検証時点ではスマートな解決方法はないという印象でした。

  • macroという名の魔改造が必須になってくる
    上記でもmacroを上書きするケースがありましたが、細かい要望を叶えようとするとmacroを多用することになります。 このmacroではJinjaを使うことになりますが、日付の計算などをJinjaだけだと取り回ししづらいケースも多いです。 カスタマイズしやすいという良い面とも言えるかもしれませんが、デメリットの面のほうが大きく感じました。

  • データ分析基盤の開発者以外には、(OSS版では)queryを書いたり、テストを追加するための学習コストが高い
    dbtの機能やフォルダ構成、macroは日頃から触っている人であればそこまで学習コストは高くないと思います。 しかし弊社では、データエンジニア以外にデータサイエンティストやビジネス側のメンバーもPull Requestを出していてそういったメンバーにとってはdbt内でコードを書いたりデバックすることはハードルが高いと思いました。 これはデータ活用だけでなく、整備も民主化しようとしている我々にとってはマイナスポイントでした。

  • Airflowと組み合わせて利用する際にDAGの見通しが悪くなる
    dbt単体ではスケジューラーや実行管理の機能を持っていないため、必然的にAirflowなどの他ツールと組み合わせて利用することになります。 これは前述のUbieさんの記事でも指摘されていますが、dbtをAirflow上で使おうとするとうまくタスクを確認することが出来なくなります。 Airflowとの連携する方法がありますが、この方法だと画像のようにすべての処理がまとめて表示されます。 展開して表示する方法もありますが、手間がかかります。

f:id:tomoyanamekawa:20210818174924p:plain
dbtのDAG

あとはKubernetesPodOperatorで処理を隔離するという方法もありますが、結局見通しの悪さは変わらないです。

検討の結果、導入を見送った

これらの点を比較してチームで話し合った結果、dbtによって解決できる点よりも導入時のコストやデータエンジニア以外にとっての学習コストが高く、一緒に整備してくれるメンバーへのハードルが上がってしまうことの影響の方が大きいと判断し、導入を見送りました。

もちろん見送っただけでは既存の課題は解決していません。 しかし、今回の検討によって副次的にですがdbtで解決しようとしていた課題・対応方法に対する解像度が上がりました。 その結果、データの品質チェックなど現状抱えている課題もAirflow内で自分たちで同等の機能を実装すれば、ある程度は解消できるという方向でチームの認識が揃い、開発を進めています。 具体的には下記のようなことを計画しています。

  • SQLをparseして依存するテーブルを検出し、自動でquery間の依存関係を定義・可視化する
  • データのテストtaskを実装して、yamlでテストの定義、追加をできるようにする

まとめ

  • dbtを使っていま抱えているデータ分析基盤の課題を解決しようとした
  • 検証した結果、良いツールであることは確認できたが、使い勝手が悪い部分も見えてきた
  • チームの状況・データ活用の方針と照らし合わせて検討した結果、導入を見送った
  • 今使っているツールを拡充して既存の課題を解決することにした

データプラットフォームチームではこの改善以外にもやるべきこと・やりたいことがまだまだたくさんあるので、一緒に働いてくれるデータエンジニアの応募をお待ちしています！ 募集要項はこちら

© 2020 Classi Corp.