AWSは、データレイクに保存されたApache IcebergおよびApache Parquetのデータを、Amazon Aurora PostgreSQL内の運用データと同時に直接クエリできる機能を追加したと発表した。この新機能により、アプリケーションはPostgreSQLの構文と既存のツールを使い、ETLパイプラインを通じてデータをデータベースにコピーすることなく、最新のレコードと履歴データを単一のクエリで統合できる。
実際に何が変わるのか？
この機能は、Aurora PostgreSQL内に直接組み込まれたDuckDBエンジンを基盤としている。これにより、単一のクエリで、未コミットの書き込みを含む運用データと、Amazon S3のIcebergテーブルまたはParquetファイルを読み取れる。また、AWS Glue Data Catalog、Amazon S3およびS3 Tablesに加え、Glueのフェデレーション機構を通じてIceberg REST Catalog互換のカタログもサポートする。
ユーザーはAurora PostgreSQLクラスターを作成し、AuroraAnalytics機能を含むIAMロールをアタッチしたうえで、aurora_analytics拡張機能を有効にする必要がある。その後、外部データを参照するforeign tableを作成するか、IMPORT FOREIGN SCHEMAを使用して、メタデータからデータスキーマを推測しながら複数のテーブルを自動的に作成できる。
なぜこのニュースが重要なのか？
これまで、Auroraの最新トランザクションとS3の履歴レコードを組み合わせるアプリケーションでは、通常、reverse ETLによるデータコピーが必要だった。そのため、同期処理、運用コスト、エンジニアリング上の複雑さが増していた。現在は、この統合をクエリの実行中に行える。これは、履歴コンテキストを必要とするダッシュボード、トランザクションを過去の記録と結び付けるアプリケーション、運用データベースとデータレイクに分散したデータを扱うシステムに役立つ。
この点は、人工知能エージェントを使用するアプリケーションではさらに重要になる。エージェントが事前に必要とする可能性のあるデータセットをすべて予測し、それらを運用データベースへコピーすることは難しいためだ。直接アクセスにより、ユースケースごとにコピーを作成することなく、利用可能なデータの範囲を拡大できる。
パフォーマンスとアクセスの選択肢
Auroraは、フィルターをデータソースへプッシュダウンし、読み取る列を削減するなどの最適化を適用する。また、頻繁に使用されるデータをAuroraインスタンス内に一時的に保存する。各クエリの挙動はaurora_analytics_stat_statements()関数で確認でき、この関数はスキャンした行数、S3から読み取ったデータ量、キャッシュが利用された回数などの指標を表示する。
クエリは、ライターや読み取り専用レプリカを含む、クラスター内の各種Auroraインスタンスで利用できる。そのため、分析処理を運用ワークロードから切り離せる。一方、数千分の1秒単位の応答時間が必要なケースでは、CREATE TABLE AS SELECT、INSERT INTO ... SELECT、またはMERGE INTOを使用して、データをネイティブなAuroraテーブルに実体化できる。実体化によって発生する書き込み処理は、ライターインスタンスで実行される。
提供状況とコスト
この機能は、Aurora PostgreSQL 17では17.11以降、18では18.6以降をサポートする。すべてのAWS商用リージョンおよびAWS GovCloud（US）リージョンで利用でき、機能自体に追加料金はかからない。コストは引き続き、クエリが消費するAuroraの追加コンピューティングに加え、データレイクのファイルを読み取るためのAmazon S3リクエスト料金に関連する。
certi.newsの見解：基本的な変化は新しいストレージ形式の追加ではなく、運用データベースとデータレイクの間の距離を縮めたことにある。ただし、これはワークロード設計上の考慮事項をなくすものではない。直接クエリは柔軟なデータアクセスに適している一方、非常に低い応答時間が優先される場合は、依然として実体化が必要になる。また、AuroraのコンピューティングとS3リクエストの消費量は、クエリパターンとデータ量に応じて測定すべき要素であり続ける。