複雑なパイプラインを構築せずに、運用データとともに分析データのリアルタイム クエリを実行するには、AlloyDB for PostgreSQL
でレイクハウス フェデレーションを使用します。bigquery_fdw 拡張機能を利用して、AlloyDB はクエリを BigQuery
にルーティングし、BigLake 外部テーブルを介してライブデータや Apache Iceberg などのオープン フォーマットにアクセスします。これにより、複雑な
ETL（抽出、変換、読み込み）移行が不要になります。
レイクハウス フェデレーションのメリット
レイクハウス フェデレーション アプローチには、次の利点があります。
- ゼロ ETL: 複雑なパイプラインを構築または維持することなく、分析データを直接クエリできます。
- 使い慣れた構文: 標準の PostgreSQL 構文を使用して BigQuery データをクエリできます。
- リアルタイムの分析情報: 運用テーブルとともに最新データにアクセスできます。
- コンピューティングのオフロード: プッシュダウン最適化により、BigQuery 分散エンジンを使用して負荷の高い処理を行います。
- 承認されたアクセス: 承認されたサービス アカウントのみが外部データをクエリできるように、Identity and Access Management（IAM）を使用してアクセス制御を一元化します。
ユースケース
レイクハウス フェデレーションは、次のビジネス ユースケースと技術ユースケースをサポートしています。
- ハイブリッド トランザクション処理 / 分析処理（HTAP）ワークロード: トランザクションのパフォーマンスに影響を与えることなく、AlloyDB のリアルタイム運用データと BigQuery または Cloud Storage の履歴データまたは分析データを同時にクエリできます。
- 脆弱なパイプラインを使用しないリアルタイムの分析情報: 従来の ETL プロセスのレイテンシと障害モードを回避できます。最新の分析データに即座にアクセスして、最新の情報に基づいてビジネス上の意思決定を行うことができます。
- エージェント ワークフローのデータ具体化: 外部の分析データを AlloyDB に具体化して、AlloyDB カラム型エンジンと AlloyDB AI 機能を使用できます。これにより、フェデレーション データに対して、高パフォーマンスのベクトル検索、ML エンベディング、高度な AI 主導のエージェント ワークフローが可能になります。
アーキテクチャとデータフロー
次の図は、レイクハウス フェデレーションを使用する場合のデータの流れとコンポーネントの相互作用を示しています。
次に、AlloyDB のレイクハウス フェデレーションのデータフロー プロセスについて説明します。
- クエリの送信: 標準の PostgreSQL クエリを AlloyDB インスタンスに送信します。
- クエリのプランニングと最適化: AlloyDB クエリ プランナーは、BigQuery 外部データラッパー（FDW）を使用して外部の BigQuery データセットにマッピングされたテーブルを識別します。
- プッシュダウン最適化: AlloyDB は、特定のフィルタと集計を BigQuery に直接プッシュダウンすることでクエリを最適化します。 これにより、ネットワークは関連するフィルタリングされた行または事前集計された要約のみを転送します。
- 実行と取得: BigQuery はクエリの一部を実行します。BigQuery の組み込みストレージを直接スキャンするか、Cloud Storage に保存されている Apache Iceberg テーブルを読み取り、結果のデータセットを AlloyDB にストリーミングします。
- 最終処理とレスポンス: AlloyDB は外部データをローカルの運用テーブルと結合し、残りのクエリ処理を完了して、最終結果をアプリケーションに返します。
連携クエリのデータ型の考慮事項
レイクハウス フェデレーションを使用して AlloyDB から外部の BigQuery テーブルをクエリすると、AlloyDB クエリ プランナーは BigQuery データ型を対応する PostgreSQL データ型として解釈します。これらのマッピングを理解することは、正しいクエリを作成し、bigquery_fdw 拡張機能で使用される外部テーブル定義を作成するうえで重要です。
BigQuery データ型に直接マッピングがない場合や、特別な処理が必要な場合は、クエリ内で明示的な CAST 関数を使用するか、互換性のある型でデータを表示するビューを BigQuery に作成する必要があります。
サポートされているデータ型とその対応する PostgreSQL 型のリストについては、データ型のマッピングをご覧ください。
セキュリティとアクセス制御
AlloyDB から BigQuery データへのアクセスは IAM で管理されます。クエリを実行できるデータセットとテーブルを定義するには、AlloyDB クラスタ サービス アカウントに特定の IAM ロールを付与する必要があります。これにより、セキュリティを損なうことなく、連携クエリが組織の一元化されたデータガバナンス ポリシーに準拠していることを確認できます。詳細については、 必要なロールをご覧ください。
プッシュダウン
フィルタと集計のプッシュダウン手法を使用すると、AlloyDB に移動または処理される前に BigQuery でデータをフィルタリングまたは集計することで、クエリを高速化し、費用を削減できます。このアプローチでは、ネットワーク トラフィックとメモリ使用量を最小限に抑え、リソース上限を超過することなく、大規模なデータセットを迅速かつ効率的に分析できます。
フィルタ プッシュダウン
フィルタ プッシュダウン（述語プッシュダウンとも呼ばれます）は、クエリフィルタ（WHERE 句を使用）を AlloyDB から BigQuery に移動することで、データのフィルタリングをストレージ レイヤにできるだけ近づける最適化手法です。
フィルタ プッシュダウンを使用すると、WHERE 句を含む SQL クエリを使用して、リモートテーブルからデータのサブセットにアクセスできます。このデータは、ローカルテーブルで具体化することも、PostgreSQL
テーブルにローカル パーティションとしてアタッチすることもできます。
フィルタ プッシュダウンでサポートされているオペレーションは次のとおりです。
- 標準の比較演算子:
=、<、>、<=、>=、<> - 論理演算子:
AND、OR、NOT - パターン マッチング:
LIKE、NOT LIKE - Null チェック:
IS NULL、IS NOT NULL - リスト内評価:
IN、NOT IN
集計プッシュダウン
集計プッシュダウン は、SUM、COUNT、AVG、GROUP BY などの計算をストレージ
レイヤにできるだけ近づけて実行する高度なデータベース最適化です。このプッシュダウンは、BigQuery
で集計関数を直接評価します。これにより、AlloyDB に返される行数を大幅に削減できます。
集計プッシュダウンでサポートされているオペレーションは次のとおりです。
SUMCOUNTAVGMINMAX
上限プッシュダウン
上限プッシュダウン （OFFSET プッシュダウンを含む）は、クエリの LIMIT 句と OFFSET 句を AlloyDB から
BigQuery に移動する最適化手法です。
これにより、BigQuery はリクエストされた行の特定のサブセットのみを返すため、ネットワーク トラフィックとクエリのレイテンシが大幅に削減されます。
上限プッシュダウンは、可能な限り自動的に適用されます。次の条件が満たされていることを確認してください。
- クエリで
FETCH FIRST句のWITH TIESオプションを使用していない。 LIMIT式とOFFSET式は、リモートで評価できる基本的な定数または式である。
BigQuery の費用と請求
BigQuery 外部データラッパーは、次のものに依存します。
- BigQuery コンピューティングの料金
- BigQuery Storage API の料金
詳細については、BigQuery の料金をご覧ください。
ランタイム プロジェクト
BigQuery では、データを 1 つのプロジェクトに保存し、別のプロジェクトでクエリを実行できます。クエリを実行してコンピューティング費用が発生するプロジェクトは、ランタイム プロジェクト （または課金プロジェクト）と呼ばれます。
ランタイム プロジェクトをデータ ストレージ プロジェクトから分離することで、コンピューティング費用を特定の費用センターに分離し、割り当てを個別に管理し、基盤となるデータを移動せずにさまざまなワークロードの支出を管理できます。
BigQuery データにアクセスするように AlloyDB を構成する場合は、サーバーレベル（関連するすべての外部テーブルに適用）または個々のテーブルレベルでランタイム プロジェクトを指定できます。ランタイム プロジェクトを指定しない場合、AlloyDB はデフォルトでデータを所有するプロジェクトを使用します。
制限事項
AlloyDB と BigQuery ではデフォルトの照合順序が異なる場合があり、2 つのシステム間でデータの並べ替えや文字列比較の結果が異なることがあります。たとえば、バージョン 15、16、17 のデフォルトの PostgreSQL 照合順序では、Unicode コードポイントに基づいて文字列を厳密に評価する BigQuery のデフォルトの照合順序とは異なり、並べ替え時に大文字と小文字が区別される場合があります。
BigQuery でリモートで実行されるクエリの部分では、照合順序は BigQuery の設定に従います。照合順序の競合を減らすには、AlloyDB で ICU を使用しない
C.UTF-8照合順序を使用し、BigQuery でデフォルト（空）の照合順序を使用することを検討してください。プッシュダウン後に BigQuery から大量のデータを返すクエリは 最適化されません。
外部テーブルを作成する場合、AlloyDB はリモート BigQuery テーブルの存在またはスキーマを積極的に検証しません。
連携クエリで大量のデータを読み取る必要がある場合（フィルタ プッシュダウンを適用できない場合など）、BigQuery API レスポンス サイズの上限によりクエリが失敗する可能性があります。BigQuery の最大レスポンス サイズの上限は引き続き適用されます。これらの上限の詳細については、割り当てと上限をご覧ください。
PostgreSQL は中間計算の精度が高く、BigQuery は小数点の精度を厳密に管理します。この違いにより、複雑な計算中に精度が失われたり、オーバーフロー エラーが発生したりする可能性があります。詳細については、10 進数型をご覧ください。
Database Migration Service では、
bigquery_fdw拡張機能を使用して作成された外部テーブルの移行はサポートされていません。回避策として、移行ジョブから外部テーブルを除外するか、移行を開始する前に外部テーブルを削除し、移行が完了したら移行先の AlloyDB クラスタで再作成します。bigquery_fdw拡張機能を使用して外部テーブルをクエリすると、BigQuery は AlloyDB クラスタ サービス アカウントに基づいてデータアクセス権限を評価します。データベース ユーザーが IAM データベース認証を使用してログインしても、個々の IAM ユーザー権限はリモート BigQuery テーブルに対してチェックされません。 詳細については、AlloyDB に BigQuery データセットへのアクセス権を付与するをご覧ください。