Unity CatalogでOpenTelemetryトレースからPIIを秘匿化する
OpenTelemetry(OTel)トレースデータには、Eメールアドレス、電話番号、クレジットカード番号などの個人を特定できる情報(PII)が、スパン属性、ログ本文、およびリソースメタデータに埋め込まれていることがよくあります。このトレースデータをデバッグや可観測性のために広く共有すると、コンプライアンスとプライバシーのリスクが生じる可能性があります。
このページでは、AI FunctionsとLakeflow Spark宣言型パイプラインを使用して、生のOTelテーブルからPII(個人情報)を段階的に匿名化し、その結果をより広範なアクセス制御を持つ別のテーブルセットに書き込むソリューション例について説明します。構成可能な保持ジョブは生データをクリーンアップします。ダウンロード可能なアセットを独自のワークスペースにデプロイし、要件に合わせて調整します。
このソリューションは、OpenTelemetryトレースをUnity Catalogに保存するものを含め、Unity Catalogに保存されている任意のOTelトレースで使用できます。
仕組み

A LakeFlow Spark宣言型パイプラインは、新しいOTelスパンを増分的に読み取り、PII(Eメール、電話番号、SSN、クレジットカード、氏名、住所)を編集するためにai_maskを適用し、編集されたテーブルに書き込みます。スケジュールされたジョブは、生テーブルでのオプションの保持クリーンアップを処理します。
前提条件
- Unity Catalog が有効になっているワークスペース
- サーバレス SQLウェアハウスまたはサーバレス パイプラインを通じて、AI Functions を利用できます。
- Databricks CLI はお客様のワークスペースに認証されています。
- Unity Catalogテーブル内のOTelトレースデータは、MLflow、OTelエクスポーター、または任意のOTLPクライアントを介して書き込まれます。「Unity Catalog に OpenTelemetry トレースを保存する」をご覧ください。
アセットをダウンロードしてください
以下のファイルをダウンロードし、ワークスペースにインポートします:
ファイル | 説明 |
|---|---|
ガイド付きデプロイノートブック: | |
CLI デプロイスクリプト。 | |
パイプライン( | |
スパンおよびアノテーションを結合した統合トレースビュー。 | |
スキーマの作成とアクセス制御の権限付与 | |
例のパイプライン構成 (参照)。 | |
OTelスパンとしてPIIテストデータを送信するテストユーティリティです。 | |
50行の合成PIIテストデータ。 |
詳細については、リファレンス ドキュメントを参照してください。
ソリューションを導入する
次のいずれかのデプロイ方法を選択してください。
- Guided notebook (recommended)
- CLI
- Manual
ワークスペースに直接、段階的にデプロイするには:
- 他のダウンロード済みアセットとともに、deploy_notebook.py をワークスペースにインポートします。Databricks Git フォルダーを参照してください。
- ワークスペースで
deploy_notebook.pyを開きます。 - 上部にあるウィジェットのパラメーター(カタログ、ソーススキーマ、ターゲットスキーマ、およびテーブルのプレフィックス)を入力します。
- 「 すべて実行 」をクリックします。各ステップは続行する前に検証します。
このアプローチは、Databricks Python SDKを使用し(CLIは不要)、安全に再実行でき、各ステップでインタラクティブなフィードバックを提供します。
お使いのワークスペースの詳細を使用してデプロイメントスクリプトを実行してください:
./deploy.sh <WORKSPACE_HOST> <CATALOG> <SOURCE_SCHEMA> <TARGET_SCHEMA> <TABLE_PREFIX>
例えば:
./deploy.sh https://my-workspace.cloud.databricks.com my_catalog traces_raw traces_redacted my_app
スクリプトは次の処理を行います:
- パイプラインのSQLをワークスペースにアップロードします。
- ターゲットスキーマを作成します。
- パイプラインを作成してトリガーします。
- 未加工テーブルの自動TTLを構成します(
retention_daysが設定されている場合)。
パイプラインの完了後、統合トレースビューを作成するためにunified_view.sqlを実行します。${...} 変数を独自の__値__に置き換えます。
ステップを追って設定するには:
- ターゲットスキーマを作成してください。
setup_schema_and_grants.sqlのステートメントを実行します。 - パイプラインSQLをアップロードします。
pii_redaction_pipeline.sqlをワークスペースにインポートします。 - パイプラインを作成
pipeline_config.jsonをテンプレートとして使用し、<PLACEHOLDER>の値を置き換えてください。 - パイプラインの実行をトリガーします。 UIを使用するか、
databricks pipelines start-update <PIPELINE_ID>を実行します。 - 統合ビューを作成してください。 最初のパイプライン実行後に
unified_view.sqlを実行します。 - 保持を構成してください。 生テーブルで自動time-to-liveを有効にする。OTelトレースからのPIIマスキングを参照してください。
パラメーター
以下の表は、ガイド付きデプロイメントノートブック(deploy_notebook.py)にあるウィジェットパラメーターについて説明しています。
パラメーター | 説明 | デフォルト |
|---|---|---|
| 未加工テーブルおよび編集済みテーブルの両方のためのUnity Catalogカタログです。 | (必須) |
| 生OTelテーブルを格納しているスキーマ。 | (必須) |
| 編集済み出力テーブルのスキーマ。 | (必須) |
| OTelテーブル名に使用されるプレフィックス | (必須) |
| マスキングするPIIの種類は、カンマ区切りで、シングルクォーテーションで囲んでください。 |
|
| パイプライン名。 |
|
| 生データを削除するまでの日数。空白の値、 |
|
| パイプライン実行モード: |
|
| パイプラインの実行頻度(トリガーモードのみ): |
|
ソーステーブルは{catalog}.{source_schema}.{table_prefix}_otel_spans、{catalog}.{source_schema}.{table_prefix}_otel_logs、{catalog}.{source_schema}.{table_prefix}_otel_annotationsと命名されます。
パイプラインは2つの実行モードをサポートしています:
- トリガー済み :選択された頻度でパイプラインをトリガーするスケジュールされたジョブが作成されます。パイプラインは、実行ごとに新しいデータを処理し、その後停止します。
- 連続 :パイプラインを継続的に実行し、到着時に新規データを処理します。スケジュールジョブは作成されていません。このモードは、パイプラインが常に実行されているため、トリガーモードに比べてコンピュートコストが高くなります。
何が除外されますか
このパイプラインは、次のフィールドにai_maskを適用します:
テーブル | フィールドは秘匿化されました。 |
|---|---|
スパン |
|
ログ |
|
注釈 | パススルー(PIIは想定されていません) |
パイプラインは、トレースID、スパンID、タイムスタンプ、サービス名、ステータスコードなどの非PIIフィールドをそのまま保持します。
サポートされているPIIカテゴリ
ai_mask LLM を活用しており、email、phone、name、address、ssn、credit_card、ip_address、および date_of_birth を含む標準的な PII タイプを認識します。
ai_mask さまざまなPII形式(例:(555) 123-4567、555.123.4567、または+1 555-123-4567のように書かれた電話番号)を、それぞれのバリエーションに個別のパターンを必要とせずに処理できるため、推奨されます。パイプラインは、regexp_replaceを用いた明示的な正規表現のような、異なる匿名化方法を使用するように調整できます。
カスタム パターン (例: 従業員 ID EMP-XXXXXX) の場合は、パイプライン SQL で ai_mask の前に regexp_replace を使用してください。詳細については、OTelトレースにおけるPIIマスキングのリファレンスを参照してください。
保持とアクセス制御
生データ保持
デプロイは、生OTelテーブルに自動有効期間を設定し、設定可能な日数よりも古いトレースデータを自動的に削除します(デフォルト:90日)。これは、元の目的に不要になった後、個人データの削除を義務付けているGDPRやその他のデータ保護規則の遵守に役立ちます。パイプラインが生のスパンを処理した後、自動TTLにより、保持ポリシーに従ってPIIを含む元のデータが削除されます。別途保持を管理している場合は、自動削除を無効にするには、retention_days を 0 または none に設定します。コンプライアンス要件で厳格な削除期間が求められる場合、正確な自動 TTL 削除のタイミングは保証されないため、代わりに DELETE と VACUUM を使用して手動でスケジュールされたジョブを設定できます。
生のテーブルへのアクセスを制限する
生OTelテーブルにはPIIが含まれており、アクセスを制限する必要があります。デバッグまたはインシデント対応のためにアクセスが必要なパイプラインサービスプリンシパルおよび管理者のみに、元のソーススキーマへのアクセスを付与します。すべての定型的なアナリティクス、ダッシュボード、および可観測性ワークフローは、代わりに編集済みのテーブルをクエリする必要があります。setup_schema_and_grants.sql ファイルには、この分離を徹底するのに役立つ認可の例が含まれています。Unity Catalog の権限に関する詳細については、「Unity Catalog での権限の管理」を参照してください。
秘匿化をテストする
テスト PII データを送信
既知のPIIを含むテストスパンを生成して、マスキングを検証します:
pip install opentelemetry-exporter-otlp-proto-http
python send_pii_traces.py <WORKSPACE_HOST> <CATALOG.SCHEMA.PREFIX_otel_spans>
これにより、Eメール、電話番号、SSN、クレジットカード、名前、および住所を含む50のテストトレースが送信されます。
出力を検証する
パイプラインを実行した後、生の範囲と編集済みの範囲を比較します:
SELECT
s.span_id,
CAST(s.attributes AS STRING) AS raw,
CAST(r.attributes AS STRING) AS redacted
FROM <source_catalog>.<source_schema>.<prefix>_otel_spans s
JOIN <target_catalog>.<target_schema>.redacted_spans r
ON s.trace_id = r.trace_id AND s.span_id = r.span_id
WHERE s.name = 'pii-test-interaction'
LIMIT 5;