このポストについて
データ基盤移行について書いていくシリーズです。
シリーズ一覧はこちらから。
前回 Part 6. メタデータ編ではメタデータの運用開始と移行について書きました。
今回は最も苦労してようやく最近終わった ELT 処理の移行について記載します。
この移行については Part 3. アーキテクチャ編でも触れているのですが、今回はもう少し詳細に書きます。
ELT 処理の移行の概要
このデータ基盤移行では Amazon Athena を中心とした構成の旧データ基盤から、Databricks で構成された新データ基盤への移行を行いました。
ELT 処理まわりについて、移行前は Glue Job (PySpark) と Athena クエリを Apache Airflow から回すというような形になっていました。
移行後は処理エンジンは Databricks SQL に統一し、それを dbt から回すという形にしました。
なぜこうしたのかについては Part 3. アーキテクチャ編をご覧ください。
一方でそっちには書いていなかったのですが、table 間の依存関係の管理を Apache Airflow から dbt に変更することによってかなり開発・運用の手間が減ったという面があります。
Aiflow はいろいろなことができ、また UI も使いやすく worfklow orchestration の仕組みとして悪いものではありません。
しかし DAG 上で task 間の関係として依存関係を管理するのはそれなりに手間がかかります。
dbt の場合は下流 model の定義において {{ ref('upstream_model') }} のように上流 model 名を指定して参照するだけで依存関係を表現できます。
これはかなり楽でした。
ELT 処理の移行の苦労
このデータ基盤移行で最も苦労したのがこの ELT 処理の移行です。
ここではその苦労話を書いていきます。
Glue Job から Databricks SQL へのコード変換
元の Glue Job として記述されたコードは Python で書かれています。
これを dbt 用の Databrciks SQL のコードに書き換えるという作業があります。
Glue Job のコードは時折 Python で特殊な処理が実装されていたりして、それを読み解き SQL で実装、またはそれが困難な場合は Python UDF を作る必要があります。
これにはかなり骨が折れました。
今なら AI エージェントで一発かもしれませんが、この移行を始めた当時はまだエージェントとしての AI はあまり使われていませんでした。
そこで LangGraph + LangChain で AI ワークフローを実装し、作業コストを下げるなどしていました。
ちなみに「Glue Job なら PySpark だからほぼそのまま Databricks で動くのでは？」と思う方もいらっしゃるかもしれません。
残念ながら元コードはかなり Glue 依存が強い書き方になっていました。
Spark の DataFrame ではなく Glue の DynamicFrame を使っているところがたくさんあったり、などです。(ポータビリティ大事！)
イメージとしてはこんな感じ。
# Python で何か PySpark の built-in でできないことをやってる
dynamic_frame_2 = do_something(dynamic_frame_1)
# DynamicFrame 独自のメソッドを使用
dynamic_frame_3 = dynamic_frame_2.apply_mapping([...])
...
どちらにしろ Spark のコードは開発・運用にハードルが高いのでコードとしては SQL にしたいというのもありました。
column 命名ルールの統一
旧データ基盤では table ごとに column の命名がそろっておらず、同じドメインで同じ概念を指す属性でも table によって呼び名が違うというような状況になっていました。
この状況を移行のタイミングで改善するため、column の命名ルールを決めて命名を統一することを行いました。
例えば「時刻を表す column は timestamp 型にし、名前は <過去分詞形>_at にする (ex. created_at)」などです。
これは結果としてデータ基盤利用者から喜ばれた反面、table の schema が右から左ではなくなったため開発とレビューのコストを上げるものとなってしまいました。
システムの移行においては schema を変えず、いったん移行が終わった後に整理するという方法もあります。
移行済みの table に対して column 名をルールに準拠させた view を作るという形もいいでしょう。
ただそれだと利用者から見たときに参照先が複数ある状態になり、それもいかがなものかというのがあります。
とはいえもしもう一度移行をすることになったら、移行時に schema は変えない方針を取る可能性が高いですね…
移行対象の table 数
以上のようなことを table の数だけやる必要があります。
旧データ基盤の table の棚卸しを行い、移行不要なものは移行対象から外すなども行った結果、移行対象の table は最終的に数十件 (silver, gold layer 換算) になりました。
この数について大きめの会社からすると「めっちゃ少ないやん！」となると思います。
しかしあまり大きくない組織の少ない人員ではなかなかたいへんでした。
工数の確保
結局これがダイレクトに効いてきます。
移行を始める前に他社の人から「優先度が上がらず、なかなかデータ基盤の移行が終わらない」というあるある話を聞きましたが、我々も見事にそうなりました。
データ基盤の移行を始めた後に組織内で別の優先度の高い案件が始まり、どうしてもそちらに工数を突っ込まないといけないというようなことが複数回ありました。
「このクォーターは移行に工数を使えない」というような時期もあり辛い思いをしました。
移行の完了
というような苦労がありましたが、結果として ELT 処理の移行は完了しました！
旧データ基盤上にあった必要な table が新データ基盤でも使える状態になったわけです。
結果としてこの移行を終えるまで、計画から2年かかってしまいました。
ようやくこれから新しい基盤の上で新しいことができるフェーズとなってきました。
もしこれからデータ基盤の移行をやろうとしている人がいるのであれば、工数を確保する強い政治力、または徹底的な効率化が必要だということをお伝えしたいです。
今ならどちらかというと後者、AI エージェントを使っての効率化を頑張るのが勝ち筋だと思います。
次回予告
移行終わったし、総集編でも書こうかな。