というのをチームで議論する機会があったので、書いてみます。「うちではこうしている」とか「ここはこっちのほうがいいんじゃない?」とかあったらコメントで教えてください。
背景 / 前提
- データウェアハウスのテーブルを社内に広く提供したい
- 初期の提供時期が過ぎてしばらくすると、要望を元にスキーマの変更や集計ロジックの変更が入る
- (事前にレビューはもちろんするが)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のバージョン管理と似た形に落ち着いた気がする