分析用データ
分析用データ メトリクスは、容量のうちどれだけが使用されているかを示します。このトピックでは、カウントされるデータおよび除外されるデータの内容について説明します。また、使用量の計算方法についても説明します。これらの詳細を理解することで、何が Qlik Cloud の容量を消費しているかを把握し、データをより効率的に管理できるようになります。
メトリクスに含まれるデータ
「分析用データ」メトリクスは、環境にロードされ、保存されているデータの総量を測定します。
カウントされるデータ
このメトリクスには次が含まれます。
-
外部ソースから Qlik Cloud にロードされたデータ
-
リロードによって新しい増分データが追加されると、データ カウントが増加します。リロードに含まれるデータ量が以前より少ない場合、データ カウントはそれに応じて減少します。
-
複数のテナントにロードされたデータは、テナントごとに個別にカウントされます。
-
一度ロードされ、同じテナント内の複数のアプリで使用されるデータは、1 回のみカウントされます。
-
-
Qlik Cloud にアップロード、または作成されたデータファイル
-
アップロードまたは作成されたファイルのファイル サイズがカウントされます。
-
Qlik Cloud 内でデータ ファイルをコピーすると、新しいファイルがメトリクスにカウントされます。
-
共有スペースでアプリをリロードせずに複製しても、カウントは増加しません。
-
メトリクスの計算方法
分析用データメトリクスは、次のように計算されます。
-
Qlik Sense アプリ経由で Qlik Cloud に取り込まれる外部データの量。
-
Qlik データ ゲートウェイ - データ移動 経由で Qlik Cloud にロードされる外部データの結果の QVD ファイル サイズ。
-
Qlik Cloud にアップロードされるデータ ファイルのファイル サイズ。
-
QVF としてアップロードされたアプリのファイル サイズ。アプリの基本 RAM フットプリントとして測定されます。
カウントされないデータ
メトリクスには次のデータは含まれません。
-
ユーザーの個人スペースにあるアプリとデータ。これには、任意のソースからロードされた、またはオンデマンドアプリ生成 (ODAG) を使用して個人スペースで生成されたアプリまたはデータが含まれます。
-
このメトリクスは、アプリの場所に基づいており、データ接続の場所には基づいていません。個人スペースのアプリは、共有スペースの接続を使用している場合でもカウントされません。共有スペースのアプリは、常にメトリクスの対象としてカウントされます。
-
-
Qlik Cloud に保存されている別のアプリをバイナリ ロードするだけのアプリ。元のアプリはすでにカウントされているため、ロードするアプリはメトリクスに追加されません。
-
Qlik Cloud に保存されているファイル (QVD など) からのみデータをロードするアプリ。QVD はすでに別途カウントされています。
-
管理スペースに公開されたアプリとデータ。管理スペースでのアプリのリロードはカウントされます。
-
Direct Query を介してロードされたデータ。
分析用データ容量のサブスクライブ
分析用データの要件に基づいて、データ パックをサブスクライブします。
各ユーザーは、サブスクリプションに含まれる容量に加えて、個人スペースで利用できる一定量の容量を持っています。この容量は、分析用データのメトリクスの合計にはカウントされません。
Qlik Cloud Analytics Starter エディションには固定のデータ容量があり、このエディションのサブスクリプションはユーザー数に基づいています。
Qlik Cloud へのデータの移動
データの移動には、次のようなオプションがあります。
-
Qlik Sense からの直接データ接続
-
Qlik Data Gateway - 直接アクセス
-
Qlik Talend Data Integration を使用した Qlik Cloud へのデータ移動
Qlik Cloud の Premium エディションと Enterprise エディションを使用すると、任意のソースから Qlik Cloud Analytics にデータを移動できます。Standard エディションでは、SAP、メインフレーム、レガシー ソースを除くあらゆるソースからのデータを移動できます。
分析用データ量の計算
分析用データの計算方法を理解することで、容量を効率的に使用することができます。このセクションでは、月次ピーク、データ ロード、アプリのリロード、データ作成の測定方法について説明します。
月次ピークと日次ピーク
分析用データの容量を購入すると、使用量は購入した量に対して測定されます。システムは毎日使用量を記録し、その月の使用量がもっとも多かった日が月次ピーク (高基準値) となります。たとえば、250 GB の容量を購入し、月次ピークがこの容量を超えると、超過料金が発生する場合があります。
毎日の使用量の追跡方法
お客様の利用状況は毎日追跡されます。毎日、システムは 1 日のピークを以下の合計として計算します。
-
保存されているファイルの合計サイズ
-
アプリのリロード中に取り込まれるデータ量
-
派生または作成されたデータの量
以前にロードされたものの、リロードされていないアプリも使用量に含まれます。システムは、新しいリロードが行われるかアプリが削除されるまで、前回のロード時のデータを引き継ぎます。
繰り越しの仕組み
特定の日にアプリがリロードされない場合、システムは前回の正常なリロードで取り込まれたデータを引き継ぎます。アプリは、新しいリロードで異なる量のデータが取り込まれるまで、この量を日次ピーク使用量に加算し続けます。
新しい月が始まると、月次ピークはリセットされます。ただし、新しい月の初日の日次ピーク使用量には、前月の最終リロードから引き継がれた値が含まれる場合があります。そのため、報告される使用量が、アプリで現在表示されているデータ量よりも多く見えることがあります。
例:
-
1 日目: テナントは 70 GBのデータ ファイルを保存し、アプリのリロードを通じて40 GBを取り込みます。日次ピークは 110 GB です。
-
2 日目: テナントは 70 GBのデータ ファイルを保存し、リロードは行われません (取り込まれたデータは 0 GB)。以前に取り込まれた 40 GB が引き継がれるため、日次ピークは 110 GB のままです。この値を減らすには、40 GB 未満のデータを取り込む新しいリロードが必要です。
月次ピークと高基準値
月次ピークとは、その月に記録された日次ピーク値の中でもっとも高い値のことです。これは、データ使用量の合計が最も多かった日を示す、高基準値として機能します。月次ピーク値を購入容量と比較し、超過料金が適用されるかどうかを判断します。
例 - 1 日の使用量から月次ピークを特定
月次ピークがどのように決定されるかを示すため、この例では 4 日間だけ、購入容量 250 GB の単純化したシナリオを使用します。使用量は、1 日の最高ピークが月次ピークになることを説明するのに役立ちます。
このデータ テーブルは、4 日間のデータ使用量をタイプ別に分類したものです。
| 日 | 保存 | リロード | 作成日 | 日次ピーク |
|---|---|---|---|---|
| 1 | 50 GB | 30 GB | 15 GB | 95 GB |
| 2 | 70 GB | 40 GB | 30 GB | 140 GB |
| 3 | 60 GB | 0 GB | 20 GB | 120 GB |
| 4 | 80 GB | 50 GB | 40 GB | 170 GB |
テーブル データの理解:
-
3 日目はデータのリロードはありません。2 日目のリロード分 (40 GB) は繰り越され、日次ピーク (120 GB) に加算されます。
-
4 日目は日次ピークがもっとも高く (170 GB)、これが月次ピークとなります。
月次ピークが購入容量 250 GB 以内であるため、超過料金は適用されません。使用量が 250 GB を超えた場合、超過料金が発生したり、容量のアップグレードが必要になることがあります。
保存、インジェスト、作成されたデータを示す 4 日間の 1 日ごとの使用量。緑の線は購入した容量を示しています。

Qlik Cloud へのデータのロード
外部ソースから Qlik Cloud にロードされたデータは、日次ピークにカウントされます。
-
同じデータ セットが複数のアプリに個別にロードされた場合、各ロードは個別にカウントされます。
-
一度テナントにロードされたデータは、そのテナント内の複数のアプリで再利用でき、再度カウントされることはありません。複数回のカウントを避けるには、データを一度 QVD ファイルにロードし、複数のアプリがそれらの QVD から読み取るようにすることを検討してください。
-
複数のテナントにロードされたデータは、テナントごとに個別にカウントされます。
データが日次ピークに加算される仕組み:
-
アプリ経由でロードされたファイルベースのデータ: ファイル サイズに応じて測定されます。
-
クエリまたはコネクタを使用したアプリのリロード: データ ソースから取り込まれた最大バイト数としてカウントされます。同じ日に複数回のリロードが発生した場合、最大のリロードのみが日次ピークにカウントされます。
例: アプリが 1 日に 0.75 GB、1.25 GB、1 GBで 3 回リロードしたとします。1.25 GB のみが日次ピークに加算されます。
情報メモリロードが一度カウントされると、その日のうちにアプリが削除されたとしても、それは日次ピークの一部として残ります。取り込まれた最大バイト数は、アプリがテナントに存在する限りカウントされます。 -
Qlik データ ゲートウェイ - データ移動 経由で Qlik Cloud にロードされたデータ: 出来上がった QVD ファイルのサイズで測定されます。
-
分析 アクティビティ センター内または qlik-cli を使用して、ファイル インポートによってアップロードまたはロードされたアプリ: アプリの情的バイト サイズで測定されます。
-
アップロードされた QVD ファイル: ファイル サイズで測定されます。
データは、アプリ経由、データ移行、または 分析 アクティビティ センターや qlik-cli を使用したインポートなど、さまざまな方法で Qlik Cloud にロードできます。
次の状況では、データは日次ピークの計算に含まれません。
-
ユーザーの個人スペースにロードされたデータは、個人スペース内に制限される場合に限り、カウントされません。他のユーザーと共同作業をするためにデータを共有スペースに移動した場合はカウントされます。
-
リロードに失敗した場合、取り込まれたバイトはカウントされません。ただし、結果の QVD ファイルはすべてカウントされます。
-
Qlik Cloud にすでに存在するデータを含むアプリをロードする場合、データのロードはカウントされません。たとえば、コピーまたはバイナリでロードされたアプリ (別の Qlik Sense アプリからデータをロード) は、外部ソースからリロードされない限り、1 日のピークに影響を与えません。
内部ソースからのアプリのリロードは、日次ピークに影響を与えません。
アプリのリロードで取り込まれたバイト数の測定
外部ソースから Qlik Sense アプリをリロードする場合、次のことが適用されます。
-
データ量が変わらない場合に限り、日次ピークに影響を与えることなく、同じソース データセットからアプリを複数回リロードできます。
-
ソース データセットのサイズが増加すると、日次ピークに影響が出ます。データセットに追加されるデータの各 GB と同等の量が、リロード中に取り込まれるデータに寄与されます。
-
逆に、ソース データセットのサイズが減少すると、その減少分は日次ピークにも反映されます。
例: データセットのサイズが 0.25 GB 減少すると、リロード サイズも同じ量だけ減少します。ただし、その日の早い時間に 1 GB のリロードが発生した場合、その日の日次ピークは 1 GB のままになります。この減少分は翌日の日次ピークにのみ反映されます。
-
ソース データセットの内容が変更されても、そのサイズが変更されない限り、日次ピークには影響しません。日次ピークに影響するのはデータ量のみです。
ソース データセットのサイズまたは内容が変更されたときに取り込まれるバイト数の測定。
-
1 つのロード スクリプト内で同じデータセットに複数回クエリを実行する場合、各クエリはすべて個別にカウントされます。総データ量は、すべてのクエリの合計です。
例: 同じデータセットから 1 GB ずつの 3 つのクエリを含むロード スクリプトがある場合、それらの 3 つのクエリはすべて個別にカウントされます。したがって、日次ピークにカウントされる合計データ量は 3 GB になります。
-
アプリをロードした後にテーブルを削除しても、日次ピークは減少しません。日次ピークは、アプリのその日の最大リロード サイズに基づいているためです。
-
アプリをロードして同じ日に削除した場合でも、そのアプリはその日存在していたため、その日の日次ピークにカウントされます。翌日にはアプリは存在しないため、日次ピークには影響しません。
異なるアプリのリロード シナリオで取り込まれたバイト数の測定。
Qlik Talend Data Integration を使用して QVD ファイルにロードされたデータの測定
Qlik データ ゲートウェイ - データ移動 を使用して外部ソースから QVD ファイルにデータをロードする場合、次のことが適用されます。
-
データセットを複数回アップロード、インポート、または生成しても、データ量が変化しない限り、日次ピークには影響しません。
-
ソース データセットのサイズが増加すると、日次ピークに影響が出ます。追加されるデータ 1GB ごとに、結果として生成される QVD ファイルのサイズも同量増加します。
-
QVD ファイルのサイズが 1 日の間に変化した場合、到達した最大サイズが記録されます。日次ピークは、常にその日に観測された最大サイズを反映します。
-
ソース データセットのサイズが減少した場合も、その減少分は日次ピークに反映されます。
例: データセットが 0.25 GB 減少すると、QVD ファイルのサイズも同量減少します。
-
データセットの内容が変更されてもサイズが変わらない場合は、日次ピークには影響しません。日次ピークに影響するのはデータ量のみです。
ソース データセットのサイズまたは内容が変更された場合の QVD ファイル サイズの測定。
外部ソースと内部ソースからのアプリのロード
アプリにロードされるデータが日次ピークに与える影響は、ソースに応じて異なります。次のシナリオは、さまざまな種類のデータがどのように影響するかを示しています。
-
外部ソースからアプリにロードする
外部ソースからロードされたデータは、取り込まれたバイト数としてカウントされます。
例: 10 GB のデータがロードされた場合、アプリは日次ピークに10 GB 加算されます。
-
Qlik Cloud の QVD からアプリにロードする
Qlik Cloud に保存されている QVD ファイルからデータをロードしても、アプリの外部データ取り込み量としてはカウントされません。
例: アプリが QVD ファイルから 10 GB のデータをロードした場合、アプリの加算分は 0 GB です。QVD ファイルは別途 10 GB 加算されます。
-
Qlik Cloud の QVD から新しい QVD ファイルを生成する
QVD ジェネレーターアプリが Qlik Cloud の既存の QVD ファイルからデータをロードする場合、アプリの加算分は 0 GB です。生成された QVD ファイルがカウントされます。
例: 10 GB の QVD ファイルが新しい 5 GB の QVD ファイルに変換された場合、日次ピークへの合計加算分は 15 GB です。
-
外部ソースと内部ソースの両方からアプリにロードする
アプリが外部ソースから 10 GB、Qlik Cloud の QVD から 5 GB をロードする場合、アプリの外部データ取り込み量としてカウントされるのは 10 GB のみです。QVD ファイルは別途 5 GB として加算されるため、日次ピークへの合計加算分は 15 GB になります。
データ ファイルと、内部ソースと外部ソースからのロード時に取り込まれたデータの合計の測定。
Qlik Cloud でのデータ作成
Qlik Cloud で新しいデータを作成すると、データ ファイルのコピーであるか、既存の生データを組み合わせた派生であるかにかかわらず、そのデータは日次ピークにカウントされます。データは、作成プロセスで生成されたファイルの合計サイズとして測定されます。作成されたデータは、使用するアプリの数に関係なく、1 回のみカウントされます。
例:
-
STORE ステートメントを使用して 1 GB QVD ファイルを作成すると、日次ピークに 1 GB が追加されます。
-
1 GB の QVD ファイルをコピーすると、両方のコピーが合計に寄与するため、日次ピークに 1 GB が追加されます。
-
変換を通じて 0.5 GB の QVD ファイルを作成すると、日次ピークに 0.5 GB が追加されます。結果として得られる QVD ファイルのみがカウントされます。 QVD ジェネレーター アプリは、すでに Qlik Cloud にあるデータをロードするため、カウントされません。
Qlik Cloud で作成されたデータ ファイルの測定。
データ管理のベストプラクティス
効率的なデータ管理は、分析用データ容量を最大限に活用するのに役立ちます。以下の推奨事項は、Qlik Cloud におけるデータ ロードの最適化、不要なストレージの削減、古いデータや非アクティブなコンテンツの管理方法について説明しています。
データを再利用するために QVD ファイルを作成する
複数のアプリでデータを共有する場合は、QVDファイルを使用します。外部データを一度ロードし QVDとして保存することで、繰り返しの取り込みが減り、日次ピークを低く抑えることができます。Qlik データ ゲートウェイ - データ移動 を使用して QVD ファイルでデータを再利用するほうが、データをアプリケーションに直接リロードするよりも一般的に効率的です。
例:
10 GB の外部データを一度ロードし、5 GB の QVD ファイルとして保存した場合、日次ピークにカウントされる合計データは 15 GB です。5 GB の QVD をロードするアプリは、元の 10 GB のデータを再度取り込む必要はありません。一方、同じ 10 GB の外部データを 2 つのアプリに直接ロードすると、取り込みが 2 回行われ、20 GB がカウントされます。
外部データを各アプリに直接ロードするよりも、QVD ファイルを作成し、そこから複数のアプリにデータをロードするほうが効率的です。
効率的なデータ ロードの方法を使用する
データ ソースでフィルタリングと変換を適用 (SQL プッシュダウン) することで、データのリロード時に転送されるデータを削減します。
例:
このクエリでは、フィルターはソース側で適用されるため、データの一部のみが転送されます。
大規模なデータセットにオンデマンド アプリを使用する
オンデマンドアプリ生成 (ODAG) を使用すると、まず集計データをロードし、必要なときにのみ詳細なサブセットを取得することで、大規模なデータセットを処理できます。
詳細については、「On-demand アプリ」を参照してください。
Direct Query とダイナミック ビューで大規模なデータセットを処理する
Direct Query とダイナミック ビューを使用すると、すべてのデータをメモリにロードすることなく、オンデマンドで大規模なデータセットをクエリできます。必要なデータのみを照会することで、これらのアプローチにより取り込み量が削減され、使用量を容量制限内に抑えることができます。
詳細は以下をご覧ください。
古いまたは未使用のアプリを管理する
テナント内のアプリは、最後に正常にリロードされた時点に基づいて、分析用データの使用量に影響を与え続けます。データがロードされたアプリが存在する限り、そのアプリは容量レポートに影響を与え続けます。
不要な使用量を避けるには:
不要なデータを削減または削除する
完全なデータセットが不要になったアプリからデータを削除するか、構造のみが必要な場合はデータのないアプリを作成します。より小さなデータセットでアプリをリロードすると、報告される使用量が更新されます。
不要な複製を避ける
アプリは必要な場合にのみコピーしてください。各コピーは個別のアプリとして扱われ、容量使用量に影響します。
共有スペースを意図的に使用する
共有スペースを使用することで、リロードの場所と方法を制御できます。
不要になったアプリを削除する
定期的なクリーンアップにより、古いコンテンツが容量を消費するのを防ぎます。
-
カタログで [最終更新日]、 [Viewed by] (閲覧者)、 [Used in] (使用場所) を確認して、使用されていないアイテムを特定します。
-
影響分析と系列を使用して、データ ファイルがどこで使用されているかを把握します。
-
アクティビティ センターから使用されていないアプリとデータファイルを削除します。管理者は、管理画面からもアプリを削除できます。
詳細は以下をご覧ください。
リロード関連の消費量を削減する
アプリのリロードによって報告されるサイズは、リロードによってデータセットが小さくなった場合にのみ減少します。報告されるサイズを減らすには、より少ないデータでアプリをリロードし、報告されるサイズを更新します。
アプリのリロード動作
-
新しいデータなしでのリロード:
新しいデータを追加せずにアプリをリロードした場合、報告されるサイズは変わりません。
例: アプリが以前と同じデータセットでリロードされます。追加データやデータ量の削減が行われていないため、報告される使用量は変化しません。
-
取り込み後にアプリが空になる:
アプリがすべてのテーブルを削除し、データ モデルが空になったとしても、最後に正常に実行されたデータ取り込みは日々の使用量に加算されます。
例: アプリが 10 GB の外部データを取り込み、QVD ファイルを生成し、スクリプトの最後にすべてのテーブルを削除します。アプリは空になりますが、取り込まれた 10 GB は日々の使用量に加算されます。
-
アプリを別のスペースにコピーする:
アプリを別のスペースにコピーすると、別のアプリとして扱われ、容量使用量に再度カウントされます。
リロード関連の消費量を制限する方法
次の 2 つの方法のいずれかを使用して、リロード関連のデータ消費量を削減できます。どちらの方法もアプリからデータを削除します。
-
ロード スクリプトを早期に停止する: ロード スクリプトの先頭に Exit script; ステートメントを追加して、データなしでアプリをリロードします。完全なデータが必要な場合は、このステートメントをコメント アウトするか、特定のシナリオ (例: アプリが特定のスペースにある場合など) でのみ実行されるように条件を適用します。
-
データなしでアプリを再作成する: データなしでアプリをダウンロードし、新しいアプリとしてインポートします。新しいバージョンを検証した後、元のアプリを削除します。