データエンジニア向けSnowflakeプライバシー保護機能まとめと実践③差分プライバシー
はじめに
データが企業の重要な資産として活用される現代、顧客や従業員の個人情報を適切に保護することは、コンプライアンスの遵守や信頼性の向上に不可欠です。一方で、データの活用とプライバシー保護のバランスを取ることは、多くの企業にとって難しい課題となっています。Snowflakeは、こうした課題に対応するため、柔軟なデータ管理と高度なプライバシー機能を両立するプラットフォームを提供しています。
本記事では私自身がsnowflakeの各プライバシー保護機能について学んだ内容に私なりの解釈も含めて、体系的にまとめた前回までの記事に続き、10月4日に一般提供された差分プライバシーについて取り扱ってみたいと思います。
差分プライバシーの一般提供（2024/10/4）
前回までの記事
あと、例によって長文記事ですいません。気長に読んでいただくか、それぞれの機能に飛んで読んでいただければと思います。
1. 差分プライバシーの基礎理解
1.1 概要
差分プライバシーは、個々のエンティティ（人、企業、場所など）の情報を保護しながら、データの分析を可能にする統計的手法です。Snowflakeでは、差分プライバシーポリシーというテーブルに対する制御機能として一般提供されています。
1.2 主要な特徴
- ターゲットを絞ったプライバシー攻撃からの保護
- プライバシーと分析精度のトレードオフを定量化
- クエリ結果へのノイズ導入による保護
- プライバシー予算による制御
そもその差分プライバシーという技術については、以下の記事でまとめていますので参考にしていただければと思います。
1.3 プライバシー保護機能の比較表
上記を踏まえた各プライバシー保護機能と今回取り扱う差分プライバシーポリシーの特徴を比較してみました。
| 機能 | 保護レベル | 実装の複雑さ | 性能影響 | 主な使用シナリオ | リスクや懸念事項 |
|---|---|---|---|---|---|
| 動的データマスキング | 中 | 中 | 低 | 特定のユーザーや状況に応じたデータ保護 | 不適切な条件設定でデータ露出のリスク |
| 行アクセスポリシー | 高 | 中 | 中 | ロール別・ユーザー別のアクセス制御 | ポリシーの複雑化による管理オーバーヘッド |
| ハッシュ化・暗号化 | 高 | 低 | 低 | 機密データの保存・転送時の保護 | 鍵管理の複雑さ、暗号化処理の遅延 |
| セキュアビュー | 中 | 低 | 中 | 必要最低限のデータアクセスの提供 | 設計ミスによる露出リスク、パフォーマンス低下 |
| 集計ポリシー | 中 | 中 | 中 | 小規模グループに対する統計的保護 | 厳格すぎるポリシーによる分析の制約 |
| 投影ポリシー | 中 | 中 | 低 | プライバシー項目の出力制御 | 設計ミスによる露出リスク |
| 差分プライバシー | 高 | 高 | 高 | 高度な匿名化と統計的有用性の両立 | ノイズ追加でデータ精度が低下する可能性 |
| 合成データ | 高 | 高 | 低 | 元データとの完全な分離 開発/テスト環境での利用 規制対応したデータ共有 |
モデルの品質管理の複雑さ 生成データの品質保証 統計的特性の検証必要性 |
2. 差分プライバシー機能の概要
2.1 実装要件と制約事項
| カテゴリ | 項目 | 詳細 |
|---|---|---|
| 基本要件 | エディション要件 | Enterprise Edition以上が必要 |
| データ型サポート |
サポート対象: - 数値型（INT, FLOAT, DECIMAL等） - 文字列型（VARCHAR, TEXT） - 日付時刻型（TIMESTAMP_NTZ） - 論理型（BOOLEAN） 非サポート: - バイナリ型 - タイムゾーン付き時刻型 - 構造化データ型 データ型の制約は厳格に適用される |
|
| コアコンポーネント | プライバシーポリシー | - スキーマレベルのオブジェクト - ユーザー/ロールと予算の関連付け - テーブル/ビューへの適用 - 1テーブルにつき1つのポリシーのみ適用可能 |
| プライバシー予算 | - クエリごとのプライバシー損失の定量化 - 累積的な予算管理 - 期間ベースのリセット機能 - 予算超過時はクエリ実行不可 |
|
| プライバシードメイン | - 数値型：範囲指定（BETWEEN） - カテゴリ型：値リスト指定（IN） - 集計前のフィルタリングに使用 |
|
| 機能制約 | 他機能との互換性 |
併用不可: - マスキングポリシー - 集計ポリシー - ストリーム - 動的テーブル - UDF - レプリケーションされたテーブルでのエンティティキー 機能の競合を避けるため事前確認が必要 |
| クエリ制約 | - Row-levelクエリ（SELECT *）禁止 - 中間集計へのノイズ非付加 - 最終集計のみノイズ付加 - 複数ポリシーの同時適用不可 クエリ設計時に考慮が必要 |
|
| パフォーマンス | レイテンシー | - 基本クエリで最低7秒の追加遅延 - 複雑なクエリでさらに遅延増加 以下の場合に特に影響: - 多数のJOIN - 複雑なサブクエリ - 大量のグループ化 |
| データ構造 | エンティティ要件 | - 1行1エンティティの原則 - エンティティ識別子の一貫性 - 関連テーブル間の整合性 データモデル設計時に考慮が必要 |
| クエリ制御 | 予算管理 | - クエリごとの予算消費 - 累積予算の制限 - 予算リセットの管理 定期的なモニタリングが必要 |
| アクセス制御 | - ロールベースのアクセス制御 - オブジェクトレベルの権限管理 - 予算使用の監視 適切な権限設定が重要 |
2.2 実装のステップバイステップ
前回の合成データで味を占めたので、TPCデータでまたテストデータを作成したいと思います。
さすがに全件だとデータセットがでかすぎるので、ほどほどのサイズに調整
2.2.1 データ準備
USE ROLE PRIVACY_HO_ADMIN;
CREATE OR REPLACE TABLE PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER AS
SELECT * FROM SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.CUSTOMER
LIMIT 100000;
2.2.2 プライバシーポリシーの設定
プライバシーポリシーのエンティティ設定
プライバシーポリシーをテーブルやビューに適用する際、以下のいずれかの方法を選択します：
ALTER { TABLE | VIEW } <name>
ADD PRIVACY POLICY <policy_name>
{ NO ENTITY KEY | ENTITY KEY ( <column_name> ) }
エンティティ設定の選択
| 設定 | 説明 | 使用条件 |
|---|---|---|
| ENTITY KEY | - 指定された列を使用してエンティティレベルの差分プライバシーを実現 - エンティティに属するすべてのレコードを識別可能に |
- エンティティ（個人、企業など）が複数のレコードに出現する可能性がある場合 - エンティティを一意に識別する列が存在する場合 |
| NO ENTITY KEY | - エンティティキーを指定せずに差分プライバシーを適用 - 各レコードを独立して扱う |
- エンティティが1レコードにのみ出現する場合 - レコードレベルでの保護が十分な場合 |
なお、以下のTipsが最近追加されており、例えば、顧客マスタのような、IDで一意になっているテーブルは、NO ENTITY KEY にしますが、履歴テーブルは、ENTITY KEY(ID)となり、エンティティキーが不揃いとなります。
この場合、ノイズ計算が正常に行えなくなるため、このような場合は、エンティティキーを揃えたり、結合済のデータマートに対し、プライバシーポリシーを設定するようにしてください。（ドハマリしました・・）
プライバシーポリシーと他のポリシーとの関係
併用不可のポリシー
| ポリシー | 制約内容 |
|---|---|
| Masking Policy | 同一テーブル/ビューへの適用不可 |
| Aggregation Policy | 同一テーブル/ビューへの適用不可 |
| Projection Policy | 同一テーブルへの適用は技術的には可能だが、クエリが失敗するため実質的に不可 |
併用可能なポリシー
| ポリシー | 相互作用 |
|---|---|
| Row Access Policy | - Row Access Policyが優先される - Row Access Policyによってブロックされた行は、差分プライバシーのクエリ結果に含まれない |
ポリシー併用が難しいため、1つのテーブルに多角的に設定するというよりは、処理ステップや元テーブル→集計後データテーブルなど分けて、差分プライバシーをどこで当てるかを考える必要があるように思われます。
プライバシーポリシーの設定
-- プライバシーポリシーの作成
USE ROLE PRIVACY_HO_ADMIN;
CREATE OR REPLACE privacy policy PRIVACY_HO_DB.PRIVACY.TPC_ACTIVE_CUSTOMERS_POLICY AS () RETURNS privacy_budget ->
CASE
WHEN CURRENT_ROLE() in ('ACCOUNTADMIN','PRIVACY_HO_ADMIN') THEN no_privacy_policy()
WHEN CURRENT_ROLE() IN ('PRIVACY_ANALYST') THEN privacy_budget(budget_name => 'PRIVACY_ANALYST.' || current_user())
ELSE privacy_budget(budget_name => 'default')
END;
-- ポリシーの適用
-- 1エンティティ1行になっている`TPC_CUSTOMER`はNO ENTITYに設定
USE ROLE PRIVACY_HO_ADMIN;
ALTER TABLE PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER ADD PRIVACY POLICY PRIVACY_HO_DB.PRIVACY.TPC_ACTIVE_CUSTOMERS_policy NO ENTITY KEY;
2.2.4 基本的なクエリ確認
-- まずはプライバシーポリシーが無効となっている管理者で実行
USE ROLE PRIVACY_HO_ADMIN;
SELECT
COUNT(DISTINCT C_CUSTOMER_SK) as customer_count
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER;
CUSTOMER_COUNT
100000
-- すぐにクエリが返り、10万件で出力
-- 次にプライバシーポリシーが適用される分析ユーザーで実行
USE ROLE PRIVACY_ANALYST;
SELECT
COUNT(DISTINCT C_CUSTOMER_SK) as customer_count
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER;
CUSTOMER_COUNT
99999
-- クエリは10秒ほどかかり、10万件で作成したはずが1件減っています。
-- 意地悪なので同じクエリを何度か試してみます
CUSTOMER_COUNT
99997
CUSTOMER_COUNT
100000
-- 毎回計算し直すようで、差分はランダムに出力されるようです
-- プライバシー保護度合いでノイズを入れるため、特定性が低い場合は実数と同値もありえるようです
-- 少し複雑なケースを試してみましょう
-- 出身国ごとの顧客数
USE ROLE PRIVACY_ANALYST;
SELECT
C_BIRTH_COUNTRY,
COUNT(DISTINCT C_CUSTOMER_SK) as customer_count
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
GROUP BY C_BIRTH_COUNTRY;
210007 (P0000): User Error Report: Invalid schema: GroupByAggregate max domain size limit exceeded: number of possible groups (infinity) must not exceed 10000. The number of possible groups can be limited by filtering values or by removing grouping columns. in function SYSTEM$PRIVACY_ENGINE_INTERNALS_UI
-- なんかめっちゃ怒られたので、翻訳してみました
210007 (P0000): ユーザーエラーレポート： スキーマが無効です： GroupByAggregate max domain size limit exceeded: 可能なグループの数 (infinity) は 10000 を超えてはなりません。可能なグループの数は、値のフィルタリングまたはグループ化列の削除によって制限できます。
-- 国の数は最大でも200ちょいだけど、恐らくSTRING型の場合、1万件の上限を超えて無限大になる可能性があるので、受け付けなかったよ。というような事のようです。公式ドキュメント探したけど、上限とか見つけられず。。
ちなみに国名リストアップして、211国分のプライバシードメイン設定しようとしたら、上限を超えたようでエラーが出ました。
Privacy domain for column 'C_BIRTH_COUNTRY' has too many items in the list: '211'. Consider using REFERENCES domain type instead.
と言う訳で211か国をエリアに分けるUpdateかまして、エリアでプライバシードメイン切るという力技をやりましたが、本筋じゃないので、見たい方は↓からどうぞ
211か国エリア分けUpdate
USE ROLE PRIVACY_HO_ADMIN;
UPDATE PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
SET C_BIRTH_COUNTRY =
CASE
-- 北米
WHEN C_BIRTH_COUNTRY IN (
'UNITED STATES', 'CANADA', 'MEXICO'
) THEN 'NORTH_AMERICA'
-- 中南米
WHEN C_BIRTH_COUNTRY IN (
'BRAZIL', 'ARGENTINA', 'CHILE', 'COLOMBIA', 'VENEZUELA', 'PERU',
'ECUADOR', 'BOLIVIA', 'PARAGUAY', 'URUGUAY', 'GUYANA', 'SURINAME',
'FRENCH GUIANA'
) THEN 'LATIN_AMERICA'
-- 西欧
WHEN C_BIRTH_COUNTRY IN (
'GERMANY', 'FRANCE', 'UNITED KINGDOM', 'ITALY', 'SPAIN', 'PORTUGAL',
'NETHERLANDS', 'BELGIUM', 'LUXEMBOURG', 'SWITZERLAND', 'AUSTRIA',
'MONACO', 'ANDORRA', 'LIECHTENSTEIN', 'SAN MARINO'
) THEN 'EUROPE_WEST'
-- 東欧
WHEN C_BIRTH_COUNTRY IN (
'POLAND', 'ROMANIA', 'CZECH REPUBLIC', 'HUNGARY', 'BULGARIA',
'SLOVAKIA', 'CROATIA', 'SERBIA', 'SLOVENIA', 'ALBANIA',
'MONTENEGRO', 'MOLDOVA, REPUBLIC OF', 'UKRAINE'
) THEN 'EUROPE_EAST'
-- 北欧
WHEN C_BIRTH_COUNTRY IN (
'SWEDEN', 'NORWAY', 'DENMARK', 'FINLAND', 'ICELAND',
'ESTONIA', 'LATVIA', 'LITHUANIA', 'FAROE ISLANDS',
'ALAND ISLANDS'
) THEN 'EUROPE_NORTH'
-- 東アジア
WHEN C_BIRTH_COUNTRY IN (
'CHINA', 'JAPAN', 'KOREA, REPUBLIC OF', 'HONG KONG', 'MACAO',
'MONGOLIA', 'TAIWAN'
) THEN 'ASIA_EAST'
-- 南アジア
WHEN C_BIRTH_COUNTRY IN (
'INDIA', 'PAKISTAN', 'BANGLADESH', 'SRI LANKA', 'NEPAL',
'BHUTAN', 'MALDIVES'
) THEN 'ASIA_SOUTH'
-- 東南アジア
WHEN C_BIRTH_COUNTRY IN (
'INDONESIA', 'THAILAND', 'VIETNAM', 'MALAYSIA', 'PHILIPPINES',
'SINGAPORE', 'MYANMAR', 'CAMBODIA', 'LAOS', 'BRUNEI DARUSSALAM',
'TIMOR-LESTE'
) THEN 'ASIA_SOUTHEAST'
-- 中央アジア
WHEN C_BIRTH_COUNTRY IN (
'KAZAKHSTAN', 'UZBEKISTAN', 'KYRGYZSTAN', 'TAJIKISTAN',
'TURKMENISTAN', 'AZERBAIJAN', 'ARMENIA', 'GEORGIA'
) THEN 'ASIA_CENTRAL'
-- 中東
WHEN C_BIRTH_COUNTRY IN (
'TURKEY', 'SAUDI ARABIA', 'IRAN', 'IRAQ', 'ISRAEL', 'LEBANON',
'JORDAN', 'SYRIA', 'UNITED ARAB EMIRATES', 'QATAR', 'KUWAIT',
'OMAN', 'BAHRAIN', 'YEMEN', 'CYPRUS', 'SYRIAN ARAB REPUBLIC'
) THEN 'MIDDLE_EAST'
-- 北アフリカ
WHEN C_BIRTH_COUNTRY IN (
'EGYPT', 'MOROCCO', 'ALGERIA', 'TUNISIA', 'LIBYA', 'SUDAN',
'WESTERN SAHARA'
) THEN 'AFRICA_NORTH'
-- 南アフリカ
WHEN C_BIRTH_COUNTRY IN (
'SOUTH AFRICA', 'NIGERIA', 'KENYA', 'ETHIOPIA', 'GHANA', 'ANGOLA',
'MOZAMBIQUE', 'NAMIBIA', 'BOTSWANA', 'ZIMBABWE', 'ZAMBIA',
'UGANDA', 'TANZANIA', 'RWANDA', 'BURUNDI', 'MALI', 'SENEGAL',
'BURKINA FASO', 'GUINEA', 'SOMALIA', 'DJIBOUTI', 'MALAWI',
'MADAGASCAR', 'MAURITANIA', 'GABON', 'SIERRA LEONE', 'TOGO',
'EQUATORIAL GUINEA', 'CAPE VERDE', 'COMOROS', 'ERITREA',
'GAMBIA', 'GUINEA-BISSAU', 'LESOTHO', 'LIBERIA', 'MAURITIUS',
'NIGER', 'SEYCHELLES', 'SWAZILAND', 'CÔTE D''IVOIRE', 'BENIN'
) THEN 'AFRICA_SOUTH'
--コートジボアールがエスケープ要るの鬼門過ぎる
-- オセアニア
WHEN C_BIRTH_COUNTRY IN (
'AUSTRALIA', 'NEW ZEALAND', 'PAPUA NEW GUINEA', 'FIJI',
'SOLOMON ISLANDS', 'VANUATU', 'NEW CALEDONIA', 'FRENCH POLYNESIA',
'SAMOA', 'AMERICAN SAMOA', 'TONGA', 'PALAU', 'TUVALU',
'KIRIBATI', 'NAURU', 'NORFOLK ISLAND', 'NIUE', 'TOKELAU',
'WALLIS AND FUTUNA', 'BOUVET ISLAND', 'PITCAIRN'
) THEN 'OCEANIA'
-- カリブ海
WHEN C_BIRTH_COUNTRY IN (
'JAMAICA', 'TRINIDAD AND TOBAGO', 'BAHAMAS', 'BARBADOS',
'SAINT LUCIA', 'ANTIGUA AND BARBUDA', 'GRENADA', 'DOMINICA',
'CAYMAN ISLANDS', 'BERMUDA', 'HAITI', 'CUBA', 'PUERTO RICO',
'VIRGIN ISLANDS, U.S.', 'NETHERLANDS ANTILLES', 'ARUBA',
'MARTINIQUE', 'GUADELOUPE', 'SAINT HELENA', 'MONTSERRAT',
'ANGUILLA'
) THEN 'CARIBBEAN'
-- その他
WHEN C_BIRTH_COUNTRY IN (
'ANTARCTICA', 'CHRISTMAS ISLAND', 'GUERNSEY', 'ISLE OF MAN',
'JERSEY', 'GIBRALTAR', 'VATICAN CITY', 'RÉUNION', 'MAYOTTE'
) THEN 'OTHER'
ELSE 'OTHER'
END
WHERE C_BIRTH_COUNTRY IS NOT NULL;
-- 更新結果の確認
SELECT
C_BIRTH_COUNTRY as region,
COUNT(*) as customer_count
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
GROUP BY 1
ORDER BY 1;
REGION CUSTOMER_COUNT
AFRICA_NORTH 2689
AFRICA_SOUTH 18043
ASIA_CENTRAL 3710
ASIA_EAST 2779
ASIA_SOUTH 3248
ASIA_SOUTHEAST 4113
CARIBBEAN 9635
EUROPE_EAST 5988
EUROPE_NORTH 4641
EUROPE_WEST 6891
LATIN_AMERICA 5418
MIDDLE_EAST 6352
NORTH_AMERICA 1422
OCEANIA 9596
OTHER 11998
3477
-- 集約したし、プライバシードメインなくてもいけんじゃね？とクエリ実行
USE ROLE PRIVACY_ANALYST;
SELECT
C_BIRTH_COUNTRY,
COUNT(DISTINCT C_CUSTOMER_SK) as customer_count
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
GROUP BY C_BIRTH_COUNTRY
ORDER BY 1;
510231 (0A000): Query not supported or insufficient privileges to run this query on a privacy-protected table. Please check the documentation for the list of supported commands and functions.
510231 (0A000): クエリがサポートされていないか、プライバシー保護されたテーブルでこのクエリを実行するには権限が不足しています。サポートされているコマンドと関数のリストについてはドキュメントを確認してください。
-- ドキュメント読め、ボケ!と怒られました・・ちゃんとプライバシードメイン設定したいと思います
2.2.4 プライバシードメインの目的
さて改めてプライバシードメインの設定を行いますが、この設定のそもそもの目的と効果について理解を深めておきましょう。
| 目的 | 詳細 | 効果 |
|---|---|---|
| プライバシー保護の範囲定義 | - データの取り得る値の範囲を明確化 - 有効な値の範囲を制限 - 異常値の除外 |
- 情報漏洩リスクの低減 - ノイズ計算の正確性向上 - 保護レベルの明確化 |
| ノイズ付加の基準提供 | - ノイズの適切な計算範囲を定義 - データの感度に基づく調整 - 統計的有意性の確保 |
- 適切なノイズレベルの実現 - 分析精度の確保 - 予算消費の最適化 |
| データの意味的制約表現 | - ビジネスルールの反映 - 論理的な値の範囲設定 - 分析コンテキストの定義 |
- 分析結果の妥当性確保 - 業務要件との整合性 - データ品質の維持 |
設定の基本原則
上記を踏まえた設定の考え方をまとめました
| 原則 | 内容 | 考慮事項 | リスク |
|---|---|---|---|
| 最小十分性 | - 必要最小限の範囲定義 - ビジネス要件充足 - 過剰な範囲設定の回避 |
- 実際のデータ分布 - 業務要件の範囲 - 将来的な変動可能性 |
- 範囲過小：分析制限 - 範囲過大：保護弱体化 |
| データ特性の反映 | - 実データの分布考慮 - 業務的区分の反映 - 統計的特性の考慮 |
- データの偏り - 外れ値の処理 - 季節性や傾向 |
- 特性無視：精度低下 - 過度な反映：複雑化 |
| セキュリティと 利便性のバランス |
- 保護レベルの設定 - 分析有用性の確保 - 最適なバランス点の特定 |
- セキュリティ要件 - 分析ニーズ - 運用コスト |
- バランス不適切： 保護過剰or不足 |
2.2.5 プライバシードメインの設定
まずは、国名の地域名への更新が完了した先ほどのC_BIRTH_COUNTRYについて、プライバシードメインを設定し、検証再開していきます
--プライバシードメインの設定
USE ROLE PRIVACY_HO_ADMIN;
ALTER TABLE PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
MODIFY COLUMN C_BIRTH_COUNTRY
SET PRIVACY DOMAIN IN (
'NORTH_AMERICA', -- 北米
'LATIN_AMERICA', -- 中南米
'EUROPE_WEST', -- 西欧
'EUROPE_EAST', -- 東欧
'EUROPE_NORTH', -- 北欧
'ASIA_EAST', -- 東アジア
'ASIA_SOUTH', -- 南アジア
'ASIA_SOUTHEAST', -- 東南アジア
'ASIA_CENTRAL', -- 中央アジア
'MIDDLE_EAST', -- 中東
'AFRICA_NORTH', -- 北アフリカ
'AFRICA_SOUTH', -- 南アフリカ
'OCEANIA', -- オセアニア
'CARIBBEAN', -- カリブ海
'OTHER' -- その他
);
-- 出身国ごとの顧客数
USE ROLE PRIVACY_ANALYST;
SELECT
C_BIRTH_COUNTRY,
COUNT(DISTINCT C_CUSTOMER_SK) as customer_count
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
GROUP BY C_BIRTH_COUNTRY;
C_BIRTH_COUNTRY CUSTOMER_COUNT
3477
AFRICA_NORTH 2686
AFRICA_SOUTH 18041
ASIA_CENTRAL 3715
ASIA_EAST 2779
ASIA_SOUTH 3249
ASIA_SOUTHEAST 4113
CARIBBEAN 9633
EUROPE_EAST 5984
EUROPE_NORTH 4640
EUROPE_WEST 6890
LATIN_AMERICA 5421
MIDDLE_EAST 6355
NORTH_AMERICA 1424
OCEANIA 9598
OTHER 12002
-- 正常に出力されました!
と言う訳でプライバシードメインは設定が必要と理解しましたので、端折らず真面目に取り組みます。
と思ったのですが、その前にいくつか単純なクエリにも関わらず、エラーになるケースがあり、この段階でエラーに躓く方もいると思いますので、先んじて紹介しておきます。結論ドキュメントだけでこれ理解するのも無理じゃね？？です。
2.2.6 単純クエリーでのエラー
-- 設定確認用の基本クエリ（地域別集計）
USE ROLE PRIVACY_ANALYST;
SELECT
C_BIRTH_COUNTRY EREA,
COUNT(DISTINCT C_CUSTOMER_SK) as customer_count
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
WHERE C_BIRTH_COUNTRY in('EUROPE_EAST','EUROPE_WEST')
GROUP BY C_BIRTH_COUNTRY;
EREA CUSTOMER_COUNT
EUROPE_EAST 6022
EUROPE_WEST 6831
-- ORDER BY の追加（エラー）
SELECT
C_BIRTH_COUNTRY EREA,
COUNT(DISTINCT C_CUSTOMER_SK) as customer_count
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
WHERE C_BIRTH_COUNTRY in('EUROPE_EAST','EUROPE_WEST')
GROUP BY C_BIRTH_COUNTRY
ORDER BY C_BIRTH_COUNTRY;
510231 (0A000): Query not supported or insufficient privileges to run this query on a privacy-protected table. Please check the documentation for the list of supported commands and functions.
-- ORDER BY の追加はプライバシーポリシーに抵触するようです。
-- ノイズにより順序付けの整合性が取れない、もしくは小さな値の順序で実データを推測されるとか？
-- NVL の追加（エラー）
SELECT
NVL(C_BIRTH_COUNTRY,'NO') EREA,
COUNT(DISTINCT C_CUSTOMER_SK) as customer_count
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
WHERE C_BIRTH_COUNTRY in('EUROPE_EAST','EUROPE_WEST')
GROUP BY NVL(C_BIRTH_COUNTRY,'NO')
510254 (0A000): Function 'NVL' not supported in a private query.
-- NULL値を補完する、NVLはサポートされないようです。
-- NULL値の置き換えでドメイン範囲外のデータを作れたり、ノイズの計算に影響するのではないかと
このようにSQLの制限は多いので、不明なエラーが出た方は後述のエラーパターンを参照してください。
2.3 差分プライバシーのノイズ間隔評価関数
2.3.1 DP_INTERVAL_LOW と DP_INTERVAL_HIGH
差分プライバシーによるノイズの影響を評価するための組み合わせ関数が提供されています。ただ、これってどう使ったらいいのか？と迷われる方もいるかと思いますので、以下に仕様や使い方をまとめています。
2.3.2 基本情報
| 項目 | 説明 |
|---|---|
| 入力引数 | 集計された列のエイリアス |
| 戻り値 | 整数（非保護テーブルの場合はNULL） |
| 信頼度 | デフォルトで95% |
2.3.3 関数の特徴
DP_INTERVAL_LOW
- ノイズ区間の下限値を返却
- 実際の値が返却値以上である確率が95%
- 集計結果の最小値の推定に使用
DP_INTERVAL_HIGH
- ノイズ区間の上限値を返却
- 実際の値が返却値以下である確率が95%
- 集計結果の最大値の推定に使用
2.3.4 基本的な使用パターン
-- 顧客数の集計
USE ROLE PRIVACY_ANALYST;
SELECT
C_PREFERRED_CUST_FLAG,
COUNT(*) as customer_count,
DP_INTERVAL_LOW(customer_count) as min_count,
DP_INTERVAL_HIGH(customer_count) as max_count
FROM TPC_CUSTOMER
WHERE C_PREFERRED_CUST_FLAG = 'Y'
GROUP BY C_PREFERRED_CUST_FLAG;
C_PREFERRED_CUST_FLAG CUSTOMER_COUNT MIN_COUNT MAX_COUNT
Y 47428 47422 47434
この結果が示すもの
実際の優良顧客数は、95%の確率で47,422人から47,434人の間に存在
これは、20回同じクエリを実行した場合、19回はこの範囲に実際の値が含まれる
言い換えれば、このデータを基に「優良顧客は約47,400人」と報告しても、個人の特定にはつながらならず、かつ、経営判断に必要な精度は維持されている
ビジネス判断における解釈
区間幅が狭い（例：±0.1%）
→ より確実な判断が可能
→ 「優良顧客は47,400人±100人程度」
区間幅が広い（例：±10%）
→ より慎重な判断が必要
→ 「優良顧客は40,000人から50,000人の間」
活用シーン
施策の効果測定
介入前：4,700±100人
介入後：5,200±100人
→ 明確な効果が確認できる
トレンド分析
1月：4,700±100人
2月：4,720±100人
3月：4,750±100人
→ 緩やかな上昇トレンドが確認できる
この２つの関数は、差分プライバシーを適用したデータ分析において、結果の信頼性を評価するための重要なツールです。95%という高い信頼度でノイズの影響範囲を把握できることから、より確実な意思決定をサポートします。
2.4 プライバシードメインの設定について
さて、改めてプライバシードメインの設定を進めるためにはデータ構造の理解を深める必要があります。
自社データであれば、ドメイン知識やデータカタログや処理設計を元に容易に設計できると思いますが、今回はTPCデータのため、理解を深めるための確認作業を実施します。
2.4.1 データ確認
-- 数値型項目の範囲を確認
USE ROLE PRIVACY_HO_ADMIN;
SELECT
MIN(C_BIRTH_YEAR) as min_year,
MAX(C_BIRTH_YEAR) as max_year,
MIN(C_BIRTH_MONTH) as min_month,
MAX(C_BIRTH_MONTH) as max_month,
MIN(C_CUSTOMER_SK) as min_cust_id,
MAX(C_CUSTOMER_SK) as max_cust_id
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER;
MIN_YEAR MAX_YEAR MIN_MONTH MAX_MONTH MIN_CUST_ID MAX_CUST_ID
1924 1992 1 12 7014865 64788476
--カテゴリカル列の分析
SELECT
COUNT(DISTINCT C_BIRTH_COUNTRY) as unique_countries,
COUNT(DISTINCT C_BIRTH_YEAR) as unique_years,
COUNT(DISTINCT C_BIRTH_MONTH) as unique_months,
COUNT(DISTINCT C_PREFERRED_CUST_FLAG) as unique_flags
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER;
UNIQUE_COUNTRIES UNIQUE_YEARS UNIQUE_MONTHS UNIQUE_FLAGS
15 69 12 2
-- 年齢の分布を10年刻みで確認
SELECT
FLOOR(C_BIRTH_YEAR/10)*10 as year_range,
COUNT(*) as count
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
GROUP BY 1
ORDER BY 1;
YEAR_RANGE COUNT
1920 8277
1930 14033
1940 13973
1950 14086
1960 14012
1970 14016
1980 13914
1990 4205
3484
SELECT
COUNT(*) as total_rows,
COUNT(CASE WHEN C_BIRTH_COUNTRY IS NULL THEN 1 END) as null_country,
COUNT(CASE WHEN C_BIRTH_YEAR IS NULL THEN 1 END) as null_year,
COUNT(CASE WHEN C_BIRTH_MONTH IS NULL THEN 1 END) as null_month
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER;
TOTAL_ROWS NULL_COUNTRY NULL_YEAR NULL_MONTH
100000 3546 3484 3466
全体の傾向は概ね掴んだので、以下のように設計しました。
またNULL値についてドキュメント上以下の記載があり、ドメイン範囲外はNULLに置き換わります。
そのためNULL値に意味がある場合は、別の値に置き換え、それをプライバシードメインにも追加することが必要となります。
2.4.2 プライバシードメイン設計
| カラム名 | データ型 | 実データと設定内容 | 設定の考え方 |
|---|---|---|---|
| C_CUSTOMER_SK | NUMBER(38,0) | 実データ: 7014865-64788476 設定: BETWEEN (7014865, 64788476) |
・エンティティキー兼結合キー ・将来拡張性を含め正確な値が望ましい ・IDのコード体系に従い適切に設定 |
| C_BIRTH_YEAR | NUMBER(38,0) | 実データ: 1924-1992 設定: BETWEEN (1924, 1992) |
・年代別の顧客分析に必要 ・実データの年代範囲を維持 ・特異値は丸める |
| C_BIRTH_MONTH | NUMBER(38,0) | 実データ: 1-12 設定: BETWEEN (1, 12) |
・季節性分析に必要 |
| C_BIRTH_COUNTRY | VARCHAR | 実データ: 15種類の地域 設定: 前述の通り |
・地域別分析の基本単位 ・個別国名を地域グループに集約し分析粒度を適正化 |
| C_PREFERRED _CUST_FLAG |
VARCHAR | 実データ: Y/N 設定: IN ('Y', 'N') |
・顧客セグメント分析の基本指標 ・二値データとしてシンプルに維持 |
| C_FIRST_SHIPTO _DATE_SK |
NUMBER(38,0) | 設定しない | ・現時点で分析対象外 ・必要に応じて追加設定を検討 |
| C_FIRST_SALES _DATE_SK |
NUMBER(38,0) | 設定しない | ・現時点で分析対象外 ・必要に応じて追加設定を検討 |
| C_SALUTATION | VARCHAR | 設定しない | ・分析対象外として除外 |
| C_FIRST_NAME | VARCHAR | 設定しない | ・分析対象外として除外 |
| C_LAST_NAME | VARCHAR | 設定しない | ・分析対象外として除外 |
| C_LOGIN | VARCHAR | 設定しない | ・分析対象外として除外 |
| C_EMAIL_ADDRESS | VARCHAR | 設定しない | ・分析対象外として除外 |
| C_LAST_REVIEW_DATE | VARCHAR | 設定しない | ・現時点で分析対象外 ・必要に応じて追加設定を検討 |
今回はMIN/MAX通りのピーキーな設定にしましたが、実際のデータ仕様に沿って、適切に設定しましょう。
・ID系：ID開始位置～理論上の最大値
・生年月日：1900年～2100年など
・数値系：発生しうる桁数や値の範囲
2.4.3 プライバシードメインの設定
TPC_CUSTOMER の設定
--===================================
-- TPC TPC_CUSTOMERのプライバシードメイン設定
--===================================
-- 1. 顧客ID（エンティティキー兼結合キー）の設定
-- 実データ範囲：7014865-64788476
USE ROLE PRIVACY_HO_ADMIN;
ALTER TABLE PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
MODIFY COLUMN C_CUSTOMER_SK
SET PRIVACY DOMAIN BETWEEN (7014865, 64788476);
-- 2. 誕生年の設定
-- 実データ範囲：1924-1992、NULLが約3.5%
ALTER TABLE PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
MODIFY COLUMN C_BIRTH_YEAR
SET PRIVACY DOMAIN BETWEEN (1924, 1992);
-- 3. 誕生月の設定
-- 実データ範囲：1-12、NULLが約3.5%
ALTER TABLE PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
MODIFY COLUMN C_BIRTH_MONTH
SET PRIVACY DOMAIN BETWEEN (1, 12);
-- 4. 地域（出生国のグループ化）の設定(実施済)
-- 実データ：15地域グループ、NULLが約3.5%
ALTER TABLE PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
MODIFY COLUMN C_BIRTH_COUNTRY
SET PRIVACY DOMAIN IN (
'NORTH_AMERICA',
'LATIN_AMERICA',
'EUROPE_WEST',
'EUROPE_EAST',
'EUROPE_NORTH',
'ASIA_EAST',
'ASIA_SOUTH',
'ASIA_SOUTHEAST',
'ASIA_CENTRAL',
'MIDDLE_EAST',
'AFRICA_NORTH',
'AFRICA_SOUTH',
'OCEANIA',
'CARIBBEAN',
'OTHER'
);
-- 5. 優良顧客フラグの設定
-- 実データ：Y/Nの二値
ALTER TABLE PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
MODIFY COLUMN C_PREFERRED_CUST_FLAG
SET PRIVACY DOMAIN IN ('Y', 'N');
-- 設定後の確認用クエリ（正常系）
-- 地域別の顧客数（COUNT DISTINCT）
USE ROLE PRIVACY_ANALYST;
SELECT
C_BIRTH_COUNTRY,
COUNT(DISTINCT C_CUSTOMER_SK) as customer_count,
DP_INTERVAL_LOW(customer_count) as count_lower_bound,
DP_INTERVAL_HIGH(customer_count) as count_upper_bound
FROM PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER
WHERE C_BIRTH_COUNTRY IS NOT NULL
GROUP BY C_BIRTH_COUNTRY;
C_BIRTH_COUNTRY CUSTOMER_COUNT COUNT_LOWER_BOUND COUNT_UPPER_BOUND
AFRICA_NORTH 2688 2682 2694
AFRICA_SOUTH 18043 18037 18049
ASIA_CENTRAL 3711 3705 3717
ASIA_EAST 2786 2780 2792
ASIA_SOUTH 3253 3247 3259
ASIA_SOUTHEAST 4115 4109 4121
CARIBBEAN 9633 9627 9639
EUROPE_EAST 5988 5982 5994
EUROPE_NORTH 4642 4636 4648
EUROPE_WEST 6893 6887 6899
LATIN_AMERICA 5418 5412 5424
MIDDLE_EAST 6353 6347 6359
NORTH_AMERICA 1423 1417 1429
OCEANIA 9597 9591 9603
OTHER 11997 11991 12003
DP_INTERVAL関数も使い、出力した各値に対し、その範囲が表示されており、一定のノイズが含まれた出力であることが確認出来ました。
ここまでのステップにより、TPC_CUSTOMERの設定を通じて、差分プライバシーの仕様や制御について一通りの確認が出来ました。
2.4.4 複数テーブル間でのENTITY KEYの統一
今回のケースでは、1テーブルのみで、TPC_CUSTOMERのエンティティ仕様に従い、NO ENTITY KEYで実施しましたが、複数テーブルを用いる場合は、テーブル間でENTITY KEYを揃える必要があります。
エンティティ設定の注意事項にあったようにエンティティが不ぞろい場合、正常にノイズが設定出来ず、正しい件数が出力されません。という事を見落としていて、サポートに問い合わせたり、色々やったり、ドキュメント見直しして気付きました。。
定義を揃えた上で、2テーブルを結合してもノイズ計算は色々難しいようで正常に出ないケースもあり、シンプルに1つのデータマートを作る方が良いように思いました。
自由度の高いクエリ実行そのものが差分プライバシーとの相性が悪いため、マルチ結合な差分プライバシー環境を目指すのはかなり労力が伴いますので目的に合わせたテーブル設計と差分プライバシーのバランスが重要となります。
また履歴系でも、NO ENTITY KEYにした方が後述にある無限乗数などのエラーが回避できるケースもあり、実際のデータ仕様に基づいて、自身で確認することが重要です。
2.5 プライバシーポリシーの確認手順
プライバシーポリシーについては確認する事が多いため、主要な確認手順を以下にまとめています。
-- プライバシーポリシーの一覧確認
SHOW PRIVACY POLICIES;
-- プライバシーポリシーのソース確認
USE ROLE ACCOUNTADMIN;
SELECT *
FROM SNOWFLAKE.ACCOUNT_USAGE.PRIVACY_POLICIES
WHERE POLICY_NAME ='TPC_ACTIVE_CUSTOMERS_POLICY'
-- 該当のプライバシーポリシーの適用テーブルの確認
SELECT policy_name, policy_kind, ref_entity_name
FROM TABLE(information_schema.policy_references(policy_name => 'TPC_ACTIVE_CUSTOMERS_POLICY'));
-- プライバシードメインの設定確認
DESC TABLE TPC_CUSTOMER;
3. プライバシーポリシーのパラメータ設定仕様
さて続いては差分プライバシーを運用する上で各内部パラメータの理解を深めましょう。
3.1 PRIVACY_BUDGET関数のパラメータ
| パラメータ | デフォルト値 | 設定可能な値 | 説明 |
|---|---|---|---|
| BUDGET_NAME | 必須パラメータ | 文字列 例： - 'analyst_budget' - 'external_budget.' || CURRENT_ACCOUNT() |
- プライバシー予算の識別子 - 自動的に予算を作成 - アカウント間では自動的に名前空間化 |
| BUDGET_LIMIT | 233.0 | 0より大きい10進数 | - 許容される総プライバシー損失量 - 約1000の集計を許可（MAX_BUDGET_PER_AGGREGATE=1の場合） |
| MAX_BUDGET_PER_AGGREGATE | 0.5 | 0より大きい10進数 | - 各集計関数の予算使用量 - ノイズ量に影響 - 実行可能な集計回数に影響 |
| BUDGET_WINDOW | 'WEEKLY' | - 'DAILY' - 'WEEKLY' - 'MONTHLY' - 'YEARLY' - 'NEVER' |
- 予算リセットの頻度 - UTC 12:00に更新 - NEVERは更新なし |
3.2 注意点
-
予算計算
- BUDGET_LIMIT = デフォルトで233と決まっている
- NUMBER_OF_REMAINING_DP_AGGREGATES = 995と決まっている模様
- 実際の回数は
MAX_BUDGET_PER_AGGREGATEの値に依存
-
更新タイミング
- すべてUTC 12:00が基準
- NEVERの場合は累積値が継続
-
アカウント間の動作
- 自動的な名前空間分離
- アカウントごとの独立した予算管理
3.3 クエリ実行によるバジェットの消費状況
SELECT * FROM TABLE(
SNOWFLAKE.DATA_PRIVACY.ESTIMATE_REMAINING_DP_AGGREGATES(
'PRIVACY_HO_DB.PRIVACY.TPC_CUSTOMER'-- テーブル名フルパス
)
);
ポリシーを設定してからその挙動を確認してみました。
途中でMAX_BUDGET_PER_AGGREGATEをデフォルトの0.5から2.0、0.1と変えてみましたが、2.0にする事でノイズが大きくなり、バジェットの消費が減るのは予想通りだったのですが、0.1とよりシビアな数値にしたのにバジェットの消費は少ないままとなかなか謎な動きでした。
ただいずれにせよ、バジェットの消費（Privacyの保護上限）を意識して、適切なパラメータを模索する事が必要となりそうです。
| NUMBER_OF_REMAINING_DP_AGGREGATES | BUDGET_LIMIT | BUDGET_WINDOW | BUDGET_SPENT |
|---|---|---|---|
| 995 | 233 | DAILY | 1.400 |
| 994 | 233 | DAILY | 2.100 |
| 993 | 233 | DAILY | 2.800 |
| 992 | 233 | DAILY | 3.500 |
| 991 | 233 | DAILY | 4.200 |
| 990 | 233 | DAILY | 4.900 |
| 989 | 233 | DAILY | 5.600 |
| 984 | 233 | DAILY | 9.560 |
| 983 | 233 | DAILY | 10.134 |
| 982 | 233 | DAILY | 10.707 |
| 981 | 233 | DAILY | 11.280 |
・BUDGET_SPENT
クエリパターンに限らず、一定で消費される（テーブルごとに消費量は変動の模様）
BUDGET_LIMITを超過する、もしくは実行残り回数が0になるとクエリ実行出来なくなる（見た事ない）
MAX_BUDGET_PER_AGGREGATEについて
当初、このパラメータは、差分プライバシーの概念でいう、ε（プライバシー保護の強度）を抽象化したパラメータだと想定していましたが、実際の結果を見ると強度を調整しているというよりはバジェットの消費をコントロールするパラメータと想定されます。
実際にDP_INTERVAL関数のLOW/HIGHの幅を確認したところ、01~05~2.0で一定幅であったため、強度の変化がなかったと判断しています。
そのため、εそのものを変更する手段はなく、snowflake内のアルゴリズムが良しなにやってくれるという仕様のようです。
パラメータ設計から解放されるもののプライバシー保護観点で言えば、ホワイトボックス化しておきたい箇所ではあるので、悩ましいところです。
この辺り、サポートに仕様面の確認は引き続き行っていこうと思います。
4. エラーパターン、制約一覧
4.1 クエリエラーパターン一覧
さてここまでの章で基本的な設定や制御、運用面を学んできました。その纏めの中で差分プライバシーを適用する上では制約事項が多い事は薄々感じていただけたと思います。
皆様が実装される際も制約に抵触したり、クエリのお作法に沿ったクエリがかけず、エラー等でお困りになるケースがあると考えています。
そこで私が今回の検証で遭遇したエラー一覧も公開させていただきますので、皆さんが躓いた時の参考にしていただければと思います。
| エラーコード | エラーメッセージ | 主な原因 | 解決方法 |
|---|---|---|---|
| 210007 | "Invalid schema: GroupByAggregate max domain size limit exceeded: number of possible groups (XXXXX) must not exceed 10000" | ・GROUP BY句での可能なグループ数が10,000を超過 ・計算式によるグループ化で理論上の可能な値が多すぎる ・結果セットが大きすぎる |
・より粗い粒度でのグループ化 ・WHERE句での範囲制限 ・個別クエリへの分割 |
| 210007 | "Private tables have an infinite multiplier..." | ・プライバシードメインが未設定 ・文字列型カラムの無制限な使用 ・複数テーブル結合時のGROUP BY ・無限の可能性を持つ文字列カラムでのグループ化 |
・プライバシードメインの適切な設定 ・単一値での絞り込み ・GROUP BYを使用しない結合 ・NO ENTITY KEYでのポリシー適用（マスタテーブルの場合） |
| 210007 | "Invalid expression type: expected INT, got TEXT" | ・データ型の不一致 ・特に文字列を数値として扱おうとした場合 ・暗黙の型変換が発生するケース |
・適切なデータ型の使用 ・明示的な型変換の実施 ・プライバシードメインと一致するデータ型の使用 |
| 210007 | "Attempted to run a differentially private query on a relation without any DP-protected tables" | ・差分プライバシーが設定されていないテーブルでDP_INTERVAL関数を使用 ・プライバシーポリシーが正しく設定されていない |
・テーブルのプライバシーポリシー設定を確認 ・プライバシーポリシーの再設定 ・通常のクエリとして実行 |
| 510231 | "Query not supported or insufficient privileges..." | ・サポートされていない構文の使用 ・WITH句やサブクエリの不適切な使用 ・複雑なクエリ構造 |
・シンプルな集計クエリの使用 ・複雑なクエリの分割 ・単一のSELECT文での実行 |
| 510237 | "Queries on privacy-protected tables must produce an aggregate output" | ・集計されていない結果の取得を試みた ・行レベルのデータアクセス |
・集計関数の使用 ・GROUP BY句との適切な組み合わせ |
| 510245 | "Expression is neither an aggregation, nor a group by key, nor a differentially private interval function" | ・非集計カラムの直接参照 ・不適切なカラム参照方法 |
・集計関数の使用 ・GROUP BY句のキーとしての使用 |
| 510254 | "Function 'NVL' not supported in a private query" | ・サポートされていない関数の使用 ・NULL値の不適切な処理 |
・WHERE句でのNULL除外 ・集計前のサブクエリでの変換 ・NULL許容の集計関数の使用 |
| 510255 | "Multiple aggregations in a private group by analysis must have the same argument" | ・同一クエリ内での異なるカラムに対する複数の集計 ・異なる集計関数の混在 ・不適切な集計の組み合わせ |
・同一カラムに対する集計に統一 ・別々のクエリに分割 ・単一の集計関数に統一 |
| 510256 | "Sub query expressions are not supported in private queries" | ・サブクエリの使用 ・IN句やEXISTS句でのサブクエリ ・相関サブクエリ |
・JOINを使用した代替実装 ・クエリの分割 ・単一のSELECT文での実装 |
4.2 構文制約事項一覧
エラーも含めた構文制約のまとめです。
| 制約カテゴリ | 制約内容 | 対処方法 | 備考 |
|---|---|---|---|
| 結合制約 | ・複数テーブルでのGROUP BY不可 ・結合キーのプライバシードメイン一致が必要 ・複雑な結合条件不可 |
・シンプルな結合条件の使用 ・単一値での絞り込み ・事前の範囲制限 |
エンティティキーでの結合を推奨 |
| ORDER BY制約 | ・集計結果でのソート不可 ・DP_INTERVAL結果でのソート不可 |
・アプリケーション側でのソート ・個別クエリでの取得 |
全ての種類のORDER BYが不可 |
| グループ化制約 | ・最大10,000グループまで ・計算式も理論上の可能値としてカウント ・複数テーブルでは不可 |
・より粗い粒度での集計 ・個別クエリへの分割 ・WHERE句での範囲制限 |
単一テーブルのみで使用可能 |
| 関数制約 | ・NVL関数不可 ・Window関数不可 ・複雑な文字列操作関数制限 |
・WHERE句でのNULL除外 ・シンプルな集計関数の使用 ・複数クエリでの代替 |
基本的な集計関数のみサポート |
| 集計関数制約 | ・同一クエリ内は同一カラムの集計のみ ・DP_INTERVAL関数が必要 |
・クエリの分割 ・同一カラムでの集計に統一 |
COUNT, SUM, AVG, MIN, MAXが基本 |
| WITH句/サブクエリ | ・WITH句の使用制限 ・複雑なサブクエリ制限 |
・シンプルなクエリ構造 ・個別クエリへの分割 |
基本的な構文のみ使用可能 |
| CASE文制約 | ・複雑なCASE文は注意 ・GROUP BY内での使用制限 |
・シンプルな条件分岐 ・WHERE句での条件指定 |
基本的な条件分岐のみ推奨 |
5. 推奨実装パターン
差分プライバシーの制約は多岐に渡るため、基本的にデータ構造はシンプルな構成が望ましいと考えています。
場合によっては1つのテーブルでなんでもやれるようにするよりは分割してそれぞれ運用する、複数のテーブルでの結合は可能な限り避けるといったことを留意して実装するのがベストと考えています。
| パターン | 説明 | 具体例 |
|---|---|---|
| シンプル集計 | ・単一の集計関数 ・明確な範囲指定 ・DP_INTERVAL関数使用 |
SELECT COUNT(DISTINCT id), DP_INTERVAL_LOW/HIGH() |
| 範囲分析 | ・個別クエリに分割 ・明確な範囲指定 ・シンプルな条件 |
WHERE value BETWEEN x AND y |
| テーブル結合 | ・エンティティキーでの結合 ・シンプルな結合条件 ・事前の範囲制限 |
JOIN ON entity_key |
| 1テーブル化 | ・エンティティキーの明確化 ・結合による複雑化の回避 |
顧客マスタと履歴データのデータマート |
| 目的テーブル化 | ・エンティティキーの明確化 ・結合による複雑化の回避 |
目的に合わせたデータマートを複数用意 1テーブル辺りのプライバシー保護強度を緩和 |
結論：Snowflake差分プライバシー機能の実践的評価
検証を通じた総合的な評価
本検証を通じて、Snowflakeの差分プライバシー機能は、データプライバシーの保護と分析ニーズの両立において、大きな可能性と同時に実務上の様々な考慮点があることが明らかになりました。
機能の本質的な価値
差分プライバシーは、個々のレコードの特定を困難にしながら、全体的な傾向やパターンを分析可能とする革新的なアプローチを提供します。
特に
- 統計的な分析精度を維持しながらプライバシーを保護
- プライバシー保護レベルを定量的に管理
- データ利活用の新たな可能性を開拓
という点で、データ駆動型の意思決定とプライバシー保護の両立を目指す組織にとって、有力なソリューションとなり得ます。
実装時の現実的な課題
一方で、本機能の効果的な活用には、以下のような実務上の制約や課題への適切な対応が必要です。
- クエリパターンの大幅な制限と複雑化 ⇒一般的な分析アウトプットを出すのは難しい
- パフォーマンスへの影響（基本的な遅延の発生） ⇒差分保護処理を挟むため、8秒程度の滞留が発生
- 結合操作時の予期せぬ挙動や制限 ⇒極力1テーブル化が望ましい
- エンティティ設計の重要性と難しさ ⇒不要項目の除外、匿名加工処理、文字列ではなく、数値型
- ε（プライバシー保護強度）の非開示 ⇒Snowflakeにお任せで良いと割り切れるかどうか
今後の展望
差分プライバシーは、データプライバシーの保護と活用のバランスを取る上で、重要な選択肢の一つとなっています。しかし、その効果的な活用には、技術的な理解だけでなく、ビジネスニーズとの適切なバランス、そして運用面での十分な準備が必要です。
本検証で得られた知見は、差分プライバシーの実装を検討する組織にとって、より現実的な期待値の設定と、効果的な実装計画の立案に寄与するものと考えられます。
最後に
差分プライバシーは、プライバシー保護技術として大きな可能性を秘めていますが、現時点では一定の制約や課題も存在します。これらを十分に理解した上で、適切なユースケースを選択し、段階的に導入を進めていくアプローチが、実務での成功につながると考えられます。
本検証を通じて得られた知見が、差分プライバシーの実践的な活用を検討する組織の一助となれば幸いです。
なお、外部公開するサービスや統計出力に特化したDB構築など様々な活用も模索しましたが、集計ポリシーなどとの併用が難しいため、入力⇒出力⇒ノイズ混入⇒集計加工といったステップが必要だと考えています。そのため、サービス全体でのアプリケーション的な制御を行う必要があります。
単純にテーブルにポリシーを当てればよいと言う訳ではなく、データ活用とプライバシー保護を両立させるために各プライバシー保護機能やその適用方法や順序などを十分に検討する必要があります。
そういう意味ではSnowflake自身が提供しているデータクリーンルーム機能が拡充されるとこのような詳細な制御の検討からある程度解放されると考えており、クリーンルームの更なる拡張を期待したいと考えております。
またそのようなサービスの進化と並行して、各プライバシー保護機能がより柔軟で強固な進化を遂げてくれるとさらに柔軟なデータ活用の実現をプライバシー保護を両立して実現出来る可能性が高まると考えています。
次の記事に向けて
さて、私のプライバシー保護機能のまとめもこれで一段落というところですが、一周回ってみて気付いた点も多く、より深堀したい気持ちもある一方、よりセキュアな仕組みを実現するためにsnowflakeのデータクリーンルームをさらに知りたいとも考えています。
またプライバシー保護機能やデータクリーンルームに限らず、もっともっとsnowflakeを理解し、さらにさらに事業に貢献出来る基盤を実現するための学びをシェアしていきたいと考えています。
最近の様々な機能アップデートやリリース、あまり触れていない、streamlitやCortexAIなど偉大な先輩方の記事を参考に自分でも試していきたいと考えていますので、次の記事のテーマはまだ定めていませんが、興味の赴くままに色々探索してきたいと思います！
Discussion