これなら使える!ビッグデータ分析基盤のエコシステム

第9回[最終回] データパイプラインのためのワークフロー管理

この記事を読むのに必要な時間:およそ 3 分

基本KPIや応用KPIが決まり,実際に,毎日の運用の中で定期的にデータを更新して,可視化するためには,一連の処理を自動化する必要があります。今回は,データパイプラインを扱うためのワークフロー管理ツールを紹介していきます。

データパイプラインとワークフロー管理

データパイプライン (以下,パイプライン)とは,データ処理を行なう小さなタスク(1回のファイルコピーや,SQLの実行など)を順次実行することにより,最終的に求める結果を得るための一連のプロセスを指します。狭義には,単体のシステム内で完結するパイプラインを指します(SparkやGoogle Cloud Dataflow,など)。

また,広義には,複数のシステムを組み合わせて大きなパイプラインを構成することもあります(MySQLから取り出したデータをRedshiftで集計する,など)。今回,取り上げるパイプラインとは,広義のパイプラインで,その実現にパイプラインを扱うワークフロー管理が必要です。

ワークフロー管理 とは,指定した時間に複数のジョブを実行し,各ジョブの進行を管理するためのシステムを指します。たとえば,ジョブのスケジュール実行,ジョブの依存関係の解決,エラー時の通知や自動リトライ,指定したジョブの再実行,過去の実行履歴の管理などといった機能があります。

パイプラインを実現するのに,次のようにワークフロー管理を行なっているケースが多いようです。

  1. 自分でスクリプトを書く(リトライ制御などもスクリプトの中に記述する)。
  2. Jenkinsを用いる(Jenkinsには依存解決,エラー通知など,ワークフロー管理に必要な機能がある)。
  3. JP1を用いる(国内のIT部門では定番のワークフロー管理システム)。

しかし,毎回スクリプトを書くのは大変ですし,ちょっとしたパイプラインにJenkinsやJP1を導入するのも大袈裟です。もっと手軽にパイプラインを管理できるツールが欲しい,ということで作られているのが,最近のワークフロー管理ツールです。

ETLツールとの違い

ところで,この分野の伝統的なソフトウェアといえばETLツールですが,それを使っているという話はほとんど耳にしません。従来のデータウェアハウスのように,要件定義やテーブル設計が明確な世界では使われているのかもしれませんが,ビッグデータ界隈とは相性が悪いのかもしれません。

ETLツールは,それ自体が大量のデータ処理を行うため,Javaによる高速実行や分散処理を想定して設計されています。ところが,最近は性能が必要なところではHadoopなどが用いられるようになり,ワークフロー管理はAPIを呼び出すだけになりつつあるため,既存のETLツールではオーバースペックとなり,より簡潔なツールが求められているのでしょう。

今後,クラウドサービスの普及が進むにつれて,ますますAPIによってシステム連携が行われるようになると,ワークフロー管理もAPIによるコントロールが中心となり,ソフトウェアとしては軽量化されていくことが考えられます。

ワークフロー管理の役割

前提として,パイプライン実現のために求められるワークフロー管理の要件をまとめておきます。

大量のデータを扱う場合,1つのジョブに数時間かかることもよくあります。たとえば,データのロードに1時間,前処理に1時間,集計に1時間,結果のアウトプットに30分,といった具合です。

ここで最後のアウトプットで予期せぬエラーが発生し,スクリプトの実行に失敗したとしましょう。最初からやりなおすとまた3時間以上かかってしまうので,最後のアウトプットだけやり直したいでしょう。そうするとスクリプトを修正して,手動でリカバリ作業を行うことになります。スクリプトを実行した翌日になってエラーに気付くのもよくあることで,そうするとますます時間を使ってしまいます。

ワークフロー管理の役割のひとつは,こうしたエラーのリカバリを簡単にすることにあります。最初からリカバリのことを想定し,どこでエラーが起きたらどうやり直すのかを意識しながらプロセスを記述します。大きなジョブを複数の小さな「タスク」に分割し,各タスクはリトライ可能となるように実装します。

もうひとつ重要な役割が,タスクの並列実行です。ビッグデータ分析エンジンで手軽に大量のデータにクエリを実行できるようになってはいますが,「データが大きすぎるので24分割してください」などと言われる場合があります。多くのシステムは「巨大なタスクを一つ実行」するよりも「小さな多数のタスクを並列実行」する方が効率良く動作するようになっているためです。経験的には,一つのタスクが数分から1時間程度で終わるように分割すると効率的なように思います。ただし,並列度があまりに高すぎるのは駄目で,どんなシステムであれ,同時に100万リクエストも発行しようものなら大量のエラーを受け取ることになるでしょう。

そこで必要になるのが「タスクキュー」のモデルで,それにより並列処理を適度に抑制することができます。たとえ100万タスクをキューに入れても,並列度を20に設定しておけば,一度に20以上のリクエストは実行されなくなります。利用するAPIやクエリ実行エンジンによって最適な並列度は異なるため,複数のキューを使い分けて並列度をコントロールするのが理想です。

最後に必要なのが,タスクの依存関係の解決です。タスクキューで多数のタスクを並列実行し,エラーのリトライを繰り返す中で,タスクの実行順序を保証するには,各タスクの依存関係を記述できなければなりません。

これらが,ワークフロー管理に求める必須要件で,これらに加えてジョブのスケジュール実行や,わかりやすいUIなどをパッケージにまとめたものが,パイプライン処理のためのワークフロー管理ソフトウェアです。

著者プロフィール

高橋達(たかはしとおる)

Treasure Data Inc.でテクニカルサポートエンジニアとして,毎日,日米問わず顧客のサポートを担当。サポートエンジニアのエンジニアとしての地位向上を目指して色々模索中。そのために,秋葉原幻橙館で今日も元気にOSS活動を行っている。

URL:http://toru-takahashi.gitbooks.io/secret-ninja/content/

コメント

コメントの記入