メインコンテンツまでスキップ
に最終更新

Dimensional modeling in Lakeflow pipelines

Dimensional modeling is a technique for organizing your gold-layer data into fact tables and dimension tables so that analysts and business intelligence (BI) tools can query it efficiently. This page explains how to build that model with Lakeflow pipelines.

Overview​

Dimensional modeling separates data into two kinds of tables:

  • ファクトテーブル は、注文、クリック、売上など、関心のあるイベントや測定値を保持します。各行はそのイベントの1回の発生を表し、主にキーと数値メジャーによって記述されます。
  • ディメンションテーブル は、顧客、製品、日付など、それらのイベントに関する記述的なコンテキストを保持します。各行は1つのビジネス・エンティティです。

A star schema is the shape you get when you place one fact table in the middle and join it out to several dimension tables through their keys. The layout is easy for analysts and BI tools to query and easy for engineers to reason about, because each table has a single, clear responsibility.

In LakeFlow Pipelines、スタースキーマはメダリオンアーキテクチャのゴールドレイヤーに自然に適合します。ブロンズおよびシルバーのデータセットが取り込みとクレンジングを処理し、ゴールドがファクトテーブルとディメンションテーブルをマテリアライズするため、ダウンストリームのコンシューマーはそれらを直接クエリーできます。パイプラインがそれらのテーブルを増分的に最新の状態に保つため、BI レイヤーで個別の抽出、変換、ロード（ETL）ステップを実行することなく、スタースキーマのクエリーのシンプルさを実現できます。

仕組み​

パイプライン内でディメンションとファクトをデータセットとして構築し、それぞれの変更方法に一致するデータセットタイプを選択します。ほとんどのゴールドレイヤーモデルの場合：

  • ディメンションテーブル をマテリアライズドビューとして構築します（履歴が必要な場合は、SCD（緩やかに変化するディメンション）タイプ2を使用したストリーミングテーブルとして構築します）。マテリアライズドビューは、入力の変更に応じてクリーンアップされたシルバーデータから効率的に再計算を行い、ビジネスエンティティごとに1行を提供します。
  • Build fact tables as streaming tables fed incrementally from silver, so gold-layer aggregates stay close to real time. Facts reference their dimensions by key rather than duplicating descriptive attributes.

2つのデータセットタイプの詳細については、マテリアライズドビューおよびストリーミングテーブルを参照してください。ディメンションの履歴を追跡するには、「AUTO CDC APIs : パイプラインによる変更データ キャプチャの簡素化」を参照してください。

キーと代理キー​

ソースの ナチュラルキー （注文番号など、ソースデータにすでに存在する識別子）が安定して使用可能な場合は、クラスタリングや結合に適しているため、ナチュラルキーの使用を優先してください。ソースがIDを再利用または変更する場合にのみ、 サロゲートキー （パイプラインで生成された代用識別子）を使用してください。

代理キーが必要な場合は、sha2(natural_key) のような ハッシュ 代理キーの使用は避けてください。ハッシュは意図的にランダム化されるため、リキッドクラスタリングやZ-Orderのパフォーマンスには悪影響を及ぼします。物理的に隣接する行が複数のファイルに分散してしまうためです。代わりに、安定したナチュラルキーから順序を保持する代理キーを決定論的に導出することで、同じビジネスエンティティが常に同じ代理キーにマッピングされるようにします。決定論的なキーは、ディメンションの完全更新や再構築後も保持されるため、既存のファクトテーブルとディメンションテーブル間の結合が維持されます。

あるいは、アップストリームテーブルが追加専用で、完全更新が一度も行われない場合は、IDENTITY列を使用できます。IDENTITYの値は行が挿入される際に割り当てられるため、リビルドによって同じエンティティに異なるIDが再割り当てされ、古い値を保持していたファクト・ディメンション間の結合が警告なしに破損する可能性があります。

日付ディメンション​

Build a dim_date as a simple materialized view generated with sequence() and explode() over a date range, rather than ingesting it from a source. It's static reference data, cheap to compute, and it simplifies date-based joins and windowing everywhere else in the model.

Examples​

以下の例では、顧客ディメンションと注文ファクトテーブルを使用して、小さなスタースキーマを構築します。

ディメンションテーブル​

A dimension table is typically a materialized view built from cleaned silver data, with one row per business entity, as in the following code:

Python
from pyspark import pipelines as dp

@dp.materialized_view(name="dim_customer", comment="Customer dimension")
def dim_customer():
    return (
        spark.read.table("customers_silver")
        .select("customer_id", "customer_name", "region", "signup_date")
    )

ファクトテーブル​

A fact table holds the measurable events, referencing dimensions by their keys rather than duplicating descriptive attributes. Keep facts narrow (mostly keys and numeric measures) and use joins to pull in descriptive detail at query time, as in the following code:

Python
from pyspark import pipelines as dp

@dp.table(name="fact_orders", comment="One row per order line, keyed to dimensions")
def fact_orders():
    return (
        spark.readStream.table("orders_silver")
        .select(
            "order_id",
            "customer_id",       # foreign key to dim_customer
            "product_id",        # foreign key to dim_product
            "order_date",        # foreign key to dim_date
            "quantity",
            "amount",
        )
    )

Best practices​

スター型スキーマが健全に成長していくためには、いくつかの実践方法があります。

  • 変更履歴が特に必要な場合を除き、 ファクトはストリーミングテーブルとして、ディメンションはマテリアライズドビューとして保持してください 。変更履歴が必要な場合は、AUTO CDC と STORED AS SCD TYPE 2 を使用してください。「AUTO CDC APIs : パイプラインによるチェンジデータキャプチャの簡素化」を参照してください。
  • Use downstream BI tools to query gold materialized views directly. Lakeflow pipelines keep them incrementally refreshed, so you get near-real-time results without a separate reporting ETL step.
  • Model dimensions and facts as separate flows into the same gold layer , so each dataset can be scheduled, checkpointed, and refreshed as part of one coherent DAG. See Load and process data incrementally with Lakeflow pipeline flows.

その他のリソース​

このページの見出し