プロダクトDB × BigQuery × スプレッドシートのカオスを終わらせた話

当時はプロダクトDBの各テーブルをBigQueryに同期し、そのテーブルを非エンジニアが直接クエリできる状態でした。各関係者はスプレッドシートなど各ツールで独自にクエリをカスタマイズしており、それを分析や事業運営上重要な数値を出すために利用していました。

ツール導入前の課題

• プロダクトDBに対するテーブルスキーマ変更の影響範囲が測れない
  • クエリ利用者が独自にクエリしており、どのテーブルがどのように使われているかを洗い出すのが困難
• 再利用性の低い複雑なクエリが散財している
  • 一つの結果を出すためにいくつものJOINを必要とし、複雑なクエリになっていた
  • このクエリがまた別の目的のためにカスタマイズされ、冗長なクエリが量産されていた
• BigQueryと接続するスプレッドシートがエラーになる
  • 一つの目的のために、BigQueryと接続しているシートAを、さらにBigQueryと接続しているシートBが参照する、という多段構成のときにシートの読み込みが遅い、エラーになる

どのような状態を目指していたか

• プロダクトDBの各テーブルの中で、どのテーブル・カラムがどのような形で利用されているかが可視化されている状態
• スプレッドシートなどで利用する時点で必要なカスタマイズの8割が完了している状態
• 一つの目的のためにシンプルなクエリを書けば欲しいデータが取得できる状態

• 内部的にはBigQueryを利用するだけなので追加の費用なく開始できること
• クエリの構築はBigQuery Studioとほぼ同じなので、将来的にエンジニア以外でも編集できると考えたこと

改善したかった課題はどれくらい解決されたか

• BigQuery上でケアすべき影響範囲を完全に可視化できた
  • 共用dataset（スプレッドシートなど各ツールから利用される）を用意し、そこにDataformで加工したテーブルを出力する構成。
  • ここで出力されるテーブルのスキーマが担保されていれば、Dataform内をどれだけ変更しても問題がない
• 再利用性の低い複雑で冗長なクエリは、たった数個のJOINでカスタマイズが完了するほどシンプルになった
• シートの読み込みを高速化できた

どのような成果が得られたか

• プロダクトDBのカラム修正、削除のハードルが低くなった
  • Dataformの加工に問題が発生する場合はアラートを出して、エンジニアが気付ける状態にした
• Git管理されることでクエリの品質を管理しやすくなった
  • エンジニアの視点を入れて必要な共通化ができるようになった
• データ分析やその他で、どんなデータが必要とされているか見通しやすくなった
  • エンジニアが関与していない箇所でどのような利用がされているかキャッチアップしやすくなった
• スプレッドシートが軽くなった
  • クエリを結果を使用しているシートを、さらに別シートで参照する、という多段利用の場合に読み込みが遅くエラーになる問題があったが、解消した