データパイプライン用の|dcm|

|dcm|は、データパイプラインの管理に合わせた機能を含む、フルライフサイクルの開発者エクスペリエンスを提供します。

パイプライン固有のコマンドは、すべてのオブジェクトタイプに適用されるわけではありません。これらは、次のようなパイプラインのユースケース向けにコアコマンドを拡張するものです。

  • |dcm-object|が管理する:ref:label-dcm_projects_pipelines_refresh

  • 管理対象のオブジェクトにアタッチされた:ref:label-dcm_projects_pipelines_test

  • デプロイ前に動的テーブル、ビュー、またはテーブルからのサンプル出力を確認する:ref:label-dcm_projects_pipelines_preview

動的テーブルのREFRESHコマンド

パイプライン定義の変更をデプロイした後には、データ品質の期待をテストする前にパイプラインプロジェクト内の動的テーブルをリフレッシュすることで、新しい変換ロジックすべてを最初から最後まで適用できます。

|dcm-object|で管理されているすべての動的テーブルと、必要な上流の動的テーブルを、1つのコマンドでリフレッシュできます。このコマンドは、定義ファイルとは関係なく、参照されるプロジェクトによってデプロイおよび管理される動的テーブルにのみ適用されます。タスクなどの他のオブジェクトタイプは影響を受けません。

REFRESHとTESTを組み合わせた使用例については、:ref:`label-dcm_projects_pipelines_test`を参照してください。

このコマンドは、すべての動的テーブルのリフレッシュが完了するまで実行され、各動的テーブルの行の変更またはエラーの概要を返します。

REFRESHコマンドを実行するには、次の操作を行います。

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_STG
  REFRESH ALL;

JSON出力には、次の形式で動的テーブルのリフレッシュ操作の結果が格納されます。

プロパティ

説明

dts_refresh_result

動的テーブルリフレッシュ操作の結果が含まれます。

refreshed_tables[]

リフレッシュされた動的テーブルごとのエントリの配列。

table_name

リフレッシュされた動的テーブルの完全修飾名。

statistics

テーブルのリフレッシュ統計。

inserted_rows

リフレッシュ中に挿入された行数。

deleted_rows

リフレッシュ中に削除された行数。

data_timestamp

リフレッシュ後のデータの鮮度を表すISO 8601タイムスタンプ。

動的テーブルリフレッシュのJSON出力の例:

{
  "dts_refresh_result": {
    "refreshed_tables": [
      {
        "table_name": "db.schema.my_dynamic_table",
        "statistics": {
          "inserted_rows": 150,
          "deleted_rows": 30
        },
        "data_timestamp": "2026-03-16T12:00:00.000Z"
      }
    ]
  }
}

データ品質期待値に対応するTESTコマンド

データ変換のすべてのステージに対して、品質ゲートとしてデータ品質の期待値を設定できます。

  • ブロンズレイヤーのランディングテーブルの生データに期待値をアタッチすることで、未処理の入力が期待値を満たし、変換中にエラーを引き起こさないことを確認します。

  • シルバーレイヤーに品質ゲートとして期待値をアタッチすることで、さまざまな変換ステージにチェックポイントを設け、データの不具合のデバッグを容易にします。

  • ゴールドレイヤーに期待値をアタッチすることで、データ製品の出力品質を確保します。

  • データ製品の下流のコンシューマーからの期待値をゴールドレイヤーにアタッチすることで、破壊的変更をデプロイする前にそれらの期待値を検証できます。

DCMプロジェクトで期待値をアタッチする方法については、:ref:`label-dcm_projects_object_type_dmf`を参照してください。

|dcm-object|で管理しているテーブル、動的テーブル、またはビューにアタッチされているデータ品質期待値すべてを、1つのコマンドでテストできます。

期待値なしでアタッチされたデータメトリック関数はチェックされません。

CLIコマンドを使用して、CI/CDワークフローの一環となる自動テストを設定できます。たとえば、QA、テスト、またはステージング環境に本番に近いデータがある場合は、次の手順に従います。

  1. QAに対してPLANを実行し、予想されるプロジェクト定義の変更を確認します。

  2. QAにDEPLOYします。

  3. QAの動的テーブルにREFRESH ALLを実行し、新しい変換ロジックと最新の定義に基づいてデータを更新することで、古いデータに対して期待値がテストされないようにします。

  4. QA環境のテーブルオブジェクトにアタッチされたデータ品質期待値にTEST ALLを実行し、新しくデプロイされたロジックが期待通りに動作し、データ出力の予想される形状に悪影響がないことを確認します。

  5. QAですべての期待値が満たされていた場合は、実稼働環境へのPLANとDEPLOYの実行に進みます。

TESTコマンドを実行するには、次の操作を行います。

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_STG
  TEST ALL;

TESTの出力には、全体的なステータスと期待値が次の形式で含まれます。

重要

プレビュー段階では、正確な出力形式が変更される可能性があります。

{
  "status": <status>,
  "expectations": [
    {
      "table_name": <table_name>,
      "metric_database": <metric_database>,
      "metric_schema": <metric_schema>,
      "metric_name": <metric_name>,
      "expectation_name": <expectation_name>,
      "expectation_expression": <expectation_expression>,
      "value": <value>,
      "expectation_violated": <expectation_violated>,
      "column_names": <column_names>
    }
  ]
}

プロパティ

説明

status

テスト実行の全体的な結果。指定可能な値:``SUCCESSFUL``(すべての期待値が満たされた)、``FAILED``(1つ以上の期待値に違反があった)。

expectations[]

評価されたデータ品質期待値ごとの、期待値テスト結果の配列。

table_name

期待値が評価されたテーブルまたはビューの完全修飾名。

metric_database

データメトリック関数を含むデータベース。

metric_schema

データメトリック関数を含むスキーマ。

metric_name

データメトリック関数の名前(例:NULL_COUNTMINUNIQUE_COUNT)。

expectation_name

プロジェクトで定義されている期待値の名前。

expectation_expression

メトリック値の評価基準となるブール式(例:value = 0value >= 0)。

value

データメトリック関数の評価結果。``expectation_violated``が``false``の場合にのみ存在します。

expectation_violated

期待値に対する違反があったかどうか。メトリックの値が期待値の式を満たさなかった場合は``true``、それ以外の場合は``false``になります。

column_names

データメトリック関数が評価された列名の配列。

データ品質テストのJSON出力の例

{
  "status": "FAILED",
  "expectations": [
    {
      "table_name": "db.schema.my_table",
      "metric_database": "SNOWFLAKE",
      "metric_schema": "CORE",
      "metric_name": "NULL_COUNT",
      "expectation_name": "no_nulls_in_id",
      "expectation_expression": "value = 0",
      "value": 0,
      "expectation_violated": false,
      "column_names": ["ID"]
    },
    {
      "table_name": "db.schema.my_table",
      "metric_database": "SNOWFLAKE",
      "metric_schema": "CORE",
      "metric_name": "UNIQUE_COUNT",
      "expectation_name": "unique_id_check",
      "expectation_expression": "value >= 100",
      "value": null,
      "expectation_violated": true,
      "column_names": ["ID"]
    }
  ]
}

PREVIEW コマンド

動的テーブルまたはビューのSELECTステートメントを記述または変更する際、サンプル出力はデータの形状の検証に役立ちます。複数の変換ステップを持つ複雑な系統図の場合、上流でさらに変更を加えた場合の下流ビューや動的テーブルの出力を確認できます。

デプロイ前に、コード内の変換によって期待されるデータ出力が得られるかどうか検証するには、PREVIEWコマンドを実行します。

PREVIEWコマンドはPLANを実行し、デプロイ済みの状態に関係なく現在の定義をコンパイルし、指定された動的テーブル、ビュー、または通常のテーブルのデータサンプルを返します。

次の要件と考慮事項に留意してください。

  • PREVIEWコマンドは、Jinja変数を使用せずに、常にテーブルオブジェクトの完全修飾名を参照する必要があります。

  • 出力にサンプルデータを表示するには、ソーステーブルのデータがすでに使用可能であることを確認する必要があります。

  • PREVIEWは、参照される動的テーブルおよびビューのすべてのSELECTステートメントをクエリしますが、タスクやCREATE TABLE AS SELECTステートメントは実行しません。

PREVIEWコマンドを実行するには、次の操作を行います。

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  PREVIEW
    DCM_PROJECT_DEV.SERVE.V_DASHBOARD_KPI_SUMMARY
  USING CONFIGURATION DEV
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/DCM_Project_Quickstart_1'
  LIMIT 100;