鮮度の高いインサイトで迅速な意思決定を – talabat が AWS と Google Cloud で実現したニアリアルタイム分析

本記事は 2026 年 8 月 18 日に公開された「Fresher insights, faster decisions: talabat’s near-real-time analytics across AWS and Google Cloud」を翻訳したものです。

talabat は、中東・北アフリカ (MENA) 地域をリードする日常生活アプリです。レストランや小売店の幅広い選択肢から、食品、食料品、その他の日用品を手軽に注文でき、パーソナライズされた体験を提供しています。2004 年にクウェートで創業した talabat は、アラブ首長国連邦、オマーン、カタール、バーレーン、ヨルダン、イラク、エジプトに事業を拡大し、2025 年 12 月時点で月間アクティブユーザー 700 万人以上にサービスを提供しています。本社はアラブ首長国連邦のドバイにあり、2024 年 12 月にはドバイ金融市場 (DFM) で新規株式公開 (IPO) を完了しました。Delivery Hero SE の子会社として、グローバルな知見を活かしてサービス向上と事業拡大に取り組んでいます。パートナーとライダーのネットワークを通じて、顧客が必要なものを必要なときに届ける、地域全体の日常の利便性を支えています。

本記事では、talabat がハイブリッドなマルチクラウドレイクハウスを構築し、ストリーミングデータの Apache Iceberg コピーを AWS 上に一元的に保持しながら、Google Cloud Platform (GCP) からガバナンスの効いたニアリアルタイム分析を実現した方法を紹介します。

talabat におけるデータ

データは talabat のビジネスの中枢です。顧客が「注文」ボタンを押した瞬間からドアベルが鳴るまで、システムは瞬時にデータドリブンな意思決定を行い、価格設定、配車、ルーティング、注文の不正検知をリアルタイムで最適化しています。長年にわたり、talabat のアプリケーションは 2 つのパブリッククラウドにまたがる環境へと成長しました。トランザクションおよびオペレーション基盤は AWS 上で成熟し、エンジニアリングチームがサービスを構築・運用しています。一方、多数のアナリスト、データサイエンティスト、分析エンジニアリングパイプラインは Google Cloud Platform のウェアハウスである Google BigQuery を標準としています。

どちらへの投資も深く、どちらも価値を生み出しています。戦略的な問いは「どちらのクラウドに統合するか」ではなく「両者の境界をまたいでデータをどうスムーズに流すか」でした。この前提がアーキテクチャ全体を形作っています。課題はクラウド間だけでなくリージョン間にも及びます。AWS サービスは EU リージョンでホストされ、GCP のデータは US リージョンにあります。

次の図は、AWS 上のオペレーションプレーンと GCP 上の分析プレーンの間における talabat のデータフローを示しています。

Data flow between talabat's operational plane on AWS and analytics plane on Google Cloud

図 1: AWS 上のオペレーションプレーンと Google Cloud 上の分析プレーン間のデータフロー

これまでデータエンジニアリングチームは、2 つのクラウド間のデータ移動をオーケストレーションしており、AWS から GCP へ、EU から US への物理的なデータ移動が必須でした。従来の ETL (抽出、変換、ロード) ツールやフレームワークでの移動は、複数のホップを経てデータの遅延と重複を引き起こしていました。具体的には、Amazon Relational Database Service (Amazon RDS) から Amazon Simple Storage Service (Amazon S3) EU AWS リージョンへ、Amazon S3 EU から Amazon S3 US リージョンへ、そして最終的に Amazon S3 US から BigQuery US への移動です。

各ホップはコピーであり、コピーのたびにリスクが積み重なりました。障害点の増加、レイテンシーの累積、冗長なコンピューティングとストレージ、型の忠実性、そして最も重要なのはクロスリージョンおよびクロスクラウドのデータ転送料（エグレスコスト）です。

要するに、従来の設計は自ら作り出した問題、すなわち BigQuery がデータを読めるようにデータを移動するという問題の解決に、コスト、レイテンシー、信頼性の代償を払っていました。典型的なデータウェアハウスのボトルネックです。代わりにオープンデータレイクを使えないか？使えます。しかし分析の利用は BigQuery に集中しており、オープンソースのデータレイク層を通じたアクセスが制限されています。そこで再設計は逆の前提から始めました。AWS にコピーを 1 つ保持し、BigQuery にそのままの場所で読み取らせる。本記事の残りで説明するのは、この talabat のレイクハウスです。

課題

オペレーションシステムは、注文ライフサイクルの変更、ベンダー、メニュー、ロジスティクスやライダーのシグナル、決済情報といったビジネスイベントを継続的にストリームとして発行し、Amazon Managed Streaming for Apache Kafka (Amazon MSK) 上の Apache Kafka にパブリッシュしています。これらのイベントは Protocol Buffers でエンコードされ、Confluent Schema Registry に登録された後方互換スキーマで管理されているため、プロデューサーとコンシューマーが安全に進化できます。

分析側の要件は、簡単に述べられるものの実現は困難です。イベントを正しい型で、生成から数分以内にクエリ可能にし、各チームが既に使っているツールからクエリできるようにすることです。

2 つのクラウドを持つことを技術的負債と見なしがちですが、talabat のようなリアルタイムビジネスにとっては単に地形であり、それぞれの側に本来の強みがあります。

イベント基盤は AWS 上にある。トランザクションおよびストリーミングシステムが Amazon MSK にパブリッシュしている。これらのイベントを最も低レイテンシーかつ低リスクに参照・処理できるのは、同じ AWS リージョン内、イベント基盤のすぐ隣です。
分析基盤は Google Cloud 上にある。何千もの下流のモデルやダッシュボード、そしてそれらを構築する人々が、BigQuery をクエリサーフェスとして前提としています。

どちらか一方に統合するには数年規模のマイグレーションが必要であり、片方のユーザーグループにとっては大幅な機能後退を意味します。単にインジェストと分析の間の継ぎ目を取り除くためだけに。データエンジニアは、その継ぎ目を排除するのではなく設計することに決めました。設計目標は一文にまとまります。データの物理コピーを AWS に 1 つ保持し、両方のクラウドからネイティブに読み取れるようにする。ハイブリッドデータレイクハウスにより、「どちらのクラウドか」という問いはアーキテクチャ上の分岐ではなくアクセスパスの選択肢になります。

最初に試したこと: ホットパス上のクロスクラウド書き込み

最初の試みでは、最終的に採用したフローとは逆のアプローチを取りました。Raw (Bronze とも呼ばれる) レイヤーのデータを AWS から直接 Google Cloud Storage 上の BigQuery マネージド Iceberg テーブルに書き込みました。理論上、最大の参照者基盤に最も近い場所にデータが配置されます。しかし実際には、常時稼働のストリーミングパスでクラウドをまたいで書き込むことで、長期的に許容できない問題が生じました。

インジェストパスにおけるクロスクラウド依存。マイクロバッチのたびに、リモートクラウドの書き込み API の可用性とレイテンシーに結合していました。
ストリーミング書き込み API の障害がインジェスト障害として顕在化。リモート書き込みが脆弱なリンクとなり、読み取り側の問題が書き込み側の障害に転化しました。障害を吸収する場所としては最悪です。
プレビュー段階の機能が物理レイアウトを制約。特定のパーティショニング動作や機能が一般提供されておらず、コストとパフォーマンスのためのデータ編成が制限されていました。

教訓は明確でした。書き込みパスはシフトレフトすべきです。書き込みパスは短く、ローカルで、シンプルであるべきです。クロスクラウドの課題は読み取りパスに属し、読み取り専用、キャッシュ可能、リトライ可能であり、インジェストに影響しません。この再構成が、現在稼働しているアーキテクチャに直結しました。

BigQuery が AWS 上のデータを読み取る方法の選択

フローを反転させ (Raw データは AWS 上、読み取りは Google Cloud から)、BigQuery が物理的に AWS 上にあるテーブルを読み取る 3 つの方法を評価しました。4 つの基準に照らして評価しました。

データ移動なし。
オープンテーブルフォーマット。
ガバナンス可能な信頼モデル。
最小限の運用面。

アプローチ	評価
Google Cloud Storage へのクロスクラウド書き込み	Bronze を Google Cloud Storage 上の BigQuery マネージド Iceberg に書き込み続ける方法。前述の理由で却下しました。インジェストのホットパスにクロスクラウド依存とクロスリージョンレイテンシーが生じるためです。
BigQuery Omni	BigQuery Omni のマネージドなクロスクラウドコンピュートを通じて AWS 上のデータをクエリする方法。読み取り専用の Bronze レイヤーに対して必要以上のマネージド面と制約が生じ、カタログと信頼モデルを直接制御したかったため不採用としました。
Lakehouse フェデレーテッド Apache Iceberg REST カタログ (IAM 認証)	BigQuery が Amazon S3 Tables (マネージド Apache Iceberg テーブルを提供する Amazon S3 の機能) 内のデータを、AWS Glue Data Catalog のメタデータを同期するフェデレーテッドカタログを通じて読み取る方法。アクセスはクロスクラウド IAM 信頼で認証されます。4 つの基準をすべて満たしたため、この方法を選択しました。

決め手となったのは、Raw データが AWS から出ないこと、フォーマットがオープンな Apache Iceberg であること (Amazon Athena、Spark、Iceberg 互換エンジンが同じテーブルを読める)、そしてクロスクラウドの関係が定期的なコピージョブではなくアイデンティティと信頼として表現されることです。

Amazon S3 Tables を選んだ理由

AWS 上に単一の Iceberg コピーを保持するアーキテクチャが決まった後、スケーラブルな Iceberg に特化したストレージレイヤーが必要でした。Amazon S3 Tables は運用面を追加せずに要件を満たしました。テーブルメンテナンス (コンパクション、スナップショット期限切れ、未参照ファイル削除) はサービスマネージドポリシーとして自動実行され、テーブル数に比例して増える外部オーケストレーションジョブが不要です。同様に重要な点として、各テーブルが Amazon Resource Name (ARN) でアドレス指定可能なリソースです。IAM ポリシーで個別テーブルへのアクセスを許可・拒否でき、他の AWS リソースに適用するのと同じ最小権限モデルが使えます。また、AWS CloudTrail がすべてのアクセス判定を記録します。信頼境界が IAM のみで表現されるクロスクラウド設計では、テーブルがファーストクラスの IAM リソースであることは利便性ではなく前提条件です。S3 Tables により、マネージド Iceberg ハウスキーピングときめ細かく監査可能なアクセス制御が単一の構成で実現し、エンジニアリングチームはストレージ層の実装ではなくストリーミングロジックに集中できました。

ソリューション概要

システムは、オープンテーブルフォーマットで接続される 2 つの部分で構成されています。

AWS 上の短くローカルな書き込みパス。
BigQuery がデータを参照できるようにする読み取り専用のクロスクラウドハンドシェイク。

唯一の信頼できるソース (Single Source of Truth) は、Amazon S3 Tables 内の Apache Iceberg データです。すべてのコンシューマーがこの 1 つの物理コピーを読み取ります。

次の図は、イベントインジェストからストレージ、参照経路までのエンドツーエンドアーキテクチャを示しています。

End-to-end architecture from event ingestion through Amazon S3 Tables storage to BigQuery, Athena, and Spark consumers

図 2: イベントインジェストからストレージ、参照経路までのエンドツーエンドアーキテクチャ

書き込みパス: 短く、ローカルで、信頼性が高い

Kafka トピックごとに 1 つの Amazon EMR Serverless Spark Structured Streaming ジョブ (プリベイクされた Docker イメージ、ARM64/Graviton 上の emr-7.13.0) を、Amazon MSK と同じ AWS リージョン (eu-west-2) で実行しています。コンピュートをイベント基盤と同じ場所に配置することで、マイクロバッチあたりのデータ転送量を最小化し、コストとレイテンシーを削減しています。各ジョブは Spark の foreachBatch オペレーションをトリガー間隔約 1〜5 分、at-least-once デリバリーで実行します。各マイクロバッチは 5 つのステップを実行します。

Kafka からコンシュームする。
登録済みスキーマを使用して Protocol Buffers をデコードする。
ターゲットの Iceberg スキーマに変換する。
Amazon S3 Tables 内の Iceberg テーブルに追記する。
オフセットをコミットする。

このサイクルが中断なく繰り返されます。

このパスは AWS のみで完結します。クロスクラウド依存はなく、意図的なクロスリージョンホップが 1 つだけあります。コンピュートは欧州 (ロンドン) リージョン (eu-west-2)、ストレージは米国東部 (バージニア北部) リージョン (us-east-1) です。標準の AWS リージョン間データ転送コストが発生しますが、これは BigQuery からのクロスクラウド読み取りが同一リージョン内に収まるようにするための意図的な選択です。

不正レコードはストリームをブロックしません。専用のデッドレターキュー (DLQ) テーブル (<table>_dlq) が別の S3 Tables バケットに配置され、生のペイロード (raw_value_b64) と skip_reason が保存されます。暗黙のドロップは発生しません。DLQ テーブルは Lakehouse を通じて AWS Glue Data Catalog に登録されているため、エンジニアは Amazon Athena または BigQuery から障害を検査できます。

この時点から、Amazon S3 Tables が信頼できるソースとなります。

核心: クロスクラウドハンドシェイク

ここが設計の中核です。BigQuery は Lakehouse フェデレーテッド Apache Iceberg REST カタログを通じて S3 Tables の Iceberg データを読み取ります。Google Cloud 側の読み取り専用カタログが AWS 上のテーブルを参照する仕組みです。3 つのメカニズムで実現しています。

オープンなカタログ契約 (Iceberg REST)。

Amazon S3 Tables は Apache Iceberg REST カタログインターフェースを公開し、Google Lakehouse も同じ標準を使用します。双方が Iceberg のオンディスクフォーマットと REST カタログプロトコルに合意しているため、変換レイヤーもデータコピーも不要です。BigQuery は Athena や Spark が読み取るのと同一の Iceberg データファイルを読み取ります。

Google Cloud 側では単一の Lakehouse フェデレーテッドカタログです。アナリストにはテーブルが talabat-data.s3tables-glue.catalog.orders として表示されます。

クロスクラウドのアイデンティティと信頼 (IAM と OIDC)。

Lakehouse カタログは、Google マネージドのサービス ID (Lakehouse REST カタログサービスアカウント) として AWS に認証します。AWS Identity and Access Management (IAM) ロールが accounts.google.com との OpenID Connect (OIDC) フェデレーションを通じてこのサービス ID を信頼し、sts:AssumeRoleWithWebIdentity でサービスアカウントの数値 ID をロールの信頼ポリシーにピン留めしています。S3 Tables Iceberg エンドポイントへのリクエストは SigV4 署名されます。他の AWS SDK が使用するのと同じ AWS リクエスト署名スキームで、S3 Tables サービスにスコープされています。つまり、ハンドシェイクはプロプライエタリなコネクターではなく、信頼された外部 ID が実行する標準の AWS リクエスト署名です。

信頼は AWS 側で Infrastructure as Code (IaC) としてコード化されており、最小権限が付与され、いつでも取り消し可能です。次の図は認証シーケンスを示しています。

図 3: Lakehouse カタログと AWS IAM 間のクロスクラウド認証シーケンス

この信頼関係のステップバイステップのウォークスルー (IAM ロールの作成、トークンのオーディエンスとサブジェクトの検証、信頼ポリシーへの Lakehouse サービスアカウント ID のピン留め) については、Create and manage AWS Glue federated datasets および Set up cross-cloud Lakehouse for AWS Glue を参照してください。

メタデータ同期 (約 5 分間隔のリフレッシュ)。

フェデレーテッドカタログは、S3 Tables のフロントとなる AWS Glue Data Catalog からテーブルメタデータを定期的に同期します。新しく作成されたテーブルや新データは、短いリフレッシュサイクル (約 300 秒) で BigQuery から参照可能になります。読み取りはライブの Iceberg データに対して行われ、同期されるのはカタログポインターのみです。

結果として、AWS 上で一度書き込まれたテーブルは BigQuery で通常のカタログオブジェクトとして表示され、標準 SQL でクエリできます。一方で、バイトは AWS から出ず、フォーマットはオープンなままです。

Infrastructure as Code: クロスクラウド信頼面

以下のセクションでは、アーキテクチャ図に示した認証ハンドシェイクを説明します。Lakehouse カタログサービスアカウントが Google OIDC JSON Web Token (JWT) を提示し、AWS が IAM OIDC プロバイダーを通じて検証し、読み取り専用の S3 Tables アクセスにスコープされた短期間の認証情報を返します。

Google を信頼された ID プロバイダーとして登録する。Lakehouse カタログのサービスアカウントにスコープされます。

resource "aws_iam_openid_connect_provider" "google" {
  url = "https://accounts.google.com"
  client_id_list = [var.lakehouse_sa_audience] #Lakehouse REST-catalog serviceaccount
}

信頼を特定の ID に限定する。ここがセキュリティの核心です。ロールは、サブジェクトがサービスアカウントに一致する Google 署名トークンを通じてのみ引き受け可能です。sub クレームの条件が他のすべてのプリンシパルを排除します。

data "aws_iam_policy_document" "trust" {
  statement {
    actions = ["sts:AssumeRoleWithWebIdentity"]
    principals {
      type = "Federated"
      identifiers = [aws_iam_openid_connect_provider.google.arn]
    }
    condition {
      test = "StringEquals"
      variable = "accounts.google.com:sub"
      values = [var.lakehouse_sa_subject_id] # nobody else can assume the role
    }
  }
}

resource "aws_iam_role" "lakehouse_read" {
  name = "bq-lakehouse-read"
  assume_role_policy = data.aws_iam_policy_document.trust.json
  max_session_duration = 43200 # 12-hour sessions, then re-issued
}

読み取り専用の最小権限を付与する。引き受けたロールには、AWS Glue を通じたカタログメタデータの読み取りと S3 Tables を通じた Iceberg データへのアクセスに必要な権限のみが含まれ、IAM ポリシーで保護され、書き込み可能なものはありません。

statement {
  actions = [
    "glue:Get*",
    "s3tables:GetTable", "s3tables:GetTableData", "s3tables:ListTables", "s3tables:ListTableBuckets", "s3tables:GetTableMetadataLocation", "s3tables:ListNamespaces", "s3tables:GetNamespace","s3tables:GetTableBucket"
  ]
  resources = [var.s3tables_bucket_arn, "${var.s3tables_bucket_arn}/*"]
}

Google 側のカタログをこのロールに紐付ける。Lakehouse フェデレーテッドカタログ自体はパイプラインとは別に事前作成 (一回限りの gcloud コマンド) され、前述のロールに紐づけられるため、すべての読み取りが信頼された ID を提示します。AWS キーが Google Cloud に存在することはありません。
```
gcloud iceberg catalogs create s3tables-glue \
  --federated-catalog-type=GLUE --glue-aws-region=us-east-1 \
  --glue-aws-role-arn=arn:aws:iam::<account>:role/bq-lakehouse-read
```

これら 4 つのステップがハンドシェイクの全体像です。信頼された発行者、サービスアカウントのみが引き受けられるロール、最小権限の読み取り許可、そしてそのロールにバインドされたカタログです。

運用上の教訓: メタデータをファーストクラスの関心事として扱う

オープンなフェデレーテッドカタログをクラウド間で運用する中で、テーブルメタデータをファーストクラスの運用上の関心事として扱うことの重要性を学びました。具体的には以下を意味します。

スナップショット保持: Iceberg のスナップショット保持期間を短く設定し、テーブルごとのメタデータをコンパクトに保ち、確実に同期できるようにする。
コンパクション: S3 Tables 組み込みのメンテナンス設定を通じて、テーブルメンテナンス (コンパクションとスナップショット期限切れ) を統一的なサービスマネージドポリシーとして標準化する。
スキーマ進化: Protobuf スキーマが進化 (後方互換の追加) すると、Spark ジョブが S3 Tables 内の Iceberg スキーマにカラムを追加・削除する。フェデレーテッドカタログは次の同期サイクルで変更を検出し、BigQuery は手動介入なしに変更を反映する。

設定方法さえ分かってしまえば小さく明確な設定項目にすぎませんが、カタログが正常に動作するか、時間とともにずれていくかの分かれ目です。

データ参照はエンジンの選択であり、コピーの選択ではない

ソースがライブになった後、同一の Iceberg テーブルに 1 つの物理データセットから 3 つの方法でアクセスできます。

BigQuery ユーザーは標準 SQL でクエリし、Google Cloud ウェアハウスの他のデータと結合できる。
インフラエンジニアはアドホック確認や継続的インテグレーション (CI) バリデーションのために Amazon Athena で同じクエリを実行できる。
データサイエンティストは BigQuery や Athena を経由せず、Spark で直接テーブルを読み取れる。

夜間エクスポートを待つ必要はなく、3 つの異なるコピーを照合する必要もありません。コピーは 1 つだけです。

パフォーマンスとコストへの影響

定性的なメリットは既に明らかです。

ニアリアルタイム分析のための数分レベルの鮮度を持つ Raw データ。従来アーキテクチャのレイテンシーはデータ量の問題ではなく設計上の制約でした。インジェスト自体は 5 分間隔で実行されていましたが、下流の 1 時間バッチジョブがエンドツーエンドの鮮度を 60〜90 分に制限していました。カタログフェデレーションにより、同じデータが生成から数分以内にクエリ可能になります。イベントの 95% が 5 分以内、レイテンシーに敏感なミッションクリティカルなワークロードでは 100% をカバーするようにパイプラインを調整する選択肢もあります。
S3 Tables に 1 つのストレージコピー、3 つのコンピュートエンジン。BigQuery、Athena、Spark またはその他の Iceberg 互換エンジンが Amazon S3 Tables 内の単一の物理 Iceberg データセットを読み取り、ストレージの重複とコピー同期に伴う照合コストを回避します。
ホットパスでのクロスクラウドエグレスなし。インジェストは AWS 内で完結します。唯一のクロスクラウドトラフィックは読み取り時のメタデータ同期とクエリ読み取りであり、継続的な書き込みストリームではありません。月次の AWS および Google Cloud データ転送料金、オーケストレーションオーバーヘッド、多層 ETL ワークフローコスト、ストレージバックアップ料金の内部比較に基づき、talabat は同等のデータボリュームでデータ移動コストを約 40% 削減しました。比較は継続的レプリケーションパイプラインの削除前後の 2 か月間にわたり、月間数百テラバイトの反復的なクロスリージョンおよびクロスクラウドデータ転送を排除しました。
オープンテーブルフォーマット、ロックインなし。Raw の Bronze データレイヤーが Amazon S3 Tables 内の Apache Iceberg であるため、データは特定のクエリエンジンやクラウドに囲い込まれません。新しいコンシューマーはエクスポートを要求する代わりに、Iceberg 対応のインターフェースで接続するだけです。
ガバナンス可能なクロスクラウドアクセス。クロスクラウドの境界は、常時稼働のデータパイプラインではなく、IAM 信頼関係 (最小権限、監査可能、取り消し可能) で保護されています。BigQuery 内のエンドユーザーアクセス制御は、GCP のネイティブなロールベースアクセス制御 (RBAC) とフェデレーテッドカタログのきめ細かなアクセス制御で別途管理されます。

今後の拡張

今後は、残りの高価値イベントストリームとバッチストアをハイブリッドな単一設定パターンに取り込み、ソースカバレッジを拡大する予定です。エンドツーエンドの鮮度目標とその周辺のオブザーバビリティ (バッチレベルのメトリクス、デッドレター監視、カタログ同期の正常性) を形式化しています。テーブル数が増加してもクロスクラウドカタログが高速かつ信頼性の高い状態を維持できるよう、スナップショット保持とコンパクションの調整を続けます。より広い観点では、Bronze レイヤーを超えた新しいデータセットについても「一度書き込み、任意のエンジンで読み取り」をデフォルトにし、クラウド間の接続基盤としてオープンテーブルフォーマットをさらに活用していく方針です。

まとめ

2 つのクラウドを使うことは、マイグレーションすべき問題として捉えられがちですが、talabat にとっては単に地形です。イベント基盤は AWS が中心であり、分析コミュニティは BigQuery で活動しています。Apache Iceberg を搭載した Amazon S3 Tables を AWS 上の唯一の信頼できるソースとし、クロスクラウド IAM 信頼で保護された Lakehouse フェデレーテッド Iceberg REST カタログを通じて BigQuery に読み取り専用で参照させることで、2 つのクラウドという制約を数分以内にエンジンが読み取れる単一のガバナンスされたデータセットに変えました。書き込みパスは短く、ローカルで、信頼性が高いままです。クロスクラウドの課題は、あるべき場所、すなわち読み取りパスに存在し、データ移動ではなくオープン標準とアイデンティティで表現されています。

これがハンドシェイクです。AWS 上にデータのコピーを 1 つ、オープンなカタログ契約、そしてクラウドの境界を越えてデータを読み取るための署名された、信頼された、取り消し可能なアイデンティティです。

本記事では BigQuery から AWS 上のデータを読み取ることに焦点を当てました。他のシステムから AWS Glue Data Catalog へのカタログフェデレーションを含む、より広範なマルチクラウド Lakehouse パターンについては、Multi-cloud Lakehouse architecture on AWS for agentic AI を参照してください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

Amazon Web Services ブログ