エンタープライズ規模のデータパイプラインでのツール選定(dbt vs dataform)

概要

こんにちは、バンダイナムコネクサスの小林です。今回は過去のブログでも取り上げた、ゲームタイトル横断分析ダッシュボードのアーキテクチャを見直したプロジェクトについてご紹介します。

2021年にローンチされたこの横断分析ダッシュボードは社内でも非常に好評で、利用者の拡大とともに出てくる様々な要望を取り込み、機能追加を行いながら運用を続けていました。

一方で、このダッシュボードを支えるデータパイプラインを運用するメンバーはごく少数であったため、限られたリソースは機能追加などのリクエスト対応に割かれることが多く、保守性やコストまで意識したアーキテクチャの改修は後回しになっていました。

ちょうど私がこのプロジェクトに入ることになったのは、既存のアーキテクチャでの運用が限界を迎え、GCPの費用が急速に増加した段階でした。すぐできるコスト削減の取り組みは既に始まっていましたが、それだけでは不十分であったため、アーキテクチャの見直しまで含めたコスト最適化を行うことが私のミッションとなりました。

データパイプラインの特徴

まずは、このプロジェクトで扱うデータパイプラインの特徴を整理するところから始めました。過去の記事にもあるように、このダッシュボードのデータパイプラインはcloud composer (airflow) 経由で実行されていました。

一部機械学習を使った処理も含まれていましたが、コスト的には無視できるものであり、肥大化したコストの大半はBigQuery Operatorsを使ったBigQueryのクエリ実行によるものが分かったため、BigQueryでの処理にフォーカスすることにしました。

次は扱うデータの特性です。ゲームログは様々なデータの中でも規模が大きくなるドメインであることは想像に難くないとは思います。何年も続いているゲームタイトルもあるため、1つのクエリでTB級のスキャン量になることは珍しくありません。

加えて、

• 新しいゲームは頻繁にリリースされること
• 既存タイトルはログデータが蓄積され、日々スキャン量が増加していくこと
• 既にKPIは数百個あるが、リクエストがあれば適宜追加していること
• 利用者によって知りたいことが異なるため、集計粒度も変化・増加すること（顧客軸、地域、プラットフォームなど）

といった形で、データパイプラインの本数・処理量が加速度的に増えていたことがコスト増加の主要因でした。そのため、こうした要望に応えつつも、費用を抑えて運用できる機能を備えたスケーラビリティに優れたアーキテクチャが必要になります。

また、データパイプラインの内部構成にも簡単に触れておきます。ダッシュボードで可視化するKPIは各ゲームタイトルで共通なため、データパイプラインは

• データソース間の差分を無くし同一スキーマを定義する中間レイヤー
• 同一のスキーマからタイトルごとのデータマートを生成する共通処理レイヤー
• 指定されたセグメント別にKPIを計算する集計レイヤー

の大きく3層で構成されています。

データパイプラインのイメージ

共通処理レイヤーのおかげで新規のゲームタイトルを追加する際には中間レイヤーを定義するだけでリリースが可能になるように効率化されていましたが、後続のレイヤーも度重なるKPIの追加により複雑性が上がっており、改修が非常に難しくなっていました。

なお、BigQueryのコスト最適化については、パーティショニング、クラスタリング、増分更新の実装、スロット契約プランの見直しなど、既に一定のベストプラクティスが確立されています。
そのため、そうしたベストプラクティスの中で漏れているもの、実行されているクエリの中で高額になっているものがあれば優先的に改修を行うことで短期的なコスト削減を実施しました。

アーキテクチャの見直し

並行して、アーキテクチャの選定を進めていきました。データ加工処理の大半はSQLで書かれているため、SQLワークフローエンジンの導入は必須としつつ、以下の3パターンを検討しました。

• dataform
• データオーケストレーションツール + dbt
• dbt cloud

選定のポイントとしては、

• ファイル数、ロジックの両面でデータパイプラインの規模が今よりさらに大きくなっても運用可能なスケーラビリティを備えていること
• データ変換処理以外のインフラ部分の運用工数を抑えられること

の2点を重視しました。

dataform

dataformはBigQuery向けにGCP上で提供されているSQLワークフローツールです。バンダイナムコネクサスではアナリストを始めとしたデータ分析チームがdataformを導入しており、全社的なSQLワークフローとして普及しています。

dataformのメリットは何より追加コストなしでSQLワークフローが組めるという点が優れています。scheduled queryなどで小規模な分析用データマートを作っているチームがもう少し複雑なデータパイプラインを作りたいような場合に適しています。

しかし、dataformには正常に動作するリソース数に制限が設けられており、今回の巨大なデータパイプラインはその制限に引っかかることは確実でした。

またパッケージ等周辺ツールも他と比較して乏しいため、高コストかつ巨大なパイプラインを運用するには不向きであると判断しました。

データオーケストレーションツール + dbt

データオーケストレーションツールを使うと、カスタマイズ性の高いデータパイプラインを構築することができます。dbtと組み合わせることも可能で、airflowの場合はcosmos、他にもdagsterなどが有名です。

しかし、カスタマイズしたデータパイプラインを技術的負債にすることなく運用し続けるには、高い技術力を持った専門の運用チームをアサインする必要があるなど、組織として相応のリソースを割く意思決定が求められます。

一方でデータパイプラインを運用するチームは前述の通り少人数な上にデータ分析業務の支援など幅広い業務を担当しており、たとえ新しいツールやパッケージを導入したとしても、オーケストレーションツールのインフラを運用し続けるリソースが足りないという根本的な問題は解決できないと考えました。

また、アーキテクチャ選定の過程で既存のairflowのコードを精査しましたが、主要な処理はBigQuery to BigQueryのデータ変換処理であり、dataformやdbtのようなSQLワークフローエンジンで実装できない機能や要件も見当たらなかったため、現在使っているairflowの利用は徐々に減らしていく方向で進めることにしました。

dbt cloud

最後はdbt Labs社が提供しているマネージドサービスであるdbt cloudです。マネージドサービスゆえに一定の費用は発生しますが、インフラの運用工数を抑えながら高品質なデータパイプラインを構築することができます。

また、dataformにはない以下のようなスケーラビリティを備えていることも今回の要件に合致していました。具体的には、

• enterprise版であれば複数リポジトリをシームレスにつなぐことも可能で、ファイル数がさらに肥大化しても管理がしやすいこと
• 高機能なデータカタログがあり、複雑なデータパイプラインでも効率的に運用できること
• semantic layerのようなスケールさせやすい機能も含まれており、将来的な導入を進めやすいこと

が挙げられます。一方で一定規模以上の会社で大規模に利用するケースでは、高額なライセンス費用がボトルネックとなりがちです。しかし、今回のケースのように小規模なチームが局所的に導入する分には、費用を抑えつつも効果を最大化できると考えました。

導入決定までのやり取り

上記のような判断要素を資料にまとめ、dbt cloudの導入をマネージャーに提案しました。承認を得る過程で最も深く議論したのは、「なぜ既に全社的に使っているdataformではダメなのか」という点でした。

社内で似たようなツールを自由に使ってしまうとやがてガバナンス等の面で問題が出てくるので、当然慎重になるべきポイントです。私からは、本プロジェクトではスケーラビリティやインフラの運用工数削減が重要であること、対象のデータパイプラインであればライセンス料を上回る効果が十分に得られることを説明し、最終的には導入を承認いただきました。

dbt cloud導入時の工夫

dbt cloudの導入にあたって、組織構成やデータパイプラインの特性に合わせていくつか工夫を行ったため、その一部をご紹介します。

全リソースをterraformで管理

dbt cloudでは公式のterraform providerが提供されています。また、dbt cloudを触るメンバーはエンジニア寄りのメンバーに限られるため、jobを始めとしたterraformで定義できるリソースはすべてterraform管理下に置き、GUIでの操作は行わないルールにしました。

こうしたSaaSのよくある注意点として、利用者がGUIで自由に設定値を操作できてしまうゆえに統制を効かせる難しさがありますが、terraformでの管理によってリソースの管理や複製が行いやすくなりました。

emptyフラグを使用した開発環境での検証の効率化

対象となるデータが巨大な場合、開発段階であってもDWHでのクエリコストの増加や実行完了までの待機時間による開発生産性の低下が懸念されます。都度ダミーデータを用意することも手間なため、開発環境ではdbt core 1.8で追加されたemptyフラグを使うようにしています。

このフラグをつけるとBigQueryではクエリにlimit 0が追加され、実際のデータがスキャンされなくなるため、高速かつ追加コストなしでクエリの検証ができます。

加えて、まだ本格的な導入はできていませんが、dbt unit testと組み合わせることで、CIの時点で

• SQLの構文エラーがないこと
• 想定しているデータに対してSQLロジックが正しく動作すること

をDWH側の追加費用なしで保証できるようになるため、バグの可能性をかなり減らすことができます（実際のデータが想定と乖離している場合など、エラーになるケースが一部残ることには注意が必要です）。

elementaryでのdbt cloudの実行状況のモニタリング

データ監視・モニタリングツールであるelementaryも導入していますが、dbt cloudの機能と重複する部分もあるため、現時点ではパッケージが出力するデータを流用する形でパイプラインのパフォーマンスやコストの監視に使用しています。

既存のアーキテクチャでは「このゲームタイトルの分析にはどれだけの処理時間と費用がかかっているのか」という問いに対して簡単に集計するのが困難でした。dbt cloudでもコンソールログやGUIには記録として残っていますが、細かい分析がすぐできる状態ではありません。

しかし、elementaryパッケージを導入することで、job_idとjob_run_idといったdbt cloud固有の情報も dbt_invocationsというテーブルに出力することができます。こうしたelementaryが定義するテーブルを組み合わせることで、前述の実行時間やコストのデータをゲームタイトルごとに集計してBIツールで可視化できるようになったため、すぐにクリティカルなポイントを特定できるようになりました。

最後に

目標であったコスト削減については、dbtに移行させつつ実行しているクエリやBigQueryの設定値の調整などを行った結果、稼働中のデータパイプラインの本数を削ることなく、コストが急増する以前の水準にまで戻すことができました。

新しく導入するツールとして今回はdbt cloudを選択しましたが、組織構成・扱うデータの特徴・予算など、様々な要素によって最適なソリューションは変わってきます。

また、目先の負債の解決だけでなく、数年先でも安定して運用できるアーキテクチャを選定するためには、それぞれのツールの特徴を理解していることを前提として、開発生産性やデリバリー先であるBIツール利用者の利便性といった組織のニーズも考慮した上で適切な選択を行うことが重要です。それゆえに、単一の最適解がないことが技術選定の難しさであり、面白さでもあると改めて感じました。

本記事執筆時点ではまだ移行作業の過程ですが、dbtへの全面切り替えが完了すればsemantic layerの導入など、データ品質のさらなる向上に向けて新しい領域にもチャレンジしたいと考えています。