Databricks Lakeflow クイックワークショップ / lakeflow-workshop

Databricks Lakeflow Spark Declarative Pipelinesのクイックワークショップのスライドです。

Transcript

1. Lakeflow Spark Declarative Pipelines (SDP) ワークショップ データブリックス・ジャパン
2. • Lakeflow とは？ • Lakeflow SDP の開発環境 • Lakeflow SDP の重要な構成要素 このワークショップの旅路 Lakeflow Spark Declarative Pipelines (SDP) Workshop • Databricksとは？ • データガバナンスとUnity Catalog • データエンジニアリング入門 • ちょっとだけSpark ② データエンジニアリング入門 ① プロローグ ③ Lakeflow 基礎理解 メダリオンアーキテクチャを意識しながら、販 売履歴を加工するパイプラインを構築 ④ Lakeflow SDP ハンズオン • イベントログの活用 • CI/CD対応 • 外部へのデータ連携 ⑤ まだあるLakeflow SDPの強み
3. Databricks とは？
4. DATA+AI カンパニー クリエーター 15,000+ グローバルのお客様 $4B+ YoY 50%+ 年間収益 $100B+ の企業価値 レイクハウス の 発明者 生成AIの パイオニア LEADER 2023 Cloud Database Management Systems LEADER 2024 Data Science & Machine Learning Analytic Stream Processing 4
5. Databricksを用いることで 1つのプラットフォームで データとAIに関する あらゆるユースケースを実現
6. データ変換 ペタバイト級 データ分析 SQL, BI 生成AI 活用〜カスタマイズ モデル開発〜提供 機械学習 Databricksの得意分野 活用／ シンプル化
7. ディザスターリカバリ コストコントロール エンタープライズセキュリティ 100% サーバレス レイクハウス AI/BI ビジネス インテリジェンス Databricks SQL データウェアハウス Workflows/DLT 取り込み、ETL ストリーミング Mosaic AI 人工知能 Databricksデータインテリジェンスプラットフォーム
8. ディザスターリカバリ コストコントロール エンタープライズセキュリティ 100% サーバレス レイクハウス AI/BI ビジネス インテリジェンス Databricks SQL データウェアハウス Lakeflow 取り込み、ETL ストリーミング Mosaic AI 人工知能 Databricksデータインテリジェンスプラットフォーム 本日の テーマ
9. データガバナンスと Unity Catalog
10. Q. データガバナンスとは？ A. データ資産について、ライフサイクル全体を通して管理するための、 原則、プラクティス（実践的な手法）、ツールを組み合わせた総合的な管理手法 • デジタルビジネスを拡大しようとする 組織の 80％は、不十分なガバナンスが原因で失 敗している（Gartner） • データガバナンスの不備により、ユーザー の時間の30％が付加価値のない タスクに費やされている（McKinsey） • データガバナンスの不備は、年間1,500万 ドルもの財務的損失をもたらす可能性があ る（investopedia） 監査 共有 アクセス制御 リネージ ディスカバリー データの使用状況の把握（利用者、時期） 社内外へのデータの安全な共有 データ保護の仕組み・方法 データの関連性とライフサイクルの追跡 データの容易な検索・検出 事実 主要なテーマ
11. Unity Catalog データとAIを一元管理する ガバナンス基盤 従来の カタログ Delta Lake Parquet Iceberg アクセス制御 発見・検出 リネージ 監査 安全な データ共有 品質 モニタリング コスト制御 ビジネス上の 意味 セキュリティ コラボレーション 品質 管理 テーブル AIモデル ファイル Notebooks Dashboards あらゆる外部 データソースと接続 あらゆるツール、エンジン、プ ラットフォームとの オープンなアクセスと連携
12. データについての詳細を調べることができるポータルとして機能 カタログエクスプローラー テーブル構造・説明 列名、データ型、 ビジネスメタデータ 等 その他基本情報 作成/最終更新の日時、ユー ザー、ストレージの場所、 テーブルプロパティ 等 履歴 いつ、誰が、どのコードやジョ ブでどんな処理をしたか、等を 一覧表示 アクセス権限 アクセスできるユーザーや権 限の種類 データリネージュ 他のデータとの依存関係の可 視化、ジョブやMLモデル、 コードとの関連も表示 利用状況 このテーブルを使用している 主なユーザー、クエリやコー ド、利用頻度 等を可視化 データプロファイル データの中身に関する様々な 統計、データ品質のダッシュ ボード
13. Unity Catalog のオブジェクト階層 メタストア → カタログ → スキーマ → テーブル メタストア カタログ スキーマ (データベース） シェア Recipient ビュー テーブル 関数 ストレージ 資格情報 外部ロケーション モデル Volumes 例えばテーブルへのアクセスは、以下のように行う。 SELECT * FROM <カタログ名>.<スキーマ名>.<テーブル名>
14. Unity Catalog のオブジェクト階層 メタストア → カタログ → スキーマ → テーブル メタストア カタログ スキーマ (データベース） シェア Recipient ビュー テーブル 関数 ストレージ 資格情報 外部ロケーション モデル Volumes ワークショップ参加者毎に作成 予め管理者が用意したカタログを使用 例えばテーブルへのアクセスは、以下のように行う。 SELECT * FROM <カタログ名>.<スキーマ名>.<テーブル名>
15. ② 管理者から指定されてい るカタログを検索し、開く ワークショップ用のスキーマを作成 ① ワークスペース左側のメ ニューから “Catalog” を開く ③ “Create schema” をクリック ④ 他参加者と重複しないスキーマ名 (自 身の氏名を含むもの等 ) を決 め、”Schema name”に入力して “Create” をクリック
16. データエンジニアリング入門
17. データエンジニアリング入門 基本的なデータエンジニアリング アーキテクチャ 取り込み データソース データストレージ データ処理 データガバナンス、アクセス、セキュリティ オーケストレーション データウェアハウスと BI データサイエンスと 機械学習 データ共有
18. データエンジニアリング入門 データエンジニアの主な役割 • データパイプライン：多様な ソースからストレージ、各種分 析ツールにデータが流れる経 路 • これらのパイプラインを作成、 自動化、最適化 データ パイプラインの 設計、構築、保守 • 多様なソースからデータを抽出 • エラーや不整合を除去 • ユーザーが活用しやすいように 構造化形式に変換して出力 • データの正確性、一貫性、 信頼性を監視・維持するための プロセスを開発 • 上記を実際に維持 データの品質と 整合性の確保 生データをクリーンで 信頼できるデータに変換
19. メダリオンアーキテクチャ ブロンズ、シルバー、ゴールドの3つのレイヤーで構成 データ品質レベル データの処理と変換 活用 シルバー ブロンズ データ品質の向上 データが各レイヤーを通過するにつれて、データの構造と品質 を段階的に改善します ゴールド 取り込み 機械学習と AI BI および レポート作成 ストリーミング分 析 バッチ ストリーミング
20. メダリオンアーキテクチャ ブロンズレイヤー データの処理と変換 活用 ブロンズ シルバー バッチ ストリーミング ゴールド 取り込み 機械学習 とAI BI および レポート作成 ストリーミング分 析 • 外部ソースシステムから取り込んだ生データの集積場所 • 生データのまま取り込み • 多くの場合 長期保存 (年単位) 必要に応じて個人を特定できる情報 (PII) を削除
21. メダリオンアーキテクチャ シルバーレイヤー データの処理と変換 シルバー ブロンズ バッチ ストリーミング 取り込み ゴールド • ブロンズデータをフィルタ、クレンジング、結合、エンリッチ • スキーマの強制 または進化を適用 • Single Source of Truth; SSoT = 信頼できる唯一の情報源 活用 機械学習 とAI BI および レポート作成 ストリーミング分 析
22. メダリオンアーキテクチャ ゴールドレイヤー データの処理と変換 活用 ゴールド 取り込み 機械学習と AI BI および レポート作成 ストリーミング分 析 ブロンズ シルバー バッチ ストリーミング • 活用の準備が完了 したクリーンなデータ • ビジネスレベルの集計、BIや機械学習に使いやすいデータセット • 下流のユーザーやアプリケーションが活用
23. メダリオンアーキテクチャ Delta Lake ACIDサポートにより柔軟なデータ操作が可能 データの処理と変換 シルバー ブロンズ ゴールド 取り込み バッチ ストリーミング 活用 機械学習 とAI BI および レポート作成 ストリーミング分 析 Delta Lake ACIDサポート データ変換プロセス全体を通じて、挿入、削除、更新、統合を 可能にする INSERT • DELETE • MERGE • OVERWRITE • AGGREGATE
24. メダリオンアーキテクチャ 現実世界のメダリオンアーキテクチャはより複雑なのが一般的 データストリーム ソース データストリーム ソース データレイク バッチ ソース 機械学習と AI BI および レポート作成 ストリーミング分 析 (CSV、 JSON、TXT...)
25. ちょっとだけ Spark
26. • Lakeflow SDP は内部ではSparkを活用していますが、従来のようにSparkの詳 細な仕組みを知らなくても容易にデータパイプラインを開発 /運用できる のが 特徴です。 • 一方でLakeflow SDPをPython APIで使用する場合、データの読み込みと変換 の基本的なコードの書き方は Sparkと共通している部分が多いです。 • そのため、ここでは詳細を省きながらSparkの概要、基本的なコードのイメージ のみにフォーカスして説明します。 なぜここで Spark の説明をするのか？ Lakeflow SDP は Spark を基礎技術として活用している
27. Apache Spark とは？ 大規模データの分散処理に最適化されたフレームワーク • 統合計算エンジン • 複数のノードから構成される「クラスター」で並列データ 処理 • Sparkはデータの分散処理において最もアクティブに開 発されているオープンソースエンジン • 広く使用されている複数のプログラミング言語をサポー ト(Python、Java、Scala、R) • SQLからストリーミング、機械学習に 渡る様々なタスクのためのライブラリも提供 構造化 ストリーミング 構造化API データセット データフレーム SQL 高度分析、ML、 グラフ解析、 ディープ ラーニング エコシステム + パッケージ 低レベルAPI 分散変数 RDD
28. Spark の分散処理機構 ドライバが分散したタスクをエグゼキュータへ振り分け クラスター ドライバ (司令塔) ワーカー (作業者) コア メモリ ローカルストレージ コア ワーカー (作業者) コア メモリ ローカルストレージ コア ③ワーカーへの タスクの振り分け クラスター マネージャー ②ワーカーの リソース割り当て &管理 ①ワーカーの リソースを要求 ③ワーカーへの タスクの振り分け 実行するコード
29. PythonでSparkを使用する際には、例えば spark.read.format(“データソースのファイル形式 ”) のようにしてデータを読み込む等、様々な操作を行うた めに使用します。 Apache Spark とは？ 大規模データの分散処理に最適化されたフレームワーク • SparkSessionはすべてのデータフレームAPIの機 能に対する単一のエントリーポイント • Databricksでは、”spark”という変数名でSpark セッションが自動的に作成されます JVM Spark セッション Python プロセス Rプロセス エグゼキューターへ
30. Spark DataFrame Sparkで表形式のデータを格納するためのオブジェクト item_id name price M_PREM_Q Premium Queen Mattress 1795 M_STAN_F Standard Full Mattress 945 M_PREM_F Premium Full Mattress 1695 M_PREM_T Premium Twin Mattress 1095 qty 35 24 45 18 テーブルと同じように列(カラム)と行(レコード) の概念、カラム名、カラム毎のデータ型、といった 情報が保持されている。 以下の例では、データファイルを読み込んで出来たDataFrameが変数”df”に格納される df = spark.read.format(“データソースのファイル形式 ”).load(“データファイルのパス”)
31. DataFrame を起点に様々データ変換を行う 列の選択、行のフィルタ、並べ替え、グループ化、集計、列追、etc. # データ変換例 その1 df.select("item_id", "price") .where("price > 70") .orderBy("price") # データ変換例 その2 df.withColumn("revenue", expr(“price * qty”)) .groupBy("item_id") .agg(sum(“revenue”).alias(“total_revenue”)) 1. dfに格納されているDataFrameから”id”列 と”result”列のデータのみを取り出す (select) 2. “result”列の値が70より大きいレコードのみを抽出 (where) 3. “result”の値が小さい順に並べる (orderBy) 1. dfに新たな列"revenue"を追加し、price とqtyを掛 けた値を格納する (withColumn) 2. “item_id”でレコードをグループ化 (groupBy) 3. “item_id”毎にrevenueの合計を計算 (agg と sum) 4. 計算した合計を入れる列名を ”total_revenue”にす る (alias)
32. Spark は様々なデータソースに対応 データソースからの読み込み & DataFrame の作成 # /path_of_files にある Parquet ファイルから DataFrameを作成 df = spark.read.format(“parquet”).load(“/path_of_files”)
 1 2 Parquetファイルから作成 # /path_of_files にある csv ファイルから DataFrameを作成 df = spark.read.format(“csv”).load(“/path_of_files”)
 1 2 CSVファイルから作成 同様の書き方で、JSON, Avro, ORC 等からも DataFrameを作成可能
33. 直感的なコーディングでデータ加工 DataFrame を使ったデータ加工 # user_id毎の販売金額合計を算出 new_df = (df .select(“user_id”, “revenue”) .groupBy(”user_id”) .sum(“revenue”))
 1 2 3 4 5 SQLやPandas DataFrameのような感覚で処理を記述可能 Spark内部で最適な実行プランの作成や並列処理化等を行ってくれる ちなみに・・・Spark は「遅延評価」の仕組みになっているため、 上記のコードを実行しただけでは実際のデータ処理は(まだ)行われない
34. 加工したデータを必要な形式で保存 DataFrame からの書き出し # new_df を Parquetファイルとして /path_to_save に書き出す (new_df .write .format(“parquet”) .save(”/path_to_save”)) 1 2 3 4 5 Writeメソッドにフォーマットを指定し、必要な形式で加工したデータを保存 「遅延評価」の仕組みにより、1つ前のスライドで記述した集計処理は 上記のコードを実行した際に初めて行われる
35. Lakeflow とは？
36. データエンジニアには膨大な管理・運用工数が発生 データ品質チェック ガバナンス データの発見性 (本当にやりたい、ビジネス側が求める ) データ加工ロジックの実装 依存関係 の管理 パーティション の最適化 チェックポイントと リトライ バックフィル 対応 バージョン管理 インフラ管理 データレイク オーケストレーション DWH ストリーミング BI データサイエンス 生成AI 機械学習
37. ©2025 Databricks Inc. — All rights reserved Lakeflow はあらゆる データに対して、より信頼 性の高いデータパイプラ インを、より早く構築する ための 統合ETLソリューション Data Engineers LAKEFLOW データ取り込み データ加工 オーケストレーション Connect Jobs Spark Declarative Pipelines
38. ©2025 Databricks Inc. — All rights reserved 本ワークショップの メイン Lakeflow はあらゆる データに対して、より信頼 性の高いデータパイプラ インを、より早く構築する ための 統合ETLソリューション LAKEFLOW データ取り込み データ加工 オーケストレーション Connect Spark Declarative Pipelines Jobs 本ワークショップでは ほぼ含まない (ストレージからの 標準的な取り込みが 主体) 本ワークショップでは 少し含む (1タスクのみの 単純なジョブを作成 )
39. Spark Declarative Pipelines とは？ ETL のためのモダンソフトウェアエンジニアリング 信頼性の高いデータパイプライン を、シンプルな宣言型アプローチ で構築可能なETLフレームワーク。 大規模なインフラを自動的に管理 するため、データアナリストやエンジニアはツールの操作に費やす時 間を削減し、データから価値を引き出すことに集中できる。 ETLの開発を加速 インフラを 自動管理 データの品質に 自信を持つ バッチも ストリーミングも シンプルに実現 https://www.databricks.com/product/data-engineering/dlt
40. コードの記載順序やファイルの分 け方等に関わらず、自動的に正 しい実行順序を組み立て、並列 で実行できる部分は並列化する といったオーケストレーションを 行ってくれる。 複雑な処理でもより少ない & 分 かりやすいコードで実装できる。 パイプラインの品質を上げるため に必要な詳細なロジックは、予 め用意された関数やオプション に内包されている。 Declarative (宣言型) だと何が良いのか？ 開発スピードが向上 ！ 得たい結果を簡易なコードで表現すれば、面倒な部分は自動で最適化される オーケストレーションが 自動化される！ 開発者が意識しなくても、独自 の増分処理エンジン によって、 可能な限り差分データのみを処 理するようプランを立てて実行し てくれる。 自動増分処理が コスパを最適化！
41. コードの記述が簡単になる例 1つ1つの処理ステップを記述するのではなく、得たい結果とその条件を記述 DLTによる宣言型のコード例 def upsertToDelta(microBatchOutputDF: DataFrame, batchId: Long) { microBatchOutputDF .groupBy("key") .agg(max_by("ts", struct("*").alias("row")) .select("row.*") .createOrReplaceTempView("updates") microBatchOutputDF.sparkSession.sql(s""" MERGE INTO cdc_data_raw t USING updates s ON s.key = t.key WHEN MATCHED AND s.is_delete THEN UPDATE SET DELETED_AT=now() WHEN MATCHED THEN UPDATE SET A=CASE WHEN s.ts > t.ts THEN s.a ELSE t.a, B=CASE WHEN s.ts > t.ts THEN s.b ELSE t.b, … for every column … WHEN NOT MATCHED THEN INSERT * """) } cdcData.writeStream .foreachBatch(upsertToDelta _) .outputMode("append") .start() APPLY CHANGES INTO cdc_data FROM source_data KEYS (id) SEQUENCE BY ts APPLY AS DELETE WHEN is_deleted PySpark でのコード例 本番向けの処理では様々なデータの到 着パターンやエラーへの対応等を含め て、実装すべきコードが増える PySparkでは全て自身でコードを書いて実装してい た部分が、書かなくても内部で自動的にハンドリン グしてくれたり、簡単なキーワード指定のみで実現 できるようになったりする 同じ処理を DLTで書くと
42. Lakeflow SDPは どんな環境で開発する？ 〜 Lakeflow Pipelines Editor 〜
43. Lakeflow SDPのコード開発環境の選択肢 Lakeflow SDPのコード開発では、Lakeflow Pipelines Editor が推奨 Lakeflow Pipelines Editor Databricks Notebook 任意のローカル IDE Lakeflow SDPのコード開発に最適化された環 境。コードを編集しながら対話的に実行 /テス トを行うことができ、グラフや様々なメトリクス、 エラー、パイプライン設定等を 1つ画面で確認・ 操作することが可能。 Databricks上での汎用的なコード作成・ 実行環境。ただし、Lakeflow SDPでは Notebook本来のセル単位での対話的 な実行ができない。パイプライン設定、 グラフ、様々なメトリクスは別画面で確認 する必要がある。 推奨 ローカルIDE上ではコードの編集のみが 可能。動作確認/実行するには Databricksワークスペース上への同期 / デプロイを都度実行する必要があるた め、インタラクティブな開発 /テストが困 難。 公式Doc : Lakeflow 宣言型パイプライン コード をローカル開発環境で開発する 公式Doc : Lakeflow宣言型パイプラインのノート ブックを使用した ETLパイプラインの開発とデ バッグ Lakeflow Pipelines Editorを使用した パイプラ インの開発とデバッグ
44. Lakeflow Pipelines Editor とは Lakeflowを使ったデータエンジニアリング専用の”IDE” 複数ファイルのタブ切替 コードファイルの管理 パイプラインの設定 & 実行 テーブルの自動可視化 テーブルのプレビュー パフォーマンス /メトリクス エラー調査 効率的な開発 /デバッグ のための部分的実行
45. Lakeflow Pipelines Editor とは Lakeflowを使ったデータエンジニアリング専用の”IDE” 複数ファイルのタブ切替 コードファイルの管理 パイプラインの設定 & 実行 テーブルの自動可視化 テーブルのプレビュー パフォーマンス /メトリクス エラー調査 効率的な開発 /デバッグ のための部分的実行 ここの構造、考え方について説明
46. ルートフォルダ と ソースコードフォルダ パイプラインの実行使うコードと、それ以外のコードを整理できる ルートフォルダ パイプラインに関連する 全てのファイルを格納する場所 ソースコードフォルダ パイプラインを実行した時に 実行されるソースコード その他 任意のフォルダ その他 任意のフォルダ ・・・ この2つのフォルダは設定で管 理され、特別な意味を持つ ルートフォルダ直下にその他のフォルダ を作ったり、ソースコードフォルダの配下 をサブフォルダに分けたり等は自由に行 える
47. ルートフォルダ と ソースコードフォルダ 実際のディレクトリ構成と設定の例 パイプラインアセットブラウザ パイプライン設定 ルートフォルダ ソースコード ルートフォルダ、ソースコードフォルダを それぞれどこにするかはパイプライン設定上で 管理されており、変更することも可能 でパイプライン全体を実行した時、 実行されるファイルはこの部分だけ
48. パイプラインソースコードからイン ポートした場合はLDP専用Compute で、(テスト等で) 単体実行の場合は 汎用クラスターで実行 ルートフォルダ と ソースコードフォルダ 推奨 (およびデフォルトの) ディレクトリ構成 パイプラインを使うには最低限何らかのルートフォルダ、ソースコードフォルダが設定され ていればOKであり、フォルダ名も任意。 しかし以下の推奨構成があり、この構成がデフォルトになっている。 ルートフォルダ (パイプライン名と同じ ) ソースコードフォルダ transformations explorations utilities パイプライン実行時に実行する Python / SQLのソースコードファイル パイプライン実行時には使用しない、ノー トブック、クエリ、ダッシュボード等の各種 アセット 各フォルダに配置するアセット 実行時のコンピュート LDP専用Computeで実行 (Serverless or Classic) LDP以外の、それぞれのアセットの 種類に応じたComputeで実行 パイプラインのソースコードから インポートして使う共通モジュール等
49. Lakeflow SDP の 重要なコンポーネント
50. Lakeflow SDP の主な構成要素 これ全体をLakeflow SDPのパイプライン と呼ぶ これらをコードの中でブロックのように組み合わせ、パイプラインを作成 ストリーミング データソース ファイル、テーブル、 ストリーミングテーブル、 メッセージバス、 変更データフィード、 etc. ファイル、テーブル、 ストリーミングテーブル、 マテリアライズドビュー、 etc. バッチ データソース ストリーミング処理 Append フロー Auto CDC フロー ストリーミングターゲット シンク ストリーミングテーブル ストリーミング処理 マテリアライズドビュー フロー バッチターゲット マテリアライズドビュー 上流にある様々な データソース
51. ストリーミングテーブル (ST) 技術的な特徴 • Append-onlyなデータ取り込み / 変換専用のテーブル • 各入力レコードは1回だけ処理 (Exactly-Once) • 上流データが既に取り込み済みのレコードの再処理は行わ れない（ただし、Full Refreshを行うと全レコードを再処理） 留意事項 • データ変換のロジックが途中で変わっても、過去に処理され たデータの再処理は行われない • 既に取り込みのデータが上流のデータソース側が変更 /削 除されても、ストリーミングテーブル上のレコードは変更 /削 除されない Append-onlyなデータ取り込み / 変換 基本的な作成方法 <SQLの場合> CREATE OR REFRESH STREAMING TABLE basic_st AS SELECT * FROM STREAM samples.nyctaxi.trips; <Pythonの場合> from pyspark import pipelines as dp @dp.table(name = "trips_st") def basic_st(): return spark.readStream .table("samples.nyctaxi.trips")
52. マテリアライズドビュー (MV) 技術的な特徴 • 結果を事前計算、キャッシュするビュー • 上流データの変更/削除に追随して結果が最新化される • 全データを再処理するのと同じ最新の結果を担保しつつ、 内部では可能な限り増分的に処理する • 指定した間隔で上流データと同期 留意事項 • 最新の結果を計算するのに増分処理を適用できるかどうか は内部のエンジンの判断に依存し、判断の結果次第で全レ コードの再計算となる場合がある 変更や削除も含め、常に最新の結果を反映 基本的な作成方法 <SQLの場合> CREATE OR REFRESH MATERIALIZED VIEW basic_mv AS SELECT * FROM samples.nyctaxi.trips; <Pythonの場合> from pyspark import pipelines as dp @dp.materialized_view(name = "trips_mv") def basic_mv(): return spark.read .table("samples.nyctaxi.trips")
53. STとMVの挙動の違い 上流データに追加、変更があった場合の挙動を見てみよう ストリーミング テーブル マテリアライズド ビュー データ ソース Step 1 初回のデータ取り込み ストリーミング テーブル マテリアライズド ビュー データ ソース Step 2 データソースにレコード追加 ストリーミング テーブル マテリアライズド ビュー データ ソース Step 3 2回目のデータ取り込み レコード数： 10 件 レコード数： 12 件 INSERT レコード 2 件 追加 追加の 2件だけ 取り込み 12 件 全てを 取り込み レコード数： 12 件 ※ 正確には、 12件全てのレコード
54. フロー データソースからST / MVへデータを取り込む流れ を表し、上流のデータソースからデータを取得するクエリ と、取得したデータの書き込み先となるターゲット を定義する。 ストリーミングテーブルやマテリアライズドビューにデータを取り込む データソース ファイル、テーブル、メッ セージバス 等 フロー データソースとターゲットを 指定して、データを取得す るクエリ ターゲット ストリーミングテーブル、マ テリアライズドビュー フローには2つの種類があり、用途に応じて使い分ける。 Append フロー データソースに追加された新しいデータ(ファイ ル、レコード)のみを処理し、ターゲットに追記 (Append)する Auto CDC フロー データソースのChange Data Feed (CDF)を使 用して、ターゲットテーブルを差分更新する。追 記だけではく更新、削除を含む。
55. Append フロー データソースに追加された新しいデータ(ファイル、レコード)のみを処理し、 ターゲットに追記(Append)するフロー ストリーミングテーブルやマテリアライズドビューにデータを取り込む 基本的な作成方法 (明示的に作成する場合 ) <SQLの場合> CREATE FLOW customers_silver AS INSERT INTO customers_silver BY NAME SELECT * FROM STREAM(customers_bronze); <Pythonの場合> from pyspark import pipelines as dp @dp.append_flow(target = "customers_silver") def customer_silver(): return spark.readStream.table("customers_bronze") ※ 上記の例では、customer_silverというストリーミングテーブルが予め作成されてい るものとする • マテリアライズドビューやストリーミングテーブルを データ取得クエリを含める形で作成した場合、 暗黙的 にAppendフローが作成されている • 明示的に作成したフローは、ストリーミングテーブルま たはシンク(後述)のみをターゲットとすることができる • 複数のフローからターゲットを、同一のストリーミング テーブルに指定することもできる
56. Auto CDC フロー データソースのChange Data Feed (CDF)を使用して、ターゲットテーブルを差分更新する。追記だけではく 更新、削除を含む。 Change Data Feed (CDF)を使用した差分更新 基本的な作成方法 <SQLの場合> CREATE FLOW target_flow AS AUTO CDC INTO target FROM stream(cdc_data.users) KEYS (userId) APPLY AS DELETE WHEN operation = "DELETE" SEQUENCE BY sequenceNum COLUMNS * EXCEPT (operation, sequenceNum) STORED AS SCD TYPE 2; <Pythonの場合> dp.create_auto_cdc_flow ( target = "target", source = "users", keys = ["userId"], sequence_by = col("sequenceNum"), apply_as_deletes = expr("operation = 'DELETE'"), except_column_list = ["operation", "sequenceNum"], stored_as_scd_type = "2" ) ※ 上記の例では、targetというストリーミングテーブルが予め作成されおり、usersには ソースのCDF情報が格納されているいるものとする。 • Append フローと異なり、Auto CDC フローは必ず明 示的に作成する必要がある • Auto CDC フローのターゲットとして指定できるのは、 ストリーミングテーブルのみ • Append フロー同様、複数のフローからのターゲット を同一のストリーミングテーブルに指定することもでき る • 同一キーを持つレコードに対して上流から複数レコー ドが到着した場合の順序判断や、 SCD Type 1 / Type 2のどちらで更新するか等、差分更新の動作を コントロールするパラメータが用意されている
57. 補足：SCD Type 2 とは？ モチベーション：過去の任意の時点のデータを取得したい SCD Type 2 とは • あるIDのレコードに対して更新があっても上 書きはしない • 同一ID (PK) に対して、過去履歴を含む複数 のレコードを保持 • 各レコードには、いつからいつまで有効で あったかを示すカラムが保持されている userId name city __START_AT __END_AT 123 Isabel Monterrey 2025/1/10 5:00 2025/2/20 9:00 123 Isabel Chihuahua 2025/2/20 9:00 2025/3/1 2:00 124 Raul Oaxaca 2025/1/10 5:00 null 125 Mercedes Tijuana 2025/1/25 8:00 2025/2/20 9:00 125 Mercedes Mexicali 2025/2/20 9:00 2025/3/1 2:00 125 Mercedes Guadalajara 2025/3/1 2:00 null 126 Lily Cancun 2025/1/25 8:00 null 3/1 2:00で DELETE 現在も有効な レコードは ENDがNULL SCD Type 2のテーブル例 SCD Type 2 のデータモデルを採用することで、 長期を跨いで任意の時点のデータが取得できるようになる
58. 補足：SCD Type 2 の実装上の課題 SCD Type 2 は分析には便利な反面、 様々なケースに対してロバストに実装しようとすると煩雑になる • 同じ(マイクロ)バッチの中で、同一IDに対する操作が 複数含まれていたら？ • データの操作日時と、実際にデータが到着する日時 で順不同になっていたら？ • DELETEが来たらどうハンドリングするか？ • 順不同問題とDELETE問題の混合パターン：先に DELETEが来たIDに対するUPDATE/INSERTが遅れ て到着したら？ userId name city __START_AT __END_AT 123 Isabel Monterrey 2025/1/10 5:00 2025/2/20 9:00 123 Isabel Chihuahua 2025/2/20 9:00 2025/3/1 2:00 124 Raul Oaxaca 2025/1/10 5:00 null 125 Mercedes Tijuana 2025/1/25 8:00 2025/2/20 9:00 125 Mercedes Mexicali 2025/2/20 9:00 2025/3/1 2:00 125 Mercedes Guadalajara 2025/3/1 2:00 null 126 Lily Cancun 2025/1/25 8:00 null SCD Type 2のテーブル例 想定しなければいけないケースの例 上記への対処を全て実装しようとすると、 コードの煩雑化や考慮漏れが発生する
59. Auto CDC による SCD Type 2 の容易な実現 SCD Type 2 の実装上の煩雑さを排除し、シンプルなAPIで実現可能にする userId name city operation sequence 123 Isabel Monterrey INSERT 2025/1/10 5:00 123 null null DELETE 2025/3/1 2:00 125 Mercedes Guadalajara UPDATE 2025/3/1 2:00 ・・・ ・・・ ・・・ ・・・ ・・・ SourceからのCDF (Change Data Feed) userId name city 123 Isabel Chihuahua 124 Raul Oaxaca 125 Mercedes Guadalajara 126 Lily Cancun Sourceからのスナップショット userId name city __START_AT __END_AT 123 Isabel Monterrey 2025/1/10 5:00 2025/2/20 9:00 123 Isabel Chihuahua 2025/2/20 9:00 2025/3/1 2:00 124 Raul Oaxaca 2025/1/10 5:00 null 125 Mercedes Tijuana 2025/1/25 8:00 2025/2/20 9:00 125 Mercedes Mexicali 2025/2/20 9:00 2025/3/1 2:00 125 Mercedes Guadalajara 2025/3/1 2:00 null 126 Lily Cancun 2025/1/25 8:00 null OR LDPが提供する Python/SQLのAPI create_auto_cdc_flow() または create_auto_cdc_from_sn apshot_flow() 前ページの例のような 様々なケースに対応する ための処理を実装済み • ソートキーの指定 • NULL列の扱い • DELETEの挙動指定 • TRUNCATEの挙動指定 • 追跡対象の列指定 • SCD Typeの指定
60. シンク ST/ MV以外の形式でデータを書き出す LDPで加工したデータをDatabricks外の様々なシステムで使用可能にするため、ST / MV以外の形式で データを書き出す。 シンクで対応可能な書き出し先 / 形式 • Delta テーブル • Apache Kafka • Azure Event Hubs • Python カスタムデータソース • 任意の書き込み先/形式をカスタム実装可能 留意事項 • Pythonのみ対応 (SQLは非対応) • ストリーミングクエリのみ対応 • Append フローのみ • LDP側でクエリの変更や既存データの更新 /削除等を行った 場合でも、シンク先に書き出し済みのデータは更新 /削除さ れない (新規データの書き出しのみ ) 基本的な作成方法 (Kafkaをシンクにする例) <Python> credential_name = "<service-credential>" eh_namespace_name = "dp-eventhub" bootstrap_servers = f"{eh_namespace_name}.servicebus.windows.net:9093" topic_name = "dp-sink" dp.create_sink ( name = "eh_sink", format = "kafka", options = { "databricks.serviceCredential": credential_name, "kafka.bootstrap.servers": bootstrap_servers, "topic": topic_name } ) @dp.append_flow(name = "kafka_sink_flow", target = "eh_sink") def kafka_sink_flow(): return ( spark.readStream .table("spark_referrers") .selectExpr("cast(current_page_id as string) as key", "to_json(struct(referrer, current_page_title, click_count)) AS value") )
61. リアルタイム性が必要 な場合、MVではなく通 常のビューも選択肢 パイプラインの中での ST / MVの使い分け 上流データソースの種類/更新の性質と、変換処理の内容によって選択 • クラウドストレージ：新規ファイル追加 のみ • メッセージバス (Kafka / Kinesis / Event Hubs / etc.) • Append-onlyのテーブル (Federation 接続した外部テーブル、 Databricksマ ネージドテーブル ) データソース Bronze Silver Gold • ストリーミングテーブル • CDFがあるデータソース • クラウドストレージ：テーブル全体のス ナップショット or 既存ファイルの上書き あり • マテリアライズドビュー • 更新/削除があるテーブル (Federation接続した外部テーブル、 Databricksマネージドテーブル ) ストリーミング テーブル マテリアライズド ビュー マテリアライズド ビュー ストリーミング テーブル マテリアライズド ビュー Append フロー Auto CDC フロー Append フロー MV フロー(暗 黙) MV フロー(暗 黙) Append フロー(暗 黙) MV フロー(暗 黙) フィルタリング、カラム追 加等レコード単位の変換 のみの場合 上流がMVの場合 Auto CDC フロー 集計処理 パイプライン外にある上流データ 生データの保存 整形、結合等を行ったデータ (集計無し) 個々の分析用途に合わせて 集計された結果 シンク 外部システム向けに ST/MV以外の任意の形式で書き出したい場合
62. 実際にパイプラインを開発してみよう 販売履歴のデータパイプライン構築
63. ハンズオンのシナリオとデータセット 販売履歴に顧客マスター、商品マスターを紐付けてデータマートまで作成 商品 マスター テーブル 商品マスター (products) マテリアライズドビュー パイプライン 上流データソース MVフロー 顧客 マスター CSVファイル (CDF) 顧客マスター (users) ストリーミングテーブル 顧客マスター 変更情報 Export AutoCDC フロー CSVファイル 販売履歴 (transactions) 東エリア 販売履歴 Appendフロー 西エリア 販売履歴 CSVファイル Appendフロー ストリーミングテーブル 分析用 販売履歴 (traffic_log_enriched) ストリーミングテーブル ユーザーセグメント別売上 (revenue_by_ user_segment) マテリアライズドビュー 商品サブカテゴリ別売上 (revenue_by_ subcategory) マテリアライズドビュー Bronze Silver Gold
64. ワークショップ用コードのインポート ① ワークスペース左側のメニュー から “Workspace” を開く ② 右上の方にある 3点リーダーの 様な部分から、 “Import” を開く ③ インポート画面が開くので、 配布されたワークショップ用コードの zipファイ ルをそのままドラッグ &ドロップする
65. ③ 他参加者と重複しないパイプライン名 (自身の氏 名を含むもの等 ) を決め、入力し、 ”Add existing assets” を選択 新規にパイプライン設定を作成する ① ワークスペース左側のメニュー から “Jobs & Pipelines” を開く ② “Create”の右側にあるプルダウ ンを開き、 ”ETL pipeline” を選択 自身のカタログとスキーマに変更 パイプライン名を決める 選択
66. ④ “Pipeline root folder” はインポートしたワークショップ用 コードのトップのフォルダを指定し、 ”Source code paths” に はその配下にある ”transformations” を指定 新規にパイプライン設定を作成する
67. 新規作成したパイプラインの初期画面 Lakeflow Pipelines Editor
68. パイプラインの設定を開く コードとディレクトリ、カスタムパラメータ、ロギング等の様々な設定 Lakeflow Pipeline Editorの 画面右上から設定画面を開く OR (画面サイズによって表示が変更される )
69. 本ワークショップで行う設定変更 ① デフォルトのカタログをスキーマを変更 コード内でテーブル名にアクセスする際、カタログ名をスキーマ名を省略できるよう、デフォルト設定を変更 ② パラメータ設定 自身のカタログ名とスキーマ名をコード内で参照できるように Key-Value形式のパラメータとして設定しておく
70. 本ワークショップで行う設定変更 ③ イベントログをテーブルに保存するよう設定 “Advanced settings” を編集し、Event Logs の “Publish event to Unity Catalog” にチェックを入れる。 Event logを保存するテーブル名を新たに決め、テーブルを格納するカタログをスキーマも選択する。 このワークショップでは、カタログとスキーマはパイプラインで設定したものと同じにする。
71. ワークショップ事前セットアップ “explorations”フォルダの配下にある以下のノートブックを使って、環境設定と初期 サンプルデータの作成を行います。 • ノートブック「00_環境設定」にある変数”CATALOG_NAME” と”SCHEMA_NAME”を自身の環境に合わせて書き換える。 • ノートブック「01_初期データ生成」を “Run all” ボタンで実行する。 ここで使用するノートブックはワークショップ用の環境 (スキーマやファイル格納用のボリューム等)の セットアップ、サンプルデータの生成を行うためのものなので、中身のコードを確認/理解する必要はあ りません。 サンプルデータの生成
72. ブロンズレイヤーの作成
73. まず最初に、商品マスターをパイプラインに取り込む。商品マスターは上流データソースにあるテーブルを直接参照して、そのデータをパイプ ラインに取り込むことになっている。商品マスターでは新規商品レコードの追加だけでなく、 既存の商品レコードの更新や削除も発生 する。 → ここでは 商品マスター が比較的小さなテーブルであるという想定で、マテリアライズビューへ直接取り込む。 マテリアライズドビューは「上流データの変更 /削除に追随して結果が最新化される」ため、既存の商品レコードの更新や削除も自動的に パイプライン側に反映される。 最初のコードを記述してみよう 商品マスターの取り込み（ファイル名：ingest_products.py） 商品 マスター テーブル ※ ワークショップでは構成を簡単にするため、 このテーブルもDatabricks上にありますが、 本来は上流 (Databricks) にあると仮定します 商品マスター (products) マテリアライズドビュー パイプライン 上流データソース MVフロー※ ※ MVのフローは明示的に作 成するものではなく、 MVを作成 すると暗黙的に (自動的に作成 される)
74. 簡単に使い始められるだけでなく、 サーバーレスならではの以下のメリットがある マテリアライズドビューの増分リフレッシュ 可能な限り差分だけを部分的に更新し、コストパ フォーマンスを最適化する ストリームのパイプライニング マイクロバッチを同時並行で処理し、ストリーミング処 理の効率や速度を向上させる 垂直オートスケーリング 最適でコスト効率のよいインスタンスタイプを自動選択 し、メモリ不足による失敗を防ぐ サーバレスコンピュートに接続する インスタンスのサイズや台数、その他設定も一切気にせず、ただ接続するだけ ボタンを押すだけでサーバーレスコンピュートが 割り当てられ、自動でスケール
75. Dry Run でコードチェックとグラフの可視化 実際にパイプラインを実行する前に Dry Run を行うこと で、実際のデータ更新や公開を行わず、安全にソース コードが正しいかを確認 できる。 Dry Runの主な処理 • パイプラインで定義されたデータセットやフローの定 義を解決。 • 誤ったテーブル名・カラム名などのエラーを検出して UI上に表示。 • 実際のデータの生成や公開は行わない。 クイックで安全なコード検証方法
76. 顧客マスターも新規顧客レコードの追加だけでなく、 既存の顧客レコードの更新や削除も発生 する。しかし顧客マスターは商品マスターと 違って大きなテーブルであるため、マテリアライズドビューで毎回全レコードを見て取り込むのは処理時間、コスト面で懸念がある。 → Auto CDCフロー + ストリーミングテーブルを活用することで、差分更新を容易に実現可能。 ここでは上流の顧客マスター DBがレコードの変更履歴を記録した CSVファイルを一定間隔でクラウドストレージに出力し、 AutoCDCフローで取 り込むことで、パイプライン側の顧客マスターで 効率的な差分更新 を実現する。 Auto CDC による差分更新のフローを作る 顧客マスターの取り込み（ファイル名：ingest_users.py） 顧客 マスター CSVファイル形式の Change Data Feed (CDF) 顧客マスター (users) ストリーミングテーブル パイプライン 上流データソース 顧客マスター 変更情報 Export AutoCDCフロー で差分取り込み
77. 販売履歴はマスターデータと違って、既存レコードの更新や削除が発生しない Append-onlyのデータである。ただし、それぞれ別々のクラウド ストレージに出力される東エリアの販売履歴と西エリアの販売履歴 (データ構造は同じ) を1つのテーブルに取り込みたい。 → Appendフロー + ストリーミングテーブルの組み合わせで、処理効率の高めながら実現可能。 取り込み先のテーブルが 1つの場合でも、異なるデータソースからの取り込みを並列で実行。非効率な Unionを回避。 複数データソースから 1つのテーブルに取り込む 販売履歴の取り込み（ファイル名：ingest_transactions.py） CSVファイル 販売履歴 (transactions) ストリーミングテーブル パイプライン 上流データソース 東エリア 販売履歴 Appendフロー 西エリア 販売履歴 CSVファイル クラウドストレージ B クラウドストレージ A Appendフロー 並列で実行！
78. シルバーレイヤーの作成
79. Lakeflow SDPの重要な性質： オーケストレーションの自動化 　記述したコードの中では、「最新の販売履歴を取り込 み、顧客マスターと商品マスターも更新してから、結合 して・・・」といった処理の実行順序を一切定義してい ない。 → Lakeflow SDPがテーブル間の関係性をコードか ら認識し、以下のことを自動で実現している • 販売履歴、顧客マスター、商品マスターの 3テー ブルは違いに依存していないので、更新処理は 並列に行う（並列化） • 分析用販売履歴の更新は、上流の 3テーブルの 更新が完了してから行う （正しい順序） 販売履歴に対して、顧客マスターと商品マスターを結合する。 実行順序の自動解決 履歴とマスターの結合（ファイル名：enrich_transactions.py） 販売履歴 (transactions) ストリーミングテーブル パイプライン 商品マスター (products) 顧客マスター (users) ストリーミングテーブル マテリアライズドビュー 分析用 販売履歴 (transactions_enriched) Stream-Static 結合 ストリーミングテーブル
80. ゴールドレイヤーの作成
81. 分析用販売履歴に対して、集計処理を行って個々の分析に合わせたデータマート作成する。 → マテリアライズビューで作成する。 MVの重要な性質： 増分処理エンジン (Enzyme) 　地域別平均スループットを算出するには、毎回分析用販売履歴の全レコードを見て平均を計算するロジックが必要となる。このよう な、通常であれば毎回全レコードの処理が必要なケースであっても、 MVの増分処理エンジン (Enzyme) は追加/変更があったレコー ドのみを処理する等の最適化を図ることで大幅にコスパを改善。 (ただし保証はされず、処理内容 /データによって全件処理となる場合 もある。) マテリアライズドビューの増分処理エンジン データマートの作成（ファイル名：revenue_by_user_segment.py） ユーザーセグメント別売上 (revenue_by_user_segment) マテリアライズドビュー パイプライン MVフロー 分析用 販売履歴 (transactions_enriched) ストリーミングテーブル
82. Enzyme とは データマート(MV)の更新を最適化し、コストパフォーマンスを大幅に改善 変更情報の トラッキング クエリプラン の分析 Monotonic Append (追加レコードのみ処理 ) Partition Recompute (影響するパーティションのみ再計算 ) MERGE Updates (キーのマッチングによる差分更新 ) Full Recompute (全レコードの再計算 ) Cost Model 最適な 処理戦略 を選択 + Catalyst Query Optimizer Enzymeが選択する処理戦略 公式Doc : Enzyme による増分処理の条件、各処理戦略の詳細等
83. Lakeflow SDPでの データ品質管理
84. パイプラインを破壊する “不正なデータ ” データ基盤が汚染され、分析結果に狂いが生じる Col1 Col2 Col3 1 null STARTED 2 True XWKQEDLQQ 1000000000 False FINISHED 1 False PAUSED • 値の欠落 (NULL, 空文字, etc.) • データフォーマットの逸脱 • エンコーディングの差異 • 外れ値、上限を上回る/下限を下回る値 • 未知のカテゴリ値の出現 • 数値の単位変更のズレ • ・・・
85. Lakeflow SDPでのデータ品質管理 個々のデータに任意の条件を定義し、それに応じてアクションを取り、 結果を記録することができる 全てのDLTパイプラインの実行について 品質メトリクスが可視化され、深掘り分析も可 能なログも提供 データの品質や整合性に関する条件を、 Expectations という機能 (SQL/Python内に 記述) で定義する 定義した条件をデータが満たさなかった場合、 希望するアクションを実施させることができる /* Stage 1: Bronze Table drop invalid rows */ CREATE STREAMING TABLE fire_account_bronze AS ( CONSTRAINT valid_account_open_dt EXPECT (acconut_dt is not null and (account_close_dt > account_open_dt)) ON VIOLATION DROP ROW COMMENT "Bronze table with valid account ids" SELECT * FROM fire_account_raw ...
86. 不正データに対する選択可能なアクション 基本となる3つのアクションから、カスタム実装のより高度なアクションまで 基本の3パターン 1. Fail : 処理全体を異常終了させる 2. Drop : 不正データのみドロップして、 正常データの処理を継続する 3. Monitor : 不正データとして件数の カウントのみ行い、正常データと一緒 に処理する 応用パターンの例 隔離：不正データを正常データは別のテー ブルに隔離しておき、後で修正、再処理が できるようにしておく
87. データ品質ルール ①：購入数量と代金 購入数量は購入代金はそれぞれ1以上、0より大 きいものとし、違反したレコードは隔離。 データ検証の条件式： quantity >= 1 transaction_price > 0 ワークショップ用 不正データ混入のシナリオ 追加ファイル名：expectation_rules.py 変更する既存ファイル名：ingest_transactions.py, enrich_transactions.py CSVファイル 販売履歴 (transactions) ストリーミングテーブル 上流データソース 東エリア 販売履歴 西エリア 販売履歴 CSVファイル 販売履歴 (transactions) ストリーミングテーブル 商品マスター (products) 顧客マスター (users) ストリーミングテーブル マテリアライズドビュー 分析用 販売履歴 (transactions_enriched) データ品質ルール ② AND ③：マスタ存在チェック 顧客マスターや商品にマスタに含まれないuser_idや product_idを含む販売履歴が来た場合、深刻な不正 データとして扱い、処理を異常終了させる <データ検証の条件式> products.product_id IS NOT NULL users.user_id IS NOT NULL ストリーミングテーブル ここでチェック ここでチェック 正常データ (処理継続 ) 不正データ (隔離) 結合で紐付かないログが あったら、処理を異常終了
88. データ品質ルールを適用してから、 不正データを発生させてみよう 1. 既存のコードを変更して、データ品質ルールを適用してください a. 「ingest_transactions.py」のコードは、「ingest_transactions_expectation.py」 のコードに差し替えてください。 b. 「enrich_transactions.py」のコードは、 「enrich_transactions_expectation.py」のコードに差し替えてください。 2. ノートブック「02_不正データ追加 」を “Run all” ボタンで実行してください。 ※ 「02_不正データ追加」のノートブックはワークショップ用のサンプルデータの 生成を行うためのものなので、中身のコードを確認/理解する必要はありません。
89. 結果として発生するエラー例 どのデータが、どのルールに違反したかが詳細に表示される グラフ上で エラー発生箇所が ハイライト User_idの NULLチェックルール での違反を確認 ルール違反が発生した レコードの具体的な値等も表示 この販売履歴との結合時に顧客マスター側のレコードが NULLとなっている。 ここから、顧客マスターに無い user_idが販売履歴に含まれているのでは？と推測できる。
90. 作成したパイプラインを本番化する Lakeflow Jobs
91. Serverless LAKEFLOW Jobs データとAIのための 信頼性の高い オーケストレーション Scheduled Continuous File arrival Table update Triggers Observability Control Flow ETL ML/AI Analytics/BI
92. Lakeflow Jobs のタスクタイプや制御フロー タスクを選択し、制御フローを作成し、Jobsのデータトリガーを定義する Databricks Notebooks Python Scripts Python Wheels SQL Files/ Queries DLT dbt Java JAR file Spark Submit ジョブは 1 つ以上の タスクをまとめて管 理可能 タスク間に柔軟な制 御フローを構築可 能 ジョブは柔軟なトリ ガー設定をサポート AI/BI Dashboards Manual Trigger Scheduled (Cron) API Trigger File Arrival Triggers Table Triggers Continuous (Streaming) Power BI Sequential Parallel Conditionals (If/else) Run Job (Modular) For each
93. Lakeflow Jobs の統合オーケストレーション • コード再利用や子ワークフローによる柔軟 な設計 • ジョブパラメータをタスクに渡すことで動的 制御を実現 • タスク間で値を共有し効率的に連携 • Slack などと統合可能な Webhook をサ ポート • 遅延ジョブを検知し、ステークホルダーに 自動通知する仕組み
94. ③ 他参加者と重複しないジョブ名 (自身の氏名 を含むもの等 ) を決め、入力する 新規ジョブの作成 ① ワークスペース左側のメニュー から “Jobs & Pipelines” を開く ② “Create”の右側にあるプルダウ ンを開き、 ”Job” を選択
95. 作成済パイプラインをタスクとして定義 ① “Add another task type” を選択 ② タスクタイプとして “ETL Pipeline” を選択 ② タスク設定で作成済みのパイプラインを指定し、 　必要に応じてリトライ設定や通知設定を入れる
96. ジョブをスケジュールする ① ジョブ画面右側の設定の 　中から、 Add trigger を選択 ② トリガータイプを選択し、トリガータイプ毎の各種設定 (スケジュールや監視ディレクトリ等 )
97. ワークショップで カバーできなかった Lakeflow SDPの発展的な内容
98. モニタリング
99. パイプラインに関連する全ての情報を提供 • パフォーマンスメトリクス • データ品質チェック結果 • パイプラインの実行状況 • データリネージ • エラーの詳細 イベントログはパイプラインのUI上だけでなく、 テーブルとして蓄積されるので、複数のパイプ ライン横断での分析や過去のログを含めた 時系列での分析等も容易 イベントログ パイプラインで起きたこと全てを自動で記録し、様々な分析に活用可能
100. ダッシュボードとの組み合わせ イベントログから分かるパイプラインの重要なメトリクスをダッシュボード化 Lakeflow SDP イベントログ AI/BI ダッシュボード
101. イベントログの活用例 多数のパイプラインのパフォーマンス 情報を横断で収集し、処理時間やデー タ量の統計を可視化。優先的にチュー ニングを行うべきパイプラインを特定。 過去の実行も含めてパイプラインで発 生したデータ品質ルール違反をルー ル別に時系列分析し、特に多いデータ 品質問題のパターン、その推移を可視 化する。 多数のパイプラインについてエラーク ラス毎のエラー発生件数等を集計、可 視化、運用工数削減のために注力す べきエラーケースを特定する。 パフォーマンス分析 データ品質の時系列分析 エラー発生件数 パイプラインで起きたこと全てを自動で記録し、様々な分析に活用可能 パイプライン 1 ・・・ パイプライン 2 パイプライン 3
102. CI/CD対応
103. Databricks Asset Bundles と組み合わせる 開発環境と本番環境の整合性を保ってCI/CDを回すためにはほぼ必須 よくあるご要望： Declarative Pipelinesのコードも GitHub等のリポジトリで管理できるか？ A. Gitフォルダをルートフォルダとして使用する等して、簡単にリモートリポジトリと連携可能。 ただしDeclarative Pipelinesを構成しているのはソースコードのみではなく、様々な設定が存在
104. Databricks Asset Bundles と組み合わせる 開発環境と本番環境の整合性を保ってCI/CDを回すためにはほぼ必須 パイプライン設定 ルートフォルダ以下のアセット (ソースコード含む) ＋ パイプライン 開発環境 GitHub等のリモートリポジトリ ルートフォルダ以下のアセット (ソースコード含む) パイプライン設定 ルートフォルダ以下のアセット (ソースコード含む) ＋ パイプライン 本番環境 同期 コード編集 設定変更 設定は 変更前のまま 同期 設定差異
105. Databricks Asset Bundles と組み合わせる 開発環境と本番環境の整合性を保ってCI/CDを回すためにはほぼ必須 パイプライン設定 ( DABでコード化 ) ルートフォルダ以下のアセット (ソースコード含む) ＋ パイプライン 開発環境 GitHub等のリモートリポジトリ パイプライン設定 ( DABでコード化 ) ルートフォルダ以下のアセット (ソースコード含む) ＋ パイプライン 本番環境 同期 コード編集 設定変更 パイプライン設定 ( DABでコード化 ) ルートフォルダ以下のアセット (ソースコード含む) 設定も一致
106. LDP + DAB の標準ディレクトリ構成 LDPルートフォルダ以下のコードと、DABのコードを同じリポジトリで管理 ルートフォルダ (パイプライン名と同じ ) ソースコードフォルダ transformations explorations utilities my_pipeline.yml my_job.yml databricks.yml Gitフォルダ resources 開発/本番等の環境によって異なるパラメータを定義 パイプライン設定を yamlコード化したもの ジョブ化する場合はこちらも作成 LDPルートフォルダ以下のコード (+ ジョブ化する場合はその DABファイル等も加える ) DABのファイル
107. 外部システムへのデータ連携
108. 外部の読み取りクライアントとの互換性 LakeFlowで加工したデータはDatabricks以外のツールからも読み取り可能 外部のDelta/Icebergリーダー向け に、あらゆるLakeflow宣言型パイプラ インのデータセットをクローン ダウンストリームシステムとの互換性 のための手動でのエクスポートが不 要に Lakeflow Declarative Pipelines
110. Appendix
111. ノートブック データ分析、ETL、機械学習、アプリ開発まで行える万能インターフェイス マルチ言語対応 SQL / Python / R / Scala リアルタイム共同編集 柔軟なクラスター管理 処理や負荷に応じたスペック選択 サーバーレスオプション 開発者フレンドリー 生成AIアシスタントによる支援、 自動履歴保存、Git連携、 変数の表示、デバッグ etc. 機能紹介 1/6
112. ジョブ ノートブックをはじめとした 様々な処理をジョブとして実行可能 多様なタスク ノートブック、SQL、Python、JAR、DLT、 dbt Core、ダッシュボード、Power BIなど 機能紹介 2/6 多様なトリガー スケジュール、ファイル到着、 テーブル更新、手動 (GUI/CLI/API/SDK) 柔軟なジョブ定義 パラメーター渡し、他のジョブ呼び出し、 制御 (If-Else/For-Each) 低コスト クラスター実行料金以外の追加料金なし
113. SQLウェアハウス 高性能・低コストなSQLとBIの実行基盤 SQL & 組み込みの BI SQLエディタ、SQLノートブック、 ダッシュボード、Genieの実行基盤 主要BIツールからの接続性 Power BI / Tableau / Looker etc. JDBC / ODBC接続をサポート アドバンスドな機能 ユーザー定義関数 / AI (LLM) 関数 フェデレーションクエリ(Snowflake / BigQuery / Redshift / 各種RDB etc.) 機能紹介 3/6
114. 機械学習 実験から本番運用まで MLOpsをワンストップで実現 ライフサイクル管理 実験管理、モデル管理、サービング、 モニタリングまで一気通貫でサポート リアルタイム推論 本番環境グレードのサーバーレスの リアルタイム推論エンドポイント LLM機能 カスタムLLMの構築・Fine Tuning AIエージェントの開発から評価まで 機能紹介 4/6 AutoML ノーコードで迅速なモデル開発 生成されたノートブックでさらに改善
115. Databricks Apps セキュアなデータ & AIアプリを 迅速に構築 機能紹介 5/6 シンプルにアプリを構築可能 使いなれたPythonフレームワークを用いて アプリを素早く構築、実行できる。用意されたPython テンプレートから選択も可能 本番環境対応 Gitバージョン管理、CI/CDサポートにより 本番環境対応のアプリケーションを実行可能 セキュリティとガバナンス Unity Catalog、OIDC/OAuth 2.0とSSOによる セキュアなユーザー認証を提供
116. Agent Bricks (ベータ) ローコードでAIエージェントを構築 AIエージェント作成 Databricksの機能やLLMと連携し一般的な AIユースケース向けのドメイン固有の AIエージェントシステムを作成可能 シンプルなローコード ドメイン固有のAIエージェントシステムを 簡単に構築・最適化できる環境を提供 技術的な実装の複雑を軽減 機能紹介 6/6 Databricks上に構築 セキュリティやガバナンス、データ取込、 ベクトル検索、品質評価などDatabricksの 各種機能とシームレスに連携
117. 参考：ノートブック vs ファイル Declarative Pipelines のソースコードにはファイルの利用を推奨 Q. Declarative Pipelines のコードをノートブックに記述し、パイプラインとして実行することは 可能か？ A. 可能。ただし、Declarative Pipelinesではノートブック本来の利点であるセル毎の実行、インタ ラクティブな実行等ができないため、ノートブックを使用する意義が薄い。 Q. ファイルでしか出来ない操作、機能はあるか？ A. ファイル単位での実行 はノートブックの場合は実行できない。また、ソースコードフォルダ内で 新規ファイルを作成する際にはノートブックは直接作成できず 、ソースコードフォルダ外で一度 ノートブックを作成してからソースコードフォルダ内に移動するといった余計な操作が必要となって しまう。
118. 参考：ノートブック vs ファイル Declarative Pipelines のソースコードにはファイルの利用を推奨 新規ファイル の作成 ソースコードフォルダ内 では Notebookが直接作成できない ソースコードフォルダ外 ではNotebookも作成できるが、パイプラインとして 実行するにはソースコードフォルダを移動させる必要がある ファイル単位 での実行 ファイルの場合、 単体での実行が可能 ノートブックの場合、 セル単位や単一ノートブックのみでの実行はできない
119. Onceオプションによるバックフィルのメリット • 分離の原則 ：通常処理とバックフィル処理は取り込 みや加工方法が異なる場合が多いため、明確に区 別した方が管理しやすい。 • 監査証跡 ：パイプラインのグラフとコードにはバック フィルフローの明確な監査証跡が残る。 • 処理最適化 ：大規模なバックフィルフローを複数に分 割し、並列化することが非常に容易。 Onceオプションとは？ • onceオプションを trueにしたフローは、「正確に 1度だ け実行される」 • パイプラインをフルリフレッシュ (全データの再処理 ) を行った場合も 1回だけ実行される “once” オプションでバックフィルを容易に 通常の処理フローと異なるフローも統合管理 バックフィルが必要になる典型的なケース • 上流データソースの データ品質問題 により、データの一部を再処理する • 今まで扱っていなかった 過去データを一括で取り込みたい • データの加工 /分析要件が変更 され、今後のデータだけでなく、これまで処 理済みのデータも遡及的に再処理したい @dp.append_flow(once = true) def backfill_flow(): return ( spark.read….. )
120. 不正データの修正 (顧客マスター欠落 ) 上流データベース担当との確認と、正しい変更履歴の入手 顧客情報を管理している上流データベースの担当者に確認したところ、 最新の顧客の変更履歴ファイルから欠落したデータがあったことが判明しました。 欠落したデータを翌日の変更履歴ファイルにマージしてもらうこともできますが、 分析者がいるビジネス部門からの要望で、それを待たずにすぐ正常なデータを 提供することにしました。 そこで欠落データだけが入った追加の変更履歴ファイルを 上流DBの担当者から受領し、以下のディレクトリに格納しました。 “/Volumes/{カタログ名 }/{スキーマ名 }/raw_data/users_backfill/”
121. 顧客マスターを取り込む通常のフローには触らず、 バックフィル専用のフローをonce=trueで追加する。 Auto CDC による差分更新のフローを作る 顧客マスターの取り込み（ファイル名：backfill_users.py） 顧客マスター (users) ストリーミングテーブル パイプライン 上流データソース 顧客マスター 変更情報 顧客マスター 変更情報 (追加) クラウドストレージ A クラウドストレージ B バックフィルフロー
122. 顧客マスターのバックフィルを実行・結果確認 バックフィルフローの高度を作成したら、　　　　　　で実行してください。 今度は処理は成功し、追加のレコードが各テーブルに出力されます。
123. • ワークショップで使用可能なワークスペースの準備 (既存でもOK) • 使用するワークスペースのプレビュー機能管理画面から、以下のプレビュー機能を有効化。 ◦ Lakeflow Jobs UI ◦ Lakeflow Pipelines Editor • ワークショップ用のカタログを 1つ作成 。参加者全員で1つのカタログを共有する想定。カタログ作成時は、 Storage Locationに対し て参加者が使用して良い外部ロケーションを設定する。 (参加者個々でスキーマを作成する際、外部ロケーションの作成が必要とな ることを避けるため) • ワークショップ参加者のユーザー作成 • ワークショップ参加者を使用するワークスペースへ割り当て、以下のエンタイトルメントを付与 ◦ Workspace access ◦ Databricks SQL access ◦ Unrestricted cluster creation • ワークショップ参加者に対し、以下の権限を付与 ◦ カタログ： CREATE SCHEMA, USE CATALOG • ワークショップ参加者自身によるワークスペースへのログイン確認 管理者様で必要な事前準備