みなさん、データのメタデータ管理ってどうやってますか？ #datatech-jp レポート

datatech-jpのイベントで、メタデータ管理についてのイベントが開催されました。

開催される経緯見てましたが、たしか@kuwa_twさんからの呼びかけで、登壇者が集まり、視聴者もぞろぞろ集まって700人以上が登録されるようなイベントになってました。

みんなメタデータに興味あるんだなぁ。メタデータ管理って実際の事例が外に出ていないので気持ちはわかる。

松元さんと吉田さんはメタデータの知見が1歩も2歩も先行っているなと感じました。

データマネジメント セミナーレポート

その他データマネジメント関連のセミナーに興味ある人はこちらから。

メタデータ関連の記事を過去書いていたのでメタデータってなに？という人はこちらを参照ください。

「メタデータ・マネジメント入門」

発表者

Quollio 松元さん

発表資料

※こちらは２年前の資料のほう

概要

Quollioの事業紹介

国産のデータカタログツールでおなじみのQuollioの松元さんがトップバッターです。

松元さんはメタデータの記事を書いているので参考になる。メタデータ管理の最先端をいきすぎている人。

メタデータの価値と意義

データ基盤作ってもメタデータがないと必要なデータを発見するのは難しい。
テーブルの物理名とデータの中身だけでは想像はできるけど、意外とわからない。

また、データ自体の意味以外にも制約条件とか利用者情報などがあり、そういうメタデータを整備することでデータ活用ができる。

メタデータの種類

• システム基礎系：DDLとか

• ビジネス系：活用方法

• 関連性：リネージやER図

• 統制系：品質情報

• セキュリティ情報：アクセス権限情報

• システム運用系：ジョブ実行ログ

• ソーシャル系：利用者のレビューやアクセス頻度

メタデータの管理とデータカタログ

メタデータを管理するためのツールとしてはデータカタログがある。

データカタログは銀の弾丸だと思われがちで、いいデータカタログがあればだれもが使ってデータ利活用が進むと思われがちだが…

実際データカタログを入れたところで、メタデータは入力されずカタログ・ゴーストタウン現象が起きることが多い。

正しく管理されるためには運用業務体制と組織間連携が必要。
全て人手ではなくて、システムでできるところはシステムで自動化して手動対応が必要なところは手動で整備していく必要がある。

感想

カタログ・ゴーストタウン現象をクリアするためには2つ障壁があると思っていて、まずはデータカタログにメタデータを入力していくという所。
ここは近々の利用者及びデータ生成元は手元にメタデータメモを持っていてデータカタログに入力するインセンティブがないので全然入力してくれない。

ここをクリアしたら万事解決かというとそうではなくて、ツール入れたけど使われないという点で、先ほど書いたように利用者は手元にメタデータメモを持っていて困っていないので利用されない。

じゃあ、データカタログっていらないんじゃない？って事かというとそうではなくて、手元のメモは集合知になりえないのと、横断的に活用するときにナレッジトランスファーができないのでデータカタログを使ったメタデータ管理は必要なんだよなと思っている。

質疑

Q.国産のデータカタログという事で、日本市場を意識した点はどのあたりでしょうか？

A.ビジネスメタデータの入力をどうするかという所で、海外製品では共同入力を前提としたものになっているが、国内では共同入力はワークしないのでワークフローとして実装できるようにした。
アメリカというよりヨーロッパのカルチャーと近いと思うので、そういう所を意識して製品を作っている。

エンプラ企業でやりたいメタデータ管理～データエンジニア編～

発表者

Sakatokuさん

発表資料

（なさそう）

概要

エンプラ企業の状況

組織が大きくて、縦割り・横割りな状況であり、そうなるとデータライフサイクルを一気通貫で見れる人がいない。

そうなってくるとDWH担当はデータアナリストの唯一の相談相手で、データに関するあらゆる相談が来る。

「知らんがな」といいつつ、データ生成元に確認して解決していくが、都度都度質問のバケツリレーが発生しており、つらい状況。

メタデータの管理で解決に動いてみた

データリネージとメタデータを管理すれば見通し良くなるんじゃねと思って試してみた。

OpenMetadataを使ってみた。コネクタも準備されていてメジャーなDWHとの連携もできて便利。
コネクタが無いExcelみたいなデータソースの事もよくあるので、一回DWHに入れて連携というのもあるが、メタデータを引き継ぐためにカスタムコネクタを使って対応したらうまくいった。

OpenMetadataをつかって管理したら、データアナリストの要望も叶えられて、データエンジニアもバケツリレーが減って両者happyな解決策ができた。

今後の展望

まだまだ入口なので、見るべきメタデータはたくさんあることは理解しているので、必要なメタデータを特定してメタデータの管理をすることで業務を楽にしていこうと思ってます。

感想

OpenMetadataはデータカタログの選定対象の一つなので、良さそうって話が聞けて良かった。

と言っても業務の問題でツールの問題じゃなさそうなので、今回の課題を解決するツールとしては何でも良さそうなので、導入の容易性が重要なのかなと思った。無料とかね。

質疑

Q.OpenMetadataって使われますかね？

A.OpenMetadataは使いやすい感触があるので、事例として増えてくるという感覚値はある。

StreamlitとTerraformでデータカタログを作った話

発表者

GENDA ヤマグチさん

発表資料

概要

データカタログを自作した話

データカタログが無くて、メタデータが管理されておらず、カタログ型のソフトウェアも高額だったため自作しました。

• スキーマのテーブル一覧

• カラム情報：Snowflakeのコメントを拾ってきてます

• データプレビュー

結果データアナリストに評判の良いデータカタログができました。

運用における課題と解決策

使われるデータカタログを作れたのは良かったが運用面の課題が出てきた。

• Snowflakeのコメントの更新が大変。

• データエンジニア以外の人が編集できない

• 更新履歴が残らない

Terraformを使って管理することで上記課題を解決できた。

• メタデータの最新情報をGitHubで管理を一元化できるようになった

• データカタログの更新方法が確立した

• ユーザーからの更新依頼に対してスムーズに対応することができるようになった

感想

昔コンフルでデータカタログを作ったことを思い出した。結局データ利用者が使いたいメタデータを集約できればツールは何でもいいってことなんだろうなと。

Terraformを使って業務フローが作れるくらいにITに強い会社であれば高いかね払ってデータカタログツール入れなくてもよくねという事例かなと。

Terraformで管理することでウェブエンジニアの人がテーブル変更するときもデータカタログの更新をしてくれるようになったとおっしゃっていたが、データカタログが使いやすくて更新することに意味があると思ってもらっているというのが前提としてあって、そこがすごいなと思った。

質疑

Q.作るのどれくらいかかったのですか？
A.データカタログを作ったのは2カ月くらい、Terraformは1カ月くらいです。

Q.大変だったのは？
A.Streamlitが簡単に作れるので、楽しくできた。

Databricksでやろう、メタデータ管理！

発表者

Databricks 阿部さん

発表資料

概要

メタデータの基礎

メタデータはデータの活用のためには不可欠なもの。大きく分けで３つに分類される。

• ビジネスメタデータ：人による入力が必要

• テクニカルメタデータ：システムから収集可能

• オペレーショナルメタデータ：システムから収集可能

※詳細なメタデータの種類についてはDMBOKを参考に下さい。

ポイントは全ての組織は全てのメタデータを整備する必要はない。組織の状況に応じて取捨選択する必要がある。

メタデータ管理の課題と解決

ビジネスメタデータはデータ生成元から連携されないこともあれば、データカタログに入力されないことも多く大変。

テクニカルメタデータもドキュメント管理がされておらず古い。

オペレーショナルメタデータもジョブ実行履歴とかを取得することはできても、どのデータにアクセスしているかが中を見ないとわからない。

そういう状況なので、システムから収集可能なテクニカルメタデータやオペレーショナルメタデータなど自動化できるものは自動化することが大事。

ビジネスメタデータについては、銀の弾丸はないので体制構築と入力の容易性を担保することが大事。

最後に管理されたメタデータへのアクセスを容易にすることも使われるために重要な要素。

Databricks（Unity Catalog）で何ができるか

Unity CatalogはDatabricks内のメタデータだけではなくて、外部クラウドのメタデータの管理もできる。

先ほど述べたようにテクニカルメタデータやオペレーショナルメタデータの管理が自動的にできて、便利だよ。

GUIも整っているので、メタデータの管理のためのツールの候補になりそうだよ。

感想

まあ、そうだなぁと思った内容でした。

質疑

Q.Unity Catalogのメタ情報はどこに格納されるのでしょうか？
A.Databricksに格納されます。

データマネジメントを支える武器としてのメタデータ管理

発表者

10X Yoshidaさん

発表資料

概要

吉田さんと10Xの紹介

吉田さんメタデータ大好きなので、メタデータおかずにご飯3杯いけるらしい（笑）
10Xはスーパーマーケットに向けたソリューションを提供している会社。

※詳しくはスライドを参照してください

事業とデータ活用の関係性

マーケティングから店舗運営まで事業を回すためにはデータ利活用が重要になってくる。

DMBOKによるとフェイズ3に位置づけられている。10Xでデータマネジメント成熟度アセスメントをやったところフェイズ2に位置づけられた。

そのくだりはこのスライドにて。

データの管理状況

パートナー横断DWHからパートナーごとのDWHを作っていったが、そのことによってデータの意味とデータを使う場所が分かれてしまった。

データカタログを使った話はこちらにて。

どうやってメタデータをメンテしていくか

手動でビジネスメタデータを記入していったとすると、データレイク層のデータを変えた時に、後続のDWH層、データマート層に書くとしたらめっちゃ更新しなくなっちゃって現実的ではない。

dbtを使って、メタデータをリレーする仕組みを作ったことで上記課題を解決していった。

メタデータ管理はそれ自体が目的じゃなくて、目的達成のための強力な武器である。

メタデータを使った品質改善

データ品質に関する問い合わせはよく受けるが、そもそもの状態がわからないと調査コストが高くなりがち。

データ品質の指標の定義がチームによって違うことが課題になってきたので、会社として統一した指標の定義が必要になった。
品質の指標を統一のために、elementaryというツールを使った。

dbtの実行後にメタデータをjsonで出力してくれて、elementaryはdbtのメタデータを解き明かしたうえで、DWHに格納してくれる。

データセットごとに同じ品質基準でテストを回して結果を可視化することができるようになった。

DWHとデータマートと、どのレイヤでどのテストを行うべきかをメタデータを使って見直すことができるようになった。

テーブルの撤退をするときのメタデータ活用例

テーブルの撤退をするために参照回数を調べてみた。

以下のような依存関係があるとして参照回数を見るとこんな感じだった。
テーブルA（2回）→テーブルB（50回）→テーブルC（100回）

参照の絶対数だけを見ると2回となっており、あたりを付けてみた所、実は後続のテーブルがめちゃめちゃ使われていたため、全然撤退できないテーブルだった。

テーブルの撤退をするためには累積参照回数が実は大事
テーブルA（152回）→テーブルB（150回）→テーブルC（100回）

累積参照回数をメタデータとして持っておくと、それを基に安全にテーブルの撤退ができる。
メタデータとして累積参照回数を取得したら撤退に便利だよという事例の紹介。

アクティブメタデータ

強制されることなく、自分からメタデータを取って活用するものらしい。
気になる人は松元さんの記事を読んでみよう。

• 拾いだす

• 創り出す

• 送り出す

今回やったことはアクティブメタデータなのではという事に気が付いて、吉田さんはハッとしたらしい。

• 拾いだす：システムからの自動収集

• 創り出す：dbt-osmosisを使ったメタデータの連携

• 送り出す：テーブルの撤退

感想

使われるデータカタログを作ればDescriptionが入力されるようになったという事かなと思って、一方Descriptionが無いデータカタログは使われないので、鶏と卵問題ではあるが順番気にせずやることが大事だなと。

累積参照回数という概念とか、それを収集してテーブルの撤退を楽にしたとかこういう事を思いつけるのがすごいなと。さすがメタデータのプロ。

吉田さんのメタデータ愛を感じました（笑）

質疑

Q.ビジネス部門の人がメタデータを見る状況とは？
A.ビジネス部門の人もクエリを書きます。パートナーさんにアドバイスするための裏付けとしてデータを見せるために使っている。

メタデータ管理の解説動画

メタデータ管理のゆっくり解説動画を作ったので、こちらもよろしくお願いします。

データマネジメントを学ぶ人が抑えておきたい本

今すぐわかるデータマネジメントの進め方
著者のDMBOKを用いてCDO室を立ち上げデータマネジメントを推進した経験を基にデータマネジメントの進め方をまとめたkindle本を執筆しました。

データ組織立ち上げ編 ＡＩ事務員宮西さん
著者のデータ組織の立ち上げ経験をマンガ＋コメントでまとめてみました。立ち上げ編は組織を立ち上げてやることが決まるまでのストーリーです。
無料公開のため0円となります。
データ組織の立ち上げに関係する方は是非読んでみてください。

DXを成功に導くデータマネジメント
DXを成し遂げるために必要なデータをどうマネジメントしていけばよいかが書かれている。
データ環境より、セキュリティの観点であったり、プライバシーの観点であったりといった非技術者向けの内容が多く書かれている。
データマネージメントに興味を持った人はまずは読んでみるとデータマネジメントでなすべき概要が理解できる。

実践的データ基盤への処方箋
データ利活用を行うために必要なデータ基盤の考え方と、利活用するためにはデータをどのようにマネジメントしていけば良いかを具体的な例を用いて説明されている。
技術が中心になるので現在データ技術に係る人がデータマネージメントに興味を持った時には、まず手に取ることをおすすめする。

個人データ戦略活用 ステップでわかる改正個人情報保護法実務ガイドブック
個人情報保護法を順守するための基本的な考え方が実務ベースで書かれている。2022年4月に施工される改正個人情報保護法で新たに追加される概念も同様に記載されている。
政府の出しているガイドラインよりも俯瞰的に読めるためデータプライバシーにかかわる人、データを使ったビジネスを推進する人は読んでおくとスムーズに業務が進められる。

データマネジメント知識体系ガイド（DMBOK）
自分も要約・解説記事を書いているDMBOK。データマネジメントに興味を持った人がまず手に取ると挫折することは間違いないほどのボリュームがある。
読めば読むほど味が出てくるので、データマネジメントを進めようとしている人は各家庭に1冊は是非買っておきたい。

データマネジメントが30分でわかる本
著者もDMBOKを読むためには非常にボリュームが多く読み解くには苦労するので、かみ砕いた解説書をまとめたと書いてある通り、DMBOKを独自解釈してわかりやすく書かれている。
DMBOKを技術者目線で読み解いた内容になっているので、実践的データ基盤への処方箋と同様データ技術に係る人におすすめする。