このポストについて

データ基盤移行について書いていくシリーズの最終回です。
シリーズ一覧はこちらから。

前回 Part 7. ELT 処理移行編では最も苦労した ELT 処理の移行について書きました。
ELT 処理の移行が終わり、データ基盤移行としては一区切りついたので今回は総集編です。

Part 1 の冒頭で「データ基盤移行について書かれた技術ブログは割とさらっと書かれていることが多い」「本当は記事に表れていない辛さや工夫などがあるはず」と書きました。
そこから2年近くかけて7本の記事を書いてきましたが、どうだったでしょうか。
少なくとも辛さはそれなりに伝わったのではと思います。

このポストではシリーズ全体をざっと振り返りつつ、途中の記事で今後の課題として挙げていたこと、そして終わった今だから言えることを書いていきます。
初めてこのシリーズを読む方はまずこのポストで全体像をつかんでから、気になる回を読んでいただくのがいいかもしれません。

移行の全体像

組織と前提

改めて、どういった組織におけるデータ基盤移行なのかについて。

  • 社員規模: 〜100名
  • web 系の B2C ビジネス
  • データチームの構成
    • マネージャ: 1名 (データエンジニアリングの経験はほぼない)
    • データエンジニア: 2〜4名 (時期によって変化)

意思決定プロセスは JTC 感があり、人員的にはまあまあきびしい。
よくある中小 IT 企業のよくあるデータ基盤移行です。

Before / After

移行前後のアーキテクチャを並べるとこのようになります。

旧データ基盤新データ基盤
storageS3S3
table formatParquetDelta Lake
SQL engineAthenaDatabricks SQL
ETL / ELTGlue Job (PySpark), Athenadbt (Databricks SQL)
workflow orchestrationMWAA (Apache Airflow)Lakeflow Jobs
data catalog / メタデータGlue Data Catalog, OpenMetadataUnity Catalog, dbt YAML
IaCCDKTerraform

ざっくり言うと AWS のサービスの寄せ集めから、Databricks + dbt を中心とした構成になりました。
各要素の選定理由については Part 2. 技術選定編、Part 3. アーキテクチャ編をご参照ください。

タイムライン

移行の流れを時系列で並べるとこんな感じです。
メタデータについては移行の前から取り組んでいたので、少し時期が早いところから始まっています。

timeline
    2023 : OpenMetadata 導入
    2024 : DMMA, 利用者アンケート
         : ロードマップ作成
         : 技術選定 (PoC)
         : IaC, CI/CD 構築
         : ELT 処理の移行作業
    2025 : AI ワークフローによる移行効率化
         : ELT 処理の移行作業
    2026 : メタデータの Databricks への移行
         : ELT 処理の移行作業完了

(図が見にくい場合はライトモードにしてください)

計画から ELT 処理の移行完了まで2年。
長かった。

各回のダイジェスト

ここで各回の内容を簡単に振り返っておきます。
詳しくはそれぞれの記事をご覧ください。

Part 1. 戦略策定編

エライ人の鶴の一声で始まった移行を、単なる技術スタックの置き換えで終わらせないために戦略を考えた回です。
データマネジメント成熟度アセスメント (DMMA) と利用者アンケートによりボトムアップで課題を洗い出し、DWH 製品と dbt の導入を軸としたロードマップを作りました。
一方でトップダウンの戦略策定はうまくいかず、タイトルに偽りありの回でもあります。

Part 2. 技術選定編

一次調査 (スクリーニング) と二次調査 (PoC) を経て Databricks を選定し、予算を獲得するまでの回です。
決め手はコストパフォーマンス、オープン性、アナリストからの評価でした。
予算獲得ではステークホルダーへの事前説明により「雰囲気」を醸成することの大切さを学びました。

Part 3. アーキテクチャ編

データ取込、workflow orchestration、ELT、data catalog、storage のそれぞれの技術スタックと、medallion architecture に dbt best practice の staging layer を加えたデータの階層構造について書いた回です。
Spark を直接書くのはやめて SQL + dbt でやるぞ、という方針もここで示しています。

Part 4. AI ワークフローで移行作業効率化編

Glue Job から dbt model への移行作業を、LangGraph + LangChain で作った AI ワークフローで効率化した回です。
移行済みの table を few-shot prompting の例として使い、体感で50~80%ぐらいの工数削減ができました。
AI まわりの進化は早く、今となっては古い内容です。

Part 5. IaC と CI/CD 編

初手で絶対に CI/CD 環境を構築するマンが Terraform による IaC と GitHub Actions による CI/CD を構築した回です。
Databricks のリソースを Terraform で管理する際の注意点についても書いています。

Part 6. メタデータ編

「メタデータ？ナニソレオイシイノ？」の暗黒時代から OpenMetadata の導入、そして Databricks (dbt YAML) への移行までの回です。
データオーナーを決められたことが運用面で効いています。

Part 7. ELT 処理移行編

このシリーズで最も苦労した ELT 処理の移行の回です。
Glue 依存の強いコード、column 命名ルールの統一、そして何より工数の確保に苦しみました。

それからどうした

シリーズの途中で「今後の課題」などと書いておきながら、そのままになっていたものがいくつかあります。
それがどうなったかを補足的に書いておきます。

dbt の unit test

Part 5 では dbt の unit test の導入を検討中で、近いうちに GitHub Actions から実行できるようにすると書きました。

こちらについては一部の dbt model や macro について unit test を導入し、GitHub Actions で実行するという運用が始まっています。
unit test はこれから拡大していきたいです。

メタデータの移行と Elementary

Part 6 では OpenMetadata から dbt YAML へのメタデータの移行がまだ現在進行形であること、Elementary のデータを一部のデータ品質モニタリングに使う計画があることを書きました。

dbt YAML へのメタデータ移行は現時点でまだ完了しておらず、継続中です。
一方で Elementary と dbt の data test を組み合わせたデータ品質のチェックの運用が始まっています。
何をチェックすべきかはなかなか難しい問題ですね。

旧データ基盤の停止

Part 2 では新旧のデータ基盤の並行稼働期間の費用についても見積もる必要があると書きました。

実は旧データ基盤はまだ止まっていません。
旧データ基盤を利用する外部システムがまだあり、そちらの移行が完了していないためです。
そういう意味では真の移行完了はまだということになるでしょう。
年末までにはどうにか…

振り返り

移行が一区切りした今、全体を通して振り返ってみます。

うまくいったこと

初手で IaC と CI/CD を入れた

Part 5 で書いたとおり、構築の最初期から Terraform と GitHub Actions を導入しました。
Databricks に慣れていない時期に入れるのはそれなりにたいへんでしたが、結果として正解だったと思います。
リリースの数だけ自動化のリターンがあり、ジュニアなメンバーでも安心してリリースできる状態になっています。

dbt による依存関係の管理

Part 7 で触れたとおり、table 間の依存関係を Airflow の DAG から dbt の ref に移したことで開発・運用の手間がかなり減りました。
またデータ処理の記述自体も Python (PySpark) から SQL になったことでやりやすくなっています。

地味ですが日々の開発で効いています。
今のチームではジュニアなメンバーでも少ない工数で table 追加・変更が行えるようになりました。

Databricks の導入

Part 3 で書いたように新しいアーキテクチャは Databricks 中心の構成となっています。
これにも触れないわけにはいきません。

  • Unity Catalog による一貫した権限管理
  • 統合された開発体験・分析体験
  • Delta Lake が提供する ACID transaction 等
  • Genie すごい
  • etc.

Databricks の各種機能の活用はまだ道半ばで、もっと運用に取り入れられる箇所があるはずです。
とはいえこの船に乗っていれば良さそうという安心感が強いです。

事前の根回し

予算獲得におけるステークホルダーへの説明 (Part 2)、メタデータ整備におけるデータオーナーの設定と依頼 (Part 6)。
当初は本当に必要か？と思っていたこれらのステップは、結果としてどれも効いていました。
データエンジニアの仕事はステークホルダーが多いこともあり、技術だけでは完結することはなく政治的な要素も含まれてきます。

うまくいかなかったこと

トップダウンの戦略策定

Part 1 で書いたとおり、事業戦略とひもづけたデータ戦略を作ることはできませんでした。
結果として移行のスコープは戦術レベルのロードマップに基づくものとなり、経営から見ると「単なる技術スタックの置き換え」に見えていたかもしれません。
これは後述の工数確保の問題にもつながっていると思っています。

工数の確保

Part 7 で書いたとおり、組織内で優先度の高い案件が始まるたびに移行の工数が削られました。
「優先度が上がらず、なかなかデータ基盤の移行が終わらない」というあるある話を事前に聞いていたにもかかわらず、見事にそうなりました。
データ基盤移行が経営から見て重要な取り組みとして認識されていれば、もう少し違ったのかもしれません。

もう一度やるなら

もしもう一度データ基盤の移行をすることになったら、次のようにすると思います。

  • 移行時は schema を変えない
    • Part 7 で書いたとおり、column 命名ルールの統一は利用者に喜ばれた反面、開発とレビューのコストを上げた
    • アーキテクチャの移行とデータモデル改善は分けてやる方が見通しがいい
  • 最初から AI エージェント前提で効率化する
    • 今なら AI ワークフローを自作するより、AI エージェントでもっとうまくやらるでしょう
  • 移行の意義を経営層と先に握る
    • 技術スタックの置き換えではなく、組織のデータマネジメントにとってどういう意味があるのかを先に議論しておく
    • 工数確保のための政治力の源泉にもなる

これからデータ基盤移行をする人へ

シリーズを通しての学びを、これからデータ基盤移行をやろうとしている人向けにまとめておきます。
あくまである一社での例です。

  • 移行の目的を技術スタックの置き換えより一段高いところに置く
  • 課題はサーベイ (DMMA や利用者アンケートなど) で定量的に把握し、ステークホルダーに説明できるようにしておく
  • 技術選定ではよく使うワークロードで PoC をやる (コスパはワークロード次第)
  • 予算獲得や他チームへの依頼は根回しから
  • IaC と CI/CD は初手で入れる
  • 移行作業には AI フル活用
  • 移行時に schema は変えない
  • 工数を確保する強い政治力、または徹底的な効率化を用意する

これから

ELT 処理の移行が完了し、ようやく新しい基盤の上で新しいことができるフェーズになりました。
今後は例えば次のようなことに取り組んでいきたいと考えています。

  • data contract の導入
  • よりセキュアなデータの取り扱い
  • ビジネスメタデータの量と質の担保、およびそれを活かした Genie などの AI 活用

データ基盤移行のシリーズとしてはこれでいったん完結となります。
新しい基盤の上でやったことについては、また別の記事で書くかもしれません。

おわりに

計画から2年、記事としては7本 + 総集編となりました。
最初に「全編書き終わるのはかなり先になりそう」と書きましたが、本当にかなり先になりました。

ふつうの会社のふつうのデータ基盤移行として、うまくいったこともいかなかったことも含めて書いてきました。
これからデータ基盤移行をする方、今まさに苦労している方の参考に少しでもなれば幸いです。

以上、現場からでした。