【イベントレポ】2024/11/28 データカタログ 事例から学ぶメタデータ管理の実態
どれくらいの企業が使えるデータカタログを持っていると自信を持って言えるのでしょうか？データ利活用が活発な企業であればあるほど、データカタログの整備は追いついていなかったりするかもしれません。今回はどんな時データカタログがあってよかったと思えるのか、どう作ればいいのかについてまとめられたらと思います。
概要
データの活用が求められる昨今、合わせてデータカタログ構築によるメタデータ管理の重要度も高まっています。
本イベントでは、ご登壇者の皆様より実際にデータカタログを導入、整備された事例、データの信頼性や活用性を高めるための取り組みについてご共有いただきます。参加者の皆様が、自社での活用法やデータカタログの有用性やノウハウのヒントを得ることができるイベントを目指します。
Streamlitで開発した自作データカタログの導入
登壇者
山口 歩夢 (@Yamaguchi_aaaaa)
株式会社GENDA
データエンジニア
2023年にGENDAにデータエンジニアとして入社。
データ基盤の構築や運用、Streamlitでのデータ可視化アプリケーションやデータカタログの開発に携わる。
すみません、参加が遅れたため、メモをとれませんでした。
ただ、Streamlitで作成した後データカタログの有用性や欲しい機能が明確になりOpenMetadataの採用に至ったとのことでした。
ヤプリのデータカタログ整備1年間の歩み
登壇者
山本 雄太(@Y4M4MOTO)
株式会社ヤプリ
開発統括本部 プロダクト開発本部 データサイエンス室
2023年新卒入社。dbt導入によるデータ基盤刷新に従事し、dbtの開発体制やリリースフロー構築などを担当。現在はdbt docsを用いたデータカタログ拡充やデータ基盤メンテナンスのためのドキュメント整備に取り組んでいる。
自己紹介
Yappliはノーコードアプリ開発製品
dbt導入と並行したdbt docs 整備
目的はDS室メンバのために、データの仕様をまとめていく場所を作るため。
やったことは下記
はやいうちからGitHubPagesへ自動デプロイする仕組み
複数人でのdbt開発がスタートした時点でdocsを利用した。
導入時からdocsを使い始めていたが、役に立った。なぜならリネージグラフは見れた。また、拡充すればもっと使える社内ドキュメントにあったDB仕様書をdbt docsへ転記
テーブルからむの情報を埋まった状態にできる。
他チームのドキュメントだったが、越境して取りに行けた
Yappliでは毎月YappdateDayという改善に注力する日があり、そこで転記できたdbt-osmosis導入
カラム説明を継承できる。上流のdbtモデルの説明を下流dbtモデルへ継承させられるのでdocsの拡充率を30%→80%まで拡充で来た
データカタログは下流の改廃が多めなので、上流（ソース側）から埋めていくのが効率的。
トラッキング仕様書の移行&更新体制構築
閲覧ログ、操作ログを取得してデータ基盤やGA4に送信している。トラッキング仕様書とは、各イベントでどのようなログを送信するかをまとめたもの。
課題と対策は下記
分析用データ基盤送信と計測サービス送信で仕様管理が二重管理
スプレッドシートを1枚にマージした
コンフリクトした際はコメントを残して、重要度を追記した
DS室がトラッキング仕様の策定に関われていなかったため、PdMも分析側も疲弊
仕様策定、実装、リリースからDS室が関われるようにした
データカタログを自作したけど 運用しなかった話
登壇者
すずき (@suzupappa)
株式会社HR Force
DS統括部DXグループDataチーム マネージャー
新卒でHR Forceに入社後、セールスに従事。その後はセールス経験を活かし、Salesforce管理者として営業活動の効率化と組織成長に向けたデータ整備・利活用を推進したのち、Salesforce外に存在するデータも含めた活用を推進するため、モダンデータスタックのデータ基盤の導入を主導。現在はデータ基盤の運用、データ活用の推進、顧客へのデータ提供を行う。
はじめに
データカタログを自作したが運用しなかった。
そもそも、ビジネス側の人がSnowflakeにどんなデータがあるか知りたいから一覧表が欲しいとのことでデータカタログを作成した。
概要
データカタログは、Snowflakeからメタデータをnotionに吐き出し。更新時にSlackに自動で送信するといったもの。
制作にかかった時間は2-3時間。
システム構成の理由は、Notionに情報を集約しようという動きがあったため。というのも、ビジネスの人がnotionをよく利用するため。また、NotionでDB機能や階層構造も作れる点、コストもかからない点。
しかし、徐々に衰退していった。
問題点
勢いで始めてしまった点が問題。
例えば,,,
ユーザーを明確にしていなかった点
カタログのオーナーをビジネス側にしなかったためbotみたいになってしまった点
カタログに記載するテーブルやカラムのスコープを定めなかった点
利用者にとっての最適なUI・UXを考慮していなかった。
一番重要なのは利用ユーザーを明確にしていなかった点。
役割とデータの詳しさの関係
セールス、マーケ、データアナリスト、データエンジニアの順でデータに詳しくなっていく。
最初欲しいといった人はまぁまぁ使う人、しかし実際にデータカタログの利用者はたまに使う属性の人。
よく使う人は1回見れば覚えていられる。1週間に1回見るか見ないかの人は覚えていられない。
また、たまに使う人は全てのカラムの情報は見ない。
自分が関係ないテーブルまであると、探せない。
まとめ
データカタログは社内向けのプロダクト。そのため、誰に届けるのか、どうやって届けるのかを考え抜くべし。
現場からスモールに始めるデータカタログ
登壇者
谷口 槙吾 (@pronto_20240601)
株式会社インテージ
MLエンジニア/データエンジニア
新卒入社後、データサイエンティストとして様々なデータ分析案件に従事。現在は分析基盤上のデータマート作成や機械学習/生成AIを用いた分析を中心に行う。
現状とモチベーション
データ分析は前処理8割と言われている。そのため、きれいなデータマートを作って管理することは重要。データサイエンティストはデータエンジニアリングの知見を使えばもっとより良くできるのではないかと考えた
現状と課題
バージョン違い
ドキュメントでデータのメタデータ管理をしていた。しかし、分析結果などとバージョン違いが発生してしまっていた。個々人の心構えの問題になってしまうので仕組みで解決したい。
データに関する情報取得にコストが掛かる
真に知りたい情報は誰かに聞いたりする。誰に聞けばいいのか分からない。
導入ハードル
カタログはNice to have
カタログが無くても業務は回せるが、その程度の物は権力者がいないと基本コケる
高機能な商用カタログサービスは高い
年間数100万円かかるのは、費用対効果を見積もる必要がある。ただ関係者が多いため難しい。セキュリティなども。
検証
マルチにデータソースがあり、そこから分析マートを作成し分析を行うという課題設定で複数技術を検証した。
結果、Snowflake中心でデータカタログを組むのがよさそう。
理由として下記
スキーマ、テーブル、カラムにコメントを付けられる
COMMENT ONステートメントでDBからカラムまでコメントを付けられる。ドキュメントがある場合はリンクを貼れる。ミニマルに始められる。
テーブルについては、WebUI上からコメント編集できる
SQLクエリを解析して自動でリネージを作ってくれる
リネージはWebUI上から閲覧できる。
Pythonからもdataframe形式でリネージを取得できる。
参照数の多いテーブルや特定テーブルをよく参照されている人が分かるので注力するものが分かる。
クエリ結果をダッシュボード形式にして他ユーザーに公開できる
マッチしなかったもの
OpenMetaData
何でもできるがゆえに運用カロリーが高くなる。例えば、自由にリネージを定義できるので実態と乖離が出たり、大量のリネージが表示されてしまった
dbt
分析を行う人のスキルセットの幅が広いので、普及させるのが難しそう。
総括
Snowflakeの機能を使えば十分効果が見込める
基盤維持側で欲しい要件は異なるため、両社のニーズを満たすメタデータ管理の構成は目指したい。
まとめ
データ基盤の構築時に最初からデータカタログについて真剣に作っていくのは難しいかもしれません。というのも利用者の想定がそもそもあいまいであったり、、なくても業務が回せるため優先度が落ちてしまったり。一方で、データカタログに入力する情報はテーブルのコメントや仕様書に残しておくことは最初から必要だと思います。特にデータソースに近い場所は、再利用できることからも優先的に残していくのが良さそうです。