データウェアハウスのバージョン管理をどうやるか

というのをチームで議論する機会があったので、書いてみます。「うちではこうしている」とか「ここはこっちのほうがいいんじゃない?」とかあったらコメントで教えてください。

背景 / 前提

  • データウェアハウスのテーブルを社内に広く提供したい
  • 初期の提供時期が過ぎてしばらくすると、要望を元にスキーマの変更や集計ロジックの変更が入る
    • (事前にレビューはもちろんするが)SQLのミスなどで以前のバージョンに戻したいといったことがありえる
    • 他の部門では新しいバージョンをすでに使っていて、気軽に戻せないこともある
  • データウェアハウスのバージョンを場面に応じて複数提供できると都合がよい
  • 一方で、大多数のデータウェアハウスのユーザーは最新バージョンの利用だけでよいはず
    • SSOT(Single Source of Truth)になっていて欲しいわけなので...
    • 複数バージョン見えていると「どのバージョンを使えばいいの?」と迷いが出たり、不必要な問い合わせが増えてしまう
    • 複数バージョンが見えていると、古いバージョンをずっと使い続ける人が出てくる
      • 複数のバージョンを長い期間メンテナンスし続けるのはコスト的に辛い
    • 必要な人だけ過去のバージョンを提供したい
      • ユーザーに見せる必要がないものは隠蔽したい

解決方法の一例

ここではcustomerというテーブルをデータウェアハウスで公開すると仮定する。BigQueryのデータセットなどをイメージして欲しい。こういう構成を考える。

  • customer_versionizedデータセット
    • customer_v0.0.1テーブル
    • customer_v0.0.2テーブル
    • ...
    • customer_v1.0.0テーブル
  • customerデータセット
    • customerビュー
      • ビューの内容としてはSELECT * FROM customer_versionized.customer_v1.0.0という感じで、最新のテーブルへの参照が実態

管理としては以下のようにする。

  • データウェアハウスの一般ユーザーにはcustomerデータセットにのみ閲覧権限を付与する
    • 色んなバージョンが見えると混乱の元なので、customer_versionizedデータセットはそもそも見えないようにしておく
    • このままだと、ビューのクエリSELECT * FROM customer_versionized.customer_v1.0.0も叩けないので、データウェアハウスの一般ユーザーに対して承認済みビューでクエリは叩けるようにしておく
      • 承認済みビューなので、データセット自体は見えない
  • バージョンを上げる際にやることは、ビューで指定しているバージョンを書き換えるだけ
  • 管理者や一部のシステムで過去のバージョンが必要な人だけにcustomer_versionizedデータセットの閲覧権限は編集権限を付与する
    • 「古いバージョンはdeprecatedだから、なるべく早く最新のバージョンに乗り換える必要がある」といったバージョン管理の事情が分かっている人のみに公開する
  • customer_versionizedデータセットを見ている人は限定されるので、古くなったバージョンの削除は割とやりやすい(はず)
  • 必要な場合は、各バージョンのテーブルスナップショットを保存する

所感

  • 管理のしやすさと利用者の迷わなさを考えた結果、この形になった
  • 細かく切り分けできる仕組み & 運用もそれほど手間ではない気がする
    • 承認済みビューの存在はあるが、Terraformで管理できるのでそこまで難しいことにはならないはず
  • APIのバージョン管理と似た形に落ち着いた気がする