Data Driven Knowledgebase

今回は、Dataikuでデータパイプラインの出力が期待通りかどうかを検証するための2つの機能、Integration Test（統合テスト）とDataset Schema Equals（DQルール）について、わかりやすく解説していきたいと思います。

データパイプラインを運用していると、「レシピをちょっと変えたら下流のデータが壊れていた」「カラムの型がいつの間にか変わっていた」といった問題に遭遇することがあります。こうしたリスクに対処するために、Dataikuには出力の一致性を検証するための仕組みが用意されています。

なぜ出力一致検証が必要なの？

Dataikuのプロジェクトでは、Flowの中に多数のレシピやデータセットが連なっています。どこか1箇所の変更が、下流のデータセットに予期しない影響を及ぼす可能性があります。本番環境にデプロイする前に「出力が変わっていないこと」を確認できれば、安全にリリースを進められます。

この検証には大きく分けて2つのアプローチがあります。

 

それぞれ異なる部分での検証を担っており、組み合わせて使うことで堅牢なデータ品質管理が実現できます。

Integration Test（統合テスト）

Integration Testは、Dataikuのシナリオステップとして提供されている非回帰テスト機能です。以下の3ステップで動作します。

1. Flowの入力データセットを、あらかじめ用意したリファレンス入力データセットに差し替える


2. 指定したデータセットをビルドして、新しい出力を生成する


3. 生成された出力をリファレンス出力データセットと比較する

つまり「既知の入力を与えたとき、既知の出力が得られるか？」を自動で検証してくれる仕組みです。設定ではReference inputs（入力の差し替え）、Builds（ビルド対象）、Results validation（出力の比較）の3要素を指定します。比較は全カラム対象にも、特定カラムだけに絞ることも可能です。

以下は、Integration Testステップの設定画面です。Reference inputsで入力の差し替え、Buildsでビルド対象、Results validationで出力の比較先をそれぞれ指定しています。

テストを実行すると、各処理の結果がステップごとに表示されます。以下の例では、入力データセットの差し替え・ビルドは成功していますが、最終的な出力比較（revenue_loss と test_reference_revenue_loss の比較）でエラーが検出され、テストが失敗しています。

注意点として、リファレンスデータセットは処理パターンを十分にカバーするよう意図的に設計することが重要です。また、Pythonレシピではテーブル名をハードコードするとテスト時の差し替えが機能しないため、dataiku.Dataset("DATASET_NAME")経由で名前を取得する必要があります。

---

Dataset Schema Equals（DQルール）

Dataset Schema Equalsは、DataikuのData Quality（DQ）ルールの一つで、データセットのスキーマが期待通りの構造かを検証します。あらかじめ定義した「期待スキーマ」と実際のスキーマを比較し、以下の項目を厳密にチェックします。

• カラムの存在：欠落があればエラー


• カラムの型：complex型（array、map等）はサブフィールドまで再帰的にチェック


• カラムの意味（Meaning）：”Any”に設定すればスキップも可能


• カラムの順序：並び順が異なればエラー


• 予期しないカラム：期待スキーマにないカラムがあればエラー


• 文字列の最大長：string型はデフォルト”-1″（無制限）でチェック

以下は、Dataset Schema Equalsルールの設定画面です。期待スキーマとしてカラム名・型・Meaningが一覧表示されており、「RUN TEST」ボタンでテストを実行した結果、現在のスキーマが期待通りであることを示す「OK」が返されています。

順序を問わず「特定カラムが含まれるか」だけを確認したい場合は、別途Dataset Schema Containsルールが使えます。また「Reset to current schema」ボタンで、現在のスキーマをワンクリックで期待スキーマに取り込むことも可能です。

テストシナリオとしての運用

Dataikuでは、シナリオに「Mark as a test scenario」フラグを立てることで、テスト用シナリオとして管理できます。テストシナリオの実行結果はTest Dashboardに表示され、プロジェクト全体のテスト状況を一覧で確認できます。

運用フローの一例を示します。

STEP 1：入出力データを取得 検証対象のフローを実行し、入力データと出力データを取得します。これが「正解データ」としての基準になります。

STEP 2：DataikuにリファレンスDSとして登録 取得した入出力データをDataikuにアップロードし、リファレンスデータセットとして登録します。Integration Testのリファレンス入力・リファレンス出力、およびDataset Schema Equalsの期待スキーマの元になります。

STEP 3：Dataikuでフローを再構築 対象の処理をDataikuのレシピ（Prepare、Python、SQLなど）で構築します。

STEP 4：統合テスト、Schema Equalsで出力一致を自動検証 構築したフローに対して、Integration Testで出力データの値レベルの一致を検証し、Dataset Schema Equalsでスキーマの構造一致を検証します。これらのステップをテストシナリオ（「Mark as a test scenario」をONにしたシナリオ）にまとめます。

STEP 5：Test Dashboardで検証状況を一元管理 テストシナリオの実行結果はTest Dashboardに集約されます。全テストの成功/失敗がひと目で確認でき、JUnit XMLやHTML形式でレポートを出力することも可能です。

メリットとデメリット

Integration Test

Dataset Schema Equals

両機能の使い分け

Integration Testは「データの中身が正しいか」を、Dataset Schema Equalsは「データの構造が正しいか」を検証します。この2つは補完関係にあり、併用することで「構造も値も変わっていない」ことを多層的に保証できます。

ただし、どちらも連続パラメータの微小な差分（浮動小数点の丸め誤差など）には注意が必要です。Integration Testで数値カラムを比較する場合、許容範囲の設定やカラムの選択を慎重に行う必要があります。

• Integration TestはFlowの出力データを値レベルで検証する非回帰テスト機能


• Dataset Schema Equalsはスキーマの構造一致を検証するDQルール


• 両者を組み合わせることで、構造と値の両面から出力の一致性を保証できる


• テストシナリオとTest Dashboardを活用すれば、プロジェクト全体のテスト状況を可視化できる

データパイプラインの品質を守るためには、「壊れてから気づく」のではなく「壊れる前に検知する」仕組みが不可欠です。Dataikuの出力一致検証機能を活用して、安全なデプロイ運用を目指しましょう。