【登壇資料】データ基盤をTreasureData + Databricksから Databricksへ統一する話

20260409　第3回 Youは何しにDatabricksへ！？

Transcript

1. データ基盤を TreasureData + Databricksから Databricksへ統一する話 yuhei.yoshida / 株式会社エブリー
2. 2 Copyright © 2015 every, Inc. All rights reserved. - 名前: 吉田裕平 - 所属: 株式会社エブリー - 職種: データエンジニア　 - やってること - データ基盤構築 - ETLパイプライン開発 自己紹介 & 会社紹介
3. 3 Copyright © 2015 every, Inc. All rights reserved. エブリーが提供しているプロダクト、ソリューション一覧 エブリーではマルチプロダクトを展開し、あらゆる暮らしの最適化に向き合っています 「インフルエンサーと熱狂を共 創する」SNS・動画のプロ フェッショナルチーム 「熱狂を、仕掛ける。世の中 を、揺さぶる。」 SNS・動画の プロフェッショナルチーム WEB
4. 4 Copyright © 2015 every, Inc. All rights reserved. レシピ動画サービス『デリッシュキッチン』 ▪ 日本最大級のレシピ動画サービス ▪ 「誰でも簡単においしく作れるレシピ動画」毎日配信 ▪ 全レシピ、管理栄養士が監修！蓄積データによるオリジナルレシピを考案 ▪ SNS/APP/WEBを通じて延べ 56,000本以上のレシピ動画を提供 レシピ提案 / レシピ検索 / 献立機能 買い物リスト / チラシ / 店頭ビーコン連動 調理手順動画 /キッチンモード / 作った・レビュー / お気に入り 菅原千遥　 デリッシュキッチン カンパニー長 料理研究家 斎藤 香織 副編集長 管理栄養士 • 30名以上の食のプロが、蓄積 データに基づきオリジナル レシピを日々考案 • 月間1,500本以上の動画配信 サービス・機能 レシピ検討 買い物 料理中・料理後 専門家によるレシピ考案・監修
5. 5 Copyright © 2015 every, Inc. All rights reserved. 今日話すこと 今日する話 - 移行の背景 - 実際の移行内容 - 移行後、どうなったか 想定 - データ基盤を移行しようか悩んでいる方
6. 6 移行の背景
7. 7 Copyright © 2015 every, Inc. All rights reserved. 移行前アーキテクチャ - Databricks - メインのデータ基盤 - S3やBigquery、TDをソースにETL -> BI用にTDに書き込み - TreasureData - 主にDWHとしてBIからのクエリを処理 - 一部の中間テーブルを作成 - 一部のログを直接テーブルに書き込み
8. 8 Copyright © 2015 every, Inc. All rights reserved. 移行前アーキテクチャの課題 1. データフローの複雑化 a. TDで作成した中間テーブルをDatabricksが取り込み、再処理してTDに書き出しなど 2. データの分散 a. TD/Databricksのどちらかにしかないデータが存在 3. TD + Databricksのコスト
9. 9 Copyright © 2015 every, Inc. All rights reserved. なぜDatabricksに統一したか UnityCatalogがすべてを管理する世界にしたい - すべてのデータが Databricksに - UnityCatalogによるデータマネジメント - シンプルなアーキテクチャとコスト体系 - AI連携
10. 10 移行の内容
11. 11 Copyright © 2015 every, Inc. All rights reserved. 移行でやったこと 移行方針を検討し、大きく 3段階で移行 1. すべてのデータを Databricksに集める a. TD Workflow -> Databricks JobsへETL移行 b. TDへの直接ログ投入廃止 c. TD -> Databricksへテーブル移行 2. UnityCatalog化 a. テーブル管理をUnityCatalogへ移行 3. Redashクエリを移行 a. Presto SQL -> Spark SQLの変換
12. 12 Copyright © 2015 every, Inc. All rights reserved. 移行でやったこと 移行方針を検討し、大きく 3段階で移行 1. すべてのデータを Databricksに集める a. TD Workflow -> Databricks JobsへETL移行 => 差分比較はpyspark.testing.assertDataFrameEqualなどを利用 b. TDに直接書き込まれていたログの移行 => 管理部門と連携して新しいログ収集基盤を作成するなど c. TD -> Databricksへテーブル移行 => Databricks上でTD上の全テーブルを取り込むスクリプトを実行 2. UnityCatalog化 a. テーブル管理をUnityCatalogへ移行 3. Redashクエリを移行 a. Presto SQL -> Spark SQLの変換
13. 13 Copyright © 2015 every, Inc. All rights reserved. 移行でやったこと 移行方針を検討し、大きく 3段階で移行 1. すべてのデータを Databricksに集める a. TD Workflow -> Databricks JobsへETL移行 b. TDへの直接ログ投入廃止 c. TD -> Databricksへテーブル移行 2. UnityCatalog化 a. テーブル管理をUnityCatalogへ移行 => 既存のdelta tableはexternal tableとして登録 (CREATE TABLE <catalog.schema.table> LOCATION ‘<s3://path/to/delta>’) b. TD <> Databricksのテーブル対応表を作成 3. Redashクエリを移行 a. Presto SQL -> Spark SQLの変換
14. 14 Copyright © 2015 every, Inc. All rights reserved. 移行でやったこと 移行方針を検討し、大きく 3段階で移行 1. すべてのデータを Databricksに集める a. TD Workflow -> Databricks JobsへETL移行 b. TDへの直接ログ投入廃止 c. TD -> Databricksへテーブル移行 2. UnityCatalog化 a. テーブル管理をUnityCatalogへ移行 3. Redashクエリを移行 a. Presto SQL -> Spark SQLの変換 移行対象クエリを洗い出し => 2000件超 => 手動変換は大変すぎる
15. 15 Copyright © 2015 every, Inc. All rights reserved. 移行における最大の壁 Presto SQL -> Spark SQLのクエリ変換 Presto SQL SELECT TD_TIME_FORMAT(time, 'yyyy-MM', 'JST') AS month FROM td.tbl WHERE TD_TIME_RANGE( time, '2026-01-01', '2026-02-01', 'JST' ) Spark SQL SELECT DATE_FORMAT( FROM_UTC_TIMESTAMP( TIMESTAMP_SECONDS(time), 'JST' ), 'yyyy-MM' ) AS month FROM databricks.unitycatalog.tbl WHERE '2026-01-01' <= date AND date < '2026-02-01' 変換箇所 - 参照するテーブル - TD独自の関数(TD_TIME_RANGE等) - TDのtime partitionからdeltaのpartition columnへ - TDはレコード作成時のunixtimestampにより秒単位で自動パーティションされる - deltaではパフォーマンスが悪化するため、適切なパーティション設計が必要
16. 16 Copyright © 2015 every, Inc. All rights reserved. 突破法 移行用prompt + scriptを用意して Coding Agentで実行した 1. Redashからクエリを取得 2. Presto -> Spark sqlの変換 a. sqlglot.transpile(sql, read=’presto’, write=’spark’)で文法を変換 b. その他はPromptに情報を記載して、Agentで処理 i. TD独自関数はドキュメントへのリンクを記載 ii. time parititonの変換、テーブル参照なども注意事項として記載 3. 変換前後で実行結果を比較する a. 変換後クエリをredashに自動登録 -> 実行して結果を取得 b. 結果を比較して検証 i. pandas.testing.assert_frame_equalを利用 4. 問題なければ既存クエリに上書き / 問題あれば修正 => クエリの担当部門毎に移行をお願いした
17. 17 Copyright © 2015 every, Inc. All rights reserved. 突破法 どうしても差分が発生する - ケース - データの取得方法が変わる - Webのイベントログ - TD-JS-SDKからGA4 - TDの独自関数 - IP Lookup関数など、databricksに存在しないため独自実装した => 最終的にPdMなど意思決定者が誤差を許容するか判断
18. 18 移行後の世界
19. 19 Copyright © 2015 every, Inc. All rights reserved. 移行後のアーキテクチャ Databricksにすべてのデータを集約 - UnityCatalogが管理 - シンプルなデータフロー - Redashからのクエリは Databricks SQL Warehouseで処理 ※Redashは移行のスコープ外とした
20. 20 Copyright © 2015 every, Inc. All rights reserved. パフォーマンス - SQL WarehouseはServerlessの2X-Smallを利用 - 一番小さいやつから様子見: driver -> i3.2xlarge, worker -> i3.2xlarge * 1 - 1 ~ 5台でオートスケールの設定 - ピークタイムは4 ~ 5台、平常で1 ~ 2台ほどで推移 - TDと比較して基本的にはパフォーマンス劣化は感じない - 一部クエリは速度低下 - Sparkに合わせたチューニング - 参照テーブルのオプティマイズ - コールドスタート時に速度低下
21. 21 Copyright © 2015 every, Inc. All rights reserved. - データ基盤全体で見ると安くなった => コストを40%削減 - Databricks単体で見ると - Job Computeは50%増 - Serverless SQLがDatabricks全体のコストの半分を占める - Serverless SQLは高い コスト databricksのコスト推移：USD
22. 22 Copyright © 2015 every, Inc. All rights reserved. UnityCatalog UnityCatalogが非常に便利 - データリネージ - クエリを追っていた作業がリネージグラフで一発に - 全自動でメタデータを収集してくれる - テーブルの利用履歴やリネージ - Databricksの運用記録が保存される systemテーブル - コンピュートリソースのメトリクス - クエリ履歴 - テーブル情報 - など => GenieやAI Agentと組み合わせると強い リネージグラフ
23. 23 Copyright © 2015 every, Inc. All rights reserved. 障害時の影響調査 - テーブルAのデータソースで障害発生 => 影響するテーブルを洗い出してください という依頼 - system.access.table_lineageを活用 - 読み取り/書き込みイベントのレコードが保存 - source -> targetが分かる - クエリ一発で出せる => 以前ならETLのコードを追っていた systemテーブルの活用 クエリ例 SELECT DISTINCT source_table_full_name, target_table_full_name FROM system.access.table_lineage WHERE source_table_name = 'table_a'
24. 24 Copyright © 2015 every, Inc. All rights reserved. 長時間実行されているクエリの調査 - Serverless SQLは起動時間でコスト発生 => 長時間実行されているクエリを探したい - system.query.historyを活用 - sql warehouseで実行されたクエリの履歴 - 実行時間などが分かる - Genieに登録して聞いてみる => 1日の総実行時間に占める割合が大きいクエリtop10を教えて systemテーブル + Genieの活用
25. 25 Copyright © 2015 every, Inc. All rights reserved. その他活用例 - Jobに割り当てるコンピュートリソースを最適化する - system.compute.node_timelineとGenie Research Agent - Databricks Genie Research Agentを利用してJobのコンピュートリソースを最適化する - every Tech Blog - Managed MCPでUnityCatalogのSchemaを取得する - system.information_schema.columnsとDatabricks Managed MCP - Databricks Managed MCP ServerとUnity Catalog Functionでテーブルスキーマを取得する - every Tech Blog - Claude CodeスキルでUnity Catalogのテーブル探索を自動化する - systemテーブルとClaude Code - Claude CodeスキルでUnity Catalogのテーブル探索を自動化する - every Tech Blog
26. 26 今後の展望
27. 27 Copyright © 2015 every, Inc. All rights reserved. UnityCatalogを育てる - 使い始めたばかり - テーブルやカラムにコメントを追加して育てていく AIとの連携 - GenieやAI Agentからデータ利用 - 一部レイヤーのデータ分析を自動化 SQL Warehouseの最適化 - コスト体系が変わったため、クエリ実行の最適化 - 単一クエリの最適化ではなく、Warehouseでみた実行の最適化 今後の展望