Treasure Workflow for ビギナー 4本目。Arm Treasure Data Advent Calendar 2019 - Adventarの２日目。

ある日、トレジャーデータを利用している部署にアサインされ、Treasure Workflowを使ってデータパイプラインを管理しているからそれをメンテしてね！って頼まれる日がくるかもしれないです。

さて、そんなときはとりあえず触らぬ神に祟りなしということで、既存コードを触らず動かし続けることもあるかもしれません。しかしある日、無情にも下記の通知メールが届くこともあるでしょう。このメールは、Treasure Workflowの実行時にエラーになると自動でWorkflowのオーナーに通知されるメールです。

f:id:toru-takahashi:20191201095657p:plain

つまりTreasure Workflowの処理が失敗したということになります。ここからどうやって処理を復旧すればよいのかみていきましょう。

はじめにエラーとなったタスクを確認する

エラーが発生したら、それが一時的な問題なのかそれとも何らかの外的な変更によって発生した問題なのかを確認する必要があります。そのためにはエラーになったタスクを確認するのが第一です。

メールにあるsession XXXXXXをクリックするとエラーになったセッションに直接行くことができます。タスクタブを開いて、どのタスクでエラーになったかを確認しましょう。

f:id:toru-takahashi:20191201100205p:plain

Treasure Workflowの一つ一つの処理には依存関係と親子関係があります。エラーになったタスクの親タスクについては"Group Error"と表記されるため、 Group Errorは無視して、"Error"の子タスクを探します。

今回エラーになったタスクを見ると、Job IDがついていません。通常、td_load / td / td_run といったオペレータはHive/Presto/DataConnectorなどの処理が実行されるため、JOB IDが付与されます。この場合はJOB IDからエラーをチェックするのがログとしては見やすいです。

Job IDがついていない場合は、s3_waitなどのトレジャーデータと関係がない処理であるか、もしくはトレジャーデータに対して処理を発行すること自体が失敗しているケースのどちらかであることが通常です。この確認のためには、Workflow Logsのタブを開いて、Treasure Workflowのログを眺める必要があります。ここで一時的なエラーだということを確認できれば、特に難しいことを考えず失敗したセッションを再実行させることでワークフローを復旧させることができます。

どうやって一時的なエラーかどうかを判別するのかはまた色んな話があるので、とりあえずパッとみてわからなかったらサポートに聞いてみましょう。