注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
分析の最適化
Contour の分析とダッシュボードのパフォーマンスを改善するには、以下の推奨事項に沿って進めてください。
分析の構成
重複するロジックの最小化
分析に、ほぼ重複するロジックを適用して複数の出力を計算するパスが複数含まれる場合（たとえば、複数のパスで同じフィルター条件を適用し、最後の数個のパスだけで新しいメトリクスを計算する場合）は、こうしたパスの重複を最小限に抑えます。代わりに、共通の入力パスを使用し、そのパスの結果をほかのパスの入力として使用します。
結合
結合前にデータセットを可能な限り絞り込みます。データセットを新しい Contour パスで開き、フィルター条件を追加してから、データセットではなくそのパスの結果に結合することで、結合前にデータセットを絞り込めます。これにより、パフォーマンスが大幅に改善することがあります。
「いずれかに一致」を使用した複数条件での結合
「いずれかに一致」を使用する複数条件の結合は、データが分散しているため、Spark では特に多くのリソースを消費します。フィルターを上流に移すなどして、操作前に規模を可能な限り縮小してください。分析の設計を変えることで、複数条件の結合を回避できることがよくあります。たとえば、個別の結合を複数適用し、その結果をユニオンする方法があります。
データセットとして保存
ボードまたは一連のボードの出力を、下流の複数のボード（同じパス内または異なるパス内）で使用する場合は、出力を Foundry データセットとして保存し、新しく保存したデータセットから下流のすべての計算を開始すると、非常に効果的な場合があります。出力に複雑な計算（たとえば、結合、ピボットテーブル、正規表現フィルター）が含まれる場合は、特に効果的です。
パラメーターの使用
ユーザーがパラメーターの値を変更すると、分析内のすべてのボードが再計算されます。起点となるデータセットがあり、パラメーターを使用しない多くの計算を行った後に、パラメーターを使用するフィルターを適用する分析を考えてみます。可能であれば、パラメーターを使用しない計算の後で、出力をデータセットとして保存します。これにより、新しいパラメーターが入力されたときに、レポート内のチャートやグラフの再計算と更新がすばやく行われます。
フロントエンドのパフォーマンス
分析をすばやく読み込み、応答性を確保するために、分析ごとのパス数を15～20個以下にすることを推奨します。この上限を超える場合は、分析を複数の分析に分割します。
フィルターの使用
可能な限り具体的なフィルターを使用
フィルターを適用するときは、大文字と小文字を区別する設定を有効にする、「含む」よりも「完全一致」のフィルターを優先する、または元のデータをすべて大文字かすべて小文字に統一します。特に、正規表現の使用は計算コストが高くなります。
たとえば、データセットの文字をすべて小文字かすべて大文字に統一し（大文字と小文字を区別する絞り込みを有効にするため）、絞り込み条件を可能な限り正確にして完全一致を使用する（たとえば、テキストに対して contains ではなく is を使用する）ことで、パフォーマンスが改善する場合があります。
列のデータ型に適したフィルターの適用
列のデータ型に適した種類のフィルターを使用してください。
たとえば、integer、long、double 型の列で特定の数値に一致するフィルターを適用する場合、「数値が等しい」フィルターを使用すると、「文字列の完全一致」フィルターよりも大幅に高速になります。
入力データセット
パーティショニング
Contour の分析で使用するデータセットが適切にパーティショニングされていることを確認してください。データセット内のファイルの平均サイズは、少なくとも128 MB にする必要があります。データセットを開いて「概要」タブを選択すると、ファイル数とデータセットのサイズを確認できます。
以下の例では、ファイル数は80個で、データセットのサイズは365 MB です。ファイル数は最大でも3個であるべきなので、これは適切にパーティショニングされていません。
入力データセットが適切にパーティショニングされていない場合は、上流のトランスフォームでパーティショニングできます。
上流の Python トランスフォームでパーティショニングするには、次のコード行を追加します。
# パーティションの再分割 – df.repartition(num_output_partitions)
df = df.repartition(3)
パーティショニングと、それが Spark に及ぼす影響の詳細については、Spark の最適化の概念を参照してください。
プロジェクション
データセットの所有者は、データセットにプロジェクションを設定して、さまざまな種類のクエリのパフォーマンスを改善できます。
入力データセットにプロジェクションが設定されている場合、以下に示すように、開始ボードの最適化済みセクションにプロジェクションが一覧表示されます。一覧にある列のいずれかに完全一致フィルターを設定することで、プロジェクションを活用できます。現在、Contour が情報を表示するのは、入力データセットのすべての列を含む、フィルター向けに最適化されたプロジェクションのみです。
一般的に、Contour のパフォーマンスを改善するために、クエリパターンを予測できるデータセットにプロジェクションを設定することを推奨します。コンピューティング使用量を削減するため、データセットが頻繁に使用される場合（つまり、1回の書き込みに対して特定のパターンの読み取りが10～100回ある場合）にのみプロジェクションを設定することを推奨します。プロジェクションのビルドと保存には、データセットへの書き込みのたびに追加の計算が必要になるため、その計算が下流で継続的に活用される場合にのみ、使用量の削減につながります。
分析の保守と共有
Contour の分析を多数の対象ユーザーが利用する場合、上記のすべての最適化が特に重要になります。
ビルドのスケジュール設定
Contour でビルドするデータセットのスケジュールを設定するときは、頻度を十分に検討します。スケジュールを設定した後はビルドを監視し、不要なビルドでリソースを消費することなく、必要な頻度でデータが利用可能になっていることを確認してください。たとえば、Contour でビルドするデータセットの入力が毎日更新されるデータセットである場合、そのデータセットを毎時間ビルドする必要はありません。
パラメーター数の制限
Contour の分析をレポート内で多数の対象ユーザーが利用する場合は、パラメーターの数を最小限に抑えることを推奨します。
理想的なレポートウィジェットは、ユーザーが入力したパラメーター値に基づいて絞り込みを行い、その後に集計を行って、ユーザーに関連する可視化を表示します。理想的には、それ以外の複雑なロジック（結合やピボット）をすべて Foundry のデータセット内で事前に計算しておき、パラメーターを変更するたびに再計算が必要にならないようにします。