ディメンションETLワークフローの構築
によって Lorenz Verzosa, クリシュナ・サティアバラプ, Peyman Mohajerian, ジェシー・ヘラヴィ 、 ブライアン・スミス（Bryan Smith） による投稿
Archived. This article has not been updated since the publish date above. The dynamic nature of information means that previously accurate content can become outdated or even obsolete over time. Readers are advised to exercise due diligence and cross-check any information found in this blog post before making decisions or adopting any practices based on said information.
組織が分析ワークロードをDatabricksに統合する際、従来のデータウェアハウスの手法を適応する必要がよくあります。このシリーズでは、Databricks上でのディメンションモデリング、特にスタースキーマの実装方法を探ります。最初のブログではスキーマ設計に焦点を当てました。このブログでは、ディメンションテーブルのETLパイプライン、特にSlowly Changing Dimensions (SCD) Type-1およびType-2パターンを説明します。最後のブログでは、ファクトテーブルのETLパイプラインの構築方法を示します。
前回のブログで、私たちはスタースキーマを定義し、ファクトテーブルとそれに関連するディメンションを含めました。特に、DimCustomerというディメンションテーブルを強調しました（スペースを節約するために一部の属性を削除して表示しています）：
このテーブルの最後の3つのフィールド、つまり、StartDate、EndDateおよびIsLateArrivingは、レコードのバージョニングを支援するメタデータを表しています。顧客の収入、結婚状況、住宅所有、家庭内の子供の数、その他の特性が変化すると、その顧客の新しいレコードを作成したいと考えます。これにより、FactInternetSalesなどのオンライン販売取引のファクトが、その顧客の正しい表現と関連付けられます。これらのレコードでは、自然（ビジネス）キーであるCustomerAlternateKeyは同じままですが、メタデータは異なり、その顧客のバージョンが有効だった期間を知ることができます。また、代理キーであるCustomerKeyも異なり、ファクトが正しいバージョンにリンクすることができます。
注：代理キーはファクトとディメンションをリンクするために一般的に使用されるため、ディメンションテーブルはこのキーに基づいてクラスタ化されることがよくあります。ソートされたレコードにb-treeインデックスを利用する従来のリレーショナルデータベースとは異なり、Databricksはリキッドクラスタリングという独自のクラスタリング方法を実装しています。リキッドクラスタリングの詳細はこのブログの範囲外ですが、ディメンションテーブルの定義中に常に代理キーにCLUSTER BY句を使用して、この機能を効果的に活用します。
属性が変化するたびにディメンションレコードをバージョニングするこのパターンは、タイプ2の緩やかに変化するディメンション（または単にタイプ2 SCD）パターンとして知られています。タイプ2 SCDパターンは、クラシックなディメンショナル方法論でディメンションデータを記録するための優先的なパターンです 。しかし、ディメンションレコードの変更を扱う他の方法もあります。
ディメンション値の変更を処理する最も一般的な方法の一つは、既存のレコードをその場で更新することです。レコードのバージョンは一つだけ作成されるため、ビジネスキーがレコードの一意の識別子として残ります。パフォーマンスや一貫性などの理由から、私たちは代替キーを実装し、ファクトレコードをこれらのディメンションにそのキーでリンクします。それでも、開始日と終了日というメタデータフィールドは、特定のディメンションレコードがアクティブと見なされる時間間隔を記述するためには必要ありません。これはType-1 SCDパターンとして知られています。私たちのスタースキーマにおけるプロモーションディメンションは、Type-1ディメンションテーブルの実装の良い例を提供しています：
しかし、IsLateArrivingというメタデータフィールドは、Type-2のDimCustomerにはありますが、Type-1のDimPromotionにはありません。このフィールドは、レコードが遅延して到着したことを示すために使用されます。 遅延到着レコードは、ファクトETLサイクル中にビジネスキーが表示されるが、以前のディメンション処理中にそのキーのレコードが見つからないというものです。 Type-2 SCDの場合、このフィールドは、遅延到着レコードのデータが初めてディメンションETLサイクルで観察されたときに、レコードがその場で更新され（Type-1 SCDパターンと同様）、その後からバージョン管理されることを示すために使用されます。 Type-1 SCDの場合、このフィールドは必要ありません。なぜなら、レコードはどのような場合でもその場で更新されるからです。
注：Kimball Groupは、Type-1とType-2のパターンのバリエーションと組み合わせを含む、追加のSCDパターンを認識しています。Type-1とType-2のSCDは、これらのパターンの中で最も頻繁に実装され、他のものとの関連性が密接であるため、このブログではこれら二つのディメンションタイプに限定しています。Kimball Groupが認識する8種類のSCDについての詳細は、Slowly Changing Dimension Techniquesセクションを参照してください。このドキュメント。
データがインプレースで更新されるため、タイプ1 SCDワークフローパターンは2次元ETLパターンの中で最も単純です。これらのディメンションをサポートするには、以下の手順に従います。
タイプ1 SCDの実装を示すために、DimPromotionテーブルの継続的な集計のためのETLを定義します。
最初のステップは、運用システムからデータを抽出することです。