このポストについて

DMBOK2 を読み進めていくシリーズ。
今回は第8章「データ統合と相互運用性」について。
業務で扱っているデータ基盤はデータ統合が不完全であるため、なんとかしたいと考えている。

以降、特に注釈のない引用は DMBOK2 第8章からの引用とする。

データストレージと相互運用性とは

データ統合と相互運用性 (DII: Data Integration and Interoperability) は次のように定義されている。

アプリケーションや組織内および相互間におけるデータの移動と統合を管理する

データの移動を効率的に管理することがそのビジネス上の意義となる。
ほとんどの組織には数多くのデータストアがあり、組織内・組織間でデータを移動させることは IT 組織の重要な任務となっている。
複雑さとそれに伴うコストを管理するために、全社的な視点からデータ統合を設計しなければならない。
データウェアハウスなどのデータハブによりアプリケーション間のインターフェースの数を削減することができる。

DII のゴールは以下

  1. 法令を遵守しながら、必要とするフォーマットと時間枠でデータを安全に提供する。
  2. 共有のモデルとインターフェースを開発することでソリューションを管理するコストと複雑さを軽減する。
  3. 重要なイベントを特定し、アラートとアクションを自動的に起動する。
  4. ビジネスインテリジェンス、アナリティクス、マスターデータ管理、業務効率化の取り組みをサポートする。

概念・用語など

抽出、変換、取込

DII の中心にあるのが、抽出 (Extract)、変換 (Transform)、取込 (Load) のいわゆる ETL という基本プロセス。

  • 抽出
    • ソースから必要なデータを選択し、抽出する
    • 抽出されたデータはディスク上やメモリ上にステージングされる
    • 業務システムで実行される場合は、少ないリソースを利用するように設計する
  • 変換
    • ソースデータを変換してターゲットデータストアの構造と互換性を持つようにする
    • フォーマット変更、構造の変更、意味的変換、重複排除、並べ替えなどがある
  • 取込
    • ターゲットシステムに物理的に格納されるか、提供される
  • ELT
    • ターゲットシステムにより多くの変化機能がある場合は、プロセスの順序を ELT にすることができる
    • データレイクへの取込を行うビッグデータ環境では一般的

レイテンシ

ソースシステムでデータが生成されてから、ターゲットシステムでそのデータが利用可能になるまでの時間差。
アプローチによってレイテンシの高低が異なる。

  • バッチ
    • 利用者や自動的な要求に応えて、定期的にアプリケーションや組織間を一定量まとまって移動させる
    • レイテンシは高いが大量データを処理するときのパフォーマンスがいい
    • 低レイテンシを実現するためのマイクロバッチもある
  • 変更データキャプチャ
    • データの変更 (挿入・変更・削除) のデータセットを監視し、その差分をターゲットのシステムに渡す
    • DBMS のアクティビティログをコピーし、処理する形で行われることもある
  • 準リアルタイムとイベント駆動
    • 設定された予定により1日を通して分割された少量のデータセットで処理されたり、データ更新などのイベントが発生したときに処理されたりする
    • 一般的にエンタープライズ・サービス・バスを利用して実装される
  • 非同期
    • データ提供側は受信側の更新確認を待たずに処理を続行する
  • リアルタイム、同期
    • 次のトランザクションを実行する前に、他のアプリケーションからの確認を受け取るまで実行プロセスが待機する
    • 非同期と比べて状態管理の負担が少ないが、他のトランザクションをブロックしたり遅延させたりすることもある
  • 低レイテンシまたはストリーミング
    • イベントが発生したときにシステムからリアルタイムで連続して流れる

リプリケーション

分析やクエリによるパフォーマンス低下を防ぐために、トランザクション処理環境にリプリケーション (複製) を使用することがある。
多くの DBMS にはリプリケーションを作るためのユーティリティ機能がある。

アーカイブ

利用頻度が低いデータは、よりコストがかからない代替データ構造やストレージに移行できる。
アーカイブ技術が変わっても古いデータにアクセスできるようにしておくことが重要。

エンタープライズ・メッセージフォーマット／カノニカルモデル

組織やグループでデータを共有するための標準化されたフォーマット、共通モデルがカノニカルモデル。
組織内で合意するのは大仕事だが、データ相互運用性の複雑さとサポートコストが大幅に削減される。

データ連携モデル

データ転送のためのシステム間を接続する方法。

  • ポイント・ツー・ポイント
    • データを共有するシステム間で互いに直接データを渡す
    • 多数のシステムが同じソースから同じデータを必要とする場合は効率が下がる
  • ハブ＆スポーク
    • 多くのアプリケーションが利用できる中央データハブへ共有データを集約
    • データウェアハウス、データマート、オペレーショナル・データストア、マスターデータ管理のハブなどがその例
    • ソースシステムへのリソースへの影響やインターフェース構築のコストを最小にできる
  • パブリッシュ・サブスクライブ
    • データを提供するシステムはデータサービスのカタログにリストされ、データを利用するシステムはそれらのサービスをサブスクライブする

DII アーキテクチャの概念

  • アプリケーションカップリング
    • 2つのシステムが関連し合っている結合度合い
    • サービス、API、メッセージキューなどの技法を用いて疎結合にするのが望ましい
  • オーケストレーションとプロセスコントロール
    • オーケストレーションとは復数のプロセスがシステム内でどのように構成され、実行されるかを説明するために使われる
    • プロセスコントロールはデータの発信、配信、取込が正確かつ完全であることを保証するために必要な要素
      • バッチジョブのログ
      • アラート
      • ジョブ依存チャート
      • etc.
  • エンタープライズアプリケーション統合
    • ソフトウェアモジュールは明確に定義されたインタフェース呼び出し (API) だけを介して連携するというモデル
  • エンタープライズ・サービスバス
    • システム間の仲介役として機能し、システム間でメッセージをやり取りするシステム
    • 疎結合の例ではアプリケーション間のサービスとして機能する
  • サービス指向アーキテクチャ (SOA)
    • アプリケーション間で明確に定義されたサービス呼び出しを利用することでデータを提供したり、データを更新したりする
    • SOA によりアプリケーションの独立性が担保され、システムの置き換えが容易になる
    • データについてのサービスはサービスカタログ上で定義される
  • 複合イベント処理 (CEP)
    • 復数のソースから得られるデータを結合して重要なイベントを識別すること
    • 振る舞いや行動を予測し、リアルタイム応答を自動的に起動できるようになる
  • データフェデレーションと仮想化
    • データフェデレーションでは構造に関係なく、個々のデータストアの組み合わせにアクセスできる
    • 仮想化では復数の異種データストアを単一のデータベースとしてアクセスできる
  • Data as a Service
    • SaaS (Software as a Service) と同様の概念
    • DaaS ではベンダーがライセンスを提供し、必要に応じてデータを提供する
  • クラウドベースの統合
    • データ、プロセス、SOA、アプリケーション統合などのユースケースに対応する、クラウドサービスとして提供されるシステム統合の一形態
    • SaaS の登場により、クラウドベースの統合を経て、組織が持つデータセンターの外にあるデータを統合するための新しい種類の需要が生まれた

データ交換標準

データエレメントの構造に関する正式なルール。
ISO により制定されている。
システム間で交換書式やデータレイアウトを合意すれば、起業のデータ相互運用性を大幅に簡素化し、運用コストを下げることができる。

所感

概ね業務などを通じて知っている内容だった。
データ統合は難しい。

Apache Flink には CEP の機能があるけど、よく使われているのだろうか？