複雑なパイプラインを構築せずに、運用データとともに分析データのリアルタイム クエリを実行するには、AlloyDB for PostgreSQL でレイクハウス連携を使用します。bigquery_fdw 拡張機能を活用することで、AlloyDB はクエリを BigQuery にルーティングし、BigLake 外部テーブルを介してライブデータや Apache Iceberg などのオープン フォーマットにアクセスします。これにより、複雑な ETL（抽出、変換、読み込み）移行が不要になります。
また、BigQuery を介してクエリ実行をルーティングせずに、Cloud Storage に保存されている Apache Iceberg テーブルや Lakehouse ランタイム カタログに登録されている Apache Iceberg テーブルに対してクエリを実行するには、AlloyDB カラム型エンジンを使用します。詳細については、AlloyDB から Iceberg データにアクセスするをご覧ください。
レイクハウス連携のメリット
レイクハウス連携アプローチには、次の利点があります。
- ゼロ ETL: 複雑なパイプラインを構築または維持することなく、分析データを直接クエリします。
- 使い慣れた構文: 標準の PostgreSQL 構文を使用して BigQuery データをクエリします。
- リアルタイムの分析情報: オペレーション テーブルとともに最新のデータにアクセスできます。
- コンピューティングのオフロード: BigQuery 分散エンジンを使用して、プッシュダウン最適化による重い処理を実行します。
- 承認済みアクセス: 承認されたサービス アカウントのみが外部データをクエリできるようにするには、Identity and Access Management（IAM）を使用してアクセス制御を一元化します。
ユースケース
レイクハウス連携は、次のビジネス ユースケースと技術ユースケースをサポートしています。
- ハイブリッド トランザクション / 分析処理（HTAP）ワークロード: トランザクションのパフォーマンスに影響を与えることなく、AlloyDB のリアルタイム運用データと BigQuery または Cloud Storage の履歴データまたは分析データを同時にクエリできます。
- 脆弱なパイプラインを使用しないリアルタイムの分析情報: 従来の ETL プロセスのレイテンシと障害モードを回避できます。最新の分析データに即座にアクセスして、最新の情報に基づいてビジネス上の意思決定を行うことができます。
- Agentic Workflows のデータ マテリアライズ: 外部分析データを AlloyDB にマテリアライズして、AlloyDB カラム型エンジンと AlloyDB AI 機能を使用できます。これにより、連携データに対して高パフォーマンスのベクトル検索、ML エンベディング、高度な AI 駆動型エージェント ワークフローを実行できます。
アーキテクチャとデータフロー
次の図は、レイクハウス連携を使用する場合のデータの流れとコンポーネントの相互作用を示しています。
AlloyDB のレイクハウス連携のデータフロー プロセスは次のとおりです。
- クエリの送信: 標準の PostgreSQL クエリを AlloyDB インスタンスに送信します。
- クエリの計画と最適化: AlloyDB クエリ プランナーは、BigQuery 外部データ ラッパー（FDW）を使用して、外部 BigQuery データセットにマッピングされているテーブルを識別します。
- プッシュダウン最適化: AlloyDB は、特定のフィルタと集計を BigQuery に直接プッシュダウンすることで、クエリを最適化します。これにより、ネットワークは関連するフィルタされた行または事前集計されたサマリーのみを転送します。
- 実行と取得: 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 に移動することで、データのフィルタリングをストレージ レイヤにできるだけ近づける最適化手法です。
フィルタの pushdown を使用すると、WHERE 句を含む SQL クエリを使用して、リモート テーブルからデータのサブセットにアクセスできます。このデータは、ローカル テーブルでマテリアライズすることも、ローカル パーティションとして PostgreSQL テーブルにアタッチすることもできます。
フィルタのプッシュダウンでサポートされているオペレーションは次のとおりです。
- 標準の比較演算子:
=、<、>、<=、>=、<> - 論理演算子:
AND、OR、NOT - パターン マッチング:
LIKEとNOT LIKE - null チェック:
IS NULLとIS NOT NULL
集計プッシュダウン
集計プッシュダウンは、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 では、あるプロジェクトにデータを保存し、別のプロジェクトでクエリを実行できます。クエリを実行してコンピューティング費用が発生するプロジェクトは、ランタイム プロジェクト（または課金プロジェクト）と呼ばれます。
ランタイム プロジェクトをデータ ストレージ プロジェクトから分離することで、コンピューティング費用を特定のコストセンターに分離し、割り当てを個別に管理して、基盤となるデータを移動することなく、さまざまなワークロードにわたる支出を制御できます。
BigQuery データにアクセスするように AlloyDB を構成する場合、ランタイム プロジェクトをサーバーレベル（関連するすべての外部テーブルに適用）または個々のテーブルレベルで指定できます。ランタイム プロジェクトを指定しない場合、AlloyDB はデフォルトでデータを所有するプロジェクトを使用します。
制限事項
AlloyDB と BigQuery では、デフォルトの照合順序が異なる場合があります。これにより、2 つのシステム間でデータの順序付けや文字列の比較結果が異なる場合があります。たとえば、バージョン 15、16、17 のデフォルトの PostgreSQL 照合順序では、並べ替え時に大文字と小文字の区別が BigQuery のデフォルトの照合順序とは異なる方法で処理される場合があります。BigQuery のデフォルトの照合順序では、Unicode コードポイントに基づいて文字列が厳密に評価されます。
BigQuery でリモートで実行されるクエリの部分については、BigQuery の設定に従って照合が行われます。照合の競合を減らすには、AlloyDB で ICU を使用しない
C.UTF-8照合を使用し、BigQuery でデフォルト（空）の照合を使用することを検討してください。プッシュダウン後に BigQuery から大量のデータを返すクエリは最適化されません。
外部テーブルを作成するときに、AlloyDB はリモート BigQuery テーブルの存在やスキーマを積極的に検証しません。
連携クエリで大量のデータを読み取る必要がある場合（フィルタのプッシュダウンを適用できない場合など）、BigQuery API のレスポンス サイズの上限によりクエリが失敗することがあります。BigQuery の最大レスポンス サイズの上限は引き続き適用されます。これらの上限の詳細については、割り当てと上限をご覧ください。
PostgreSQL と BigQuery では、10 進数の精度、除算、中間計算の処理方法が異なります。これらの違いにより、複雑な計算中に丸め誤差、精度の低下、オーバーフロー エラーが発生する可能性があります。詳細については、10 進数型と算術演算子をご覧ください。
Database Migration Service は、
bigquery_fdw拡張機能を使用して作成された外部テーブルの移行をサポートしていません。回避策として、移行ジョブから外部テーブルを除外するか、移行を開始する前に外部テーブルを削除して、移行の完了後に移行先の AlloyDB クラスタで再作成します。bigquery_fdw拡張機能を使用して外部テーブルをクエリすると、BigQuery は AlloyDB クラスタ サービス アカウントに基づいてデータアクセス権限を評価します。データベース ユーザーが IAM データベース認証を使用してログインしても、個々の IAM ユーザー権限はリモート BigQuery テーブルに対してチェックされません。詳細については、AlloyDB に BigQuery データセットへのアクセス権を付与するをご覧ください。