運用データストア（ODS：Operational Data Store）は、複数のソースからデータを抽出して処理するために、最終的なストレージ先へデータを送信する前に、データ処理のための一時的なストレージの場所として機能します。データは構造化または非構造化として保存できますが、抽出して、最終的なデータ・ウェアハウスの場所の形式に変換できる方法で保存する必要があります。ODS アーキテクチャは通常、ETL（抽出、変換、ロード）および ELT（抽出、ロード、変換）データ・パイプライン用に構築されています。
ODS とは？
運用データストアは、運用レポートと分析に使用されるリアルタイムまたはニア・リアルタイムのデータのための集中型リポジトリです。大規模なデータ・パイプラインでは、ODS は、データ・フォーマット、重複排除、最終処理のためのステージング・エリアとして機能し、データがデータ・ウェアハウスに送信されます。例えば、大規模な不動産企業は、複数の異なるウェブサイトからデータを抽出し、顧客のために分析を行う場合があります。抽出プロセス中、データ・パイプラインは抽出された情報を ODS に格納し、自動スクリプトがデータのフォーマット、整理、重複排除を可能にします。ETL がデータを処理すると、データ・ウェアハウスに送信され、そこで不動産アプリケーションがクエリを発行できます。
ODS は構造化データと非構造化データに使用されますが、リレーショナル・データベースを扱うデータ・パイプラインに特に役立ちます。ODS は、ファイルやスクレイピングされた Web ページからの非構造化データを保存する可能性があり、ETL は、変換ステップの前に収集したデータを処理するためにそれを使用します。ODS を使用しないと、レコードのフォーマットに失敗するとデータが失われます。トランスフォーメーションに失敗したレコードは、追加の処理や人間によるレビューのために ODS に残ります。
ODS の目的
大企業や機械学習アプリケーションでは、ETL 処理中に複数の場所からデータが取得されることがよくあります。データ・パイプラインは、ネットワーク・ソースからファイル、API エンドポイントからデータ、Web アプリケーションからスクレイピングされたデータを引き出す可能性があります。データを収集するために使用されるスクリプトは、データを処理できる ODS にダンプします。ODS の目的は、データ抽出スクリプトが、処理前に収集した情報を保存する場所を確保できるようにすることです。
ODS は、特に ODS で収集されたデータが複数の場所で使用されている場合に、リアルタイムのダッシュボードやアプリケーションの重要な部分です。例えば、ODS には、ETL プロセスがデータ・ウェアハウスに送信する前にフォーマットする収集されたデータが含まれており、分析は財務予測に使用できます。ODS は、エンドユーザー・アプリケーションにデータを提供する前の中間データ収集サービスです。
ODS のメリット
エンタープライズ・ビジネスには、より良いデータ処理と効率的な ETL パイプラインのための ODS が必要です。ETL スクリプトにはデータを保存する場所があるため、リアルタイム・アプリケーションには、迅速な処理、人工知能の計算、機械学習の取り込みのためにデータを取得する場所もあります。ODS がない場合、ETL データ・パイプラインは、データベースの制約にあわないデータや、データ・ウェアハウスに格納される前に処理できないデータをドロップする可能性があります。
さらに、次のようなメリットがあります。
- 異なるフォーマットと組織によるさまざまなデータソースの便利な収集
- 必要に応じて、問題の特定やデータの再処理に使用できる、さまざまなソースから収集された全てのレコードの完全なスナップショット
- 分析と機械学習のための非構造化データ・ストレージ機能
- クラウド ODS システムは、場所を問わず、ユーザー、アプリケーション、管理者、第三者ベンダーが利用できるように構成
- 全ての内部アプリケーションのデータを収集する場所を一元化し、重要なレポート全体のデータの正確性と整合性を向上
ODS の実装
ODS はデータ・パイプラインや ETL 処理の一部であるため、設計やデータ・アーキテクチャに含めなければなりません。収集されたデータの種類は、ODS の大きな決定要因です。非構造化データには NoSQL データベースが必要です。リレーショナル・データベースは、テーブルの制約に適合しないデータを拒否します。
データベース・プラットフォームを選択したら、ODS をオンプレミスまたはクラウドのどちらでホストするかを決定する必要があります。オンプレミスのデータベースは、一般には利用できない内部アプリケーションに適していますが、ETL スクリプトは、データベースや内部データ・ウェアハウスに到達できる必要があります。クラウド・データベースは、本番クラウド・アプリケーション・データベースに接続するように構成できるパブリック・クラウド・アプリケーションに有益です。
リアルタイム・アプリケーションには高速性と計算能力が必要です。データベース・アーキテクチャに、大量のデータを処理する帯域幅、計算能力、メモリ、ストレージ容量があることを確認してください。必要なストレージ容量を特定するために、データ・コレクションを試用することは理にかなっているかもしれませんが、スケーラビリティのために追加のストレージを許可することを忘れないでください。スナップショットは、最終的に別のバックアップ・データベースに移動されたり、データの経過後に削除されたりして、もはや関連性がなくなる可能性があります。
ODS とデータ・ウェアハウス
データ・ウェアハウスは、整備されフォーマットされたデータの最終目的地です。ETL 手順の ODS では、構造化、重複排除、検証が行われるまで未加工データが保存されます。データの整理方法や保存場所は、個々のビジネス・ルールによって異なります。データ・ウェアハウス内のリレーショナル・データベースには、格納前にフォーマットする方法で厳密なルールを持つ構造化データが必要です。
ODS テーブルは、常に新しいデータで更新され、リアルタイムのデータ処理やユーザー・アプリケーションに使用できます。構造化データと非構造化データは ODS テーブルに保存できますが、多くのシステムでは非構造化データを使用しているため、データ収集の制約が少なくなります。制約やフィルタリングは、データ・ウェアハウスへのインポート・プロセス中に適用できます。
クエリは、データがより永続的なデータ・ウェアハウス・テーブルから実行する必要があります。データ・ウェアハウスからデータを削除するのは珍しいことです。アーカイブすることもできますが、データを完全に削除することは珍しいことです。ODS データは、はるかに不安定です。重複したデータは取り除かれ、古いデータや破損したデータは削除される可能性があります。
まとめ
データ・ウェアハウスのためにさまざまなソースからデータを収集する場合、ODS 暫定アーキテクチャは、異なるビジネス・ルールを持つ複数のアプリケーションをサポートするデータ・パイプラインにとって有益です。データを構造化形式と非構造化形式に変換することで、機械学習、クエリ、レポート、分析ダッシュボード、データ・ウェアハウスを使用するその他のフロントエンド・アプリケーションをサポートできます。
ピュア・ストレージのクラウド・ソリューションは、データベースの拡張を可能にするために、AWS、Azure、その他のプロバイダによる ODS 接続をサポートしています。ETL プロシージャは、スケーラブルなデータベース・サービスに高速にアクセスし、リアルタイム処理と高速クエリをサポートします。
