はじめに
プレビューにご登録のうえプレビューしてください。
1 営業日以内にこちらから連絡がなかった場合は、再度登録してください。
数十億の時系列を対象とした予測と異常検出は計算の集中的です。既存のシステムの大半は、バッチジョブとして予測と異常検出を行います（リスク パイプライン、トラフィック予測、需要計画など）。これにより、オンラインで実行可能な分析の種類が大幅に制限されます（たとえば、イベントのセットが急激に増加した場合または減少した場合にアラートが通知された場合）。
時系列予測を行い、時系列分析 API で異常検出に使用する主な目標は次のとおりです。
- 数十億の時系列にスケーリング（時系列における一連のイベント（時系列で行われるトランザクションの数など）が時系列として定義される）に対応する。
- 予測と異常検出にリアルタイムのレイテンシを提供する（すべての時系列で傾向や季節性を数秒で検出し、スライスが急激に変化するか下回るかを判断）
API 機能
- Google Cloud Storage に保存されている複数のデータソースで構成されるデータセットをインデックスに登録して読み込みます。ストリーミング イベントの追加イベントを許可する。
- 読み込まれたデータセットに対して時系列クエリを実行し、傾向を予測し、異常を検出します。
- 不要になったデータセットをアンロードします。
- データセットの処理ステータスを尋ねます。
入力データ
時系列データは、時間経過とともに繰り返し測定される観測のコレクションです。たとえば、特定のジョブの 1 分あたりの平均 CPU 使用量は、単純な時系列データです。特定の時点での Key-Value ペアとしてのデータポイントは、入力データの最小単位です。ここで、キーはディメンションの名前です。この例では、cpu、ram、state などです。
イベント
Timeseries Insights API はイベントの基本的なデータとしてイベントを使用します。単位のスケールでデータポイントを処理する場合、さまざまな集計のために複数のディメンションを使用できます。たとえば、データセンター、ユーザー、ジョブ名、タスク番号が 1 つのイベント全体として追加されます。
{"name":"user","stringVal":"user_64194"},
{"name":"job","stringVal":"job_45835"},
{"name":"data_center","stringVal":"data_center_30389"},
{"name":"task_num","longVal":19},
{"name":"cpu","doubleVal":3840787.5207877564},
{"name":"ram","doubleVal":1067.01},
{"name":"state","stringVal":"idle"}
各イベントには次のものが含まれます。
- タイムスタンプ
- 各ディメンションには次のような特徴があります。
- 名前（データセット全体で一意）
- 値（文字列、ブール値、int/long、または double）イベントのディメンションは、イベントに関連するプロパティです。 当然ながら、一連のディメンション名はイベントの種類に対応しています。たとえば、
["user", "job", "data_center", "task_num", "gcu"]はジョブリソース消費イベントに、["user", "gcu", "disk", "ram"]はユーザー割り当てイベントに使用されます。
- long 型のグループ ID。関連する Event レコードに同じ値に設定します。 ほとんどの場合、各 Event レコードには一意の ID が割り当てられます。グループ ID のユースケースには次のものが含まれます（ただし、これらに限定されません）。
- 複数のイベントレコードからの同じイベントのイベント識別子（同じタイムスタンプを使用）。特に、異なるイベントの参照元がそれぞれ異なるソースとものである場合。システムに統合する前にマージすることはできません。 たとえば、同じデバイスをモニタリングする複数のセンサーが、それぞれ異なるイベント レコードを生成することがあります。
- 関連するイベントのセッション識別子（通常、タイムスタンプが短期間）。 たとえば、ウェブ ブラウジング セッションのアクティビティです。もう 1 つの例はタクシー乗車時のログエントリです。
- 同じユーザー ID を持つすべての Event レコードは、同じユーザーに属します。
データセット
データセットはイベントの集合です。 各クエリは、同じデータセット内で実行されます。各プロジェクトに複数のデータセットを含めることができます。
各データセットは、バッチデータとストリーミング データから作成できます。バッチビルドでは、データソースとして複数の Cloud Storage URI からの読み取りを読み取ります。バッチビルドが完了すると、ストリーミング データを使用してデータセットを更新できます。履歴データに対してバッチビルドを使用すると、コールド スタートの問題を回避できます。
データセットをクエリまたは更新するには、その前にデータセットを作成またはインデックス登録する必要があります。インデックス登録はデータセットの作成時に開始されます。また、データの量によっては、完了するまでに数分から数時間かかることがあります。 具体的には、データソースは初期インデックス登録時に 1 回スキャンされます。初期インデックス登録の完了後、Cloud Storage URI のコンテンツが再スキャンされることはありません。 ストリーミング更新を使用して、追加のデータを取得します。 ストリーミング更新は、ほぼリアルタイムでインデックス化されます。
注: Timeseries Insights API では生のストリーミング更新は返せないため、クライアントはこれらのデータ用に独自のストレージを持っている必要があります。
時系列と異常の検出
Timeseries Insights API の場合、スライスは、特定のディメンション値の組み合わせを持つイベントのコレクションです。 Google では、これらのスライスに時系列で配布されるイベントの分布を確認します。 スライスは、指定された時間間隔ごとのユーザーごとの数値に集計されます。これは、異常を検出する時系列です。上の図は、"user", "job", "data_center" ディメンションを持つデータセットからさまざまなスライスを選択する方法を示しています。
特定の時点での値の数値が過去の値と大きく異なる場合は、特定のスライスで異常が発生します。この図は、10 年間にわたる世界各地の気温に基づく時系列を示しています。2015 年の先月が異常かどうか調べてみましょう。システムに対するクエリでは、間隔の間隔として testInterval を指定します。これは「one month ends on 2015/12/31」です。testInterval よりも前に取得された時系列が、前のトレーニング期間に分割され、その後に保留期間になります。システムはトレーニング期間のデータを使用してモデルをトレーニングし、ホールドアウト期間を使用して、モデルで次の値を確実に予測できることを確認します。この例では、ホールドアウト期間は 1 年間です。通常、ホールドアウト期間は、使用した履歴全体の 5 ～ 10% です。この図は、下限と下限のモデルの実際のデータと予測値を示しています。2015/12 度の温度は、実際の値が予測境界外に大きく発生しているため、異常としてマークされています。