Databricks DQXとは？PySparkデータ品質検証フレームワークの機能と使い方【2026年最新】

Databricks DQXは、Databricksを開発するチームのオープンソース部門「Databricks Labs」が公開する、PySpark向けのデータ品質フレームワークです。あらかじめ定義した品質ルールでPySparkのDataFrameやテーブルを検証し、条件を満たす「良質なデータ」と満たさない「不良データ」を2つのDataFrameに分離（quarantine）します。パイプラインにデータが書き込まれる前後どちらでも検証でき、どの行のどの列がなぜ違反したかを詳細に記録できる点が特徴です。本記事は2026年7月時点の最新版v0.15.0の実仕様に基づき、DQXの機能・導入手順・採用時の注意点を整理します。

まとめ：Databricks DQXの要点

• DQXはDatabricks Labsが公開するOSSで、PySpark DataFrame／テーブルの品質を検証し、良質データと不良データ（quarantine）に分離する。
• ルールはcriticalityとcheck（function＋arguments）で宣言する。YAMLメタデータでもPythonコードでも定義できる。
• pip install databricks-labs-dqxで導入し、DQEngineのapply_checks_and_splitで検証と分離を実行する。
• プロファイラ（DQProfiler）が既存データを分析し、ルール候補を自動生成する。
• Lakeflow Pipelines（旧Delta Live Tables）やUnity Catalogと統合でき、バッチ・ストリーミング双方に対応する。
• Databricks Labsプロジェクトのため公式SLAは無い。本番の品質ゲートに据えるならバージョン固定と検証を前提に採用する。

以下で定義・従来ツールとの違い・機能・実装手順・注意点の順に見ていきます。

DQXとは：PySparkのデータ品質を検証するDatabricks Labs製OSS

DQXは「databricks-labs/dqx」として公開されているデータ品質フレームワークで、Apache Spark（PySpark）上で動作します。入力DataFrameをあらかじめ定義したルールで検証し、合格データと不合格データを分けて出力するのが基本動作です。不合格データには「どのチェックに」「なぜ違反したか」というメタ情報が付与されるため、原因の特定と修正がしやすくなります。

検証はデータ格納後の事後監視（at-rest）と、書き込み前の事前検証（in-transit）のどちらにも対応します。従来ツールが完成済みデータセットの一括検証を前提としがちだったのに対し、DQXはストリーミングを含むパイプライン処理の途中に組み込める設計になっています。

公開元はDatabricks Labsで、リポジトリは2026年7月時点でスター約430、最新はv0.15.0（2026年6月13日リリース）です。Databricks Labsのプロジェクトは「探索・検証用途」の位置づけで公式のSLAは付かないため、本番採用時はこの前提を踏まえた運用設計が必要になります（注意点は後述）。

従来のデータ品質ツールとの違いとDQXの位置づけ

DQXの独自性は、Databricksネイティブでありながら、パイプラインの内外どちらでも同じルールを使える柔軟さにあります。競合・関連ツールとの位置づけを整理します。

まず、Lakeflow Pipelines（旧Delta Live Tables／DLT）の「expectations」はパイプライン内でのみ機能する品質制約です。DQXはexpectationsと競合するものではなく、パイプラインの外でDataFrameを検証したり、プロファイリング結果からexpectationsの候補を生成したりと、補完的に使えます。パイプラインに縛られず単独のジョブでも検証できる点が、expectations単体との実務上の差になります。

次に、汎用ツールのGreat Expectations等と比べると、DQXはPySpark／Databricksに特化している分、Sparkの分散処理やUnity Catalogとの連携が素直で、行・列レベルの違反理由を細かく残せます。逆に、Databricks外の環境や非Sparkのデータソースを主軸にする場合は、DQXの利点は薄れます。

結論として、Databricks上でパイプラインの内外を横断して品質ゲートを統一したいならDQX、宣言型パイプライン内で完結させたいならexpectations、という使い分けが基本方針になります。

DQXの主な機能：チェック・プロファイラ・criticality

DQXはルール定義から検証・可視化までを一通りカバーします。読者が個別に探しやすいよう機能ごとに整理します。

行レベル・列レベルの品質チェック

チェックは行レベル・列レベルの両方で定義できます。is_not_null（NULL不可）、is_not_null_and_not_empty（NULLも空文字も不可）、is_in_list（許可値のみ）、is_unique（重複不可）といった組み込み関数に加え、集計値を検証するis_aggr_not_greater_thanなどの関数も用意されています。列単位・行単位で同時に検証できるため、違反箇所を絞り込みやすくなります。

プロファイリングによるルール候補の自動生成

「どのルールを作るべきか」を一から設計するのは負担が大きい作業です。DQXはDQProfilerで既存データの統計や分布を分析し、DQGeneratorのgenerate_dq_rulesでルール候補を自動生成します。生成された候補を確認・修正して使えば、初期導入の工数は大きく減る。

quarantineとcriticality（warnとerrorの挙動差）

各チェックには重大度criticalityをwarnかerrorで指定します。errorは違反データを不良（quarantine）側のみに送ります。一方warnの違反行は良質側に残しつつ、記録用にquarantine側にも出力される（＝下流への流入は遮断されない）挙動です。つまりerrorは下流に流さず遮断、warnは流しつつ記録という違いになり、要件に応じて遮断と可視化を使い分けられます。

ML行レベル異常検知

しきい値を手動指定せずにデータ内の異常な行を機械学習で自動検出する、ML行レベルの異常検知も追加されています。明示的なルールを書きにくい未知の異常パターンに対する、補助的な検知手段です。

Unity Catalogとの連携・可観測性

DQXはUnity Catalog管理下のテーブルにも適用でき、検証結果をメタ情報として扱えます。どのテーブルがどの品質基準を満たしているかを追跡し、ダッシュボードで品質状況を可視化することで、ガバナンスと品質管理を結び付けられます。

DQXの導入と実装手順

導入はライブラリのインストールからルール定義、検証実行までの3ステップで進みます。

インストール（%pip／Databricks CLI）

DatabricksのノートブックまたはクラスタにPyPIパッケージを導入します。ノートブックなら次の1行で追加できます。

%pip install databricks-labs-dqx

Databricks CLI経由でワークスペースにツールとしてインストールする方法も用意されています。導入後、DatabricksランタイムとUnity Catalogを利用可能な状態にしておきます。

ルール定義（YAMLメタデータとPythonコード）

ルールはcriticalityとcheck（functionとarguments）で宣言します。旧来の資料にあるrule_typeやerror_levelという記法は現行の形式ではないため注意してください。YAMLメタデータで書く場合は次の形になります。

- criticality: error
  check:
    function: is_not_null
    arguments:
      column: user_id
- criticality: warn
  check:
    function: is_not_null_and_not_empty
    arguments:
      column: email

同じ内容をPythonコードで型付きに定義することもできます。CI／CDでレビューやテストに載せたいならYAML、複雑な条件ロジックを組みたいならコード、と用途で選べます。

チェックの適用とGood／Quarantineの分離

定義したチェックはDQEngineで適用します。コード定義のルールはapply_checks_and_split、YAML等のメタデータ定義はapply_checks_by_metadata_and_splitを使い、良質データと不良データの2つのDataFrameに分離します。

from databricks.labs.dqx.engine import DQEngine
from databricks.labs.dqx.rule import DQRowRule
from databricks.labs.dqx import check_funcs
from databricks.sdk import WorkspaceClient

dq_engine = DQEngine(WorkspaceClient())

checks = [
    DQRowRule(
        criticality="error",
        check_func=check_funcs.is_not_null,
        column="user_id",
    ),
]

input_df = spark.read.table("catalog.schema.input")
valid_df, quarantine_df = dq_engine.apply_checks_and_split(input_df, checks)

分離後は、valid_dfを下流の本番テーブルへ、quarantine_dfを隔離用テーブルへ書き込む構成が基本です。隔離データは違反理由を確認して修正し、再検証のうえ本番へ戻す運用にすると、不良データの伝播を防ぎつつ復旧経路を確保できます。

Lakeflow（旧DLT）・レイクハウスとの統合

DQXはDatabricksのレイクハウス基盤に組み込んで使うことを想定しています。Lakeflow Pipelines（旧Delta Live Tables）とは、DQXで定義・生成したルールをexpectationsとして適用する形で連携でき、宣言型パイプラインの中で品質検証を自動化できます。

ストレージ面ではDelta Lakeのテーブルに対して検証を実行でき、バッチ処理と構造化ストリーミングのどちらでも同じチェックを適用できます。KafkaやオブジェクトストレージなどSparkから読めるソースであれば、入力元が変わっても検証処理を差し込むだけで品質を担保できます。Unity Catalog上の資産管理と組み合わせれば、ブロンズ層で粗い検証、ゴールド層で最終保証といった多段の品質ゲートも構築できます。

DQXを採用する前に押さえる注意点

DQXは有用ですが、無条件に基幹へ据えるべきツールではありません。採用判断で確認すべき点を挙げます。

第一に、DQXはDatabricks Labsのプロジェクトであり、公式のSLAやフォーマルなサポートは付きません。GitHubのイシューでベストエフォートに対応される位置づけです。本番の品質ゲートに使うなら、利用バージョンを固定し、自前のテストで挙動を確認し、障害時の代替手段を用意したうえで採用すべきで、未検証のまま基幹パイプラインを丸ごと依存させるのは避けるべきです。

第二に、バージョンは0.x系で進化が速く、APIやチェック関数の仕様が更新されることがあります。導入時はバージョンを固定し、アップグレード時にはリリースノートで破壊的変更を確認してください。最新の関数一覧や引数は公式ドキュメントで確認するのが確実です。

第三に、DQXはPySpark／Databricksを前提とします。Databricks外や非Sparkのデータ処理が主軸なら、Great Expectationsなど別ツールの方が適合するケースがあります。既存基盤がDatabricksに寄っているかどうかが、DQX採用の実質的な分かれ目になります。

よくある質問

Databricks DQXは無料で使えますか？

DQX自体はオープンソースで、PyPIから無償で導入できます。ただし実行にはDatabricks（Apache Spark）環境が必要で、その計算リソースの費用は別途かかります。

DQXとDelta Live Tables（Lakeflow）のexpectationsはどちらを使うべきですか？

宣言型パイプライン内で品質制約を完結させたいならexpectations、パイプラインの内外を横断して同じルールを使い、不良データをquarantineで分離・分析したいならDQXが向きます。両者は補完的で、DQXでexpectationsの候補を生成する使い方もできます。

ルールをゼロから作らずに始められますか？

できます。DQProfilerで既存データをプロファイリングし、DQGeneratorでルール候補を自動生成できます。候補を確認・調整してから運用に載せることで、初期設計の負担を減らせます。

ストリーミングデータにも使えますか？

使えます。Spark構造化ストリーミングに対応しており、マイクロバッチごとに検証を実行して異常データを即時に隔離できます。バッチとストリーミングで同じチェック定義を再利用できます。

本番システムの品質ゲートに採用して問題ありませんか？

Databricks LabsプロジェクトでSLAが無い点を踏まえた運用が前提です。バージョン固定・自前テスト・障害時の代替経路を用意すれば実運用に組み込めますが、未検証での基幹依存は避けるべきです。

関連記事

• Databricksとは何か？プラットフォームの概要と歴史
• Azure Databricksにおけるサーバーレス コンピューティングの種類
• Apache Icebergの概要と基本的な定義
• Omnigentとは：Databricks発OSSのメタハーネスでAIエージェントを統合・制御する新レイヤー