はじめに
こんにちは。レバレジーズ データ戦略室の辰野です。 前回の投稿からいつの間にか1年以上経過していました。引き続きデータマネジメントやデータガバナンスに関連する仕事をしていたのですが、今回は私が昨年度末に取り組んだ、Dataformを利用したデータ分析基盤の構築についてお話させていただきます。
Dataformとは
Dataformとは、現在Google Cloudで利用できるデータモデリングツールの一つです。ELT（抽出、読み込み、変換）処理における、T（変換）の部分を管理できます。主な機能として、下記があります。
- SQLワークフローを開発、実行できる
- テーブル同士の依存関係を管理できる
- テーブルの品質テストができる
これらの機能を利用することで、すべてのデータプロセスを管理することが可能です。
（参考：Google Cloud,Dataform の概要）
Dataformを導入することになった背景
データマネジメントに注力するフェーズ
ここ数年、レバレジーズではデータの民主化を進めるべく、さまざまな取り組みを行ってきました。データマートの拡充、BIツールの活用などはある程度進んでいる状況でしたが、以下の課題がありました。
現在どういった設計になっているかの説明は割愛しますが、今後更に事業が拡大しデータ活用が進んでいく前に、上記の課題を解決することが重要視されるフェーズにありました。
そこで、これらを解決するための一つとして、データモデリングツールの導入を検討することとなりました。
この時、データモデリングツールはGoogle CloudのDataformを利用しようとしていましたが、利用目的の一つである依存関係ツリーの参照画面がまだリリースされておらず、見送っている状態でした。
※Dataformを選んだ理由はこの後に記載します
採用管理システムの変更と依存関係ツリーのプレビュー版リリース
元々、採用データを専任で管理しているメンバーがいなかったので、データ分析基盤やSQLワークフローの管理はかなり煩雑な状態でした。そんな時、人事の採用管理システムをリプレイスするプロジェクトが動き出し、私はそのプロジェクトでデータ分析基盤の再構築を担当することになりました。 ここで、
- 現状データ分析基盤が整っていない
- リプレイスなのでデータの移行期間を設ける必要がない
ということを踏まえると、データモデリングツールを導入するならこのタイミングがいいのでは？という考えに至り、最初に採用部門から実装してみることになりました。 また、ちょうどこの時、Dataformの依存関係ツリーのプレビュー版がリリースされ始めたことも決め手でした。
Dataformを選んだ理由
いくつかのデータモデリングツールが存在するかと思いますが、技術調査を行った結果、レバレジーズで利用するならDataformが良さそう、という結論に至りました。 主な理由は下記の3点です。
1.導入ハードルが低い
他のツールと比較して、導入ハードルが低いと感じた点は以下です。
- Dataform自体は無料で使用できる
- 環境構築に難しい技術スキルは不要
まず、Dataformは無料のサービスなので、簡単に試すことができ、追加で契約する必要もありません。また、基本的に操作はGUI上で完結し、データ変換の管理にはSQLベースの言語を使用するので、SQLを理解していれば難しいことはありません。
（参考：Google Cloud,Dataform）
2.データ管理がGoogle Cloud内で完結できる
レバレジーズではデータ管理にBigQueryを利用しています。そのため、同じGoogle CloudのサービスであるDataformであればBigQueryと接続させる作業は不要になり、一貫したデータ管理が可能です。
3.Gitリポジトリに接続しコードのバージョン管理が可能
接続作業は現在取り掛かっている途中ではありますが、Githubと連携することでチーム内でのコード共有、バージョン管理が可能になります。 基本的にデータ戦略室のコード管理はGithubで行っているため、連携できることのメリットは非常に大きいです。 これらの理由から、レバレジーズではDataformを導入することに決定しました。
データアーキテクチャ図
Dataformを導入する際のデータアーキテクチャは、下図のように設計しました。
採用に関するローデータ保管から、BIツールへ接続させるまで全てGoogle Cloudのサービスで完結します。
Dataformのスケジュール管理は、当時はGUIでの設定はなかったので、WorkflowsとCloud Schedulerを利用することにしました。
（参考：Google Cloud,Workflows と Cloud Scheduler を使用して実行をスケジュールする）
現在はGUIでも設定できるようなので、設定内容をバージョン管理する必要がなければWorkflowsなどを利用しなくても良いかと思います。
（参考：Google Cloud,ワークフロー構成で実行をスケジュールする）
導入にあたって気をつけたポイント
導入時は、リポジトリ内の構造に配慮しました。Dataformでは、作成したリポジトリの既定ディレクトリ内にファイルを作成しますが、更に下層にディレクトリを作成し、階層構造で管理することが可能です。今後リポジトリ内で検索する際の利便性も考え、今回はデータセット毎にフォルダを作成し、その中に対象テーブルのファイルを作成することにしました。ファイルパスには必ずその階層までのディレクトリが入るので、ファイル名にはテーブル名を入れて管理することにしました。
現在、公式ガイドにもリポジトリ内の構造化についてベストプラクティスが掲載されているようなので、参考にすると良いと思います。
（参考：Google Cloud,リポジトリ内のコードを構造化する）
Dataformのメリット
Dataformを導入するなかで、特に以下の機能が便利だと感じました。
SQLワークフローが依存関係に従って実行される
レバレジーズの各部署のSQLワークフローは、Github上にSQLコードを作成し、実行順を明記したワークフローファイルを用意してdigdagを使って実行させていました。ですが、Dataformではファイルごとに依存関係を定義することで、依存関係ツリーの順番に従ってSQLを実行してくれるので、ワークフローファイルを別途管理する必要がなくなります。現在の運用だとワークフローファイルのレビューに工数がかかったり、一連の実行管理をデータエンジニアが行う必要があったので、その分の工数削減に繋がると感じています。
タグ指定のSQLワークフロー実行
Dataformでは、各ファイルごとにタグ付けができます。このタグを利用して、SQLを実行するファイルを選定することも可能です。例えばdailyのような更新頻度を表すタグをつければ、ワークフローのスケジュール設定時に「タグにdailyを含む」と指定することでそのタグがついたファイルだけ実行させることが可能です。
また、指定したタグに関連する依存関係や依存元を実行に含めるかどうか、テーブルの更新方法も指定できます。
テーブル品質テストと依存関係テーブルの実行制御
アサーションを作成することで、データ品質テストをすることが可能です。 また、アサーションを依存関係として追加することで、例えばテーブルBがテーブルAに依存している場合「テーブルAのアサーションに合格した場合のみ、テーブルBを実行する」といったことが可能なので、誤ったデータを更新してしまうといったことが防げます。
今後の課題
現在、すべての部署でDataformを導入するためのプロジェクトが進行しています。データ品質が保たれる仕組みを作り、SQLワークフロー管理の属人化を防ぐことで、データガバナンスを強化します。 また、BigQueryのメタデータ管理の整備も進行しており、同じくGoogle CloudのサービスであるData Catalogを利用予定です。今までメタデータはスプレッドシートで管理していましたが、これにより、データ利用者はデータ探索やメタデータの閲覧をGoogle Cloud Console内で完結できます。 今後も、データを効率的に、かつ安全に利用できるよう整備していきたいと思います。
