Sodaとは：YAMLで宣言するデータ品質ツールの使い方

データ品質チェックを書こうとすると、Pythonコードや複雑な設定にひるむチームは多いです。「YAMLでサクッと宣言したい」「dbtプロジェクトに自然に併設したい」「失敗時の通知も簡単に組みたい」。こうした実務寄りのニーズに、シンプルに答えるのがSodaです。

Sodaは、SodaCL（Soda Checks Language）と呼ばれるYAMLベースのDSLでチェックを書く。読みやすさと導入の軽さで、データエンジニアと業務側の橋渡しがしやすいツールだ。基本構造と運用を順に押さえる。

Soda Core と Soda Cloud

Soda Coreで動かし、Soda Cloudで結果を集約する併用が定番だ。最初はCoreだけで始め、運用が広がってきたらCloudを足す、という順序で導入できる。

SodaCLでチェックを書く

SodaCLは、自然言語に近いYAMLで品質ルールを記述する。例を見るとイメージしやすい。

# checks/orders.yml
checks for orders:
  - row_count between 1000 and 1000000
  - missing_count(order_id) = 0
  - duplicate_count(order_id) = 0
  - invalid_count(order_status) = 0:
      valid values: ['pending', 'paid', 'shipped', 'cancelled']
  - avg(order_total) between 1000 and 100000
  - freshness(ordered_at) < 24h
  - schema:
      warn:
        when required column missing: [order_id, customer_id, order_total]
      fail:
        when forbidden column present: [credit_card_number]

「行数」「欠損」「重複」「不正値」「平均値の範囲」「鮮度」「スキーマ」と、データ品質で頻出する観点が、宣言的に書ける。読めばすぐに「何を検査しているか」が分かるのが、Sodaの強みだ。

接続設定と実行

# configuration.yml
data_source orders:
  type: snowflake
  connection:
    account: ${SNOWFLAKE_ACCOUNT}
    user: ${SNOWFLAKE_USER}
    password: ${SNOWFLAKE_PASSWORD}
    database: PROD
    schema: SILVER

# 実行
soda scan -d orders -c configuration.yml checks/orders.yml

SodaはSnowflake、BigQuery、Redshift、Databricks、PostgreSQLなど主要なデータストアに接続できる。クラウドDWHの位置づけはクラウドDWH入門を参照してほしい。

dbtとの組み合わせ

Sodaはdbtプロジェクトに自然に併設できる。実務でよく見る組み合わせは次の3パターンだ。

多くのチームは「併用」を選ぶ。dbt testsは変換コードと一体化したテストとして残し、Sodaは「業務側と共有する品質ルール」として置く構成だ。dbt testsの基本はdbt tests 実践、変換層の設計はdbt実装ガイドを参照してほしい。

業務側とルールを共有する

Sodaのいちばん効く側面は、技術側だけでなく業務側にも読みやすいYAMLでルールを書けることだ。「キャンセル注文には売上が立たない」「価格は1円〜100万円の範囲」のような業務的な期待を、業務担当者と一緒にレビューできる。

# 業務ルールをそのまま書ける
checks for orders:
  - failed rows:
      name: キャンセル注文には売上が立たない
      fail condition: order_status = 'cancelled' AND revenue > 0
  - failed rows:
      name: 価格は1円〜100万円の範囲
      fail condition: order_total <= 0 OR order_total > 1000000

ルールの命名に業務的な意味のある日本語をつけられるので、失敗通知が業務担当者にも届いた時点で「何が起きたか」が伝わる。「データ品質を技術側だけで抱え込まない」運用の起点となる。

通知とCI/CDへの組み込み

Soda Cloudを使えば、SlackやTeams、Webhookに失敗通知を送れる。Coreだけの場合も、実行結果のJSONを受け取って独自にハンドリングできる。

# CI/CDでの実行例（GitHub Actions等）
- name: Run Soda scans
  run: |
    soda scan \
      -d orders \
      -c configuration.yml \
      checks/orders.yml
    if [ $? -ne 0 ]; then
      echo "Soda checks failed"
      exit 1
    fi

dbtジョブの前後にSodaのscanを挟むのが、定番のパターンです。取り込み直後のRawデータをチェック、変換完了後のSilver/Goldをチェック、という2ポイント運用で品質を担保します。

向く・向かない場面

• 向く：YAMLで宣言的に書きたい、業務側とルールを共有したい、dbt中心の運用に併設したい、チーム展開でルールを読みやすく保ちたい
• 向かない：複雑な統計的検査やカスタムロジックが多い（→Great Expectations）、書くこと自体を減らしたい（→Monte Carlo）

まとめ

• SodaはSodaCL（YAMLベース）でチェックを書く、運用しやすさ重視のデータ品質ツール。
• Soda Core（OSS）で始め、規模が広がったらSoda Cloud（SaaS）を足す。
• dbtとの併用が定番。取り込み直後と変換完了後の2ポイント運用が効く。
• 業務側と共有しやすい記述で、品質責任を技術側だけで抱え込まない運用ができる。
• 複雑な統計検査が必要ならGreat Expectations、書きたくないならMonte Carlo、と切り分ける。

全体像はデータ品質ツール選定ガイド、隣接の選択肢はGreat Expectations とは・Monte Carlo とはにあります。データ品質運用の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。

よくある質問（FAQ）

Q. Soda CoreだけでもSoda Cloudの価値はありますか？

A. Coreだけでも品質チェック自体は完結します。Cloudの価値は、結果の集約・履歴の可視化・通知・コラボ機能にあります。1チームでJSONログを自前で扱える規模ならCoreで十分です。複数チームで結果を共有したい、業務担当者にも閲覧してほしい、SLA管理が必要、という段階でCloudを検討します。

Q. dbt testsをやめて、Sodaに一本化していいですか？

A. 推奨しません。dbt testsはdbtの変換コードの隣にあり、CI/CDでコードレビューと一緒に動きます。Sodaは「データ側の品質ルール」で、業務側と共有しやすい場所に置きます。両者は役割が違うので、一本化すると「コードの正しさ」と「データの正しさ」の境界が曖昧になります。dbt testsを土台に、外側のチェックをSodaで補う構成が現実的です。

Q. freshnessチェックは、どう設計するのがよいですか？

A. データの更新サイクルに合わせて閾値を決めます。日次バッチなら24時間、リアルタイムに近いものなら数分〜数時間です。失敗時のアクションも、即時通知して止めるか、警告だけ出して待つかをデータの重要度で分けます。鮮度監視は、データが「来ていないこと」を検知する唯一の手段なので、必ず1本は入れます。

Q. SodaとGreat Expectationsを併用する組織はありますか？

A. あります。SodaをチームのDS向けの宣言的品質ルール、Great Expectationsを高度な統計的検査やデータサイエンス側の検証に使い分ける、というパターンです。ただし併用は運用コストが2倍になります。両方使う場合は「どちらをどの責任範囲で使うか」のラインを最初に決めないと、規約が崩れて誰も触らなくなりがちです。