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

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

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

既存のソフトウェア

ビッグデータ界隈でよく耳にするソフトウェアをいくつか取り上げます。概ね下にいくほど新しいツールです。

Apache Oozie

Apache Oozieは,Hadoop標準のワークフロー管理ツールです。Hadoopに渡すパラメータなどをまとめてXMLに記述しておくと,その定義にしたがってジョブを順次実行してくれます。

Apache Falcon

Apache Falconは, Hortonworksに組み込まれているワークフロー管理ツールです。Oozieの後継として作られているようで,こちらもXMLにジョブのパラメータを記述するタイプです。

Azkaban

Azkabanは,LinkedInで開発され,オープンソースとして公開されているJava製のワークフロー管理ツールです。タスクごとに個別のテキストファイル(ini形式)を作成し,それらをzipファイルにアーカイブしてREST APIでアップロードすると実行される仕組みになっています。Hadoop以外の拡張パッケージはあまり多くありません。リトライ時には,手動でパラメータを再設定した上で,ブラウザから再実行します。

Azkaban UI

Azkaban UI

Luigi

Luigiは,Spotifyで開発され,オープンソースとして公開されているPython製のパイプラインのためのワークフロー管理ツール(このあたりから「パイプライン」という呼び方が一般的になったよう)です。Hadoop以外にも,MySQLやPostgreSQL,Sparkなどさまざまなエンジンに標準対応しています。タスクをPythonのクラスとして定義する仕様で,プログラミング能力が求められます。

データベースやサーバがなくとも,単体のスクリプトとして実行できるため,手軽さは抜群です。ただし,それは欠点でもあり,完了したタスクの管理がユーザ任せになるなど,利用する側に負担を強いることになります。自分でコーディングするのが苦にならないPythonプログラマには扱いやすいですが,そうでなければ敷居が高そうです。

Luigi

Luigi

Amazon Data Pipeline

Amazon Data Pipelineは,AWSで提供されている名前の通りパイプラインのためのワークフロー管理サービスです。Webコンソール,またはJSONでジョブを記述します。決まった時間にEMRを起動し,Hiveの実行結果をS3に書き出し,それをRedshiftで集計する,などといったAWSに閉じたパイプラインを実行するのに良いです。

Data Pipeline

Data Pipeline

Azure Data Factory

Azure Data Factoryは,Microsoft Azureで提供されているパイプラインのためのワークフロー管理サービスです。Webコンソール,またはJSONでジョブを記述します。Hadoopクラスタの起動やHiveクエリの実行などが出来るようで,Amazon Data Pipelineと似ています。

Azure

Azure

Google Cloud Dataflow

Google Cloud Dataflowは,Googleで提供されているパイプラインのためのワークフロー管理サービスです。Java SDKが提供されており,処理内容はJavaで記述します。これはどちらかというと狭義のパイプラインであり,ここから他のサービスをコントロールするのではなく,Googleに格納されたデータをGoogleの計算リソースでパイプライン処理するのに用いられます。

Dataflow

Dataflow

Dataswarm

Dataswarmは,Facebook社内で使われているというPython製のワークフロー管理ツール。ジョブの記述にPythonを用いるのはLuigiと同じですが,クラスを定義するのではなく,一連のタスクをDAGとして記述するようです。ソースコードは公開されておらず,利用はできません。

Airflow

Airflowは,Airbnbで開発され,オープンソースとして公開されているPython製のワークフロー管理ツールです。⁠Dataswarmにインスパイアされた」とあるように,DAGとしてジョブを記述するようになっています。

Airflow

Airflow

パイプラインを記述する3つのスタイル

これまで紹介したワークフロー管理ツールを利用するための記述方法には,大きく分けて次の3つのスタイルがあります。

  1. 宣言型: 宣言型とは,XMLやJSONなどで実行したい内容を記述するタイプを指します。
    宣言型は,Java製のツールに多いです。また,あらかじめ用意された機能では不十分な場合に,Javaクラスとして拡張モジュールを登録するか,あるいは外部コマンド(orスクリプト)を用意する必要があります。

  2. 手続き型: 手続き型とは,プログラムに組み込む形でパイプラインを記述するタイプを指します。
    パイプラインを実装する過程で,自前でスクリプトを書くことが多いために,最初からスクリプト言語でパイプラインを記述した方が効率が良くなります。そこで,データ処理と相性のいい(Pandasが使える)Pythonをパイプラインの記述に用いることが増えてきています。

  3. DAG型: DAG(Directed Acyclic Graphs)とは,ノードとノードが矢印で結び付いたデータ構造のことで,それを基礎としたプログラミングモデルを,ここでは特にDAGスタイルとして区別します。
    これも手続き型と同じくスクリプトにパイプラインを埋め込む点は同じですが,プログラムの書き方が異なります。

これらのスタイルが具体的にどう異なるか,についての説明は今回は省きます。ワークフロー管理ツールは,ビッグデータ分析エンジンと同じようにまだまだホットな領域で,さまざまなツールが生まれ,デファクトスタンダードはまだありません。こうしたさまざまなツールがある中で自分たちのユースケースに合わせてツールを取捨選択し,自分たちのビッグデータ分析エンジンを効率的に運用するために活用してみてください。

ビッグデータ分析基盤を支えるエコシステムまとめ

この連載では,ビッグデータ分析基盤の第一歩となるエコシステムを紹介しました。

ログコレクタとして,ストリーミング処理のためのFlunetd,バッチ処理のためのEmbulkを紹介し,アクセスログやRDBからデータのインポートを行いました。

次に,分析エンジン上に収集されたデータをアドホックに分析する環境として,JupyterとPandasを利用しながら,ウェブサイト全体の指標となる基本KPI分析と,ユーザのパスに着目した応用KPI分析を行いました。

そして,最終回となる今回では,これらの処理をパイプラインとして実運用で定期実行するためのワークフロー管理システムを紹介しました。

ここで紹介したシステムを利用することで,さまざまなビッグデータ分析エンジンにも柔軟に対応して,ビッグデータ分析の第一歩を踏み出すことができるでしょう。

しかし,今回のビッグデータ分析基盤の構成は,あくまでも第一歩であり,この先には,リアルタイム処理や機械学習エンジンなど考えるべき仕組みがまだまだあります。

そのためにも柔軟にシステムの追加ができるように考えていきながら,自分たちのビッグデータ分析基盤に合ったエコシステムを選んでいきましょう。

著者プロフィール

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

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

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