開発部データエンジニアの遠藤です。現在、私はデータ×テクノロジーでZOZOグループのマーケティングを支援するデータチームに所属して、データ処理基盤の運用などに従事しています。本記事では、Lookerを用いて運用中のデータ集計基盤をきれいなデータをスマートに取り出せる基盤に改良した件について報告します。~データガバナンス機能~LookMLデータディクショナリGitによるバージョン管理データ集計基盤(改)の設定フローデータ集計基盤(改)でのデータマート更新まとめデータ集計基盤で燻っていた問題ZOZOでは、サービスに関するあらゆるデータをBigQueryに集約しています。BigQueryに集約した大量のデータからデータマートとして必要なデータを取り出し、BIツールの可視化や機械学習システムの入力データなどに用いています。データマートは以下の2ステップで作成します。SQLを作成してデータ集計基盤にセットデータマートは、BigQueryへのマスタデータ取り込み完了後にデータ集計基盤上でクエリを順次実行して、毎日更新しています。データ集計基盤を運用していくにつれて以下の問題が発生しました。クエリ管理の限界ZOZOでは現在までに多くのデータマートが生成され、その総数は数百にのぼります。数百のSQLファイルを管理していることになります。SQLファイルがここまで増加した背景として、車輪の再発明による量産状態になっていたことが挙げられます。データマートの作成要件があるたびにSQLを1から作り上げたため、アウトプットが似ている当時のベストエフォートクエリが複数のSQLファイルに散在していました。データベースのシステム仕様に変更が生じた際、SQLファイル群から変更箇所を全て探し出して修正しなければならず、クエリの修正工数が膨大になることも問題となっていました。そのため、クエリの効率的な管理の必要性が叫ばれていました。集計定義に対するデータの信憑性が謎データベースのシステム仕様・ビジネス的な集計定義・データマートにおけるアウトプットは、基本的にクエリ内のSQLで表現し、それでも分かりにくい場合はクエリ内にコメントを付記することで管理していました。その管理では集計仕様の把握コストの増加(クエリからそのクエリの表現に至った背景・経緯までは理解しにくい)集計結果が当初取り決めた集計定義とずれる(定義に沿った集計フローに対してシステムレベルまで関係者全員の意識を合わせることは難しい)システム仕様変更に追随しきれない状態になると集計結果の正確性が左右されるのような問題が起きてしまいました。その結果、「今日の数字、何か間違ってない?」と集計データに関する問い合わせが頻発し、(ビジネス側から見て)データ集計基盤における集計精度の信憑性を疑問視する(システム運用側から見て)原因調査からリカバリまでの誤集計に対する一連の障害対応の工数が膨らむといった誰も得しない状況に陥る恐れがありました。そのほかにも、データ集計基盤には様々な根深い問題が存在していて、以下の図に示す内容に集約されます。現状のデータ集計基盤では、ビジネス側で集計定義が完璧に決められていたとしても、誤った情報などが蔓延りやすくデータドリブンな意思決定の精度を下げるリスクがありました。~データガバナンス機能~データチームは、データ集計基盤で起こる様々な根深い問題に対してシステムによる解決アプローチを模索したところ、Lookerというツールに目をつけました。SaaSで提供しているBIプラットフォームです。Looker充実したReporting・Visualization機能がLookerの大きな特徴で、Lookerを国内で導入している企業のほとんどがBIツールとして使用しています。Lookerと他のBIプラットフォームツールの相違点は様々あるのですが、ここで特筆すべき決定的に違う点...。