ふつうのデータ基盤移行 - Part 2. 技術選定編
このポストについて データ基盤移行について書いていくシリーズです。 前回は戦略策定 (実際は戦術) までのところを書きました。 今回はそれを踏まえた技術選定、およびその後の予算獲得について書いていきます。 また、こちらは 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 の内容からすると潮目が変わる可能性もありそうです) ...
