はじめに

DeNAのゲーム事業のデータ分析基盤は、以下の2つに分類されます

1. ゲームタイトル横断で共通で処理できるものをまとめて処理してデータをゲームタイトル毎に配布する基盤
2. ゲームタイトル毎に独立で構築する基盤

共通処理を行う基盤では、開発ツールやディレクトリ構成、コードの書き方などの統制が取りやすいです。 一方、ゲームタイトルごとの基盤ではデータエンジニアがその時点で良いと判断した方法を取り入れて開発するため、統制が取りづらい状況があります。
今回は、独立したゲームタイトルごとのデータパイプラインの開発環境について話します。

対象者

• データエンジニア
• アナリティクスエンジニア
• dbtを使ったデータパイプライン開発を行うロールの方

今回話さないこと

• dbtや導入している技術の基礎知識
• ワークフローエンジンのDAGの開発
• インフラの構築

現行の開発環境

現在、digdagをワークフローエンジンとして使用しています。 処理に使うものとして、PythonやSQL、Shell Script、Rubyなど状況に応じて選択しています。 一部ではdbtも導入されていますが、基本的な構成は同じです。 共通化されている部分は、課金やアクセス系のマートをタイトル共通のロジックで処理しています。共通化にはGitサブモジュールを使用しています。

以下の図は、現在の実行環境の構成イメージです。

この構成の良いところ/辛いところ

良いところ

• digdagのDAG作成はyamlで行えるため、学習コストが比較的低い
• 処理ファイルをリポジトリに置くだけでデプロイできる手軽さがある

辛いところ

• digdagが全ての依存関係を管理する形を取るのでデータパイプラインのコードは、digdagで動かすせるように依存関係を意識した開発が必要です
  • 例えば、データマートの作成するときに、依存するテーブルがdigdagのどの段階で処理されているかを確認して、依存関係に矛盾が発生しないように対応する必要があります
• 開発を行う際にdigdag上とローカル環境を再現する方法がチームで確立されておらず、個人ごとの開発環境の統制が取れていない状況でした
• 弊社の環境は、直接GKEのワーカーにdigファイルをデプロイするようになっているため、Github Actionsを使うにはセキュリティルールをクリアする必要があります
• 外的要因ですが、ここ1 ~ 2年の新規プロジェクトでは構成が変わっており同じロジックを転用できないことが増えてきました

以上の理由から、この構成を継続するのが難しくなり、プロジェクトごとに適したデータパイプラインを構築しやすい環境が必要となりました。

開発中プロジェクトの開発環境

digdagの辛いところで発生した問題を解消するために、SQL処理のDAGをdbt中心としたデータパイプライン開発に切り替えました。 それに伴い、複数のプロジェクトで担当者それぞれで開発環境を作る形を取っています。 ワークフローエンジンは、Cloud Composer(Google Cloudが提供するAirflowのフルマネージドサービス)を採用しました。 また、データパイプラインの実行環境は、Cloud Batchを採用してDockerfileで開発したものを実行することでローカルと実行環境の差分を減らすことに成功しました。

また、簡単なdbt開発テンプレートを作成してそれを使うことでプロジェクト間で近い開発環境を実現できています。

以下の様なイメージで実行環境が構成されています。

この構成の良いところ辛いところ

良いところ

• SQLをdbtの記法に合わせて作成すればDAGの作成がされるため、データパイプラインをdbtワンストップで構築可能
• Dockerfileを中心に開発が行えるため、ローカルの実行と実行環境の実行の条件を比較的合わせやすい
• dbtの機能を活用し、データのテストやデータリネージュなどの開発を担保、補助する機能を活用できます

辛いところ

• dbtに変数を設定して、実行するクエリを制御できるために人によって入れる変数が変わりチーム開発で混乱が発生し易い
• SQLの書き方に差が生じ、品質にばらつきが発生する (dbt テストを厳密に書く場合もあれば省略されている場合もあったり)
• 統制がとれていない状態の開発環境の提供の形式を取っており、プロジェクト間で開発スタイルに乖離が発生して認知負荷が発生している

以上の理由より、データパイプラインの開発は一定やりやすくなり生産性は向上しました。 ただ、以下の理由により開発担当者、場合によっては同プロジェクトのメンバー同士で開発スタイルの違いが発生しチーム開発に混乱が発生している場面が増えてきました。

• 開発リポジトリの構成の統制を厳格にしていない
• SQLを拡張するツールの特性でより自由度が増した記述方式

開発環境の改善のコンセプト

今までの開発環境の辛いことがチームで発生していることと、ある程度dbtで開発することに慣れるようになりました。 このタイミングで開発環境の改善を目的としてdbtを中心に新しくチーム標準の開発環境の構築を行いました。

以下のコンセプトの元の改善の取り組みを実施しています。

• データパイプラインの開発でローカル(メンバー間含む)と実行基盤で同じ実行条件を実現する
• データパイプラインの開発スタイルをチーム全体で揃えられるようにし認知負荷を下げる
• SQLとデータパイプラインの品質の水準を一定以上高めてより質の良いアウトプットの作成を目指す

改善に向けて作っている開発環境の構成について

上述したコンセプト実現に向けて下図のアーキテクチャの作成とそれを実現するためのツールの導入を行いました。

開発環境の改善に向けて取り入れているツールについて

開発のフロー

この開発環境を使って、dbtプロジェクト生成からブランチへのマージまでの開発フローを例示します。

1. 開発環境のルートディレクトリでデータパイプライン開発テンプレートディレクトリを複製します
2. 複製したテンプレートディレクトリでVSCodeを開きます
3. ディレクトリにdocker-compose.ymlがあるのでdev-containerを実行して開発向けの仮想環境を構築します
4. 仮想環境でdbtプロジェクトを生成するツールを実行して、dbtプロジェクトの生成と実行環境を構築します
5. リポジトリにコミットするタイミングでpre-commitが自動で実行され、SQLFluffとdbt-project-evaluatorで統制をとりました
6. プッシュしたコードとディレクトリ構成は、すでに統制が取られるため、レビュー負荷がある程度軽減された状態ものでprを作ることができます
7. レビュワーは、開発したロジックが正しいかを集中してレビューし、問題なければmain/devマージへ段階を持ってマージされていきます

デプロイして実行基盤での実行

1. 開発フローに則って実装が完了したらGithub ActionsにてCDのワークフローが実行されます
2. CDは、Cloud BuildでのDockイメージをビルドしてArtifact Registryにデプロイします
3. Artifact RegistryにあるDockerイメージをCloud Batchがロードしてデータパイプラインの実行環境を作ります
4. Cloud Batch実行時に渡すエントリーポイントをpythonで開発したデータパイプライン実行I/Fが受け取って任意のdbtやpythonの実行をします

1 ~ 3の手順ができれば、Cloud Batchの実行先はデータパイプライン実行I/Fに沿った入力値を渡してワークフローエンジンでもローカルでも同じ実行環境からの実行結果を得ることができます。

何が改善できたか

この構成の開発環境を作ったことで、コンセプトとして挙げたものを達成して以下の改善ができると考えています。

• データパイプラインの開発スタイルの統制
• データパイプライン実行I/Fによる実行結果の再現性の向上
• コード、dbt projectの品質の水準の底上げ

今後の展望

標準開発環境は、現在作成したばかりでこれから実際に開発をしているプロジェクトに展開をしていくのでまずはその展開を進めています。 また、dbt以外のデータパイプライン開発ツール(特にpythonを使ったデータインジェストなど)が作られることが予想されます。 それらの開発でも開発スタイルの統制と安定した実行I/Fの提供ができる方法の検討をしていければと思います。

まとめ

時間の経過と共に様々な技術や開発スタイルが世の中やチームの体制の移り変わりによって作られ変化が求められると思います。 その中で、チームとして生産性を落とさず安全に運用に繋げられるような標準化のアップデートを続けその時点でチームで良いと考えたものに更新することが重要と考えています。

今回作った標準のデータパイプライン開発環境も決してゴールではないので引き続きアップデートを加えていければと思います。

また、ある程度変更がまとまったタイミングこの様な記事出していこうと思います。