BigQueryの布教活動をしていますna0です。 この文書は、BigQueryリソースに対する期待値をラベルで明示する提案を行うものです。
組織全体でデータ品質に合意するための第一歩としてBigQueryリソース ラベルを使ってみませんか。 ラベル品質のベースラインとして、マネーフォワード ケッサイで運用している規約を紹介します。
BigQueryリソース ラベル規約
この文書は、データ活用を促すためのBigQueryラベル規約を定めるものです。 提案、指摘をお願いします。
結論
- BigQueryリソースに対する期待値をラベルで明示しましょう
- 一貫性を持ったラベル付けのために、規約を整備したのでご協力ください
課題意識
BigQueryの利用者が増えていくと、リソースに対する期待値も様々です。 期待値に合うリソースなのかを利用者自身で判断できる状態が望ましいです。 期待値がずれていると、せっかく提供しているデータも期待したデータ活用効果が得られなくなります。
そこで、ラベルを使って期待値の構造化を行うことで利用者が判断できると同時に、提供者が正しく提供できているかを評価する仕組みを構築します。
また、意味の一貫性を持ったラベルを付けてデータ活用を推進できるように、ラベル規約を明文化して運用します。
BigQueryラベルとは
ラベルの概要より抜粋。
BigQuery リソースを整理するために、データセット、テーブル、ビューにラベルを追加できます。ラベルとは、リソースに添付可能な Key-Value ペアです。BigQuery のリソースを作成するとき、ラベルは必須ではありません。
リソースにラベルを付けると、ラベル値に基づいてそのリソースを検索できるようになります。たとえば、ラベルを使用してデータセットを目的別、環境別、部署別などにグループ分けできます。
ラベルを使うとデータセットやテーブルにKey-Valueペアを自由に定義できて検索性を高めることができます。 ただ各チームバラバラにつけても検索性は上がらないので、ここではマネーフォワード ケッサイの運用を叩き台として共有します。
ラベル規約
必須と書いてあるものは、新規にリソースを作成する際に入れましょう。 それ以外は推奨していますが、任意です。
state
状態のラベルで、deprecated 、 supported が入ります。
設定されていないものはサポート中として扱います。非推奨リソースに deprecated を設定し、いつまでも使われないように、Slack Botから促すために使っています。
公式のガイドラベルの概要でも例としてあるラベルですね。
状態のラベル: state:active、state:readytodelete、state:archive など。
update_frequency
リソース利用者に保証する更新頻度を入れます。現状は、hourly、daily、weeklyを想定しています。
更新頻度はCloud Composerで管理していますが、こちらは表向きにデータ利用者に対して整備者が保証する更新頻度です。
原則毎日更新ですが、最大で一週間遅延することがあります。といった感覚を広く共有して、メンテナンスしやすくしたい意図があります。 利用者とうまく認識合わせていきたいですね。
created_by
テーブルの生成リポジトリを入れて、メンテナンス時に生成ロジックを追えるようにします。
リソース作成は以下に絞っており、生成ロジックはどこかでコード管理されているはずです。
Deployment Manager
データセット、外部テーブル、ストリーミングインサート用の空テーブルの作成に使います。
Cloud Composer
動的な外部テーブル（Cloud SQLの全テーブルなど）の作成、定期更新に使います。
dataform
ビュー、UDFの作成に使います。
dataset_type（必須）
lake 、 warehouse 、 mart のいずれかを入れます。頻度の高いmartクエリをwarehouseに格上げしたり、martからwarehouseの参照がされていないかの怪しさをチェックしたりします。
dataset_typeは以下のように分類しています。
Lake
データソースまたは、その複製で一切のデータ変換、クレンジングを行っていないものを指します。
データソースの例
- 本番環境のCloud SQL
- スクレイピングしたデータ
- アンケート結果
- Salesforceなど
Lakeの例
- EXTERNAL_QUERY
- bq loadしただけのデータ
- GCS外部テーブル
- Salesforce取り込みデータ など
Warehouse
Lakeを使いやすく、クレンジング、集約、結合、フィルタしたもので、多目的なものを指します。
Warehouseの例
- データの欠損の除外や文字列の正規化を施したもの
- アプリケーションログのうち特定のイベントだけ取り出したもの
- 入金消込を行った取引記録 など
Mart
Warehouseを単一の目的のために、集約、結合、フィルタ、列選択したものです。
理想的には、結合処理をWarehouse層に限定し、Martでは集約・列選択・フィルタのみを行うようにしたいです。 ただ、利用を妨げる害も大きそうなので、今のところは厳密に定めていません。
Martの例
- 月別の入金状況を可視化するために集計した表
- Salesforceに送信するための表 など
materialization_frequency
ビューや外部テーブルの実テーブル化頻度として hourly 、 daily を入れます。
このラベルがついたリソースは、Cloud Composerから SELECT * FROM {{ table }} で __materialized サフィクス付きの実テーブルを定期生成されます。
実テーブルの方が速度や権限設定に優れるため、エンジニアの試行錯誤用です。リアルタイムデータが欲しい場合にはビューを使ってください。
inserted_by
ストリーミングインサートされるテーブルで、インサート元を特定可能な情報を入れます。 原則、リポジトリ名を入れますが、Zapierなどリポジトリ管理されない外部サービスから挿入される場合には、サービス名を入れます。
ストリーミングインサートが適切かは良く検討しましょう。
{{ team }}__{{ label }}
チーム固有のラベルがある場合、チーム名とアンダースコア2つ、固有ラベルを結合したものを追加できます。 全体で利用可能であれば、チーム固有のラベルから昇格させることがあります。
例えば、 data_forward チームの priority なら、 data_forward__priority ラベルを使います。
その他のアイデア
現在は、利用しているデータソースの特性上、適時性に比重を置いたラベルが多いです。 今後、他のデータ品質についてもチェックする必要性が出てきたらぜひ提案してください。
規約を守るべきか
BigQueryリソースがルールに則っているかは、Slack Botで定期的にチェックします。 ルールに則っていないから悪い、守れ！ではなくて、なぜギャップが生まれているのか、差異を埋める仕組み作りは今後の課題です。
BigQueryリソース ラベル運用で得られたこと
運用を始めたばかりで、成果らしい成果は出ていませんが、エンジニア向けには以下のような小さなメリットを出せています。
- サポートステータス
stateを明示したことで非推奨リソースを参照するクエリジョブを簡単に探せて、embulkからBigQueryのCloud SQL連携クエリに素早く移行できた - 保証更新頻度
update_frequencyを元に要求されている更新頻度を保てているかチェックでき、データの最新性管理が可能になった - 作ったビューに、実体化頻度
materialization_frequencyラベルをつければ、実体化を自動的に行うようになった
この他にも、ラベルの使い方によって様々なデータ品質に合意していくことができるのではと期待しています。
bigquery.tables.get権限を持っている人はラベルからデータの品質が確認できるので、今後は組織全体でデータ品質に合意できるように進めていきます。
最後に
データ品質に関する課題は組織それぞれで、1つの対応で全ての組織の課題が解決するものではありません。 ぜひ皆様の様々なデータ活用方法を教えてください。
最後までご覧いただきありがとうございました。