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

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

本ブログ作成経緯

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

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

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

CIHについて

CIHは日本語で「統合ハブ」と呼ばれ、「データハブ」であったり「データ連携ハブ」と呼ばれているハブを介した連携を実現させる機能を提供しているサービスとなります。
データハブ自体は自前で用意する必要があるのですが、データハブ連携をするのに役立つ機能をCIHが提供してくれています。

主に導入メリットは主に二つに大別されます。

• システム同士のデータ連携をハブを介すことによってシステム間を疎結合にする
• データの配信・集信をわけて非同期にする

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

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

具体的にデータハブで実現できる嬉しいことをさらに考えてみましょう。

嬉しいこと1

例えば、上図の赤塗りつぶし部分、業務システムの日付項目タイムゾーンが他のタイムゾーンとずれていたため、修正する変更対応が必要になりました。
この場合、P2P連携（左）の場合は連携数の分だけ改修の影響がありますが、データハブを導入している場合はデータハブへの配信1インターフェースの改修で基本的に済むということで、変更影響が最小で済みます。
影響範囲の調査もデータ連携が入り組んでいないため、容易です。

嬉しいこと2

次はこんな状況の場合を考えてみます。

• あるシステムAのIDは別のシステムBのIDと重複している
• 同じ商品なのにシステムAとシステムCのIDで別IDが振られている

もしもこの状況で、システム間データ連携で都度システム間のID対応表を作成してIDの変換対応をしてしまうと、システム数が増えるたび変換をしなければならずデータのスパゲティ化まっしぐらです。　
また新たな競争優位性のあるシステムの置き換えのたびに、システム間で新たに変換対応表を作成しなければなりません。

この場合は、マスタデータ管理システムを確立させ、統合IDに変換させた、いわば標準データをデータハブに配置することで解決します。
標準データがデータハブに存在すると、あとはデータを使用したいシステムがデータハブからデータ取得すればよいだけとなり、結果的にデータ連携数が少なくなります。

なお、標準データではなくシステムのローカルデータがデータハブに格納されてしまうと、結局システム間のローカルデータ同士の変換となり、データハブの効果は薄れてしまいます。

嬉しいこと3

システム同士を直接連携しないので、お互いPub（データをデータハブに提供すること）Sub（データをデータハブから購読すること）を自由なタイミングで非同期で実施できます。
相手のシステム側を意識する必要はありません。
新しくSubシステムが増えたとしても、Pub側のシステムを気にせずデータハブからデータを取得して自システムのローカルデータに合うようにデータ連携すれば良いです。

📍データハブを作る上でのPOINT

• データハブに格納する標準データを整備すること
• 標準データと各システムのローカルデータの対応表を作ること

データハブについて、つらつらと書いてしまいましたが、
じゃあCIHは何なのかというと、データハブ連携を実現するための補助的な機能を提供してくれるサービス、となります。

CIHのアーキテクチャ

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

参照：Cloud Integration Hub architecture（2023/09/25引用）

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

Clients

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

Informatica Intelligent Cloud Services Hosting Services

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

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

• トピックテーブルのサイズ制限：64,000 bytes
• リポジトリの最大サイズ：25GB
• 参考：Hosted publication repository size specifications

プライベートリポジトリを利用する場合は、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連携がテクニカルからビジネスドメインまでを考慮に入れて定義した標準データモデルとなるよう連携する方法です。

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

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

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

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

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

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

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

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

トピック構造

パブリケーションリポジトリのトピックにトピックテーブルのスキーマの定義方法を設定できます。
定義方法は、以下の４種類があります。

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

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

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

2. アプリケーション

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

アプリケーションの作成単位は名前のとおり、まずはアプリ単位でいいと思いました。
SalesForceがあればSalesForceという単位で作成するイメージです。

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

3. パブリケーション

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

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

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

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

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

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

モード

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

スケジューリング

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

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

4. サブスクリプション

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

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

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

オプションのトピック

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

再試行ポリシー

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

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

5. 実行

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

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

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

例として、今回のターゲットテーブルのデータは以下になります。

まとめ

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

トピックやパブリケーション・サブスクリプションの設計が考えどころではありますが、データハブとしての疎結合化が非常に魅力的だと思いました。
CIHは連携の綺麗さを目指すもので、なかなかCDIと比べると効果が明らかに感じることはできない部分はどうしてもあると思うのですが、
少しでもデータハブとCIHの魅力が伝われば幸いです。
個人的意見としては、データハブは確実に必要なものではないため、導入はリーダーシップを持って実施する必要がありそうです。　　

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