データエンジニアリングワークショップ：Auto LoaderとSparkで学ぶデータパイプライン構築

本ワークショップでは、Databricksを活用したデータパイプライン構築の基礎から実践までを、ハンズオン形式で学びます。

S3に格納されたデータをAuto Loaderで取り込み、PySparkで加工し、AI/BIで可視化したうえで、Lakeflow Jobsを使って処理を自動化する一連の流れを体験します。

ワークショップ終了後には、Databricksのデータエンジニアリング機能の全体像を理解し、データの取り込みから加工、可視化、自動化までのパイプラインを自身で構築できる状態を目指します。

Transcript

1. データエンジニアリング ワークショップ AutoLoaderとSparkで作る データパイプラインの基礎から実践まで データブリックス・ジャパン株式会社
2. このワークショップについて AutoLoaderとSparkで作るデータパイプライン 主な対象者 • データの取り込みや加工のためのデータパイプラインを構築、 運用するデータエンジニア • PythonやSQLの基本的なコーディング経験があり、これから Databricksを使ってデータパイプラインを構築することにご興味 をお持ちの方 事前準備 • 環境： お客様のDatabricks環境(ワークスペース )を利用。本 ワークショップに参加される方がワークスペースにログインで き、クラスターを作成可能な権限を持っていること • サンプルデータ： サンプルデータ作成用ノートブックを事前に 実行し、参加者にアクセス権を付与 ゴール • Databricksのデータエンジニアリングに関するソリューションの全体像を理解する • S3 のデータを Auto Loader で取り込み、 PySpark で加工、AI/BI で可視化、Lakeflow Jobs で自動化する一連の 流れを自身で実施できるようになる
3. 本ワークショップのアジェンダ データエンジニアリングに関する機能の全体像を理解し、 ハンズオンで取り込み・変換・活用・オーケストレーションの手順を体験 1. データエンジニアリング ソリューションの全体像 2. 環境セットアップ & サンプルデータ確認 3. データの取り込み：Lakeflow Connect / Auto Loader 4. データ加工：PySpark / Spark SQL と Open Table Format 5. 分析・可視化：AI/BI Dashboard 6. オーケストレーション：Lakeflow Jobs 7. Appendix 1 : 管理者向け 事前準備 8. Appendix 1 : GUIから手動でダッシュボードを作成 2 〜 6 はパート毎に 説明 → ハンズオン の流れで進行
4. データエンジニアリング ソリューション全体像
5. • • Unity Catalog に統合：取り込み・加工・可視化・自動化のどの機能においても、読み書きするデータは全て Unity Catalog管理され、 権限管理・リネージ可視化・監査・データ品質管理、等を一元化 Open Table Format ネイティブ：データはOpen Table Format (Delta / Iceberg) で読み書きすることでデータ のロックインを回避し、Unity Catalog がパフォーマンス最適化等の運用を自動化 AIエージェント開発 Agent Bricks データ分析・可視化 Dashboard, Genie Agents Lakehouse Lakebase Serverless Postgres And more… Lakeflow Ingest, ETL, streaming Unity Catalog 統合ガバナンス オープンフォーマット Databricks Apps Genie 自社のデータ・ナレッジを AIが認識 Data warehousing カスタムアプリ開発 Postgres
6. 複雑化・サイロ化を解消するガバナンス Databricks は Unity Catalog で全てのユースケース、アセットを統合 他のデータ基盤 と の連携 データ & AI の 全てのユースケース に対応 ディスカバリー リネージ コスト管理 安全&オープンな データ共有 AIガバナンス 品質モニタリング 従来のデータカタログ アクセス制御 全てのアセット の統合ガバナンス ビジネスセマンティクス テーブル ファイル ドキュメント MCP MLモデル And more… 50… Unity Catalog 統合ガバナンス オープンフォーマット エージェント Postgres
7. データエンジニア ビジネスアナリスト Genie Code + ZeroOps Lakeflow Designer エージェント型データエンジニアリング ノーコードのビジュアルキャンバス Lakeflow 統合されたデータエンジニアリングソ リューションで、データの取り込み、変 換、オーケストレーションを実行 Lakeflow Jobs Connect あらゆるデータソースを 1つのプラットフォームに接続 エンタープライズ SaaS アプリ 統合オーケストレーション Spark Declarative Pipelines バッチとストリーミングに対応する 信頼性の高いデータパイプライン 100以上のコネクタ 自動化されたデータ品質管理 データベース エッジ / テレメトリデータ オペレーショナルデータス トリーミング Zerobus Ingest gRPC + SDKs 変更データキャプチャ (CDC) REST APIs リアルタイムモード
8. 環境セットアップ サンプルデータについて
9. 使用するコンピュート、カタログ、スキーマ 管理者/講師側で準備したデータソースを使い、各自のスキーマに書き出す • コンピュート ：サーバレスコンピュートを使用 (作成作業は不要) • カタログ、スキーマ等 ：下記の表の通り。(必要なものは管理者側で予め作成済み、またはワークショップ中の初期セット アップ用Notebookで自動作成するため、手動で作成するものは無し) オブジェクト 名前（例） 用途 カタログ <ワークショップ用カタログ名> 予め作成済みの1つカタログを全員で共有 参加者用スキーマ <ワークショップ用カタログ名>.dew_<user_name> ワークショップの中で各自が作成する Bronze / Silver / Gold の各テーブルを格納するスキーマ 共有スキーマ de_workshop_shared 管理者側で予め作成済みの共有スキーマ 共有ボリューム（landing） de_workshop_shared.landing 上流から届くファクトデータのParquetファイルが格納される ボリューム。全員がデータ取り込み時に参照。 共有ボリューム（master） de_workshop_shared.master マスターデータのParquetのParquetファイルが格納されるボ リューム。全員が初回セットアップ処理の実行時に参照。
10. サンプルデータセット一覧 架空のキャッシュレス決済サービスのデータを題材に、複数のマスターテーブル、 ファクトテーブルを組み合わせてデータパイプラインを構築 区分 データソース名 内容 元フォーマット マスターテーブル m_customers 会員情報（属性・通信プラン・平均利用 額 等） UC マネージドテーブル ※ 元データが共有スキー マ配下に右記のテーブル 名で格納されている m_merchants 加盟店情報（店名・業種カテゴリ・所在 地） UC マネージドテーブル m_payment_methods 決済手段（QR / クレカ / iD / デビット） UC マネージドテーブル t_payments 決済履歴（主テーブル・不正ラベル付き ・約100万件） Parquet（Volume） t_point_transactions ポイント取引（付与 / 利用 / 失効） Parquet（Volume） t_charges チャージ履歴（残高入金） Parquet（Volume） t_login_events ログイン履歴（乗っ取り検知の補助） Parquet（Volume） ファクト ※ 元データが共有ボ リューム配下に右記のディ レクトリ名で Parquetファイ ルとして格納されている
11. データパイプライン概要図
12. ワークショップ用 Notebookのインポート ① ワークスペース左側のメニュー から “Workspace” を開く ② 右上の方にある 3点リーダーの 様な部分から、 “Import” を開く ③ インポート画面が開くので、 配布されたワークショップ用コードの zipファイ ルをそのままドラッグ &ドロップする
13. ハンズオン準備：初期セットアップ 初期セットアップ用Notebookで自分の作業スキーマとマスターテーブルを作成 作業手順 1. 2. 3. 4. de_workshopフォルダの直下にあるノートブック 05_setup を開く 冒頭セルの最初の変数 user_name を自分の分かりやすい名前に書き換える（例：user_name = "taro"） その下の変数 catalog を管理者から指定されるワークショップ用カタログ名に書き換える（例：catalog = "workshop_catalog"） デフォルトで選択されている Serverless コンピュートを使用し、「すべてを実行」ボタンを押す このノートブックの実行によって作成されるもの • • • 自分専用スキーマ dew_<user_name>（この中に Bronze/Silver/Gold の各テーブルを格納） Auto Loader 用の専用チェックポイントとして使用するVolume 共有 Volume から取り込んだマスターテーブル (3つ) 補足：変数定義はこのノートブックに集約され、後続のBronze/Silver/Gold は %run ./05_setup で再利用する。
14. ワークショップ用 Notebookの変数書き換え ① インポートしたフォルダの中にある 05_setup というノートブックを開く ② 05_setup ノートブックの最初のセルで、 user_name という変数の値を 自身の分かりやすい名前に書き換える
15. データの取り込み
16. Lakeflow Connect 組織のあらゆるデータソースと繋がる SaaSアプリ ファイルソース Zerobus Ingest Direct write for records データベース メッセージバス Direct write for batches データウェアハウス
17. Lakeflow Connect が提供する取り込み方式 標準コネクタ、マネージドコネクタ、Zerobus Ingest Lakeflow Connect は、様々なデータソースの種類や、マネージドvs カスタマイズのバランスに対応するデータ取り込み方式 を提供。Unity Catalog のガバナンスと統合され、取り込みを高速・スケーラブル・低コスト にする。 分類 代表的な機能 特徴 標準コネクタ クラウドストレージから Auto Loader / COPY INTO で取り込み Kafka / Kinesis / Pub/Sub / SFTP / Pulsar 等の メッセージバスからの取り込み Structured Streaming や PySpark と組み合わせて 自在に制御 マネージドコネクタ Salesforce / Workday / ServiceNow / SQL Server(CDC) / GA4 等のデータソース毎の専用 コ ネクタ群 認証・CDC・スキーマ進化・リトライまで自動化 Zerobus Ingest アプリ / デバイスからの直接取り込み イベントを push 型で受け取る取り込み経路 本ワークショップでは 標準コネクタを使い、 AutoLoaderでクラウドストレージのファイルを取り込む
18. (参考) Lakeflow Connect：マネージドコネクタ SaaS やデータベースを対象に、専用コネクタを使って簡単にデータ取り込み ポイント & クリック Unity Catalog のガバナンス 工数の大幅削減
19. (参考) Zerobus Ingest が無い場合 Kafka や Kinesis、 EventHub 等のメッセージバスが必要だった Producers Message Bus Spark Lakehouse Cloud Apps Delta Lake Edge Apps Parquet Iceberg IoT Devices
20. (参考) Zerobus Ingest による直接取り込み 新しいデータソースとの接続や運用をもっと迅速に Producers Zerobus Ingest Cloud Apps Edge Apps Delta Lake Parquet Iceberg IoT Devices High throughput Low-latency Low TCO テーブルを作成 → プッシュするだけ
21. Auto Loader とは？ 新規ファイルを増分として自動検出し、重複なく取り込む • クラウドストレージ上に到着する新規ファイルを増分・自動検出して取り込む • チェックポイントにより、再実行しても取り込み済みファイルを重複処理しない（Exactly-once） • スキーマ推論・スキーマ進化に対応（想定外の列は _rescued_data に退避） • バッチとストリーミングの両方に使用可能
22. Auto Loader のファイル検出モード Auto Loader は新規ファイルの検知、取り込みステータス管理どう行うか モード 事前セットアップの手間 スケーラビリティ 仕組み 注意・備考 ディレクトリ リスティング モー ド 不要 低い (ディレクトリサイズによって 制限される) ロードパスを毎回スキャンして新 規ファイルを検出（通知なし） 小規模向け。ファイル数が増え るとスキャンが高コスト・低速化 ファイル通知モード (従来方式 ) 多数の設定が必要（21以上 のクラウド構成オプション） 1時間あたり数百万のファイル ストリーム自身が SNS/SQS を 自動セットアップしキューを直接 読む（ストリーム毎に専用 キュー） キューが乱立し、通知数上限 に当たりやすい ファイル通知モード (ファイルイベント方式 ) ※ 本番環境での推奨 少ない設定で済む（1回限り のアクセス許可の設定） 1時間あたり数百万のファイル UC External Location で通知 を有効化、Databricks がメタ データをキャッシュ（1 バケット 1 キュー共有） 乱立と通知数上限のヒットを回 避でき、スケール、コスト効率 が高い 本番運用では ファイル通知モード (ファイルイベント方式 ) が推奨だが、 本ワークショップでは環境セットアップを最小限にするためディレクトリリスティングモード を使用
23. 各ファイル検出モードの動作イメージ ディレクトリ一覧・ファイル通知・ファイルイベントの 3のモードが存在 ディレクトリ一覧：https://docs.databricks.com/aws/ja/ingestion/cloud-object-storage/auto-loader/directory-listing-mode ファイル通知 (従来方式 / ファイルイベント方式)：https://docs.databricks.com/aws/ja/ingestion/cloud-object-storage/auto-loader/file-notification-mode
24. ハンズオン： Auto Loader で増分取り込み データ取り込み処理のコードを 2 回実行し、 2 回目は増分だけが取り込まれていることを確認する ハンズオンの流れ： ノートブック 10_bronze_autoloader に沿って実施 1. 取り込み処理 1 回目：取り込みセルを実行 → bronze_t_payments テーブルのレコード件数を確認 2. 管理者が新しいデータファイル (Parquet) を共有 Volume に追加 3. 取り込み処理 2 回目：同じセルをもう一度実行（コードは変えない）→ 増分だけが取り込まれることを確認 def ingest_fact(table): (spark.readStream.format("cloudFiles") # Auto Loader .option("cloudFiles.format", "parquet") .option("cloudFiles.schemaLocation", f"{checkpoint_base}/{table}/") .option("cloudFiles.schemaEvolutionMode", "addNewColumns") .load(f"{shared_landing}/{table}/") .withColumn("_ingested_at", # 取り込み時刻（東京 TZ） F.from_utc_timestamp(F.current_timestamp(), "Asia/Tokyo")) .writeStream .clusterBy("customer_id") # Bronze にも Liquid Clustering .trigger(availableNow=True) # 到着分を処理して停止 .toTable(f"{bp}.bronze_{table}").awaitTermination())
25. Auto Loader のベストプラクティス (1/2) • • • スキーマ進化の管理 ：スキーマ (列の構成とそれぞれのデータ型) の想定される変化に応じて、スキーマ 進化モードを適切に選択する。 ◦ Auto Loaderを実装するコードで、オプション schemaEvolutionMode : <使用するスキーマ進 化モード> で指定可能。 ◦ 使用するスキーマ進化モードとして指定するモードは、例えばスキーマが常に固定なら .schema() で明示的にスキーマ構成を指定、列の追加が想定されるなら addNewColumns 、型拡張が想定 されるなら addNewColumnsWithTypeWidening 、・・・等 不良データとデータ品質の処理 ◦ スキーマ不一致は _rescued_data、解析不能な行は _corrupt_record （columnNameOfCorruptRecord で有効化） ◦ 不正データを下流に伝播させる前に「検出・捕捉・隔離」 _metadata 列を使って、少なくとも file_path、file_modification_time 列をレコードに付与 する
26. Auto Loader のベストプラクティス (2/2) • • • コストとパフォーマンスの最適化 ◦ ファイルイベントで LIST API を最小化（毎回のフルディレクトリ探索を回避） ◦ ファイル到着トリガーで新規到着時のみ起動 → アイドル料金ゼロ チェックポイント管理 ◦ チェックポイントはストリーム進捗とファイル状態を保持する重要な情報であるため、チェックポイント を保持するクラウドストレージパスにはライフサイクルポリシーを適用しない（チェックポイントが意図 せず削除され、ファイル状態等の情報が失われるため） ◦ ストリーム／ソースディレクトリごとに個別のチェックポイントを使用 ファイル通知モード (ファイルイベント方式) を使用する場合、性能向上のためロード対象のパスとして外 部ボリュームを使用 する。クラウドパス（例 s3://bucket/path）ではなくボリュームパス（例 /Volumes/catalog/schema/volume）で指定。 詳細は以下を参照 https://docs.databricks.com/aws/ja/ingestion/cloud-object-storage/auto-loader/best-practices
27. Auto Loader の詳細ドキュメント 実装手順や各設定の詳細、ベストプラクティス、サンプル実装等 • ファイル通知モードでの実装手順 ◦ • ベストプラクティス集 ◦ • https://docs.databricks.com/aws/ja/ingestion/cloud-object-storage/auto-loader/observability 様々な実装例 ◦ • https://docs.databricks.com/aws/ja/ingestion/cloud-object-storage/auto-loader/production Auto Loader によるファイルの取り込み状態や様々メトリクスのモニタリング ◦ • https://docs.databricks.com/aws/ja/ingestion/cloud-object-storage/auto-loader/best-practices 本番運用時の考慮 / 推奨事項 ◦ • https://docs.databricks.com/aws/ja/ingestion/cloud-object-storage/auto-loader/file-notification-mode https://docs.databricks.com/aws/ja/ingestion/cloud-object-storage/auto-loader/patterns よくある質問 ◦ https://docs.databricks.com/aws/ja/ingestion/cloud-object-storage/auto-loader/faq
28. データの加工
29. Databricks での主なデータ加工の手段 Python, SQL, Scalaであれば基本的には何でも使用可能 Lakeflow Spark Declarative Pipelines Lakeflow Designer PySpark SQL Python (Pandas, etc.) 宣言型でデータ加工の複 雑な実装を容易に 生成AIを活用した新たな ノーコードETLツール 豊富な実績と高い移植 性、実装の柔軟性 SQLさえ書ければ 大規模分散処理ができる 使い慣れた任意の ライブラリを使用 OSS Databricks固有 OSS or 汎用言語 大規模なデータ処理に対応 コード ノーコード 運用負荷 小 新規構築での 第一選択肢 小規模データのみ コードを扱えない ユーザーが簡易な 処理を作るのに最適 コード 運用負荷 中 既存のPySpark 処理を移行する場合 既存のSQL処理を 移行する場合 運用負荷 大 扱うデータが 小さい場合のみ
30. (参考) Spark Declarative Pipelines とは？ ETL のためのモダンソフトウェアエンジニアリング 信頼性の高いデータパイプライン を、シンプルな宣言型アプローチ で構築可能なETLフレームワーク。 大規模なインフラを自動的に管理 するため、データアナリストやエンジニアはツールの操作に費やす時 間を削減し、データから価値を引き出すことに集中できる。 ETLの開発を加速 インフラを 自動管理 データの品質に 自信を持つ https://www.databricks.com/product/data-engineering/spark-declarative-pipelines バッチも ストリーミングも シンプルに実現
31. (参考) Spark Declarative Pipelines Lakeflowを使ったデータエンジニアリング専用の”IDE” 複数ファイルのタブ切替 パイプラインの設定 & 実行 テーブルの自動可視化 効率的な開発 /デバッグ のための部分的実行 コードファイルの管理 テーブルのプレビュー パフォーマンス /メトリクス エラー調査
32. (参考) Lakeflow Designer ガバナンスを維持したまま、本番品質のETLを “AI & ノーコード”で構築
33. Databricks での主なデータ加工の手段 Python, SQL, Scalaであれば基本的には何でも使用可能 Lakeflow Spark Declarative Pipelines Lakeflow Designer PySpark SQL Python (Pandas, etc.) 宣言型でデータ加工の複 雑な実装を容易に 生成AIを活用した新たな ノーコードETLツール 豊富な実績と高い移植 性、実装の柔軟性 SQLさえ書ければ 大規模分散処理ができる 使い慣れた任意の ライブラリを使用 OSS Databricks固有 OSS or 汎用言語 本ワークショップでは 小規模データのみ PySpark を使って実装 大規模なデータ処理に対応 コード ノーコード 開発工数・運用負荷 小 新規構築での 第一選択肢 コードを扱えない ユーザーが簡易な 処理を作るのに最適 コード 開発工数・運用負荷 中 既存のPySpark 処理を移行する場合 既存のSQL処理を 移行する場合 開発・運用負荷 大 扱うデータが 小さい場合のみ
34. UC マネージドテーブル の活用 UC マネージドテーブルにすると、運用力・信頼性・ガバナンスでメリット データ取り込みによっと作成するブロンズ層はもちろん、データ加工で作成するシルバー層もゴールド層のテー ブルもすべて Unity Catalog のマネージドテーブル (Open Table Forma) として書き出す ことで、素の Parquetファイルには無い様々なメリットがある。 観点 素の Parquet ファイル UC マネージドテーブル (Open Table Format) トランザクション なし（部分書き込み・競合リスク） ACID トランザクションで一貫性を保証 更新・削除 実質不可（洗い替え） MERGE / UPDATE / DELETE が可能 履歴・復旧 なし Time Travel で過去バージョン参照・ロール バック 性能最適化 手動 Liquid Clustering / Predictive Optimization ガバナンス ファイル権限止まり UC で権限・リネージ・監査を一元管理 Databricks におけるデータの読み書きではこちらを使用
35. パフォーマンス向上と自動メンテナンス Liquid ClusteringとPredictive Optimizationにより、 Iceberg / Delta Lakeのパフォーマンスを最大化
36. Liquid Clustering パーティション設計に悩まず、キーの変更もデータ再書き込みなしに できる次世代のパフォーマンス最適化技術 • 従来のパーティショニングや Z-Ordering を置き換える、テーブルのデータ配置最適化機能 • クラスタリングキーをいつでも変更可能。過去データを書き直す必要がない • 高カーディナリティ列や偏りのあるデータでも効果的にスキップを効かせる • 自動・増分でクラスタリングが進み、パーティションの過剰分割（small files）を避けられる • 有効化は CLUSTER BY <列名>（列指定）または CLUSTER BY AUTO（自動でキーを選択） 新規テーブル作成時に適用 既存テーブルに後から適用 対象列を指定 CREATE TABLE table2 CLUSTER BY (col0) AS SELECT * FROM table1; ALTER TABLE <table_name> CLUSTER BY (<clustering_columns>) 対象列を自動選択 CREATE TABLE table2 CLUSTER BY AUTO AS SELECT * FROM table1; ALTER TABLE <table_name> CLUSTER BY AUTO
37. Predictive Optimization OPTIMIZE や VACUUM などのメンテナンスを自動実行 • UC マネージドテーブルに対し、最適化処理（OPTIMIZE、VACUUM、ANALYZE）を自動で実行 • 利用パターンを学習し、必要なテーブルに必要なタイミングでメンテナンスを適用 • 無駄な最適化を避けるため、コスト効率も高い • Liquid Clustering と組み合わせ、パフォーマンス最適化とメンテナンスの両方が自動化される アカウント全体で一括有効化 / 無効化 (デフォルトを決める ) カタログ、スキーマ、テーブル単位で個別に有効化 / 無効化 -- カタログ単位で有効化 ALTER CATALOG <catalog_name> ENABLE PREDICTIVE OPTIMIZATION; -- スキーマ単位で無効化 ALTER SCHEMA <schema_name> DISABLE PREDICTIVE OPTIMIZATION; -- テーブル単位で有効化 ALTER TABLE <table_name> ENABLE PREDICTIVE OPTIMIZATION;
38. ハンズオン：シルバーレイヤーの加工 各ファクトを別々の DataFrame に読んでから結合し、 PK/FK と Liquid Clustering 付きで保存する ハンズオンのポイント： 詳細はノートブック 20_silver_cleanse_and_join に沿って実施 • 作成テーブル：silver_payments / silver_point_transactions / silver_charges / silver_login_events • 結合キーとなる customer_id には Liquid Clustering を適用 • PKやFKのテーブル制約も付与 payments_df = spark.table(f"{bp}.bronze_t_payments").dropDuplicates(["payment_id"]) \ .filter(F.col("status").isin("完了","返金")) # 有効な決済のみ customers_df = spark.table(f"{bp}.bronze_m_customers").select(...) # 会員マスター # ...加盟店・決済手段も同様に別 DataFrame へ silver_payments = (payments_df .join(customers_df, "customer_id", "left") # マスター結合 .join(merchants_df, "merchant_id", "left") .join(methods_df, "method_id", "left") .withColumn("payment_date", F.to_date("payment_timestamp"))) # 派生列 silver_payments.write.clusterBy("customer_id").saveAsTable(f"{bp}.silver_payments") # 続いて PK(payment_id) と FK(customer_id/merchant_id/method_id → マスター) を付与
39. ハンズオン：ゴールドレイヤーの加工 顧客別・加盟店別・決済手段別・日次の集計を作成 ハンズオンのポイント： 詳細はノートブック 30_gold_aggregations に沿って実施 • SQL で作成 (Notebookで多言語を使い分けられることを体験 ) • 以下の表の通り結合やフィルタで使用する列に Liquid Clustering を適用しながら各テーブルを作成 テーブル Liquid Clustering 理由 gold_customer_summary customer_id 顧客の絞り込み・結合キー gold_merchant_summary merchant_id 加盟店の絞り込み・結合キー gold_payment_method_summary method_type ダッシュボードのフィルタ列 gold_daily_payment_trend payment_date 時系列フィルタ列 # 顧客別集計（PySpark） gold_customer_summary = spark.table(f"{bp}.silver_payments").groupBy("customer_id").agg( F.count("*").alias("payment_count"), F.sum("amount").alias("total_amount"), F.round(F.avg(F.col("is_fraud").cast("int"))*100, 2).alias("fraud_rate_pct")) gold_customer_summary.write.clusterBy("customer_id").saveAsTable(f"{bp}.gold_customer_summary") # 日次トレンド（Spark SQL） spark.sql(f"""CREATE OR REPLACE TABLE {bp}.gold_daily_payment_trend CLUSTER BY (payment_date) AS SELECT payment_date, method_type, COUNT(*) payment_count, SUM(amount) total_amount FROM {bp}.silver_payments GROUP BY payment_date, method_type""")
40. 可視化・分析
41. 「レガシー」 BIの一般的なアーキテクチャ BIプラットフォーム BIダッシュボード BIガバナンス データのサブセット AIの知識 範囲が限定的 データとガバナンスポリシーのコピー 管理すべきシステムが複数存在。 データセット、セマ ンティクス、ガバナンスモデルの同期を維持することが 困難。追加のBIライセンスの購入 が必要。 パフォーマンスとスケールのどちらかを選択する 必要がある。 BIツール側へデータをコピー/重複保 持する問題か、ダイレクトクエリのレイテンシの問 題のどちらかに直面。 Databricksプラットフォーム データエンジ ニアリング データウェア ハウス Unity Catalog あなたのすべてのデータ AIとML AIアシスタントのインテリジェンスは限定的。 特定のダッシュボードやセマンティックモデルの知識 しか持っていない。
42. データ、セマンティクス、ガバナンスを 一元管理 スタンドアローンの BI 統合された BI Databricksプラットフォーム データエンジニ アリング データウェアハ ウス BIプラットフォーム Databricksプラットフォーム AI/BIダッシュボード & Genie AIとML データエンジニ アリング データウェア ハウス AIとML セマンティッ クモデル Unity Catalog データ ガバナンス BIダッシュボード & AIボット セマンティックモデル セマンティッ ク モデル Unity Catalog データ ガバナンス データガバナンス あなたのデータのサブセット あなたのすべてのデータ あなたのすべてのデータ ✔ ✔ ✔ ✖ ✖ ✖ データを 一元管理 セマンティクス を一元管理 データガバナンス を一元管理 データを複数の 場所で管理 セマンティクスを 複数場所で管理 データガバナンスを 複数の場所で管理
43. すべてのデータに対する インタラクティブなパフォーマンス 超高速インタラクティブ性 高パフォーマンスなクエリ 全体的なTCOの削減 クライアントサイド実行によるドリルダウンとフィル タリングのための 抽出データだけでなく、最新のすべての データに対して パフォーマンスを向上させ、ラウンド トリップを削減し、全体的な TCOを低減するため の共有キャッシュ
44. ハンズオン：ダッシュボードの作成画面を開く 1. 左メインメニューの「ダッシュボード」を開く 2. 右上の「ダッシュボードを作成」ボタンを押す
45. ここからのダッシュボードの作成方法について シンプルなGUIから手動で作成 or Genie Codeに指示して自動作成 シンプルな GUIで作成 → GUIでの作成手順は Appendixで解説 Genie Codeに指示して自動作成 → 本ワークショップでは Genie Codeを使用
46. ハンズオン： Genie Code へ指示 ダッシュボードで可視化したい内容をプロンプトで指示するだけ 右記のプロンプトを <ワークショップで使用しているカタロ グ名>.<自身のスキーマ名 > の部分のみ書き換えてから 、 Genie Codeに貼り付け。 ※ 結果として作成されるダッシュボードの細かな設定や見 た目は、参加者によって異なる場合があります。 次の Gold テーブル群をデータソースとして、決済分析ダッシュボードを作成してください。 すべて <ワークショップで使用しているカタログ名 >.<自身のスキーマ名 > スキーマ配下にあります。 # 使用するデータソース - gold_customer_summary：顧客別の決済集計・不正率 - gold_merchant_summary：加盟店別の決済集計・不正率 - gold_payment_method_summary：決済手段別の集計・不正率 - gold_daily_payment_trend：日次×決済手段の決済推移 # ダッシュボード全体 - タイトル：「決済分析ダッシュボード」 - 上部にフィルタ（日付範囲、決済手段、加盟店業種）を配置し、全ウィジェットに適用 - 通貨は日本円（ ¥）、金額はカンマ区切り、不正率はパーセント表示 # 1段目：サマリ KPI 3つのカウンターを用意し、それぞれ以下の指標を表示。 - 総決済金額 - 総決済件数 - 平均不正率 # 2段目：折れ線グラフ「日次決済金額の推移」 - ソース： gold_daily_payment_trend - X軸：payment_date（日次）、 Y軸：決済金額の合計 - 系列：決済手段（ method_type）で色分け # 3段目：横棒グラフ「決済手段別の決済件数」 - ソース： gold_daily_payment_trend - X軸：method_type、Y軸：SUM(total_amount) # 4段目：テーブル「加盟店別 集計値」 - ソース： gold_merchant_summary - 列：加盟店名、加盟店カテゴリ、合計決済件数、合計決済金額、不正率 - 不正率の降順で表示 各ウィジェットには日本語のタイトルを付け、 Gold テーブルの既存カラムを使って集計してください。 存在しないカラムは作らず、実際のスキーマに合わせてマッピングしてください。
47. ハンズオン：ダッシュボードの公開 権限を持つユーザーがダッシュボードへアクセスできる状態にする • 「公開」ボタンで、作成したダッシュボードを閲覧可能な状態にする ◦ • 「共有」設定で許可されているユーザーだけが、公開されたダッシュボードにアクセスできる 他のユーザーがダッシュボードを閲覧する時、ダッシュボード作成者の権限 or 閲覧者の権限 どちらでデータにアクセスするのかも設 定可能。本ワークショップでは「共有データに対する権限」を選択してダッシュボード作成者の権限を使用。
48. オーケストレーション
49. Lakeflow Jobs 様々の種類の処理を簡単に組み合わせ、本番ジョブとしてオーケストレーション Triggers • データ鮮度を最適に保つ、様々な トリガー設定 • 条件分岐や繰り返しを含む複雑な 処理にも対応可能な制御フロー Scheduled ジョブの実行状況、コストやパ フォーマンスの監視、分析が可能 な可観測性 Continuous • • • サーバーレス / クラシックのコン ピュートでコスパも運用負荷も調 整可能 データ加工からモデル学習、ダッ シュボード更新、3rdパーティツー ルも含む様々な処理を簡単に統 合 Control Flow Observability ETL ML/AI File arrival Table update Serverless Analytics/BI
50. シンプルなジョブの作成と管理 データ取り込み・加工処理のコードを実装するのと同じ場所で 本番ジョブの作成までシームレスに行える 様々なタスクタイプを 数クリックで組み合わせ、 本番運用可能なジョブを構成 Databricks Automation BundlesやREST API、CLI等、環境に合うツールで ジョブの作成や管理を CI/CDに組み込み
51. リアルタイムなモニタリング ジョブの実行状況を直感的に把握可能なUIで、即座にアクションを取りやすく シンプルで直感的な監視 UIが、 ワークフロー実行ごとのリアルタイムな メトリクスと詳細な分析を提供 どのタスクがなぜ失敗しているのかを 把握し、顧客に影響が出る前に問題を トラブルシューティング可能
52. コストやパフォーマンスの分析 実行ステータス、コスト、パフォーマンスに関する様々なログを すぐに分析可能なテーブルとして提供し、可視化の仕組みもセット 製品、ワークスペース、ジョブ、ノートブック、 ユーザーごとにコストを追跡可能 ジョブ実行の健全性、失敗、 ランタイムメトリクス、リソース使用率等を追跡可能
53. Lakeflow Jobs のタスクタイプや制御フロー タスクを選択し、制御フローを作成し、Jobsのデータトリガーを定義する ジョブは 1 つ以上の タスクをまとめて管 理可能 タスク間に柔軟な制 御フローを構築可 能 ジョブは柔軟なトリ ガー設定をサポート Spark Databricks SQL Files/ Declarative Notebooks Queries Pipelines Sequential Scheduled (Cron) Python Scripts Parallel API Trigger Python Wheels AI/BI Dashboards Conditionals (If/else) File Arrival Triggers Table Triggers Spark Submit dbt Run Job (Modular) Continuous (Streaming) Java JAR file Power BI For each Manual Trigger
54. ハンズオン：ジョブの新規作成画面を開く データ取り込み、加工、ダッシュボード更新を一連のジョブとして構成 1. 左側のメインメニューから「ジョブとパイプライン」を開く 2. 「ジョブ」ボタンからジョブの新規作成画面を開く 3. 「＋別のタスクタイプを追加」ボタンを押し、どんなタスクタイプが用意 されているのかをスクロールしながら観察 4. 「ノートブック」を選択する
55. ハンズオン：データ取り込みのタスクを作成 1. 2. ノートブックタスクの設定画面で、最低限以下の項目のみ設定。他に もどんな内容が設定できるか観察。 a. タスク名：ingest b. 種類：ノートブック（デフォルト） c. ソース：ワークスペース（デフォルト） d. パス：自身の 10_bronze_autoloader ノートブックを指定 e. コンピュート：サーバーレス 「タスクを作成」ボタンでタスクを保存
56. ハンズオン：データ加工のタスクを作成 1. 「＋タスクを追加」ボタンから新しいタスクの設定画面を開いて2つ目、3つ目のタスクを続けて作成する。以下の設定項目 以外は、1つ目に作成してタスクと同じ設定を入れる。 a. タスク名：2つ目のタスクは transform_silver 、3つ目のタスクは transform_gold と設定 b. パス：2つ目のタスクは 20_silver_cleanse_and_join 、3つ目のタスクは 30_gold_aggregations を選択 c. 依存先：2つ目のタスクは ingest 、3つ目のタスクは transform_silver を選択
57. ハンズオン：ダッシュボード更新のタスク 1. 「＋タスクを追加」ボタンから新しいタスクの設定画面を開い て4つ目のタスクを作成する。 a. タスク名：refresh_dashboard b. タイプ：ダッシュボード c. ダッシュボード：自身で作成したダッシュボード名 d. SQLウェアハウス：講師/管理者から指定 e. 依存先：transform_gold
58. ハンズオン：ジョブの起動トリガーを設定 定期実行だけでなく、新規ファイル到着や上流テーブル更新も設定可能 1. 右側の設定メニューの「スケジュールとトリガー」から「トリガーを追加」を開く 2. トリガータイプとして選択できるものを見ながら、各トリガータイプで設定できる内容を UIから観察 3. 本ワークショップでは「なし（手動）」のままにしておく
59. ハンズオン：ジョブ通知の設定 ジョブの失敗や長時間化等をSlack, Teams, メール等でリアルタイムに通知 1. 右側の設定メニューの「ジョブ通知」から「通知を編集」を開く 2. 「＋通知を追加」ボタンを押す 3. 配信先を設定し、通知を出したいイベント種類を選択する(本ワークショップでは自身のメールアドレスを設定)
60. ハンズオン：ジョブ名を変更し、実行する 1. ジョブ画面左上のジョブ名を、分かりやすい名前に変更（例：決済データパイプライン _<自身の名前>） 2. 「今すぐ実行」ボタンでジョブを手動実行する
61. ハンズオン：単一ジョブのモニタリング (1/2) 個別のジョブの実行状況を詳細にドリルダウン 1. 「ジョブの実行」タブを開くと、ジョブの実行履歴・ステータスを確認可能 2. 個々の実行の詳細を確認するには、「開始時刻」列のリンクをクリックする
62. ハンズオン：単一ジョブのモニタリング (2/2) 個別のジョブの実行状況を詳細にドリルダウン 3. 「グラフ」「タイムライン」「リスト」でタスク別の成否や実行時間等の詳細にドリルダウン可能 グラフ リスト タイムライン
63. (補足) 多数のジョブの俯瞰的なモニタリング 複数のジョブをまたぐ問題の特定、コスパの改善が必要なジョブの特定等 全てのジョブの状況を横断的に UIで確認 左側メインメニューの「 ジョブの実行 」を開く システムテーブルで分析・可視化 主にシステムテーブルの system.lakeflow スキーマ配下の テーブル、コスト情報も含める場合は system.billing ス キーマのテーブルも組み合わせることで SQLによる任意の分析 ができ、フルカスタマイズのダッシュボードも作成可能 https://docs.databricks.com/aws/ja/admin/system-tables/jobs-cost https://docs.databricks.com/aws/ja/jobs/monitor
64. 本番運用時のベストプラクティス & 注意点 クラスタ再利用・リトライ・イベント駆動・IaC 管理 • ジョブを実行するコンピュートタイプは、まずはVMの考慮が不要かつ起動も高速なサーバーレスで検討。何 らかの制約等でサーバーレスが使えない場合、クラシックジョブコンピュートを使用。 ◦ 汎用コンピュート (ノートブックでの対話実行用) をジョブで使用することコストが割高となるため、使用 しない。 • リトライ / タイムアウト 設定を入れてジョブの頑健性を高める • ファイル到着 / テーブル更新トリガーによるイベント駆動でコスト効率を高める • 環境分離（dev / prod）と Declarative Automation Bundles（DABs）による IaC 管理で運用を自動化する • システムテーブルによる実行監視・コスト分析で要改善なジョブやタスクを常に把握できるようにする。
67. Appendix 1 : 管理者向け 事前準備
68. STEP 0：事前チェック 1. 参加者全員のアカウント（メールアドレス）が対象ワークスペースに追加済みか確認 2. 参加者を1つのグループ（例：<参加者用グループ>）にまとめておく（個別付与を避けるため推奨） 3. 対象ワークスペースにサーバレス、または汎用クラスタ／SQLウェアハウスが起動できることを確認
69. STEP 1：SQLウェアハウスの準備 1. Serverless SQLウェアハウスを1台作成（参加者全員で共用） a. SQL → SQLウェアハウス → 作成 → タイプ：Serverless b. サイズは参加者数に応じて選択（目安：〜10名で 2X-Small〜Small、Auto-stop を有効化） c. 参加者グループに「使用可能（CAN USE）」権限を付与 d. 作成したウェアハウスの権限設定 → <参加者用グループ> グループに Can use を付与 これによりダッシュボード・Genie・Spark SQL 実行を全員が同一ウェアハウスで共用できる ※ 本ワークショップではサーバーレスコンピュートを使用するため、参加者個別のコンピュート準備は不要。
70. STEP 2：カタログの準備 1. ワークショップで使用する共有カタログを新規作成（既存なら省略） CREATE CATALOG IF NOT EXISTS <ワークショップ用カタログ名>; ※ 参加者ごとのスキーマ（dew_<ユーザー名>）と共有データ用 Volume 等は、STEP 3 の初期セットアップノートブック内で自 動作成されるため手動作成は不要。
71. STEP 3： 初期データの生成 1. 2. 3. 4. ノートブック一式の中から、管理者用フォルダadmin 配下の 00_setup_and_generate_initial_data を開く 冒頭のパラメータを確認・設定 a. catalog = <ワークショップ用カタログ名 > ノートブックを上から順に全セル実行。ノートブック内では主に以下の処理が実行される。 a. 共有スキーマ・共有データ用 Volume を作成 b. マスタ（m_customers / m_merchants / m_payment_methods）をマネージドテーブルとして作成 c. ファクト（t_payments / t_point_transactions / t_charges / t_login_events）を Parquet として共有Volumeに 出力 実行後、テーブルとファイルが生成されたことを確認
72. STEP 4：参加者への権限付与 1. 参加者がマスタと共有ソースファイルを直接READでき、かつ自分のスキーマを作成できるよう権限を付与します（グループ 推奨）。STEP 3 でオブジェクトが作成された後に実行します。 -- カタログ／スキーマの利用権限 GRANT USE CATALOG ON CATALOG <ワークショップカタログ名 > TO <参加者用グループ >; GRANT USE SCHEMA ON SCHEMA <ワークショップカタログ名 >.shared TO <参加者用グループ >; -- 各参加者が自分のスキーマ（ dew_<user_name>）を作成できるように GRANT CREATE SCHEMA ON CATALOG <ワークショップカタログ名 > TO <参加者用グループ >; -- マスタテーブルの参照 GRANT SELECT ON TABLE <ワークショップカタログ名 >.shared.m_customers TO <参加者用グループ >; GRANT SELECT ON TABLE <ワークショップカタログ名 >.shared.m_merchants TO <参加者用グループ >; GRANT SELECT ON TABLE <ワークショップカタログ名 >.shared.m_payment_methods TO <参加者用グループ >; -- 共有Volume（ソースParquet）の参照 GRANT READ VOLUME ON VOLUME <ワークショップカタログ名 >.shared.source_files TO <参加者用グループ >; ※ グループ名（<参加者用グループ>）とカタログ名 (<ワークショップカタログ名>)は環境に合わせて置き換え。
73. STEP 5：増分データ投入の準備 1. ノートブック一式の中から、管理者用フォルダadmin 配下の 01_generate_incremental_data を開いておく 2. 「パラメータ設定」すぐ下のセルで、catalog = "<ワークショップカタログ名>" に書き換え、正常実行できることを確 認しておく。 ワークショップ当日、 Auto Loader によるデータ取り込みのハンズオン中に管理者がこのノートブックを実行する必要がある
74. STEP 5：ノートブックと資料の事前配布 1. ワークショップ用のノートブック一式＋説明資料(本資料) は管理者から全参加者へ予め配布しておく。
75. Appendix 2 : GUIから手動でダッシュボードを作成
76. ハンズオン：ダッシュボードの作成画面を開く 1. 左メインメニューの「ダッシュボード」を開く 2. 右上の「ダッシュボードを作成」ボタンを押す
77. ここからのダッシュボードの作成方法 シンプルなGUIから手動で作成 or Genie Codeに指示して自動作成 シンプルな GUIで作成 → 本Appendixで解説 Genie Codeに指示して自動作成 → ワークショップ本編で実施
78. ハンズオン：データセットの定義 ダッシュボードで使用するデータセットを定義 1. ダッシュボードのタイトルを「決済モニタリング _<user_name>」のような名称に変更 2. 「データ」タブを開き、「＋データを追加」を押して自身のスキーマ dew_<user_name> 配下にある以下テーブルを選択 a. gold_payment_method_summary / gold_daily_payment_trend / gold_merchant_summary / gold_customer_summary
79. ハンズオン：グラフウィジェットの配置 まずはグラフの枠をキャンバスに置く 1. 「無題のページ」タブを開き、「ビジュアライゼーションを追加」ボタンを押して新規グラフを追加 2. 新規グラフを任意の位置に配置し、右側のグラフ設定で可視化するデータセットやグラフ種別、カラム等の各種設定を入れる 「ビジュアライゼーションを追加」ボタン グラフの設定
80. ハンズオン：ダッシュボード化（ GUI） 自分の Gold テーブルからデータセットを定義し、KPI・時系列・ランキングを GUI で 配置する。 1. 「無題のページ」タブを開き、「ビジュアライゼーションを追加」ボタンを押して新規グラフを追加 2. 新規グラフを任意の位置に配置し、右側のグラフ設定で可視化するデータセットやグラフ種別、カラム等の各種設定を入れる a. 次ページ以降で作成する各グラフはこの手順で追加していく 「ビジュアライゼーションを追加」ボタン グラフの設定
81. ハンズオン：「カウンター」による可視化 「カウンター」タイプの可視化で、重要指標3つを表示させる 1. 「ビジュアライゼーションを追加」で新しいウィジェットを 3つ追加し、可視化として「カウンター」タイプを選択。 2. それぞれに対してタイトル、可視化、日付、値を下表の通りに設定する a. 「タイトル」はチェックを入れてからウィジェット上で直接上書き編集する 「カウンター」の設定項目 3つの「カウンター」それぞれに設定する内容 タイトル 可視化 日付 値 (ここだけカウンター毎に異なる ) 総決済件数 カウンター 「payment_date」列を MONTHLY で選択 「payment_count」列を SUM で選択 総決済金額 カウンター 「payment_date」列を MONTHLY で選択 「total_amount」列を SUM で選択 平均不正率 カウンター 「payment_date」列を MONTHLY で選択 「fraud_rate_pct」列を AVG で選択 完成するカウンターの例
82. ハンズオン：「折れ線」による可視化 「折れ線」タイプの可視化で決済件数の日次トレンド表示 1. 「ビジュアライゼーションを追加」で新しいウィジェットを追加し、可視化として「折れ線」タイプを選 択。 2. それぞれに対してタイトル、可視化、 X軸、Y軸、色を右図の通りに設定する。 a. X軸、Y軸、色で選択しているカラムは「 gold_daily_payment_trend」テーブルの列 b. 「タイトル」はチェックを入れてからウィジェット上で直接上書き編集する 完成する折れ線グラフの例 「折れ線」の設定項目
83. ハンズオン：「棒」による可視化 「棒」タイプの可視化で、決済手段別の決済件数を表示 1. 「ビジュアライゼーションを追加」で新しいウィジェットを追加し、可視化として「棒」タイプを選択。 2. それぞれに対してタイトル、可視化、 X軸、Y軸を右図の通りに設定する。 a. X軸、Y軸で選択しているカラムは「 gold_daily_payment_trend」テーブルの列 b. 「タイトル」はチェックを入れてからウィジェット上で直接上書き編集する 完成する棒グラフの例 「棒」の設定項目
84. ハンズオン：「テーブル」による可視化 「テーブル」タイプの可視化で、加盟店毎の集計値を表示 1. 「ビジュアライゼーションを追加」で新しいウィジェットを追加し、可視化として「テーブル」タイプを選 択。 2. それぞれに対してタイトル、可視化、列、行の順序を右図の通りに設定する。 a. 列、行の順序で選択しているカラムは「 gold_merchant_summary」テーブルの列 b. 行の順序は、 fraud_rate_pct 列を選択してから右のボタンで降順にする c. 「タイトル」はチェックを入れてからウィジェット上で直接上書き編集する 完成するテーブルの例 「折れ線」の設定項目
85. ハンズオン：ダッシュボードの公開 権限を持つユーザーがダッシュボードへアクセスできる状態にする • 「公開」ボタンで、作成したダッシュボードを閲覧可能な状態にする ◦ • 「共有」設定で許可されているユーザーだけが、公開されたダッシュボードにアクセスできる 他のユーザーがダッシュボードを閲覧する時、ダッシュボード作成者の権限 or 閲覧者の権限 どちらでデータにアクセスするのかも設 定可能。本ワークショップでは「共有データに対する権限」を選択してダッシュボード作成者の権限を使用。