AWS Clean Roomsの集約分析ルールのクエリ結果コントロールの設定値と集計結果の対応を確認する
データアナリティクス事業本部 機械学習チームの鈴木です。
この記事はAWS Analytics Advent Calendar 2023の13日目の記事になります。
AWS Clean Roomsの集約分析ルールの設定であるクエリ結果コントロールについてご紹介します。
はじめに
AWS Clean RoomsではGlueデータカタログのテーブルを設定し、コラボレーション(ほかのAWSアカウントにデータを連携するための設定)に公開することができます。このとき機密情報が連携されてしまわないように分析ルールを設定し、このルールに従ってデータコンシューマーがデータをルールで許可された自由度で分析・利用することが可能です。
分析ルールのうち、集計結果を利用できるようにする集約分析ルールには、集計軸の中で限られた数のサンプルしかないようなデータについて閾値を設け、個人が特定されてしまうリスクがあるほどに少ない場合はデータを連携しないようにするクエリ結果コントロールの設定があります。
使ってみると何をするオプションなのか分かるのですが、最初はピンと来にくいと思うので、この記事ではどのような挙動になるのか簡単にですがご紹介できればと思います。
クエリ結果コントロールについて
あるカラムで集約する場合に、集約対象のカラムのデータのバリエーションがいくつ以上あれば、コラボレーター側のクエリで集約結果を表示するかを指定できるオプションです。
以下のガイドで紹介されています。
また、分析ルールのベストプラクティスとして、以下のガイドで紹介もされています。
ベストプラクティスからは、行レベルの値が機密であるすべての列にクエリ結果コントロールを追加することが重要になります。外部のデータと結びつけることで個人が特定できてしまう場合にコンプライアンスを遵守できなくなる可能性があります。
クエリ結果コントロールを使えば、このリスクがあるような集計の場合に、下限値を設定し、そもそもデータを連携しないようにすることでリスクを軽減することができます。
なお、このようなリスクを統計的な観点で厳密に対処する機能として差分プライバシーがありますが、AWS Clean Roomsの差分プライバシーの機能は、直近開催されたre:Invent2023期間中にアナウンスされたプレビュー版の機能として提供が開始されております。
テストデータの作成
早速設定値によるクエリ結果を確認して動きを理解しようということで、今回は以下のようにダミーのデータを作成してみました。
pii1,pii2,pii3,class,data1,data2,data3 100000000000000,1985/4/30,東京都新宿区虹ヶ丘,A,1,2,3 100000000000001,1985/5/1,北海道雲の上市星空町,B,5,5,3 100000000000002,1985/5/2,愛知県猫町パウパウ,A,1,2,6 100000000000003,1985/5/3,大分県湯けむり温泉,B,1,2,3 100000000000004,1985/5/4,広島県平和市希望ヶ丘,A,5,4,3 100000000000005,1985/5/5,神奈川県横浜市風の谷,B,1,2,3 100000000000006,1985/5/6,宮城県仙台市光の森,B,1,2,3 100000000000007,1985/5/7,青森県りんご市甘味,B,3,2,8 100000000000008,1985/5/8,福岡県博多市美食町,B,1,2,3 100000000000009,1985/5/9,沖縄県青い海市サンゴレーン,B,1,4,3 100000000000010,1985/5/10,京都府神社市巫女ヶ丘,B,1,2,3 100000000000011,1985/5/11,兵庫県姫路市城下町,A,1,2,3 100000000000012,1985/5/12,鳥取県砂丘市風の子,A,1,2,7 100000000000013,1985/5/13,島根県神秘市古代町,A,1,6,3 100000000000014,1985/5/14,長野県スキー市雪の谷,A,3,2,3 100000000000015,1985/5/15,山梨県富士市雲の上,A,8,2,5 100000000000016,1985/5/16,岐阜県美濃市こうげつ,A,1,2,3 100000000000017,1985/5/17,三重県伊勢市神宮前,A,1,2,3 100000000000018,1985/5/18,静岡県茶市抹茶,C,1,2,3 100000000000019,1985/5/19,岩手県盛岡市麺の街,C,1,2,5 100000000000020,1985/5/20,茨城県水戸市歴史ヶ丘,C,1,1,3 100000000000021,1985/5/21,栃木県日光市光明,C,1,2,3 100000000000022,1985/5/22,群馬県草津市湯元,A,1,2,3 100000000000023,1985/5/23,山形県酒市米谷,B,3,2,3 100000000000024,1985/5/24,新潟県雪市寒川,A,1,6,2 100000000000025,1985/5/25,富山県魚市海岸線,B,1,2,3 100000000000026,1985/5/26,石川県金沢市茶屋町,A,1,2,3 100000000000027,1985/5/27,福井県恐竜市骨の浜,A,5,2,3 100000000000028,1985/5/28,長崎県五島市島風,B,1,3,9 100000000000029,1985/5/29,熊本県阿蘇市火口,A,1,7,3 100000000000030,1985/5/30,岩手県盛岡市麺の街,B,1,2,3 100000000000031,1985/5/31,茨城県水戸市歴史ヶ丘,A,1,2,3 100000000000032,1985/6/31,茨城県水戸市歴史ヶ丘,D,20,3,2
例えば以下のようにGlueテーブルを作り、集計するとpii2
という明らかに個人情報が入っていそうなカラムのバリエーションは、class
がD
の場合に1件しかないようにしてあります。次いで、class
がC
の場合は4件です。
クエリ結果コントロールの設定値により、コラボレーションに参加しているコンシューマー側のクエリ結果がどう変わるか確認します。
やってみる
1. 集約分析ルールの設定
AWS Clean Roomsに先のGlueテーブルを設定した後、分析ルールを作成しました。
分析ルールタイプの選択
で、今回は集約分析ルールを設定しました。
クエリコントロールを指定
で、検証のため、集約関数とディメンションコントロールを設定しました。
最後にクエリ結果コントロールを指定
で、pii2
のバリエーションが2以上のみのデータを連携するように設定しました。
ちなみに最小は2
になっています。
これで分析ルールを作成しました。以下のようになりました。
2. 集約結果を取得してみる
先ほどの集約分析ルールを設定したテーブルを関連づけたコラボレーションのコラボレーターのAWSアカウントで、先ほどのテーブルをクエリしてみました。
Athenaで実行したものと同じクエリを実行しましたが、class
がD
のデータは出力されていないことが分かりました。この記事を読んでいる方はこのデータを出さないことを知っているので「消えたんだな」という印象だと思いますが、例えばこのことを全く知らないコラボレーターからすると全く気づかずデータを使うこととなります。
3. クエリ結果コントロールを修正してみて影響を確認する
以下のようにpii2
のバリエーションが5以上の場合のみ連携するようにクエリ結果コントロールを修正しました。
再度コンシューマー側でクエリすると、以下のようにclass
がC
のデータも表示されなくなりました。
最後に
AWS Clean Roomsの集約分析ルールの設定であるクエリ結果コントロールについて例を交えてご紹介しました。
参考になりましたら幸いです。