QuantumLeap

FIWARE Core Context Management stackoverflow

概要

QuantumLeap は、NGSI v2 時空間データを保存、クエリ、および 取得するための REST サービスです。QuantumLeap は、NGSI の半構造化データ を表形式に変換して time-series database に保存し、各データベース のレコードを時間インデックスに関連付け、NGSI データに存在する場合は 地球上の場所に関連付けます。REST クライアントは、時間範囲と空間演算子を 使用してエンティティ・セットをフィルタリングすることにより、NGSI エンティティを取得できます。クライアントの観点から、これらのクエリは データベースのテーブルではなく NGSI エンティティで定義されることに 注意してください。ただし、REST インターフェイスを介して使用できるクエリ 機能は非常に基本的であり、最も複雑なクエリでは通常、クライアントが データベースを直接使用する必要があります。

QuantumLeap が実装する NGSI-TSDB と呼ばれるREST API specification は、NGSI 仕様自体に可能な限り近い、NGSI エンティティの時系列のストレージ、クエリ、および取得にデータベースに 依存しない REST インターフェイスを提供することを目的として定義されて います。したがって、NGSI-TSDB は、時系列データにアクセスするための統一 された、FIWARE 開発者にとって使い慣れた、メカニズムを提供し、QuantumLeap などのサービスを実装して複数のデータベース・バックエンドを透過的に サポートします。実際、現在 QuantumLeap はバックエンド・データベースとして CrateDBTimescale の両方をサポートしています。

STH Comet との関係

QuantumLeap と FIWARE STH Comet は同様の目標を共有しますが、 Comet は複数のデータベース・バックエンドをサポートせず (MongoDB のみが利用可能)、NGSI v2 もサポートしません。Comet 自体は素晴らしい ソフトウェアですが、開発のきっかけとなったニーズと仮定のいくつかはもはや 最新のものではありません。QuantumLeap は、特定のデータベース・バックエンド にコミットせずに、FIWARE エコシステムで履歴データを利用できる代替方法の 調査として始まりました。

オペレーション

通常、QuantumLeap は、Context Broker, Orion で事前に設定された NGSI 通知を介して、FIWARE IoT Agent レイヤーから間接的に NGSI エンティティ の形式で IoT データを取得します。(読者は、NGSI specificationNotification Messages および Subscriptions セクションで説明されて いる NGSI パブリッシュ/サブスクライブのメカニズムに精通していると想定 します) 前述のように、着信した NGSI エンティティはデータベースに変換され、 構成された時系列データベースのバックエンドの1つ (通常はデータベース・ クラスタ) に記録および保存されます。しばしば、QuantumLeap がデータベースに 保存する時系列データを視覚化するために、Grafana などの視覚化 ツールもデプロイされます。以下の図は、一般的な QuantumLeap デプロイ・ シナリオでのこれらのシステム間の関係と相互作用を示しています。

QL Architecture

QuantumLeap が Orion からデータを受信するために、クライアントは Orion でサブスクリプションを作成し、変更が発生したときに通知するエンティティを 指定します。この図は、クライアントが QuantumLeap (1) で サブスクリプションを直接作成していることを示しています。これは、 クライアントのサブスクリプションを Orion に単に転送する QuantumLeap REST API の便利なエンドポイントです。(サブスクリプションの設定の詳細については、 QuantumLeap マニュアルの Orion Subscription セクションを ご覧ください。)

この時点から、IoT レイヤーのエージェント が Context Broker (2) にデータをプッシュするとき、データがクライアントのサブスクリプション によって特定されたエンティティに関係する場合、Orion は、NGSI エンティティを QuantumLeap の 通知のエンドポイントに (3) に POST することに より、データを QuantumLeap に転送します。

QuantumLeap の Reporter コンポーネントは、POST されたデータを解析および 検証します。さらに、ジオコーディングが設定されている場合、ReporterGeocoder コンポーネントを呼び出して、通知されたエンティティの位置表現を 調整します。これには、OpenStreetMap (OSM) で地理情報を検索することが 含まれます 最後に、Reporter は、検証および調整された NGSI エンティティを Translator コンポーネントに渡します。Translator は、NGSI エンティティを表形式に変換し、それらを時系列レコードとしてデータベースに 保持します。サポートされている各データベースバックエンドに対応する Translator コンポーネントがあります。以下のセクションを参照してください。 設定 に応じて、Reporter は使用する Translator を 選択します。

クライアントが REST API にクエリして NGSI エンティティ (4) を取得すると、 Reporter および Translator が相互作用して、Web クエリを空間および 時間句を含む SQL クエリに変換し、データベースを取得します。それらを記録し、 最終的にクライアントに返される NSGI エンティティの時系列に変換します。 前述のように、REST インターフェイスで使用できるクエリ機能は非常に基本的です。 QuantumLeap は、時間範囲、NGSI 仕様で定義された地理的クエリ、 および平均などの単純な集計関数によるフィルタリングをサポートします。 それ以外に、QuantumLeap は履歴レコードの削除もサポートしていますが、 現時点では NGSI-TSDB 仕様を完全に実装していないことに注意してください。 詳細については、REST API 仕様を参照してください。

最後に、図は、Webクライアント(5) の時系列を視覚化するために、 データベースに直接クエリする Grafana を示しています。原則として、 データベースの代わりに QuantumLeap REST API をクエリする Grafana プラグインを 開発できます。これにより、QuantumLeap 内部から可視化ツールが保護されます。 実際に、(それほど遠くない!) 将来、そのようなプラグインを開発する計画が あります。

データベース・バックエンド

QuantumLeap 設計の指針の1つは、複数の時系列データベースを使用できることです。 この設計上の選択は、現在の状況によってはデータベース製品が他の製品よりも 適している可能性があるという事実によって正当化されます。現在、QuantumLeap は CrateDBTimescale の両方で使用できます。 [InfluxDB][influx] および RethinkDB の実験的サポートも利用 できますが、これら2つのバックエンドの開発が停滞しているため、現時点では 使用できません。

このマニュアルの データベースの選択 セクションでは、 利用可能なデータベース・バックエンドのいずれかを使用するように QuantumLeap を構成する方法について説明しています。

CrateDB バックエンド

CrateDB はデフォルトのバックエンドです。 containerisation に適した shared-nothing アーキテクチャに より、スケーリングが容易です。そのため、Kubernetes などを使用して、 コンテナ化された CrateDB データベース・クラスタを比較的簡単に管理できます。 さらに、CrateDB は SQL を使用してデータをクエリし、一時的 および地理的クエリ の組み込み拡張機能を使用します。また、 Grafana には、CrateDB に保存されている時系列を視覚化するために使用できる プラグイン が付属しています。

Timescale バックエンド

Timescale は、NGSI エンティティの時系列を格納するバックエンド として QuantumLeap で使用できる別の時系列データベースです。実際、 QuantumLeap は、地理的特徴 (GeoJSON または NGSI Simple Location Format としてエンコード)、構造化タイプ、配列など、NGSI エンティティの Timescale への保存を完全にサポートしています。

QuantumLeap は、既存の notify 通知エンドポイントを使用して NGSI エンティティを Timescale に保存します。Timescale のバックエンドは、 PostgreSQL で構成され、Timescale と PostGIS 拡張の両方が有効になっています :

-------------------------
| Timescale     PostGIS |          ---------------
| --------------------- |  <-----  | QuantumLeap |-----O notify
|       Postgres        |          ---------------
-------------------------

PostgreSQL は確固たる、テスト済みのオープンソース・データベースであり、その PostGIS 拡張機能は高度な空間機能の優れたサポートを提供しますが、Timescale 拡張機能は時系列データをかなり強力にサポートします。NGSI エンティティを 表形式に変換するメカニズムは、いくつかの改善を除いて、Crate バックエンドと ほぼ同じです。

  • NGSI 配列は、Crate バックエンドの文字列のフラット配列ではなく、 インデックス化およびクエリ可能な JSONとして保存されます
  • GeoJSON および NGSI Simple Location Format 属性は、インデックスおよび クエリが可能な空間データとして保存されます。Crate バックエンドでは、 空間属性の完全なサポートはまだ不完全です

QuantumLeap ソースベースの test_timescale_insert.py ファイルには、 NGSI データが Timescale に保存される方法の非常に多くの例が含まれています。

注: データのクエリと取得

現時点では、QuantumLeap は、Crate バックエンドで利用可能な QuantumLeap REST API を介したデータのクエリまたは取得を実装していません。つまり、 現在のところ、データにアクセスする唯一の方法は、Timescale DB に直接クエリを 実行することです。ただし、今後の QuantumLeap メジャー・リリースでは、 REST API を介したデータのクエリと取得が計画されています。

関連情報

  • 管理者ガイドは、QuantumLeap をインストールして実行する方法 を説明しています
  • ユーザ・マニュアルでは、その使用方法と他の補完的なサービスへ の接続方法について詳しく説明しています
  • FIWARE Time Series は、QuantumLeap のセットアップと使用方法を学ぶ ための完全なステップ・バイ・ステップの実践的チュートリアルです
  • SmartSDK ガイド・ツアーには、FIWARE クラウドでの QuantumLeap の使用に関するセクションがあります