データ レイクとデータ ウェアハウス

多くの組織は、過去数年間にわたってデータの統合や変換に関する戦略を確立してきたか、現在そのような活動に積極的に取り組んでいます。 これらの戦略は、多くの場合、サイロ化されたデータ システムの解消、統合された迅速なデータセット間分析の実現、そしてデータ量と複雑性の増大に対応して大規模に効果的に作業する必要性など、複数の目的が重なり合う中で推進されています。

この変革を支援するために、データ レイク テクノロジーとデータ ウェアハウス テクノロジーという 2 つのカテゴリーの技術が、併用されることも含めて導入されることがよくあります。 データ レイクとデータ ウェアハウスのテクノロジーは混同されることが多く、非公式な議論では混同されることもありますが、概念レベルと実装レベルの両方で、エンタープライズ情報システムにおいて異なる目的に使用され、異なる役割を果たします。 このページでは、これらのテクノロジを一般的レベル、ベンダー レベル、および製品に依存しないレベルで説明し、ArcGIS システムの視点からこれらのテクノロジーを利用するための Esri の戦略的アプローチについて紹介します。

データ レイク

データ レイクの定義や構成はさまざまですが、一般的な概念として、データ レイクはさまざまなタイプの個々のデータ アイテム (ファイル) の一元化されたリポジトリーであり、これらのファイル間でのインデックス作成、カタログ化、および分析の実行を可能にする 1 つの大規模でスケーラブルなストレージ システムに保存されます。 データは、構造化されたものもあればされていないものもあり、さまざまなファイル形式で保存でき、受信データ ストリームまたはそのデータを作成する他のシステムに従って整理できます。 その後、データ レイク プロバイダーがソフトウェアを通じて公開するツールと機能を使用して、データがアクセス、視覚化、分析されます。

たとえば、組織はデータ レイクを使用して、車両の位置、速度、方向に関する個々の時間ごとの軌跡を表す数千個の CSV ファイルを格納できます。 データレイク ソフトウェアは、これらの数千個のファイルに対してバッチ分析を実行して、速度が一定量を超えたシナリオを抽出したり、頻繁に停止が発生する場所の傾向を検出したりすることをサポートしている場合があります。 従来のデータ システムでは、これらの多くのファイルを 1 つのデータセットに統合してアクセスできるようにする必要がありましたが、データ レイクを使用すると、このクエリーと分析の処理を膨大なデータのプール全体で大規模に実行できます。 同じデータ レイクでは、同じ組織が、ファイルベースのアーカイブ形式に基づいて顧客プロファイルと販売データをまとめた異なる形式のデータを格納する場合があります。これにより、以前の活動をアクティブな注文または顧客のライブ トランザクション データベースに関連付けて活用できます。

ArcGIS でのデータ レイクの操作

データ レイクは、主に ArcGIS から分析的な問いを行うためのデータ ソースとしてアクセスされ、その結果は空間インターフェイスまたはマップベースのインターフェイスで表示されます。 これらのストレージ システムには通常、同様の構造のファイルに非常に大きなデータ コレクションが含まれているため、このデータを操作する過程では、多くの場合、コンテンツを要約してから、地理空間解析を実行したり、これらのデータセットを他の空間レイヤーまたは非空間レイヤーと比較したりして、個々の分析上の疑問を解決します。 一般に、これらの解析は処理集約型であるため、ワークフローは通常、次の複数の手順で構成されます。

  1. 多くの場合、データのサブセットまたは単一のサンプル ファイルまたはデータセットを使用して、分析の質問を慎重に設計または定義します。 非常に大きなデータ レイヤーに対して実行する場合は、この分析を可能な限り最適化し、出力列とデータを可能な限り減らして効率を高めます。
  2. データ レイクまたは Apache Spark などの外部処理システムによって提供されるインターフェイスを使用して分析を実行します。 結果は、多くの場合、そのインターフェイス内のメモリー内データフレームまたはデータセットに返されます。
  3. 要約された分析結果を表形式または空間レイヤーとして表示して、分析の質問に対する回答を確認します。 必要に応じて、CSV ファイルを公開するか、ArcGIS ホスト フィーチャ レイヤーを作成するか、結果を別の API またはシステムにプッシュすることで、結果を別の形式またはリポジトリーに保持します。

データ レイクは、ArcGIS Pro からクラウド接続ファイルを介してアクセスされる画像データセットやラスター ファイルのリポジトリーとして、またはモザイク データセットの一部としても使用できます。 データ レイクの画像はモザイク データセットに追加し、解析のソースとして、イメージ サービスの公開に使用できます。それらの解析は、ラスター解析によって実行され、ArcGIS Pro で表示されて、ジオプロセシング、解析、またはレンダリング ワークフローで使用されます。

ArcGIS を使用したデータ レイク ワークフローの例には、次のようなものがあります。

  • ArcGIS GeoAnalytics Engine または ArcGIS Pro の ArcGIS GeoAnalytics を使用して、複数年にわたって収集された鳥の位置情報を含む数千個の CSV ファイル全体に対しホット スポット解析を実行することができます。
  • 環境科学者として、ArcGIS Python API を使用して、[インシデントの検出 (Detect Incidents)] や [時空間キューブの作成 (Create Space Time Cube)] などのツールを使用して、数百万個の静的センサー読み取りのデータセットにおいて、全国におけるオゾン濃度が高い時間帯と場所を特定できます。

データ ウェアハウス

データ ウェアハウスは、設計、定義、構成が異なる場合がある、別のタイプのストレージ システムです。 一般的な概念としては、データ ウェアハウスはリレーショナル データベース管理システムに大変似ており、データセット間のクエリー、分析、集計の機能を備えた大規模な構造化データセットを保存できます。 データ ウェアハウスは、対応可能なデータ規模、実行可能な分析の種類や形式、処理速度の点で、従来のリレーショナル データベース システムとは異なります。

また、データ ウェアハウスは、よりクラウドネイティブな構成で構築されることが多く、データ ウェアハウス テクノロジーを構築する企業が管理するシステムにクライアントが接続し、そのプロバイダーがホストおよび管理しているコンピューティング容量とストレージを使用して接続する Software-as-a-Service モデルで提供されることもよくあります。 データ ウェアハウスのもう 1 つの一般的な要素として、スター モデル、ディメンション データ モデル、またはその他の同様の概念などの非リレーショナル データ モデルの使用が挙げられます。

ArcGIS でのデータ ウェアハウスの操作

ArcGIS でデータ ウェアハウスを操作する方法には、いくつかの形式があります。 最も一般的な形式は、ArcGIS Pro からデータ ウェアハウスへの接続から始まり、テーブル、ビュー、またはデータセットに対してクエリーを実行する形式です。 これは、クエリー レイヤー (ArcGIS Pro のレイヤー タイプで、サポートされているリレーショナル データベース管理システムまたはクラウド データ ウェアハウスに対してユーザー定義の SQL を実行できるレイヤー) を通じて作成されます。 サポートされているデータベースとクラウド データ ウェアハウスのリストについては、ArcGIS Pro のドキュメントをご参照ください。

クエリー レイヤーは、データベースから結果をテーブルとして返し、ArcGIS で認識される空間列が含まれている場合はマップ上に表示でき、視覚化、解析への入力、または地図作成の入力として使用できます。 このレイヤーはウェアハウスへのライブ接続であるため、マップ範囲が変更されるたびに新しいクエリーが送信され、更新されたソース データや再計算された結果、または単に新しい空間範囲を反映した新しい行セットが返されます。

Web ベースのアクセスが必要な場合、このクエリー レイヤーをダイナミック マップ サービスとして ArcGIS GIS Server サイトに公開することで、ArcGIS Pro マップのシンボルまたは定義をサービス構成に引き継がれます。その後、ユーザー リクエストごとに ArcGIS Server からデータ ウェアハウスへの更新済み SQL クエリーがトリガーされます。

データ ウェアハウスは、大規模なクエリー、分析クエリー、またはサマリー クエリー用に最適化されているため、データ所有者は「過去 24 時間の店舗で行われた数百万件の取引における各製品カテゴリーの平均購入規模はどれくらいだったか」といった問いの答えが得られます。このようなクエリーは通常、定期的に実行され、その結果は、ダッシュボードやデータ サマリー、チャートで使用され、定期的に更新されるまで表示され続けます。 データ ウェアハウスは、データ アナリストまたはデータ サイエンティストによる、より反復的な探索的解析にも使用でき、通常は要約統計情報またはレポートを定義してから再利用するためにも使用できます。

このため、データ ウェアハウスに接続する ArcGIS のクエリー レイヤーは、特定のトランザクション行のセット (24 時間内のすべての 100 万件のトランザクションのリストなど) ではなく、このような解析の結果に対し_最も頻繁に_クエリーを実行する必要があります。 データ ウェアハウスでは、機能的には行ごとにクエリーを実行できますが、この種のトランザクション対話操作に合わせて最適化されているわけではなく、マップに表示するために 100 万行に対しクエリーを実行しようとするなど、負荷が高くなることにつながります。その結果、要求されたすべての行を返す (および表示する) のに 5 分かかるなど、パフォーマンスに影響を与えることがあります。

データ ウェアハウスを基盤とするクエリー レイヤーが ArcGIS Enterprise に公開されると、特定のプロバイダーに対して ArcGIS によって追加のパフォーマンス最適化が行わることがあります。 ArcGIS は、クラウド データ ウェアハウスを使用して、特にコンピューティングの総消費量に基づいてコストを課すことができる AWS Redshift、Google BigQuery、Snowflake データベースに対しては、クエリーの効率的な処理やコンピューティング リソースの使用を最適化する追加ロジックを導入しました。 ArcGIS は、公開時に (必要に応じて) ソース データ ウェアハウスにマテリアライズド ビューを自動作成することで、パフォーマンスを向上させ、クエリーの全体的なコストを節約できます。 別のオプションとして、データのコピーを公開時に ArcGIS Data Store に移動し、公開者が設定したスケジュールで定期的に最新状態に保たれる「スナップショット」モードがあります。これにより、GIS システムは常に最新の結果セットを保持しますが、比較的遅いクエリーがソース データ ウェアハウスに継続的に送信されることはありません。

データ ウェアハウスとの統合方法は他にもありますが、次のような方法はあまり一般的ではありません。

  • ETL スタイルの統合: データ ウェアハウスのクエリーまたはビューの結果が別のデータ形式にコピーされるか、ホスト フィーチャ レイヤー ビューまたはエンタープライズ ジオデータベース フィーチャクラスとしてエンタープライズ GIS システムに定期的に統合されます。
  • API スタイルの統合: ArcGIS Web アプリケーションやクライアント アプリケーションが Data Warehouse の HTTP エンドポイントにクエリーを実行して結果や値を返すことができます。 これは、結果からクライアント側のフィーチャ レイヤーまたはグラフィックス レイヤーを作成できる ArcGIS Maps SDK で可能な場合があります。
  • どちらのシナリオでも、認証、データ更新頻度、アクセス制御は、考慮すべき関連する議論および要件です。
Top