re:Invent 2024: AWSがS3 Tablesを発表 - 大規模表形式データ管理の新機能
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - [NEW LAUNCH] Store tabular data at scale with Amazon S3 Tables (STG367-NEW)
この動画では、Amazon S3の新機能「S3 Tables」について詳しく解説しています。S3 TablesはAmazon S3上で完全マネージド型のApache Icebergテーブルを提供し、表形式データの保存と管理を効率化するサービスです。従来のバケットと比較して最大10倍のトランザクション/秒を実現し、自動圧縮機能によりクエリパフォーマンスを最大3倍高速化できます。AWS Glue Data Catalogとの自動統合により、Amazon AthenaやAmazon Redshiftなどのアナリティクスサービスとシームレスに連携し、Lake Formationを通じた細かなアクセス制御も可能です。また、新機能のS3 Metadata Tablesについても紹介され、S3バケットのメタデータをリアルタイムでIcebergテーブルに保存できることが説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon S3 Tablesの紹介と本セッションの概要
木曜日の最後まで待っていただき、ありがとうございます。数日前に私たちが立ち上げたばかりの新機能、Amazon S3 Tablesについてご紹介させていただきます。本セッションでは、Amazon S3 Tablesを使用して大規模な表形式データを保存する方法についてお話しします。私はAditya Kalyanakrishnan、略してAdiと呼んでいただいており、Amazon S3チームのPrincipal Product Managerを務めています。また、この機能の開発者の一人であるAmazon S3チームのPrincipal Applied ScientistのJames Bornholtも後ほど登壇します。私たち二人とも、この新機能についてお話しできることを大変楽しみにしています。
本日は盛りだくさんの内容をご用意しています。まず、S3 Tablesの機能について基本的な概要をご紹介し、その後、この機能がどのように動作するのか、新しいコンポーネントや基本的な仕組みについて詳しく説明します。次に、ユースケースやワークロードについてお話しし、ここでJamesが登場して、実際のデモを交えながらこの新機能の詳しい使い方をご紹介します。最後に、これらの機能について簡単におさらいをします。60分間すべてを使って説明させていただきますので、ご質問がある方はご心配なく。もし会場から出されてしまっても、外でも構いませんので、皆様のご質問にお答えできる限り対応させていただきます。
S3 Tablesの背景と主要機能
2006年にAmazon S3を構築した当時、私たちはインターネットのためのストレージを目指していました。開発者の皆様が、S3に安全かつ確実にデータを保存し、必要な時にいつでも利用できるようにすることが目標でした。そのため、お客様はS3を使用して、世界中のWebサイトを支えるビデオや写真、その他のコンテンツを保存することができました。これが私たちが想定していた使用方法でした。これは今でも非常に重要なユースケースですが、約20年の間に、皆様がS3を使って実現される様々なワークロードには本当に驚かされてきました。時とともに、お客様である皆様が、私たちを全く異なる方向へと導いてくださったのです。
現在、S3で実行される主要なワークロードの多くは、データ分析、機械学習、AIを中心としています。これらのワークロードにおいて、お客様はすでにS3を主に表形式データストアとして使用しています。気象データ、金融取引記録、Webサイトのインプレッション、その他様々なユースケースのデータは、Apache Parquetなどの表形式ファイルフォーマットで処理され、S3に保存されています。現在、お客様はエクサバイト規模のParquetオブジェクトをS3に保存しており、Parquetは、このようなデータをS3に保存する際の事実上の標準となっています。実際、ParquetはAmazon S3で最も一般的に保存され、最も急速に成長しているファイルタイプの一つとなっています。
長い間、これらのデータセットは、オンプレミスシステムと同様に、単純にファイルとフォルダとして整理されており、クラウドではそれらがオブジェクトとプレフィックスとして反映されていました。しばらくの間、それで問題なく機能していましたが、ユースケースがより複雑になるにつれて、これらのデータセットをより良い方法で維持し、進化させる必要があることが明らかになってきました。複数の異なるアプリケーションが同じデータセットに同時にアクセスする際のデータ整合性の維持や、列の削除や追加によるデータセットのスキーマ進化など、これらの作業はより複雑になっていきました。そして、データが確実にスケールを保ちながら適切なタイミングで処理されるようにするために必要なシステムの複雑さも増していったのです。
これは、数年前にOpen Table Formatが登場した時期です。Open Table Formatにより、データセットを整理するためのより優れたフレームワークが提供されました。これらのTable Formatの中でも、Apache Icebergは大きく成長し、私たちのお客様にとって非常に人気のある選択肢となっています。Icebergは、データセットをより適切に構造化できるメタデータファイルを追加します。このメタデータレイヤーにより、複数のアプリケーションが互いに干渉することなく協調して動作する安全なトランザクションを実現する堅牢な機能群が提供されます。
データセットのスキーマを柔軟に進化させることができ、タイムトラベルのような魅力的な機能も実現できます。つまり、データセットの過去の状態に遡って、その時点でのデータがどのような状態だったかを確認し、ロールバックすることができるのです。これにより、お客様はAmazon S3上で進化し続けるユースケースを確実に処理できるようになりました。
Apache Icebergが提供する豊富な機能セット、シンプルなSQLセマンティクスでデータを照会できる機能、そしてParquetがアプリケーションやツールの間で広くサポートされていること、これらの要因により、Icebergは現在、お客様がデータを保存・構造化する方法として非常に人気があります。すでに何千ものお客様がAmazon S3でIcebergを使用しています。そして、Icebergの高度な機能により、今日の複雑な分析ワークロードを処理するために必要な信頼性と柔軟性が提供されています。また、データの不整合を心配することなく、複数のクエリエンジン、コンシューマー、プロデューサーが同時にクエリや更新を行える、真の共有データセットを作成することができます。これは、最初からAmazon S3のスケールと経済性を活用できるように設計されていました。
より多くのお客様がIcebergを採用するようになりましたが、データレイクを最も効率的かつパフォーマンスの高い方法で運用するために克服する必要のある課題がまだいくつかありました。その第一はパフォーマンスです。Icebergにより、複数のアプリケーションが同じデータセットで作業することが容易になりました。しかし、これは同時に、オンボーディングしたすべてのアプリケーションが同じデータセットに対してリクエストを行うことになり、これらのデータセットに対するベースラインのトラフィック需要が増加することを意味していました。これらのアプリケーションは引き続き同じパフォーマンスを期待しています。規模が拡大するにつれて、これらのデータセットを最適化するために時間、リソース、人員に投資する必要がありました。Icebergはコンパクションなどの手法を提供していますが、ある程度の労力が必要です。
これらのテーブルを管理する上での2番目の側面は、お客様がセキュリティポリシーの適用とテーブルのガバナンスをどのように考えるかということでした。実際の物理的なストレージレイアウトを把握し、データを実際に保存しているプレフィックスでポリシーを作成する必要がありました。しばらくの間はうまく機能しましたが、何千ものテーブルを一度に扱う場合、それらすべてを管理するのはかなり面倒になる可能性があります。最後に、コストを最適化する際に考慮しなければならない運用上の負担もあります。Icebergでは、コミットを行ってデータセットを更新し、それぞれのコミットがスナップショットとして保存されます。これらのデータセットを成長させ、より多くのデータを追加し続けるにつれて、これらのスナップショットと関連するデータファイルも蓄積されていくため、時間の経過とともにこれらのテーブルのライフサイクルをクリーンアップし管理する方法が必要になりました。
これらの作業には、テーブルのコストを削減するために実際にコンピュートを立ち上げて実行する必要があった圧縮処理のように、追加の労力が必要でした。これらはすべて、お客様が対処しなければならない複雑さでした。そのため、私たちは Amazon S3 Tablesを導入しました。S3 Tablesは表形式データを格納するために特別に設計され、Amazon S3上で完全マネージド型のApache Icebergテーブルを提供します。私たちはS3 Tablesをインターネットのためのテーブルストレージとして構想しています。
S3 Tablesの構成要素と利点
では、Amazon S3 Tablesに含まれるコンポーネントについて詳しく見ていきましょう。S3 Tablesでは、Table Bucketsと呼ばれる新しいバケットタイプを導入し、Apache Iceberg形式のテーブルをAmazon S3上でネイティブに保存できるようになりました。S3は現在、テーブルを新しい構成要素としてサポートしており、ファーストクラスのAWSリソースとして提供されています。つまり、これらのテーブルはそれぞれ独自のARNを持ち、直接リソースポリシーを設定することができます。また、これらのリソースにアクセスするための新しいエンドポイントも用意されています。
さらに、これらのテーブルと対話するための新しいAPIセットも用意されています。テーブル操作用APIには、テーブルの作成やTable Bucket内のテーブル一覧表示機能が含まれています。また、最新のデータビューを取得するために必要な最新のIcebergメタデータファイルを確認するためのテーブル読み取り機能や、提供されているAPIを使用して直接コミットする機能もあります。これは、テーブルに関するすべての操作を一元的に処理できる仕組みで、テーブルに対して直接CRUD操作（作成、読み取り、更新、削除）を実行することができます。
また、Table BucketレベルとTableレベルの両方でテーブル管理APIが用意されており、これらのリソースに対してリソースポリシーを作成することができます。テーブルメンテナンスポリシーでは、S3に実行させたい圧縮のための目標ファイルサイズや、スナップショットの保持期間、エージアウトの方法などのパラメータを指定できます。S3テーブルの基本的な特徴として、各テーブルには独自のストレージロケーションがあり、クエリエンジンやアプリケーションがテーブルに関連するデータファイルやメタデータファイルを管理するために使用します。これらのリソースには基本的な保護機能が組み込まれており、削除や既存オブジェクトの上書きは許可されていません。これらの保護機能によってテーブルの整合性が維持され、オブジェクトを適切にエージアウトするにはメンテナンスポリシーを使用します。さらに、AWS CloudTrailによる監査も可能で、誰がテーブルに対してどのような操作を行っているかを監視できます。
これらの機能に加えて、最適化されたパフォーマンス、よりシンプルなセキュリティコントロール、そして自動化されたコスト最適化も提供されます。これらの側面について詳しく見ていきましょう。これらは、お客様が独自のIcebergテーブルを運用する際に抱えていた疑問や懸念に対応する3つの柱を表しています。パフォーマンスに関して、S3テーブルでは、一般的なバケット内のプレフィックスと比較して、すぐに最大10倍のトランザクション/秒（TPS）を実現できます。さらに、バックグラウンドで定期的に実行される自動圧縮機能と組み合わせることで、S3テーブルに保存されたIcebergテーブルのクエリパフォーマンスを最大3倍高速化することができます。
さらに詳しく見ていきましょう。S3 Tablesは表形式データに特化して設計されています。アプリケーションがApache Icebergスタンダードを使用してこれらのテーブルにデータを読み書きする際、 S3はこれらがIceberg形式で保存された表形式データセットであることを認識し、特定の最適化を適用できるようになりました。これは、その名の通り様々なワークロードに使用される汎用バケットとは対照的です。内部的には、S3のネームスペースをデータをより最適化された方法でレイアウトするように調整しており、アプリケーションは最初から高いトランザクション処理能力を実現できます。 比較として、汎用バケットでは、汎用バケットのプレフィックスで1秒あたり5,500回の読み取りまたは3,500回の書き込みから開始します。
これは単なる開始点に過ぎません - リクエストトラフィックの需要が増加し、バケットへのトラフィックが増えると、S3は自動的にスケールします。バケットへのトラフィックが増加すると、S3は自動的にリクエスト処理能力を追加して追加の需要に対応し、アプリケーションに必要な適切なスケールを実現できます。テーブルバケットでは、1秒あたり最大10倍のトランザクション、つまり55,000回の読み取りまたは35,000回の書き込みを最初から実現でき、それ以上にもスケールします。私たちはApache Icebergに特定の最適化を提供しており、Icebergでデータファイルを書き込みレイアウトするデフォルトの方法が、S3が提供する自動スケーリングをより活用できるように最適化されています。Amazonの広告部門がこれらのクライアントサイドの変更をIcebergワークフローで活用して、アイドル状態のリソースを削減することでパフォーマンスを向上させコストを削減した方法についてのブログリンクがあります。
現在、私たちは毎日数百ペタバイトのParquetデータを提供しており、お客様はこれらのParquetデータファイルに対して1秒あたり1,500万以上のトランザクションを実行しています。テーブルバケットの高いベースラインのトランザクション処理能力は、特に同じデータセットを使用して複数のアプリケーションが効率的に作業する場合の増大するニーズに対応するのに役立ちます。パフォーマンスのもう一つの側面はコンパクション（圧縮）です。Apache Icebergテーブルでは、レコードの更新や削除によってデータセットを進化させ続けると、それらの変更がテーブル内の追加ファイルとして蓄積されていきます。つまり、データがスケールアップしテーブルが大きくなるにつれて、アプリケーションはデータをクエリする際にそれらの追加ファイルを処理する必要があり、時間とともにパフォーマンスが低下する可能性があります。
Apache Icebergはコンパクションを通じてこれを最適化する方法を提供しており、小さなデータファイルをより大きなファイルに統合します。これにより、各クエリに必要なリクエスト数が減少し、クエリのパフォーマンスが向上します。これまでは、お客様はこれらの操作を定期的に実行するためにコンピュートリソースを起動し、クラスターを管理するチームを持つ必要がありました。お客様と話をすると、一般的に2つのグループに分かれていました：データセットを最適化し自動化されたワークロードを実行する高度なIcebergショップと、コンパクションを考慮していないか実装していない初心者です。
S3 Tablesでは、コンパクションについて心配する必要はまったくありません。コンパクションはバックグラウンドで定期的に実行され、小さなParquetオブジェクトをより大きなファイルに統合します。これにより、アプリケーションが行うリクエスト数が減少し、S3 Tablesを使用することで最大3倍のクエリパフォーマンスを実現できます。昨日公開したブログへのリンクがあり、S3 TablesのApache Icebergテーブルと汎用バケットで実行される未管理のIcebergテーブルを比較したベンチマークの詳細が記載されています。
2番目の側面は、よりシンプルになったセキュリティコントロールです。これまでは、テーブルへのアクセスを管理するために、物理的なデータの場所やストレージ内のメタデータファイルの場所に関する知識が必要なポリシーを作成する必要がありました。また、テーブルの読み書きの権限と、テーブル内のデータの読み書きの権限を別々に管理しなければならないこともありました。S3 Tablesでは、テーブルをリソースとして扱うことで、このプロセスがシンプルになりました。
テーブルに対して直接リソースポリシーを適用できるため、テーブルとテーブルバケット自体へのアクセスを管理することができます。いくつか例を見てみましょう。左側にあるのは、一般的なバケットやDirectory Bucketのポリシーと非常によく似たTable Bucketポリシーで、テーブル全体へのアクセスを管理することができます。この例では、プリンシパルにバケット内のすべてのテーブルを一覧表示するための読み取り権限とリスト権限を付与しています。右側では、より具体的なテーブルレベルのリソースポリシーを使用して、誰がそのテーブルにアクセスできるかを明確に指定できます。これは、プリンシパルに読み取りアクセスを与える例です。
では、Table BucketとTableの中間的なものが必要な場合はどうでしょうか？そこで役立つのがNamespaceという概念です。Table Bucket内にNamespaceを作成することで、バケット内の異なるテーブルを論理的にグループ化できるようになりました。開発、テスト、ステージング環境のテーブルをそれぞれのNamespaceにグループ化し、適切な人々に特定のNamespaceへのアクセス権限のみを付与することができます。こちらがTable Bucketポリシーの例です。Namespaceを含むTable Bucketポリシーを作成するには、条件キーを指定して、テーブルのサブセットへのアクセスを管理します。これにより、テーブルレベルの粒度の細かいアクセス権限から、Namespaceレベル、さらにはTable Bucketレベルまで、よりシンプルな方法で適用できます。
3番目の側面は、ストレージコストの最適化とその自動化についてです。Apache Icebergテーブルへの更新は、コミット操作を発生させ、そのテーブルの新しいスナップショットを作成します。これはIcebergの素晴らしい特徴で、過去の時点に戻ってテーブルの状態を確認したり、テーブルをロールバックしたりすることができます。時間の経過とともにデータセットを更新していくと、新しいデータをコミットする度に新しいスナップショットが生成されていきます。つまり、それらのスナップショットは新しいデータファイルを参照していますが、同時に、永久に保持する必要のない古いスナップショットも存在することになります。
先ほど説明したCompactionと同様に、これまではテーブルを最適化し、古いスナップショットを適切に期限切れにし、古いスナップショットに関連するファイルを削除してガベージコレクションを行うために、手動での作業が必要でした。しかし今では、S3 Tablesにそのすべてを任せることができ、手動での作業は不要になりました。バックグラウンドで自動的なメンテナンス手順が実行され、スナップショットの有効期限管理や、不要になった古いスナップショットに関連する未参照ファイルのクリーンアップを行います。これにより、不要になったデータをより安全に削除することができます。
AWSアナリティクスエコシステムとの統合デモ
これらの手順はすべてポリシーによって制御されています。この例では、スナップショットを何個保持するか、どのくらいの期間保持するかを指定できるポリシーを適用でき、さらにバックグラウンドでテーブルの整合性チェックも行っています。これらのテーブルのメンテナンス操作の状況を簡単に確認することができます。 理論的な部分と各コンポーネントについて多くお話ししてきましたが、ここでJamesを招いて、実際のワークロードについて、そしてS3 Tablesの実際の動作をご覧いただきたいと思います。ありがとうございます、Audie。皆様、本日はお集まりいただき、ありがとうございます。私はJamesと申します。S3チームのPrincipal Engineerを務めており、このTablesに関する各チームの取り組みについてお話しできることを大変嬉しく思います。チーム全体でこの製品を作り上げていく過程を見守るのは、とても楽しい経験でした。 これから、S3 Tablesの使用例をいくつかご紹介したいと思います。
私たちの目標は、お客様がアプリケーションに集中できるよう、表形式データの保存と管理において卓越したサービスを提供することです。 Table Bucketそれ自体では、実際にはデータのクエリや読み込みはできません。これは、S3自体がバケットに保存されているバイトデータを解釈したり解析したりしないのと同じです。私たちはTable Bucketをストレージのプリミティブと考えており、S3 Tablesを使用する最適な方法は、本日からパブリックプレビューで利用可能となったAWS Analyticsエコシステムとの新しい統合を通じてです。
AWS Analyticsをご存知の方なら、多くのコンポーネントが馴染み深いものだと感じられるでしょう。S3 Tablesは、汎用的なS3バケット内の既存のテーブルと同様の方法で、アナリティクスサービスと連携します。これらの統合の中心となるのが、組織のデータセットの一元化されたインデックスであるAWS Glue Data Catalogです。AWS Glue Data Catalogは長年、自己管理型のS3バケットに保存されたテーブルをサポートしてきましたが、それらを自分で登録して管理する必要がありました。S3 Tablesでは、管理されたテーブルが自動的にAWS Glue Data Catalogに登録されるため、すべてのテーブルが確実に登録されているか、また不要になったテーブルの削除について心配する必要がありません。
S3 TablesがAWS Glue Data Catalogに登録されると、AWS Analyticsエコシステム全体で自動的に表示され、使用可能になります。Amazon Athenaで素早くデータをクエリし、Amazon Redshiftで詳細な分析を実行し、Amazon Data Firehoseから直接S3 Tablesにデータをストリーミングし、Amazon QuickSightで簡単に可視化を構築できます。Amazon KinesisやCloudWatchログ、IoTデバイスなどのデータソースを接続することもできます - アナリティクスの世界で慣れ親しんだ機能がすべて利用可能です。
それでは、S3 Table Bucketの使用体験をご案内しましょう。 最初のステップは、Table Bucketの作成です。S3コンソールでTable Bucketを見つけることができます - 左側にTable Bucket用の新しいオプションがあり、作成するにはバケットの名前を指定するだけです。 アカウントで初めてTable Bucketを作成する際、AWS Glue Data Catalogとの統合が自動的にセットアップされます。 これは、Table Bucketをアナリティクスで利用可能にするために必要なIAMロールとパーミッションをすべてセットアップする一回限りのステップです。 このセットアップは、アカウントごと、リージョンごとに一度だけ必要な手順です。
Table Bucketをアカウントに作成したので、次のステップはその中にテーブルを作成することです。AWS Glueとの統合はまだプレビュー段階にあり、その理由の1つは、現時点ではテーブルの作成が少し複雑だからです。今のところ、Amazon AthenaやAmazon Redshiftなどのエンジンを通じてテーブルを作成することはできません - これは開発中です。現在のところ、テーブルを作成する最適な方法は、Amazon EMRのS3 Tables統合を使用することです。Amazon EMR StudioのSparkノートブックを作成し、そのノートブック内でTable Bucketに対してSQLクエリを実行できます。これにはCREATE TABLE文も含まれます。このノートブックでは、私が所有する店舗の売上データを保存するための大規模なテーブルをTable Bucketに作成しています。このデータは、デモの残りの部分で損益を分析するために使用します。
テーブルでできることについて説明しましょう。要するに、データを入れて取り出すことが目的です。データの入力方法については、アプリケーションによって異なるので、一旦置いておきます。S3 TablesはネイティブなApache Icebergプロダクトなので、AWSの内部サービスでIcebergに書き込めるものや、Icebergデータを生成して指定した場所に保存できるサードパーティのサービスなど、非常に豊富なエコシステムがあります。
S3 TablesのApache Icebergテーブルにデータを入れた後、Amazon AthenaとAmazon Redshiftを使用してそれを分析する2つの例をお見せしたいと思います。まずはAmazon Athenaから始めましょう。Athenaをご存じない方のために説明すると、AWS Glue Data Catalogを通じてS3 TablesをネイティブにクエリできるサーバーレスSQLエンジンです。Athenaでは、Table Bucketのデータを使い始めるための特別なセットアップは必要ありません - すぐにTable Bucketに対してSQLを書き始めることができます。クエリを書く際には、テーブル名を3つのパートで指定する必要があります。最初は、この文脈ではバケット名となるカタログと呼ばれるものです。つまり、私のsales demoバケットからデータを選択します。テーブル名の2番目のパートは名前空間で、これは先ほど説明したテーブルの論理的なグループ化です。ここでは、salesという名前空間があります。
3番目のパートはテーブル名そのものです。この場合、私のテーブルはstore salesと呼ばれています。これらが、Table Bucketの中の、この名前空間の、このテーブルからデータをクエリしたいと指定するために必要な3つのパーツです。
Athenaは、Icebergデータを探索するのに本当に優れた方法です。エラスティックで、サーバーレスで、アドホッククエリに最適です。また、他の場所でも使用されます - 可視化をしたい場合にQuickSightにデータを取り込む方法としても使われます。ここでご覧いただけるように、テーブル内のデータを分析して、私の店舗の日々の純利益を把握することができました。
Amazon Redshiftについて簡単にご紹介させていただきます。Amazon Redshiftをご存じない方のために説明しますと、組織全体のデータソースを幅広く統合できる分析用のデータウェアハウスサービスです。 特にIcebergの大容量データに特化した高性能なクエリエンジンを提供しています。Redshift統合のプレビュー版では、現時点では期待するほどスムーズな体験が得られない部分があります。RedshiftはAWS Glue Data CatalogとS3テーブルの完全な統合をサポートしていないため、データをRedshiftに取り込むには追加の手順が必要になります。
AWS Glueではリソースリンクと呼ばれるものを作成する必要があります。Redshiftからデータをクエリする場合は、Formationコンソールに移動し、データベースの作成ボタンを使ってリソースリンクを作成します。 名前を付け、使用するカタログを選択する必要があります。これは私がクエリを実行するテーブルバケットのバケット名です。そして、データベース名を指定します。 この場合、AWS Glueではデータベースとして名前空間を使用するので、テーブルバケットのsales名前空間をAWS Glue Data Catalogにマッピングしたいと思います。 基本的に、この名前空間内のS3テーブルを、RedshiftがすでにアクセスできるようになっているAWS Data Catalogで見えるようにすると宣言しているわけです。
これはテーブルバケットの名前空間ごとに1回だけ必要な手順です。これを実行すると、その名前空間内のすべてのテーブルがRedshiftで表示され、クエリできるようになります。名前空間をリソースリンクにマッピングしたら、Redshiftで利用できるようになります。Redshiftのクエリエディタを見てみましょう。ここからは先ほどAthenaで見たのと同じような操作になります。私は実際にRedshift Serverlessクラスターを使用していますが、これは弾力的にスケールアップ・ダウンします。もちろん、Redshiftのプロビジョンド版でも同じように動作します。
左側のカタログをドリルダウンしていくと、先ほど作成したリソースリンクの名前でAWS Data Catalogの下にテーブルバケットが表示されているのがわかります。ここではstore sales linkという名前で、私のテーブルがそこにあります。すべての列を含むテーブルのスキーマが確認できます。それでは、先ほどAthenaで書いたのと同じクエリをRedshiftでも書いてみましょう。 同様の結果が得られるシンプルなSQLクエリです。実は、S3テーブルに対するクエリにおいて、AthenaとRedshiftのこの組み合わせにとても期待しています。 Athenaという使いやすいアドホッククエリエンジンから、Amazon Redshiftでのテラバイトやペタバイト規模のIcebergデータに対する強力なクエリまで、幅広いオプションを提供できるからです。
AWSアナリティクスとの統合について、他にも興味深い点を手短にご紹介したいと思います。その1つが、AWS Lake Formationを通じた細かなアクセス制御の機能です。Lake Formationをご存じない方のために説明しますと、各テーブルへのユーザーアクセス、さらにはテーブル内の個々の列や行へのアクセスを指定できる方法です。Lake FormationはIAMおよびIAM Identity Centerと統合されているため、IAMロールやユーザーだけでなく、Active DirectoryインスタンスのユーザーやOktaインスタンス、その他IAMと統合される多数のアイデンティティプロバイダーを通じたフェデレーテッドアイデンティティに対してもこのアクセス制御を実施できます。
IAMプリンシパルだけでなく、それらのユーザーに対してアクセスコントロールポリシーを作成できます。S3テーブルを手動でこの統合に取り込む作業は一切必要ありません - 登録されたS3テーブルバケットとテーブルは、すべて自動的にLake Formationに表示されます。もちろん、これを使用したくない場合は、IAMのパーミッションも完全に機能します。では、Table Bucketに保存されたテーブルに対するLake Formationの細かなアクセス制御の例をお見せしましょう。先ほど私が実行していたクエリに注目していた方は、興味深いことに気づいたかもしれません - 私のビジネスはあまり上手くいっていないのです。毎日、純利益がマイナスを示しています。これが私がビジネスパーソンではなくエンジニアである理由です。私はこのことを恥ずかしく感じており、Audieには知られたくありません - 私のビジネスが赤字であることを。細かなアクセス制御を使って、Audieから純利益の情報を隠せるか見てみましょう。Lake Formationコンソールに移動すると、デフォルトでは Audieは私のテーブルにアクセスできません。明示的にアクセス権を付与しない限り、アクセスはできません。そこで、テーブルへのアクセス権を付与してみましょう。
Lake Formationを用いた細かなアクセス制御
Lake Formationコンソールを通じてテーブルへのアクセス権を付与します。Table Bucketカタログを選択し、テーブル、Namespace、またはTable Bucket全体へのアクセス権を誰かに付与するために「Grant」を選択できます。プリンシパルを選択し、アクセスを許可するデータの選択を開始できます。この特定のTable Bucket、具体的には作業してきたSales Demoバケットを選択します。そのバケット内のデータベースとNamespaceを選択し、ここではSalesを選択します。そして、そのバケット内のStore Salesテーブルへのアクセス権を付与します。
次に、実際に付与するパーミッションを選択します。Select権限だけを付与するか、コンテンツの削除、コンテンツの挿入、さらにはテーブル全体の削除権限まで付与するかを選択できます - これは私次第です。最後に、細かなパーミッションを選択できます。テーブル全体へのアクセスを許可する代わりに、1つの列を除くすべてへのアクセスを許可することができます。純利益の列へのアクセスを除外することにします。これで他のすべての列にアクセスできますが、その1列だけはアクセスできなくなります。これが私が達成しようとしていたこと - 純利益情報を隠すことです。
では、実際にテーブルにアクセスする際にどのように機能するか見てみましょう。Redshift Query Editorに戻りましょう。ここで注目していただきたいのは、右上に表示されているように、これは私ではなくAudieの視点から見ているということです。AudieがRedshift Query Editorにいます。私が付与したパーミッションで何ができるでしょうか？以前と同じように、左側のカタログをドリルダウンし、AWS Data Catalogを見つけ、作成したResource Linkを見つけ、Table Bucket内のテーブルを見つけることができます。テーブルのスキーマも確認できますが、下部を見ると純利益の列が消えていることに気づくでしょう。これは以前のテーブルの最後の列でした。
ここで、以前実行していたのと同じクエリ、つまり日別にグループ化した売上の純利益を見るクエリを書いてみましょう。このクエリを書き終えて実行してみます。パーミッションエラーが発生します - このテーブルの純利益列を参照する権限がないことがわかります。何が起きているかを示すために、クエリから純利益の列を削除してみましょう。このクエリは意味をなさなくなりましたが、テーブルの他の部分にはアクセスできることを示しています - 純利益の列へのアクセスだけが失われているのです。
AWS Glue Data CatalogやAWSのアナリティクスエコシステムとS3 Tablesの統合における素晴らしい強みの1つは、このような細かなアクセス制御が標準で提供されることだと思います。これは、テーブルのパフォーマンス上の利点に加えて、Amazon AthenaやAmazon Redshift Serverlessのような製品を使ってデータの操作を簡単に始められるという利点もあります。
S3 Tablesの活用例とまとめ
テーブルの使用についてもう1つお話ししたいことがあります。すべてのお客様がAWSのアナリティクスサービスを使用しているわけではないことは承知しています。それは全く問題ありません。多くのお客様は、独自のApache Sparkインフラストラクチャや、独自のApache Flinkストリーミングインフラストラクチャ、あるいはデータ分析に使用したい任意のインフラストラクチャを運用しています。先ほど申し上げたように、私たちはS3 Tablesをストレージのプリミティブとして考えているので、AWS内外を問わず、必要な場所にS3 Tablesのデータを持ち込めるようにしたいと考えています。
また、S3 Tablesとお好みのアナリティクスエンジンを統合するための、オープンソースのIcebergカタログも提供しています。Icebergにおいて、カタログは本質的にコネクタです。つまり、クエリを実行したいテーブルのメタデータを発見する方法をIcebergに伝えるものです。IcebergのS3 Tablesカタログは、Sparkアプリケーションが直接S3 Tablesに接続してテーブルを発見し操作できるようにするプラグインです。S3 TablesカタログをIcebergで使用することで、Amazon EMR on EKSで実行されているSparkや、お好みのコンピュート上で実行されているSparkから直接テーブルに接続できます。プロセスが少し複雑なため、ここでは説明しませんが、AWS Glue Data Catalog以外での使用を開始するための分かりやすい手順がドキュメントに記載されています。
これらのツールを使って構築できるワークフローの例をいくつかお見せして、まとめとしたいと思います。最初の例は、Amazon Kinesis Data FirehoseからS3 Tables、そしてAmazon QuickSightに至るエンドツーエンドのデータパイプラインです。Kinesis Data Firehoseを使用すると、データベースや店舗からのトランザクションデータ、IoTデバイスからのセンサーデータなど、あらゆるストリーミングデータソースを直接Icebergテーブルに取り込むことができます。そして、QuickSightを使用すれば、そのテーブルからデータを取り出し、自動的にクエリを実行してリアルタイムで可視化することができます。これにより、テーブルに入ってくるデータのリアルタイムなストリーミング分析ビューが得られます。その過程で、Audieが説明したIcebergのすべての利点を得ることができます。データの以前のスナップショットにタイムトラベルできたり、AWS内外の様々な場所からデータにクエリを実行できたり、自動化されたテーブルメンテナンスによるパフォーマンスとコストの利点を得ることができます。
AWS Glue Data Catalogを活用してAmazon S3テーブルをお好みのアナリティクスサービスに橋渡しし、アナリティクスアプリケーションの構築を劇的に簡素化するこの取り組みに、私は非常に興奮しています。これがS3テーブルをプリミティブとして使用して組み合わせることができるものの一例です。
今週発表したS3の新機能についてもう1つお話ししたいと思います。それはS3 Metadata Tablesと呼ばれるものです。 S3 Metadata Tablesは、汎用のS3バケットの内容に関するメタデータを自動的に生成し、そのデータをS3 Table bucketのApache Icebergテーブルにほぼリアルタイムで保存します。S3 Metadata Tablesが特に価値があるのは、単なるオブジェクトのリスト以上のものだからです。オブジェクトのタグやユーザー定義のメタデータなどのメタ情報を含んでいます。ストレージコストや変更日時、その他の詳細情報も含まれています。S3 Metadata Tablesは、S3バケットに保存されているデータの豊富で常に最新のインベントリを提供します。
S3 Metadata Tablesは、お客様が所有するS3 Table bucketにデータを保存するため、これまでお話ししてきたメリットがすべて適用されます。Amazon Athenaを使って、バケット内のオブジェクトを見つけるためのアドホッククエリを実行できます。S3 Metadata Tablesを他のデータソースと組み合わせて、豊富な分析を行うことができます。これらのメタデータテーブルに対して細かなアクセス制御を行い、ユーザーが閲覧できるメタデータの範囲を制御することができます。S3 Tablesを使用して、このようなことがすべて可能です。S3 Metadata Tablesは今週からプレビュー版として提供を開始しており、S3 Tablesを基盤として皆様がどのようなものを構築されるのか、とても楽しみにしています。
これで駆け足のツアーは終わりです。 さらに詳しく知りたい方のために、豊富なドキュメントをご用意しています。S3 Tablesは、完全マネージド型のApache Icebergサービスです。タイムトラベルやトランザクションのセマンティクス、行レベルの更新と削除といったApache Icebergのメリットに加えて、弾力的なストレージや大規模データセットに対する極めて高いパフォーマンスなど、S3ならではのメリットもすべて得られます。S3 Tablesでは、既存のIcebergストレージの運用オーバーヘッドなしにこれらすべてを手に入れることができます。私たちがすべてのメンテナンスを行い、IAMとLake Formationによる新しいアクセス制御メカニズムを提供し、保存しているデータを最大限活用できるようAWSのAnalyticsシステムとすべてを自動的に統合します。
S3チーム全体がこれらの機能を提供するために懸命に働いてきました。私はこれらについてお話しできることを本当に幸運に感じています。特にS3 TablesとS3 Metadata Tablesについて、皆様からのフィードバックを心待ちにしています。これはS3によるApache Icebergとオープンフォーマットの採用の始まりに過ぎないと考えており、今後さらに多くの展開が期待できます。本日午後、木曜の午後までお時間を割いてS3 Tablesについて学んでいただき、ありがとうございます。お時間が許せば、セッションのアンケートにご協力いただけると幸いです。来年何についてお話しすべきか、何が最も興味深いかを理解する上で役立ちます。改めて、ご参加いただきありがとうございました。今晩のre:Inventをお楽しみください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion