Databricks

このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回 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 にそこまで慣れていない導入初期にこれらの仕組みを入れるのはそれなりにたいへんです。 しかしそのたいへんさ以上のメリットがあると判断しました。 ...

このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回 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 の内容からすると潮目が変わる可能性もありそうです) ...