トップ > BigQuery > Dataplex(旧Data Catalog)によるデータカタログの調査

Dataplex(旧Data Catalog)によるデータカタログの調査

BigQuery データ基盤

Dataplex(旧Data Catalog)によるデータカタログについてあれやこれやれやをまとめておいたポインタが欲しくなってきたので、とりとめもなくつらつらと書きます。

注意点:

  • BigQuery on GCPの運用を前提に書いてます
  • Dataplexはデータカタログ以外の機能もたくさんありますが、データカタログの観点にフォーカスして書いてます
    • 論理的なデータ構造を作成したり、それに基づいた権限管理など
  • 少人数のチームでデータ基盤を運営しており、データカタログの運用自体に工数をなかなか割けない前提で書いてます
    • 自前で作ることも難しいし、ましてそれを継続的に運用するのはさらに難しい
  • 「データカタログ」という言葉が指すスコープも色々ありそうですが、「検索 + メタデータ管理」くらいのスコープで書いてます
    • 包括的に書くつもりはないので、漏れてる観点は多いと思います

データカタログがなぜ必要か

大まかには3つくらいの観点がありそう。

DWHやデータマートの利用者観点(アナリスト / データサイエンティスト / bizdev):

  • DWHやデータマートに多数散らばっている中で自分に有用そうなテーブルを探したい
    • テーブル名をexactに覚え切れているわけではない、曖昧検索したい
      • テーブル名以外からも検索したい、カラム名やdescriptionにもヒントがあるはず
      • BigQueryの画面だと、テーブル名のexactな検索か部分一致しかできないし、ソート順も指定できない

DWHやデータマートの作成者観点(データエンジニア / アナリティクスエンジニア):

  • 利用者からの問い合わせコストを減らしたい
    • 都度回答していると時間が足りないし、スケールしない
  • help your own
    • 作成者とはいえ、DWHやデータマートの全てのテーブルの仕様を把握するのは現実的には困難
    • SQLの定義を辿るのが一番正確ではあるが、ショットカートできるようにしたい
  • 関連チームとのインターフェイスを揃える
    • 「ここを見てください(to ユーザーサイド)」「ここに書いてください(to データソースサイド)」と言える場所を一元的に管理したい
    • 複数あると覚え切れないし、管理コストも増える

データソースの提供者観点(アプリケーションエンジニア / SRE):

  • 自分が提供しているデータが誰に使われているかの把握
    • 提供しているデータの種類も多いし、自分が認知していなかったけどいつの間にか社内で使われていた、ということはよくある
  • 問い合わせコストを減らしたい
    • DWH作っている人からの問い合わせもあるし、データ利用者から問い合わせがくるときもある

Dataplexのデータカタログが提供してくれる機能

検索

データカタログのある意味一番大切な機能はやはりここ。

  • 多彩な検索方法
    • 組織内にGCPのプロジェクトが多数ある場合、プロジェクトを横断して検索できるのは便利
    • データセットを探したいのか、テーブルを探したいのかといった粒度も指定できる
      • UDFやマテビューに絞る、というのもボタンポチポチで検索できる
    • 検索語に対する関連度合いや最終更新日などソート方法も指定できる
    • お気に入り(スター)に入れた対象のみの指定もできる
  • 検索対象の範囲の広さ
    • BigQueryのテーブルだけでなく、GCSやBigTableやpubsubなどもサポートされている
    • GCPを使っていると、自然とDataplexが自然とクロールしてくれるので手間がかからない
      • 手間があったとしてもCatalogのAPIを有効化する、くらいでよい
    • 自前で登録すればAWSなどGCP外のリソースを対象に含めることも可能
  • IAMとの連携
    • 「このデータは誰に見せてよいか」はIAMと連携されるので、管理コストが減らせる

メタデータ管理

検索に負けず劣らず、データカタログに求められていること。

参照できる情報:

  • テーブルのdescriptionや最終更新日など、BigQuery上で見れる情報も当然ある
  • データリネージ
    • dbtやdataformを使っていると、うれしさがそこまでないようにも思うかもしれないが、そんなことはない
      • 組織内ではdbtやdataform以外でリソースを作成する場合も多い
        • 例: 開発ではdigdag、bizdevではGASで定期的にテーブル作成
    • dbtやdataformを使っていようが使っていまいが、データリネージを一元的に確認できるというのはめっちゃありがたい
      • 毎度INFORMATION_SCHEMAのreferenced_tablesを使ったクエリを書く必要がない
      • INFORMATION_SCHEMAのことを知らない人にも案内しやすい
      • dbtやdataformが不要になる、という話ではもちろんない
    • リネージだけでなく、そのテーブルを作ったときのDDLも表示できる
      • 「このカラム、めっちゃNULLばっかり入ってるけど、どういうロジックで作られてるんだ...」を確認する術にできる
    • リネージにはBigQueryのテーブル以外にもGCSなども対象に含まれている
      • bq loadでロードしたようなものでも勝手にリネージ対象に入れてくれる
      • 「テーブルは削除したけど、GCSに元データが残ったままになってたね...」というような事態にも気付ける
  • 直近30日でのクエリされた回数
    • テーブルを廃棄したいときなどにさっと確認できて便利
      • 「誰が見てたか」などは流石に分からないので、INFORMATION_SCHEMAを引きましょう

管理できる情報:

  • ラベルやテーブルのdescriptionなどBigQuery上で管理できるものも当然ある
    • BigQueryのtable descriptionとは別にdataplex上にはOverviewというのがある
      • こちらはwysiwygでリッチに情報を定義することが可能なようだ
      • Overviewではリッチな情報を記載できる
  • タグ(テンプレート)
    • BigQueryのデータセットやテーブルにラベルを振ることはできる
      • ラベルはBigQueryに限らず、GCPのリソースで割と幅広く使える
        • 例えばBigQueryのjobにラベルを付与することもできる
    • 一方でラベルはあまり高度なことができるわけではない
      • 単純なkey-valueしか持たせることができず、例えばdatetimeを指定できなったり、enumで特定の種類しか選択できない、といったことはできない
    • タグテンプレートではより柔軟に指定できる
    • 便利な一方、「どこで管理するのか」は現状よい解がなさそう...
      • ラベルであればdbtに情報を付与して、BigQueryに反映させることができる
      • 一方で、タグテンプレートはAPIやsdkはあるものの、テーブル管理で使うdbtやdataformとの連携は現状まだ十分とは言えず、自前で別途管理する必要がある
  • Business terms

Dataplexでのデータカタログのメリット / デメリット / 要望

メリット

  • 何といってもマネージドで手間がかからない
    • APIを有効にしておけばある程度よしなにやってくれる
  • 料金が安い
    • データカタログのSaaSを導入しようと思うと、それなりのお金がかかる
    • それと比べると、データカタログはかなり導入が容易
  • セキュリティ観点
    • データカタログのSaaSを使う場合は、メタデータ相当の権限をGCP外に渡す必要が出てくることが多い
    • データ自体の閲覧権限ではないが、外部に情報を出すことにはなるので、ハードルとしては多少高くはなる
    • データの分布(min / max / distinct countなど)の簡易的な分析をしてくれるものも存在し、その場合はデータ自体の閲覧権限を渡す必要がある

デメリット

OpenMetadataやSaaSとしてデータカタログを提供しているもの(例: DataHub)と比較した場合を考えます。

とはいえ、データカタログ単体のプロダクトは組織によってはtoo muchな機能であったり、OSSにしても運用が回るかといった課題はあるので、Dataplexによるデータカタログで十分、というケースもかなりあるのではないかと思います。

Dataplexでのデータカタログに対する要望

  • BigQueryとの連携をさらに強化して欲しい(マジで切実)
    • Dataplex側でリッチなメタデータの情報を付与した場合、BigQuery側にもそれが見えるように連携して欲しい
      • 例えばタグテンプレートとかビジネス用語集はdataplex上でしか見えない
    • 特にビジネスユーザーがデータを触るときの起点はBigQueryであることが多く、せっかく情報を付与しても活用し切れないわけなので、めちゃくちゃ歯痒いです
    • BigQuery側からDataplex上のカタログへのリンクが追加される、などでもよい
  • カラム列のdescriptionで検索がヒットした場合に、検索結果でも確認できるようにして欲しい
    • 一度、テーブル側を確認しに行かないといけないので手間が多い
  • terraformなどの連携の強化
    • タグテンプレートやビジネス用語集などはIaCとして定義を管理したいことも多いですが、terraformでサポートされていないケースも多いです
    • 自前でやるのは運用コストがかかるため、terraformなどで使いやすくなるといいなと思っています
    • Webの画面からが中心となるユースケースにおいては、変更履歴や誰が変更したか、などが分かるようになっていて欲しい
      • ドキュメント管理のシステムでは当たり前に必要になる機能
  • システムでサポートされる情報のリッチ化
    • 特にシステムメタデータ。「このテーブルを一番叩いている / 最後に叩いた人は誰か」などはINFORMATION_SCHEMAから出して付与すればできるが、dataplex側でやって欲しい
      • 現場が同じようなことをやっていて無駄が多い

参考