Treasure Data - Support Engineering Team blog

トレジャーデータのサポートエンジニアリングチームのブログです。

Job の Status と同時実行数について

こんにちは、Treasure Dataサポートの伊藤です。

本記事ではJobのStatusとその同時実行数について説明していきます。

Job の Status について

Jobが現在どういう状態なのかStatusによって知ることができ、具体的には下記5種類が存在します。

Status 説明
Queued キューで待機している状態で処理は始まっていません。同時実行数上限が関係しているため詳細は後述します。
Running 処理が開始されている状態です。
Success Runningのあと処理が成功するとこの状態になります。
Error Jobが成功しなかったことを表します。
Killed ジョブが発行されたあとに中断されたことを示します。

例えばJob Activitiesにより各JobのStatusを確認することができます。

Job Activities

Queuedについて

イメージしづらい Status は Queued かと思います。 この Status はその名の通りキューで待機している状態のことを指します。

キューで待機している図

キューはFIFO(FIrst-In First-Out)という管理方式となるデータ構造として有名かと思いますが、その方式通りキューから取り出されるのは最も古い要素となります。 そのため、Treasure Dataの場合もキューで待機している Job が複数存在する場合、最初に処理が開始されるのは最も昔に発行された Job です。 (優先度によって前後することはあります)

キューから取り出された後は Running 状態となって処理が開始されます。そのため Status が Queued となっている場合待っていても一向に処理は開始されず、キューから取り出されるまで待つ必要があります。

Queued で待っていた時間の確認方法

Job 完了後に、そのJobがどれくらい Queued となっていたか知りたいケースがあるかと思います。 その場合はREST APIを使うことで確認できます。具体的には GET /v3/job/show/<job_id> のレスポンスから Queued となっていた時間を算出できます。

curlコマンドで REST API を実行するサンプルは下記になります。

$ curl -X GET "https://api.treasuredata.com/v3/job/show/<job_id>/" -H "Authorization: TD1 <API Key>"

レスポンスサンプルは下記で、created_atとstart_atの差が Queued となっていた時間となります。キューから取り出され処理がされている時間は start_at と end_at の差(duration)です。

{
  "job_id": "1256214458",
...
  "created_at": "2022-01-07 01:23:30 UTC",
  "duration": 2,
  "end_at": "2022-01-07 01:23:41 UTC",
...
  "start_at": "2022-01-07 01:23:39 UTC",

また、Presto Job の場合先行してキューから取り出される場合があります。 処理を開始する前に準備をしているとイメージすると良く、その場合はログの queued time で確認できます。

2022-08-02 06:25:27 -- peak memory: 60M, queued time:00:10:00.000
20220802_062525_xxxxxxxxxxx                                                                                        00:00:01.214   rows  bytes bytes/sec  done   total 
[0] output <- remotesource[1]                                                                                      FINISHED      6,443  1.0MB  62.7MB/s     1 /     1 
...

同時実行数上限について

次に、同時実行数上限について説明していきます。

Job の種類と同時実行数上限

Hive と Prestoの同時実行数上限

HiveとPrestoの同時実行数上限は契約内容によって決まります。 どちらにも転化できるComputed Unitを決めて、その内訳を決めるような形が多いのではないかと思います。

Result Exportの同時実行数上限

Result Exportは Hive の同時実行数上限の1.5倍となります(端数は切り捨て)。

Bulk Import と Bulk Exportの同時実行数上限

Bulk ImportやBulk Exportは Hive と同時実行数の枠を共有しています。 例えば、Bulk Import Job のみで同時実行数上限を超過している場合、Hive Jobが新たに発行されるとその超過している影響を受けます。

Bulk Loadの同時実行数上限

基本的に固定値で、契約内容によって増減することは基本的にありません。

同時実行数上限を超過した場合の挙動

先述してしまった部分もありますが、どの Job の種類でも同時実行数上限を超過した場合の挙動は同じです。超過した分のJobはキューで待機させられます。 先行して発行されてRunningとなったJobが終了(Success, Error or Killed)すると、キューの先頭にいるJob(job_idが小さい)が取り出され処理が開始されます。

同時実行数上限の範囲

同時実行数上限はアカウント全体で設けられている制限です。

ユーザーごとの制限ではないため、例えばあるユーザーが大量の Job を実行して同時実行数上限を超過している場合、他のユーザーは全く Job を実行していないにも関わらず上限超過の影響を受けることになります。

Restricted Userと呼ばれる一般ユーザーの場合、権限のないデータベースに対するJobは見ることができないので、自分が見える範囲には Running となっている Job が存在していないにも関わらず Queued となってしまう場合があるでしょう。その場合は先行して実行された Job の完了を待つか、Administratorへ先行して実行された Job を kill するよう依頼するなどの対応になります。