AWS

どんな処理をどの順番で、どこにデータを送るかなどをJSON形式で書いた設計図。これを登録すると、その通りにパイプラインが動く。直感的にはワークフローをテキストで説明しているイメージ。

時間になったら毎日ジョブを回す、あるいはファイルが来たら起動するなど、自動で動かす“きっかけ”を設定できる仕組み。人間が手動でやらなくても、新しいデータが来れば即座に変換処理できるから便利なんだ。

実際の“やること”を定義する部分。例えばS3からRedshiftにコピーする“CopyActivity”や、RDSに対してSQLを実行する“SqlActivity”などがある。組み合わせれば複雑な処理もできるんだ。

ジョブやトリガーを複数つなげて、1→2→3…という一連の流れを組む機能。大規模なETL処理ではステップが多いから、ワークフローで管理すれば可視化しやすく、どこまで終わったかも追いやすいんだ。

パイプラインをどのタイミング、どの頻度で走らせるか決める。毎日や週1回、あるいはすぐ実行など自由に設定できる。長期にわたるデータ加工を定期運用するのにぴったり。

データを行や列に厳密に当てはめる前に、“柔らかい形”で扱う仕組み。多少フォーマットが違っていても読み込めたり、カラムを推定してくれたりするから、複雑なデータでもエラーになりにくい。

Activityを実行する前に“ちゃんと元ファイルがあるか？”“テーブルが空いてるか？”などの条件を確かめられる。準備ができていなければ動かさないから、エラーや無駄なリソース消費を減らせるんだ。

ジョブが前回どこまで処理したかを覚えていて、次回は続きから処理する機能。毎回全部を再変換しなくていいし、差分だけやるから速く終わる。ログの更新分だけ取り込むなどのシナリオで助かるんだ。

処理に使うコンピュータ(EC2)やEMRクラスターなどを指定する。どんなスペックのマシンが必要か、スポットインスタンスを使うかなどを設定して、最小コストで動かす工夫もできる。

Webブラウザ上の画面でドラッグ&ドロップしながらETLジョブを作れるツール。プログラミングが苦手でも流れを簡単に組めるし、裏ではPySparkのコードを自動生成してくれるから学習しやすい。