次の方法で共有


バッチまたはストリーム処理によるデータのクリーンと検証

データのクリーンと検証は、レイクハウス内のデータ資産の品質を確保するために不可欠です。 この記事では、データ品質を支援するために設計された Azure Databricks オファリングの概要と、カスタム ルールを実装するビジネス ロジックを定義するための推奨事項について説明します。

Azure Databricks でのスキーマの適用

Delta Lake は、書き込み時にスキーマと制約のチェックを適用するセマンティクスを提供し、これにより、レイクハウス内のテーブルのデータ品質が保証されます。

スキーマの適用により、テーブルに書き込まれるデータが事前定義されたスキーマに準拠することが保証されます。 スキーマ検証規則は操作によって異なります。 「スキーマの適用」を参照してください。

スキーマの進展を扱うために、Delta にはスキーマを変更してテーブルを進展させるためのメカニズムが用意されています。 フィールドの削除やパイプラインの失敗を避けるために、スキーマ進展をいつ使うかを慎重に検討することが重要です。 手動または自動でスキーマを更新する方法の詳細については、「テーブル スキーマの 更新」を参照してください。

テーブル制約

制約は、情報主キーおよび外部キー制約、または強制制約の形式を取ることができます。 ADD CONSTRAINT の条項を参照してください。

Azure Databricks のテーブル制約は、"強制" か "情報" のいずれかです。

強制される制約には、NOT NULL 制約と CHECK 制約が含まれます。

情報制約には、主キー制約と外部キー制約が含まれます。

Azure Databricks の制約」を参照してください。

null または欠損値を処理する

NOT NULL は Delta テーブルに適用できます。 これは、既存のテーブルで列内の既存のレコードが null でない場合にのみ有効にすることができ、null 値を持つ新しいレコードがテーブルに挿入されるのを防ぎます。

パターンの強制

正規表現 (regex) を使うと、データ フィールドに予期されるパターンを強制できます。 これは、特定の形式やパターンに従う必要があるテキスト データを扱う場合に特に便利です。

正規表現を使ってパターンを強制するには、SQL で REGEXP または RLIKE 関数を使用できます。 これらの関数を使うと、データ フィールドを指定された正規表現パターンに対して照合できます。

SQL でパターンを適用するために正規表現で CHECK 制約を使用する方法の例を次に示します。

CREATE TABLE table_name (
  column_name STRING CHECK (column_name REGEXP '^[A-Za-z0-9]+$')
);

値の強制

制約を使って、テーブル内の列に値の範囲を強制できます。 これにより、指定された範囲内の有効な値のみが挿入または更新できるようになります。

値の範囲制約を強制するには、SQL で CHECK 制約を使用できます。 CHECK 制約を使うと、テーブル内のすべての行に対して true でなければならない条件を定義できます。

CHECK制約を使用して列に値範囲を適用する方法の例を次に示します。

CREATE TABLE table_name (
  column_name INT CHECK (column_name >= 0 AND column_name <= 100)
);

Lakeflow Spark 宣言パイプラインを使用して、期待値を定義および構成します。

Lakeflow Spark 宣言型パイプラインを使用すると、具体化されたビューまたはストリーミング テーブルを宣言するときの期待値を定義できます。 期待値を構成して、違反について警告するか、違反レコードを削除するか、または違反に基づいてワークロードを失敗させるかを選択できます。 パイプラインの期待を使用してデータ品質を管理する方法については、を参照してください。

データの監視

Azure Databricks は、アカウント内のすべてのテーブルのデータの統計プロパティと品質を監視できるデータ品質監視サービスを提供します。 データ プロファイルを参照してください。

キャスト データ型

テーブルにデータを挿入または更新するとき、情報を失わずに安全に実行できる場合、Azure Databricks はデータ型をキャストします。

キャスト動作の詳細については、次の記事を参照してください。

カスタム ビジネス ロジック

フィルターと WHERE 句を使って、不適切なレコードを検疫し、ダウンストリーム テーブルに反映されないようにするカスタム ロジックを定義できます。 CASE WHEN ... OTHERWISE 句を使うと、条件付きロジックを定義して、予測可能な方法で期待に反するレコードにビジネス ロジックを適切に適用できます。

DECLARE current_time = now()

INSERT INTO silver_table
  SELECT * FROM bronze_table
  WHERE event_timestamp <= current_time AND quantity >= 0;

INSERT INTO quarantine_table
  SELECT * FROM bronze_table
  WHERE event_timestamp > current_time OR quantity < 0;

Databricks では、特に構造化ストリーミングを使う場合は、フィルター処理されたデータを常に個別の書き込み操作として処理することをお勧めしています。 .foreachBatch を使って複数のテーブルに書き込むと、一貫性のない結果が生じる可能性があります。

たとえば、 NULL 値をエンコードできないアップストリーム システムがあり、不足しているデータを表すためにプレースホルダー値 -1 使用される場合があります。 Azure Databricks のすべてのダウンストリーム クエリに対して、-1 を含むレコードを無視するカスタム ロジックを作成するのではなく、case when ステートメントを使ってこれらを変換として動的に置き換えることができます。

INSERT INTO silver_table
  SELECT
    * EXCEPT weight,
    CASE
      WHEN weight = -1 THEN NULL
      ELSE weight
    END AS weight
  FROM bronze_table;