データセットの最適化とキャッシング
AI/BIダッシュボードは、クエリ結果をキャッシュして読み込み時間を改善します。このページでは、ダッシュボードのキャッシュとデータセットの最適化の仕組み、ダッシュボードがキャッシュされた結果を使用する場合、およびSQLウェアハウスに対してクエリを再実行する場合について説明します。
クエリのパフォーマンス
クエリとそのパフォーマンスは、ワークスペースのクエリ履歴で調査できます。 クエリ履歴には SQL ウェアハウスを使用して実行されたクエリ SQLが表示されます。 サイドバーの「
クエリー履歴 」をクリックすると、クエリー履歴が表示されます。クエリ履歴を参照してください。
ダッシュボード データセットの場合、 Databricksデータセットの結果サイズに応じてパフォーマンスの最適化を適用します。 データセットのパフォーマンスしきい値については、 「データセットのパフォーマンスしきい値」を参照してください。
データセットの最適化
ダッシュボードは、可能な場合はブラウザ内で直接、フィルターまたは視覚化設定に基づいてフィルタリングと集計の操作を実行することで、速度を最適化します。これらのパフォーマンス最適化には次の制限があります。
データセットのサイズ | 処理動作 |
|---|---|
小規模（10万行以下、100MB以下） | ダッシュボードの速度を最適化するために、最初のデータセットが読み込まれた後、フィルタリングと集計はブラウザで実行されます。これらの操作はローカルで処理されるため、データウェアハウスとのさらなる対話が回避され、クエリ履歴には表示されません。 |
大規模（10万行以上または100MB以上） | フィルタリングと集約はブラウザではなくバックエンド サーバーで処理されます。最初のデータセット クエリは SQL |
複合クエリ（大規模データセット） | バックエンドに送信される視覚化クエリの場合、同じデータセットに対して同じ |
パラメーターは、実行時にクエリに直接値を代入するため、これらの操作は常にクエリ履歴に表示されます。
切り捨てられたテーブルをダウンロードするとクエリが実行されます。データセットが100,000行を超過したため、テーブルで切り捨てられた結果が表示される場合、CSVとしてデータをダウンロードするとSQLウェアハウスに対してクエリが実行されます。このクエリはクエリ履歴に表示されます。
キャッシュとデータの鮮度
ダッシュボードは、初期読み込み時間を最適化するために 24 時間の結果キャッシュを保持し、ベストエフォート方式で動作します。 つまり、システムは常にダッシュボードの資格情報にリンクされた履歴クエリ結果を使用してパフォーマンスを向上させようとしますが、キャッシュされた結果を作成または維持できない場合があります。 キャッシュされたデータには、特定のメモリ制限や固定のクエリ数はありません。
読み込み時間を改善するために、ダッシュボードは最初にダッシュボードキャッシュを確認します。キャッシュ結果が利用できない場合、汎用的なクエリー結果キャッシュを確認します。これら2つのキャッシュは異なる方法で無効化されます。クエリー結果キャッシュは、基になるデータの変更によってすべてのエントリが無効になるため、古いデータを返すことはありません。ダッシュボードキャッシュは、異なる無効化動作を持っています。基になるデータが変更されていても、ダッシュボードキャッシュは最大24時間前の結果を返すことがあり、基になるデータの変更によってダッシュボードキャッシュが自動的に無効化または更新されることはありません。
ダッシュボードキャッシュを確実に更新するには、ダッシュボードのスケジュールを設定してください。基になるデータが変更されても、ダッシュボードキャッシュはそれ自体では更新されず、パイプラインステップの一部としてデータを更新してもダッシュボードキャッシュは更新されません。スケジュールされた更新以外では、ダッシュボードキャッシュは、キャッシュが提供できないクエリーをダッシュボードが実行した場合にのみ更新されます。
ダッシュボードキャッシュから結果を提供しても、SQLウェアハウスは開始されません。ダッシュボードがキャッシュされた結果を返す場合、Databricksはクエリを実行せずにキャッシュから読み取るため、基盤となるSQLウェアハウスを実行する必要はありません。ウェアハウスは、ダッシュボードがキャッシュで提供できないクエリを実行した場合にのみ開始されます。
複数ページのダッシュボードには、以下が適用されます。
- ドラフトダッシュボードを編集すると、すべてのデータセットが読み込まれてキャッシュされます。
- 閲覧者が公開済みダッシュボードを開くと、アクティブ ページをサポートするデータセットのみが実行され、キャッシュされます。
- スケジュールが設定されている場合、すべてのデータセットはスケジュールに従って更新され、その結果はキャッシュされます。
次の表は、ダッシュボードのステータスと認証情報によってキャッシュがどのように異なるかを説明しています。
ダッシュボードの種類 | キャッシュタイプ |
|---|---|
共有データ権限で公開されたダッシュボード | 共有キャッシュ。 すべての視聴者に同じ結果が表示されます。 |
ドラフトダッシュボードまたは個別のデータ権限で公開されたダッシュボード | ユーザーごとのキャッシュ。 閲覧者には、データ権限に基づいて結果が表示されます。 |
ダッシュボードは、前回のクエリー後に基になるデータが変更された場合でも、結果が24時間以内に取得されたものであれば、自動的にキャッシュされたクエリー結果を使用します。古い結果が存在し、パラメーターがダッシュボードに適用されている場合、過去24時間以内に同じパラメーターが使用されていない限り、クエリーは再実行されます。同様に、100,000行を超えるデータセットにフィルターを適用すると、過去24時間以内に同じフィルターが以前に適用されていない限り、クエリーが再実行されます。
現在のタイムスタンプ機能とキャッシュの無効化
SQL クエリでcurrent_timestamp()または同様の関数を使用しても、ダッシュボード レベルのキャッシュは無効になりません。ただし、これらの関数は、SQL クエリを検査し、キャッシュの更新をトリガーするクエリ結果キャッシュを無効にします。
スケジュールされたクエリ
共有データ権限で公開されたダッシュボードにスケジュールを追加すると、すべてのダッシュボード閲覧者の初期読み込みプロセスが大幅に高速化されます。
スケジュールされたダッシュボードの更新ごとに、次の処理が行われます。
- データセットを定義するすべての SQL ロジックは、指定された時間間隔で実行されます。
- 結果はクエリ結果キャッシュに入力され、ダッシュボードの初期読み込み時間を短縮するのに役立ちます。