ビッグ データの時代には、メダリオン アーキテクチャは、生データから高度にキュレーションされたデータセットまで、さまざまな段階でデータを管理および処理するための堅牢なフレームワークとして目立つようになった。 この構造化されたアプローチにより、データの管理性が向上するだけでなく、データのライフサイクル全体にわたってデータ品質が維持されます。
情報に基づくビジネス上の意思決定を行うには、medallion アーキテクチャのすべての段階でデータ品質の確保が不可欠です。 データ品質が低いと、間違った分析情報や運用上の非効率性が生じる可能性があります。
この記事では、Microsoft Fabric の具体化された湖のビュー (MLV) にデータ品質を実装する方法について説明します。
データ品質を実装する
データを変換するときは、ソース テーブルから品質の低いデータを除外する正確なクエリを作成することが重要になります。これにより、処理時間が長くなり、小さなデータの問題が原因でパイプライン全体が失敗する場合があります。
データ品質は、MLV を定義するときに制約を設定することによって維持されます。 Fabric 内の具体化されたビューは、データ品質管理のチェックを効率的に実装するアプローチを提供します。
制約が指定されている場合は、次のアクションを実装できます。
FAIL – このアクションは、制約に違反すると MLV の更新を停止し、最初のインスタンスで停止します。 FAIL キーワードを指定しなくても、これは既定の動作です。
DROP – このアクションは MLV を処理し、指定された制約を満たしていないレコードを削除します。 また、系列ビューで削除されたレコードの数も提供します。
注
DROP アクションと FAIL アクションの両方が MLV で定義されている場合、FAIL アクションが優先されます。
具体化されたレイク ビューでのデータ品質チェックの定義
次の例では、cust_blank フィールドが null でないかどうかをチェックする制約customerNameを定義します。 null customerName を持つ行は、処理から除外されます。
CREATE MATERIALIZED LAKE VIEW IF NOT EXISTS silver.customers_enriched
(CONSTRAINT cust_blank CHECK (customerName is not null) on MISMATCH DROP)
AS
SELECT
c.customerID,
c.customerName,
c.contact,
CASE
WHEN COUNT(o.orderID) OVER (PARTITION BY c.customerID) > 0 THEN TRUE
ELSE FALSE
END AS has_orders
FROM bronze.customers c LEFT JOIN bronze.orders o
ON c.customerID = o.customerID;
現在の制限
- MLV の作成後のデータ品質制約の更新はサポートされていません。 データ品質制約を更新するには、MLV を再作成する必要があります。
- 制約条件での LIKE や regex などの演算子での関数およびパターン検索の使用は制限されています。
既知の問題
- 制約内の FAIL アクションを使用して MLV を作成および更新すると、"デルタ テーブルが見つかりません" という問題が発生する可能性があります。 このような場合は、MLV を再作成し、FAIL アクションを使用しないようにすることをお勧めします。