Things Cloud DataHubの操作方法

概要

Things Cloud DataHubは、Things Cloudのオペレーショナル ストアからデータを抽出して変換し、データレイクへオフロードするオフロード パイプラインを構成、管理、および実行する機能を提供します。

オフロードパイプラインを操作するには、設定または管理の権限が必要です。詳細については、Things Cloud DataHubの権限とロールの定義セクションを参照してください。

基本機能

オフロードページでは、オフロードの管理および監視タスクを実行します。

• オフロードするThings Cloudベースコレクションの選択
• オフロード構成の定義と検証
• オフロード構成の編集、複製、または削除
• オフロード構成のインポート/エクスポート
• オフロードの実行をスケジュールする、またはで手動トリガーする
• オフロード実行の履歴の表示する

オフロードの概要

オフロードページのメイン パネルには、すべてのパイプラインとその現在のステータスが表示されます。

アクション バーには、タスク名、説明、フィルター述語、追加の列、または UUID に検索文字列が含まれるすべてのオフロード構成を検索するための検索フィールドがあります。有効/無効フィルターを使用して、有効/無効の構成を表示/非表示にすることができます。 アクション バーには、オフロード用のコレクションの追加、構成とそのステータスのリストのリロード、および構成のインポート/エクスポートのためのボタンもあります。

アクション バーの下に、現在の構成のリストがあります。

オフロードリスト

各オフロード構成は、以下の情報を提供します。

有効化

トグルにより、現在のジョブの状態が表示され、オフロードジョブを有効または無効にすることができます。

ジョブ名

ジョブ名は、構成プロセスで定義されたタスク名を指します。ソートコントロールを使用して、ジョブ名でのソートが可能です。

ターゲットテーブル名

ターゲットテーブル名は、Dremioのターゲットテーブルを指し、このオフロードパイプラインによってオフロードされたデータをクエリできます。ソートコントロールを使用して、ターゲットテーブル名でのソートできます。

オフロードステータス

オフロードがまだ実行されていない場合、オフロードステータスは空です。実行中および完了した実行の場合、開始時間が表示され、スケジュールされた実行の場合はカレンダーアイコン 、手動トリガーされた実行の場合はユーザーアイコン が表示されます。実行中の実行については、経過時間も表示されます。完了した実行については、失敗/成功ステータス、オフロードされたレコード数、および実行時間が表示されます。実行中および完了した実行については、オフロードステータスをクリックすることで、ジョブ履歴内のその実行の詳細ビューに移動します。

ソートコントロールを使用して成功した/失敗したジョブでのソートが可能です。フィルターコントロールを使用して実行ステータスでのフィルタリングが可能です。

コンパクションステータス

コンパクションステータスは、オフロードがまだ実行されていない場合は空です。コンパクションが実行された場合、最新の実行のステータスが表示されます。これには実行時間と実行が成功したかどうかを示す成功または失敗のアイコンが含まれます。成功した実行の場合はランタイムも表示されます。ソートコントロールを使用して成功/失敗　したジョブでソートでき、フィルターコントロールを使用して実行ステータスでフィルタリングできます。コンパクションステータスは、管理権限を持つユーザーのみが利用できます。

追加情報

構成を展開すると、ジョブスケジュール、追加の列、およびフィルタ述語が表示され、追加情報も表示されます。これには、Dremio UI内でパイプラインの対象テーブルに移動するリンクが含まれており、テーブルの内容を直接調査できます。このリンクは、パイプラインが少なくとも一度実行された場合にのみ表示されます。

コンテキストメニュー

構成のコンテキストメニューには、次のセクションで詳細に説明されているオフロードプロセスを管理するためのコントロールがあります。

オフロードジョブの構成

以下のステップでは、オフロードパイプラインの設定方法を説明します。

オフロード構成の定義

オフロード構成を定義するには、オフロードコレクションをクリックして、主要なステップを案内するウィザードを開始します。

• オフロード構成の定義 {#defining-an-offloading-configuration}
  • コレクションの選択 {#select-collection}
  • ターゲットテーブルの構成 {#configure-target-table}
  • 追加の結果カラムを設定する {#set-additional-result-columns}
  • フィルター述語の設定 {#set-filter-predicate}
  • タスクの詳細を設定 {#set-task-details}
  • 追加の設定を構成し、構成を完了する {#configure-additional-settings}

ウィザードでは、構成プロセスを容易にするために、さまざまなステップの設定を事前に入力します。これらの設定は、必要に応じて変更できます。

コレクションの選択

ドロップダウンボックスで、次のThings Cloudベース コレクションのいずれかを選択します。

• アラーム
• イベント
• インベントリ
• メジャーメント

Things Cloud基本コレクションのオフロードでは、ベースコレクションごとにオフロードされるデフォルト属性の概要を確認できます。

次の構成ステップに進むには、次へをクリックします。オフロード構成をキャンセルするには、キャンセルをクリックします。

ターゲットテーブルの構成

オフロードするコレクションを選択したら、データ レイクでターゲット テーブルを指定する必要があります。ターゲットテーブル名は、データ レイク内のフォルダー名を示します。このフォルダは自動的に作成され、オフロードされたデータが保存されます。Dremioでは、このデータ レイク フォルダーを指す同じ名前のテーブルが作成されます。このテーブルは、対応するデータ レイク フォルダー、つまりオフロードされたデータをクエリするときに使用されます。ターゲット テーブル名は、次の構文規則に従う必要があります。

• 英数字で始まる必要があります。
• 英数字、アンダースコア (_)、ダッシュ (-) を使用できます。
• 各アンダースコアまたはダッシュの前には、英数字が必要です。
• 名前は 2 文字以上にする必要があります。

各パイプラインには、データ レイク内に独自のターゲット テーブルが必要です。つまり、オフロード構成ごとに個別のターゲット テーブル名を選択する必要があります。

アラーム、イベント、インベントリコレクションの場合、この手順ではターゲット テーブル名のみを指定する必要があります。

メジャーメントコレクションには、追加の設定が必要です。ターゲットテーブルレイアウトは、メジャーメントの保存方法を表します。基本コレクションのメジャーメントにはさまざまなタイプが含まれる場合があります。たとえば、あるコレクションには温度、湿度、気圧のメジャーメントが含まれている、などの場合です。レイアウトの選択に応じて、メジャーメントはターゲット テーブルに異なる方法で格納されます。

1つのメジャーメントタイプに対して1つのテーブル(デフォルト)というレイアウトは、1つの特定のタイプのメジャーメントのみを含むテーブルを作成します。他のタイプのメジャーメントは含まれていません。このレイアウトを選択する場合、オフロードされたメジャーメントが制限されるメジャーメントタイプを追加で指定する必要があります。既存のメジャーメンタイプを識別するために、Things Cloud DataHub は、初期データと最新データを含むデータのサブセットを自動的に検査します。メジャーメントタイプのドロップダウン ボックスに、これらの自動検出されたタイプが一覧表示されます。探している特定のタイプが検出されなかった場合は、このボックスに手動で入力できます。あるいは、ドロップダウン ボックスの横にある更新をクリックして、メジャーメントタイプの検出を手動で再トリガーすることもできます。この場合、パフォーマンスが集中するプロセスの可能性があるため、コレクションに最近挿入されたデータに予期されるメジャーメントタイプが存在することがわかっている場合にのみトリガーしてください。パフォーマンス上の理由から、このような更新は5分ごとにのみトリガーできます。

**1つのテーブル内のすべての測定タイプ (TrendMiner)**というレイアウトは、すべてのタイプのメジャーメントを含むテーブルを作成します。メジャーメントを区別するために、テーブルには各メジャーメントに対応するタイプをリストする列があります。このレイアウトは、TrendMiner が時系列分析のためにデータを使用できるように、データをデータ レイクにオフロードするユース ケース専用です。このレイアウトが選択されている場合、ターゲット テーブル名は、TrendMiner がデータ インポートに先とする固定の編集不可能な名前に設定されます。時系列データモデルが使用されている場合、TrendMinerモードはサポートされていません。

基本コレクションごとに、データ フィールドの既定のセットが派生します。このセットは、データ フィールドをキャプチャする列を使用して、ターゲット テーブルの既定のスキーマを定義します。セットはコレクションごとに固定されており、編集できません。デフォルトスキーマを表示を選択して、デフォルト 対応する名前とタイプとともにスキーマの列を表示します。

次へをクリックして、次の構成手順に進みます。終了するをクリックして、最終ステップに直接ジャンプします。関連する基本コレクションが空の場合、必要なスキーマ調査を防ぐために両方の手順が失敗します。このような場合、オフロード構成に進む前に、基本コレクションが空でないことを確認する必要があります。前へをクリックして、1つ前の構成手順に戻ります。オフロード構成ウィザードをキャンセルするには、キャンセルをクリックします。

追加の結果カラムを設定する

もしThings Cloudにデータを供給する際に追加のトップレベルフィールドを追加した場合、それらにアクセスしたい場合は、Things CloudDataHubクエリでそれらを取得するために、それらを追加の結果カラムとして設定することができます。追加の結果カラムを使用して、デフォルト スキーマの一部ではない基本コレクションのデータ フィールドをオフロードすることもできます。オプションで、追加の結果カラムを構成できます。TrendMinerでは、このオプションはサポートされていません。

自動検出されたカラム

構成プロセスを簡単にするために、Things Cloud DataHubは追加の結果カラムを自動検出します。基本コレクションのサンプルを使用して、Things Cloud DataHubは追加のトップレベルフィールドを検索し、それらを追加の結果カラムとして提供します。このような自動検出されたカラムをオフロードに含めるかどうかを指定できます。自動検出ロジックはサンプルに依存するため、追加したすべてのトップレベルフィールドがキャプチャされるわけではありません。カラムを手動で追加して、見逃したフィールドを含めることができます。

追加の結果カラムの構造

手動で構成されているか、自動検出されているかに関係なく、追加された各結果カラムには次のプロパティがあります。

• 選択済み: このチェックボックスを使用して、列をオフロード パイプラインに含めるかどうかを定義します。
• カラム名: カラム名は、カラムがターゲット テーブルで持つ名前です。カラムの名前は一意で、空でなく、少なくとも1つの空白以外の文字を含んでいる必要があります。
• 自動検出: このプロパティは、カラムが自動検出されたか、ユーザーによって手動で追加されたかを示します。
• ソース定義: ソース定義は、このカラムのデータがどのように見えるかを定義する実際のSQL式です。
• カラムの種類: カラムタイプは、カラムに含まれるデータの種類を定義します。たとえば、二重値の場合はDOUBLE、文字列の場合はVARCHARです。

追加の結果カラムの構成ステップに入ると、すべてのカラムとそのプロパティが表に表示され、行ごとに1つの追加の結果カラムが表示されます。右上にある自動検出された列を非表示チェックボックスを使用すると、自動検出されたカラムを表示するかしないかを選択できます。追加の各結果カラムの右側には、折りたたみボタンとコンテキストメニューアイコンが用意されています。折りたたみボタンを使用すると、カラムの詳細を展開/折りたたむことができます。詳細欄では、ソース定義とカラムのサンプル データを確認できます。追加の結果カラムのコンテキスト メニューには、カラムを編集、複製、削除するためのアクションがあります。カラム名は、名前フィールドをクリックして名前を変更し、フィールドの外で一度クリックすることで、インラインで編集することもできます。

テーブルの右上には、手動で結果カラムを追加するためのボタンがあります。

有効なオフロードパイプラインに対して結果カラムの追加ステップを入力した場合、つまりパイプラインがスケジュールされている場合は、カラムを変更することはできません。

結果カラムを追加する

結果カラムを追加する場合、カラムを定義するためのダイアログボックスが表示されます。ユニークなカラム名とソースの定義を指定する必要があります。ソースの定義に関して、最初のステップは、ソースの定義エディタでベースコレクションからフィールドを指定することです。その後、このフィールドのデータを必要に応じて調整するために、空白を削除したり、小数値を丸めたりするなどのSQL関数をオプションで適用できます。ソースの定義エディタは、コンテンツ補完と構文の強調表示をサポートして、このプロセスを助けます。データ型の変更コントロールを使用すると、ソースの定義のデータ型を変更する関数を定義できます。たとえば、ソースの定義がVARCHAR型で、対応する値が常にtrueまたはfalseである場合、データ型の変更ドロップダウンボックスでBOOLEANを選択して、VARCHAR値をBOOLEANにキャストする関数を定義できます。さまざまなターゲットデータ型がコントロールに用意されており、いくつかには非一致の値を処理するオプションがあります。たとえば、すべての値をINTEGER型にキャストし、非一致のリテラルN/Aが処理される場合、キャスティング関数を0の代わりに使用するように構成できます。データ型の変更を選択したら、適用をクリックして適用するか、キャンセルをクリックしてその型の変更を元に戻すことができます。ソースの定義に適用できる関数は、データ型の変更の下で提供されるデータ型変更関数に制限されておらず、ソース定義エディタではDremioがサポートするすべてのSQL関数を適用できます。詳細はSQL関数カテゴリをご覧ください。

ネストされたコンテンツから追加の結果カラムを導き出したい場合、接頭辞“src.”とネストされたフィールドへのパスを使用して、ネストされたフィールドを指定することができます。例えば、“someField"というトップレベルのフィールドにネストした"someSubField"というフィールドがある場合、“src.someField.someSubField”を追加結果カラムとして追加します。同じように、入れ子になった配列にアクセスすることもできます。“someField”というトップレベルフィールドに"someArraySubField"というネストした配列フィールドがある場合、最初の配列エントリにアクセスするために、追加の結果カラムとして“src.someField.someArraySubField[0]”を追加します。

ソース定義を検証し、その結果をプレビューするには、サンプルの読み込みをクリックします。システムは関連付けられているコレクションのデータを取得し、デフォルトでは過去24時間からサンプルを取得し、そのデータに対してソース定義が評価されます。NULLの結果はフィルタリングされます。最大の結果数は100に制限されています。右上の時間コントロールを使用して、データのサンプリング対象となる期間を調整できます。期間には、最大で過去7日間が含まれます。特定のサンプル値を検索するには、上部のフィルターコントロールを使用して、現在のサンプル結果の一覧をフィルタリングします。サンプル結果のタイプは、ソースデータとソース定義によって異なります。STRUCTなどの複雑なタイプについては、エントリ内のノードをクリックして、サンプルエントリのネストされたコンテンツを参照します。ソース定義をエントリの特定のパスに設定する場合は、そのパスに移動し、パスの横にある手のアイコンをクリックします。パスの横にあるコピーアイコンを使用してパスをコピーすることもできます。ソース定義を変更すると、通常、現在のサンプル結果は一致しなくなります。新しいソース定義に関するサンプル結果のリストを取得するには、再読み込みをクリックします。

保存をクリックしてカラムを追加すると、デフォルトでオフロードに選択されます。ソース定義が無効な場合、例えば未知のカラムにアクセスする場合、Column “UnknownColumn” not found in any tableのようなエラーメッセージが表示されます。先に進む前にソース定義を修正する必要があります。追加結果カラムの設定をキャンセルするには、キャンセルをクリックします。

追加した結果カラム編集

追加した結果カラムのコンテキストメニューで、編集を選択すると、カラム名とソース定義を編集するためのダイアログが表示されます。保存をクリックすると、新しい設定でカラムが更新されます。カラム名は固有である必要があり、ソース定義は有効でなければ続行できません。キャンセルをクリックすると、カラムの編集を終了します。

自動検出されたカラムに対しては、ソースの定義を変更することはできません。ソースの定義を変更したい場合は、自動検出された列を複製し、必要に応じてソースの定義を変更する必要があります。

追加した結果カラムの複製

追加した結果カラムのコンテキストメニューで、複製を選択すると、カラムを複製するためのダイアログが表示されます。複製されたカラムのソース定義は、元のカラムと同じであり、ニーズに合わせて変更することができます。新しいカラムの名前は、元のカラム名にカウンター接尾辞を追加して名前を一意にします。必要に応じて名前を変更できます。また、元のカラムも名前を変更できます。新しいカラム名と元のカラム名の両方が一意である必要があります。

保存をクリックすると完了し、キャンセルをクリックするとカラムの複製を中止します。

複製の一般的なユースケースは、自動検出されたカラムのデータ型を変更することです。たとえば、“statusOrdinal"というカラムを複製し、ソースの定義エディタで対応するキャスティング関数を適用します。新しいカラム名として"statusOrdinal"を使用し、元のカラムの名前を"statusOrdinal_Old"に変更します。追加のカラムのリストで"statusOrdinal"を選択し、“statusOrdinal_Old"を非選択にします。

追加した結果カラムの削除

追加した結果カラムのコンテキストメニューで、削除を選択すると、カラムを削除するためのダイアログが表示されます。そのまま削除する場合は確認を、削除を中止する場合はキャンセルをクリックします。自動検出されたカラムを削除することはできません。

追加した結果カラムを削除すると、そのデータは次のオフロードの実行に含まれなくなります。すでにデータレイクにオフロードされているデータは、カラムの削除の影響を受けません。したがって、追加の結果カラムが削除されると、カラム自体はデータレイクにまだ存在しますが、値はNULLになります。

次の設定に進むには、次へをクリックします。前へをクリックすると、1つ前の設定ステップに戻ります。オフロードの設定を中止するには、キャンセルをクリックします。

フィルター述語の設定

オプションで、フィルター述語を定義することができます。デフォルトでは、基本コレクションのすべてのエントリーがデータレイクにオフロードされます。述語を使用して、データレイクに存続させたくないエントリーをフィルタリングできます。例えば、無効な値や異常値をフィルタリングすることができます。追加フィルター述語フィールドでは、SQL構文でフィルターを指定することができます。例えば、アラームコレクションの場合、フィルターはstatus='ACTIVE' AND severity='WARNING'とし、緊急度が「警告」で有効なアラームのみを存続することができます。フィルター述語機能は、複雑なSQL構文（AND/ORの組み合わせ、IN(...) / NOT IN(...)のよなどの節、REGEXP_LIKE(text, 'MyText\S+')などの関数）をサポートしています。

フィルター述語では、カスタムフィールドだけでなく、基本コレクションのすべての標準属性をクエリすることができます。前の構成ステップで定義した追加の結果カラムは、フィルター述語の中でその名前を使ってアクセスすることはできません。代わりに、対応するカラムで定義されているソース定義を使用する必要があります。

追加のフィルター述語を定義する際に、検証をクリックすると、述語の検証を行うことができます。検証が失敗した場合は、エラー説明が表示されます。これらのエラーを修正しないと先に進めません。

次の設定に進むには、次へをクリックします。前へをクリックすると、1つ前の設定ステップに戻ります。オフロードの設定をキャンセルするには、キャンセルをクリックします。

タスクの詳細を設定

タスク設定ステップには、オフロードタスク名と説明文が含まれます。オフロードタスク名は、オフロードパイプラインの識別子です。最低でも1つの、スペースを含まない文字が必要です。タスク名は一意である必要はありませんが、一意の名前を使用することが推奨されます。

説明フィールドでは、このオフロードパイプラインの説明を追加することができます。説明は任意ですが、パイプラインとその目的に関する追加情報を提供するため、説明を使用することをお勧めします。

次の設定に進むには、次へをクリックします。前へをクリックすると、1つ前の設定ステップに戻ります。オフロードの設定を中止するには、キャンセルをクリックします。

追加の設定を構成し、構成を完了する

最後のステップでは、設定の概要、追加設定の構成、および結果のプレビューが表示されます。概要には、前のステップの設定と、この設定の内部UUIDが含まれます。UUIDはシステムによって生成され、変更することはできません。UUIDを使用すると、監査ログやオフロードのステータスを参照するときなどに、同じタスク名を持つ構成を区別することができます。概要では、オフロードパイプラインが開始されると実行されるスケジュールも表示されます（例：“every hour at minute 6”（毎時6分））。サマリーの最後にある無効/有効トグルで、保存時にオフロードの定期的な実行を有効にするかどうかを選択できます。

オフロードのプレビューでは、実際のデータがデータレイクにどのように保存されるかを確認できます。データの確認ができるよう、オフロードプレビューが実行され、結果データのサンプルが返されます。サンプルデータのヘッダー行には、カラム名とカラムタイプが含まれています。時間カラムを隠すを使用すると、時間的な概念を持つデフォルトのカラムを表示するかしないかを選択できます。プレビューでは、データはデータレイクに永続的に保存されません。

オフロード頻度

デフォルトでは、各アクティブなオフロードパイプラインは毎時、同じ分に一度実行されます。オフロードの頻度は、ドロップダウンボックスで実行されるオフロードの時間を1日の中で設定することで調整できます。デフォルト設定と同様に、実行のための正確な時間の分はシステムによって選択されます。時間はUTCとしてのタイムゾーンを基準に定義されています。少なくとも1時間を選択する必要があります。それ以外の場合、設定を保存することはできません。

コンパクション戦略

追加設定では、オフロードパイプラインのコンパクション戦略を定義することができます。コンパクション戦略とは、Things Cloud DataHubが、データレイクにある複数の小さなファイルを1つ以上の大きなファイルに自動的に結合する方法のことです。Things Cloud DataHubは、大量の小さなファイルがクエリのパフォーマンスに悪影響を及ぼす可能性があるため、オフロードパイプラインのためにコンパクションを定期的に実行します。コンパクションは1日に1回実行され、コンパクションのスケジュールは変更できません。

Things Cloud DataHubは、自動的にコンパクション戦略を設定しますが、オプションで戦略を変更することも可能です。利用可能なコンパクション戦略は以下の通りです

• 月次・日次コンパクション：Things Cloud DataHubは、データレイクにあるその日のデータを含むすべてのファイルを、各日ごとに選択します。これらのファイルは、この日の全データを含む1つまたは複数の大きなファイルに結合されます。さらに、1ヶ月のすべての日が、この月のすべてのデータを含む1つまたは複数の大きなファイルに結合されます。この結果、各日および各月の要約ファイルが作成され、元のファイルは削除されます。
• 日次コンパクション：Things Cloud DataHubは、データレイクにあるその日のデータを含むすべてのファイルを、各日ごとに選択します。これらのファイルは、その日の全データを含む1つまたは複数の大きなファイルに結合されます。この結果、各日の要約ファイルが作成され、元のファイルは削除されます。
• コンパクションなし：コンパクション無効。この設定は、クエリのパフォーマンスに悪影響を及ぼす可能性が高いため推奨されず、慎重に使用する必要があります。

すでに実行されているオフロードパイプラインのコンパクション戦略を変更するには、パイプラインを無効化してコンパクション戦略を編集し、再度パイプラインを有効化します。過去にコンパクションがすでに実行されていた場合、コンパクション戦略を変更しても、前のコンパクション結果を覆すことはできません。

具現化の表示

追加設定では、アラーム、イベント、インベントリコレクションに基づいて、オフロードパイプラインのビューの実体化を有効/無効にすることができます。これら3つのコレクションについては、ターゲットテーブルに対する追加のビューがDremioのテナントのスペースで定義されます。_latestビューは、中間遷移を除いたすべてのエンティティの最新ステータスを維持します。大規模なテーブルの場合、ビューのメンテナンスが全体のパフォーマンスに悪影響を及ぼす可能性があります。そのため、_latestビューを具現化して、各エンティティの最新の状態をデータレイクに永続化することができます。この設定がパイプラインで有効になっている場合、具現化ビューは次のオフロードの実行時に作成され、その後の実行ごとに更新されます。設定を無効にした場合、ビューは引き続き利用できますが、具現化されなくなります。

重複するカラム名

もう1つの設定は、メジャーメントコレクションにのみ適用される、重複するカラム名の処理です。オフロード中、測定値は関係形式に変換されます。測定値の対応するカラム名は、パスと単位/値を連結して構築されます。これにより、大文字小文字を除いて同じ名前のカラムができることがあります。その場合、すべてのエントリが同じカラムにオフロードされます。これがオフロードプロセスで望ましくない動作である場合、名前をサニタイズできます。有効にすると、同じカラム名（大文字小文字は考慮されない）となる生成されたカラム名に対して、元の派生名に一意の接尾辞を追加した新しいカラムが作成されます。

2つの異なるオフロード実行からの次の2つの例文書は、以下のように処理されます。

最初の文書：

{
    "id": "4711",
    ...
    "time": {
      "date": "2020-03-19T00:00:00.000Z",
      "offset": 0
    },
    "type": "c8y_Temperature",
    "_seriesValueFragments": [{
      "unit": "C",
      "value": 17.3,
      "path": "c8y_TemperatureMeasurement.T"
    }]
}

2番目の文書:

{
    "id": "4711",
    ...
    "time": {
      "date": "2020-03-20T00:00:00.000Z",
      "offset": 0
    },
    "type": "c8y_Temperature",
    "_seriesValueFragments": [{
      "unit": "C",
      "value": "NaN",
      "path": "c8y_temperaturemeasurement.T"
    }]
}

2つのパスc8y_TemperatureMeasurement.Tとc8y_temperaturemeasurement.Tは等しいです（大文字小文字は考慮しない）。名前のサニタイズがない場合、カラムc8y_TemperatureMeasurement.T.unitのみが作成され、すべての単位のエントリが保存されます。同様に、カラムc8y_TemperatureMeasurement.T.valueも作成され、すべての値のエントリが保存されます。後者の場合、カラムはDOUBLEとVARCHARの混合型になり、DremioはそのカラムのためにVARCHAR型に強制的に変換されます。

オフロード実行が同じカラム名（大文字小文字は考慮しない）を持つ複数のフラグメントを処理する最初の回では、サニタイズも異なるカラム名を生成し、それぞれの名前に一意の接尾辞が付いています。

この重複列名の処理は、時系列データモデルが使用されている場合には適用されません。このモデルは、大文字と小文字の違いによって異なる名前の区別をサポートしていないため、すべての名前はオフロードプロセスで同じデータレイク列に送られます。列名の大文字と小文字は、最初に遭遇した発生を基準に決定されます。

アラームの発生

オフロードおよびコンパクションの実行は、ネットワークの問題やタイムアウトなど、さまざまな理由で失敗する可能性があります。オフロードジョブごとの履歴およびオフロードジョブごとのコンパクションの履歴にに記載されているように、オフロードおよびコンパクションのジョブ履歴は成功した実行と失敗した実行の詳細を提供します。さらに、失敗した場合にはThings Cloudプラットフォーム内でアラームが発生します。

アラームの作成の下で、オフロードおよびコンパクションの失敗に対してアラームを発生させることができます。デフォルトでは、オフロードの設定は有効になっており、コンパクションは無効になっています。有効状態でオフロード実行が失敗すると、アラームが発生します。オフロードが複数回連続で失敗すると、関連するアラームは各新しい失敗ごとに更新されます。連続した実行が失敗するほど、アラームの重大度が上がり、警告から致命的までの範囲になります。各アラームには、どのオフロードパイプラインが失敗したか、連続して何回失敗したかといった情報が含まれます。同様のことがコンパクションの失敗に対して発生したアラームにも適用されます。アラームの種類はそれぞれ CDH_offloading_ または CDH_compaction_ という名前で始まり、その後にオフローディングパイプラインのUUIDが続きます。このようなアラームは、Things Cloud のデバイス管理アプリケーションで利用できます。

アラームはクリアされるまでアクティブのままです。オフロード実行が成功するか、オフロードの設定が削除された場合、アクティブなアラームはクリアされます。アラームの設定が有効であるかどうかに関係なく、アクティブなアラームがクリアされます。オフロードがスケジュールから外れた場合や、アラームの発生が無効になった場合、アラームはアクティブのままです。同様に、コンパクションの失敗に対して発生したアラームにも同じことが適用されます。

完了時のイベントの発生

セクションオフロードジョブごとの履歴およびオフロードジョブごとのコンパクションの履歴では、オフロードおよびコンパクションのジョブ履歴について説明し、成功した実行と失敗した実行の詳細を提供します。さらに、オフロードまたはコンパクションのジョブが成功または失敗として完了した場合、Things Cloudプラットフォーム内でイベントを発生させることができます。イベントの作成の下で、完了したオフロードおよびコンパクションの実行に対してイベントを発生させることができます。これが有効にされると、オフロードまたはコンパクションの実行が完了したときに、実行の詳細を含む新しいイベントが発生します。デフォルトでは、この設定は無効にされており、不要なイベントが送信されるのを防ぎます。

このイベントは、Things Cloud デバイス管理アプリケーションで利用可能です。各イベントには、時刻やタイプなどの標準イベントプロパティが含まれます。イベントのタイプは、*CDH_offloading_またはCDH_compaction_*になり、続いてオフロードパイプラインのUUIDが続きます。さらに、各イベントには、関連するオフロードまたはコンパクションのジョブの名前、ID、実行ID、および状態が含まれます。この状態は、オフロード実行の開始および終了時刻、失敗/成功、オフロードされたレコードの数などの詳細を提供します。

このようなイベントを送信および受信するオプションにより、オフロード実行が完了した際にアクションを起こすことができます。たとえば、オフロードに興味のあるイベントタイプ（例：CDH_offloading_92622259-c78b-408e-95e2-30944de2cc95）を指定して、イベントREST APIを使用して、そのオフロードパイプラインに関連するイベントを取得できます。または、イベント通知APIを使用することもできます。

混合型の取り扱い

各オフロードパイプラインは、データレイク内の結果テーブルの各カラムが一意のデータ型を持つことを確認する必要があります。混合型の状況は、オフロード実行が期待されるカラムデータ型と一致しないデータ型を検出した場合に発生します。たとえば、カラムの型がINTEGERである場合、オフロードはVARCHAR型のリテラルN/Aを処理する可能性があります。このような混合型の状況を解決するには、スキーマを自動進化またはパイプラインの停止の戦略を使用できます。

スキーマを自動進化：これはデフォルトの戦略です。システムは自動的にスキーマを進化させ、新しいデータのために新しい型の列を導入します。その列の名前は、元の列名、リテラルの CDH、そして新しいデータ型を組み合わせて作られます。例えば、新しい型が DOUBLE の場合、その列名は ValvePressure_CDH_DOUBLE となります。以後、各新しい値は新しいデータ型を持つこの新しい列に保存されるようになります。元の列には保存されず、NULL となります。 混合型が検出されたジョブは、パイプラインのジョブ履歴で成功としてマークされます。

パイプラインの停止：システムはパイプラインを停止し、データの修正や追加の結果列の適応などの訂正処置を行うための時間を確保します。これらの修正が完了したら、手動でパイプラインを再有効化する必要があります。混合型が検出されたジョブは、パイプラインのジョブ履歴でエラーとしてマークされます。

混合型が検出された場合、Things Cloudプラットフォームには関連するカラムや型などの詳細情報を含むアラームが追加で発生します。スキーマの変更（schema evolution）が選択された場合、アラームの種類は CDH_schemaEvolved_ にオフローディング UUID を加えたものとなり、アラームタイプは WARNING で発報されます。パイプライン停止（pipeline stop）が選択された場合は、アラームの種類は CDH_pipelineStopped_ にオフローディング UUID を加えたものとなり、アラームタイプは CRITICAL で発報されます。このようなアラームは、前述のアラーム発生の設定とは独立して常に発生します。アラームは手動でクリアする必要があります。オフロードパイプラインが削除されると、アラームは自動的にクリアされます。

データモデリングおよび混合型に関する詳細については、セクションデータモデリングとオフロードの整合性も参照してください。

オフロード構成の完了

最後に、保存をクリックして、オフロードのパイプラインを保存します。保存したくない場合は、キャンセルをクリックしてオフロードの設定を中止します。また、前へボタンを使用して、以前の設定に戻ることができます。

Things Cloud 基本コレクションのオフロード

基本コレクションのオフロード

次の表は、Things Cloud の各基本コレクションの結果スキーマをまとめたものです。これらのスキーマには、内部目的で使用される仮想列 dir0、…、dir3 も含まれています。これらの列は抽出プロセス中に生成されますが、Things Cloud のオペレーショナルストアに対応するデータは存在せず、データレイクにも保存されません。dir0、…、dir3 を追加の列として使用しないでください。列を追加する場合はオフロード構成で適宜名前を変更してください。

アラーム コレクションのオフロード

アラーム コレクションは、発生したアラームを追跡します。 オフロード中、アラーム コレクションのデータはフラット化され、結果のスキーマは次のように定義されます。

アラーム コレクションは、アラームを追跡します。 アラームは、時間の経過とともにそのステータスを変更する場合があります。 アラーム コレクションは、これらの変更を組み込むための更新もサポートしています。したがって、アラーム コレクションのオフロード パイプラインには、追加の手順が含まれます。

1. 最後のオフロード以降に追加または更新されたアラーム コレクションのエントリをオフロードします。これらは、上記の標準スキーマでデータ レイクのターゲット テーブルにオフロードされます。
2. Dremio のテナントのスペースで、ターゲット テーブルに対する追加のビューが定義されます。 それらの名前は、ターゲット テーブル名に all と latest を加えたもので、それぞれ定義されます。 次の例では、ターゲット テーブル名として"alarms"を使用しています。
   • alarms_all - 中間更新を含まない、2 つのオフロード実行間の更新を含むビュー。
   • alarms_latest - すべてのアラームの最新ステータスを含むビューで、以前の遷移はすべて破棄されます。ビューのマテリアライゼーションが有効になっているオフロード構成では、データレイク内のマテリアライズされた状態が使用されます。

ビューは Dremio スペースで提供されます。 Dremio のビューとスペースの詳細については、オフロードされたThings Cloudデータの洗練を参照してください。オフロード ページのメイン パネルには、オフロード構成の詳細セクションに、Dremio UI の対応するテーブルとビューに移動するためのリンクがあります。

イベントコレクションのオフロード

イベント コレクションは、イベントを管理します。 オフロード中、イベント コレクションのデータはフラット化され、結果のスキーマは次のように定義されます。

イベントはアラームと同様に、変更可能であり、作成後に変更することができます。したがって、アラームに適用されるのと同じロジックが適用されます。

ターゲットテーブルに対する追加のビューがテナントのスペース内のDremioで定義されています。その名称はターゲットテーブル名に _all または _latest を追加したものです。以下の例は events をターゲット テーブル名として使用しています。

• events_all - すべてのイベントのキャプチャされた状態を含むビュー。
• events_latest - 過去の状態を含まない、全てのイベントの最新状態のみを表示するビュー。ビューのマテリアライゼーションが有効なオフロード構成の場合、データレイク内のマテリアライズされた状態が使用されます。

これらのビューは、あなたのDremioスペースで提供されています。Dremioのビューやスペースに関する詳細については、オフロードされたThings Cloudデータの洗練を参照してください。オフロード ページのメイン パネルには、オフロード構成の詳細セクションに、Dremio UI の対応するテーブルとビューに移動するためのリンクがあります。

インベントリ コレクションのオフロード

インベントリ コレクションは、マネージドオブジェクトを追跡します。 オフロード中、インベントリ コレクションのデータはフラット化され、結果のスキーマは次のように定義されます。

インベントリ コレクションは、マネージドオブジェクトを追跡します。Things Cloud DataHubは、Things Cloudプラットフォームの内部オブジェクトを自動的に除外するので注意してください。 これらの内部オブジェクトは、Things Cloud REST APIを使用する場合にも返されません。 マネージドオブジェクトは、時間の経過とともに状態が変化する場合があります。インベントリ コレクションは、これらの変更を組み込むための更新もサポートしています。したがって、インベントリのオフロード パイプラインには追加の手順が含まれます。

1. 最後のオフロード以降に追加または更新されたインベントリ コレクションのエントリをオフロードします。 これらは、上記の標準スキーマでデータ レイクのターゲット テーブルにオフロードされます。
2. Dremio のテナントのスペースで、ターゲット テーブルの 2 つのビューが定義されます。 それらの名前は、ターゲット テーブル名に _all と _latest を加えたものとしてそれぞれ定義されます。 次の例では inventory をターゲット テーブル名として使用しています。
   • inventory_all - 中間更新を含まない、2 つのオフロード実行間の更新を含むビュー。
   • inventory_latest - すべてのマネージドオブジェクトの最新ステータスを含むビューで、以前の遷移はすべて破棄されます。ビューのマテリアライゼーションが有効になっているオフロード構成では、データ レイク内のマテリアライズされた状態が使用されます。

ビューはDremio スペースで提供されます。 Dremio のビューとスペースの詳細についてはオフロードされたThings Cloudデータの洗練を参照してください。オフロード ページのメイン パネルには、オフロード構成の詳細セクションに、Dremio UI の対応するテーブルとビューに移動するためのリンクがあります。

メジャーメントコレクションのオフロード

メジャーメントコレクションには、デバイスのメジャーメントが保存されます。 メジャーメントコレクションのオフロードは、ターゲット テーブル レイアウトを明示的に選択する必要があるため、他のコレクションとは異なります。ターゲット テーブル レイアウトには、1 つのタイプに対して 1 つのテーブルが含まれるか、TrendMiner の場合はすべてのタイプのメジャーメントを含む 1 つのテーブルが含まれます。オフロードページのメインパネルにあるオフロード設定の詳細セクションには、Dremio UIの対応するテーブルに移動するリンクがあります。

デフォルトのターゲット テーブル レイアウトを使用したメジャーメントのオフロード

デフォルトのレイアウトを使用する場合、オフロードされたすべてのデータが同じタイプになるように、メジャーメントタイプを選択する必要があります。 オフロード中、メジャーメントコレクションのデータはフラット化され、結果のスキーマは次のように定義されます。

メジャーメントコレクションのエントリは、対応するデバイスが出力するデータの種類に応じて、異なる構造を持ちます。センサーにより、温度と湿度の値を出力するものや圧力値を出力するものがあります。これらの属性の平坦化された構造は、fragment. として定義され、その後に属性名と、メジャーメントコレクションで定義されている関連付けられた型が続きます。属性の具体的な数は、メジャーメントタイプによって異なります。上の表のfragment.attribute1.name.value から fragment.attributeN.name.value までを示しています。

例

次の基本コレクション内のメジャーメントドキュメントの抜粋は、以下のように処理されます。

{
    "id": "4711",
    ...
    "time": "2020-03-19T00:00:00.000Z",
    "type": "c8y_Temperature",
    "c8y_Temperature": {
        "T": {
            "unit": "C",
            "value": 2.079
        }
    }
}

システムは type 属性を使用して、c8y_Temperature をメジャーメントタイプとして定めます。 次に、メジャーメントタイプとしてT、メジャーメントの値として 2.079、メジャーメント単位としてC、をプロパティとして含むメジャーメントフラグメントc8y_Temperatureを定めます。このフラグメントはフラット化され、データレイク のターゲット テーブルで次のように表されます。

TrendMiner ターゲット テーブル レイアウトによる測定のオフロード

TrendMiner レイアウトを使用すると、すべてのメジャーメントが 1 つのテーブル c8y_cdh_tm_measurements にオフロードされます。 対応する型は列 type に格納されます。 unit 列は単位を定義し、 value 列はメジャーメントを定義します。 列 tagname は、特定の系列を検索するために TrendMiner によって使用されます。 これは、メジャーメントコレクションに保存されているソース、フラグメント、およびシリーズで構成されています。

結果のスキーマは次のように定義されます。

マッピング例

以下はベース コレクションのメジャーメントドキュメントの抜粋です。

{
    ...
    "source": "857",
    "type": "Temperature",
    ...
     "c8y_Temperature": {
         "T": {
             "unit": "C",
             "value": 2.0791169082
         }
     }
}
...
{
    ...
    "source": "311",
    "type": "Pressure",
    ...
     "c8y_Pressure": {
         "P": {
             "unit": "kPa",
             "value": 98.0665
         }
     }
}

データ レイクのターゲット テーブルでは次のように表されます。

c8y_cdh_tm_measurements というテーブルに加えて、c8y_cdh_tm_tags というテーブルが作成されます。 このテーブルにはタグ名とソース ID が格納され、Things Cloud プラットフォームで管理されたタグ名とソース IDと共にTrendMiner で使用されるタグ名と関連付けます。 c8y_cdh_tm_tags テーブルのスキーマは次のように定義されています。

データモデリングとオフロードの調整

ドキュメントデータをリレーショナルデータにマッピング

Things Cloud DataHub は、Things Cloud プラットフォームからデータをデータレイクにオフロードし、その後、SQLを使用してオフロードされたデータを分析することを可能にします。そのためには、Things Cloud DataHub は、ドキュメントベースの形式のデータをリレーショナルな形式に変換し、それをデータレイク内のParquetファイルとして永続化する必要があります。

オフロードが構成されると、Things Cloud プラットフォームの運用データベースのドキュメントからデータが変換され、データレイク内のターゲットテーブルの列に格納されます。システムはこれらの変換を自動的に生成するか、ユーザーに変更オプションを提案します。ユーザーは追加の変換も構成できます。データフィールドが列に変換される方法を定義する構成には以下が含まれます。

• ソースドキュメントからデータを取得する方法を示す式
• ターゲット列の名前
• ターゲット列の型

プラットフォームが指定する組み込みデータ属性に対しては、型は固定されており、Things Cloud DataHubが認識しています。他の属性については、Things Cloud DataHubが前述の式を運用データベース内のデータに適用して型を決定します。Dremioは、構成時点のデータベースの状態、または以前に取得されたメタデータに基づいてこれを実施します。性能の観点から、この評価はデータの一部、具体的にはコレクションの最初の4095のドキュメントを基に行われます。評価時に式と属性のすべてのインスタンスが同じ型であれば、その型が列の型を定義します。

混合型の管理

属性のインスタンスが異なる型を持っている場合、システムはそのような混在型の状態を解決するために型の強制メカニズムを適用できます。強制メカニズムは、異なる型から単一の適切な型を導き出します。例えば、INTEGERとFLOATはFLOATに、TIMESTAMPとVARCHARはVARCHARに強制されます。各オフロードパイプラインごとに混在型の処理方法を構成できます。デフォルトでは、システムはスキーマの進化によって混在型を自動的に解決します。このスキーマの進化は、新しい列を強制型に基づいて導入するために型強制を使用します。代替として、システムはパイプラインを停止して修正を許可することもあります。混合型の処理 セクションではこれらの戦略を構成する方法が説明されています。

計測フラグメントをリレーショナルデータにマッピング

計測の系列値フラグメントを処理する場合、オフロード構成メカニズムは異なります。追加のフラグメントが頻繁に動的に追加されるためThings CloudDataHubはオフロードパイプラインを再構成する必要なく、ランタイムで各系列を自動的に取得します。

各系列には、NUMBER型の必須の値と、STRING型のオプションの単位が必要です。値がNUMBER型でない場合、Things Cloud DataHubはオフロードランタイムで各系列の型を決定します。ランタイムでの各値のランタイム型を評価し、対応するオフロードランに対する列型を導出します。系列のすべての値がBOOLEAN、FLOAT、STRUCT、LISTのいずれかに一貫してキャストできる場合、結果の列の型はそれになります。それ以外の場合、DataHubはVARCHARを使用します。ユースケースが同じ系列の異なる型を混在させる場合は、前述の混在型処理が適用されます。

ガイドライン

データをモデル化するときは、次のガイドラインを考慮してください。

制限事項

データをモデル化するときは、次の制限に注意する必要があります。

オフロード ジョブの管理

次の手順では、オフロード パイプラインを開始および管理する方法について説明します。

オフロード ジョブのスケジュール方法

オフロード構成を定義して保存したら、オフロード パイプラインを開始できます。

定期オフロードの開始

パイプラインの構成時にアクティブ化されていない場合は、オフロード構成で有効トグルをクリックして、オフロード パイプラインの定期的な実行を有効化します。 Things CloudDataHub のスケジューラ コンポーネントは、パイプラインを定期的にトリガーします。

初期オフロードは、オフロード パイプラインの最初の実行を示します。 後続の実行ではデータの増分のみをオフロードしますが、最初のオフロードでは、すべてのコレクション データをThings Cloudオペレーショナル ストアからデータ レイクに移動します。 したがって、最初のオフロードでは、膨大な量のデータを処理する必要がある場合があります。 このため、最初のオフロードでは 1 つの大きなデータ セットを処理するのではなく、データをバッチに分割してバッチを処理します。 たとえば、データ レイクの停止が原因で最初のオフロードが失敗した場合、次のオフロードでは、どのバッチが既に完了しているかがチェックされ、まだ完了していないバッチが続行されます。

過去に同じパイプラインが既に開始および停止されている場合、パイプラインを新たに開始すると、既存のデータをフラッシュするか、既存のデータにデータを追加するかを尋ねるボックスが開きます。 後者を選ぶ場合は、最後の実行後に追加されたデータのみをオフロードします。 最初のものを選ぶと、データ レイクをフラッシュします。 その後、次の実行で完全なコレクションがオフロードされます。

定期的なオフロードを再開する前に、列を追加または削除して結果スキーマを変更した可能性があります。(たとえば、追加の結果列を追加または削除など)　パイプラインを再起動すると、データ レイク内の既存のデータは変更されませんが、オフロードされる新しいデータには新しいスキーマが組み込まれます。 異なるスキーマで構成されるこのようなデータ セットを照会すると、システムはマージされたスキーマを計算し、(仮想的に) フィールドがまだ提供されていない場所に null 値を入力します。 これは通常、追加の属性がオフロード構成に含まれているか、オフロード構成から削除されている場合、問題なく機能します。 ただし、スキーマのマージが失敗するか、場合によっては予期しない動作が発生する可能性もあります。 1つの例が、データタイプを変更した場合です：たとえば、古い構成では「myCustomField1」が「文字列」として設定されていたのに、「CAST(myCustomField1 AS Integer) AS myCustomField1」を使用して「数値」に変更した場合など。 したがって、オフロードするデータに一貫性があるよう注意する必要があります。

データはデータ レイクの同じフォルダーに格納されているので、以前のオフロード パイプラインが同じターゲット テーブルに既に書き込まれている可能性があります。この場合、新しいオフロード パイプラインを開始するときに、既存のデータをフラッシュするか、既存のデータにデータを追加するかを尋ねられます。 古いデータと新しいデータが同じスキーマを共有している場合にのみ、データを追加してください。 さもなければ、異種データで構成されるテーブルになってしまう可能性があり、意味のある分析ができなくなります。 新しいデータが古いデータと異なる場合は、新しいターゲット テーブルを使用すると良いでしょう。 また、古いコンテンツが不要になった場合は、既存のテーブルをフラッシュしてください。 繰り返しになりますが、削除したデータは回復できない可能性が高いため、テーブルをフラッシュするときは注意が必要です。

スケジュール設定

スケジューラは、デフォルトでオフロード パイプラインを 1 時間に 1 回実行するように構成されています。 オフロードが開始される正確な時間（分）は、Things Cloudのオペレーショナル ストアの負荷のバランスをとるために、つまり、異なるテナントからのすべてのオフロード ジョブが同時に実行されるのを避けるために、システムによって割り当てられます。

定期的なオフロードの停止

定期的なオフロードを停止するには、オフロード構成で有効トグルを使用します。 その後、スケジューラは新しいジョブのスケジューリングを停止し、実行中のジョブが完了します。

オフロードパイプラインの管理

各オフロード パイプラインのコンテキスト メニューには、パイプラインを管理および監視するためのアクションがあります。

オフロード パイプラインの編集/表示

編集をクリックして、現在の設定を編集します。 無効なパイプラインのみを編集できます。 このパイプライン用に選択された Things Cloud ベース コレクションは変更できませんのでご注意ください。 メジャーメントコレクションの場合、ターゲット テーブルのレイアウトも変更できません。追加のフィルター述語と追加の結果列は変更可能です。これらの変更は既にエクスポートされたデータには適用されません。オフロードパイプラインへの変更は、今後のオフロード実行でエクスポートされるデータにのみ影響します。

有効なパイプラインについては、表示をクリックすると構成を参照できます。 設定を編集することはできません。

オフロードパイプラインの複製

複製をクリックして、現在の構成を複製します。 新しい構成は、タスク名とターゲット テーブルを除いて（どちらにも固有のサフィックスが追加されます。）、元の構成と同一の構成であり、必要に応じて設定を変更できます。

TrendMiner 設定は 1 つしか許可されていないため、TrendMiner オフロード設定は複製できません。

オフロードパイプラインの削除

削除 をクリックして構成を削除します。 無効なパイプラインのみを削除できます。 このオフロード パイプラインによって既にエクスポートされているデータ レイク内のデータは削除されません。データ レイク内の実際のデータを削除するには、AWS S3 コンソールや Azure Storage Explorer などのデータ レイク プロバイダーが提供するツールを使用する必要があります。

手動オフロードジョブのトリガー

定期的なオフロードが有効になっている場合は、スケジュールされた 2 つの実行の間にオフロード ジョブを手動でトリガーすることもできます。 たとえば、最新のデータをデータ レイクにオフロードするために、次にスケジュールされた実行を待ちたくない場合があるとします。 今すぐオフロードをクリックして、手動オフロードを開始します。定期的なオフロードと同様に、手動オフロード実行では、最後のオフロード実行以降に追加された増分データのみが処理されます (この最後の実行が手動またはスケジューラによってトリガーされたかどうかは関係ありません)。

ただし、手動でトリガーするのではなく、定期的なオフロードに依存することをお勧めします。

オフロードパイプラインの監視

オフロード履歴の表示をクリックして、パイプラインの実行履歴を調べます。 詳細については、オフロードジョブの監視 を参照してください。

オフロード構成のインポート/エクスポート

インポート/エクスポート機能により、オフロード構成をファイルにバックアップできます。 データ レイク設定を編集するとき、またはオフロード構成を 1 つの Things Cloud DataHub インスタンスから別のインスタンスにコピーするときに、バックアップを使用できます。 インポート/エクスポートには、パイプラインの構成のみが含まれます。 これには、パイプラインのランタイム ステータスも既にエクスポートされたデータも含まれません。

オフロード構成のエクスポート

アクションバーにExportボタンがあり、すべてのオフロード設定をエクスポートします。このボタンは、オフロード設定が定義されていない場合は無効になります。Exportをクリックすると、すべてのオフロード設定がファイルにエクスポートされます。ファイルは、ブラウザが使用するローカルのダウンロードフォルダーに配置されます。

アクション バーには、すべてのオフロード構成をエクスポートするエクスポートボタンがあります。 オフロード構成が定義されていない場合、ボタンは無効となっています。エクスポートをクリックすると、すべてのオフロード構成がファイルにエクスポートされます。ファイルは、ブラウザが使用するローカルのダウンロード フォルダにあります。

オフロード構成のインポート

アクション バーにはインポートボタンがあり、以前にエクスポートした構成ファイルからオフロード構成をインポートします。

インポートをクリックして、ダイアログボックスを開きます。ファイルをインポートキャンバスにドロップするか、キャンバスをクリックしてファイルシステムをブラウズしてインポートファイルを選択します。ファイルが選択されると、そのファイルに含まれるすべての設定が表示されるテーブルが表示されます。各エントリには、タスク名、元の構成の内部ID、対象テーブル名、および説明が一覧表示されます。ステータス列は、オフロード構成をインポートできるかどうかを示します。緑色の場合、構成は有効でインポートできます。黄色の場合、構成はインポート可能ですが、テナントでサポートされていない設定がいくつか無視されます。赤色の場合、構成は既存の構成と重複しており、したがってインポートできません。既存の構成と同じ対象テーブル名または同じ内部IDを持つ場合、重複しています。インポート列には、インポートする構成を選択するためのチェックボックスが提供されています。

選択した構成をインポートするには、インポート をクリックします。 インポートをキャンセルする場合は、キャンセル をクリックします。

構成が有効であったかどうかはエクスポートに含まれないため、インポート後に構成を手動で有効化する必要があります。

オフロードジョブの監視

オフロードパイプラインを構成して起動したら、定期的にデータがデータレイクにオフロードされます。 Things Cloud DataHub UIは、異なるパイプラインの実行状態に関する洞察を提供し、すべてが予想どおりに動作しているかどうかを調査できます。オフロードの失敗の場合、アラームの発生で説明されているように、オフロードパイプラインをアラームを発生させるように構成することもできます。

オフロードの状況の概要はホーム画面に表示され、詳細はジョブ履歴で確認できます。

オフロードパイプラインごとの履歴

特定のパイプラインの実行履歴を調べる場合は、ナビゲーションバーでオフロードを選択し、目的のオフロードジョブを選択します。

オフロード構成のメニューでオフロード履歴を表示をクリックして、オフロード実行の履歴を表示します。

一覧には実行履歴が表示され、各実行は次の詳細で構成されます。

システムは、限られた最新のジョブ実行の履歴を保持するように構成設定されています。

リロードをクリックして一覧を更新します。

エントリをステータスまたはタイムスタンプでフィルタリングするには、上部のフィルターコントロールを使用します。現在のフィルタ設定でエントリをフィルタリングするには、適用をクリックしてください。現在のフィルタ設定をリセットするには、フィルタのリセットをクリックしてください。

ページ下部のナビゲーションボタンを使用して、履歴エントリを移動することができます。

オフロードジョブの詳細

特定のオフロードジョブについて、その実行の詳細を調べることができます。

対応するジョブの一覧から、該当のジョブをクリックします。詳細ビューには、次の情報が含まれます。

実行スケジュール

結果

ジョブ詳細

オフロードの結果

オフロード中、データはDremioにより、一時的なフォルダー階層に従ってデータレイク内に新しく作成されたファイルに編成されます。 これらのファイルごとに、次の情報が提供されます。

圧縮ジョブの監視

オフロード中、Things Cloud のオペレーションストアからのデータは、データレイク内のファイルに書き込まれます。これらのファイルの簡潔な物理的レイアウトを確保するために、Things Cloud DataHub はバックグラウンドで定期的な圧縮ジョブを自動的に実行します。オフロードパイプラインごとに、対応する圧縮ジョブが作成およびスケジュールされます。Things Cloud DataHub UI は、さまざまなパイプラインのコンパクションステータスに関する洞察を提供するため、すべてが期待どおりに実行されているかどうかを調査できます。コンパクションが失敗した場合、アラームの発生 で説明されているように、オフロードパイプラインがアラームを発生させるように設定することもできます。

すべての圧縮ジョブのステータス

ナビゲーターにある、ステータスの下の圧縮を選択して、各パイプラインの圧縮ジョブの最新ステータスの概要を取得します。一覧には、すべてのパイプラインに対応する最後の圧縮ジョブが表示されます。 各圧縮は、次の詳細で構成されます。

リロードをクリックして、表示されているステータスを更新します。

アクション バーのフィルター ボタンを使用して、ステータスで絞り込みができます。 ページ ボタンを使用して、履歴エントリをトラバースできます。

オフロードパイプラインごとの圧縮履歴

特定のオフロードパイプラインの圧縮履歴を調べる場合は、ナビゲーションバーでオフロードを選択し、目的のオフロードジョブを選択します。

オフロード構成のメニューで圧縮履歴を表示をクリックして、圧縮履歴を表示します。

一覧には実行履歴が表示され、各実行は次の詳細で構成されます。

システムは、限られた最新の圧縮ジョブ履歴を保持するように構成設定されています。

リロードをクリックして一覧を更新します。

上部のフィルターを使用して、ステータスまたはタイムスタンプで絞り込みができます。適用をクリックして、現在のフィルター設定でエントリをフィルタリングします。フィルターリセットをクリックして、現在のフィルター設定をリセットします。デフォルトでは、過去7日間のエントリが表示されます。

圧縮ジョブの詳細

特定の圧縮ジョブについて、その実行の詳細を調べることができます。

表示されたジョブ一覧で、目的のジョブをクリックします。詳細ビューには、次の情報が含まれます。

実行スケジュール

ジョブ詳細

毎日の圧縮結果

毎日の圧縮の際、時間階層に従ってファイルはマージされます。その結果、各日付けのフォルダーが作成され、フォルダ内には、その日に測定されたすべての値を組み合わせたファイルが1つ以上格納されます。 これらのファイルごとに、次の情報が提供されます。

毎月の圧縮結果

毎月の圧縮の際、時間階層に従ってファイルはマージされます。その結果、各月のフォルダーが作成され、フォルダ内には、その月に測定されたすべての値を組み合わせたファイルが1つ以上格納されます。 これらのファイルごとに、次の情報が提供されます。

オフロードされたThings Cloudデータのクエリ

Things Cloud はSQLインターフェースを提供しているため、オフロードされたデバイスデータを効率的に照会し、独自のアプリケーションでこの結果を活用できます。 デバイスデータに対してSQLクエリを実行するための前提条件は、Things Cloudのオペレーショナルストアからデータレイクにデータを複製および変換するオフロードパイプラインを設定および実行していることです。

概要

Things Cloud DataHubの概要で説明されているように、Things Cloud DataHubは、Things Cloudのオペレーションストアからデータを定期的に抽出するオフロードパイプラインを管理し、データを関連形式に変換し、最終的にデータレイクに保存します。オペレーショナルストアをクエリする代わりに、データレイクに対してクエリを実行します。分散SQLエンジンDremioは、データレイクにアクセスするためのクエリインターフェイスを提供します。

このために、JDBC、ODBC、RESTなどのさまざまな標準インターフェイスが存在します。Dremio UIも使用可能です。これらのインターフェイスのいずれかを使用するには、ナビゲーションバーでHomeを選択します。Quick linksの下に、さまざまなインターフェイスの起点があります。

データレイクコンテンツへのアクセス

SQLクエリを実行するには、別のDremioアカウントが必要です。 Dremioを使用してデータレイクに対してクエリを実行するときにリクエストを認証するには、Dremioアカウントが必要です。 初期設定のステップで、対応するDremioユーザーが作成されています。Dremioアカウントの設定については、管理者にお問い合わせください。

接続を確立したら、（オフロードパイプラインが正常に実行されるたびに新しいデータが追加される）データレイクのテーブルに対してSQLクエリを実行できます。クエリで参照するソースは、テナントIDとオフロード設定で指定したターゲットテーブルによって定義されます。SQLクエリでソースとして使用される識別子はそれぞれのデータレイクプロバイダーに対して次のように定義されています。

• Azure Storage: YourTenantIdDataLake.FileSystem.YourAccountName.TargetTableName とAzure Storageアカウント内のファイルシステムを示す FileSystem
• Amazon S3: YourTenantIdDataLake.Bucket.YourAccountName.TargetTableName とAmazon S3アカウント内のバケットを示すBucket
• 他: YourTenantIdDataLake.YourAccountName.TargetTableName

たとえば、tenant ID が t47110815であり、Dremioという名前のファイルシステムを含むAzure Storageアカウントの JohnsAlarmsというターゲットテーブル にアラームコレクションを書き込むオフロード構成設定を定義した場合、クエリの例は次のようになります。

SELECT * FROM t47110815DataLake.Dremio.t47110815.JohnsAlarms;

DremioのUIでテーブルへのパスを簡単に検索できます。左側の「ソース」の下にあるデータレイクをクリックしてから、右側のキャンバスのテーブルに移動します。 テーブル名にカーソルを合わせると、ツールチップ「コピーパス」が付いた小さな「コピー」アイコンがテーブル名の右側に表示されます。それをクリックすると、テーブル名がクリップボードにコピーされます。

スキーマ情報の取得

データレイク内の各テーブルは、オフロードパイプラインに関連付けられています。テーブルのスキーマはオフロードパイプラインの設定によって異なります。パイプラインが設定されているベースコレクションのスキーマと、オプションで設定された追加の結果列で構成されます。Things Cloudオフロードベースコレクションでは、ベースコレクションごとのデフォルトスキーマを確認できます。テーブル全体のスキーマを取得するには、以下のオプションがあります。

• すべてのオフロードの概要を表示するオフロードページに移動します。対応するオフロードパイプラインのコンテキストメニューで、Edit または Show を選択します。ウィザードの最終ステップに移動し、全体的なスキーマとサンプルデータを表示します。この手順を実行するには、Things Cloud DataHub の権限とロールの定義 セクションで指定されている管理者またはマネージャーのロールを持っている必要があります。また、データレイク内の対象のテーブルにデータを供給するオフロードパイプラインが存在している必要があります。
• 前述の Dremio アカウントで Dremio UI にログインします。左側の"Sources"の下にあるデータレイクをクリックし、右側のキャンバスでテーブルに移動します。対象のテーブルにマウスを合わせると、スキーマ情報が表示されます。
• 以下の接続オプションを使用して、テーブルパスを適切に調整した次の SQL クエリを実行し、スキーマとサンプルデータを取得します。

SELECT * FROM t47110815DataLake.Dremio.t47110815.JohnsAlarms LIMIT 5;

Dremio UIの使用

Dremio UIを使用して、データレイクに対してインタラクティブにクエリを実行できます。詳細については、オフロードされたThings Cloudデータの洗練を参照してください。

JDBCを介した接続

Javaクライアントを持つ場合は、JDBCを使用してデータレイクに対してSQLクエリを実行できます。まずは、Dremio JDBCドライバをダウンロードする必要があります。HomeページのQuick linksセクションにあるJDBCアイコンをクリックすると、Things Cloud DataHubからJDBC接続文字列と必要なドライバーのバージョンを取得できます。JDBCクライアントをセットアップするときのユーザー名とパスワードは、Dremioアカウントの認証情報を使用してください。

ODBCを介した接続

ODBCクライアントを使用してデータレイクに対してSQLクエリを実行する場合は、関連するDremioインストール手順に従って、プラットフォーム固有のドライバーを構成する必要があります。ODBC接続用文字列を取得するには、ホームのページのクイックリンクにあるODBCアイコンをクリックします。ODBCクライアントをセットアップするときのユーザー名とパスワードは、にDremioアカウントの認証情報を使用してください。

Dremio REST APIを介した接続

Dremioはデータレイク内のテーブルに対してSQLクエリを実行できるSQL REST APIを提供しています。APIを使用するには、Dremioに対してDremioアカウントで認証する必要があります。

APIはいつでも変更される可能性があり、いかなる保証も提供されません。DremioはCORSヘッダーを送信しないため、ブラウザー基盤のアプリケーションから直接アクセスすることはできません。Things Cloud DataHubのREST APIを使用することを強くお勧めします。以下を参照してください。

Things Cloud DataHub REST APIを介した接続

Things Cloud DataHubサーバーは、Dremioクエリ処理のためのRESTリクエストも処理でき、Dremioへのプロキシとして機能します。Things Cloud DataHubは、Dremioに対してクエリを実行するための2つのREST APIを提供しています。小規模から中規模のクエリ結果サイズ向けの標準のREST APIと、大規模なクエリ結果サイズ向けの高性能なREST APIです。詳細については、Things Cloud DataHub REST APIドキュメントをThings Cloud OpenAPI仕様で参照してください。このAPIを使用する際は、Dremioアカウントではなく、Things Cloudアカウントで認証します。

他のクライアントを接続する

Dremioは、PowerBIなどのレポートツールやPythonなどの一般的な分析言語など、さまざまなクライアントの接続に対応しています。Dremioドキュメントでは、これらのクライアントをDremioに接続し、クエリ機能を活用する方法について説明しています。

他の製品がThings Cloudに接続する方法については、Things Cloud DataHub を他の製品と統合するも参照してください。DataHub とそのクエリ機能を活用します。

オフロードされたThings Cloudデータの洗練

標準インターフェイスを使用したSQLクエリに加えて、Dremioの機能を利用して、オフロードデータをさらに洗練およびキュレートすることができます。

Dremioが提供するすべての機能の詳細については、Dremioドキュメンテーションを参照してください。

Dremioへのアクセスとログイン

Webブラウザー経由でDremioにアクセスします。 次のWebブラウザで動作確認済みです。

• Firefox（最新バージョン）
• Chrome（最新バージョン）

Dremioにアクセスするには、まずホームのページに移動します。クイックリンクにあるDremioアイコンをクリックすると、Dremioのログイン画面が表示されます。

Dremioにログインする方法

ログイン画面で、Dremioアカウントの認証情報を入力します。ログインをクリックしてDremioに入ります。

ログインに成功すると、Dremioのホームページに移動します。

ログアウトする場合は、ユーザー名をクリックして、ログアウトを選択します。

ソースとスペース

Dremioのホームページには、左側のデータセットの下に、それぞれスペースおよびソースと呼ばれる2つのパネルがあります。

ソース

ソースパネルには、YourTenantIdDataLakeというデータソースがあります（例：t47110815DataLake）。このソースは自動的に構成設定されており、自身のデータレイクを指し示します。

データソースをクリックすると、メインパネルに表示されます。 メインパネルでソースをクリックすると、データソースに移動します。 ここには、オフロードパイプラインのすべてのターゲットテーブルの一覧が表示されます。 これらのターゲットテーブルをクリックすると、SQLエディターが開き、クリックしたターゲットテーブルに対してクエリを実行できます。

スペース

Dremioで割当てられたスペースは、データセットの整理に役立ちます。Things Cloud DataHubは、YourTenantIdSpaceという名前のスペースを自動設定します（例：t47110815Space）。このスペース内に保存されるデータセットは、クエリではYourTenantIdSpace.YourDatasetと名付けられます。Things Cloud基本コレクションのオフロードで説明されているように、インベントリ、イベント、アラーム コレクションには すべてまたは最新のデータを提供する事前構成済みのビューが２つあります。

ジョブ履歴

ジョブ履歴タブには、実行したジョブ/クエリが表示されます。履歴にはジョブの詳細が表示され、フィルター機能（時間範囲、ジョブステータス、クエリタイプ、キュー）を使うこともできます。ジョブの詳細ビュー内のプロファイルビューは、クエリの最適化の可能性を調査するのに非常に役立ちます。

ビューの作成

Things Cloud DataHubでは、データのデフォルト変換を使用して、Things Cloud コレクションからデータレイクにデータを複製できます。 後続で行われるオフロードされたデバイスデータのデータ分析の要件が時間の経過とともに変化する可能性があるため、関連する可能性のあるすべてのデータが含まれるようにオフロードパイプラインを構成設定する必要があります。

ユースケースによっては、摂氏から華氏への変換、またはJSONフラグメントからのデータの抽出などのような、データを制限、絞り込み、変換した「ビュー」を提供する必要があります。

Dremioでは、対応するクエリを定義して新しいデータセットとして保存することにより、このようなビューが作成できます。新しいデータセットを保存するときは、保存場所として自分のスペースを選択する必要がありますが、ビューの名前は自由に決められます。それが完了したら、他のソースと同様に新しいデータセットを操作し、それに対してクエリが実行できます。オフロードされたThings Cloudデータのクエリで説明されているように、他のクライアントからこのビューをクエリすることが含まれます。

例

レポートツールでデータを視覚化すると想定しましょう。原データの量が多すぎるため、代わりに「myValue」という列の時間平均を表示したいとします。次のSQL構文でビューを作成し、それをビュー/仮想データセットとして保存することにより、簡単にそれを行うことができます。

SELECT DATE_TRUNC('HOUR', "time") AS "time", AVG(myValue) AS hourlyAvg
FROM myTable
GROUP BY DATE_TRUNC('HOUR', "time")

ビューの作成 (および更新) も、Dremio SQL API を介して行うことができます。 これは、タスクを自動化する場合に特に役立ちます。 上記の例は、次のように作成または更新できます。

CREATE OR REPLACE VDS YourTenantIdSpace.YourDesiredViewName AS
  SELECT DATE_TRUNC('HOUR', "time") AS "time", AVG(myValue) AS hourlyAvg
  FROM myTable
  GROUP BY DATE_TRUNC('HOUR', "time")

テーブル/ビューの結合

データレイクから定義したビューとターゲットテーブルを結合することもできます。 Dremioでは、SQLエディターを使用して結合を定義するか、グラフィカルインターフェイスを使用して結合を定義できます。

結合の一般的なユースケースは、インベントリコレクションのメタデータでアラーム、イベント、メジャーメントの値を充実させることです。

SELECT *
FROM t47110815DataLake.Dremio.t47110815.alarms
JOIN t47110815DataLake.Dremio.t47110815.inventory
USING(id)

Things Cloud DataHubのベストプラクティス

SQLクエリの堅牢でスケーラブルな処理を確実にするために、確立された使用パターンから学んでください。

命名方針

オフロード設定を定義するときは、タスク名、ターゲットテーブル、説明をそれぞれ指定する必要があります。必要なオフロードパイプラインを後で簡単に見つけられるように、これらの設定にそれぞれ適切な名前を指定する必要があります。また、適切な名前付けスキームにより、クエリの記述が容易になります。

また、オフロード設定を定義する場合、現在保存されている構成設定内で固有のターゲットテーブルを常に定義する必要があります。ここでは、削除された古いオフロード設定のターゲットテーブルを再利用しないでください。そうしないと、ターゲットテーブルが、スキーマが異なる複数の構成設定のデータで構成されるという問題に陥る可能性があります。

追加の列とフィルター述語の慎重な定義

オフロード構成設定では、オフロードする追加の列を指定したり、データを絞り込むための述語をフィルターしたりできます。両方の設定について、実際に処理に必要なデータを慎重に検討する必要があります。フィルターで除外されたデータは、再度取得することができません。後でフィルター述語を調整しても、以前のオフロード実行で適切とされていたデータはオフロードされません。 ただし、オフロードを停止し、追加のフィールドなどを含めるように構成設定を変更してから、再起動することはできます。再起動すると、DataHubは、既存のデータをフラッシュする（つまり、再インポートする）か、追加するかを尋ねます。フラッシュすると、データ レイク内のすべてのデータが削除されるため、次のオフロード実行で完全なコレクションが再びオフロードされます。 Things CloudDataHubは、Things Cloudのオペレーショナルストアに既存するデータのみを再インポートできるのでご注意ください。つまり、Things Cloudのデータ保持ポリシーによって古いデータが削除された可能性があるので、このオプションにはご注意ください。一方、今後の分析には明らかに関係のないデータは、オフロード処理に含めないでください。

複雑な追加列の分解

Things Cloudコレクションの追加列としてJSONフラグメントを使用して複雑なデータを保存している場合があります。オフロードジョブの構成設定で説明されているように、オフロード処理に含めるために列を追加することができます。これらの追加列内で、フラグメントをフラットデータに分解する関数を適用できます。

これらの関数を記述する時、多くの場合、基礎となるロジックを複数適応する反復作業となります。Dremio SQLエディターを活用して、データのごく一部をデータレイクに移動する検証目的のダミーのオフロード構成設定を定義します。フィルター述語を使用して、それらのデータの一部を取得できます。（時間フィルターの例については下記をご覧ください。）次に、Dremioを使用してオフロード設定で作成されたテーブルを開きます。そして、DremioのSQLエディターを使用して、抽出ロジックを開発します。 追加の列の分解ロジックが完了したら、列変換をコピーし、それらを使用してThings CloudDataHubで対応するオフロード構成設定を定義できます。 完了したら、テストオフロードパイプラインを削除できます。

追加のフィルタ述語の例

オフロード構成を定義する際、オフロードプロセスで不要なエントリをフィルタリングするために追加のフィルタ述語を定義できます。

時間フィルターの例

コレクションに応じて、さまざまな時間フィルターを使用できます。 すべてのコレクションは、エンティティがプラットフォームによって永続化されたときのタイムスタンプ (UTC タイムゾーン) を表すcreationTimeをサポートします。 変更可能なエンティティ (アラーム、イベント、インベントリ) は、エンティティが最後に変更されたときのタイムスタンプ (UTC タイムゾーン) であるlastUpdatedもサポートしています。timeは、クライアントによって書き込まれたアプリケーションのタイムスタンプです。 アラーム、イベント、およびメジャーメントで対応されています。

以下の時間フィルターは単なる例です。 AND/OR で接続された条件を組み合わせて、はるかに複雑または単純な組み合わせを使用できます。

アラーム/イベント アプリケーション時間が 2020-02-08 14:00:00.000 から 2020-02-08 15:00:00.000 に設定されているすべてのアラームまたはイベントをオフロードするには、次を使用します。

src."time"."date" >= {ts '2020-02-08 14:00:00.000'} AND
src."time"."date" <= {ts '2020-02-08 15:00:00.000'}

2020-02-08 15:00:00.000 以降に保持されたすべてのアラームまたはイベントをオフロードするには、次を使用します。

src."creationTime"."date" > {ts '2020-02-08 15:00:00.000'}

2020-02-08 14:00:00.000 より前に最後に変更されたアラームとイベントにオフロードを制限するには、次を使用します。

src."lastUpdated"."date" < {ts '2020-02-08 14:00:00.000'}

インベントリ 2020-02-08 14:00:00.000 から 2020-02-08 15:00:00.000 の間に保持されたすべてのデータをオフロードするには、次を使用します。

src."creationTime"."date" >= {ts '2020-02-08 14:00:00.000'} AND
src."creationTime"."date" <= {ts '2020-02-08 15:00:00.000'}

または、2020-02-08 14:00:00.000 以降に最後に更新されたすべてのデータをオフロードするには、次を使用します。

src."lastUpdated"."date" > {ts '2020-02-08 14:00:00.000'}

メジャーメント 2020-02-08 14:00:00.000 と 2020-02-08 15:00:00.000 の間のアプリケーション時間ですべてのデータをオフロードするには、次を使用します。

src."time"."date" >= {ts '2020-02-08 14:00:00.000'} AND
src."time"."date" <= {ts '2020-02-08 15:00:00.000'}

または、2020-02-08 14:00:00.000 以降にプラットフォームが受信したすべてのデータをオフロードするには、次を使用します。

src."creationTime"."date" > {ts '2020-02-08 14:00:00.000'}

アラームフィルタの例

現在の重大なアラームでフィルタリングするには、次を使用します。

status != 'CLEARED' AND severity = 'CRITICAL'

イベントフィルタの例

位置でフィルターするには、フィールド c8y_Positionが存在する場合、次を使用します。

src.c8y_Position.lat > 49.8146 AND src.c8y_Position.lat > 8.6372

テキストでフィルターするには、次を使用します。

text LIKE '%Location updated%'

インベントリフィルタの例

デバイスを特定のファームウェア バージョンに制限するには、フィールドc8y_Firmwareが存在する場合、次を使用します。

src.c8y_Firmware.version='v1.32'

オフロードされるインベントリ オブジェクトをデバイスに制限するには、次を使用します。

convert_from(convert_to("_fragments", 'JSON'), 'UTF8') LIKE '%"c8y_IsDevice"%'

Things Cloud DataHubで追加データをクエリする

Things Cloud DataHub の主な使用例は、内部の Things Cloudデータベースからデータ レイクにデータをオフロードし、その後データ レイクの内容をクエリすることです。 一部のユースケースでは、Things CloudDataHubは、Things Cloudプラットフォームに保持されていない追加データをクエリする必要があります。 クラウド環境の場合、追加データは Parquet ファイルとして提供する必要があり、Things CloudDataHub のオフロード設定で構成されているデータ レイクの特定のバケットに配置する必要があります。（オフロードジョブを介して作成されたParquetファイルのスキーマが一致しない場合） Things CloudDataHub のクエリ処理が破損するため、オフロードのターゲット テーブルとして使用されるフォルダーに Parquet ファイルを保存しないでください。

専用環境の場合、リレーショナル データベースなど、Dremio 経由でアクセスできるなら、追加データを別の場所に配置しても問題ありません。 ただし、パフォーマンスとコストの理由から、データと処理は常に同じ場所に配置する必要があります。

オフロードされたIoTデータを新しい追加データと組み合わせたい場合、Dremioで結合クエリを定義し、そのクエリをビューとして保存することができます。そのビューは、Dremio内の他のテーブルと同様にクエリでき、結合されたデータを提供します。

データレイク内のデータを修正する

Things CloudDataHubは、IoTデータをデータレイクにオフロードします。このプロセスでは、元のデータがリレーショナル形式に変換され、最終的にApache Parquet形式を使用してファイルに保存されます。各オフロード構成には、データレイク内に一意のフォルダがあり、これをターゲットテーブルと呼びます。そのフォルダ内のファイルは、時間情報に基づいたフォルダ階層で整理されています。データの効率的で特に正確なクエリを確実にするために、データレイク内のファイルは変更してはいけません。

しかし、稀にファイルの変更が必要になることがあります。古いデータを削除したり、1つまたは複数の列を削除したい場合があります。最初のステップは、このターゲットテーブルに関連するオフロード構成を停止して削除します。次に、データを外部から再度書き込むか、DremioのCTASクエリ機能を使用してこのターゲットテーブルからデータをクエリし、不要なデータをフィルタリングし、プロジェクションを使用して不要な列をスキップできます。クエリの結果を新しいデータレイクのフォルダに書き込む必要があります。フォルダをDremioのテーブルとしてアクセス可能にするために、フォルダをデータセットに昇格させます。次に、データレイクから古いフォルダを削除できます。その後、新しいフォルダ名をターゲットテーブル名として使用する新しいオフロード構成を定義する必要があります。データの形式が同じであることを確認するために、CTASクエリと同じフィルタ条件および列を定義します。オフロード構成を保存し、データを保存するために追加モードを選択し、オフロードを有効にします。

重要なのは、このユースケースはThings CloudDataHubによって公式にサポートされていないということです。データを再度書き込むことに特に問題はありませんが（またはこの方法でレガシーデータをインポートすることも）、手動で作成したファイルが必要なテーブルスキーマに準拠していない可能性が高く、その結果、対象のテーブルに追加のデータをオフロードすることができなくなり、つまり、対応するオフロードパイプラインが壊れてしまう可能性があります。特に、すべてのタイムスタンプ列 (time, timeWithOffset, creationTime, creationTimeWithOffset) に対して正しいデータ型 (TIMESTAMPMILLIS) を使用することに注意する必要があります。