Data Platform

このポストについて 書籍『クラウド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 のようになっていました。 旧データ基盤の開発・運用側 (データエンジニア) としても、また社内の利用者側としてもいろいろと問題が挙がってきてはいました。 しかしそれをうまく集約・言語化できていないという状況でした。 そんな中でエライ人の鶴の一声で移行しようぜ！ということになり、データ基盤の移行を検討することに相成りました。 移行計画を考えるにあたり まず考えたこと データ基盤の移行は組織におけるデータマネジメントにおいて重要な位置づけとなるはず。 したがって単なる技術スタックの置き換えというスコープで考えるのはもったいないです。 組織のデータマネジメントの未来を想定して、戦略を持って開発・運用を進めるべきであると考えました。 そのためにはイシューを明確化しないといけません。 でもどの抽象度レベルで？ ボトムアップの戦術策定 まずは現場感覚、ボトムアップでの課題を明らかにすることを考えました。 本来は後述する戦略レベルから先に考えるべきですが、実際に目に見えている課題があり、取り組みやすかったというところで戦術のレベルから考え始めています。(良し悪しはある) 現状のアーキテクチャと運用では戦略策定への対応が難しいため、せめてそのための地ならしとして今見えている課題に対応できる状態にしたいというのもありました。 ...