データセットの最適化とキャッシュ

AI/BI ダッシュボードは重要なデータ分析および意思決定ツールであり、効率的な読み込み時間によってユーザー エクスペリエンスを大幅に向上できます。 この記事では、キャッシュとデータセットを最適化して、どのようにダッシュボードのパフォーマンスと効率を向上するかについて説明します。

検索性能

クエリとそのパフォーマンスは、ワークスペースの Query History で調べることができます。 クエリ履歴には、SQL ウェアハウスを使用して実行された SQL クエリが表示されます。 [サイドバーのクエリ履歴でクエリ履歴を表示します。 「クエリ履歴」を参照してください。

ダッシュボード データセットの場合、Azure Databricks では、データセットの結果のサイズに応じてパフォーマンスの最適化を適用します。 データセットのパフォーマンスしきい値の詳細については、「 データセットのパフォーマンスしきい値」を参照してください。

データセットの最適化

ダッシュボードは、フィルターまたは視覚化の設定に基づくフィルター処理と集計操作を可能な限りブラウザーで直接実行することで、速度を最適化します。 これらのパフォーマンスの最適化には、次の制限があります。

キャッシュとデータの鮮度

ダッシュボードでは、最初の読み込み時間を最適化するために 24 時間の結果キャッシュを維持し、ベストエフォート ベースで動作します。 つまり、システムでは常に、ダッシュボード資格情報にリンクされた履歴クエリの結果を使用してパフォーマンスを向上しようとしますが、キャッシュされた結果の作成や維持ができない場合があります。 キャッシュされたデータには、特定のメモリ制限や固定クエリ数がありません。

読み込み時間を短縮するために、ダッシュボードではまずダッシュボード キャッシュを確認します。 キャッシュ結果が使用できない場合は、汎用 クエリ結果キャッシュを確認します。 ダッシュボード キャッシュは最大 24 時間古い結果を返すことができますが、クエリ結果キャッシュは古いデータを返すことはありません。 基になるデータが変更されると、すべてのクエリ結果キャッシュ エントリが無効になります。

マルチページ ダッシュボードの場合は、次が適用されます。

• 下書きダッシュボードを編集すると、すべてのデータセットが読み込んでキャッシュされます。
• 閲覧者が発行済みのダッシュボードを開くと、アクティブなページをサポートするデータセットのみが実行され、キャッシュされます。
• スケジュールが設定されている場合、すべてのデータセットがスケジュールに従って更新され、それらの結果がキャッシュされます。

次の表では、ダッシュボードの状態と資格情報によってキャッシュがどのように変わるかについて説明します。

ダッシュボードでは、基になるデータが最後のクエリの後に変更されていない場合、または結果が過去 24 時間以内に取得された場合は、キャッシュされたクエリ結果が自動的に使用されます。 古い結果が存在し、パラメーターがダッシュボードに適用されている場合、過去 24 時間以内に同じパラメーターが使用されていない限り、クエリは再実行されます。 同様に、10 万行を超えるデータセットにフィルターを適用すると、過去 24 時間以内に同じフィルターが適用されていない限り、クエリの再実行が求められます。

現在のタイムスタンプ関数とキャッシュの無効化

SQL クエリで current_timestamp() などの関数を使用しても、ダッシュボード レベルのキャッシュは無効になりません。 ただし、これらの関数によってクエリ結果キャッシュが無効になり、SQL クエリが検査され、キャッシュの更新がトリガーされます。

スケジュール済クエリ

共有データのアクセス許可を使用して公開されたダッシュボードにスケジュールを追加すると、すべてのダッシュボード ビューアーの初期読み込みプロセスが大幅に高速化される可能性があります。

スケジュールされたダッシュボードの更新ごとに、次の処理が行われます。

• データセットを定義するすべての SQL ロジックは、指定された時間間隔で実行されます。
• 結果はクエリ結果キャッシュに入力され、ダッシュボードの初期読み込み時間を短縮するのに役立ちます。