Contour のコンピュート使用量

Foundry のデータで Contour ワークフローを実行するには、コンピュート秒単位で測定されるリソースである Foundry コンピュートを使用する必要があります。このドキュメントでは、Contour がコンピュートをどのように使用するかを詳しく説明し、製品内のコンピュート使用量を調査および管理するための情報を提供します。

データを表示する各 Contour ボードは、Contour バックエンドへのクエリを元にしています。Foundry は、自動スケーリングする Spark クラスターで Contour クエリを実行し、結果を返します。Contour クエリのコンピュート秒は、クエリが実行中に実際に使用したコンピュート秒のみに基づいて測定されます。ただし、インタラクティブモードでは、より高速なレスポンスを提供するため、すべての Contour 分析でコンピュートリソースが「常時稼働」しています。そのため、個々のインタラクティブクエリは、バッチコンピュートよりも高いレートでコンピュート秒を使用します。

クエリが使用するリソース量は、入力データセットのサイズやレイアウト、クエリの複雑さ（使用する Contour ボードなど）といった多くの要因によって異なります。

コンピュートの測定方法

Contour は、Foundry の並列化されたコンピュートバックエンドを使用して、Foundry データに対するクエリを実行します。そのため、Contour のコンピュートは次の式で測定されます。

total_compute_seconds = contour_usage_rate * (driver_compute_seconds + executor_compute_seconds)

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

Contour の「常時準備完了」の実行システムは、エンドユーザーによるアドホッククエリに即座に対応するよう設計されています。Foundry コンピュート秒で表される Contour クエリのコストは、Spark クラスターでクエリを実行するために必要な時間と、クエリの実行中に使用されるコア数に基づきます。コア数は、クエリがスケジュールされた Spark アプリケーションにおいて、そのクエリが占める割合から算出されます。

インタラクティブモードでは、Contour ボードが作成または更新されるたびにコンピュートが使用されます。これには、Contour パス内の特定のボードより下流にあるボードに影響する「連鎖的な」コンピュートも含まれます。たとえば、Contour 分析では次の操作でコンピュートが使用されます。

• 新しいボードの作成（すべての下流ボードに影響する場合があります）
• ボードの更新（すべての下流ボードに影響する場合があります）
• パスの上部にあるデータをアップデートするをクリック

バッチでの Contour の使用

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

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

Contour 使用量の調査

Contour のインタラクティブな使用量は、常にその実行元の分析に紐付けられます。特定の Contour 分析では、すべてのインタラクティブコンピュートが分析リソース自体に紐付けられます。

コンピュートを実行する個々のボードは、Builds アプリケーションで表示できる Spark メトリクスを生成します。これには、各ボードのコンテキストメニューにあるジョブを表示セクションからアクセスできます。Contour のバッチコンピュート使用量は、Code Repositories や Code Workbook と同様に、そのコンピュートが生成するデータセットに紐付けられます。インタラクティブコンピュートとバッチコンピュートのどちらについても、Resource Management アプリケーションで全体の使用量を表示できます。

使用量を左右する要因の理解

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

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

Contour ユーザーが増えると、クエリが増加するため、使用するコンピュートが増える場合があります。ただし、Contour には、多くのユーザーによるコンピュート使用量を削減するための2つの機能、Checkpoint とキャッシュがあります。

• Contour の Checkpoint は、Contour バックエンドによって自動的に管理されます。Checkpoint により、Contour はパスの後方にあるクエリ結果をすばやく返せます。これにより、大きな Contour パスで使用するコンピュートを時間の経過とともに削減できますが、コンピュートの使用が完全になくなるわけではありません。
• Contour は、同一のデータに対する同一のクエリの結果もキャッシュします。つまり、2人のユーザーが同じ Contour 分析を続けて開いた場合、計算は1回だけ実行されます。これにより、ダッシュボードをはるかに効率的に表示でき、ユーザー数がコンピュート使用量に与える影響が軽減されます。
  • 入力データやパラメーターを変更するとキャッシュは使用できなくなりますが、その同じ入力データとパラメーターで以降の計算を行う際には、再びキャッシュが使用されます。

Contour による使用量の管理

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

使用量の計算

Contour は、Code Repositories など、プラットフォーム内のほかの Spark ベースの製品と同じ Spark の測定原則に従って動作します。コストベースのルーティングにより、Contour はバックエンドのドライバーとエグゼキューターのサイズを自動的に最適化し、データサイズとクエリの種類に応じた要求に効率的に対応します。

 Example Contour Driver Size:
    num_vcpu: 2
    gib_ram: 11
 Example Contour Executor Size:
    num_vcpu: 2
    gib_ram: 12
    num_executors: 3
 Query Duration: 3 seconds
 Interactive Contour Usage Rate: 15

driver_compute_seconds = interactive_usage_rate * driver_compute_seconds
                       = 15 * max(2vcpu, 11gib / 7.5gib) * 3sec
                       = 15 * 2 * 3 = 90 compute-seconds

executor_compute_seconds = interactive_usage_rate * executor_compute_seconds
                         = 15 * max(2vcpu, 12gib / 7.5gib) * 3sec * 3executors
                         = 15 * 2 * 3 * 3 = 270 compute-seconds


total_compute_seconds = driver_compute_seconds + executor_compute_seconds
                      = 90 compute-seconds + 270 compute-seconds = 360 compute-seconds