こんにちは！
IT統制グループの中島です。
メタデータ管理に関わるブログ第二弾になります。第一弾の記事はこちらをご参照ください。
以前と組織は変わっていますが、引き続きメタデータ管理にも携わっています。
第一弾の記事で、「メタデータ管理を流行らせたい」と書いたので、 今回は弊社のメタデータ管理の仕組みをお伝えしようと思います。 これからメタデータ管理を始められる方の参考になると幸いです。
ちなみに弊社のメタデータ管理システムは「MetaBo」と言います。
Meta Bibliography（メタ書誌情報）を略してMetaBoと名付けられました。
MetaBoの全体概要
MetaBoは、社内に散在するデータに関する情報（メタデータ）を一元管理し、横断的に検索する仕組みです。
収集したメタデータをキーワード検索することで、スキーマ・テーブル・カラム・インデックスなどに辿り着けるWebアプリケーションとなっています。
以下は更新を含めたMetaBo全体のシステムイメージ図です。
上記イメージの青色で囲まれているエリアは、リポジトリ内の情報をブラウザから検索したり更新することが可能なWebアプリケーションです。
- メタデータの参照 （青色エリアの右上）
メタデータの論理情報の更新は、ブラウザから直接編集するか、Excelを介したテーブル定義書のアウトプットやインプットで可能です。
- メタデータ論理情報の手動更新 （青色エリアの右下）
その他に、橙色と黄色のエリアがスクラッチ部分で、大きくメタデータの取得処理（橙色）とリポジトリの更新処理（黄色）に分かれています。Bash、Python、APIを使って各種DataStoreからCSVを取得し、リポジトリに反映しています。
- メタデータ物理情報の自動取得（橙色のエリア）
- メタデータ物理情報の自動更新（黄色のエリア）
上記にある物理・論理情報とは、DataStoreから機械的に取得可能な情報を物理情報とし、 それ以外のメタデータを修飾するための任意の情報を論理情報として扱っています。
例）
- 物理情報
テーブル物理名、カラム物理名、型桁 など
- 論理情報
テーブル論理名、カラム論理名、意味 など
前回ブログでも少し触れましたメタデータレベルを少し掘り下げて定義した表が以下になります。
今回のブログでは、物理情報であるメタデータレベル１及び論理情報のメタデータレベル２〜３の更新方法について主に説明していきます。
メタデータの自動更新：物理情報更新編
MetaBoではリポジトリ上の物理情報を自動的に更新しています。
冒頭と説明が重複しますが、取得と更新処理に分かれています。
取得処理では、DataStoreのリストを取得し、ディクショナリかリポジトリからSQLで情報を取得しています。セキュリティの関係で実データを直接参照できないDataStoreはAPI経由で取得しています。 以下サンプルですが、メタデータ取得時に使用しているOracle、MySQLのディクショナリ系のテーブルです。
oracle
テーブル・カラム情報
dba_tab_columns、dba_tables、dba_objects、dba_tab_comments、dba_col_comments
テーブル・インデックスの情報
dba_indexes、dba_ind_columns、dba_constraints、 dba_tables
FKの情報
dba_constraints、dba_cons_columns、dba_cons_columns、dba_tables
MySQL(information_schema)
テーブル・カラムの情報
tables、columns
テーブル・インデックスの情報
STATISTICS、KEY_COLUMN_USAGE、TABLE_CONSTRAINTS
テーブル・カラム情報は、スキーマ・テーブル・カラムの大福帳（非正規化）データとして取得しています。
テーブル・インデックス情報も同様にスキーマ・テーブル・インデックス・カラムの大福帳データです。
MetaBoのリポジトリの中は、スキーマ・テーブル・カラムなどのオブジェクト別にテーブルが分割されているので、 更新処理時にIDを採番しながら正規化を行い、前日データと差分があれば履歴データとして登録を行っています。
上記処理は日次で実行され、すべての処理が成功すると新しいデータと古いデータが置き換わります。 仮に処理に失敗した場合は、実行前の古いデータが維持されSlackに結果が通知されます。
その他通知機能として、リポジトリ内の情報が更新された場合は、スキーマ別に更新結果のサマリーをSlackの特定のチャンネルに通知するようにしています。この機能によって開発者や分析者が注視したいスキーマがあった場合、変更を検知することが可能となっています。
メタデータの更新：論理情報更新編
メタデータの論理情報については、下記２つの方法があります。
- ブラウザから更新
- Excelのテーブル定義書をアップロード
論理情報の更新については、メタデータ管理者による手動更新が基本となっています。 また一部ですが、上流のスキーマと下流のスキーマの組み合わせをマスター管理し、テーブル名やカラム名が一致していた場合、論理情報を自動更新する機能を作り込んでいます。
現状の課題
更新するための仕組みは整ってきていますが、運用上はまだ課題を抱えています。 一例としては、論理情報の鮮度維持と精度向上です。
論理情報の鮮度
メタデータ管理をする上で、論理情報の鮮度維持は難しい課題の一つです。 主な要因は、手動によるメンテナンスが必須となる点です。 普通のテーブル定義書の管理でも、テーブル定義書が最新化されていないという課題はよくあることだと思います。
この課題には大きく、下記３つの対策が必要となります。
- テーブル定義書の管理をMetaBoに集約
- 論理情報を自動的に更新
- ガバナンスを強化
しかし、どの対策も単独で解決するには、難しいものです。
１．テーブル定義書の管理をMetaBoに集約
MetaBoは多機能ではないため、テーブル定義の管理機能にフォーカスすると既存で使われている管理方法に比べて劣る面があります。
更新についても若干手間がかかるため、習得時や管理方法の移行時に学習コストがかかり、結果としてMetaBoにテーブル定義の管理を移行できない管理者（開発チーム）がいます。
そのため、Metaboを更新する開発チームの傾向として、以下のような状況が発生しています。
- テーブル定義書の管理をMetaBoで実施する開発チーム
- テーブル定義の本体をMetaBoと別で管理し、そのコピーをMetaBoに反映する開発チーム
前者のチームは比較的最新化されていますが、後者のチームはテーブル定義を二重管理しているような状況もあり、陳腐化している情報が目立っています。
２．論理情報を自動的に更新
自動更新可能な対象は例えば以下のような物があります。
- 上流のテーブル定義変更による下流のテーブル定義への反映
- 頻繁に行われる組織変更に伴うテーブル管理者の更新
ただし、自動更新を行うためには、大本の情報が必須となります。またデータソースが多数あると自動更新の仕組み作りが複雑化します。効果が高い自動更新を整備することで、局所的な課題は解決しますが、作り込みも多く発生してしまいます。
３．ガバナンスを強化
更新のルールを定めることは、情報の鮮度を維持するために必要な手段となります。しかし、開発者の数やチームが多いほど難易度が高く、無理を強いるガバナンスは、管理自体の崩壊を招く危険があります。
論理情報鮮度対策のまとめ
本課題を解決するには、各対策をバランス良く推し進め、緩やかにガバナンスが効いている状態を作り出していくことが重要です。
具体的には、自動更新する仕組みを充実させ、可能な限り人の手を介在しない仕組みに変えて行く必要があります。また現状のテーブル管理手法にない機能を追加し、MetaBo自体の魅力を向上させることで、自発的にテーブル定義の管理を移行する土壌を作り、開発者がMetaBoを使うメリットを増やすことが重要だと考えています。
論理情報の精度
MetaBoに集められた論理情報は、基本的に開発者が管理するために必要な情報となっています。 そのため分析者目線で必要な情報が必ずしも存在していない場合があります。
この課題を解決するには、データ分析者と開発者の業務をもっと近づける必要があると考えています。
データを分析することで開発者が担当するプロダクト・サービスがより成長し、
開発者の行動と分析者の行動が繋がることでより分析に必要な情報が集まり、良い循環が生まれるはずです。
つまり開発者にとって、データ分析をより自分事にすることが重要だと考えています。
ここは意識の改革やデータドリブンの文化醸成などが必要なため、少しずつ変えていく必要がありそうです。
もちろんこれが出来ているプロダクトもあるので、部分的にルールを作るのではなく全体が最適化されるようなテーブル定義書のルール作りも重要になっていきます。
まとめ
メタデータ管理の仕組みをお伝えすると今回のブログは始めましたが、まだ課題は多く理想とするメタデータ管理としては遠い状況です。
当初はメタデータを全部集めて全部最新状態を維持し隅々まで現状のデータ状況について可視化すると息巻いていました。 しかし、いざプロジェクトを進めてみると、多数のメタデータの鮮度と精度維持に厳しい状況が続いております。そのため現実問題と照らし合わせ、全てをキメ細かく管理するのではなく、「何のためにメタデータ管理をするのか」、「どういったメタデータが重要で最低限維持しなければならないのか」といった基準が重要だと今は考えています。
メタデータ管理の目的と重要度の高いメタデータ
弊社ですと「データ利活用の促進」のためにメタデータ管理をしているので、会社視点で物事を考える必要があります。そのため一例を挙げると、重要プロダクトや経営層や分析者が着目するKGI/KPIのようなデータは重要度が高いメタデータに分類することが出来ます。
重要度の決め方
メタデータの「重要度の決め方」自体もなかなか難しい課題です。弊社における重要度の高いメタデータはまだ細かく定義出来ていませんが、定性的に決めた重要度をより言語化していき、何故重要なのかを定義する必要があります。
重要度の評価
また別軸では、定性的に決めた重要度を定量的に評価するための仕組みが出来ないかも検証しています。 例えば、最近着目したものはスキーマを参照するユーザの権限です。重要度が高いデータほど、参照するユーザ数が多いのではと仮設を立て、スキーマ別の参照数ランキングを作成しました。その結果の中に、分析時に重要視するプロダクトが上位に含まれていたため、参照度の高いデータほど重要になる可能性が高いと評価出来そうです。ただこれもたまたまそうなった可能性があるため、いくつかの仮設と検証を組み合わせながらスコアリングしていく必要がありそうです。定性的な基準が細かく決まらなくても、こういった仮設・検証を繰り返すことで、ゆくゆくはメタデータの重要度に関わる情報を自動的に収集・スコアリングしていき、重要度の判定にまで繋がるのではないかと考えています。
最後に
今回は、仕組みと一部の課題の共有でしたが、進むたびに課題が産まれ解決を模索して来ました。他社の仕組みや課題についても興味があるので、様々なところで課題解決の議論や情報発信されるきっかけになれば嬉しく思います。 また今後も目的にあったツールとしての機能を高め、関係者に貢献出来れば幸いです。
