企業内に大規模なデータ基盤を構築する際には、いくつかの基本要素を押さえておく必要があります。
本稿では、分散型のデータ基盤を構成する上で欠かせない要素を順に整理していきます。
各分散ノードに存在する RDS(読み取り専用データストア)が基本
データ基盤の出発点となるのは、各分散ノードに配置される RDS(読み取り専用データストア)です。
データを取得するまでに人的コストや時間的コストがかかってしまうような業務システムは、データソースを業務システム本体から切り離す必要があります。そのために、各システムごとに RDS を用意します。
データの利用者は、業務システムがあらかじめ決めたパブリックなデータであれば、RDS にアクセスしてデータを取得します。
RDS の実体は、Azure Files であったり、共有フォルダであったり、あるいは DB のレプリカであったりとさまざまです。ただし、システムごとに異なるインフラ・テクノロジ・アーキテクチャが乱立してしまうと、後々の運用や統合が困難になります。そのため、なるべく同じインフラ・テクノロジ・アーキテクチャを用いるようガバナンスを敷くことが重要です。

また、データ基盤を主導する IT 部門が、各システムが共通して利用できる RDS データレイクを提供するケースもあります。

なお、RDS の代わりとして、読み取り用 API、DB/リポジトリへの直接アクセス、データストリームといった方式が採用される場合もあります。
データ目録 (データカタログ)
分散した RDS を活用するためには、データ目録の整備が欠かせません。
ここで言う「目録」とは、データの所在や取得方法など、データに関する情報(メタデータ)をまとめたものを指します。データ基盤で重要なのは、データそのものではなく、データの所在情報を集める点にあります。
大掛かりなデータカタログ製品の導入は、後回しにして構いません。基盤構築の最初期にこうした製品を選定しようとすると、まず間違いなく選定に迷います。迷うだけであればまだしも、グランドデザインの段階で誤った方向に進んでしまうと、後から軌道修正することが非常に困難になります。
データカタログは、将来的なオートメーションの基盤にもなり得るものです。したがって、基礎構築のフェーズと、拡張・展開のフェーズを分けて考え、データカタログ製品の導入については拡張フェーズの中で議論することが望ましいと言えます。
| 実現したいこと | テーブル一覧を公開 テーブル/データ仕様公開 リネージ情報公開 メトリクス公開 | データの細かい仕様、使い方共有 | オートメーション メタ属性に寄る検索 統一的なセマンティック実現 メタデータ計画 |
| 必要なソリューション | Excel ファイル 共有フォルダ Web ページ | 社内コミュニティ | カタログシステム |

データ管理ポリシーの「その1」
データ管理ポリシーの詳細は後述しますが、ここでは基本となる考え方だけ頭出ししておきます。
各業務システム、および各データ発行者に対しては、以下の情報を明示するようルールを定めます。
• データの所有者、データレイアウト、算出方法などの情報(メトリック)
• 問い合わせ先
• 発行日と更新日
• 固有コードに対する標準項目とのマッピング
また、各データ基盤に対しては、上記の各業務システムに課すルールに加えて、以下を用意するようなルールを定めます。
• データカタログ
• コピー元情報

コミュニティ
データの使い方やデータの仕様に関する問い合わせは、ヘルプデスクや IT 部門だけでは十分に対応しきれません。これは、データ活用を進める上で常につきまとうジレンマと言えます。
こうした問題に対応するためには、データを利用するユーザー同士が知見を共有し合えるコミュニティの存在が必要です。
ベースレジストリ
データの中には、局所的な範囲で意味が統一されていればよいドメインデータと、エンタープライズ全体で厳密に統制されるべきデータとが存在します。エンタープライズ全体に適用されるデータを配置するためには、ベースレジストリが必要です。
ベースレジストリは、統制元のみが更新可能であり、エンタープライズ全体からは読み取り専用のデータとして扱われます。



コメント