データ製品におけるデータ統合と同期戦略

ビジネス・プロセスと意思決定をサポートするデータを移動および結合するためのさまざまなアプローチが、長年にわたって数多く生み出されてきました。それぞれに独自の機能と利点があります。これらの機能と、それがデータ戦略の望ましい結果とどのように関係するかを理解することは、最適なシステムを設計するために不可欠です。

すべてのデータを最適化し、アクセスしやすく、統合された状態に保つための戦略を構築する際には、次のような複数の変数と要件を考慮する必要があります。

• どれくらい早く最新のデータが必要ですか。
• 帯域幅とストレージの制約は何ですか。
• どのような種類の技術リソースが利用可能ですか。
• 同じデータのコピーをいくつ保持する必要がありますか。
• データセットの大きさはどれくらいですか。

バッチ処理

バッチ処理では、データを一定の間隔またはバッチで転送します。これらのパターンには、抽出変換ロード (Extract Load Transform ：ETL)、抽出ロード変換 (ELT)、リバース ETL、ミラーリングまたはレプリケーション、およびライトバック ツールが含まれます。

ETLとELT

ETL は、データを移動するための従来のアプローチです。データはデータ ソースから抽出され、ビジネス ルールに基づいて変換され、ターゲット データベースにロードされます。このアプローチは非常に安全ですが、柔軟性に欠けます。この柔軟性により、データ セットを非常に構造化して文書化する必要があります。これにより、複雑な変換が容易になります。レガシー システムのデータベースは通常、非常に構造化され、柔軟性に欠けるため、ETL はこれらのシステムに適しています。これらのプロセスを構築するには、開発者はデータ構造とプログラミング言語に関する深い知識を持っている必要があります。

ELT は ETL に似ていますが、変換はターゲット データベースにロードした後に行われます。このより現代的なアプローチでは、生のデータが変換後もターゲット データベースに残るため、柔軟性が高まります。その結果、元のデータ ソースからデータを取得せずに、変換を反復的または遡及的に実行できるため、新しいデータ セットを抽出するために必要なリソースが削減されます。ELT は、データのラングリングと変換をエンド ユーザーの近くで実行できる、より広範囲で構造化されていないデータ セットに適しています。

リバースETL

リバース ETL は別のバッチ プロセスですが、データは ETL パイプラインの逆方向に流れます。データは運用中のサードパーティ アプリケーションから抽出され、中央データベースにロードされます。このアプローチにより、組織は中央ウェアハウスで 1 つのバージョンのデータ セットを統合し、運用アプリケーションで他のアプリケーションや分析で使用しているのと同じデータを使用できるようになります。リバース ETL は、組織にとって「信頼できる唯一の情報源」をサポートします。

課題は、リバース ETL がバッチで実行されることです。データが絶えず変化する動的な組織では、更新スケジュールが異なるため、異なるグループが同じデータの異なるバージョンを使用する場合があります。リバース ETL 同期戦略では、複数のソースから大量のデータが運用システムにロードされるため、運用システムに負担がかかることもあります。これにより、競合が発生し、同じデータのデータ バージョンが混在する可能性があります。

ミラーリングとレプリケーション

ミラーリングとレプリケーションは、データを変換せずに別のデータベースに保存し、多くの場合、データ損失の場合にデータ セットをバックアップするために実装されます。また、データ管理を最適化し、データが移動しているときに永続的なデータ セットを作成する場合にも役立ちます。ミラーリングは、データだけでなく、データベース構造と管理システム全体も複製します。

レプリケーションは、データベース管理システムをコピーするのではなく、データのみをコピーするため、ミラーリングとは少し異なります。データベース管理システムがデータを定義しないため、レプリケーションを使用すると、さまざまなシステムからのデータへのアクセスがはるかに簡単になります。

ミラーリングは、負荷分散に適したオプションです。ソース データベースとコピーされたデータベースは同一であるため、どちらのソースからもデータに簡単にアクセスできます。ミラーリングの一般的な使用例は、障害復旧とリソース使用の最適化です。また、ミラーリングは、移動中のデータのスナップショットをキャプチャするのにも適しています。たとえば、定期的に使用される仮想化データは、永続的なデータ ストアにミラーリングできます。

リアル・タイム

データをリアルタイムで統合および管理すると、特に多様なデータ セットをマージする場合に多くの複雑さが生じます。さまざまなデータ セットが絶えず変化するため、ソース データとマージされたデータの間には常に矛盾が生じます。リアルタイム データは、センサーや財務データを追跡する運用システムに適しています。

チェンジ・データ・キャプチャ (Change Data Capture ：CDC)

CDC は、定義されたイベントが発生すると、1 つのデータベースの変更が別のデータベースに自動的に反映されるイベント ベースのパターンです。このパターンは双方向のデータ フローをサポートしているため、ソース データベースとターゲット データベースはデータを交換して同期を確保できます。CDC は、データ セット全体ではなく、変更されたデータのみがターゲット データベースに転送されるため、ETL よりもはるかに効率的なデータ移動方法です。

CDC は、統合できないデータベースやアプリケーションでうまく機能します。CDC プロセスは別のデータベースにデータをステージングし、ステージングされたデータからターゲット データベースに変更を共有できます。この方法では、別の動的データ ソースを維持する必要があるため、複雑さが増し、エラーが発生する可能性が高くなります。

ストリーミング・データ

ストリーミング データには、データの継続的な取り込み、処理、および宛先への移動が含まれます。通常、これは金融サービス データのセンサー データを意味します。多くの場合、ストリーミングはターゲット データベースへの途中で変換されます。

ストリーミング データは高速ですが、いくつかの欠点があります。ストリーミング データは常に移動しており、インターネット上のさまざまなパスをたどるため、データが正しい順序で処理されることは保証されません。一部のデータは、より新しいデータの後に到着して処理される可能性があり、最も正確なデータについて混乱が生じます。データが適切な順序で処理されるようにするには、適切なオーケストレーションを実装する必要があります。

ストリーミング データは、データ ソースのデータ モデルを下流のユーザーに公開します。下流のアプリケーションがソース データ モデルに直接接続されている場合、このモデルを変更すると下流で混乱が生じます。

ストリーミング データがデータ プロダクト内にパッケージ化されている場合、内部ソース データ モデルをデータ プロダクトのデータ モデルにマップできます。この構造により、データを外部グループと共有しやすくなります。

ライト・バック機能

フロントエンド BI ツールのライトバック機能は、ソース データベースに変更を加えるもう 1 つの方法です。この新しいパターンにより、BI ツールを使用するアナリストは、BI ツールから直接ソース データベースに変更を加えることができます。これらの変更は、データ ソースとアナリストの作業にすぐに反映されます。これにより、データを最もよく理解しているアナリストが、元のデータ ソースを調整または修正できます。

ライトバック機能により、データ アナリストは Excel と同じくらい迅速にデータベースを更新できるようになるため、Excel スプレッドシートへの依存も軽減されます。

アプリケーション統合

SaaS アプリケーションは通常、REST API を介してデータを共有します。これは、アプリケーション データベースからデータを取得するための簡単なプロセスです。API だけではデータを変換できませんが、iPaaS プラットフォームを介して実行すると、データをターゲット アプリケーションに送信する前に、データに対して自動変換プロセスを実行できます。

REST API は、1 つまたは 2 つのアプリケーション間の単純なデータ交換には適していますが、このタイプのアプローチは拡張性に欠けます。アプリが API を変更すると、下流のアプリケーションが機能しなくなる可能性があります。

データ仮想化

データ仮想化とは、接続されたデータベースから取得したデータの新しい仮想データセットを作成するコードを実行することです。この新しいデータセットはコードが実行されるたびに作成されますが、データは必要な期間のみ保持されます。これは、 Avrioプラットフォームが分析用のデータセットを生成するために使用するパターンです。このテクノロジーをデータ統合に使用すると、次のようないくつかの利点があります。

まず、データ仮想化では、基盤となるデータベースと構造がデータ自体から分離されます。これにより、データ仮想化のスケーラビリティと柔軟性が大幅に向上します。

2 目に、データ仮想化ではデータベースの永続的なコピーは作成されません。毎回新しいデータ・セットが作成されるため、コードが実行され、ソース データ・ベースから最新のデータが取得されます。このアプローチにより、同じデータの複数のバージョン間の競合が回避されます。ストレージ コストも最小限に抑えられます。

3 番目に、洗練されたコネクタ、フェデレーション クエリ エンジン、仮想化により、複数のデータベースからデータを一度にクエリ、変換、およびマージできます。統合されたメタデータ ストアとその上に重ねられた統一されたデータ モデルにより、このアプローチでは、データ アナリストはさまざまなデータ ストアからデータを単一のデータベースであるかのように取得できます。

最後に、データ仮想化により、データの制御が強化されます。データはこの仮想化レイヤーを通過するため、データ品質チェックを実行し、きめ細かいアクセス制御を実装できます。

Avrio とデータ統合パターン

それぞれの統合および同期のアプローチには、利点と欠点があります。どのアプローチを使用するかに関係なく、健全なデータ アーキテクチャを実現するには、データのガバナンス、セキュリティ、品質に注意を払うことが最も重要です。統合プラットフォームで適切なアプローチを組み合わせることで、強力で柔軟なソリューションを実現できます。

Avrio の機能の中核はデータ仮想化です。これは、コードが実行されるたびに分析用のデータを統合して新しいデータセットを作成するために使用されます。永続的なデータが必要で、定期的に変更がある場合、Avrio にはソース データベースの変更のみをミラーリングされた環境にミラーリングする CDC 機能も備わっています。

Avrio には、仮想化されたデータ セットから永続的なデータ セットを作成するためのミラーリング機能も備わっています。データが頻繁に変更されないが定期的に使用される場合、ミラーリングによって帯域幅リソースの使用量を削減できます。

Avrio プラットフォームでは、API を介してサードパーティがデータ製品にアクセスできるようになります。Avrio のこのフロントエンド レイヤーには、BI ツールで行われた変更を Avrio プラットフォームに接続されたバックエンド データベースに組み込むための書き戻し機能も備わっています。

複数の統合および同期パターンを組み合わせてビジネス成果を達成することは、戦略的に理にかなっています。状況はそれぞれ異なり、独自の機能が必要です。Avrio プラットフォームは、適切なテクノロジーとパターンを組み合わせて、ガバナンスとセキュリティが組み込まれたセルフサービス データ製品を使用して、複数のデータ サイロ間でデータにアクセスできるようにします。これは、AI 時代、迅速な分析、より優れた意思決定のために設計されています。

Avrio は、既存の統合ツールやインフラストラクチャにも適しています。データ レイクにデータをストリーミングしている場合、Avrio はデータ プロダクトを作成して、ストリーミング データのスナップショットをキャプチャし、分析に使用できます。十分に確立され、あまり変更されない ETL パイプラインを構築している場合、Avrio はこのデータをデータ プロダクトに組み込んで、アクセスしやすくし、他のシステムのデータ セットを統合できます。