背景・目的
私は、現在データエンジニアリングを生業としています。普段は、データ基盤の構築やパフォーマンスチューニングなどに従事しています。ビックデータの収集や、蓄積、分析などの環境構築の経験はそこそこありますが、データマネジメントについては、それほど経験がありません。
そのため、データマネジメントの知識やスキルを獲得するために、DAMAのCDMP（Certified Data Management Professional）試験の学習を通して学ぼうと思います。
CDMPは、DMBOK2（Data Management Body of Knowledge version2）から、14のトピック（11の知識領域、データ管理プロセス、倫理、ビッグデータ）で出題されるようです。
参考
Data Management Process – 2%
Big Data – 2%
Data Architecture – 6%
Document and Content Management – 6%
Data Ethics – 2%
Data Governance – 11%
Data Integration and Interoperability – 6%
Master and Reference Data Management – 10%
Data Modelling and Design – 11%
Data Quality – 11%
Data Security – 6%
Data Storage and Operations – 6%
Data Warehousing and Business Intelligence – 10%
Metadata Management – 11%
DMBOK本では、章立てとして17章に分けられています。
本ページでは「第12章.メタデータ管理」について整理します。
まとめ
- メタデータの品質により、効果的なデータ活用にもつながるし、機会損失にもつながる。
- メタデータの品質を保つためには、戦略立案、設計、導入、ガバナンスといった一連のプロセスが重要。
概要
イントロ
メタデータには、以下が含まれる。
- ITプロセス
- 業務プロセス
- データのルールと制約
- 論理的、物理的なデータ構造
メタデータに記述する内容は以下のとおりです。これにより、組織がデータ、システム、ワークフローを理解するために役立ちます。
- データ自体
- データが象徴する概念
- 例）業務プロセス、アプリケーションシステム、ソースコード、IT基盤
- データと概念の関係性
ビジネス上の意義
信頼性が高く管理されたメタデータにより、以下が可能になります。
- データのコンテキストを提供、データ品質の測定を可能にしてデータへの信頼を向上させる
- 戦略的な情報を多様な用途に利用できるようにし、その価値を高める
- 冗長なデータとプロセスを特定し、業務効率を向上させる。
- 古いデータや間違ったデータの利用を防止
- データを活用した調査に要する時間を短縮
- データ利用者とIT専門家との間のコミュニケーションを改善する
- システム開発ライフサイクルを短縮し、製品の市場投入を早める
- データのコンテキスト、履歴、発生元を全て記録することで、トレーニングコストを削減しスタッフの影響を軽減する
- 法規制遵守を支援する
メタデータは、組織を機能させているデータとプロセスを説明するものであり、データガバナンスにとって不可欠である。
メタデータが適切に管理されなければ、以下の状況が発生する。
- 冗長なデータと冗長なデータ管理プロセス
- ディクショナリ、リポジトリなどのメタデータ保管が複製されることによる冗長性
- データエレメントに関する一貫性のないデータ定義と誤った利用によるリスク
- メタデータのソースやバージョンに矛盾や対立が生じることによる利用者の信用低下
- メタデータとデータの信頼性に対する疑念
ゴールと原則
メタデータ管理は、以下を目指す。
- 人々が一貫性を持ってデータコンテンツを理解しデータを利用するためデータ関連業務用語に関して組織が持つ知識を記録し管理する
- 様々なデータソースからメタデータを収集して統合し、異なる部門で生成されるデータ間の類似点や相違点を理解する
- メタデータの品質、一貫性、最新性、セキュリティを確保する
- メタデータ利用者に対して、メタデータを利用するための標準的な方法を提供する
- データ交換を可能にするメタデータ技術標準の利用方法を確立または強化する
本質的な概念
メタデータとデータ
メタデータもデータと同じように管理する必要があるが、一般的な課題としてメタデータとデータの境界線に迷うケースが有る。
哲学的判別するのではなく、メタデータの要件を定義する事が必要とのことです。
メタデータの種類
メタデータは、以下に大別できる。
- ビジネスメタデータ
- テクニカルメタデータ
- オペレーショナルメタデータ
ただし、これらのカテゴリに囚われすぎると混乱する危険があり、
そのため、メタデータをどのように利用するかの視点からではなく、どこで発生するかのカテゴリで考えるとよい。と記述がありました。
メタデータの種類ごとの例
| ビジネス | テクニカル | オペレーショナル | |
|---|---|---|---|
| 概要 | 主にデータの内容と状態に重点を置きデータガンバナンスに必要な詳細を含みます。 概念、対象領域、エンティティ、属性なに関する名称と定義が含まれ、この名称はITから独立している。 |
データの技術的詳細、データを格納するシステム、およびシステム内やシステム間でテクニカルメタデータを移動するプロセスに関する情報を提供します。 | データ処理とアクセスの詳細を記載します。 |
| 具体例 | ・データセット、テーブル、カラムの定義と説明 ・業務ルール、変換ルール、計算方法、及び導出方法 ・データモデル ・データ品質の規制と測定結果 ・データ更新されるスケジュール ・データの出所とデータリネージ ・データ標準 ・データエレメントが依存するマスターレコードシステムの指定 ・有効値成約 ・ステークホルダーの連絡先情報（データオーナーや、データスチュワード等） ・データのセキュリティ/プライバシーレベル ・データに関する基地の問題 ・データ利用上の注意 |
・物理データベーステーブルとカラムの名称 ・カラムのプロパティ ・データベースオブジェクトのプロパティ ・アクセス権 ・データCRUD ・テーブル名、キー、インデックスなどを含む物理データモデル ・ETLジョブの詳細 ・ファイルフォーマットのスキーマ定義 ・ソースからターゲットへのマッピングを示すドキュメント ・上流と下流への変更影響を含むデータリネージを記述するドキュメント ・プログラムとアプリケーションの名称と説明 ・コンテンツ更新サイクルのジョブスケジュールと依存関係 ・リカバリーとバックアップのルール ・グループ別、役割別データのアクセス権 |
・バッチプログラムのジョブ実行ログ ・データの抽出とその結果などの履歴 ・運用スケジュールの異常 ・エラーログ ・レポートとクエリのアクセスパターン、頻度、実行時間 ・パッチとバージョン管理の計画と実行 ・バックアップ、保存、実行日付、災害復旧などの規定 ・SLA要件と規定 ・容量の増減と利用パターン ・データのアーカイブと保持ルール、関連するアーカイブ ・廃棄基準 ・データ共有ルールや合意事項 ・IT側の役割と責任、連絡先 |
非構造データのメタデータ
メタデータは構造化データ以上に非構造化データにとっては重要です。
HadoopなどのビックデータPFではデータを取り込んだ後に、アクセスできるようにそれをカタログ化している。
多くの場合は取り込みと同時にカタログ化するプロセスを実装している。
メタデータのソース
メタデータは最終成果物ではなく、アプリケーション処理の副産物として作成されることが多く、ほとんどの組織では管理するレベルで作成されていない。
既存のものを受け入れメンテナンスするよりも、意図的に新しく定義したほうが良い。
メタデータアーキテクチャの種類
メタデータには、他のデータと同様にライフサイクルが存在します。概念的には全てのメタデータ管理ソリューションはメタデータのライフサイクルの段階ごとにアーキテクチャ層が設けられている。
ライフサイクルは、以下のとおりです。
- メタデータの作成と入手
- 一つまたは複数のリポジトリを使ったメタデータの保管
- メタデータの統合
- メタデータの配信
- メタデータの利用
- メタデータの統制と管理
メタデータアーキテクチャの種類
メタデータを入手し、保存し、統合し、維持し、利用者がアクセスするためには以下のようなアーキテクチャアプローチが利用できる。
| メタデータアーキテクチャ | 特徴 | 機能 | 利点 | 欠点 | |
|---|---|---|---|---|---|
| 集中型 | 単一のメタデータリポジトリで構成。 限られたITリソースしか持たない組織や 可能な限り自動化を目指す組織は避ける傾向 メタデータリポジトリを共有し、高い整合性を求める組織は恩恵を受けやすい。 |
・メタデータのインポート ・検索ポータル機能 ・クエリ機能 |
・ソースシステムと独立しているため可用性が高い ・リポジトリとクエリが一緒に存在するため、迅速なメタデータ検索が可能。 ・DB構造が分離されているので、3rdPartyや商用システムの独自仕様から影響を受けない。 ・抽出されたメタデータをソースシステムに存在しない場合付加的メタデータを利用して変換・カスタマイズ・拡張することで、品質を向上できる場合がある。 |
・ソースの変更を取り込むための複雑なプロセスが必要 ・集中型リポジトリのメンテナンスコスト ・抽出に特別仕様のモジュールやMWが必要な場合あり ・カスタマイズされたプログラムの検証とメンテナンスにより、ITスタッフとSWベンダーの負担が増大する可能性あり |
|
| 分散型 | 分散されたアーキでも、単一のアクセスポイントが維持される。 検索エンジンはリアルタイムでソースシステムから取得するため保存機能があるリポジトリは存在しない。 |
・必要なソースシステムへの索引情報を保持 クエリ機能 |
・ソースから取得するため、常に最新かつ有効 ・クエリが分散されるため、レスポンスが改善される可能性あり ・独自データ構造の詳細な理解が不要(メンテナンスコストの省力化) ・自動化されたメタデータクエリ処理の開発がより簡単になり、手動介入を最小限にできる ・メタデータのレプリケーションや同期処理が不要なためバッチ処理が削減 |
・データを追加配置できるリポジトリがないため、ユーザ定義や手動で追加されたメタデータ項目をサポートできない（カスタマイズ性がない） ・様々なデータから取得するため標準化が必要 ・クエリ機能は関係するシステムの可用性により直接影響を受ける。 ・メタデータの品質は関係するソースシステムに依存する。 横断検索ができない |
|
| ハイブリッド型 | 集中型と分散型の特性を兼ね備える。 (独自項目を追加できる集中型と、直接ソースから取得する分散型の特徴を兼ね備えている。) |
・ポータル機能 ・クエリ機能 ・拡張されたメタデータストア |
・オペレーターの介在を減らす。 ・最新かつ有効なメタデータにアクセス |
・システムの可用性は向上しない ・中央リポジトリの拡張されたメタデータと、ソースのメタデータをリンクするため余計なオーバヘッドが発生するためレスポンスに影響がでる。 |
|
| 双方向型 | メタデータは、その構成の任意の部分で変更でき、変更後にリポジトリkら元のソースに連携して反映される。 |
TBD | TBD | リポジトリに最新が反映されており、リポジトリを変更した場合にはソースシステムに強制的に変更する。 そのため変更を体系的に管理し、リポジトリとメタデータソースを結びつけるため、一連のプロセスインターフェイスを追加して構築し、維持する必要がある。 |
アクティビティ
メタデータ戦略の策定
組織がどのようにメタデータを管理しようとしているのか、現状から将来あるべき姿にどのように移行するか示す。
メタデータ要件を定義することで、戦略の推進要因を明確にでき、潜在的障害を特定できる。
戦略策定のための導入ステップは以下の通りです。
- メタデータ戦略の計画づくりを始動
- 主要なステークホルダーへのインタビューを実施
- 既存のメタデータソースとインフォメーションアーキテクチャを評価
- 将来のメタデータアーキテクチャを開発
- 段階的導入計画を立てる
メタデータ要件の把握
コンテンツの検討から始める。必要なメタデータは何か、どのようなレベルのものか。業務とIT両方のデータ利用者から要件が出る。
また、以下のような包括的なメタデータソリューションが持つ機能に関わる多くの要件がある。
| 機能 | 要件 |
|---|---|
| 変動性 | メタデータの属性などが更新される頻度 |
| 同期 | ソースの変更に関して更新されるタイミング |
| 履歴 | メタデータの履歴バージョンを保持する必要があるか |
| アクセス権限 | アクセスに使われる特定のUI機能とともに、誰がメタデータにアクセスでき、どのようにアクセスできるか |
| 構造 | 保管する際に、どのようなメタデータがモデル化されるか |
| 統合 | 様々なソースから収集されるメタデータの統合度合い、統合のルール |
| メンテナンス | メタデータを更新するプロセスとルール |
| 管理 | メタデータを管理するための役割と責任 |
| 品質 | メタデータの品質要件 |
| セキュリティ | 高度に保護されたデータの存在を明らかにされるため、一部のメタデータは公開しないなど |
メタデータアーキテクチャの定義
メタデータ管理システムは、多くのソースからメタデータを抽出できること、様々なメタデータソースをスキャンし、定期的にリポジトリを更新できるようにアーキを設計する。
メタデータのマニュアル更新、検索、参照をサポートする必要がある。
管理されたメタデータ環境は、多種多様なメタデータソースからエンドユーザを分離する。
（単一のアクセスポイントを提供することで、透過的にメタデータリソースにアクセスさせる）
そのために、次に示す設計のステップを踏んでいく。
- メタモデルの作成
- メタデータ標準の適用
- メタデータストアの管理
メタモデルの作成
- メタモデル＝メタデータリポジトリのデータモデルを指す。
- メタモデルは、以下の2つに大別される
- システム間の関係を示すハイレベル概念モデル
- モデルの要素とプロセスを記述するために属性の詳細を記述する下位レベルのメタモデル
メタデータ標準の適用
メタデータソリューションはメタデータ戦略で特定された、合意済みの以下の標準を守る必要がある。
- 内部標準
- 命名規則
- 独自定義属性
- セキュリティ
- 可視性
- 処理に関するドキュメント
- 外部標準
- データ交換の形式
- API設計
ガバナンス活動により、メタデータがそれらの標準を守っているか（遵守しているか）を監視する。
メタデータストアの管理
メタデータ環境を管理するためには、統制アクティビティを導入する。
リポジトリの統制は、以下を統制する意味を持ち、メタデータの専門家により実行される。
- メタデータの移動
- リポジトリの更新
統制アクティビティには、以下のものを含んでおり、データガバナンスの監督が必要である。
- ジョブのスケジューリングと監視
- 負荷統計分析
- バックアップ、リカバリー、アーカイブ、パージ
- 設定の変更
- パフォーマンスチューニング
- クエリ統計分析
- クエリとレポートの生成
- セキュリティ管理
品質管理アクティビティには、以下のようなものがある。
- 品質保証、品質管理
- データ更新の頻度（突き抜けないように時間内に収める）
- 欠落しているメタデータのレポート
- 失効したメタデータのレポート
メタデータ管理アクティビティには、以下のようなものがある。
- 資産のロード、スキャン、インポート、タグ付け
- ソースのマッピングと移動
- バージョン管理
- ユーザインターフェース管理
- データセットのリンクメタデータ保守
- 内部データ取得へのデータのリンク
- 外部データソースと供給ライセンス取得
- データ拡張メタデータ
訓練にはいかが含まれます。
- ユーザとデータスチュワードの教育
- 管理指標の生成と分析
- コントロール活動とクエリとレポートに関する訓練
メタデータの作成と維持
メタデータは組織のあらゆるところで生成され、格納される。高い品質を保つためにはメタデータを製品のように管理する。
良質なメタデータは、偶然生み出されず、計画的な管理が必要です。
メタデータの品質を管理する手段を以下に記載します。
- 責任
- 既存のプロセスを通じてメタデータが生成されることが多い。それを認識して業務プロセスのオーナーがメタデータの品質に責任を持つ
- 標準
- メタデータの標準を設定し、実施、監査、統合しやすくし、利用できるようにする
- 改善
- フィードバックの仕組みを作る。利用者が間違ったメタデータや最新ではないメタデータをメタデー管理チームに知らせるようにする。
メタデータの統合
統合プロセスは、外部から取得したデータのメタデータを含む、企業全体のメタデータを収集して整理し統合するものです。
統合では、様々な課題が生じるためガバナンスが必要です。
メタデータの配賦と配信
アプリケーションやツールなどに配信します。配信の仕組みは以下のとおりです。
- ブラウザ、検索、クエリ、レポート、分析のためのメタデータ・イントラネットウェブサイト
- レポート、用語集などのドキュメント
- DWH、データマート、BIツール
- モデリングとソフトウェア開発ツール
- メッセージングとトランザクション
- ウェブサービスとAPI
- 外部組織とのインタフェースソリューション
導入ガイドライン
組織へのリスクを最小限に抑えて、容易に受け入れてもらえるように管理されたメタデータ環境を段階的に導入することを推奨する。
初期段階では、オープンなRDBMSプラットフォームをでメタデータリポジトリを実装する。
リポジトリのコンテンツでは、以下の点を留意する必要がある。
- 汎用性を意識する（単純にソースシステムのコンテンツを反映しない）
- 企業内で該当する対象領域の専門家と連携し、包括的なメタデータモデルに基づいてコンテンツを設計する。
- データ利用者が様々なデータソースを見ることができるように、計画段階からメタデータの統合を考慮する。
- リポジトリは、メタデータの現行バージョン、計画バージョン、履歴バージョンを格納すべきである。
考察
メタデータの基本が多少整理されたが、実装までイメージができてない。
メタデータ管理のためのツールには、一般的にはどのようなものが使用されているか曖昧なので今後整理したいと思う。
参考