Andrew Tanによる
本当の問題を見つけられない監査
以下は、規制業界で四半期ごとに繰り返される光景です。
コンプライアンスチームがガバナンススキャンを実行します。データカタログには、すべてのData Warehouseテーブルに分類タグが表示されています。Lakehouseには列レベルのセキュリティポリシーが適用されています。BIツールは行レベルのアクセスを強制しています。全員が承認に署名します。監査人は満足して去ります。
一方、CDCフィードは、トランザクショナルデータベースから分析クラスターへ顧客のPIIをレプリケートしています。誰もストリーム自体を分類していませんでした—分類したのは宛先テーブルで、それ自体は問題ありません。ただし、ストリームは3つの異なるサービスがサブスクライブするstagingトピックを通過します。そのうちの1つは、データの断片を外部のLLM APIに送信するAIエンリッチメントジョブです。そのAPI呼び出しはデータカタログに表示されません。なぜなら、カタログは着信したものだけを登録し、移動中のものは登録しないからです。
ガバナンスプログラムは静止状態では完璧です。移動中にはほとんど目が見えていません。
これはツールの失敗ではありません。カテゴリの誤りです。私たちは、データがテーブルやファイルに存在し、エンドポイントを制御できれば物語をコントロールできるという仮定の上にガバナンスを構築してきました。しかし、現代のパイプラインはそのようには機能しません。データは絶えず移動しています—ブローカーを横切り、変換を通過し、モデルトレーニングセットに入り、パートナーAPIへ送出されます—そして、ほとんどのガバナンスフレームワークはそれに追いついていません。
なぜ静止データ向けガバナンスが難しいケースを見逃すのか
バッチ時代のガバナンスは、バッチ時代のアーキテクチャに合っていました。データはスケジュールされたロードで移動しました。いつ到着するかわかっていました。誰かがクエリを実行する前に、スキャン、分類、ポリシー適用ができました。パイプラインは基本的に配送トラックであり、ガバナンスは積み込みドックで行われました。
StreamingとCDCはそのモデルを破壊しました。データは継続的に移動します。移動中にジョインされます。外部サービスによってエンリッチされます。ガバナンス対象の宛先に到達する前に、フィルタリング、分割、複数のコンシューマーへのルーティングが行われます。データが着陸するまでに、機密部分はすでに漏洩、コピー、カタログに見えない場所へ送信されている可能性があります。
この欠陥は、具体的で痛みを伴う形で現れます：
着陸後の分類は、しばしば手遅れです。CDCストリームがマスクされていないクレジットカード番号を3つの中間トピックを経由してData Warehouseに運ぶ場合、Data Warehouseの列レベルポリシーは上流で起こった出血に対するばんそうこうに過ぎません。
バッチガバナンスツールは、ストリーミングのセマンティクスを理解しません。データカタログはテーブル内に何があるかを教えてくれます。しかし、ストリーミングジョインが1つのトピックからPIIを取得し、別のトピックから行動データと相関させて、誰もレビューしていない新しい複合データセットを作成していることを教えてくれません。
Lineageは継ぎ目で途切れます。ほとんどのLineageツールはテーブル間の関係を追跡します。しかし、パイプラインの途中でレコードをエンリッチするAPI呼び出し、ストリームのスナップショットでトレーニングされるモデル、派生データをCRMに戻すリバースETLジョブまでは追跡しません。実際のライフサイクルを通じてレコードを追うまで、地図は完全に見えます。
保持ポリシーは、移動中のコピーを無視します。Data Warehouseに90日間の保持期間を設定しました。素晴らしい。しかし、Elasticsearchにビューをマテリアライズしたストリームコンシューマーは？リプレイのためにパイプラインが書き込むS3バケットは？コピーを受け取ったパートナーAPIは？保持は最も弱いレプリカで決まり、ほとんどのガバナンスプログラムはレプリカの所在を把握していません。
モーション内ガバナンスが実際に意味するもの
ガバナンスをパイプライン内に移すことは、データカタログやLakehouseセキュリティモデルを置き換えることを意味しません。データが実際に移動している場所までポリシー施行を拡張することを意味します。
重要な4つの機能は以下の通りです：
境界でのポリシー
データが到着してから分類するのではなく、パイプラインに入る時点で分類します。顧客データベースからのCDCフィードは、PII、財務データ、健康記録などの分類タグを携行すべきであり、これらのタグはあらゆるreshape、ジョイン、ルーティング判断を通じて持続すべきです。下流のコンシューマーがタグ付きデータを未承認の宛先に送信しようとした場合、パイプラインはそれをログに記録して先に進むのではなく、ブロックすべきです。
これは自明に聞こえますが、ほとんどのパイプラインはそうしていません。ガバナンスに重要なメタデータ—分類、同意フラグ、保持要件—は通常、正規化中に取り除かれるか、ランタイムが参照しない別のカタログに格納されています。
高リスクフローの承認ゲート
一部のデータ移動は、再確認なしには行われるべきではありません。新しいテーブルを外部分析ツールにレプリケートし始めるパイプライン。位置情報データを含む新しく追加された列を含み始めるストリーム。顧客のトランスクリプトをサードパーティモデルに送信したいAI Workflow。
これらは失敗ではありません。通常の運用です。しかし、ガバナンスリスクが集中する瞬間でもあります。正しいモデルは、すべてをブロックしてチケットを待つのではありません。低リスクのフローは自動的に進め、高リスクのフローに承認フラグを立てることです—そして、その承認ゲートはエンジニアが使うか使わないかわからない別のWorkflowツールではなく、パイプライン自体に組み込まれるべきです。
データに追従する保持と削除
顧客が忘れられる権利を行使した場合、または保持期間が満了した場合、その要求はData Warehouseテーブルだけでなく、データのすべてのコピーに届く必要があります。それには、ストリームリプレイ、マテリアライズドビュー、モデルトレーニングスナップショット、パートナーAPIキャッシュが含まれます。
実践的には、これはパイプラインランタイムがデータがどこに送信されたかを追跡し、レコードのIDとそのレプリカ間のマッピングを維持する必要があることを意味します。ほとんどのストリーミングプラットフォームはこれを行いません。各メッセージを独立したものとして扱い、どこから来たのか、どこへ行ったのかの記憶を持ちません。モーション内ガバナンスは異なるモデルを必要とします：メッセージがIDを携行し、ランタイムがprovenanceを維持します。
テーブルだけでなく変換も含むLineage
テーブル間Lineageはバッチパイプラインには有用です。しかし、StreamingやCDCには不十分です。特定のエンリッチメントステップがサードパーティデータを追加したこと、ジョインが本来分離すべきだった2つのデータセットを相関させたこと、フィルターがコンプライアンスのために保持すべきレコードを静かにドロップしたことを知る必要があります。
つまり、Lineageはクエリログの事後スキャンではありません。ランタイムに組み込まれ、各ステップがデータに何をしたかを発生時に捕捉する必要があります。
ロールアウトの道筋：インターフェイスから始める
誰も1つのプロジェクトでガバナンスモデルを作り直すことはありません。成功するチームは小さく始めて拡張します。
適切な出発点はパイプラインの境界—データがシステムに入るまたは出るポイント—です。本番データベースからのCDCフィード。外部サービスへのAPI呼び出し。運用ツールにデータを戻すリバースETLジョブ。これらは最もリスクが高く、可視性が高いインターフェイスであり、ガバナンスの失敗が最初に現れる場所です。
1つのインターフェイスを選びます。ソースで分類タグ付けを追加します。データが出る前にポリシーチェックを追加します。その1つのフローにLineage追跡を追加します。機能することを証明します。次のインターフェイスに拡張します。
うまく行っていると見るチームに共通する特徴は、ガバナンスをドキュメントの問題ではなくランタイムの問題として扱うことです。ポリシーはWikiに書かれて期待されるのではありません。パイプラインによって施行され、CIでテストされ、コードと共にバージョン管理されます。ポリシーが変われば、パイプラインも変わります。パイプラインが変われば、ポリシーは再検証されます。
言うほど簡単ではない理由
障害について正直に言いたいと思います。「ガバナンスをパイプラインに移せばいい」は言うは易し行うは難しだからです。
既存のツールはそれ向けに構築されていません。ほとんどのデータカタログ、セキュリティスキャナー、LineageツールはバッチData Warehouse向けに設計されました。継続的なストリームではなく、スケジュールされたスキャンを想定しています。トピックではなく、テーブルを想定しています。これらをモーションをカバーするように拡張することは通常、ベンダーがサポートしていないカスタム統合作業を意味します。
パフォーマンスは重要です。ストリーミングパイプラインに分類チェック、ポリシー参照、Lineageロギングを追加すると、レイテンシが増加します。高スループットのフローでは、オーバーヘッドは無視できる必要があります—つまり、ポリシー判断はキャッシュされるか、非同期に評価されるか、クリティカルパスをブロックしないパイプラインのエッジに押し出される必要があります。
組織的な所有者が曖昧です。データガバナンスはしばしば、パイプラインコードを書かないコンプライアンスチームが所有しています。プラットフォームエンジニアリングはランタイムを所有しますが、ポリシーは設定しません。これらのチームが「モーション内ガバナンス」が何を意味するか、誰が保守し、壊れたときに誰がページされるかで合意することは、技術的実装よりも難しいことがよくあります。
標準はまだ形成中です。ストリーミングレコードにガバナンスメタデータを付加するための普遍的なプロトコルはありません。パイプラインポリシー施行のための標準APIもありません。ベンダーは独自のモデルを構築しており、相互運用性は低いです。特定のアプローチに賭けるなら、それは部分的にどのベンダーのモデルが勝つかに賭けることでもあります。
layline.ioが位置づける場所
私たちがこれのすべてを解決していると仮装するつもりはありません。layline.ioでは、ランタイムレイヤーに焦点を当ててきました：バッチとストリーミングの両方に対応する処理エンジンで、メタデータを変換を通じて携行し、パイプライン境界でポリシーを施行し、フルフロー全体でLineageを維持できます。
私たちの賭けは、ガバナンスがパイプラインの隣に座ってログを解析し、すべてを捕捉できることを願う別のシステムであるべきではないということです。それはパイプライン自体の一部であるべき—データを移動する同じランタイムに組み込まれ、それを変換する同じコードパスによって施行され、パイプラインが健全かどうかを教えてくれる同じ可観測性レイヤーで可視化されるべきです。
これは重要です。なぜなら、代替案は断片化だからです。カタログ作成用の1つのツール、Streaming用の別のツール、バッチ用の別のツール、Lineage用の別のツール、ポリシー管理用の別のツール。各統合ポイントは、ガバナンスが漏れ出す継ぎ目です。話をするチームは、継ぎ目にうんざりしています。
この方向性に取り組んでいるのは私たちだけではありません。Confluentはストリームガバナンスを推進しています。Airbyteはデータ主権をアーキテクチャの問題として位置づけています。市場全体が同じ結論に向かっています：移動中のデータには、静止データと同じコントロールが必要です。私たちはそのスタックの一部を構築しています。
ガバナンスチームに尋ねるべき質問
次にコンプライアンスチームがクリーンな監査に承認を与えたとき、こう尋ねてください：
「本番データベースとData Warehouseの間で、顧客のPIIがどこを通るか示してもらえますか？エンドポイントではなく、経路です。すべてのトピック、すべてのエンリッチメント呼び出し、すべてのレプリカを。」
答えが2つのボックスと1本の矢印の図なら、あなたにはガバナンスがありません。希望があるだけです。
良い知らせは、修正のためにすべてを根こそぎ入れ替える必要がないことです。必要なのは、制御点を宛先から経路に移すことです。境界から始めましょう。パイプラインにポリシーを追加しましょう。Lineageをランタイムの一部にしましょう。ツールは改善され、パターンは明確になり、最初にこれを解決したチームは、クリーンな監査だけでなく、より少ないインシデント、より速い復旧、そして実際に信頼できるデータインフラという、真の運用上の優位性を持つことになります。
StreamingまたはCDCパイプラインのガバナンスを検討している場合は、お問い合わせください。私たちはまさにこの問題でチームと協働しており、最初に見えるよりもソリューションは実用的です。
Andrew Tanは、バッチとリアルタイムの両方のワークロードをスケールで処理する企業データ処理インフラを構築するlayline.ioの創設者であり、連続起業家です。
