Data Platform

このポストについて データ基盤移行について書いていくシリーズの最終回です。 シリーズ一覧はこちらから。 前回 Part 7. ELT 処理移行編では最も苦労した ELT 処理の移行について書きました。 ELT 処理の移行が終わり、データ基盤移行としては一区切りついたので今回は総集編です。 Part 1 の冒頭で「データ基盤移行について書かれた技術ブログは割とさらっと書かれていることが多い」「本当は記事に表れていない辛さや工夫などがあるはず」と書きました。 そこから2年近くかけて7本の記事を書いてきましたが、どうだったでしょうか。 少なくとも辛さはそれなりに伝わったのではと思います。 このポストではシリーズ全体をざっと振り返りつつ、途中の記事で今後の課題として挙げていたこと、そして終わった今だから言えることを書いていきます。 初めてこのシリーズを読む方はまずこのポストで全体像をつかんでから、気になる回を読んでいただくのがいいかもしれません。 移行の全体像 組織と前提 改めて、どういった組織におけるデータ基盤移行なのかについて。 社員規模: 〜100名 web 系の B2C ビジネス データチームの構成 マネージャ: 1名 (データエンジニアリングの経験はほぼない) データエンジニア: 2〜4名 (時期によって変化) 意思決定プロセスは JTC 感があり、人員的にはまあまあきびしい。 よくある中小 IT 企業のよくあるデータ基盤移行です。 Before / After 移行前後のアーキテクチャを並べるとこのようになります。 旧データ基盤 新データ基盤 storage S3 S3 table format Parquet Delta Lake SQL engine Athena Databricks SQL ETL / ELT Glue Job (PySpark), Athena dbt (Databricks SQL) workflow orchestration MWAA (Apache Airflow) Lakeflow Jobs data catalog / メタデータ Glue Data Catalog, OpenMetadata Unity Catalog, dbt YAML IaC CDK Terraform ざっくり言うと AWS のサービスの寄せ集めから、Databricks + dbt を中心とした構成になりました。 各要素の選定理由については Part 2. 技術選定編、Part 3. アーキテクチャ編をご参照ください。 ...

このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回 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 名を指定して参照するだけで依存関係を表現できます。 これはかなり楽でした。 ...

このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回 Part 5. IaC と CI/CD 編では Terraform による IaC とそれに基づく GitHub Actions による CI/CD について書きました。 今回はみんな大好きメタデータです。 メタデータとはなんぞやという方はこちらの記事も御覧ください。 スコープ 実は今回のデータ基盤の移行のその前から OpenMetadata によるメタデータ管理を始めていました。 その導入、およびそこからの Databricks への移行について紹介します。 DMBOK2 によるとメタデータは3種に分類され、 ビジネスメタデータ テクニカルメタデータ オペレーショナルメタデータ がありますが、ここでは主にビジネスメタデータについて扱います。 あまり新規性のある話にはなりませんが、ケーススタディとしてご参考になれば。 メタデータ管理の導入 私の所属する組織がどのようにメタデータを導入していったか、大まかな流れは次のようになっています。 暗黒時代 OpenMetadata の導入 Databricks への移行 それぞれのフェーズについて述べていきます。 1. 暗黒時代 (2022年〜) 「メタデータ？ナニソレオイシイノ？」という状況がスタート地点です。 私が今の組織にデータエンジニアとして join した直後はまだ組織内で「メタデータ」という言葉が認知されておらず、「ビジネスメタデータがなくて不便」という課題すらも認識されていませんでした。 とはいえ join の直後、データ基盤のデータを眺めてみてもこれらが何なのか人に聞かないとわかりません。 table や column の命名がわかりやすいものになっていない 1 ことが、データ理解しにくさに輪をかけている状況でした。 この時点ではこの記事のタイトルにもあるデータ基盤移行はまだ始まっておらず、旧データ基盤を使っていました。 旧データ基盤では Athena や Glue Job でデータを処理しています。 したがって Glue Data Catalog にビジネスメタデータを置けないかと検討しましたが、難しそうだなという結論になりました。 たしか当時は日本語が扱えないとかだったような。(うろ覚え) ...

このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回 Part 4. AI ワークフローで移行作業効率化編では移行するための苦労と効率化について書きました。 今回はがらっと変わって IaC と CI/CD について書きます。 スコープ 今回は開発寄りの話です。 データ基盤の構築にあたり Terraform を使って IaC (Infrastructure as Code) を実現し、さらにそれに基づいて GitHub Actions による CI/CD (Continuous Integration & Continuous Derivery) 環境を作ったという話をしていきます。 IaC で作りたいアーキテクチャは AWS 上の Databricks 環境とその周辺です。 アーキテクチャについて詳しくは Part 3. アーキテクチャ編などをご参照ください。 だいたい以下の図のような話です。 お気持ち表明 こんにちは、初手で絶対に CI/CD 環境を構築するマンです。 初手で絶対に CI/CD 環境を構築するマンは、初手で絶対に CI/CD 環境を構築するぞ！という強い気持ちを持っています。 Databricks 上にデータ基盤を構築するにあたり、他社事例でインフラ構築を自動化していないケースを見たこともあります。 しかし我々のチームでは PoC 終了後の構築最初期から IaC としてインフラをコード化し、それを CI/CD の仕組みで自動でデプロイすることを決めていました。 次のような理由からです。 リリースの数だけ自動化のリターンがあるので、最初から自動化しておくのが最もリターンが大きい チームにはジュニアなメンバーもおり、手動の運用はオペミスや production, staging などの環境差発生のリスクが大きい 社内で Terraform や GitHub Actions などがよく使われており、導入できる下地があった まだ Databricks にそこまで慣れていない導入初期にこれらの仕組みを入れるのはそれなりにたいへんです。 しかしそのたいへんさ以上のメリットがあると判断しました。 ...

このポストについて 書籍『クラウドFinOps 第2版』を読んだところ、FinOps にデータマネジメントやデータエンジニアリングに深く関連する内容があるということがわかったのでまとめてみる。 書籍について J.R. Storment; Mike Fulle. クラウドFinOps 第2版 協調的でリアルタイムなクラウド価値の意思決定 O’Reilly Japan. 2025年3月に出版。 ちなみに原著の初版は2019年、第2版は2023年。 タイトルのとおり FinOps (後述) について書かれた書籍となっている。 著者は両名とも FinOps Foundation の関係者であり、本文中にも随所に FinOps Foundation についての記載が出てくる。 私はデータエンジニア、ソフトウェアエンジニアとして日々 AWS その他のクラウドサービスを利用している。 クラウドサービス上に例えばデータ基盤等を構築し、ビジネス上の価値を提供している。 その一方でクラウドを使うということは料金的な意味でのコストがかかるということでもある。 もちろん支払うコストは少ない方がいい。 それは分かるのだが、それ以上のクラウドコストについての体系的な考え方を持ち合わせていなかった。 毎日それなりの額を使ってるのにね。 というのが本書を読もうと思った理由だった。 FinOps とは 定義 これを書いている2025年8月現在における FinOps Foundation での定義は以下のようになっている。1 “FinOps is an operational framework and cultural practice which maximizes the business value of cloud and technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.” ...

このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回 Part 3. アーキテクチャ編ではどういったシステム構成にしたかを書きました。 今回はその技術スタックへと移行するための苦労と効率化について書きます。 (次は CI/CD の話をすると書きましたが…スマンありゃウソだった) スコープ 今回はやや小さいスコープの話です。 データ基盤における ETL (ELT) 処理の移行作業を対象としています。 移行作業における工数的な課題を AI ワークフローを作って効率化して軽減したという話になります。 ETL 以外の移行作業は今回はスコープ外となります。 課題 旧データ基盤から新データ基盤へと table およびそれを更新するための処理を移行するにあたり工数面での課題が2つあります。 技術スタックの移行 column 命名などの標準化 これらについて述べます。 技術スタックの移行 データ基盤の移行において、新旧の環境で技術スタックは次のようになっています。 旧データ基盤 ETL: Glue Job 新データ基盤 ELT: dbt-databricks つまり Glue Job の Python コードを dbt model、つまり SQL に翻訳する必要があり、それなりに手間がかかります。 さらにこの Python コードは次のような問題もあり、移行のハードルを上げます。 UDF を実装して特殊な処理を行っているケースがある Spark の API だけでなく Glue の API をふんだんに使っている (なるべく Spark に寄せればいいものを…) (ここ数年の業務で見た中で一番というぐらいに) コード品質が低い column 命名などの標準化 旧データ基盤は利用者への配慮があまりない状態で table の schema が作られており、利用者にとって使いにくいものとなっていました。 それを改善するため、新データ基盤では次のようなルールを導入しました。 ...

このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回 Part 2. 技術選定編では技術選定について書きました。 今回はそれを踏まえた結果としてどのようなアーキテクチャになったかを書きます。 スコープ 前回の記事ではプラットフォームとして Databricks を選定したことやその経緯について記載しました。 一方、それより詳細な技術スタックを含むシステムアーキテクチャについては示していませんでした。 例えばデータ基盤では通常次のような技術スタックについて考える必要があります。 データ取込 workflow orchestration ELT (or ETL) storage これらについて述べ、またデータ基盤の階層構造についても説明します。 システムアーキテクチャ データ基盤のシステム・アーキテクチャです。 よく混同されがちですが、データアーキテクチャではありません。 AWS + Databricks の構成をベースとして構築されています。 概要図 データ取込 現時点ではデータソースとしては S3 に置かれた半構造化データ (JSON)、RDS がメインとなっています。 これら2つの取込方法について述べます。 まず、S3 のデータは SQL の copy into 文により取り込んでいます。 Get started using COPY INTO to load data | Databricks Documentation Auto Loader を使う方が Databricks 的でありそれも検討したのですが、schema evolution や冪等性など検討した結果として copy into を採用しました。 RDS からのデータ取込は foreign catalog 経由で行います。 ...

このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回は戦略策定 (実際は戦術) までのところを書きました。 今回はそれを踏まえた技術選定、およびその後の予算獲得について書いていきます。 また、こちらは Databricks Advent Calendar 2024 シリーズ 2 の16日目の記事にもなっています。 はいそうです、出落ちですが技術選定として Databricks を選ぶことになります。 スコープ 前回 Part 1. 戦略策定編では概ねのロードマップが決まり、まずはデータ基盤のリアーキテクチャをやっていくことになりました。 リアーキテクチャにおいてはどのような技術スタックを使っていくかが重要な選択になります。 データ基盤においてはデータ処理のためのストレージとコンピュートの選択がとても重要です。 以降ではこの2つをあわせた DWH 製品の選定について書いていきます。 「DHW 製品」という言葉は適切ではないかもしれませんが、ここではストレージ + コンピュートが組み合わさったものぐらいに考えてください。 もちろんデータ基盤には他の技術要素もあり、それらも軽くない選択ですがこのポストでは割愛します。 (気が向いたら別記事で書くかも) 技術選定の目的 まず何のために技術スタックの置き換え、ひいては技術選定をするかの目的を明確にしておく必要があります。 旧データ基盤では次のような技術スタックになっていました。 ストレージ: S3 コンピュート: Glue Job, Athena この構成には次のような課題がありました。 主にこれらの課題を解決するために DWH 製品の乗り換えを検討することになりました。 dbt との親和性の低さ 一貫したガバナンスの欠如 dbt との親和性の低さ 前回作成したロードマップにおいて、dbt の導入が課題解決における重要なポイントになっています。 dbt の周辺エコシステムがデータ基盤の課題の解決に大きく貢献すると考えています。 また、データパイプラインの開発・運用の負荷も dbt 導入で軽減できそうです。 旧データ基盤では Glue Job と Athena クエリを組み合わせた複雑なパイプラインになっており、table を1つ追加するだけでもいろいろなコードに手をいれる必要があります。 ほぼ SQL で実装でき、かつ宣言的にパイプライン構築できる dbt は魅力的です。 仮に旧データ基盤に dbt を導入するとなると dbt-athena を使うことになります。 ただ dbt による Athena のサポートはやや弱く、dbt-athena はコミュニティ版から少し前に移管されたものですし、これを書いている2024年12月の時点で dbt Cloud の Athena のサポートはまだプレビューです。 反論がある方もいらっしゃるかもしれませんが、モダンなデータ基盤構築において Athena はやや影が薄い印象があり、dbt のサポートの弱さもこれが原因だと思います。 (ただし直近の re:Invent 2024 の内容からすると潮目が変わる可能性もありそうです) ...

このポストについて データ基盤移行について書かれた各社の技術ブログなど見かけることがありますが、割とさらっと書かれていることが多いように思います。 本当はいろんな面で苦労があり、記事に表れていない辛さや工夫などがあるはず。 ということで今自分が経験している普通の会社の普通のデータ基盤移行について、詳しく記事にしてみようと考えました。 何回かに分けてデータ基盤移行のいろいろな側面を、うまくいったこともいかなかったことも含めて書いていきます。 とはいえ現在進行形なので、全編書き終わるのはかなり先になりそうです。 データ基盤移行のシリーズ一覧はこちらから。 移行の背景 組織 まずイメージしやすいよう、どういった組織におけるデータ基盤移行なのかについて軽く触れておきます。 社員規模: 〜100名 web 系の B2C ビジネス データチームの構成 マネージャ: 1名 (データエンジニアリングの経験はほぼない) データエンジニア: 2 -> 3名 (途中で採用) 中小のベンチャー？企業ではありますが、意思決定プロセスは JTC 感があります。 私はデータエンジニアのポジションとなっており、その視点からの話であることにご留意ください。 小さい組織ということで私は移行の計画から設計、開発その他のあらゆるフェーズに中心的に関わっています。 どこもそうだと思いますが、人員的にはまあまあきびしい。 よくある中小 IT 企業のよくあるデータ基盤移行の話だと思っていただきたく。 大企業ではないのでそこまでちゃんとはしていません。 (ちなみに自分のブログで本件を記事にしていいかは上長に確認の上、OK をもらっています) 旧データ基盤 一連のポストでは移行前のデータ基盤のことを「旧データ基盤」と表記するものとします。 旧データ基盤は AWS 上で構築されており、アーキテクチャについて簡単に挙げると storage: S3 ETL: Glue Job, Athena SQL engine: Athena workflow orchestration: MWAA のようになっていました。 旧データ基盤の開発・運用側 (データエンジニア) としても、また社内の利用者側としてもいろいろと問題が挙がってきてはいました。 しかしそれをうまく集約・言語化できていないという状況でした。 そんな中でエライ人の鶴の一声で移行しようぜ！ということになり、データ基盤の移行を検討することに相成りました。 移行計画を考えるにあたり まず考えたこと データ基盤の移行は組織におけるデータマネジメントにおいて重要な位置づけとなるはず。 したがって単なる技術スタックの置き換えというスコープで考えるのはもったいないです。 組織のデータマネジメントの未来を想定して、戦略を持って開発・運用を進めるべきであると考えました。 そのためにはイシューを明確化しないといけません。 でもどの抽象度レベルで？ ボトムアップの戦術策定 まずは現場感覚、ボトムアップでの課題を明らかにすることを考えました。 本来は後述する戦略レベルから先に考えるべきですが、実際に目に見えている課題があり、取り組みやすかったというところで戦術のレベルから考え始めています。(良し悪しはある) 現状のアーキテクチャと運用では戦略策定への対応が難しいため、せめてそのための地ならしとして今見えている課題に対応できる状態にしたいというのもありました。 ...