データベースに保存された構造化データを含む

文書またはファイルに保存された非構造化テキスト データ

オーディオ、ビデオ、ストリーミング データなどの他のタイプの非構造化データ。

1. ETL の目標: 明確な目標を持ってデータ ウェアハウスに参入する

2. 構造化データ: データ ウェアハウスに入る

3. データ ウェアハウス: 最終的な目標は BI

定期的にスケジュールされたイベントとして実行可能（バッチ処理）

新しいデータまたはデータが更新されたときに実行可能 (リアルタイムまたはイベント駆動)

必要なデータの選択とソース データからの抽出が含まれます。

抽出されたデータは、ディスクまたはメモリ上の物理データ リポジトリに保存されます。

選択したデータをターゲットデータベースの構造と互換性のあるものにすることです

フォーマットの変更

構造変化

セマンティックな変更

重複を排除する

並べ替える

バッチまたはリアルタイムで実行可能

または、変換結果を物理的な状態でキャッシュ領域に保存します

または、変換されたデータを仮想状態でメモリに保存します

搬入工程に移るまで

変換結果をターゲット システムに物理的に保存または表示します

概要

ターゲット システムがソース システムや中間アプリケーション システムよりも強力な変換機能を備えている場合、データ処理シーケンスを ELT (抽出、ロード、変換) に切り替えることができます。

ELT を使用すると、データを変換する前にターゲット システムにロードできます。

ELT を使用すると、ソース データを生データの形式でターゲット システム上でインスタンス化できるため、他のプロセスにとって有益です。

ELT を使用したデータ レイクへの読み込み（ビッグ データ環境では一般的）

変換と同義であり、ソース構造からターゲット構造への検索行列を構築するプロセスとそのプロセスの結果の両方を指します。

抽出されるソース データと抽出されたデータの識別ルール、ロードされるターゲットと更新されるターゲット行の識別ルール、および適用される変換または計算ルールを定義します。

データがソース システムによって生成されるときと、データがターゲット システムで利用可能になるときとの間の時間差を指します。

データ処理方法が異なれば、データ遅延の程度も異なります。

データは、データ利用者からの手動リクエストに基づいて、または定期的に自動的にトリガーされて、ファイルのバッチとしてアプリケーションと組織間を移動します。このタイプの対話はバッチ処理または ETL と呼ばれます。

バッチ モードで移動されたデータは、特定の時点のすべてのデータを表します。

この一連のデータをインクリメントといい、ある時点のデータをスナップショットといいます。

バッチ データ統合ソリューションの場合、多くの場合、ソースでのデータ変更とターゲットでのデータ更新の間に大幅な遅延が発生し、その結果、遅延が長くなります。

マイクロバッチング

機会

特定の時間範囲内に変更されたデータのみを含めるフィルタリングを追加することで、送信帯域幅要件を削減する方法です。

変更データ キャプチャは、データ セットへの変更 (挿入、変更、削除) を監視し、これらの変更 (デルタ) を、データを使用する他のデータ セット、アプリケーション、および組織に伝達します。

変更データ キャプチャ プロセスの一環として、データにタグやタイムスタンプなどの識別子を付けることもできます。

変更データのキャプチャはデータベースまたはログベースで行うことができます

データに基づいて

ログに基づいて

バッチ アプローチを採用しないほとんどのデータ統合ソリューションは、ほぼリアルタイムまたはイベント駆動型のアプローチを使用します。

データは、特定のスケジュール内で、またはデータ更新などのイベントの発生に応じて、より小さなセットで処理されます。

ほぼリアルタイムの処理は、バッチ処理と比較して待ち時間が短くなります。

また、作業は時間の経過とともに分散されるため、システム負荷が低くなります。

ただし、一般に同期データ統合よりも遅くなります。

ほぼリアルタイムのデータ統合ソリューションは、多くの場合、エンタープライズ サービス バスを使用して実装されます。

非同期データ フローでは、データを提供するシステムは、受信側システムが更新を確認するのを待たずに処理を続行します。

非同期とは、他のシステムが正常に機能している間、送信または受信システムが一定期間オフラインになる可能性があることを意味します

非同期データ統合では、ソース システム アプリケーションの実行継続がブロックされず、ターゲット アプリケーションが使用不可になってもソース アプリケーションが使用できなくなることもありません。

非同期構成ではアプリケーションへのデータ更新がタイムリーではないため、準リアルタイム統合と呼ばれます。

ソース データとターゲット データ間の時間遅延やその他の差異が許可されない状況があります。

あるデータセットのデータを別のデータセットのデータと完全に同期する必要がある場合は、リアルタイム同期ソリューションを使用する必要があります。

同期統合ソリューションでは、実行は他のアプリケーションまたはプロセスからの確認を待ってから、次のアクティビティまたはトランザクションを実行します。

データ同期の確認を待つために時間を費やす必要があるため、ソリューションで処理できるトランザクションは少なくなります。

データを更新する必要があるアプリケーションが使用できない状態にある場合、アプリケーション内のトランザクションを完了できません。

インシデント対応時間を短縮するように設計された低遅延データ統合ソリューション

ソリッドステートディスクを使用する

非同期ソリューション

大規模なマルチプロセッサまたは並列処理

通常は、データセット自体ではなく、データセットの変更ログを監視します。

データセットへのアクセスに関してアプリケーションと競合しないため、運用アプリケーションへの影響を最小限に抑えます。

変更ログのデータのみがレプリカ間で転送されます。

標準のレプリケーション ソリューションはほぼリアルタイムです

共有データ システム間のやり取りの大部分は「ポイントツーポイント」であり、相互にデータを直接受け渡します。

このモデルは、小規模なシステム セットのコンテキストで機能します。

しかし、多くのシステムが同じソースからの同じデータを必要とする場合、非効率になり、組織のリスクが増大します。

インパクト加工

管理インターフェース

潜在的な不一致

共有データ (物理または仮想) をアプリケーションが使用できる中央データセンターに統合します。

データを交換したいすべてのシステムは、他のシステムと直接 (ポイントツーポイント) ではなく、中央の共通データ コントロールを通じてそれを行います。

データ ウェアハウス、データ マート、運用データ ストア、マスター データ管理センターはすべてデータ センターの例です。

データセンターは、ソース システムのパフォーマンスへの影響を限定しながら、データの一貫したビューを提供します

システムをミックスに追加するには、データセンターへのインターフェースを構築するだけで済みます。

Enterprise Service Bus (ESB) は、複数のシステム間でほぼリアルタイムでデータを共有するためのデータ統合ソリューションです。そのデータ センターは、組織内のデータ共有の標準化された形式を表す仮想概念です。

一部のハブアンドスポーク モデルには、許容できない遅延やパフォーマンスの問題がある

ハブアンドスポーク アーキテクチャではデータ センター自体に作成オーバーヘッドが発生します

パブリッシュ アンド サブスクライブ モデルには、データを宣伝 (パブリッシュ) するシステムと、データを受け入れる (サブスクライブ) 他のシステムが含まれます。

データをプッシュするシステムはデータ サービスのカタログにリストされており、データを使用したいシステムはこれらのサービスに登録します。

データを公開すると、データは購読ユーザーに自動的に送信されます

カップリングは、2 つのシステムがどの程度絡み合っているかを表します。

固く結ばれた

疎結合

整える

プロセス制御

エンタープライズ アプリケーション統合モデル EAI では、ソフトウェア モジュールは明確に定義されたインターフェイス呼び出し (アプリケーション プログラミング インターフェイス API) を通じてのみ対話します。

データ ストレージは、独自のソフトウェア モジュールを通じてのみ更新できます。他のソフトウェアは、定義された API を通じてのみアプリケーション内のデータに直接アクセスできます。

EAI はオブジェクト指向の概念に基づいており、他のモジュールに影響を与えることなくモジュールを再利用および置換できる機能を重視しています。

システム間の仲介者として機能し、システム間でメッセージを配信します。

アプリケーションは、ESB の既存の機能を通じて、送受信されたメッセージまたはファイルをカプセル化できます。

疎結合の例として、ESB は 2 つのアプリケーション間のサービスとして機能します。

アプリケーション間の明確に定義されたサービス呼び出しを通じて、プッシュ データまたは更新データを提供できます。

アプリケーションは他のアプリケーションと直接対話したり、他のアプリケーションの内部動作を理解したりする必要はありません。

アプリケーションの独立性と、対話するシステムに大幅な変更を加えることなくシステムを置き換える組織の能力をサポートします。

SOA の目標は、独立したソフトウェア モジュール間の明確に定義された対話を定義することです。

各モジュールは、他のソフトウェア モジュールまたは個々のコンシューマが機能を実行する (機能を提供する) ために使用できます。

SOA の重要な概念は、独立したサービスが提供されるということです。サービスには呼び出し側アプリケーションに関する事前知識がなく、サービスの実装は呼び出し側アプリケーションにとってブラック ボックスです。

SOA は、Web サービス、メッセージング、API などのさまざまなテクノロジを通じて実装できます。

イベント処理は、発生したイベントに関する情報の流れを追跡および分析 (処理) し、そこから結論を引き出す方法です。

複雑なイベント処理とは、複数のソースからのデータを結合し、意味のあるイベントを識別し、イベントの処理とルーティングをガイドするためにこれらのイベントのルールを設定し、動作やアクティビティを予測し、予測結果に基づいてリアルタイムの応答を自動的にトリガーすることを指します。

販売機会、Web クリック、注文、顧客からの電話など。

複雑なイベント処理にはさまざまなデータを統合できる環境が必要

予測にはさまざまな種類の大量のデータが関与することが多いため、複雑なイベント処理はビッグデータに関連付けられることがよくあります。

複雑なイベント処理では、多くの場合、リアルタイムのストリーミング データやメモリ内データベースの処理など、超低遅延をサポートするテクノロジーの使用が必要になります。

データが異なるデータ リポジトリに存在する場合、物理的な統合以外の方法でデータを集約することもできます。

データ フェデレーションにより、それぞれの構造に関係なく、独立したデータ リポジトリの組み合わせへのアクセスが提供されます。

データ仮想化により、分散データベースや複数の異種データ ストアにアクセスし、単一のデータベースとして表示できるようになります。

Software as a ServiceSaaS

Data as a Service DaaS

クラウド コンピューティングが登場する前は、統合は内部統合と企業間統合 B2B に分けられていました。

内部統合

企業間の統合

クラウド統合

これらの非効率または非効果的な構成を見つけて排除することは、プロジェクトの成功に大きく役立ち、組織のデータ使用能力全体を向上させることができます。

ハブアンドスポーク、ポイントツーポイント、パブリッシュ/サブスクライブ