Dbt

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

このポストについて Claude Code による dbt model 開発を test-first でやったらいい感じだったのでそれを紹介する。 実際に dbt model におけるある機能を test-first で開発するということをやってみる。 なんかしっくりこない Claude Code による dbt model 開発 現在本業でデータ基盤の移行を行っており、dbt model をたくさん作る必要がある。 Claude Code を使ってこの作業が楽にならないかなーと考えていたんだけど、それがなかなかしっくりこない。 なぜしっくりこないかというと、以降に際して dbt model を開発するために多様なコンテキストが必要になってくるということだと認識している。 例えばある1つの ETL 処理を dbt model に移行するにあたり、次のようなコンテキストを使いたい。 旧データ基盤の実装コード (Glue Job, Athena など) OpenMetadata に存在する旧データ基盤のメタデータ情報 社内の data modeling のルール (命名、その他) 参考にできそうな移行済み model 移行先である Databricks の仕様 などなど… このあたりのコンテキストをいい感じに整理して Claude Code が利用できるようにすべきなんだけど、その整理がまだ進んでいない。 (やれよって話なのはわかっています…) というので Claude Code がバシッとハマるという感覚をまだ得られずにいた。 dbt の unit tests で、データ基盤移行でちょっと複雑な処理を dbt model に実装しないといけなくなり、これまでやっていなかった dbt の unit test を導入することにした。 ...

このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回 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 経由で行います。 ...