多くの組織は、過去数年間にわたってデータの統合や変換に関する戦略を確立してきたか、現在そのような活動に積極的に取り組んでいます。 これらの戦略は、多くの場合、サイロ化されたデータ システムの解消、統合された迅速なデータセット間分析の実現、そしてデータ量と複雑性の増大に対応して大規模に効果的に作業する必要性など、複数の目的が重なり合う中で推進されています。
この変革を支援するために、データ レイク テクノロジーとデータ ウェアハウス テクノロジーという 2 つのカテゴリーの技術が、併用されることも含めて導入されることがよくあります。 データ レイクとデータ ウェアハウスのテクノロジーは混同されることが多く、非公式な議論では混同されることもありますが、概念レベルと実装レベルの両方で、エンタープライズ情報システムにおいて異なる目的に使用され、異なる役割を果たします。 このページでは、これらのテクノロジを一般的レベル、ベンダー レベル、および製品に依存しないレベルで説明し、ArcGIS システムの視点からこれらのテクノロジーを利用するための Esri の戦略的アプローチについて紹介します。
ArcGIS Online は、ArcGIS Data Pipelines の入力コネクターを通じてデータ ウェアハウスへの接続をサポートします。 ArcGIS Enterprise ユーザーは、ArcGIS Pro を通じて公開されたクエリー レイヤーを通じてデータ ウェアハウスに接続できます。 ArcGIS Pro ユーザーは、サポートされているデータ ウェアハウスにクエリーレイヤーとして接続できるほか、ArcGIS Enterprise から公開されたマップ サービスも利用できます。 ArcGIS Pro 向けの ArcGIS Data Interoperability エクステンションには、データ ウェアハウス システムに対応するリーダーとライターも含まれています。
ArcGIS Online は、サポートされているオブジェクト ストレージ プロバイダーを使用するデータ レイクへの接続に対応しており、parquet などの一般的なデータ レイクのデータ形式も利用できます。 Data Pipelines はデータ レイクでのバッチ解析クエリーをサポートしていません。 ArcGIS Enterprise 向けの ArcGIS Data Pipelines は同様の機能を提供しており、ArcGIS Enterprise はデータ レイク システムに保存されたデータセットを参照するイメージ サービスの公開もサポートしています。 ArcGIS Pro は、フォルダー ストレージへのマルチファイル フィーチャ接続や、データ レイクに接続してラスター画像にアクセスしたり、.crf ラスター解析結果を保存できるクラウド接続ファイルを通じて、データ レイクへの接続をサポートしています。
| 機能 | ArcGIS Online | ArcGIS Enterprise | ArcGIS Location Platform | ArcGIS Pro |
|---|---|---|---|---|
| データ ウェアハウス接続 | N/A | |||
| データ レイク接続 | N/A |
フルサポート 一部サポート
データ レイクの定義や構成はさまざまですが、一般的な概念として、データ レイクはさまざまなタイプの個々のデータ アイテム (ファイル) の一元化されたリポジトリーであり、これらのファイル間でのインデックス作成、カタログ化、および分析の実行を可能にする 1 つの大規模でスケーラブルなストレージ システムに保存されます。 データは、構造化されたものもあればされていないものもあり、さまざまなファイル形式で保存でき、受信データ ストリームまたはそのデータを作成する他のシステムに従って整理できます。 その後、データ レイク プロバイダーがソフトウェアを通じて公開するツールと機能を使用して、データがアクセス、視覚化、分析されます。
たとえば、組織はデータ レイクを使用して、車両の位置、速度、方向に関する個々の時間ごとの軌跡を表す数千個の CSV ファイルを格納できます。 データレイク ソフトウェアは、これらの数千個のファイルに対してバッチ分析を実行して、速度が一定量を超えたシナリオを抽出したり、頻繁に停止が発生する場所の傾向を検出したりすることをサポートしている場合があります。 従来のデータ システムでは、これらの多くのファイルを 1 つのデータセットに統合してアクセスできるようにする必要がありましたが、データ レイクを使用すると、このクエリーと分析の処理を膨大なデータのプール全体で大規模に実行できます。 同じデータ レイクでは、同じ組織が、ファイルベースのアーカイブ形式に基づいて顧客プロファイルと販売データをまとめた異なる形式のデータを格納する場合があります。これにより、以前の活動をアクティブな注文または顧客のライブ トランザクション データベースに関連付けて活用できます。
データ レイクは、主に ArcGIS から分析的な問いを行うためのデータ ソースとしてアクセスされ、その結果は空間インターフェイスまたはマップベースのインターフェイスで表示されます。 これらのストレージ システムには通常、同様の構造のファイルに非常に大きなデータ コレクションが含まれているため、このデータを操作する過程では、多くの場合、コンテンツを要約してから、地理空間解析を実行したり、これらのデータセットを他の空間レイヤーまたは非空間レイヤーと比較したりして、個々の分析上の疑問を解決します。 一般に、これらの解析は処理集約型であるため、ワークフローは通常、次の複数の手順で構成されます。
多くの場合、データのサブセットまたは単一のサンプル ファイルまたはデータセットを使用して、分析の質問を慎重に設計または定義します。 非常に大きなデータ レイヤーに対して実行する場合は、この分析を可能な限り最適化し、出力列とデータを可能な限り減らして効率を高めます。
データ レイクまたは Apache Spark などの外部処理システムによって提供されるインターフェイスを使用して分析を実行します。 結果は、多くの場合、そのインターフェイス内のメモリー内データフレームまたはデータセットに返されます。
要約された分析結果を表形式または空間レイヤーとして表示して、分析の質問に対する回答を確認します。 必要に応じて、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 Pro からデータ ウェアハウスへの接続から始まり、テーブルまたはビューに対してクエリーを実行する形式です。 これは、クエリー レイヤー (サポートされているデータベースに対して、ユーザー定義の SQL を実行できる ArcGIS Pro のレイヤー タイプ) を通じて作成されます。 サポートされているデータベースとクラウド データ ウェアハウスのリストについては、ArcGIS Pro のドキュメントをご参照ください。
クエリー レイヤーは、データベースから結果をテーブルとして返し、ArcGIS で認識される空間列が含まれている場合はマップ上に表示でき、視覚化、解析への入力、または地図作成の入力として使用できます。 このレイヤーはウェアハウスへのライブ接続であるため、マップ範囲が変更されるたびに新しいクエリーが送信され、更新されたソース データや再計算された結果、または単に新しい空間範囲を反映した新しい行セットが返されます。
Web ベースのアクセスが必要な場合、このクエリー レイヤーをダイナミック マップ サービスとして ArcGIS Enterprise に公開できます。 このサービスでは、ArcGIS Pro マップのシンボルまたは定義はサービス構成に引き継がれます。 その後、ユーザー リクエストごとに ArcGIS Enterprise からデータ ウェアハウスへの更新済み SQL クエリーがトリガーされます。 マップ サービスは、クライアントサイドの視覚化とクエリーのために、フィーチャ レイヤーとしてアクセスすることもできます。
データ ウェアハウスは、大規模なクエリー、分析クエリー、またはサマリー クエリー用に最適化されているため、データ所有者は「過去 24 時間の店舗で行われた数百万件の取引における各製品カテゴリーの平均購入規模はどれくらいだったか」といった問いの答えが得られます。このようなクエリーは通常、定期的に実行され、その結果は、ダッシュボードやデータ サマリー、チャートで使用され、定期的に更新されるまで表示され続けます。 データ ウェアハウスは、データ アナリストまたはデータ サイエンティストによる、より反復的な探索的解析にも使用でき、通常は要約統計情報またはレポートを定義してから再利用するためにも使用できます。
このため、データ ウェアハウスに接続する ArcGIS のクエリー レイヤーは、特定のトランザクション行のセット (24 時間内のすべての 100 万件のトランザクションのリストなど) ではなく、このような解析の結果に対し最も頻繁にクエリーを実行する必要があります。 データ ウェアハウスでは、機能的には行ごとにクエリーを実行できますが、この種のトランザクション対話操作に合わせて最適化されているわけではなく、マップに表示するために 100 万行に対しクエリーを実行しようとするなど、負荷が高くなることにつながります。その結果、要求されたすべての行を返す (および表示する) のに長時間かかるなど、パフォーマンスに影響を与えることがあります。
データに対して直接実行されるクエリーの数を減らすことで、クエリー レイヤーをさらに最適化できます。 クエリーの実行回数を減らすと、クラウド データ ウェアハウスのコストを削減できます。これらのサービスでは、一般的に、使用した計算リソースに基づいてコストが発生するからです。 クラウド データ ウェアハウスのデータからレイヤーを公開する際、ArcGIS ではオプションでマテリアライズド ビューを作成できます。 基盤となるデータが更新された後にマテリアライズド ビューをリフレッシュすることで、それらの更新内容をビューに反映させることができます。 マテリアライズド ビューを使うと、データにアクセスするたびにではなく、ビューをリフレッシュした時にだけクラウド データ ウェアハウスの計算コストが発生します。 事前に計算されたマテリアライズド ビューを使うことは、データに対して直接クエリーを実行するよりも通常は高速です。 マテリアライズド ビューは、更新頻度が低いデータセットや、多くの計算リソースを必要とする複雑なクエリーに特に有用です。
クラウド データ ウェアハウスへのクエリー数を減らすもう 1 つの方法は、クエリー レイヤーを公開する際にデータのスナップショットを作成することです。 スナップショットは、クラウド データ ウェアハウスから ArcGIS Enterprise にクエリー結果セットをコピーします。 レイヤーはクラウド データ ウェアハウスに対してクエリーを実行する代わりにこのコピーを参照するため、一般的にレイヤーのパフォーマンスが向上します。 スナップショットは、基盤となるデータが更新されても、自動的に更新されません。 ArcGIS Enterprise では、必要に応じてスナップショットを更新したり、特定の間隔で更新をスケジュールできます。
データ ウェアハウスとの統合方法は他にもありますが、次のような方法はあまり一般的ではありません。
ETL スタイルの統合: データ ウェアハウスのクエリーまたはビューの結果が定期的に ArcGIS にコピーされます。 このような統合では、ArcGIS Data Pipelines、ArcGIS Python ライブラリー、ArcGIS Notebooks、または ArcGIS Data Interoperability エクステンションを用いて、この作業を行うことがあります。 ETL スタイルの統合の利点は、データ ウェアハウスのデータを、ホスト フィーチャ レイヤーまたはテーブルとして ArcGIS Online に取り込める点です。
API スタイルの統合: ArcGIS Web アプリケーションやクライアント アプリケーションがデータ ウェアハウスにクエリーを実行して結果や値を返すことができます。 これは、結果からクライアント側のフィーチャ レイヤーまたはグラフィックス レイヤーを作成できる ArcGIS Maps SDK で可能な場合があります。 ArcGIS Enterprise SDK は、フィーチャ サービス用のカスタム データ フィードを作成するためにも利用できます。
どちらのシナリオでも、認証、データ更新頻度、アクセス制御は、考慮すべき関連する議論および要件です。