このアーキテクチャは、リアルタイム統計収集を使用したコストベースのオプティマイザーを実装する分散クエリコーディネーターを中心に構築されています。クエリ結果は、ホットデータ用のインメモリキャッシュとプレ集約結果用の分散カラムストレージから成る階層ストレージシステムにキャッシュされます。ポリシー施行ポイントは、基盤となるデータソースを変更することなく、行レベルのセキュリティ述語を挿入するためにすべてのクエリをインターセプトします。
ある多国籍金融機関は、リアルタイムのクレジットカード取引、ローン申請メタデータ、およびモバイルバンキングの行動信号を相関させてクロスプロダクト詐欺を検出する必要がありました。各ドメインチームは異なるリージョンにあるデータを所有しており—クレジットカードはAWS US-East、ローンはAzure Europe、モバイルログはGCP Asia—、中央集権的なデータ統合を防ぐ厳しい規制要件がありました。
中央集権的データウェアハウス: すべてのデータを単一のSnowflakeインスタンスに統合し、夜間にETLパイプラインを実行します。このアプローチは、アクセス制御を中央集権化することによりガバナンスを簡素化し、一貫したクエリ性能を保つことを保証します。ただし、これはドメインの自律性に違反し、チームにデータ所有権を放棄させ、リージョン間のレプリケーションに対して大規模なデータ転送コストを発生させ、リアルタイムの詐欺検出シナリオにおいて古いデータの問題を引き起こします。
基本的なクエリフェデレーション: データを移動することなく、ソースシステムを直接クエリする軽量なPrestoクラスターを展開します。これにより、ドメインの自律性が維持され、重複を避けることによるストレージコストが削減されます。しかし、地域間のネットワークレイテンシのために予測できないパフォーマンスの問題が生じ、知的キャッシングの欠如により再度の高コストスキャンが発生し、異なる認証モデルを持つ異なるソースシステム全体で一貫したセキュリティポリシーを施行できません。
ドメインゲートウェイを持つスマートフェデレーテッドレイヤー: ドメイン指向のデータプロダクトを公開する埋め込まれたOLAPエンジンを持つドメイン固有のAPIゲートウェイを実装し、コストベース最適化を使用してプッシュダウンとキャッシングのどちらを選択するかを決定するグローバルクエリプランナーと組み合わせます。これにより、ドメイン所有権が維持され、ドメインレベルでのマテリアライズドビューとクロスドメイン結果キャッシングによってパフォーマンスが提供されます。このアプローチは運用の複雑さを増加させ、ドメイン間でのデータプロダクト契約の標準化が必要です。
選択された解決策: オプション3が、自律性の要求とパフォーマンスニーズのバランスを取るため選択されました。銀行は、自分たちのゲートウェイを管理できる既存のドメイン指向チームを持っており、このアプローチが運用上実現可能であることを意味しました。さらに、段階的な移行パスにより、ドメインは大きな書き換えなしに徐々にオプトインすることができました。
システムは、95%のクロスドメイン詐欺クエリに対して500ms未満の遅延を達成し、フルレプリケーションと比較してデータ転送コストが70%削減され、EUの顧客データをヨーロッパのリージョン内に保持しながら、米国のアナリストが集約化された匿名化された結果をクエリできるようにすることでGDPRコンプライアンスを維持しました。
高カーディナリティのドメイン（例：取引）と低カーディナリティのドメイン（例：商人カテゴリ）を結合する際、全取引データセットを中央ノードに移動せずにデータの偏りをどのように処理しますか？
小さいデータセットにブロードキャスト結合を、より大きなデータセットにパーティション結合を使用し、結合キーに基づいて一貫したハッシングを行います。クエリオプティマイザーは、ドメインメタデータカタログからカーディナリティ統計を分析し、最適な戦略を自動的に選択する必要があります。偏ったキー自体には、ホットキーを複数のパーティションに分散させるためにソルト技術を適用し、結合後に結果を集計します。これにより、重い処理がデータが存在するドメインノードで行われ、最小限の結合結果だけがネットワークを横断するようになります。
ソースドメイン内の基盤データが頻繁に変更される場合、特にそれらのドメインが変更データキャプチャ（CDC）メカニズムをサポートしていない場合、キャッシュの一貫性をどのように維持しますか？
重要なクエリに対してTTLベースの無効化を伴ったキャッシュアサイドパターンを採用し、チェックサム検証を活用します。CDCを持たないドメインに対しては、観測されたデータの変動パターンに基づいた適応TTLを実装します—頻繁に変更されるテーブルには短いTTLを設定します。バージョンベクターまたは最終変更タイムスタンプを、分散メタデータサービスに保存してキャッシュエントリの検証を行います。クエリが古いキャッシュにヒットした場合、ソースドメインにフォールバックし、キャッシュを非同期に再ポピュレートしてキャッシュスタンピードを防ぎます。
あるドメインがRBAC（役割ベースアクセス制御）を使用し、別のドメインがABAC（属性ベースアクセス制御）を使用し、第三のドメインがネイティブなRLSサポートを持たない場合、ドメイン間で一貫した行レベルセキュリティ（RLS）ポリシーをどのように施行しますか？
セキュリティポリシーを統一ポリシーエンジンに抽象化し、クエリレイヤーでの実行前にポリシーを評価します。ゲートウェイレベルでユーザー属性を標準化されたクレームフォーマット（例：JWTトークン）に変換します。ネイティブなRLSを持たないドメインに対しては、セキュリティ述語を生成されたクエリに注入する仮想化アダプタをデプロイします—ユーザーの権限に基づいてフィルタリングするWHERE句を効果的に追加します。ポリシー評価中のレイテンシペナルティを回避するために、各地域ゲートウェイに分散ポリシーキャッシュを保持し、CI/CD中にポリシーシミュレーションを実施してドメイン固有のルール間の対立を検出します。