DEA / ドメイン1 データの取り込みと変換

重要な内容

パイプラインのオーケストレーションの選び方

データパイプラインは、取り込み、変換、カタログの更新、ロード、通知といった複数の処理を、決まった順序と条件で動かす仕組みです。この「順序と条件で動かす」役割をと呼びます。

DEA では、、 (Managed Workflows for Apache Airflow)、 ワークフロー、、 のどれで組むかを、要件の言葉から選び分けられるかが問われます。

Point
  • Orchestration = 指揮、編成 の意味です。オーケストラの指揮者のように、各処理の開始と順序を指示する役割です。
  • ワークフロー (workflow) は、処理の流れ全体を定義したものです。
  • DAG = Directed Acyclic Graph (有向非巡回グラフ) の略で、Airflow がワークフローを表す形です。矢印に向きがあり、ぐるっと元に戻る輪がないグラフです。
  • 和訳

概要

の道具は、「何をきっかけに始めるか」と「始めた後の流れをどう管理するか」の2つに分けると整理しやすくなります。

概要の図 きっかけ時刻 / S3 への到着 / 手動 オーケストレーター順序・分岐・再試行・待機 Glue クローラー Glue ジョブ / EMR / Athena Redshift へのロード SNS で通知
役割主な道具一言で言うと
きっかけ (スケジュールとイベント) のルールと Scheduler、 イベント通知「いつ」「何が起きたら」始めるかを決めます。
流れの管理 ()状態を持つワークフローを (Amazon States Language) で定義します。
流れの管理 ()Python の で書く Apache Airflow をマネージドで動かします。
流れの管理 ( の中で完結)Glue ワークフローとトリガーGlue のジョブとだけをつなぎます。
1つの処理を実行短い処理の実行役です。複雑な流れの管理には向きません。

試験では、「サーバーレスで運用負荷を最小にしたい」「既存の Airflow の DAG を移したい」「Glue のジョブとクローラーだけをつなぎたい」といった条件から道具を選びます。

主要技術

①オーケストレーターの比較 ⚠️ 頻出

観点 ワークフロー (単独)
定義の書き方Amazon States Language (/)、ビジュアルエディタPython の コンソールまたは でトリガーとジョブをつなぐルールとターゲット
対象200 を超える AWS サービスの API を直接呼べます のオペレーターで AWS 内外のシステムを扱えますGlue のジョブとイベントを1つ以上のターゲットへ届けるだけです
実行の基盤環境 (スケジューラー・ワーカー) を作ります。サーバーレスの実行オプションもありますサーバーレスサーバーレス
状態の管理各ステップの入出力と実行履歴を保持しますAirflow のメタデータベースで保持します実行の状態と実行プロパティを保持します保持しません
向く場面AWS サービス中心の新しいパイプライン、運用負荷を下げたい既存の Airflow 資産、オープンソースで移植性を保ちたい、AWS 外のシステムも多いGlue だけで完結する 単純な「起きたら起動」

決め手は次の3つです。

  • AWS のサービスを組み合わせるだけで、運用負荷を最小にしたいなら Step Functions です。
  • 既に Airflow の DAG がある、または Python でワークフローを書きたいチームなら MWAA です。
  • 処理がすべて Glue のジョブとクローラーなら、Glue ワークフローで足ります。

⚠️ 頻出: 「の Apache Airflow から、コードの書き換えを最小にして AWS に移したい」は MWAA です。Step Functions に作り直す選択肢は、書き換えが大きくなるため外れます。

②Glue ワークフローとトリガー

ワークフローは、Glue のジョブとをトリガーでつないだ処理の流れです。コンソールでは、各ジョブの成否を色分けしたグラフで確認できます。

トリガーには3種類あります。

トリガー動き使いどころ
スケジュールcron 式で時刻を指定して起動します毎日 2 時に夜間バッチを動かします。
条件付き監視するジョブやクローラーが指定した状態で終わったら起動しますジョブ A と B が両方成功したら C を起動します (ALL)。どちらかが失敗したら通知用ジョブを起動します (ANY)。
コンソール、、CLI から手動で起動します再実行や検証のときに使います。

ワークフロー全体の開始 (開始トリガー) には、スケジュール、オンデマンドに加えて のイベントも使えます。EventBridge のイベントで始める場合は、バッチ条件として「イベントの件数 (バッチサイズ)」と「最初のイベントからの待ち時間 (バッチウィンドウ)」を指定でき、先に満たした方で起動します。バッチウィンドウの既定値と上限は 900 秒 (15 分) です。たとえば「 に 100 個のファイルが届くか、15 分たったら 1 回だけ を動かす」という要件に合います。

条件付きトリガーが見るジョブの終了状態は SUCCEEDED、STOPPED、FAILED、TIMEOUT、クローラーの終了状態は SUCCEEDED、FAILED、CANCELLED です。

ワークフローには実行プロパティ (名前と値の組) を持たせられ、前のジョブが書き込んだ値を後のジョブが読めます。途中のジョブが失敗した場合は、原因を直したうえで、失敗したところからワークフローの実行を再開 (resume) できます。

Point
  • Glue ワークフローの中で、1つのワークフローに入れるジョブ・クローラー・トリガーは合計 100 以下に抑えるよう案内されています。大きすぎると再開や停止でエラーになることがあります。
  • 1つのトリガーで起動できるクローラーは2つまでです。多くのデータストアを調べるときは、1つのクローラーに複数のソースを設定します。

③EventBridge と Lambda の位置づけ

は「きっかけ」を担当します。 へのオブジェクトの作成、 ジョブの状態変化、決まった時刻などのイベントを受け取り、 のステートマシン、Glue ワークフロー、 などを起動します。EventBridge 自体は処理の順序や再試行の状態を持たないため、複数の手順を管理するには Step Functions などと組み合わせます。

Lambda は「1つの処理」を担当します。ファイルの到着を受けて小さな変換をする、Glue ジョブを起動する を呼ぶ、といった短い処理には向きます。しかし、Lambda の中で別のジョブの完了を待ち続けたり、複数の Lambda を連鎖させて順序を管理したりすると、タイムアウト (最長 15 分) や再試行の管理を自分で作ることになります。

やりたいこと選ぶもの
毎日決まった時刻にパイプラインを始めるEventBridge Scheduler (またはルールのスケジュール) から Step Functions を起動
S3 にファイルが届いたらパイプラインを始めるS3 イベント → EventBridge → Step Functions
小さな変換を1回だけ行うLambda
複数のジョブを順に動かし、失敗時に再試行と通知をするStep Functions (または )

⚠️ 頻出: 「Lambda から Lambda を呼んで順序を管理している。失敗時の再試行と可視化を簡単にしたい」は Step Functions に置き換えます。

④依存関係、再実行、バックフィル

パイプラインの運用では、次の3つを最初から設計します。

観点内容道具ごとの考え方
依存関係前の処理が成功してから次を始める は状態の順序、 はタスク間の依存 (>>)、 は条件付きトリガーで表します。
再実行失敗したところから再開するStep Functions は Standard ワークフローの redrive (失敗した実行を、失敗したステップから再開)、MWAA はタスクのクリア、Glue ワークフローは resume を使います。
バックフィル過去の期間分をまとめて処理し直す はデータの期間 (論理日付) ごとに を実行するため、過去の期間を指定した再実行に向きます。Step Functions では、期間を入力にした実行を繰り返します。

再実行やバックフィルで同じデータを2回書いても結果が壊れないように、各処理は (何度実行しても同じ結果になる) に作ります。具体的には、日付パーティション単位で上書きする、 で upsert する、といった書き方をします (#26 の章で詳しく扱います)。

試験対策

①判断マトリクス

問題文のキーワード選ぶもの理由
、運用負荷を最小、AWS サービスの連携基盤の管理が不要で、・・ などを直接呼べます。
既存の の 、オープンソース、PythonDAG をそのまま に置いて動かせます。
Glue のジョブとだけをつなぐGlue ワークフローGlue の中で依存関係と再開を扱えます。
2つのジョブが両方成功したら次を起動Glue の条件付きトリガー (ALL)ジョブの終了状態を監視して起動します。
S3 に一定数のファイルがたまったら、または一定時間ごとに1回だけ のイベントで始まる Glue ワークフロー (バッチ条件)バッチサイズとバッチウィンドウのどちらか早い方で起動します。
決まった時刻に開始EventBridge Scheduler / Glue のスケジュールトリガー / Airflow のスケジュールどれも時間ベースのスケジュールを持ちます。
人の承認を待つ、長時間の処理を待つStep Functions (Standard)コールバックやジョブの完了待ちに対応します。
過去の期間を再処理したいMWAA (Airflow のバックフィル)データの期間ごとの実行を前提にしています。

②よくある誤答

  • だけで複数ステップの順序と再試行を管理しようとすること。EventBridge は起動のきっかけで、状態を持ちません。
  • の中でジョブの完了をし続けること。15 分の上限と待ち時間の課金があるため、 のジョブ完了待ち (.sync) を使います。
  • 以外のサービス (、、外部の ) も多く含むのに Glue ワークフローを選ぶこと。対象は Glue のジョブとです。
  • 既存の 資産があるのに Step Functions へ作り直すこと。移行の手間が最小という条件なら です。

参考文献

  1. ※1出題比率: AWS 公式の試験ガイドに記載された、採点対象の設問のうちその分野が占める割合です。

検索

キーワードを入力してください