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

Dimensional modeling in LakeFlow Pipelines

次元モデリングは、アナリストやビジネスインテリジェンス（BI）ツールが効率的にクエリーを実行できるように、ゴールドレイヤーのデータをファクトテーブルとディメンションテーブルに整理するための手法です。このページでは、LakeFlow Pipelinesを使用してそのモデルを構築する方法について説明します。

概要​

次元モデリングでは、データを次の2種類のテーブルに分離します：

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

スタースキーマ とは、中央に 1 つのファクトテーブルを配置し、キーを介して複数のディメンションテーブルに結合した形状のことです。各テーブルが単一の明確な責任を持つため、アナリストや BI ツールがクエリーを実行しやすく、エンジニアが論理的に理解しやすいLayoutになっています。

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

仕組み​

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

  • ディメンションテーブル をマテリアライズドビューとして構築します（履歴が必要な場合は、SCD（緩やかに変化するディメンション）タイプ2を使用したストリーミングテーブルとして構築します）。マテリアライズドビューは、入力の変更に応じてクリーンアップされたシルバーデータから効率的に再計算を行い、ビジネスエンティティごとに1行を提供します。
  • ファクトテーブル は銀から段階的に供給されるストリーミングテーブルとして構築し、ゴールドレイヤーの集計がほぼリアルタイムに保たれます。事実は、記述的な属性を重複させるのではなく、キーによってその次元を参照する。

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

キーと代理キー​

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

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

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

日付ディメンション​

dim_dateを、日付範囲のsequence()とexplode()で生成するシンプルなマテリアライズドビューとして構築し、ソースから取り込むのではなく。これは静的な参照データで、コンピュートコストも安く、モデル内の日付に基づく結合やウィンドウ作成も簡素化されます。

例​

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

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

ディメンションテーブルは通常、クリーン化されたシルバーデータから構築されたマテリアライズドビューで、事業体ごとに1行ずつ構成されます。以下のコードのように:

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")
    )

ファクトテーブル​

ファクトテーブルには測定可能なイベントが格納され、記述属性を重複させるのではなく、キーによってディメンションを参照します。事実は主にキーと数値指標で絞り、クエリー時に記述的な詳細を引き出すためにジョインを使ってください。以下のコードのように:

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",
        )
    )

ベストプラクティス​

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

  • 変更履歴が特に必要な場合を除き、 ファクトはストリーミングテーブルとして、ディメンションはマテリアライズドビューとして保持してください 。変更履歴が必要な場合は、AUTO CDC と STORED AS SCD TYPE 2 を使用してください。「AUTO CDC APIs : パイプラインによるチェンジデータキャプチャの簡素化」を参照してください。
  • 下流のBIツールを使って、ゴールドのマテリアライズドビューmaterialized viewを直接クエリーqueryしましょう。 Lakeflow pipelinesは段階的にリフレッシュされるため、個別の報告ETLステップなしでほぼリアルタイムの結果が得られます。
  • ディメンションとファクトを個別のフローとして同じゴールドレイヤーにモデル化 することで、各データセットを1つの整合性のあるDAGの一部としてスケジュール、チェックポイント設定、および更新できるようにします。LakeFlow Pipelinesを使用したデータの増分読み込みと処理を参照してください。

その他のリソース​

このページの見出し