Contour でのコンピュート使用量

Foundry 上のデータで Contour ワークフローを実行するには、コンピュート秒という単位で測定される Foundry のコンピュートリソースが必要です。このドキュメントでは、Contour がコンピュートをどのように使用し、製品内でのコンピュート使用量の調査や管理に関する情報を提供します。

データを表示している各 Contour ボードは、Contour バックエンドへのクエリによってサポートされています。Foundry は、自動スケーリングの Spark クラスタで実行されるクエリによって Contour クエリを提供します。Contour クエリのコンピュート秒は、クエリが実行中に実際に使用するコンピュート秒に基づいて独占的に測定されます。ただし、インタラクティブモードでは、すべての Contour 分析のためにコンピュートリソースが「常時オン」になっており、より速い応答を提供します。これは、各インタラクティブクエリが、バッチコンピュートよりも速い速度でコンピュート秒を使用することを意味します。

クエリが使用するリソースの量は、入力データセットのサイズやレイアウト、クエリの複雑さ（使用する Contour ボードなど）など、多くの要素に依存します。

コンピュートの測定方法

Contour は、Foundry の並列化されたコンピュートバックエンドを利用して、Foundry データ上でクエリを実行します。したがって、Contour でのコンピュートは以下の式で測定されます。

# contour_usage_rateは使用率を示す変数です。
# driver_compute_secondsはドライバの計算時間（秒）を示す変数です。
# executor_compute_secondsはエグゼキュータの計算時間（秒）を示す変数です。
# total_compute_secondsは全体の計算時間（秒）を示す変数で、使用率と各計算時間の積で計算されます。
total_compute_seconds = contour_usage_rate * (driver_compute_seconds + executor_compute_seconds)

インタラクティブ Contour の使用

Contour の「常時稼働」の実行システムは、エンドユーザーによるアドホックなクエリに対応するように設計されています。Foundry のコンピュート秒に基づく Contour クエリのコストは、クエリを Spark クラスターで実行するのに必要な時間と、クエリが実行されている間に使用されるコアの数に基づいています。コアの数は、クエリがスケジュールされた Spark アプリケーションのシェアを見て算出されます。

インタラクティブモードでは、Contour ボードが作成または更新されるたびにコンピュートが使用されます。これには、Contour パス内の特定のボードから下流のボードに影響を与える「カスケーディング」コンピュートが含まれます。たとえば、以下のアクションでは Contour 分析でコンピュートが使用されます：

• 新しいボードの作成（すべての下流ボードに影響を与える可能性あり）
• ボードの更新（すべての下流ボードに影響を与える可能性あり）
• パスの上部で Update data をクリックする

バッチ Contour の使用

Contour パスはデータセットとして「保存」することができます。これにより、Contour バックエンドによって生成された基礎となるコードがデータセットジョブスペックに保存されます。このデータセットビルドはスケジュールまたはアドホックで実行することができます。これらのデータセットジョブはバッチジョブとして計測され、インタラクティブな Contour 使用に伴う「常時稼働」のオーバーヘッドは発生しません。

Contour のバッチデータセットは、汎用の並列化されたバッチ計算として測定されます。これは Code Repositories や Code Workbook を通じて作成および更新されるデータセットと同様です。これらのバッチ計算は、他のバッチ計算と同じレートでコンピュートを使用します。

Contour の使用状況の調査

Contour からのインタラクティブな使用は、それがトリガーされる分析に常に付随しています。特定の Contour 分析については、すべてのインタラクティブなコンピュートは分析リソース自体に付随しています。

コンピュートを実行する個々のボードは、Builds アプリケーションから見ることができる Spark メトリクスを生成します。これは各ボードのコンテキストメニューの View jobs セクションからアクセスできます。Contour からのバッチコンピュートの使用は、コンピュートが生成するデータセットに付随しています。これは Code Repositories や Code Workbook と同様です。インタラクティブおよびバッチコンピュートの両方について、ユーザーは Resource Management Application で全体の使用状況を見ることができます。

使用状況の要因の理解

Contour は Spark 計算フレームワーク上で動作し、そのため主に2つの要素に影響を受けます：データの規模とクエリの複雑さ（データ上で実行される操作の数とタイプ）。データに対して実行する必要のある操作が多いほど、結果を計算するためにバックエンドが使用するコンピュートは増えます。ただし、一部の操作は他の操作よりも負荷が高いため、操作を追加して全体の使用量を減らすことが可能です（例えば、高負荷な操作の前にフィルターを追加するなど）。

データに対する操作の数は、Contour パス内のボードの数に影響されます。パス内で下にあるボードは、パス内で前にあるボードからの出力に依存しています。新しいボードをパスに追加すると、パスを通じて送信されるデータが変わり、ボードの再計算と更なるコンピュートが必要になります。

より多くの Contour ユーザーがいると、クエリの増加によりコンピュートが増える可能性があります。しかし、Contour には多くのユーザーによるコンピュート使用量を減らすための2つの機能があります：チェックポイントとキャッシング。

• Contour の チェックポイントは Contour バックエンドによって自動的に管理されます。チェックポイントにより、Contour はパス内で下にあるクエリの結果を迅速に提供できます。これにより、時間とともに大規模な Contour パスからのコンピュートを減らすことができますが、コンピュートを完全になくすことはできません。
• また、Contour は同一のデータ上での同一のクエリの結果を キャッシュします。つまり、2人のユーザーが連続して同じ Contour 分析を開く場合、計算は一度だけ実行されます。これにより、ダッシュボードがはるかに効率的に提供され、ユーザー数がコンピュート使用量に及ぼす影響が軽減されます。
  • 入力データを変更したりパラメーターを変更したりするとキャッシュを使用できなくなることに注意してくださいが、その後、同じ入力データとパラメーターでの計算は再びキャッシュを使用します。

Contour を使用した使用状況の管理

分析と入力データセットの最適化により、コストと分析時間を削減することができます。Contour の最適化について詳しく学ぶ。

使用状況の計算

Contour は Code Repositories などのプラットフォーム内の他の Spark ベースの製品と同じ Spark 計測原則の下で動作します。コストベースのルーティングを使用すると、Contour はバックエンドのドライバーとエグゼキューターのサイズを自動的に最適化して、データサイズとクエリタイプの要求を効率的に満たすことができます。

 Example Contour Driver Size: // コンター ドライバー サイズの例
    num_vcpu: 2 // 仮想CPUの数
    gib_ram: 11 // ギガバイト単位のRAM
 Example Contour Executor Size: // コンター エグゼキュータ サイズの例
    num_vcpu: 2 // 仮想CPUの数
    gib_ram: 12 // ギガバイト単位のRAM
    num_executors: 3 // エグゼキュータの数
 Query Duration: 3 seconds // クエリ実行時間: 3秒
 Interactive Contour Usage Rate: 15 // インタラクティブ コンター使用率

# ドライバーの計算秒数をインタラクティブ使用率とドライバーの計算秒数で算出します
driver_compute_seconds = interactive_usage_rate * driver_compute_seconds
                       # 15倍する最大値(2vcpuと11gib / 7.5gibの大きい方)と3秒を掛け算します
                       = 15 * max(2vcpu, 11gib / 7.5gib) * 3sec
                       # 15 * 2 * 3 = 90 計算秒となります
                       = 15 * 2 * 3 = 90 compute-seconds

# エグゼキューターの計算秒数をインタラクティブ使用率とエグゼキューターの計算秒数で算出します
executor_compute_seconds = interactive_usage_rate * executor_compute_seconds
                         # 15倍する最大値(2vcpuと12gib / 7.5gibの大きい方)と3秒を掛け算し、さらにエグゼキューター数3を掛けます
                         = 15 * max(2vcpu, 12gib / 7.5gib) * 3sec * 3executors
                         # 15 * 2 * 3 * 3 = 270 計算秒となります
                         = 15 * 2 * 3 * 3 = 270 compute-seconds

# 合計の計算秒数はドライバーの計算秒数とエグゼキューターの計算秒数の合計です
total_compute_seconds = driver_compute_seconds + executor_compute_seconds
                      # 90 計算秒 + 270 計算秒 = 360 計算秒となります
                      = 90 compute-seconds + 270 compute-seconds = 360 compute-seconds