一休のETL処理をAirflowで再構築しました

一休のデータサイエンス部に所属しています小島です。

以前データ分析基盤の構築で記事を上げていましたが、今回はETL*1周りの話をしようと思います。 user-first.ikyu.co.jp

今回ETLのツールとして導入したのはAirflowというツールです。 2017年のアドベントカレンダーでも紹介させていただきました。一休のデータフローをAirflowを使って実行してみる

一休のETLの現状について

一休のETL周りは以下の画像のようになっていました。 f:id:kojimakohei2:20180607154849p:plain

課題

ETLの処理時間が伸びた（出社後も処理が続いていた）
エラーのリカバリ作業に時間がかかる（ログが確認しにくい, サーバーに入って作業しなければいけない）
複雑な依存関係の定義がしにくい（どれとどれが依存しているかわからない）
リソース負荷（全て並列で実行していた）
処理毎のボトルネックが把握できない

ツールの問題というよりは正しくツールを使えていないことが原因でしたが、上記の理由でDigdagをAirflowに移行することを決定しました。

なぜAirflowにしたか

処理が複雑にかける
管理画面の依存関係のグラフと、tree形式での表示がわかりやすい
Pythonで記述できるので、機械学習などと相性がいい
管理画面から簡単に再実行できる

Airflowの導入した結果できるようになったこと

ETLの時間が把握できるので、ボトルネックとなる処理に関して対処が可能になった
再実行が管理画面から簡単にできるので、リカバリーが簡単になり運用に時間がかからなくなった
並列数などを簡単に設定できるので、負荷が少なくなった
依存関係がとても簡単に定義できる

ボトルネックとなる処理の検知

f:id:kojimakohei2:20180601122438p:plain めちゃめちゃ簡単にわかるようになりました。

対象日付のリカバリーが管理画面から簡単にできる

f:id:kojimakohei2:20180601122649p:plain

導入に当たって苦労したこと

ETL処理は意外と追加や変更が多いので開発しやすい環境を作ること
Airflowの制約があったこと

ETL処理は意外と追加や変更が多いので開発しやすい環境を作ること

ETLで肝なのはデータが正確にDWHに格納できるかというところです。なので開発環境を作る必要があります。ただ、開発環境を作成する際に考えなければいけないのがアウトプットするDBについてです。インプットに関しては参照するだけなので、あまり考慮しなくていいのですがアウトプット用のDBをどのように用意するかを考え、結果的に開発環境ではdockerコンテナを立て件数を自動的に絞ることで開発ができるようにしています。 BigQueryや、S3などについてはコンテナを作れないので環境ごとにbucketを変更することで開発できるようにしています。

Airflowの制約があったこと

Airflowは1.9.0を使用していますが、内部的に全てUTCで動いています。利用としてはこちら記事にわかりやすく書いてありましたが、タイムゾーンに依存しないように内部のシステムは全てUTCを使用するようにしているらしいです。 [AIRFLOW-289] Use datetime.utcnow() to keep airflow system independent - ASF JIRA

なので一休では表示側はUTCで処理部分は明示的にJST => UTCに変換しています。