【CIH】データのスパゲティ化を回避せよ!データ統合ハブ「Informatica Cloud Integration Hub」の概要を改めて理解する

CIHでデータの集配信を実現しつつ、データ連携を疎結合化してデータのスパゲティを脱しよう
2023.10.02

こんにちは、データアナリティクス事業本部ビジネスソリューション部SAチームの渡部です。
今回はインフォマティカ製品のデータ統合ハブ「Cloud Integration Hub(以下、CIH)」を触ってみたので、機能概要のご紹介をしようと思います。

本ブログ作成経緯

以下の経緯でCIHを触ってみることにしました。

  • CIH導入の問い合わせをお客様からいただいたため
  • データマネジメントを学んでいる際に「データハブ」が頻出するので、インフォマティカのデータハブを実際に触って理解をしたかったため

今回CIHブログ第一弾として、どんなことができるかの概要について書いていこうと思います。

CIHについて

CIHは日本語で「統合ハブ」と呼ばれ、その機能はシステム同士のデータ連携をハブを介すことによってシステム間を疎結合にするデータの配信・集信をわけて非同期にすることにあります。
データマネジメントの文脈では、「データハブ」であったり「データ連携ハブ」と呼ばれているものを、インフォマティカがサービスとして提供したものがCIHとなります。

特にデータマネジメントでよく言われるのは、データハブを導入することによってハブ&スポークモデルを実現し、データ連携のスパゲティ化を解消できるということです。

上図がデータのスパゲティ化の図となります(左)。
もしもシステム同士を直連携(P2P連携)すると、システム数をnとした時に、n * (n-1) / 2の連携数が生じてしまいます。
システム数が増えるごとに、連携数が増えてしまい管理が非常に煩雑となる恐れがあります。
そのため、データハブであるCIHを使用して図(右)のように連携数を減らすのが効果的であるということです。

例えば、上図の赤塗りつぶし部分、業務システムの1つについて新たな競争優位性のあるシステムに置き換えを検討しているとします。
この場合、P2P連携の場合は連携数の分だけ改修の影響がありますが、データハブを導入している場合はデータハブへの配信1インターフェースの改修で基本的に済むということで、ビジネススピードが落ちません。

CIHのアーキテクチャ

次にCIHのアーキテクチャについてご紹介します。
インフォマティカ公式サイトに掲載されている図を引用します。

参照:Cloud Integration Hub architecture(2023/09/25引用)

アーキテクチャのコンポーネントについて、以下で解説します。

Clients

Webクライアントのこと。
ユーザーインターフェースを通してCIHコンポーネントであるパブリケーションやサブスクリプションの設定・イベントの監視が可能です。

Informatica Intelligent Cloud Services Hosting Services

Clientsで設定された、CIHの処理であったりデータ/メタデータを格納する場所のこと。
パブリケーションリポジトリ(Publication repository)には、パブリッシュされたデータがサブスクライブされるまで一定期間保持する役割があります。
またパブリケーションリポジトリは、Informatica Cloudが管理するホステッドリポジトリを利用するか、組織管理のサーバ上に用意したプライベートリポジトリを利用することが可能です。

ホステッドリポジトリの特徴は以下の通りです。

プライベートリポジトリを利用する場合は、DBはOracleまたはSQL Server、MySQLが選択できます(後述しますが、トピックテーブルへのリレーショナル連携の場合)。
なお、DBについてはSecure Agentと同じサーバにを配置することがパフォーマンス的には推奨です。
リポジトリへのファイル連携も可能ですが、この場合はSecure Agentがオンプレミスにないと使用できないそうです。

Informatica Intelligent Cloud Services

実際の実行環境のこと。
CIHの設定やデータ/メタデータをリポジトリから取得して、実際の処理を行います。

Data sources and targets

データ統合ハブにデータをパブリッシュ/サブスクライブする手段のこと。
図としてはDB・ファイル・アプリケーション接続というようになっていますが、意味合い的には連携手段について記載されているものと認識しました。
手段としては以下の3つがあります。

  • Cloud Data Integration(以下、CDI)
  • Mass Ingestion Files
  • API連携

やってみた

それでは実際に触っていきます!

1. トピック

トピックとは、パブリケーションリポジトリに定義される、パブリケーションが配信するデータを格納するデータ構造のことです。
トピック内に、トピックテーブルを複数作成して、パブリケーションはそのテーブルにデータを配信し、サブスクリプションはそのテーブルからデータを集信します。

そのトピックの定義方法については3種類あると思い、図にまとめてみました。

左のSource Model連携がソース定義そのままの連携、
真ん中のTarget Model連携がターゲット定義に合わせてソースデータを加工した連携、
右のDomain Model連携がビジネスドメインなどの単位で定義したデータモデルに合わせて連携する方法です。

それぞれのメリット・デメリットは以下の通りです。  

Model メリット デメリット 備考
Source ・生データをデータハブに配置可能で、ターゲット側のことを考えなくてよい
・ターゲットシステムの変更時に、配信側連携の改修が必要ない
・とりあえずなんでも連携するとデータハブにデータスワンプが発生する可能性がある
Target ・従来のP2P連携と同じように連携可能 ・データハブは導入しているが、実質のデータ連携数はP2P連携時と変わらない
・ターゲットシステムの変更時に、配信連携だけでなく集信連携も改修しなければならない
Domain ・ドメイン単位の理想的なデータ分散管理が可能 ・データモデル作成がドメインやシステムに精通している必要があり、難易度が高い ・改修時の工数はデータモデル設計次第

今回は簡単のために、一番左のSource Model連携で検証しようと思います。

以下がトピックの設定画面です。

主な設定をご紹介します。

パブリケーションリポジトリタイプ

「リレーショナル」「ファイルストア」が選択可能です。
リレーショナルは、Informatica Cloud上のホステッド、もしくは組織のパブリッククラウドorオンプレミス上のプライベートDBで管理可能です。
ファイルストアは、リポジトリがオンプレミス上にある場合に使用可能で、ファイルそのままの集配信が可能です。

コンシュームされるデータの保持期間

トピックにサブスクライバーが全てデータを受信したあとのデータ保持期間が設定可能です。
今回は7にして、7日間保持するように設定しました。

トピック構造

パブリケーションリポジトリのトピックにトピックテーブルを定義します。
定義方法は、以下の4種類があります。

  • テーブル読み込み
  • フラットファイル読み込み
  • 作成したメタデータファイルの読み込み
  • 手動

今回はフラットファイルからメタデータを読み込み、手動でデータ型を設定しました。

トピックの設定はこれで完了です。

2. アプリケーション

続いてアプリケーションの作成をします。
こちらはアプリケーション名以外の設定は不要です。
アプリケーションは、パブリケーションやサブスクリプションの集信元や配信先をひとまとめにする構造体です。

アプリケーションの作成単位は名前の通り、まずはアプリ単位でいいと思いました。
(アプリケーションに対して一つのソース接続のみでなければならないというわけではありません)

今回はs3とbigqueryの2つのアプリケーションを作成しました。

3. パブリケーション

パブリケーションではデータ配信に使用する連携タスクを定義します。

選択できる連携はトピックのパブリケーションリポジトリタイプで変わり、
リレーショナルではCDIの「マッピングタスク」と「同期タスク」を、
ファイルストアではMass Ingestionの「マスインジェスチョンタスク」を使用することができます。

今回はリレーショナルを選択したので、まず初めにCDIで「マッピングタスク」を作成していきます。
作成時の注意点として、ターゲットでCIHを指定する場合は、マッピングはパラメータ化してマッピングタスクでCIHを指定する必要があります。
パラメータ化しないマッピングでは、実行時にエラーとなってしまいます。

上述の通り、マッピングタスクでターゲットの接続とオブジェクト、フィールドマッピングを設定します。  

続いて、CIHに戻りパブリケーションを作成します。

パブリケーションの主な設定をご紹介します。

モード

パブリケーションの有効/無効化が可能です。
無効になれば配信しないようになります。
APIで有効/無効が設定できるので、用途としては、配信の異常終了時に連携を止めることに使えそうです。

スケジューリング

パブリケーションの実行トリガーを選択できます。
手動orAPI起動、もしくはスケジュール起動が設定可能です。

これで、パブリケーションの設定は完了です。

4. サブスクリプション

パブリケーションと同じく、先にマッピングタスクを作成します。
マッピング上のソース接続とオブジェクトも同様にパラメータ化して、マッピングタスクで設定をします。

続けてサブスクリプションを作成します。

サブスクリプションの主な設定をご紹介します。

オプションのトピック

ソースとして、トピックを複数指定したい場合に使用します。
結合などの処理に使用できるかと思います。

再試行ポリシー

集信が失敗した場合に自動的に設定した間隔でリカバリを実施してくれます。
接続エラーで失敗した場合に有効かと思いました。

これで、サブスクリプションの設定は完了です。

5. 実行

一連の設定が完了しました。
CIHのハブ概要では、Cloud Data Governance and Catalog(CDGC)のデータリネージュとまではいかないにしろ、どこからどこへデータが流れているかがわかるようになります。

連携を動かしてみます。
パブリケーションを手動で実行すると、パブリケーションデータがトピックに格納されたのちサブスクリプションまで自動的に実行されました。
これはサブスクリプションの起動トリガーを「パブリッシュ済みデータの準備ができている場合」にしているためです。

またトピックには自動的にDIH__PUBLICATION_INSTANCE_DATEDIH__PUBLICATION_INSTANCE_IDの2つの項目が付与されています。
そのためターゲットにこれらの項目を連携すれば、パブリケーションの日時とパブリケーションIDの情報を保持することが可能です。

以下が、ターゲットテーブルのデータです。

salesid listid sellerid buyerid eventid dateid qtysold pricepaid commission saletime DIH__PUBLICATION_INSTANCE_DATE DIH__PUBLICATION_INSTANCE_ID
1 1 36861 21191 7872 1875 4 728 109.2 2008-02-18 02:36:48.000000 UTC 2023-10-02 13:50:02.000000 UTC 245993374
2 4 8117 11498 4337 1983 2 76 11.4 2008-06-06 05:00:16.000000 UTC 2023-10-02 13:50:02.000000 UTC 245993374

まとめ

以上!
今回はCIHを触ってみました。

トピックやパブリケーション・サブスクリプションの設計が考えどころではありますが、データハブとしての疎結合化が非常に魅力的だと思いました。
今後もCIHを触っていって、次なる魅力を発見しようと思います。

ありがとうございました!