エンタープライズデータ統合パターンの比較

エンタープライズ データ統合パターンは、システム間でデータを移動および調整するための再利用可能なアーキテクチャ ソリューションであり、Hohpe と Woolf の標準カタログ (Enterprise Integration Patterns、2003) には、メッセージング、ルーティング、変換、およびエンドポイントにわたる約 65 の名前付きパターンが文書化されています。この比較では、主要なファミリー、そのトレードオフ、および選択方法について説明します。

エンタープライズ データ統合パターンの説明

実践的な観点から説明されるエンタープライズ データ統合パターンには、ほとんどの統合作業は新しいものではないという認識が含まれます。同じ問題が発生します。システムは異なるスキーマを使用し、異なるクロックで実行され、独立して障害が発生し、調整する必要があります。パターンはアーキテクトに共通の語彙を提供するため、設計レビューでソリューションを最初から再作成するのではなく、「ここではクレーム チェックを使用し、そこではルーティング スリップを使用します」と言えるようになります。

パターンの文献は 2 つの伝統に分けられます。 Enterprise Integration Patterns (EIP) カタログに根ざしたメッセージングの伝統は、統合をエンドポイント間のメッセージの非同期フローとして扱います。 Kimball スタイルのディメンション モデリング、Data Vault、最新の ELT ツールに代表されるデータの伝統では、統合をデータ セットの移動と再形成として扱います。現実世界のほとんどのアーキテクチャでは、この 2 つが混在しています。イベントのストリームがウェアハウスに供給され、正規モデルがその2つを整合させます。

パターンは商品ではありません。メッセージ ブローカーは複数のパターンを実装します。リバース ETL ツールは別のパターンを実装します。パターンは契約であり、製品はその実装です。この区別により、ベンダーが変わってもアーキテクチャの移植性を維持できるため、重要です。

エンタープライズ データ統合パターンとは

エンタープライズ データ統合パターンは、異種システムの接続で繰り返し発生する問題を解決する再利用可能な設計のことです。これらは、特定のテクノロジに依存しないソリューションの形状 (データのルーティング、変換、バッファリング、重複排除、および調整の方法) を記述します。

主なファミリーについては、明示的に言及する価値があります。

関連: Boomi AtomSphere — ハイブリッドクラウドとオンプレミスの統合のためのエンタープライズ iPaaS.

• メッセージング モデル: メッセージ チャネル、メッセージ ルーター、メッセージ トランスレーター、メッセージ ブローカー、パブリッシュ/サブスクライブ、ポイントツーポイント。
• ルーティング モデル: コンテンツ ベースのルーター、受信者リスト、スプリッター、アグリゲーター、リシーケンサー、ルーティング スリップ、プロセス マネージャー。
• 変換モデル: メッセージ トランスレーター、エンベロープ ラッパー、コンテンツ エンリッチャー、クレーム検証、ノーマライザー。
• エンドポイント モデル: クエリされたコンシューマ、イベント コンシューマ、べき等レシーバ、トランザクション クライアント、同時コンシューマ。
• データ移動モデル: ETL、ELT、変更データ キャプチャ (CDC)、バッチ同期、ストリーミング レプリケーション、リバース ETL。
• セマンティック モデル: 正規データモデル、参照データ管理、データ仮想化、エンティティ解決。

正規のエンタープライズ データ モデルはこれらの上に位置します。これは、各統合が適合する共有語彙 (顧客、注文、製品、場所) を定義します。クラウド情報モデルは、クラウド システムとオンプレミス システム全体にわたって アプリケーションに依存しない（アプリケーション・アグノスティックな） になるように設計された標準モデルのオープン ソースの例です。

エンタープライズ データ統合パターンの意味

エンタープライズ データ統合パターンの最も深いレベルでは、デカップリング（分離）が本質です。各パターンは、相互のスキーマ、タイミング、および障害モードに緊密に結合される 2 つのシステム間に安定したインターフェイスを挿入する手段です。

次の 3 つの形式のデカップリングが繰り返されます。

私たちの選択: Workato — ビジネスチームが実際に構築できる自動化主導の iPaaS.

1. 空間分離 — 送信者は、誰がメッセージを受信しているのかを知りません。パブリッシュ/サブスクライブおよびメッセージ チャネルでこれが可能になります。
2. 時間的分離 — 送信者は受信者を待ちません。キューと耐久性のあるログがこれを提供します。
3. スキーマの分離 — どちらの当事者も相手の内部形式を知りません。メッセージ トランスレータと正規モデルがこれを提供します。

3 番目は最も難しく、最も価値があります。スキーマの分離は正規モデルが存在する理由であり、ここで JSON-LD、GraphQL、およびスキーマ レジストリが登場します。正規モデルに変換層を加えた場合、新しいシステムを追加するには、既存のすべてのシステムに対する N 個のマッピングではなく、1 つのマッピングが必要になることを意味します。

エンタープライズ データ統合パターンの利点

エンタープライズ データ統合モデルの利点は、すぐに現れるのではなく、時間の経過とともに蓄積されます。テンプレートを使用して構築された最初の統合は、多くの場合、高速なポイントツーポイント スクリプトよりも遅くなります。 10 回目の統合はすでに難しい質問に答えているため、かなり高速です。

具体的なメリットとしては以下が挙げられます。

• 再利用: 一度解決されたルーティング パターンは、後続の各ルートで機能します。
• 改訂可能性: 名前付きモデルにより、新しいエンジニアや監査人にとってアーキテクチャの決定が読みやすくなります。
• 障害分離: Idempotent Receiver や Dead Letter Channel などのパターンにより、障害処理が偶発的ではなく明示的に行われます。
• ベンダーの移植性: 契約が製品に関連付けられていないため、モデル駆動設計はツールの移行後も存続します。
• コスト制御: Claim Verification のようなモデルは、高価なメッセージ バスを介して大きなペイロードを移動することを回避します。

エンタープライズ データ統合パターンの長所と短所

パターンファミリー	主な強み	主な費用	ベストフィット
ポイントツーポイント	シンプルで迅速な構築	O(N²) 接続、脆弱	2 つのシステム、安定したスキーマ
ハブアンドスポーク / ブローカー	集中管理、接続数の削減	ハブがボトルネックとなり単一障害点となる	多くのシステム、中程度のボリューム
パブリッシュ/サブスクライブ	疎結合、ファンアウト	追跡が難しく、順序付けが課題	イベント駆動型、多くの消費者
ETL (バッチ)	成熟したツール、推論が簡単	レイテンシ、ロードウィンドウ	分析、夜間の調整
ELT	ウェアハウスのコンピューティングを活用	強力な倉庫ガバナンスが必要	クラウド分析
CDC / ストリーミング	ほぼリアルタイム、ソースへの影響が少ない	運用の複雑さ、スキーマのドリフト	運用上の同期、低遅延のニーズ
正規モデル	スキーマの分離、再利用	先行モデリング投資、ガバナンス	マルチシステム、長寿命プログラム
データ仮想化	データの重複なし	クエリのパフォーマンス、ソースの可用性の依存性	フェデレーションレポート

正直なトレードオフは、各モデルが特定の機能と引き換えにシンプルさを犠牲にすることです。ポイントツーポイントはシンプルであり、進化しません。正規モデルはスケーラブルであり、確立するのに費用がかかります。両方を兼ね備えたモデルはありません。

エンタープライズ データ統合パターンには価値がありますか

エンタープライズ データ統合モデルは、システムの数、統合の有効期間、または障害のコストがしきい値を超えた場合に価値があります。 2 つの内部ツールを接続する 1 つのスクリプトの場合、テンプレートはオーバーヘッドになります。数十の SaaS アプリケーション、ERP、データ ウェアハウス、顧客ポータルを 5 年間にわたって接続するプログラムの場合、モデルは保守可能なプラットフォームと保守不可能な複雑なプラットフォームの違いを意味します。

有用な決定ヒューリスティック: 統合をカウントします。 5つ未満であれば、ポイントツーポイント（個別接続）で十分な場合が多いです。 5 年から 20 年の間に、ブローカーと正規モデルを採用します。 20 年を超えると、ガバナンス、スキーマ レジストリ、正式なモデル ドキュメントに投資します。これらのしきい値は法律ではなく経験則です。規制されている業界はより早くガバナンスを導入する必要があります。

関連: Matillion — クラウド データ ウェアハウス用に構築されたプッシュダウン ELT.

エンタープライズ データ統合パターンの問題

エンタープライズ データ統合パターンの問題は現実のものであり、コミットする前に名前を付ける価値があります。

• オーバーエンジニアリング: 些細な問題に重いモデルを適用すると、何のメリットもなくコストが増加します。
• 正規モデルのドリフト: 共有モデルは、システムが実際に必要とするものから徐々に逸脱し、マッピングに例外が蓄積されます。
• スキーマの進化: ソース システムは警告なしに変更されます。レジストリやバージョン管理がなければ、統合は静かに中断されます。
• ID 解決: 同じ顧客が 3 つのシステム上の 3 つの ID の下に存在しており、マスター データ戦略がなければこの問題を解決できるモデルはありません。
• 可観測性のギャップ: 非同期および分離されたシステムは、同期呼び出しよりも追跡が困難です。
• ガバナンス コスト: 正規モデルでは、1 回限りのプロジェクトではなく、継続的な予算配分（リソース確保）が必要です。

最も一般的な失敗は、間違ったモデルを選択したのではなく、選択したモデルを管理できないことです。所有者のいない正規モデルは 1 年以内に崩壊します。

セマンティックおよび API 層のパターン: JSON-LD および GraphQL

最新の統合は、メッセージ層だけでなく、セマンティック層と API 層でもますます行われています。 2 セットのモデルは、ほとんどのモデル カタログであまり取り上げられていないため、特に注意する必要があります。これらは、主要なエンタープライズ データ統合パターンを表しています。

どこから始めましょうか: Fivetran — 実行し続けるフルマネージドの ELT パイプライン.

エンタープライズ語彙用の json-ld コンテキスト設計パターン

エンタープライズ語彙の JSON-LD コンテキスト設計パターンは、JSON ドキュメントにグローバルに明確な意味を与えるという問題を解決します。 @context は短い用語を IRI にマッピングするため、"customerId" はシステムごとに異なる意味をもつ文字列ではなく、特定の逆参照可能な定義に解決されます。

企業で使用するための便利な json-ld コンテキスト設計パターンのリスト:

• インライン コンテキスト: @context は各ドキュメントに統合されます。シンプルですが、重複していて更新が困難です。
• 参照コンテキスト: @context は、ホストされているドキュメントへの URL です。一元化されており、キャッシュ可能でバージョン管理が可能です。
• スコープ付きコンテキスト: ネストされたオブジェクトは独自の @context を持ち、そのサブツリーの親をオーバーライドします。
• コンテキストの継承: 基本コンテキストは共通の用語を定義し、ドメイン コンテキストはそれを拡張します。これは、エンタープライズ データ モデルの JSON-LD コンテキスト設計パターンです。コア語彙に加えて、製品、注文、およびパーティの拡張機能です。
• 用語のエイリアシング: 移行中に複数の従来のフィールド名を正規の用語にマッピングします。
• 型強制: 用語が常に日付、IRI、または数値であることを宣言し、解析時の曖昧さを取り除きます。

製品データ エンタープライズ向けの json-ld コンテキスト パターン

製品データの企業展開用の JSON-LD コンテキスト パターンは通常、schema.org の用語を内部拡張でオーバーレイします。製品コンテキストは、「gtin」、「sku」、および「mpn」を正規の識別子にエイリアス化し、価格を通貨型の値に強制し、基本コマース語彙から継承することができます。これにより、カタログ、マーケットプレイス、および倉庫のすべてが、ペアごとのオーダーメイドのマッピングなしで同じ製品を説明できるようになります。

json-ld コンテキスト URI 設計パターン

コンテキスト URL は長期契約であるため、JSON-LD コンテキスト URI 設計パターンは重要です。パス (/context/v2/commerce.jsonld) をバージョン管理し、古いバージョンを無期限に解決可能な状態に保ち、適切なキャッシュ ヘッダーを使用して提供し、公開されたコンテキストを適切に変更しないことをお勧めします。意味を変えるコンテキスト URL は、すべての消費者にサイレントに影響を及ぼします。

json-ld コンテキスト レジストリの設計パターン

JSON-LD コンテキスト レジストリ デザイン パターンは、コンテキストを管理されたアーティファクトとして扱います。レジストリには、各コンテキスト、そのバージョン履歴、その所有チーム、およびその依存関係が保存されます。これらのレジストリは、ストリーミング パイプラインの Avro、Protobuf、および JSON スキーマに使用されるスキーマ レジストリと自然にペアになり、メッセージ スキーマとセマンティック コンテキストに単一のガバナンス サーフェスを提供します。

json-ld コンテキスト設計のアンチパターン

JSON-LD コンテキスト設計のアンチパターンで回避すべきものは次のとおりです。

• 変更可能な公開コンテキスト: ライブ コンテキスト URL を変更すると、警告なしにコンシューマーが中断されます。
• コンテキストのスプロール: レジストリや所有権のない、ほぼ重複した多数のコンテキスト。
• 過剰なネスト — 推論することが不可能な、範囲が深いコンテキスト。
• 暗黙的なデフォルト — 明示的な IRI ではなく、文書化されていない用語の意味に依存します。
• 懸念事項の混在 — 1 つのコンテキストが製品、パーティー、財務の語彙を同時に提供しようとしています。

エンタープライズ アプリ用のgraphql クエリ パターン

エンタープライズ アプリの GraphQL クエリ パターンは、API 統合レイヤーに対応します。関連するパターンには、永続化クエリ (承認されたクエリを固定してペイロードと攻撃対象領域を削減する)、バッチ処理とデータローダー パターン (バックエンド サービスに対する N+1 解決を回避)、大規模な安定した結果セット用のカーソル ベースのページネーション、および複数のチームがゲートウェイによって統合されたサブグラフを所有するフェデレーションが含まれます。フェデレーションは実際には、API レイヤーで表現される標準的なモデル パターンです。

正規のエンタープライズ データ モデルの多対多パターン

正規のエンタープライズ データ モデルの多対多パターンは、エンティティが複雑な方法で相互作用する現実を処理します。顧客は多数の住所を持っています。製品は多くのカテゴリに属します。注文では多くの製品が参照されます。それらのモデリングには、埋め込み配列ではなく、独自の ID とライフサイクルを持つ明示的な結合エンティティが必要です。正規モデルでは、結合エンティティが有効日、ロール、ステータスなどの関係独自の属性を保持しているため、多くの場合、結合エンティティが最も重要なオブジェクトになります。正規モデルで多対多を正しく行うことで、マッピング層が特殊なケースを蓄積するのを防ぐことができます。

選択方法: 基準リスト

エンタープライズ データ統合モデルの中から選択するのは、好みではなく決定事項です。次の基準に基づいて候補を評価します。

1. レイテンシー要件: バッチ、マイクロバッチ、またはストリーミング。
2. 結合許容差 — 1 つのシステムを変更するときに、いくつのシステムを変更する必要があるか。
3. 失敗セマンティクス: 少なくとも 1 回の配信は許容されますか、それとも 1 回だけ配信する必要がありますか?
4. ボリュームとペイロード サイズ: クレームの検証やコンテンツの強化が必要ですか?
5. パターンの変動性: ソースはどのくらいの頻度で変更されますか?また、レジスターはありますか?
6. ガバナンス能力 — 正規モデルとコンテキストを所有するのは誰ですか?
7. 可逆性 — 後でモデルを変更するのは困難ですか?

これらに対して候補者を採点し、厳しい制約を満たす最も単純なモデルを優先します。複雑さは要件によって得られるものであり、デフォルトで採用されるものではありません。

重要なポイント

• エンタープライズ データ統合パターンは再利用可能な設計であり、製品ではありません。パターンはコントラクトであり、ツールは 1 つの実装です。
• EIP カタログ (Hohpe および Woolf、2003 年) は引き続きメッセージング パターンのリファレンスであり、ETL/ELT、CDC、および正規モデルがデータ層をカバーします。
• すべてのパターンは、シンプルさを犠牲にして特定の機能を実現します。普遍的に最適なパターンはありません。
• 正規モデルと JSON-LD コンテキストは、スキーマの分離を提供します。これは、最も価値が高く、最も困難な分離形式です。これには、エンタープライズ データ モデル用の json-ld コンテキスト設計パターン、エンタープライズ語彙用の json-ld コンテキスト設計パターン、および製品データ エンタープライズ用の特定の json-ld コンテキスト パターンの利用が含まれます。エンタープライズ アプリ用の json-ld コンテキスト デザイン パターン リストまたはgraphql クエリ パターンを探している場合、これらのツールを使用するとさらに分離が可能になります。
• パターン選択ではなくガバナンスが最も一般的な失敗点です。所有されていない正規モデルは崩壊します。
• 統合数が増加するにつれて、より重いパターンを採用します。およそ 5 つの統合未満では、多くの場合、アドホックで十分です。

出典と詳細情報

• データ統合 — Wikipedia: データ統合は、複数のソースからのデータを結合、共有、または同期して、統一されたビューをユーザーに提供するプロセスです。幅広い範囲があります…
• データ モデル — Wikipedia: データ モデルは、データの要素を整理し、それらが相互にどのように関係するか、また現実世界のエンティティのプロパティとどのように関連するかを標準化する抽象モデルです。…
• エンタープライズ データ モデリング — Wikipedia: エンタープライズ データ モデリングまたはエンタープライズ データ モデリング (EDM) は、企業や組織によって使用されるデータのグラフィカル モデルを作成する実践です。典型的な出力…

よくある質問

エンタープライズ データ統合パターンとは何ですか?

エンタープライズ データ統合パターンは、異種システムを接続するための名前付きの再利用可能なアーキテクチャ ソリューションであり、データのルーティング、変換、バッファリング、調整の方法をカバーします。これらは、EIP カタログのメッセージング モデル、ETL や CDC などのデータ移動モデル、正規モデルなどのセマンティック モデルをカバーします。価値があるのは、共通の語彙と、繰り返し発生する問題に対する実証済みの解決策です。

エンタープライズ データ統合パターンの利点は何ですか?

利点としては、統合間での再利用、レビュー可能なアーキテクチャの決定、明示的な障害処理、ベンダーの移植性、クレーム検証などのモデルによるコスト管理などが挙げられます。メリットは積み重なっていきます。最初のテンプレート化された統合はスクリプトよりも時間がかかりますが、10 番目の統合は難しい質問がすでに答えられているため、はるかに高速です。

エンタープライズ データ統合パターンの長所と短所は何ですか?

利点は、再利用、明確さ、障害の分離、移植性です。欠点としては、初期モデリングのコスト、ガバナンスのオーバーヘッド、および些細なオーバーエンジニアリングの問題のリスクが挙げられます。各モデルはシンプルさを犠牲にして機能を実現しているため、適切な選択は遅延、結合許容度、相互運用が必要なシステムの数によって異なります。

エンタープライズ データ統合パターンには価値がありますか?

統合の数、寿命、または障害のコストがしきい値を超えた場合、モデルは価値があります。約 5 つの統合未満では、多くの場合、アドホックなアプローチが適しています。 20 年を超えると、ガバナンス、スキーマ レジストリ、モデルの正式な文書化が不可欠になります。規制された業界は、これらの経験則が示唆するよりも早くガバナンスを導入する必要があります。

エンタープライズ データ統合パターンはどのような問題を解決し、また生み出すのでしょうか?

パターンは、スキーマの不一致、タイミングの違い、および障害の分離を解決します。これらは、オーバーエンジニアリング、カノニカルモデルのドリフト、壊れたスキーマの進化、ID 解決のギャップ、および可観測性の問題のリスクを生み出します。最も一般的な失敗は、間違ったモデルを選択したのではなく、選択したモデルを長期にわたって管理できなかったことです。

JSON-LD と GraphQL は統合パターンにどのように適合しますか?

JSON-LD コンテキスト モデルは、ガバナンスのための継承、レジストリ、URI バージョン モデルを備えた JSON 用語にグローバルに明確な IRI を与えることにより、セマンティックな分離を実現します。永続クエリ、データ ローダーのバッチ処理、フェデレーションなどの GraphQL パターンは、API レイヤーに対応します。フェデレーションは実際には、統合された API ゲートウェイとして表現されるカノニカルモデル パターンです。

さらに読む

• Enterprise Integration Patterns — Gregor Hohpe と Bobby Woolf のカノニカルカタログ: https://www.enterpriseintegrationpatterns.com/
• エンタープライズ統合モデル (Wikipedia プレゼンテーション): https://en.wikipedia.org/wiki/Enterprise_Integration_Patterns
• JSON-LD 1.1 仕様、W3C 推奨: https://www.w3.org/TR/json-ld11/
• GraphQL仕様：https://spec.graphql.org/
• クラウド情報モデル — クラウドとオンプレミスの相互運用性のためのオープンソースの正規モデル: https://cloudinformationmodel.org/