ドキュメントの検索
karat

+

K

APIリファレンス ↗

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

タイムシリーズクエリのコンピュート使用量

Foundry は、タイムシリーズクエリに最適化された形式でディスク上にタイムシリーズデータをキャッシュします。このデータをクエリするには、コンピュート秒を使用する必要があります。

タイムシリーズクエリは次のようにコンピュートを使用します:

  1. クエリはクエリごとに固定レートのコンピュート秒を使用します。
  2. 各クエリは、クエリが読み取るタイムシリーズポイントの数に基づいて追加のコンピュート秒を使用します。

大きなタイムシリーズインデックスに対するクエリは、より多くのポイントを読み取ります。以下のセクションでは、これがどのように計算されるかについて説明しています。

コンピュートの測定方法

Foundry の使用料を支払う際には、クエリごとに固定の最小コンピュート秒が消費されることに注意してください。デフォルトの量は 20 コンピュート秒です。これは、クエリを提供するために必要な基本的なコンピュート使用量です。Palantir と企業契約を結んでいる場合は、コンピュート使用量の計算を進める前に Palantir の担当者に連絡してください。

タイムシリーズデータの保存は、Foundry のストレージ下で測定されます。タイムシリーズデータの保存はコンピュートを使用せず、タイムシリーズをインデックス化し、アクティブにデータをクエリするだけでコンピュートを使用します。

タイムシリーズクエリのコンピュートは、Foundry に保存されたタイムシリーズデータをクエリする際にのみ使用されます。タイムシリーズクエリは2つの方法でコンピュートを使用します:

  1. クエリごとに使用される最小のコンピュート秒数。使用ベースの Foundry インスタンス上では、各クエリが 20 コンピュート秒を使用します。
  2. クエリは、クエリ自体で考慮するポイントの数に基づいて固定の最小コストを超えてスケールします。クエリ中にスキャンされるポイントの数は、クエリされるシリーズのサイズと実行されるロジックの複雑さによって駆動され、これにより多数の比較/操作がポイントに対して行われます。

次の式は、クエリからコンピュート秒を導出します:

Copied!
1 2 # ポイントをスキャンした数に基づいて秒数を計算します。基本的に20秒に、スキャンしたポイント数を50000で割った値を加えます。 compute_seconds = 20 + points_scanned / 50000

時系列クエリ使用状況の調査

リソース管理アプリケーションを使用すると、データセット使用情報の詳細を確認でき、Foundryプラットフォームの使用状況調査の出発点となります。

ユーザーは、Foundry内で時系列データをクエリするための複数のツールにアクセスできます。時系列クエリの使用状況は常に、各ツールが生成または変更したリソースに付随しています。

  • Quiverでは、時系列クエリは、クエリの開始に使用された個々のQuiver分析またはダッシュボードに帰属します。
  • Workshopでは、クエリはクエリを開始したWorkshopアプリに付随します。Workshopアプリが時系列をクエリするQuiverコンポーネントを埋め込む場合でも、使用状況は引き続き上位のWorkshopアプリケーションに帰属します。
  • FoundryTSライブラリを使用して時系列をクエリする変換の場合、それらのクエリの計算は、その変換が記述されたリポジトリに帰属します。

使用状況の要因を理解する

Foundryを使用契約で利用する場合、時系列クエリによるコンピュートの主な要因は3つあります:

  1. クエリの数

    • 各クエリは最低20コンピュート秒の使用を必要とします。これは、ユーザーによって実行されるクエリが多ければ多いほど、クエリを実行するQuiverダッシュボードが多ければ多いほど、FoundryTSクエリを実行するスケジュールビルドが多ければ多いほど、より多くのコンピュート秒を使用することを意味します。
  2. クエリされる系列のサイズ

    • 各クエリは、その系列に対して実行される際に、全ての時系列ポイントをスキャンしなければなりません。全体的に、大きな系列は比較的小さな系列よりもクエリするのに多くのコンピュートを必要とします。例えば、1,000万ポイントの系列に対してクエリを実行すると、10万ポイントの系列に対してクエリを実行するよりも多くのコンピュートを使用します。
  3. クエリの複雑さ

    • 下層の系列とより複雑な相互作用を行うクエリは、その系列の上でより多くの操作を実行します。これらの操作を実行すると、スキャンされるポイントが増えるため、クエリの使用状況が増加します。

    クエリの複雑さ に関する以下のセクションを参照して、詳細情報と例をご覧ください。

時系列を使用した使用状況の管理

クエリの総数を管理することは、時系列クエリからの総コンピュート使用状況を管理するために重要です。Foundryで時系列を使用する際には、以下の実践を考慮してください:

  • 時系列ベースの分析やダッシュボードを構築する際には、各更新で実行しなければならないクエリの総数を考慮してください。また、全てのクエリがパラメーターが変更されたときに更新されないように、更新パスを分割することも考慮してください。
  • FoundryTSビルドを実行する際には、スケジュールが適切に設定されていることを確認してください。ビルドが必要以上に頻繁に実行されないようにしてください。
  • 時間範囲が時系列に適用されると、Foundryの時系列バックエンドはその時間範囲内に落ちるポイントのみを読み取ります。したがって、Foundry内の時系列クエリは、クエリしている範囲に基づいて最適化することができます。クエリの時間範囲を制限することはコンピュートを必要としません。時間範囲を選択することで、全体的にスキャンされるポイントを大幅に減らし、クエリで使用されるコンピュートを減らすことができます。
  • ジョブに適切な粒度を選択します。すべてのワークフローが最大限に詳細なデータを必要とするわけではありません。場合によっては、特定のワークフローのために事前に集約することを意味します。他の使用ケースでは、異なる粒度を異なる系列に保存することを意味します。複数の最新の系列を維持することは、インデックス作成のコンピュートを増加させる可能性がありますが、複数の系列を保存する行為はコンピュートを必要としません。したがって、異なる粒度の複数の系列を保持することは、常に最も詳細な系列をクエリするよりも安価な場合があります。

使用状況の計算

時系列クエリのコストを予測するには、クエリされる系列のサイズを常に理解していることが必要です。

次に、各クエリがシリーズ内の全てのポイントをスキャンする、10万ポイントのシリーズに対して3つのクエリがある例を考えてみてください:

シリーズのサイズ:100,000 ポイント
最小クエリ使用量:20-計算秒
1計算秒あたりのポイント数:50,000 ポイント
合計クエリ数:3

# 計算秒数を求める式は以下の通りです
# 計算秒数 = クエリ数 * 最小クエリ使用量 + 総ポイント数 / 1計算秒あたりのポイント数
計算秒数 = 3のクエリ * 20の計算秒 + 100,000のポイント * 3のクエリ / 50,000のポイント/秒
計算秒数 = 3 * 20 + 300,000 / 50,000
計算秒数 = 66計算秒

クエリの複雑さの例

クエリされた時系列データに対してネストされた操作が適用されると、時系列クエリの複雑さが増します。

例として、以下の FoundryTS コードは 2 つの時系列データを加算し、新しい時系列データのすべてのポイントを 1 年間の時間範囲で Pandas データフレームとして返します。

# 時系列データを扱うノードを作成します
series_1 = N.TimeseriesNode('series_1') # 'series_1'という名前の時系列ノードを作成
series_2 = N.TimeseriesNode('series_2') # 'series_2'という名前の時系列ノードを作成

# DSL(ドメイン固有言語)を使用して、2つの時系列ノードのデータを組み合わせる計算を定義します
# この場合、それぞれのノードから取得したデータを足し合わせる計算を指定しています
result = F.dsl(program='a+b', return_type=float)([series_1, series_2])

# 指定した時間範囲(2022年1月1日から2023年1月1日)のデータを取得します
result = result.time_range(start='2022-01-01', end='2023-01-01')

# 結果をPandasのデータフレーム形式で出力します
result.to_pandas()

このコードは、以下の形でCodexにクエリを行います:

{
  id: dsl-fomula
  // 子要素
  children: [
    { id: timeseries }, // 時系列データ
    { id: timeseries }  // 時系列データ
  ]
}

to_pandas の評価は、要求された 1 年間の時間範囲内で result タイムシリーズのポイントをスキャンするためのコストと、結果を計算するために必要な 2 つのコンポーネントシリーズのポイント(この場合は、それぞれから 1 年間の範囲)を発生させます。

次に、より入れ子になった操作を適用する FoundryTS コードを検討してみましょう。まず、2つの他のシリーズの合計であるシリーズを定義します。次に、そのシリーズを 7 日間のローリング平均と比較し、結果の 1 年分のポイントを Pandas データフレームとしてロードします:

# 時系列ノードを作成
series_1 = N.TimeseriesNode('series_1')
series_2 = N.TimeseriesNode('series_1')

# 2つの時系列ノードを加算
intermediate_1 = F.dsl(program='a+b', return_type=float)([series_1, series_2])

# 加算された時系列の7日間の平均値を計算
intermediate_2 = intermediate_1.rolling_aggregate('mean', '7d')

# 元の加算された時系列から7日間の平均値を減算
result = F.dsl(program='a-b', return_type=float)([intermediate_1, intermediate_2]).time_range(start='2022-01-01', end='2023-01-01')

# 結果を pandas のデータフレームに変換
result.to_pandas()

このコードは、以下の形式で Codex へクエリを行います:

{
  id: dsl-fomula // これはDSL(Domain Specific Language)の式を示す識別子です
  children: [
    {
      id: dsl-fomula // 子ノードもDSLの式を示します
      children: [
        { id: timeseries }, // 時系列データを示す識別子です
        { id: timeseries } // 同じく、時系列データを示す識別子です
      ]
    },
    {
      id: rolling-aggregate // これは移動集計(時間窓を移動させながらの集計)を示す識別子です
      children: [
        {
          id: dsl-fomula // 子ノードはDSLの式を示します
          children: [
            { id: timeseries }, // 時系列データを示す識別子です
            { id: timeseries } // 同じく、時系列データを示す識別子です
          ]
        }
      ]
    }
  ]
}

このクエリツリーの各ノードでは、最終結果を生成するために1年間の範囲のポイントをスキャンするためのコストが発生します。