Databricksについて.pdf

Transcript

2. 自己紹介 / 本日の背景 プロフィール: 　氏名: 木村 優子 (プラットフォーム部 データ基盤課) 　業務: BigQueryを中心とした社内分析データ基盤の運用・開発 今回の背景 : 　1. DX事業(スポバ・トーク・コボット等 ) のAWSデータ基盤を当課へ移管。 　2. 現状課題 : 仕様変更対応等の「運用工数」が肥大化しており、リソースを圧迫。 　3. 目的: 運用負荷を最小化するため、 Databricks Lakeflowによる刷新を検討。
3. 背景：データ活用における「2つの世界」の分断 これまでのデータ基盤には、大きな「壁」がありました。 1. データレイク（Data Lake）: 　- AI/機械学習エンジニアが使う「ファイル置き場」。安価だが管理が難しい。 2. データウェアハウス（ Data Warehouse）: 　- アナリストが使う「綺麗なデータベース」。管理は楽だが高価で柔軟性がない。 課題: データが分断され、移動やコピーの管理コストが肥大化していた。
4. 解決策：Databricksの「レイクハウス」 「レイク」の柔軟性と「ハウス」の管理機能を統合 Databricksとは？: 　- 世界標準の分散処理「 Apache Spark」の開発者たちが創業。 　- 世界中のデータ先進企業で採用される「データ・インテリジェンス」基盤。 Unity Catalog（ユニティ・カタログ） : 　- データの置き場所は 1つ。AIもBIも、全データを一元管理できる。
5. なぜ我々のチームに合うのか？ 高度なスキルセット不要で、最新技術を導入可能 1. SQL中心の実装 (SQL First): 　- 難しいプログラミング（ Scala/Python）は必須ではない。 　- チーム全員が使い慣れた SQLだけで、 AI基盤レベルの処理が可能。 2. サーバーレス (Serverless): 　- インフラ構築やバージョン管理が不要。 　- 「使った分だけ課金」で、スモールスタートに最適。
6. 直面している課題： 開発スピードへの「追従コスト」 活発な仕様変更（例: スポットバイトル等）への対応が限界 現状の運用（ Human Middleware）: 　- 開発チームの Slackを目視監視し、仕様変更を検知。 　- 変更があれば、手動で RedshiftにDDLを適用（見落とすと停止）。 → 課題: 「Slack張り付き」による認知負荷が高く、本来の業務を圧迫。
7. 解決策：Lakeflow SDP (宣言的パイプライン) 仕様変更に依存しない「疎結合」なパイプラインへ Lakeflow SDPのアプローチ: 　- 複雑な取り込み手順ではなく、「必要なデータ（結果）」のみを SQLで定義。 　- Auto Loaderがファイルを監視し、差分を自動検知。 　- 上流でカラムが増えても、定義外のものは「無視」して稼働継続。
8. PoC検証シナリオ：鉄壁の指定カラム連携 「何でも取り込む」のではなく「決めたものだけ通す」 -- 変更に強い実装: 必要なカラムだけを明示的に指定 CREATE OR REFRESH STREAMING TABLE sales_curated AS SELECT transaction_id, amount, transaction_date -- ここに無い "unknown_col" が元データに追加されても無視される FROM cloud_files("s3://bucket/sales/", "json") 検証ポイント: 　1. 連携元データに「告知なし」で新カラムを追加する。 　2. パイプラインがエラーにならず、定義したカラムだけを正常に取り込み続けるか確認。 　→ 成功すれば、 Slack監視業務からの解放が実現する。 「何でも取り込む」のではなく「決めたものだけ通す」
9. まとめとNext Step Databricks × SQL で「止まらない」基盤へ Databricksの選定理由 : 　- データレイクと DWHを統合し、 SQLだけで運用できるサーバーレス基盤。 Lakeflowによる堅牢化 : 　- 「Slack監視 → 手動DDL」の運用を撤廃し、自動化を実現。 Next Step: 　- 今週より開発環境にて、指定カラムでの耐久テストを開始します。