このポストについて

データ基盤移行について書いていくシリーズです。
前回は戦略策定 (実際は戦術) までのところを書きました。
今回はそれを踏まえた技術選定、およびその後の予算獲得について書いていきます。

また、こちらは 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 の内容からすると潮目が変わる可能性もありそうです)

したがってより存在感があり、エコシステムに受け入れられている DWH 製品にどこかのタイミングで乗り換えたいと以前から考えていました。
つまりプロダクトレベルの data gravity にあやかりたい。

一貫したガバナンスの欠如

旧データ基盤の技術スタックは寄せ集め感が強く、うまく表現できませんが全体として調和した上でガバナンスを持って開発・運用するのが難しいと感じていました。
複数の AWS サービスを組み合わせて考える必要があり、また初期開発当時のチームの開発スキルの問題もあり、開発上も運用上も一貫したガバナンスを持つことが困難でした。
モダンな DWH 製品ではこのあたりの配慮があります。

技術選定で考慮したいこと

技術選定では上記の課題を解決できるように DWH 製品を選ぶわけですが、加えて一般的に DWH 製品に求められる観点も考慮する必要があります。
次のような観点も見ていきます。

  • 人的・金銭的コスト (初期導入時／運用時)
  • バックアップとリカバリ
  • スケーラビリティ
  • データ統合のしやすさ
  • セキュリティ
  • UI/UX
  • エコシステム
  • サポート

技術選定の実施

技術選定の流れ

全体としては次のような流れで技術選定を行いました。

flowchart TD
    first["一次調査 (スクリーニング)"]
    second["二次調査 (PoC)"]
    decision["技術スタックの決定"]

    first --> second
    second --> decision

一次調査 (スクリーニング)

一次調査では軽めの調査で広い候補から少数の候補へとスクリーニングを行います。
ここでは旧データ基盤の維持も含め、6つの候補が挙げられました。
6つの候補は一般的によく利用されているものであり、データエンジニアの皆さんがぱっと想像できるようなアレとかアレとかです。

一次調査は公式ドキュメントなどのカタログスペックでの調査が主となっており、前述の観点で候補を比較しました。
結果として Databricks および製品 A に候補が絞られました。

(ここで AI が作ったタイトル画像をもう一度見ていただきたいのですが、朱色のレンガは焼いて作るので火属性だし、水色の、あの、あれはもちろん氷属性ですね)

二次調査 (PoC)

二次調査では一次調査の結果を受け、2つの候補でそれぞれ PoC を行い比較します。
PoC では実際に DWH 製品を導入したことを想定し、DWH 上に dbt でデータパイプラインを構築します。
業務で使う代表的なワークロードの一部を再現しました。

特に処理のコストパフォーマンスはワークロード次第なので、組織でよく使うワークロードを想定して実際に動かしてみないとわかりません。
また UI/UX の使い勝手なども実際に使ってみないとわかりません。
使い勝手的なところはアナリストにも評価していただきました。

PoC の段階ではまだ IaC は導入せず、UI などから必要なリソースを用意しました。
データエンジニア2名でそれぞれ Databricks、製品 A で環境を構築し、2〜3週間ぐらいで検証しました。

ちなみにこのとき両製品で同じ dbt プロジェクトを使っていました。
このように dbt は比較的高い相互運用性があり、何かあったときの DWH の変更のハードルを下げてくれるということを実感しました。
(クエリの書き方次第ではある)

技術スタックの決定

さて、このようにして両製品を比較したわけですが、もともと想定していた観点ではそこまで大きな違いはありませんでした。
とはいえ以下の点で優れていたことにより Databricks の採用を決めました。

  • コストパフォーマンス
    • 我々の代表的なワークロードでは Databricks の方が若干コストが安かった
    • これはワークロードによっても変わると思われる
  • オープン性
    • データ実体は Delta Lake という open table format
    • また顧客 (=我々) 管理の S3 bucket に保存されるので透明性が高く、データの囲い込みがない
    • OSS 志向も強い
    • 製品 A も open table format を選択できるが、パフォーマンスで劣るとの話があった
  • アナリストからの評価

とまあ現場レベルではこれで行きましょうという合意ができたわけですが、Databricks を使えるようにするため今度は予算を獲得する必要があります。

予算獲得

予算獲得までの流れ

どのように予算を獲得するかは組織に大きく依存するでしょう。
ウチの場合は以下のような流れでした。

flowchart TD
    estimate["費用見積"]
    stakeholder["ステークホルダーへの説明"]
    approval["承認会議"]

    estimate --> stakeholder
    stakeholder --> approval

費用見積

技術スタックが決まったので費用を見積もります。
厳密に見積もるのは難しいですが、ある程度の仮定をおいて計算します。

通常のデータ基盤であればストレージとコンピュートの費用が中心になるでしょう。
両者はともにデータ量に依存します。
事業計画にもとづいてデータ量の変化を仮定し、それに対してストレージとコンピュートの費用の見積を出しました。

また、費用については新旧のデータ基盤の並行稼働のことも考慮する必要があります。
バチッと一瞬で切り替えられるわけではなく、ある程度の期間は2つのデータ基盤を並行して運用することになります。
その間は余分に費用がかかってしまいます。

ステークホルダーへの説明

次に社内のステークホルダーへの説明を行いました。
まずは一次上長であるマネージャにやりたいことと費用見積の詳細について説明します。
Part 1 でも少し触れていますが、マネージャはデータエンジニアリングの知見はあまりなかったため、それなりの説明コストがかかりました。
とはいえちゃんと理解しようとしてくださっていたのでそこは感謝です。

次にデータ基盤に対する社内のデータプロバイダー、コンシューマーについてやりたいことやその影響の説明をしました。
3回ぐらい大きめのミーティングを開催して説明しました。
ここにも準備など含めそれなりの時間がかかっています。

正直、当初はこのステップは本当に必要なのか？と考えていました。
弊社ぐらいの小さい組織であれば、リーダーシップを持った人が責任と権限を持ち、スピード感を持って決めていく方がいいはずです。
ステークホルダーには決まった後に伝えればいいだろうと。
ただ後になってから、これは必要なステップだったと思うに至りました。

承認会議

ここまでやってようやく本丸の承認会議です。
決裁権を持つエライ人の前で説明して承認を得るという会議を開催しました。
結論として、割とすんなりと承認を得ることができました。

「たぶんやった方がいいんだろうけど」、その場でエライ人が言ったこの言葉が象徴的でした。
弊社の場合決裁権を持つマネジメント層にデータまわりに詳しい人がいません。
もちろん費用見積はちゃんと評価されるわけですが、その上で雰囲気で決まっていく感がありました。(JTC)
その雰囲気を醸成するためにステークホルダーへの説明が必要だったわけです。

組織にもよるのでしょうが、データエンジニアをやってるとこのような政治っぽいことを考えることになる場合もあるのだと理解しました。
このあたり前述のマネージャにかなり助けられました。

ここまでの課題と今後の対策

Part 1 とかぶりますが、やはりマネジメント層のデータまわりのリテラシーは組織としての課題です。
外的要因により必要にかられるようなことがない限り、少しずつ啓蒙していくしかないかなと考えています。

Databricks について

Advent Calendar の記事だということもあり Databricks についてもう少し触れておきます。
これを書いている時点では PoC のときよりは Databricks に触っており、その中で体感した良かったところを挙げておきます。
(あくまである一社での例です)

  • OSS ベースであることによる透明性
    • データ処理は Apache Spark 互換のエンジン Photon で実行される
    • ベースは OSS の Spark なので、Spark の知見があれば実行計画を見るなどして処理のイメージがつきやすい
    • 最適化のポイントもわかりやすい (と思っている)
  • 一貫したガバナンス
    • ML model 等の data product も table などの database object と同じように権限管理できる
    • 同じ user でも workspace 単位でアクセス可能なリソースを制限できる
    • PoC の時点でもカタログとしてわかっていたが、触ってみて実感したところがある
  • AI まわり
    • ChatGPT-like にデータについての問い合わせが行える Genie
    • Nootebook でエラーを出したときに原因や修正案を示してくれる
    • LLM の評価や開発の機能
  • 手厚いサポート
    • 弊社に対して担当がついており、Slack で質問に回答していただける
    • A◯S のサポートと比べても回答のスピード・質ともに高い
    • いつもお世話になってます 🙇‍♂️

とはいえまだすべての機能を確認できていないし、そもそも結構なペースで機能が増えています。
個人的には Databricks LakeFlow のあたりに期待しています。

次回予告

次回はまだ未定ですが、何か開発関連の話を書くつもりです。

以上、現場からでした。