データ基盤を Athena _ Glue から Databricks へ移行しました - 第4回 Youは何しにDatabricksへ！？

1. データ基盤を Athena / Glue から Databricks へ移行しました 株式会社スタンバイ 権藤 尚樹 2026.09.29 第4回 Youは何しにDatabricksへ！？ © Stanby, Inc. 1
2. 目次 1. 会社紹介 2. 背景と課題 3. 解決方針と Databricks の選定 4. 移行後のアーキテクチャと効果 5. まとめ © Stanby, Inc. 2
3. 自己紹介 権藤 尚樹 • 2015年：株式会社ビズリーチ中途入社 & スタンバイ事業部配属 • 2019年：株式会社スタンバイへ出向 • 2021年4月：株式会社スタンバイへ転籍 & データエンジニアへジョブチェ ンジ © Stanby, Inc. 3
4. 会社紹介 © Stanby, Inc. 4
5. 会社概要 株式会社スタンバイは、 LINEヤフー株式会社とビジョナル株式会社の合弁事業会社 です。 LINEヤフー Visional Yahoo! JAPANやLINE などを運営する 即戦力人材と企業をつなぐ 転職サイト「ビズリーチ」をはじめさまざ まな事業を提供 Yahoo! JAPANの圧倒的リーチ力と ビズリーチの HR Tech事業ノウハウを活かし 求人検索エンジン事業を運営 社名 株式会社スタンバイ 事業内容 求人検索エンジン「スタンバイ」の運営 住所 東京都渋谷区 設立 2019年11月12日 資本金 1億円 株式保有割合 LINEヤフー60%、ビジョナル 40% © Stanby, Inc. 5
6. 対象組織の概要 - 提供サービス（プロダクト） 求人検索エンジン「 スタンバイ 」 © Stanby, Inc. 6
7. 対象組織の概要 - 提供サービス（プロダクト） 求人検索エンジン「 スタンバイ 」は、Web上に点在するあらゆる求人情報を一括で検索できるサービス です。 求人票 検索 ・雇用形態 ・給与形態 ・掲載開始日 ユーザー (求職者 ) ・こだわり条件 ・自宅や最寄り駅からの距離 ネット上の求人を 一括で検索 応募 ユーザー (求職者 ) クローリング等 求人情報取得 求人メディア © Stanby, Inc. 企業ページ 直接スタンバイに 登録された求人 採用管理システム 7
8. 背景と課題 © Stanby, Inc. 8
9. 移行前のデータ基盤 • ストレージ: S3 • データカタログ: Glue Data Catalog • ETL 処理: Glue Job (PySpark) • 集計処理: Athena • オーケストレーション: Amazon Managed Workflows for Apache Airflow (MWAA) • © Stanby, Inc. BI ツールなど: Redash、Looker Studio 9
10. 課題に対するアプローチを検討 • データエンジニアの主観だけで進めるのは危険 ◦ • 今のデータ基盤はどこが良い／悪いといった診断を行う ◦ • モダンデータスタックで構築したい、といったソリューションが先行するとうまく行かない 改善の前後でどう変わったか？を定量的に測定したい データ基盤は利用者に使ってもらってなんぼのもの ◦ 利用者の声も聞いて認識を合わせながら進めるべき © Stanby, Inc. 10
11. データマネジメント成熟度アセスメントの実施 • DMBOK2 の知識領域をベースに設計 • 合計77項目の質問を5段階で自己評価 • 強み／弱みを可視化し、課題の細分化や優先順位 の決定に利用 © Stanby, Inc. 11
12. データ基盤利用者へのアンケートの実施 • 以下のような質問を選択式の回答とセットで用意 ◦ 主な利用目的は？ ◦ よく利用する周辺ツールは？ ◦ よく利用するデータは？ ◦ 現在のデータ基盤に対する満足度は？ ◦ データ基盤について現在直面している問題は？ • 自由記述形式の質問も用意 • 実施の結果、以下のような要望が多かった ◦ 様々なデータを同じデータ基盤上で扱いたい (複数のデータを統一の SQL で参照したい) ◦ データの関係性がわかりにくい (データリネージュ・メタデータの不足) ◦ KPI の計算式を統一したい (分析者によって SQL の記述方法が異なるため統一したい) ◦ データの欠損が一部あり、分析がしづらい (データ品質の不足) © Stanby, Inc. 12
13. 重点課題の設定 データマネジメント成熟度アセスメントと利用者アンケートの実施から、以下の5つを重点課題に設定 1. 非効率なデータ統合 a. 2. ER 図の欠如 a. 3. 変換の自由度が高すぎて、一部でリネージが追跡できない KPI 計算の不一致 a. 5. テーブル間の関係性が分かりにくく、データ活用の障害に 不完全なデータリネージ a. 4. GA4 や Salesforce 等が基盤に未統合。サイロ化により手作業の結合工数が発生 部署・担当者ごとに計算式が異なり、正しいSQLが分からない データ品質のテスト不足 a. データの不備に長期間気付くことができず、MLモデルへ影響した事例も発生 © Stanby, Inc. 13
14. 解決方針と Databricks の選定 © Stanby, Inc. 14
15. dbt の導入 • ELT アーキテクチャへのシフト ◦ • エコシステムの成熟度とポータビリティ ◦ • 主要 DWH との Adapter が活発に開発され、将来のインフラ変化にも柔軟に対応できる 「品質」と「リネージ」を標準装備 ◦ • 複雑な Glue Job (PySpark) から SQL 中心の ELT へ。学習コストを抑えつつ開発スピードを最大化 dbt test による自動検証、プロジェクト構造から自動生成されるリネージにより追跡可能 ビジネスロジックの一元管理 ◦ dbt Semantic Layer で KPI 計算ロジックを統合し、SSOT（信頼できる唯一の情報源）を構築 © Stanby, Inc. 15
16. DWH に何を採用するか • AWS との親和性が高い DWH ◦ データソースの大半が S3 にあるため • 利用実績が多く、サポートも手厚い DWH • dbt × Athena も検討していたが、当時は公式な adapter ではなくサポート面で不安があった • いくつかの DWH を比較検討し、PoC を開始した © Stanby, Inc. 16
17. PoC での検証項目 • コスト ◦ • データロード ◦ • dbt 連携の安定性、周辺ツールとの接続 ガバナンス ◦ • SQL / Python の記述、デバッグのしやすさ エコシステム ◦ • S3 からのデータロード・外部テーブル参照 開発体験 ◦ • クエリ実行、インスタンス起動の費用 カタログ、権限管理、リネージの自動化 AI / 機械学習 ◦ 生成 AI 連携、ノートブックの AI 補助 © Stanby, Inc. 17
18. Databricks の優位性 • • オープンなデータ管理とポータビリティ ◦ Delta Lake 形式で S3 に保存されており、他の AWS サービスからも利用可能 ◦ ベンダーロックインにならない コストパフォーマンスの良さ ◦ • 3 割ほどコンピューティングコストを抑えられる AI 活用とデータ活用の民主化 ◦ Genie を中心とした AI 機能の充実 ◦ メタデータを整備することで AI が賢くなるという相乗効果 © Stanby, Inc. 18
19. 移行後のアーキテクチャと効果 © Stanby, Inc. 19
20. 移行後のデータ基盤 • ストレージ: S3 • データカタログ: Unity Catalog • ELT 処理: dbt × Databricks SQL • オーケストレーション: Databricks Lakeflow Jobs • © Stanby, Inc. BI ツールなど: Databricks Dashboard 20
21. 重点課題に対するソリューション 1. 非効率なデータ統合 a. 2. ER 図の欠如 a. 3. → dbt によるリネージ機能や Databricks のリネージ機能 KPI 計算の不一致 a. 5. → dbterd や Databricks の Constraints による外部キーの設定 不完全なデータリネージ a. 4. → Databricks のマネージドコネクタの利用 → dbt Semantic Layer や Databricks metric view データ品質のテスト不足 a. → dbt の Data Test や Databricks の Anomaly detection © Stanby, Inc. 21
22. 現場からの声 • Notebook を用いた調査・検証作業が楽になった • データの問題調査がしやすくなった • Genie がクエリやダッシュボードを自分で作ってくれて便利 • テーブル追加等の開発時の学習コストが下がった • リネージ機能で異常発生時の影響範囲が明確になり、復旧が楽になった • ダッシュボードなどの機能が Databricks に集約され、管理の手間が減った © Stanby, Inc. 22
23. まとめ © Stanby, Inc. 23
24. まとめ • 「モダンデータスタックに作り変えたい」という手段から入らず、まず課題を洗い出した • 開発者視点（DMMA）と利用者視点（アンケート）の両方を取り入れた • スコアリングして優先順位を付けたことで、Databricks 選定の PoC も的確に設計できた © Stanby, Inc. 24
25. より詳しい内容 弊社テックブログに掲載していますので、読んでいだけると嬉しいです！ https://techblog.stanby.co.jp/entry/databricks_migration © Stanby, Inc. 25
26. ご清聴ありがとうございました © Stanby, Inc. 26