# AWS Glue でのデータ検出とカタログ化 AWS Glue Data Catalog は、組織のデータセットに関するメタデータを保存する一元化されたリポジトリです。データソースの場所、スキーマ、およびランタイムメトリクスへのインデックスとして機能します。メタデータはメタデータテーブルに保存され、そこでは各テーブルが 1 つのデータストアを表します。 データソースを自動的にスキャンしてメタデータを抽出するクローラーを使用してデータカタログに入力できます。クローラーは、内部 (AWS ベース) および AWS 外部のデータソースに接続できます。 サポートされるデータソースについては、「[クロールでサポートされているデータソース](crawler-data-stores.md)」を参照してください。 特定の要件に応じてテーブル構造、スキーマ、パーティション構造を定義することで、データカタログにテーブルを手動で作成することもできます。 メタデータテーブルの手動作成について詳しくは、「[メタデータの手動定義](populate-dg-manual.md)」を参照してください。 データカタログ内の情報を使用して、ETL ジョブを作成し、モニタリングできます。データカタログは他の AWS 分析サービスと統合され、データソースの統合ビューを提供するため、データの管理と分析が容易になります。 + Amazon Athena – SQL を使用して、Amazon S3 データのデータカタログにテーブルメタデータを保存し、クエリします。 + AWS Lake Formation – きめ細かなデータアクセスポリシーを一元的に定義および管理し、データアクセスを監査します。 + Amazon EMR – ビッグデータ処理のためにデータカタログで定義されたデータソースにアクセスします。 + Amazon SageMaker AI – 機械学習モデルを迅速かつ確実に構築、トレーニング、デプロイします。データカタログの主な機能 データカタログの主な側面を次に示します。 メタデータリポジトリ データカタログは中央メタデータリポジトリとして機能し、データソースの場所、スキーマ、プロパティに関する情報を保存します。このメタデータは、従来のリレーショナルデータベースカタログと同様に、データベースとテーブルにまとめられます。 自動データ検出可能性 AWS Glue クローラー では、新規または更新されたデータソースを自動的に検出してカタログ化できるため、手動メタデータ管理のオーバーヘッドが軽減され、データカタログが最新の状態を維持できます。データソースをカタログ化することで、データカタログでは、ユーザーやアプリケーションが組織内で利用可能なデータアセットを簡単に検出して理解できるようになり、データの再利用とコラボレーションが促進されます。 データカタログは、Amazon S3、Amazon RDS、Amazon Redshift、Apache Hive など、さまざまなデータソースをサポートしています。AWS Glue クローラー を使用して、これらのソースからメタデータを自動的に推測して保存できます。 詳細については、「[クローラーを使用したデータカタログへの入力](add-crawler.md)」を参照してください。 スキーマ管理 データカタログは、スキーマの推論、進化、バージョニングなど、データソースのスキーマを自動的にキャプチャして管理します。AWS Glue ETL ジョブを使用して、データカタログ内のスキーマとパーティションを更新できます。 テーブル最適化 Amazon Athena、Amazon EMR、AWS Glue ETL ジョブなどの AWS 分析サービスによる読み取りパフォーマンスを向上させるために、データカタログは、データカタログ内の Iceberg テーブル用にマネージド圧縮 (小さな Amazon S3 オブジェクトを圧縮してより大きなオブジェクトにコンパクト化するプロセス) を提供しています。AWS Glue コンソール、AWS Lake Formation コンソール、AWS CLI API、または AWS API を使用して、データカタログ内の個々の Iceberg テーブルの圧縮を有効または無効にすることができます。 詳細については、「[Iceberg テーブルの最適化](table-optimizers.md)」を参照してください。 列統計 追加のデータパイプラインを設定することなく、Parquet、ORC、JSON、ION、CSV、XML などのデータ形式でデータカタログテーブルの列レベルの統計を計算できます。列統計は、列内の値に関するインサイトを得ることで、データプロファイルを理解するのに役立ちます。データカタログは、最小値、最大値、null 値の合計、個別の値の合計、値の平均長、true 値の合計出現数などの列の値の統計の生成をサポートしています。 詳細については、「[列統計を使用したクエリのパフォーマンスの最適化](column-statistics.md)」を参照してください。 データリネージュ データカタログは、データに対して実行された変換とオペレーションの記録を維持し、データ系統情報を提供します。この系統情報は、データ出所の監査、コンプライアンス、理解に役立ちます。 AWS の他のサービスとの統合 データカタログは、AWS Lake Formation、Amazon Athena、Amazon Redshift Spectrum、Amazon EMR などの他の AWS サービスとシームレスに統合されます。この統合により、1 つの一貫性のあるメタデータレイヤーを使用して、さまざまなデータストアのデータをクエリおよび分析できます。 セキュリティとアクセスコントロール AWS Glue は AWS Lake Formation と統合して、データカタログリソースのきめ細かなアクセスコントロールをサポートすることで、組織のポリシーと要件に基づいてアクセス許可を管理し、データアセットに安全にアクセスできます。AWS Glue は AWS Key Management Service (AWS KMS) と統合して、データカタログに保存されているメタデータを暗号化します。 具体化されたビュー Data Catalog は、Apache Iceberg マテリアライズドビューをサポートしています。これは、SQL クエリの事前に計算された結果を保存し、基盤となるソースデータの変更に応じて自動的に更新するマネージドテーブルです。マテリアライズドビューは、冗長な計算を排除することで、データ変換パイプラインを簡素化し、クエリパフォーマンスを加速します。 マテリアライズドビューは、AWS Glue バージョン 5.1 以降、Amazon EMR リリース 7.12.0 以降、および Amazon Athena で Apache Spark SQL を使用して作成できます。Glue Data Catalog は、Apache Iceberg ソーステーブルを自動的にモニタリングし、マネージドコンピューティングインフラストラクチャを使用してマテリアライズドビューを更新します。AWS Glue、Amazon EMR、Amazon Athena にわたる Spark エンジンは、パフォーマンスが向上する場合にマテリアライズドビューを使用するようにクエリを自動的に書き換えることができます。 マテリアライズドビューは、アカウント内の Amazon S3 Tables バケットまたは Amazon S3 汎用バケットに Apache Iceberg テーブルとして保存されるため、複数のクエリエンジンからアクセスできます。Data Catalog は、自動更新スケジューリング、増分更新、メタデータ管理など、マテリアライズドビューのライフサイクルのすべての側面を管理します。 詳細については、「Using materialized views with AWS Glue」および「Using materialized views with Amazon EMR」を参照してください。 **Topics** + [AWS Glue データカタログの入力](populate-catalog-methods.md) + [トランザクションテーブルへのデータ入力と管理](populate-otf.md) + [データカタログの管理](manage-catalog.md) + [データカタログにアクセスする](access_catalog.md) + [AWS Glue データカタログのベストプラクティス](best-practice-catalog.md) + [Amazon CloudWatch での Data Catalog 使用状況メトリクスのモニタリング](data-catalog-cloudwatch-metrics.md) + [AWS Glue スキーマレジストリ](schema-registry.md) # AWS Glue データカタログの入力 次の方法を使用して AWS Glue Data Catalog にデータを入力できます。 + AWS Glue クローラー – AWS Glue クローラー は、データベース、データレイク、ストリーミングデータなどのデータソースを自動的に検出してカタログ化できます。クローラーは、さまざまなデータソースのメタデータを自動的に検出して推測できるため、データカタログにデータを入力する最も一般的な推奨方法です。 + メタデータの手動追加 – AWS Glue コンソール、Lake Formation コンソール、AWS CLI API、または AWS Glue API を使用して、データベース、テーブル、および接続の詳細を手動で定義し、これらをデータカタログに追加できます。手動入力は、クロールできないデータソースをカタログ化する場合に便利です。 + 他の AWS サービスとの統合 — AWS Lake Formation や Amazon Athena などのサービスからのメタデータをデータカタログに入力できます。これらのサービスは、データカタログでデータソースを検出して登録できます。 + 既存のメタデータリポジトリからの入力 – Apache Hive Metastore などの既存のメタデータストアがある場合は、AWS Glue を使用してそのメタデータをデータカタログにインポートできます。詳細については、GitHub で「[Migration between the Hive Metastore and the AWS Glue Data Catalog](https://github.com/aws-samples/aws-glue-samples/tree/master/utilities/Hive_metastore_migration)」を参照してください。 **Topics** + [クローラーを使用したデータカタログへの入力](add-crawler.md) + [メタデータの手動定義](populate-dg-manual.md) + [Amazon S3 Tables との統合](glue-federation-s3tables.md) + [他の AWS のサービスとの統合](populate-dc-other-services.md) + [データカタログの設定](console-data-catalog-settings.md) # クローラーを使用したデータカタログへの入力 AWS Glue クローラー を使用して、AWS Glue Data Catalog にデータベースとテーブルを入力できます。これは、AWS Glue ユーザーが最もよく使用する基本的な方法です。クローラーは 1 回の実行で複数のデータストアをクロールできます。完了すると、クローラーはデータカタログで 1 つ以上のテーブルを作成または更新します。AWS Glue で定義した抽出、変換、ロード (ETL) ジョブは、これらのデータカタログテーブルをソースおよびターゲットとして使用します。ETL ジョブは、ソースおよびターゲットのデータカタログテーブルで指定されているデータストアに対して読み取りと書き込みを行います。 ## ワークフロー 次のワークフロー図は、AWS Glue クローラーがデータストアや他の要素とやり取りしてデータカタログに入力する方法を示しています。 ![\[AWS Glue クローラーが 5 つの基本的なステップでデータカタログに入力する方法を示すワークフロー。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/PopulateCatalog-overview.png) クローラーが AWS Glue Data Catalog に入力する一般的なワークフローを以下に示します。 1. クローラーが選択した任意のカスタム*分類子*を実行し、データの形式とスキーマを推論します。カスタム分類子のコードを提供すると、指定した順序で実行されます。 データの構造を正常に認識した最初のカスタム分類子がスキーマを作成するために使用されます。リスト内の下位のカスタム分類子はスキップされます。 1. カスタム分類子と一致するデータのスキーマがない場合は、組み込み分類子がデータのスキーマを認識します。組み込み分類子の例に、JSON を認識する分類子があります。 1. クローラーがデータストアに接続します。一部のデータストアでは、クローラーがアクセスするために接続プロパティを必要とします。 1. データの推測されたスキーマが作成されます。 1. クローラーはデータカタログにメタデータを書き込みます。テーブル定義にはデータストア内のデータに関するメタデータが含まれています。テーブルは、Data Catalog でテーブルのコンテナとなるデータベースに書き込まれます。テーブルの属性には分類が含まれます。これは、テーブルのスキーマを推測した分類子により作成されるラベルです。 **Topics** + [ワークフロー](#crawler-workflow) + [クローラーの仕組み](#crawler-running) + [クローラーは、どのようにパーティションを作成するタイミングを判断していますか?](#crawler-s3-folder-table-partition) + [クロールでサポートされているデータソース](crawler-data-stores.md) + [クローラーの前提条件](crawler-prereqs.md) + [分類子の定義と管理](add-classifier.md) + [クローラーの設定](define-crawler.md) + [クローラのスケジュール](schedule-crawler.md) + [クローラーの結果と詳細の表示](console-crawlers-details.md) + [クローラーの動作のカスタマイズ](crawler-configuration.md) + [チュートリアル: AWS Glue クローラの追加](tutorial-add-crawler.md) ## クローラーの仕組み クローラーを実行すると、クローラーは以下のアクションを使用してデータストアを調査します。 + **ローデータの形式、スキーマ、および関連プロパティを確認するためにデータを分類する** – カスタム分類子を作成して分類の結果を設定できます。 + **データをテーブルまたはパーティションにグループ化する** – データはクローラーのヒューリスティックに基づいてグループ化されます。 + **メタデータをデータカタログに書き込む** – クローラーでテーブルやパーティションを追加、更新、削除する方法を設定できます。 クローラーを定義する場合、データの形式を評価してスキーマを推測する分類子を 1 つ以上選択します。クローラーを実行すると、リストで最初にデータストアの認識に成功した分類子を使用してテーブルのスキーマが作成されます。組み込み分類子を使用するか、独自に定義することができます。カスタム分類子は、クローラーを定義する前に別のオペレーションで定義します。AWS Glue には、JSON、CSV、Apache Avro などの形式の共通ファイルからスキーマを推論するための組み込み分類子が用意されています。AWS Glue の組み込み分類子の最新のリストについては、「[組み込み分類子](add-classifier.md#classifier-built-in)」を参照してください。 クローラーで作成するメタデータテーブルは、クローラーの定義時にデータベースに含まれます。クローラーがデータベースを指定しない場合、テーブルはデフォルトのデータベースに配置されます。さらに、各テーブルには、最初にデータストアの認識に成功した分類子により入力された分類子の列があります。 クロールするファイルが圧縮されている場合、クローラーはダウンロードして処理する必要があります。クローラーを実行すると、ファイルを調査して形式と圧縮タイプを判定し、これらのプロパティをデータカタログに書き込みます。一部のファイル形式 (Apache Parquet など) では、ファイルの書き込み時にファイルの一部を圧縮できます。これらのファイルでは、圧縮されたデータはファイルの内部コンポーネントであり、AWS Glue はテーブルをデータカタログ内に書き込むときに `compressionType` プロパティに値を入力しません。一方、*ファイル全体*を圧縮アルゴリズム (gzip など) で圧縮する場合は、テーブルをデータカタログ内に書き込むときに `compressionType` プロパティが事前設定されます。 クローラーは、作成するテーブルの名前を生成します。AWS Glue Data Catalogに保存されるテーブルの名前は、以下のルールに従います。 + 英数字とアンダースコア (`_`) のみを使用できます。 + カスタムプレフィックスは 64 文字より長くすることはできません。 + 名前の長さは最大 128 文字までです。クローラーは、生成した名前が制限内に収まるように切り捨てます。 + 重複するテーブル名が発生した場合、クローラーは名前にハッシュ文字列のサフィックスを追加します。 クローラーが複数回実行される場合 (おそらくスケジュールに基づいて)、データストア内の新規または変更されたファイルやテーブルが検索されます。クローラーの出力には、前回の実行以降に検索された、新しいテーブルとパーティションが含まれています。 ## クローラーは、どのようにパーティションを作成するタイミングを判断していますか? AWS Glue クローラーは、Amazon S3 データストアをスキャンしてバケット内に複数のフォルダを検出すると、フォルダ構造のテーブルのルート、およびどのフォルダがテーブルのパーティションであるかを確認します。テーブルの名前は Amazon S3 プレフィックスまたはフォルダ名に基づいています。クロールするフォルダレベルを指す**インクルードパス**を指定します。フォルダレベルの大半のスキーマが類似している場合、クローラーはテーブルを別個に作成せずに、テーブルのパーティションを作成します。クローラーで別個のテーブルを作成するには、クローラーを定義するときに各テーブルのルートフォルダを別個のデータストアとして追加します。 例えば、次の Amazon S3 フォルダ構造を想定します。 ![\[長方形が複数のレベルにあり、Amazon S3 のフォルダ階層が表されています。一番上の長方形には「Sales」というラベルが付いています。その下の長方形は、「year=2019」とラベル付けされています その下の 2 つの長方形には、「month=Jan」、「month=Feb」というラベルが付けられています。これらの長方形の下には、それぞれ 2 つの長方形があり、それぞれ「day=1」、「day=2」というラベルが付けられています。4 つの「day」(最下部) の長方形の下にはすべて、2 つまたは 4 つのファイルがあります。すべての長方形とファイルは線で接続されています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/crawlers-s3-folders.png) 4 つの最下位レベルのフォルダへのパスは次のとおりです。 ``` S3://sales/year=2019/month=Jan/day=1 S3://sales/year=2019/month=Jan/day=2 S3://sales/year=2019/month=Feb/day=1 S3://sales/year=2019/month=Feb/day=2 ``` クローラーターゲットが `Sales` に設定されており、`day=n` フォルダ内のすべてのファイルが同じ形式 (暗号化されていない JSON など) で、同じか非常によく似たスキーマを持っているとします。クローラーは、パーティションキー `year`、`month`、および `day` で、4 つのパーティションを持つ単一のテーブルを作成します。 次の例では、次の Amazon S3 構造を想定します。 ``` s3://bucket01/folder1/table1/partition1/file.txt s3://bucket01/folder1/table1/partition2/file.txt s3://bucket01/folder1/table1/partition3/file.txt s3://bucket01/folder1/table2/partition4/file.txt s3://bucket01/folder1/table2/partition5/file.txt ``` `table1` と `table2` のファイルのスキーマが類似しており、クローラーに**インクルードパス** `s3://bucket01/folder1/` で定義されているデータストアが 1 つの場合、クローラーは 2 つのパーティションキー列を持つ 1 つのテーブルを作成します。最初のパーティションキー列には `table1` および `table2` が含まれ、2 番目のパーティションキー列には、`table1` パーティションに対して `partition1` から `partition3` まで、および `table2` パーティションに対して `partition4` と `partition5` が含まれます。2 つの個別のテーブルを作成するには、2 つのデータストアを持つクローラーを定義します。この例では、最初の**インクルードパス**を `s3://bucket01/folder1/table1/` として定義し、2 番目を `s3://bucket01/folder1/table2` として定義します。 **注記** Amazon Athenaの場合、各テーブルは Amazon S3 プレフィックス (すべてのオブジェクトを含む) に対応します。オブジェクト別にスキーマが異なる場合、Athena では同じプレフィックス内の異なるオブジェクトを別個のテーブルとして認識しません。これは、クローラーで同じ Amazon S3 プレフィックスから複数のテーブルを作成する場合に発生することがあります。そのため、Athena のクエリで結果が何も返されない場合があります。Athena でテーブルを適切に認識してクエリを実行するには、Amazon S3 フォルダ構造内の異なるテーブルスキーマごとに別個の**インクルードパス**を持つクローラーを作成します。詳細については、「[Athena で AWS Glue を使用するときのベストプラクティス](https://docs.aws.amazon.com/athena/latest/ug/glue-best-practices.html)」およびこちらの「[AWS ナレッジセンターの記事](https://aws.amazon.com/premiumsupport/knowledge-center/athena-empty-results/)」を参照してください。 # クロールでサポートされているデータソース クローラーは、次に示すファイルベースおよびテーブルベースのデータストアをクロールできます。 | クローラーが使用するアクセスタイプ | データストア | | --- | --- | | ネイティブクライアント | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/crawler-data-stores.html) | | JDBC | Amazon Redshift Snowflake Amazon Relational Database Service (Amazon RDS) 内、または Amazon RDS の外部: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/crawler-data-stores.html) | | MongoDB クライアント | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/crawler-data-stores.html) | **注記** 現在、AWS Glue ではデータストリームのクローラーがサポートされていません。 JDBC、MongoDB、MongoDB Atlas、Amazon DocumentDB (MongoDB 互換) データストアでは、クローラーがデータストアに接続するときに使用可能な AWS Glue *接続* を指定する必要があります。Amazon S3 の場合、オプションで Network タイプの接続を指定できます。接続とは、認証情報、URL、Amazon Virtual Private Cloud 情報などの接続情報を保存するデータカタログオブジェクトです。詳細については、「[データへの接続](glue-connections.md)」を参照してください。 クローラーがサポートするドライバーのバージョンは次のとおりです。 | 製品 | クローラーがサポートするドライバー | | --- | --- | | PostgreSQL | 42.2.1 | | Amazon Aurora | ネイティブクローラードライバーと同じ | | MariaDB | 8.0.13 | | Microsoft SQL Server | 6.1.0 | | MySQL | 8.0.13 | | Oracle | 11.2.2 | | Amazon Redshift | 4.1 | | Snowflake | 3.13.20 | | MongoDB | 4.7.2 | | MongoDB Atlas | 4.7.2 | 次に、さまざまなデータストアに関する注意事項を示します。 **Amazon S3** 自分のアカウントのパスをクロールするか、または別のアカウントのパスをクロールするかを選択できます。フォルダにあるすべての Amazon S3 ファイルが同じスキーマを持つ場合、クローラーはテーブルを 1 つ作成します。また、Amazon S3 オブジェクトが分割されている場合、メタデータテーブルは 1 つしか作成されず、そのテーブルのパーティション情報がデータカタログに追加されます。 **Amazon S3 と Amazon DynamoDB** クローラーは、AWS Identity and Access Management (IAM) ロールをアクセス許可のために使用して、データストアにアクセスします。*クローラーに渡すロールは、クロールされる Amazon S3 パスと Amazon DynamoDB テーブルにアクセスするためのアクセス許可を持っている必要があります*。 **Amazon DynamoDB** AWS Glue コンソールを使用してクローラーを定義するとき、1 つのDynamoDB テーブルを指定します。AWS Glue API を使用している場合、テーブルのリストを指定できます。クローラーの実行時間を短縮するために、データの小さなサンプルのみをクロールするように選択できます。 **Delta Lake** 各 Delta Lake データストアで、Delta テーブルの作成方法を指定します。 + **[Create Native tables]** (ネイティブテーブルの作成): Delta トランザクションログの直接クエリをサポートするクエリエンジンとの統合を可能にします。詳細については、「[Delta Lake テーブルのクエリを実行する](https://docs.aws.amazon.com/athena/latest/ug/delta-lake-tables.html)」を参照してください。 + **[Create Symlink tables]** (Symlink テーブルの作成): 指定された設定パラメータに基づいて、マニフェストファイルを分割キーで分割して `_symlink_manifest` フォルダを作成します。 **Iceberg** Iceberg データストアごとに、Iceberg テーブルのメタデータを含む Amazon S3 パスを指定します。クローラーは Iceberg テーブルのメタデータを検出すると、それをデータカタログに登録します。クローラーがテーブルを更新し続けるように、スケジュールを設定できます。 データストアに次のパラメータを定義できます。 + **Exclusions**: 特定のフォルダをスキップできます。 + **Maximum Traversal Depth**: Amazon S3 バケットでクローラーがクロールできる深度の制限を設定します。デフォルトの最大トラバーサル深度は 10 で、設定できる最大深度は 20 です。 **Hudi** Hudi データストアごとに、Hudi テーブルのメタデータを含む Amazon S3 パスを指定します。クローラーは Hudi テーブルのメタデータを検出すると、それをデータカタログに登録します。クローラーがテーブルを更新し続けるように、スケジュールを設定できます。 データストアに次のパラメータを定義できます。 + **Exclusions**: 特定のフォルダをスキップできます。 + **Maximum Traversal Depth**: Amazon S3 バケットでクローラーがクロールできる深度の制限を設定します。デフォルトの最大トラバーサル深度は 10 で、設定できる最大深度は 20 です。 Hudi 0.13.1 およびタイムスタンプ型と互換性がないため、論理型として `millis` を含むタイムスタンプ列は、`bigint` として解釈されます。解決策は、今後の Hudi リリースで提供される可能性があります。 Hudi テーブルは次のように分類され、それぞれが固有の意味を持っています。 + 書き込み時コピー (CoW): データは列形式 (Parquet) で保存され、更新ごとに書き込み中にファイルの新しいバージョンが作成されます。 + 読み取り時マージ (MoR): データは、列形式 (Parquet) と行形式 (Avro) の組み合わせを使用して保存されます。更新は、行形式の差分ファイルに記録され、必要に応じて圧縮されて、新しいバージョンの列形式のファイルが作成されます。 CoW データセットでは、レコードが更新されるたびに、そのレコードを含むファイルが更新された値で書き換えられます。MoR データセットでは、更新があるたびに、Hudi によって変更されたレコードの行のみが書き込まれます。MoR は、読み取りが少なく書き込みまたは変更が多いワークロードに適しています。CoW は、頻繁に変更されないデータの読み取りが多いワークロードに適しています。 Hudi にはデータにアクセスするためのクエリタイプが 3 種類用意されています。 + スナップショットクエリ: 指定されたコミットまたは圧縮アクションの時点で最新のテーブルスナップショットを参照するクエリです。MoR テーブルの場合、スナップショットクエリは、クエリ時に最新のファイルスライスのベースファイルとデルタファイルをマージして、テーブルの最新の状態を提示します。 + 増分クエリ: クエリは、指定されたコミット/圧縮以降にテーブルに書き込まれた新しいデータのみを参照します。これにより、増分データパイプラインを有効にするための変更ストリームが効果的に提供されます。 + 読み取り最適化クエリ: MoR テーブルの場合、クエリは圧縮された最新のデータを参照します。CoW テーブルの場合、クエリはコミットされた最新のデータを参照します。 書き込み時コピー (CoW) テーブルの場合、クローラーは ReadOptimized serde `org.apache.hudi.hadoop.HoodieParquetInputFormat` を使用して、データカタログに 1 つのテーブルを作成します。 読み取り時マージ (MoR) テーブルの場合、クローラーはデータカタログ内の同じテーブルの場所に次の 2 つのテーブルを作成します。 + サフィックス `_ro` を持ち、ReadOptimized serde `org.apache.hudi.hadoop.HoodieParquetInputFormat` を使用するテーブル。 + サフィックス `_rt` を持ち、スナップショットクエリを可能にする RealTime Serde `org.apache.hudi.hadoop.realtime.HoodieParquetRealtimeInputFormat` を使用するテーブル。 **MongoDB と Amazon DocumentDB (MongoDB 互換)** MongoDB バージョン 3.2 以降がサポートされています。クローラーの実行時間を短縮するために、データの小さなサンプルのみをクロールするように選択できます。 **リレーショナルデータベース** データベースのユーザー名とパスワードを使用して認証します。データベースエンジンのタイプに応じて、どのオブジェクト (データベース、スキーマ、テーブルなど) をクロールするかを選択できます。 **Snowflake** Snowflake JDBC クローラーは、テーブル、外部テーブル、ビュー、マテリアライズドビューのクローリングをサポートしています。マテリアライズドビュー定義は入力されません。 Snowflake 外部テーブルについては、Amazon S3 の場所を指している場合のみクローラーによってクローリングされます。クローラーは、テーブルスキーマの他に、Amazon S3 の場所、ファイル形式、および出力をデータカタログテーブルのテーブルパラメータとしてクローリングします。分割された外部テーブルのパーティション情報は入力されないことに注意してください。 Snowflake クローラーを使用して作成されたデータカタログテーブルでは、ETL は現在サポートされていません。 # クローラーの前提条件 クローラーは、定義する時に指定する AWS Identity and Access Management (IAM) ロール のアクセス許可を取得します。この IAM ロールには、データストアからデータを抽出してデータカタログに書き込むためのアクセス許可が必要です。AWS Glue コンソールには、AWS Glue プリンシパルサービスの信頼ポリシーがアタッチされた IAM ロールだけがリスト表示されています。コンソールから、クローラーがアクセスするAmazon S3 データストアにアクセスするための IAM ポリシーを持つ IAM ロールを作成できます。AWS Glue のロールの指定の詳細については、「[AWS Glue のアイデンティティベースのポリシー](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies)」を参照してください。 **注記** Delta Lake データストアをクロールする場合、Amazon S3 の場所に対する読み取り/書き込み権限が必要です。 クローラーには、ロールを作成して次のポリシーをアタッチできるようになりました。 + `AWSGlueServiceRole` AWS 管理ポリシー。データカタログに必要なアクセス許可を付与します。 + データソースに対するアクセス許可を付与するインラインポリシー。 + ロールに対する `iam:PassRole` アクセス許可を付与するインラインポリシー。 AWS Glue コンソールクローラーウィザードにロールを作成させるのが、より迅速なアプローチです。これによって作成されるロールは、クローラー専用であり、`AWSGlueServiceRole` AWS 管理ポリシーと、指定したデータソースに必要なインラインポリシーを含んでいます。 クローラーに既存のロールを指定する場合は、そのロールに `AWSGlueServiceRole` ポリシーまたは同等のポリシー (またはこのポリシーのスコープダウンバージョン) と、必要なインラインポリシーが含まれてることを確認します。例えば、Amazon S3 データストアの場合、インラインポリシーは少なくとも次のようになります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::bucket/object*" ] } ] } ``` ------ Amazon DynamoDB データストアの場合、ポリシーは、少なくとも次のようになります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:DescribeTable", "dynamodb:Scan" ], "Resource": [ "arn:aws:dynamodb:us-east-1:111122223333:table/table-name*" ] } ] } ``` ------ また、クローラーが AWS Key Management Service (AWS KMS) 暗号化 Amazon S3 データを読み取る場合、IAM ロールには AWS KMS キーの復号化のアクセス許可が必要です。詳細については、「[ステップ 2: AWS Glue 用の IAM ロールを作成する](create-an-iam-role.md)」を参照してください。 # 分類子の定義と管理 分類子はデータをデータストアに読み取ります。データの形式を認識すると、スキーマが生成されます。分類子も、形式の認識がどれほど確実かを示す確信度数を返します。 AWS Glue では一連の組み込み分類子が用意されていますが、カスタム分類子を作成することもできます。AWS Glue は、クローラ定義で指定した順序で、カスタム分類子を最初に呼び出します。カスタム分類子から返された結果に応じて、AWS Glue が組み込みの分類子を呼び出す場合もあります。処理中に分類子が `certainty=1.0` を返した場合、正しいスキーマを 100% 確実に作成できることを示しています。次に、AWS Glue はその分類子の出力を使用します。 分類子が `certainty=1.0` を返さない場合、AWS Glue は最も高い確実性を持つ分類子の出力を使用します。どの分類子からも `0.0` 以上の確実性が返されない場合、AWS Glue は `UNKNOWN` のデフォルト分類文字列を返します。 ## 分類子を使用するタイミング データストアをクロールして AWS Glue Data Catalog でメタデータテーブルを定義する際に分類子を使用します。順序付けられた一連の分類子を使用してクローラーをセットアップできます。クローラーが分類子を呼び出す際、分類子はデータが認識されるかどうかを判断します。分類子がデータを認識できない、または 100% 確実ではない場合、クローラーはリストにある次の分類子を呼び出して、データを認識できるかどうか判断します。 AWS Glue コンソールを使用して分類子を作成する方法の詳細については、「[AWS Glue コンソールを使用した分類子の作成](console-classifiers.md)」を参照してください。 ## カスタム分類子 分類子の出力には、ファイルの分類や形式 (例えば、`json`)、およびファイルのスキーマを示す文字列が含まれます。カスタム分類子の場合は、分類子のタイプに基づいてスキーマを作成するためのロジックを定義します。分類子のタイプには、grok パターン、XML タグ、および JSON パスに基づくスキーマの定義が含まれています。 分類子の定義を変更すると、変更前の分類子を使用してクロールしたデータは再分類されません。クローラーは、以前にクロールしたデータを追跡します。新しいデータは、更新された分類子で分類されるため、スキーマが更新される場合があります。データのスキーマが更新された場合は、クローラーの実行時に分類子を更新してスキーマの変更を反映してください。データを再分類して不正な分類子を修正するには、更新された分類子を使用して新しいクローラーを作成します。 AWS Glue でカスタム分類子を作成する方法については、「[さまざまなデータ形式のカスタム分類子の記述](custom-classifier.md)」を参照してください。 **注記** 組み込み分類子のいずれかでデータ形式が認識される場合、カスタム分類子を作成する必要はありません。 ## 組み込み分類子 AWS Glue は、JSON、CSV、ウェブログ、および多くのデータベースシステムを含む、さまざまな形式の組み込み分類子を提供します。 AWS Glue が入力データ形式に 100% 確実に適合するカスタム分類子を検出できない場合、次の表に示すような順番で組み込み分類子を呼び出します。組み込み分類子は、形式が一致するか (`certainty=1.0`)、または一致しないか (`certainty=0.0`) どうかを示す結果を返します。`certainty=1.0` を持つ最初の分類子は、Data Catalog での分類文字列とメタデータテーブルのスキーマを提供します。 | 分類子タイプ | 分類文字列 | メモ | | --- | --- | --- | | Apache Avro | avro | ファイルの先頭にあるスキーマを読み取って形式を判断します。 | | Apache ORC | orc | ファイルのメタデータを読み取って形式を判断します。 | | Apache Parquet | parquet | ファイルの末尾にあるスキーマを読み取って形式を判断します。 | | JSON | json | ファイルの先頭から読み取って形式を判断します。 | | バイナリ型 JSON | bson | ファイルの先頭から読み取って形式を判断します。 | | XML | xml | ファイルの先頭から読み取って形式を判断します。AWS Glue は、ドキュメントの XML タグに基づいてテーブルスキーマを判定します。 カスタム XML を作成してドキュメントの行を指定するには、「[XML カスタム分類子の書き込み](custom-classifier.md#custom-classifier-xml)」を参照してください。 | | Amazon Ion | ion | ファイルの先頭から読み取って形式を判断します。 | | Combined Apache ログ | combined\$1apache | grok パターンを通じてログ形式を判断します。 | | Apache ログ | apache | grok パターンを通じてログ形式を判断します。 | | Linux カーネルログ | linux\$1kernel | grok パターンを通じてログ形式を判断します。 | | Microsoft ログ | microsoft\$1log | grok パターンを通じてログ形式を判断します。 | | Ruby ログ | ruby\$1logger | ファイルの先頭から読み取って形式を判断します。 | | Squid 3.x ログ | squid | ファイルの先頭から読み取って形式を判断します。 | | Redis 監視ログ | redismonlog | ファイルの先頭から読み取って形式を判断します。 | | Redis ログ | redislog | ファイルの先頭から読み取って形式を判断します。 | | CSV | csv | カンマ (,)、パイプ (\$1)、タブ (\$1t)、セミコロン (;)、および Ctrl-A (\$1u0001)の区切り記号をチェックします。Ctrl-A は Start Of Heading の Unicode 制御文字です。 | | Amazon Redshift | redshift | JDBC 接続を使用してメタデータをインポートします。 | | MySQL | mysql | JDBC 接続を使用してメタデータをインポートします。 | | PostgreSQL | postgresql | JDBC 接続を使用してメタデータをインポートします。 | | Oracle データベース | oracle | JDBC 接続を使用してメタデータをインポートします。 | | Microsoft SQL Server | sqlserver | JDBC 接続を使用してメタデータをインポートします。 | | Amazon DynamoDB | dynamodb | DynamoDB テーブルからデータを読み取ります。 | 以下の圧縮形式のファイルが分類できます。 + ZIP (単一ファイルのみを含むアーカイブに対応)。Zip は他のサービスでは十分にサポートされていないため注意してください (アーカイブのため)。 + BZIP + GZIP + LZ4 + Snappy (標準および Hadoop ネイティブの Snappy 形式の両方をサポート） ### 組み込み CSV 分類子 組み込み CSV 分類子では、CSV ファイルの内容を解析して AWS Glue テーブルのスキーマを判断します。この分類子は以下の区切り記号を確認します。 + カンマ (,) + パイプ (\$1) + タブ (\$1t) + セミコロン (;) + Ctrl-A (\$1u0001) Ctrl-A は `Start Of Heading` の Unicode 制御文字です。 CSV として分類されるためには、テーブルのスキーマに少なくとも 2 つのデータ列と 2 つのデータ行が必要です。CSV 分類子では、いくつかのヒューリスティックを使用して特定のファイルにヘッダーがあるかどうかを判断します。分類子で最初のデータ行にヘッダーを確認できない場合は、列のヘッダーが `col1`、`col2`、`col3` のように表示されます。組み込み CSV 分類子では、以下のファイルの特性を評価することで、ヘッダーを推測するかどうかを決めます。 + ヘッダー候補の各列が STRING データ型として解析されます。 + 最後の列を除き、ヘッダー候補の各列に 150 文字未満のコンテンツがあります。末尾の区切り記号を許可するには、ファイル全体で最後の列を空欄にすることができます。 + ヘッダー候補の各列が、列名に関する AWS Glue `regex` 要件を満たす必要があります。 + ヘッダー行は、データ行と十分に異なっている必要があります。これを判断するには、1 つ以上の行が STRING 型以外として解析されることを確認します。すべての列が STRING 型である場合、最初のデータ行は以降の行と十分に異なっていないため、ヘッダーとして使用できません。 **注記** 組み込み CSV 分類子で必要な AWS Glue テーブルが作成されない場合は、以下のいずれかの代替方法を使用できます。 Data Catalog で列名を変更し、`SchemaChangePolicy` を LOG に設定して、今後のクローラー実行に備えてパーティションの出力設定を `InheritFromTable` に設定します。 データを分類するためのカスタム grok 分類子を作成し、必要な列を割り当てます。 組み込み CSV 分類子では、`LazySimpleSerDe` をシリアル化ライブラリとして参照するテーブルを作成します。これは、型の推定に適しています。ただし、CSV データ内に引用符で囲まれた文字列がある場合は、テーブル定義を編集して SerDe ライブラリを `OpenCSVSerDe` に変更します。推定した型を STRING に調整し、`SchemaChangePolicy` を LOG に設定して、将来のクローラ実行に関してパーティションの出力設定を `InheritFromTable` に設定します。SerDe ライブラリの詳細については、Amazon Athena ユーザーガイドの「[SerDe リファレンス](https://docs.aws.amazon.com/athena/latest/ug/serde-reference.html)」を参照してください。 # さまざまなデータ形式のカスタム分類子の記述 AWS Glue でデータを分類するためのカスタム分類子を提供できます。grok パターン、XML タグ、JavaScript Object Notation (JSON)、またはカンマ区切り値 (CSV) を使用してカスタム分類子を作成できます。AWS Glue クローラがカスタム分類子を呼び出します。分類子がデータを認識すると、データの分類とスキーマがクローラに返されます。組み込みの分類子にデータが一致しない場合、または、クローラにより作成されたテーブルをカスタマイズする場合は、カスタム分類子を定義する必要があるかもしれません。 AWS Glue コンソールを使用して分類子を作成する方法の詳細については、「[AWS Glue コンソールを使用した分類子の作成](console-classifiers.md)」を参照してください。 AWS Glue は、組み込みの分類子の前に、指定した順序でカスタム分類子を実行します。クローラがデータに一致する分類子を検出すると、分類の文字列とスキーマが AWS Glue Data Catalog に書き込まれるテーブルの定義で使用されます。 **Topics** + [Grok カスタム分類子の書き込み](#custom-classifier-grok) + [XML カスタム分類子の書き込み](#custom-classifier-xml) + [JSON カスタム分類子の書き込み](#custom-classifier-json) + [CSV カスタム分類子の書き込み](#custom-classifier-csv) ## Grok カスタム分類子の書き込み Grok は、一致するパターンによりテキストデータを解析するために使用するツールです。grok パターンは名前のついた一連の正規表現 (regex) で、一度に 1 行のデータごとに一致させるために使用されます。AWS Glue​ は grok パターンを使用してデータのスキーマを推測します。grok パターンがデータと一致すると、AWS Glue はそのパターンを使用してデータの構造を判断し、フィールドにマッピングします。 AWS Glue は数多くの組み込みパターンを提供します。または、独自のパターンを定義することもできます。組み込みパターンとカスタム分類子の定義にあるカスタムパターンを使用して grok パターンを作成できます。grok パターンをカスタマイズしてカスタムテキストファイル形式を分類できます。 **注記** AWS Glue grok カスタム分類子は、AWS Glue Data Catalog で作成されたテーブルの `GrokSerDe` シリアル化ライブラリを使用します。AWS Glue Data Catalog で Amazon Athena、Amazon EMR、または Redshift Spectrum を使用している場合、`GrokSerDe` のサポートに関する情報については、これらのサービスに関するドキュメントを確認してください。現在、Amazon EMR と Redshift Spectrum の `GrokSerDe` を使用して作成されたテーブルのクエリを実行する際に問題が発生することがあります。 grok パターンのコンポーネントの基本的な構文を以下に示します。 ``` %{PATTERN:field-name} ``` 名付けられた `PATTERN` に一致するデータは、スキーマの `field-name` 列にデフォルトのデータ型 `string` でマッピングされます。必要に応じて、フィールドのデータ型は結果のスキーマの `byte`、`boolean`、`double`、`short`、`int`、`long`、または `float` にキャストできます。 ``` %{PATTERN:field-name:data-type} ``` たとえば、`num` フィールドを `int` データ型にキャストするには、以下のパターンを使用することができます。 ``` %{NUMBER:num:int} ``` パターンは他のパターンで構成できます。たとえば、`SYSLOG` タイムスタンプのパターンを月、日、時間のパターン (`Feb 1 06:25:43` など) で定義できます。このデータの場合、次のパターンを定義できます。 ``` SYSLOGTIMESTAMP %{MONTH} +%{MONTHDAY} %{TIME} ``` **注記** grok パターンは、一度に 1 行ずつしか処理できません。複数行のパターンはサポートされていません。また、パターン内の改行はサポートされていません。 ### grok 分類子のカスタム値 grok 分類子を定義する場合、以下の値を指定しカスタム分類子を作成します。 **名前** 分類子の名前。 **分類** 分類されたデータの形式を説明するために記述されたテキスト文字列 (例: `special-logs`)。 **Grok パターン** データストアに適用される一連のパターンで、一致があるかどうかを決定します。これらのパターンは AWS Glue の[組み込みパターン](#classifier-builtin-patterns)と定義されたカスタムパターンによるものです。 grok パターンのシンプルな例を次に示します。 ``` %{TIMESTAMP_ISO8601:timestamp} \[%{MESSAGEPREFIX:message_prefix}\] %{CRAWLERLOGLEVEL:loglevel} : %{GREEDYDATA:message} ``` データが `TIMESTAMP_ISO8601` と一致すると、スキーマの列 `timestamp` が作成されます。動作は、例にある他の名前付きパターンに似ています。 **カスタムパターン** 独自に定義するオプションのカスタムパターン。これらのパターンは、データを分類する grok パターンにより参照されます。データに適用される grok パターンでこれらのカスタムパターンを参照できます。各カスタムコンポーネントパターンは別々の行にある必要があります。[正規表現 (regex)](http://en.wikipedia.org/wiki/Regular_expression) 構文は、パターンを定義するために使用されます。 以下は、カスタムパターンを使用する例です。 ``` CRAWLERLOGLEVEL (BENCHMARK|ERROR|WARN|INFO|TRACE) MESSAGEPREFIX .*-.*-.*-.*-.* ``` 最初の名前付きカスタムパターンである `CRAWLERLOGLEVEL` は、列挙された文字列の 1 つとデータが一致するときに一致となります。2 番目のカスタムパターン `MESSAGEPREFIX` は、メッセージのプレフィックス文字列との一致を試みます。 AWS Glue は、作成日時、最終更新時間、分類子のバージョンを追跡します。 ### 組み込みパターン AWS Glue は、カスタム分類子を構築するために使用できる多くの一般的なパターンを提供します。分類子の定義の `grok pattern` に名前付きパターンを追加します。 次のリストは、各パターンの行です。各行で、パターン名の後に定義があります。[正規表現 (regex)](http://en.wikipedia.org/wiki/Regular_expression) 構文は、パターンを定義するために使用されます。 ``` #&GLU; Built-in patterns USERNAME [a-zA-Z0-9._-]+ USER %{USERNAME:UNWANTED} INT (?:[+-]?(?:[0-9]+)) BASE10NUM (?[+-]?(?:(?:[0-9]+(?:\.[0-9]+)?)|(?:\.[0-9]+))) NUMBER (?:%{BASE10NUM:UNWANTED}) BASE16NUM (?(?"(?>\\.|[^\\"]+)+"|""|(?>'(?>\\.|[^\\']+)+')|''|(?>`(?>\\.|[^\\`]+)+`)|``)) UUID [A-Fa-f0-9]{8}-(?:[A-Fa-f0-9]{4}-){3}[A-Fa-f0-9]{12} # Networking MAC (?:%{CISCOMAC:UNWANTED}|%{WINDOWSMAC:UNWANTED}|%{COMMONMAC:UNWANTED}) CISCOMAC (?:(?:[A-Fa-f0-9]{4}\.){2}[A-Fa-f0-9]{4}) WINDOWSMAC (?:(?:[A-Fa-f0-9]{2}-){5}[A-Fa-f0-9]{2}) COMMONMAC (?:(?:[A-Fa-f0-9]{2}:){5}[A-Fa-f0-9]{2}) IPV6 ((([0-9A-Fa-f]{1,4}:){7}([0-9A-Fa-f]{1,4}|:))|(([0-9A-Fa-f]{1,4}:){6}(:[0-9A-Fa-f]{1,4}|((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(([0-9A-Fa-f]{1,4}:){5}(((:[0-9A-Fa-f]{1,4}){1,2})|:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(([0-9A-Fa-f]{1,4}:){4}(((:[0-9A-Fa-f]{1,4}){1,3})|((:[0-9A-Fa-f]{1,4})?:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){3}(((:[0-9A-Fa-f]{1,4}){1,4})|((:[0-9A-Fa-f]{1,4}){0,2}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){2}(((:[0-9A-Fa-f]{1,4}){1,5})|((:[0-9A-Fa-f]{1,4}){0,3}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){1}(((:[0-9A-Fa-f]{1,4}){1,6})|((:[0-9A-Fa-f]{1,4}){0,4}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(:(((:[0-9A-Fa-f]{1,4}){1,7})|((:[0-9A-Fa-f]{1,4}){0,5}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:)))(%.+)? IPV4 (?/(?>[\w_%!$@:.,~-]+|\\.)*)+ #UNIXPATH (?[A-Za-z]+:|\\)(?:\\[^\\?*]*)+ URIPROTO [A-Za-z]+(\+[A-Za-z+]+)? URIHOST %{IPORHOST}(?::%{POSINT:port})? # uripath comes loosely from RFC1738, but mostly from what Firefox # doesn't turn into %XX URIPATH (?:/[A-Za-z0-9$.+!*'(){},~:;=@#%_\-]*)+ #URIPARAM \?(?:[A-Za-z0-9]+(?:=(?:[^&]*))?(?:&(?:[A-Za-z0-9]+(?:=(?:[^&]*))?)?)*)? URIPARAM \?[A-Za-z0-9$.+!*'|(){},~@#%&/=:;_?\-\[\]]* URIPATHPARAM %{URIPATH}(?:%{URIPARAM})? URI %{URIPROTO}://(?:%{USER}(?::[^@]*)?@)?(?:%{URIHOST})?(?:%{URIPATHPARAM})? # Months: January, Feb, 3, 03, 12, December MONTH \b(?:Jan(?:uary)?|Feb(?:ruary)?|Mar(?:ch)?|Apr(?:il)?|May|Jun(?:e)?|Jul(?:y)?|Aug(?:ust)?|Sep(?:tember)?|Oct(?:ober)?|Nov(?:ember)?|Dec(?:ember)?)\b MONTHNUM (?:0?[1-9]|1[0-2]) MONTHNUM2 (?:0[1-9]|1[0-2]) MONTHDAY (?:(?:0[1-9])|(?:[12][0-9])|(?:3[01])|[1-9]) # Days: Monday, Tue, Thu, etc... DAY (?:Mon(?:day)?|Tue(?:sday)?|Wed(?:nesday)?|Thu(?:rsday)?|Fri(?:day)?|Sat(?:urday)?|Sun(?:day)?) # Years? YEAR (?>\d\d){1,2} # Time: HH:MM:SS #TIME \d{2}:\d{2}(?::\d{2}(?:\.\d+)?)? # TIME %{POSINT<24}:%{POSINT<60}(?::%{POSINT<60}(?:\.%{POSINT})?)? HOUR (?:2[0123]|[01]?[0-9]) MINUTE (?:[0-5][0-9]) # '60' is a leap second in most time standards and thus is valid. SECOND (?:(?:[0-5]?[0-9]|60)(?:[:.,][0-9]+)?) TIME (?!<[0-9])%{HOUR}:%{MINUTE}(?::%{SECOND})(?![0-9]) # datestamp is YYYY/MM/DD-HH:MM:SS.UUUU (or something like it) DATE_US %{MONTHNUM}[/-]%{MONTHDAY}[/-]%{YEAR} DATE_EU %{MONTHDAY}[./-]%{MONTHNUM}[./-]%{YEAR} DATESTAMP_US %{DATE_US}[- ]%{TIME} DATESTAMP_EU %{DATE_EU}[- ]%{TIME} ISO8601_TIMEZONE (?:Z|[+-]%{HOUR}(?::?%{MINUTE})) ISO8601_SECOND (?:%{SECOND}|60) TIMESTAMP_ISO8601 %{YEAR}-%{MONTHNUM}-%{MONTHDAY}[T ]%{HOUR}:?%{MINUTE}(?::?%{SECOND})?%{ISO8601_TIMEZONE}? TZ (?:[PMCE][SD]T|UTC) DATESTAMP_RFC822 %{DAY} %{MONTH} %{MONTHDAY} %{YEAR} %{TIME} %{TZ} DATESTAMP_RFC2822 %{DAY}, %{MONTHDAY} %{MONTH} %{YEAR} %{TIME} %{ISO8601_TIMEZONE} DATESTAMP_OTHER %{DAY} %{MONTH} %{MONTHDAY} %{TIME} %{TZ} %{YEAR} DATESTAMP_EVENTLOG %{YEAR}%{MONTHNUM2}%{MONTHDAY}%{HOUR}%{MINUTE}%{SECOND} CISCOTIMESTAMP %{MONTH} %{MONTHDAY} %{TIME} # Syslog Dates: Month Day HH:MM:SS SYSLOGTIMESTAMP %{MONTH} +%{MONTHDAY} %{TIME} PROG (?:[\w._/%-]+) SYSLOGPROG %{PROG:program}(?:\[%{POSINT:pid}\])? SYSLOGHOST %{IPORHOST} SYSLOGFACILITY <%{NONNEGINT:facility}.%{NONNEGINT:priority}> HTTPDATE %{MONTHDAY}/%{MONTH}/%{YEAR}:%{TIME} %{INT} # Shortcuts QS %{QUOTEDSTRING:UNWANTED} # Log formats SYSLOGBASE %{SYSLOGTIMESTAMP:timestamp} (?:%{SYSLOGFACILITY} )?%{SYSLOGHOST:logsource} %{SYSLOGPROG}: MESSAGESLOG %{SYSLOGBASE} %{DATA} COMMONAPACHELOG %{IPORHOST:clientip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})" %{NUMBER:response} (?:%{Bytes:bytes=%{NUMBER}|-}) COMBINEDAPACHELOG %{COMMONAPACHELOG} %{QS:referrer} %{QS:agent} COMMONAPACHELOG_DATATYPED %{IPORHOST:clientip} %{USER:ident;boolean} %{USER:auth} \[%{HTTPDATE:timestamp;date;dd/MMM/yyyy:HH:mm:ss Z}\] "(?:%{WORD:verb;string} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion;float})?|%{DATA:rawrequest})" %{NUMBER:response;int} (?:%{NUMBER:bytes;long}|-) # Log Levels LOGLEVEL ([A|a]lert|ALERT|[T|t]race|TRACE|[D|d]ebug|DEBUG|[N|n]otice|NOTICE|[I|i]nfo|INFO|[W|w]arn?(?:ing)?|WARN?(?:ING)?|[E|e]rr?(?:or)?|ERR?(?:OR)?|[C|c]rit?(?:ical)?|CRIT?(?:ICAL)?|[F|f]atal|FATAL|[S|s]evere|SEVERE|EMERG(?:ENCY)?|[Ee]merg(?:ency)?) ``` ## XML カスタム分類子の書き込み XML は、ファイル内のタグを使用してドキュメントの構造を定義します。XML カスタム分類子で、行の定義に使用されるタグ名を指定できます。 ### XML 分類子のカスタム分類子値 XML 分類子を定義する場合、AWS Glue に以下の値を指定し分類子を作成します。この分類子の分類フィールドは `xml` に設定してあります。 **名前** 分類子の名前。 **行タグ** XML ドキュメントでテーブル行を定義する XML タグ名、山括弧 `< >` なし。名前は XML タグ規則に沿って命名する必要があります。 行データを含む要素は、自動で閉じる空の要素にすることは**できません**。たとえば、次の空の要素は ** によって解析**されませんAWS Glue。 ``` ``` 空の要素は次のように記述できます。 ``` ``` AWS Glue は、作成日時、最終更新時間、分類子のバージョンを追跡します。 たとえば、次の XML ファイルがあるとします。筆者と役職の列のみを含む AWS Glue テーブルを作成するには、`AnyCompany` として [**行タグ**] を使用し、AWS Glue コンソールで分類子を作成します。次に、このカスタム分類子を使用するクローラを追加して実行します。 ``` Rivera, Martha AnyCompany Developer Guide Stiles, John Style Guide for AnyCompany ``` ## JSON カスタム分類子の書き込み JSON は、データ交換形式です。名前と値のペア、または順序付きの値のリストでデータ構造を定義します。JSON カスタム分類子では、データ構造への JSON パスを指定し、それを使用してテーブルのスキーマを定義できます。 ### AWS Glue のカスタム分類子の値 JSON 分類子を定義する場合、AWS Glue に以下の値を指定し分類子を作成します。この分類子の分類フィールドは `json` に設定してあります。 **名前** 分類子の名前。 **JSON パス** テーブルスキーマを定義するために使用されるオブジェクトを指す JSON パス。JSON パスは、ドット表記またはブラケット表記で記述できます。以下の演算子がサポートされています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/custom-classifier.html) AWS Glue は、作成日時、最終更新時間、分類子のバージョンを追跡します。 **Example JSON 分類子を使用して配列からレコードをプルする** JSON データがレコードの配列だとします。たとえば、ファイルの最初の数行は次のようになります。 ``` [ { "type": "constituency", "id": "ocd-division\/country:us\/state:ak", "name": "Alaska" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:al\/cd:1", "name": "Alabama's 1st congressional district" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:al\/cd:2", "name": "Alabama's 2nd congressional district" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:al\/cd:3", "name": "Alabama's 3rd congressional district" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:al\/cd:4", "name": "Alabama's 4th congressional district" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:al\/cd:5", "name": "Alabama's 5th congressional district" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:al\/cd:6", "name": "Alabama's 6th congressional district" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:al\/cd:7", "name": "Alabama's 7th congressional district" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:ar\/cd:1", "name": "Arkansas's 1st congressional district" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:ar\/cd:2", "name": "Arkansas's 2nd congressional district" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:ar\/cd:3", "name": "Arkansas's 3rd congressional district" }, { "type": "constituency", "id": "ocd-division\/country:us\/state:ar\/cd:4", "name": "Arkansas's 4th congressional district" } ] ``` 組み込み JSON 分類子を使用してクローラを実行する場合、ファイル全体がスキーマを定義するために使用されます。JSON パスを指定しないので、クローラはデータを 1 つのオブジェクト、つまり、ただの配列として処理します。たとえば、スキーマは次のようになります。 ``` root |-- record: array ``` ただし、JSON 配列の各レコードに基づいたスキーマを作成するには、カスタム JSON 分類子を作成し、JSON パスを `$[*]` として指定します。この JSON パスを指定すると、分類子は配列内の 12 レコードすべてに問合せてスキーマを決定します。結果のスキーマには、各オブジェクトに次の例と同様の個別のフィールドが含まれています。 ``` root |-- type: string |-- id: string |-- name: string ``` **Example JSON 分類子を使用してファイルの一部のみを確認する** JSON データが、[http://everypolitician.org/](http://everypolitician.org/) から取られた JSON ファイルの例 `s3://awsglue-datasets/examples/us-legislators/all/areas.json` のパターンと同様だとします。JSON ファイルのサンプルオブジェクトは、次のようになります。 ``` { "type": "constituency", "id": "ocd-division\/country:us\/state:ak", "name": "Alaska" } { "type": "constituency", "identifiers": [ { "scheme": "dmoz", "identifier": "Regional\/North_America\/United_States\/Alaska\/" }, { "scheme": "freebase", "identifier": "\/m\/0hjy" }, { "scheme": "fips", "identifier": "US02" }, { "scheme": "quora", "identifier": "Alaska-state" }, { "scheme": "britannica", "identifier": "place\/Alaska" }, { "scheme": "wikidata", "identifier": "Q797" } ], "other_names": [ { "lang": "en", "note": "multilingual", "name": "Alaska" }, { "lang": "fr", "note": "multilingual", "name": "Alaska" }, { "lang": "nov", "note": "multilingual", "name": "Alaska" } ], "id": "ocd-division\/country:us\/state:ak", "name": "Alaska" } ``` 組み込み JSON 分類子を使用してクローラを実行する場合、ファイル全体がスキーマを作成するために使用されます。最終的に次のようなスキーマになります。 ``` root |-- type: string |-- id: string |-- name: string |-- identifiers: array | |-- element: struct | | |-- scheme: string | | |-- identifier: string |-- other_names: array | |-- element: struct | | |-- lang: string | | |-- note: string | | |-- name: string ``` ただし、「`id`」オブジェクトだけを使用してスキーマを作成するには、カスタム JSON 分類子を作成し、JSON パスを `$.id` と指定します。その後、スキーマは「`id`」フィールドのみに基づくものとなります。 ``` root |-- record: string ``` このスキーマで抽出されたデータの最初の数行は次のようになります。 ``` {"record": "ocd-division/country:us/state:ak"} {"record": "ocd-division/country:us/state:al/cd:1"} {"record": "ocd-division/country:us/state:al/cd:2"} {"record": "ocd-division/country:us/state:al/cd:3"} {"record": "ocd-division/country:us/state:al/cd:4"} {"record": "ocd-division/country:us/state:al/cd:5"} {"record": "ocd-division/country:us/state:al/cd:6"} {"record": "ocd-division/country:us/state:al/cd:7"} {"record": "ocd-division/country:us/state:ar/cd:1"} {"record": "ocd-division/country:us/state:ar/cd:2"} {"record": "ocd-division/country:us/state:ar/cd:3"} {"record": "ocd-division/country:us/state:ar/cd:4"} {"record": "ocd-division/country:us/state:as"} {"record": "ocd-division/country:us/state:az/cd:1"} {"record": "ocd-division/country:us/state:az/cd:2"} {"record": "ocd-division/country:us/state:az/cd:3"} {"record": "ocd-division/country:us/state:az/cd:4"} {"record": "ocd-division/country:us/state:az/cd:5"} {"record": "ocd-division/country:us/state:az/cd:6"} {"record": "ocd-division/country:us/state:az/cd:7"} ``` JSON ファイルの「`identifier`」のように、深くネストされたオブジェクトに基づいてスキーマを作成するには、カスタム JSON 分類子を作成して JSON パスを `$.identifiers[*].identifier` と指定します。スキーマは前の例と似ていますが、JSON ファイル内の別のオブジェクトに基づいています。 スキーマは次のようになります。 ``` root |-- record: string ``` テーブルからのデータの最初の数行のリストには、スキーマが「`identifier`」オブジェクトのデータに基づくものであることが示されます。 ``` {"record": "Regional/North_America/United_States/Alaska/"} {"record": "/m/0hjy"} {"record": "US02"} {"record": "5879092"} {"record": "4001016-8"} {"record": "destination/alaska"} {"record": "1116270"} {"record": "139487266"} {"record": "n79018447"} {"record": "01490999-8dec-4129-8254-eef6e80fadc3"} {"record": "Alaska-state"} {"record": "place/Alaska"} {"record": "Q797"} {"record": "Regional/North_America/United_States/Alabama/"} {"record": "/m/0gyh"} {"record": "US01"} {"record": "4829764"} {"record": "4084839-5"} {"record": "161950"} {"record": "131885589"} ``` JSON ファイルの「`name`」配列の「`other_names`」フィールドのように、別の深くネストされたオブジェクトに基づいてテーブルを作成するには、カスタム JSON 分類子を作成して JSON パスを `$.other_names[*].name` と指定します。スキーマは前の例と似ていますが、JSON ファイル内の別のオブジェクトに基づいています。スキーマは次のようになります。 ``` root |-- record: string ``` テーブルからのデータの最初の数行のリストには、「`name`」配列内の「`other_names`」オブジェクトのデータに基づくものであることが示されます。 ``` {"record": "Alaska"} {"record": "Alaska"} {"record": "Аляска"} {"record": "Alaska"} {"record": "Alaska"} {"record": "Alaska"} {"record": "Alaska"} {"record": "Alaska"} {"record": "Alaska"} {"record": "ألاسكا"} {"record": "ܐܠܐܣܟܐ"} {"record": "الاسكا"} {"record": "Alaska"} {"record": "Alyaska"} {"record": "Alaska"} {"record": "Alaska"} {"record": "Штат Аляска"} {"record": "Аляска"} {"record": "Alaska"} {"record": "আলাস্কা"} ``` ## CSV カスタム分類子の書き込み カスタム CSV 分類子を使用すると、カスタム csv 分類子フィールドの各列のデータ型を指定できます。各列のデータ型をコンマで区切って指定できます。データ型を指定することで、クローラーが推測したデータ型を上書きし、データが適切に分類されるようにすることができます。 分類子で CSV を処理するための SerDe を設定でき、データカタログに適用されます。 カスタム分類子を作成すると、その分類子を別のクローラーで再利用することもできます。 + ヘッダーのみ (データなし) の csv ファイルの場合、十分な情報が提供されないため、これらのファイルは UNKNOWN に分類されます。[Column headings] (列見出し) オプションで CSV の[Has headings](見出しあり) を指定し、データ型を指定すると、これらのファイルを正しく分類できます。 カスタム CSV 分類子を使用して、さまざまな種類の CSV データのスキーマを推測できます。分類子に指定できるカスタム属性には、区切り記号、CSV SerDe オプション、ヘッダーに関するオプション、およびデータに対して特定の検証を実行するかどうかなどがあります。 ### AWS Glue のカスタム分類子の値 CSV 分類子を定義する場合、AWS Glue に以下の値を入力して分類子を作成します。この分類子の分類フィールドは `csv` に設定してあります。 **分類子名** 分類子の名前。 **CSV Serde** 分類子で CSV を処理するため、データカタログに適用される SerDe を設定します。オプションは、「Open CSV SerDe」、「Lazy Simple SerDe」、および「None」です。クローラーが検出を行う場合は、None 値を指定できます。 **列の区切り文字** 行内の各列エントリを区切るものを示すカスタム記号。ユニコード文字を入力します。区切り記号を入力できない場合は、コピーと貼り付けをすることができます。これは、システムでサポートされていない文字 (通常は □ と表示) も含め、印刷可能な文字にも有効です。 **引用記号** コンテンツを単一の列の値に結合するものを示すカスタム記号。列の区切り文字とは異なる必要があります。ユニコード文字を入力します。区切り記号を入力できない場合は、コピーと貼り付けをすることができます。これは、システムでサポートされていない文字 (通常は □ と表示) も含め、印刷可能な文字にも有効です。 **列見出し** CSV ファイルで列見出しを検出する方法の動作を示します。カスタム CSV ファイルに列見出しがある場合は、列見出しのカンマ区切りリストを入力します。 **処理オプション: 単一列のファイルを許可します** 1 つの列のみを含むファイルの処理を有効にします。 **処理オプション: 列値を識別する前に空白を削除します** 列の値の型を識別する前に値をトリミングするかどうかを指定します。 **カスタムデータ型 – オプション** カスタムデータ型をコンマで区切って入力します。CSV ファイル内のカスタムデータ型を指定します。カスタムデータ型は、サポートされているデータ型である必要があります。サポートされているデータ型は、「BINARY」、「BOOLEAN」、「DATE」、「DECIMAL」、「DOUBLE」、「FLOAT」、「INT」、「LONG」、「SHORT」、「STRING」、「TIMESTAMP」です。サポートされていないデータ型の場合、エラーが表示されます。 # AWS Glue コンソールを使用した分類子の作成 分類子は、データのスキーマを決定します。カスタムの分類子を記述し、AWS Glue から指定します。 ## 分類子の作成 AWS Glue コンソールに分類子を追加するには、[**Add classifier (分類子を追加)**] を選択します。分類子を定義する場合、以下の値を指定します。 + **分類子名** – 分類子の一意の名前を指定します。 + **分類子タイプ** – この分類子によって推測されたテーブルの分類タイプ。 + **最終更新** – 分類子が最後に更新された時刻。 **分類子名** 分類子の一意の名前を指定します。 **分類子タイプ** 作成する分類子のタイプを選択します。 選択した分類子のタイプに応じて、分類子の次のプロパティを設定します。 ------ #### [ Grok ] + **分類** 分類されたデータの形式またはタイプを記述、またはカスタムラベルを指定します。 + **Grok パターン** これを使用してデータを解析して構造化スキーマにします。grok パターンは、データストアの形式を記述する名前付きパターンで構成されています。この grok パターンは、AWS Glue によって提供された名前付きの組み込みパターンと、[**Custom patterns (カスタムパターン)**] フィールドに書き込み、含まれるカスタムパターンを使用して書き込みます。grok デバッガーの結果は AWS Glue の結果と正確には一致しませんが、grok デバッガーでサンプルデータを使用してパターンを試すことをお勧めします。ウェブ上で grok デバッガーを見つけることができます。AWS Glue によって提供される名前付き組み込みパターンは、一般にウェブ上で利用可能な grok パターンと互換性があります。 名前付きパターンを反復的に追加して grok パターンを作成し、デバッガーで結果を確認します。このアクティビティを使用すると、AWS Glue クローラが grok パターンを実行するときにデータを解析できるという確信が得られます。 + **カスタムパターン** grok 分類子の場合、これらは、記述した [**Grok pattern**] (Grok パターン) のオプションの構成要素です。組み込みのパターンでデータを解析できない場合は、カスタムパターンを記述する必要があります。これらのカスタムパターンはこのフィールドで定義され、[**Grok pattern**] (Grok パターン) フィールドで参照されます。各カスタムパターンは個別の行に定義されています。組込みパターンと同様に、[[regular expression (regex)](http://en.wikipedia.org/wiki/Regular_expression)] (正規表現) 構文を使用する名前付きパターン定義で構成されています。 たとえば、次の `MESSAGEPREFIX` という名前は、その後に正規表現の定義が続いてデータに適用され、パターンに従っているかどうかが判断されます。 ``` MESSAGEPREFIX .*-.*-.*-.*-.* ``` ------ #### [ XML ] + **行タグ** XML 分類子では、これは XML 文書のテーブル行を定義する XML タグの名前です。山括弧 `< >` を付けずに名前を入力します。名前は XML タグ規則に沿って命名する必要があります。 詳しくは、「[XML カスタム分類子の書き込み](custom-classifier.md#custom-classifier-xml) 」を参照してください。 ------ #### [ JSON ] + **JSON パス** JSON 分類子の場合、これは、作成するテーブルの行を定義するオブジェクト、配列、または値への JSON パスです。名前をドットで入力するか、AWS Glue でサポートされる演算子を使用して JSON 構文を括弧で囲んでください。 詳細については、「[JSON カスタム分類子の書き込み](custom-classifier.md#custom-classifier-json)」の演算子のリストを参照してください。 ------ #### [ CSV ] + **列の区切り文字** 行内の各列エントリの区切りを示す単一の文字または記号。リストから区切り文字または記号を選択するか、`Other` を選択して、カスタム区切り文字または記号を入力します。 + **引用記号** コンテンツを結合して単一の列の値にすることを示す単一の文字または記号。列の区切り文字とは異なる必要があります。リストから引用記号を選択するか、`Other` を選択して、カスタム引用文字を入力します。 + **列見出し** CSV ファイルで列見出しを検出する方法の動作を示します。`Has headings`、`No headings` または `Detect headings` を選択できます。カスタム CSV ファイルに列見出しがある場合は、列見出しのカンマ区切りリストを入力します。 + **単一列のファイルを許可** CSV とみなされるためには、データが 2 列以上かつ 2 行以上必要です。このオプションを使用すると、1 つの列のみを含むファイルが処理できます。 + **列の値を識別する前に空白を削除** このオプションによって、列の値のタイプを識別する前に値の空白を削除するかどうかを指定します。 + **カスタムデータ型** (オプション) – カスタムデータ型をカンマ区切りリストに入力します。サポートされているデータ型は、「BINARY」、「BOOLEAN」、「DATE」、「DECIMAL」、「DOUBLE」、「FLOAT」、「INT」、「LONG」、「SHORT」、「STRING」、「TIMESTAMP」です。 + **CSV Serde** (オプション) - 分類子で CSV を処理するための SerDe を設定でき、データカタログに適用されます。`Open CSV SerDe`、`Lazy Simple SerDe`、または `None` から選択します。クローラーが検出を行う場合は、`None` 値を指定できます。 ------ 詳細については、「[さまざまなデータ形式のカスタム分類子の記述](custom-classifier.md)」を参照してください。 ## 分類子の表示 作成したすべての分類子のリストを表示するには、[https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/) で AWS Glue コンソールを開き、[**Classifiers**] (分類子) タブを選択します。 リストには、各分類子に関する次のプロパティが表示されます。 + **分類子** – 分類子名。分類子を作成するときは、その名前を指定する必要があります。 + **分類** – この分類子によって推測されたテーブルの分類タイプ。 + **最終更新** – 分類子が最後に更新された時刻。 ## 分類子の管理 ** コンソールの [**ClassifiersAWS Glue] (分類子) リストから、分類子の追加、編集、削除ができます。分類子の詳細を表示するには、リスト内の分類子名を選択します。詳細には、分類子を作成したときに定義した情報が含まれます。 # クローラーの設定 クローラーはデータストアにアクセスし、メタデータを識別して、テーブル定義を AWS Glue Data Catalog に作成します。** コンソールの [**Crawlers (クローラー)AWS Glue] ペインには、作成したクローラーがすべて一覧表示されます。リストには、クローラーの最後の実行のステータスとメトリクスが表示されます。 このトピックでは、クローラーのパラメータの設定、クロールするデータソースの定義、セキュリティの設定、クロールされたデータの管理など、重要な側面について触れながら、クローラーを設定する工程を段階的に説明します。 **Topics** + [ステップ 1: クローラープロパティを設定する](define-crawler-set-crawler-properties.md) + [ステップ 2: データソースと分類子を選択する](define-crawler-choose-data-sources.md) + [ステップ 3: セキュリティ設定を構成する](define-crawler-configure-security-settings.md) + [ステップ 4: 出力とスケジュールを設定する](define-crawler-set-output-and-scheduling.md) + [ステップ 5: 確認して作成する](define-crawler-review.md) # ステップ 1: クローラープロパティを設定する **クローラーを設定するには** 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。ナビゲーションペインで [**Crawlers (クローラー)**] を選択します。 1. **[クローラーの作成]** を選択して、**[クローラーの追加]** ウィザードの手順に従います。ウィザードは、クローラーの作成に必要なステップをガイドします。スキーマを定義するためにカスタム分類子を追加する場合は、「[分類子の定義と管理](add-classifier.md)」を参照してください。 1. クローラーの名前と説明 (オプション) を入力します。必要に応じて、クローラーに [**タグキー**] とオプションの [**タグ値**] でタグを付加できます。作成後、タグキーは読み取り専用になります。リソースを整理、識別しやすいように、いくつかのリソースでタグを使用します。詳細については、「AWS Glue の AWS タグ」を参照してください。 **名前** 名前に使用できるのは、文字 (A～Z)、数字 (0～9)、ハイフン (-)、またはアンダースコア (\$1) で、長さは 255 文字までです。 **説明** 説明の長さは、最大 2048 文字です。 **[タグ]** タグを使用して、リソースの整理と識別を行います。詳細については次を参照してください: + [AWSAWS Glue のタグ](monitor-tags.md) # ステップ 2: データソースと分類子を選択する 次に、クローラーのデータソースと分類子を設定します。 サポートされるデータソースについては、「[クロールでサポートされているデータソース](crawler-data-stores.md)」を参照してください。 **データソースの設定** **[データは AWS Glue テーブルにマッピングされていますか]** で、適切なオプション (「未実施」または「はい」) を選択します。デフォルトでは、「未実施」が選択されています。 クローラーは、クロールのソースとして直接データストアにアクセスでき、また既存のデータカタログのテーブルをソースとして使用することもできます。クローラーが既存のカタログテーブルを使用する場合、それらのカタログのテーブルで指定されたデータストアをクロールします。 + [Not yet] (未実施): クローリングする 1 つまたは複数のデータソースを選択します。クローラーは、さまざまなタイプ (Amazon S3、JDBC など) の複数のデータストアをクロールできます。 一度に設定できるデータストアは 1 つだけです。接続情報とインクルードパスと除外パターンを指定すると、別のデータストアを追加することもできます。 + [Yes] (はい): AWS Glue データカタログから既存のテーブルを選択します。カタログテーブルは、クロールするデータストアを指定します。クローラーは 1 回の実行でのカタログテーブルのみをクロールできます。他のソースタイプを混在させることはできません。 ソースとしてカタログテーブルを指定する一般的な理由は、(データストアの構造をすでに知っていたため) テーブルを手動で作成した場合に、新しいパーティションの追加を含め、クローラーにテーブルを更新された状態に保持させるためです。他の理由の説明については、「[クローラーを使用して手動で作成されたデータカタログテーブルを更新する](tables-described.md#update-manual-tables)」を参照してください。 既存のテーブルをクローラーソースのタイプとして指定する場合は、次の条件が適用されます。 + データベース名はオプションです。 + Amazon S3、Amazon DynamoDB、または Delta Lake データストアを指定するカタログテーブルのみが使用できます。 + クローラーが実行されるとき、新しいカタログテーブルは作成されません。既存のテーブルは、新しいパーティションの追加を含め、必要に応じて更新されます。 + データストアで見つかる削除されたオブジェクトは無視されます。カタログテーブルが削除されません。代わりに、クローラーによりログメッセージが書き込まれます(`SchemaChangePolicy.DeleteBehavior=LOG`) + Amazon S3 パスごとに単一のスキーマを作成するクローラー設定オプションはデフォルトで有効になっており、無効にすることはできません。(`TableGroupingPolicy`=`CombineCompatibleSchemas`) 詳しくは、「[各 Amazon S3 インクルードパスの単一のスキーマを作成する](crawler-grouping-policy.md)」を参照してください。 + カタログテーブルをソースとして他のソースタイプ (例: Amazon S3 または Amazon DynamoDB) と混在させることはできません。 Delta テーブルを使用するには、まず Athena DDL または AWS Glue API を使用して Delta テーブルを作成します。 Athena を使用して場所を Amazon S3 フォルダに設定し、テーブルタイプを「DELTA」に設定します。 ``` CREATE EXTERNAL TABLE database_name.table_name LOCATION 's3://bucket/folder/' TBLPROPERTIES ('table_type' = 'DELTA') ``` AWS Glue API を使用してテーブルパラメータマップ内のテーブルタイプを指定します。テーブルパラメータには、次のキーおよび値のペアを含める必要があります。テーブルを作成する方法の詳細については、「[create\$1table の Boto3 ドキュメント](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/glue/client/create_table.html)」を参照してください。 ``` { "table_type":"delta" } ``` **データソース** クローラーでスキャンするデータソースのリストを選択または追加します。 (オプション) データソースとして JDBC を選択した場合、ドライバー情報が保存されている Connection アクセスを指定するときに、独自の JDBC ドライバーを使用できます。 **インクルードパス** クロールで何を含め、何を除外するかを評価する際、クローラーは必要なインクルードパスを評価することから始めます。Amazon S3、MongoDB、MongoDB Atlas、Amazon DocumentDB (MongoDB 互換)、リレーショナルデータストアの場合は、インクルードパスを指定する必要があります。 Amazon S3 データストアの場合 このアカウントのパスを指定するか、別のアカウントのパスを指定するかを選択し、Amazon S3 パスを参照して選択します。 Amazon S3 データストアの場合、インクルードパスの構文は `bucket-name/folder-name/file-name.ext` です。バケット内のすべてのオブジェクトをクロールするには、インクルードパスにバケット名のみ指定します。除外パターンは、インクルードパスを基準とする相対パスです。 Delta Lake データストアの場合 Delta テーブルへの Amazon S3 パスを s3://*bucket*/*prefix*/*object* として 1 つ以上指定します。 Iceberg または Hudi データストアの場合 Iceberg または Hudi テーブルのメタデータを持つフォルダを含む Amazon S3 パスを s3://*bucket*/*prefix* として 1 つ以上指定します。 Iceberg および Hudi のデータストアの場合、Iceberg/Hudi フォルダはルートフォルダの子フォルダ内に存在する場合があります。クローラーは、Hudi フォルダのパス以下にあるすべてのフォルダをスキャンします。 JDBC データストアの場合 データベース製品に応じて、**/**/** または **/*
* を入力します。Oracle Database と MySQL は、パス内のスキーマをサポートしません。** または *
* は、パーセント (%) 文字に置き換えることができます。たとえば、システム識別子 (SID) が `orcl` の Oracle データベースの場合、`orcl/%` を入力して、接続で指定されたユーザーがアクセスできるすべてのテーブルをインポートします。 このフィールドでは、大文字と小文字が区別されます。 独自の JDBC ドライバーバージョンを導入する場合、AWS Glue クローラーは AWS Glue ジョブと Amazon S3 バケットのリソースを使用して、用意したドライバーが自分の環境で実行されるようにします。リソースの追加使用量はアカウントに反映されます。ドライバーは、「[AWS Glue 接続の追加](https://docs.aws.amazon.com/glue/latest/dg/console-connections.html)」に記載されているプロパティに限定されます。 MongoDB、MongoDB Atlas、Amazon DocumentDB データストアの場合 MongoDB、MongoDB Atlas、Amazon DocumentDB (MongoDB 互換) の場合、構文は `database/collection` です。 JDBC データストアの場合、構文は `database-name/schema-name/table-name` または `database-name/table-name` です。構文は、データベースエンジンでデータベース内のスキーマがサポートされているかどうかに依存します。たとえば、MySQL や Oracle などのデータベースエンジンの場合は、インクルードパスに `schema-name` を指定しません。インクルードパスでスキーマやテーブルの代わりにパーセント記号 (`%`) を使用することで、データベース内のすべてのスキーマやテーブルを表すことができます。インクルードパスでデータベースの代わりにパーセント記号 (`%`) を使用することはできません。 **最大トラバーサル深度 (Iceberg または Hudi データストアのみ)** クローラーが Amazon S3 パス内の Iceberg または Hudi メタデータフォルダを検出するために通過できる Amazon S3 パスの最大深度を定義します。このパラメータの目的は、クローラーの実行時間を制限することです。デフォルト値は 10 で、最大値は 20 です。 **除外パターン** この機能を利用すると、特定のファイルまたはテーブルをクロールから除外できます。エクスクルードパスは、インクルードパスを基準とする相対パスです。たとえば、JDBC データストア内のテーブルを除外するには、エクスクルードパスにテーブル名を入力します。 クローラーでは、JDBC データストアに接続するために、JDBC URI 接続文字列を含む AWS Glue 接続を使用します。クローラーは、データベースエンジン内のオブジェクトにのみアクセスできます。そのために、AWS Glue 接続で JDBC ユーザー名とパスワードを使用します。*クローラーは、JDBC 接続を介してアクセスできるテーブルのみ作成できます。*クローラーは、JDBC URI を使用してデータベースエンジンにアクセスした後で、インクルードパスを使用してデータカタログで作成するデータベースエンジン内のテーブルを決定します。例えば、MySQL の場合、`MyDatabase/%` というインクルードパスを指定すると、`MyDatabase` 内のすべてのテーブルがデータカタログで作成されます。Amazon Redshift にアクセスする場合、`MyDatabase/%` というインクルードパスを指定すると、データベース `MyDatabase` の各スキーマ内のすべてのテーブルがデータカタログで作成されます。`MyDatabase/MySchema/%` のインクルードパスを指定すると、データベース `MyDatabase` のすべてのテーブルとスキーマ `MySchema` が作成されます。 インクルードパスの指定後に、1 つ以上の Unix 形式の `glob` 除外パターンを指定することで、インクルードパスに含まれる予定であったオブジェクトをクロールから除外できます。これらのパターンはインクルードパスに適用されて、どのオブジェクトを除外するか決定します。また、これらのパターンはクローラーによって作成されるテーブルのプロパティとして保存されます。AWS GluePySpark 拡張機能 (`create_dynamic_frame.from_catalog` など) は、テーブルプロパティを読み取り、除外パターンによって定義されたオブジェクトを除外します。 AWS Glue は、除外パターンで次の `glob` パターンをサポートしています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/define-crawler-choose-data-sources.html) AWS Glue は、`glob` 除外パターンを次のように解釈します。 + スラッシュ (`/`) 文字は、Amazon S3 キーをフォルダ階層に区切る区切り記号です。 + アスタリスク (`*`) 記号は、フォルダの境界を超えない、0 文字以上の名前の要素と一致します。 + 二重アスタリスク (`**`) は、フォルダやスキーマの境界を越える 0 個以上の文字に相当します。 + 疑問符 (`?`) 記号は、名前の要素のちょうど 1 文字に相当します。 + バックスラッシュ (`\`) 文字は、本来ならば特殊文字として解釈される文字をエスケープ処理するために使用されます。`\\` 式はバックスラッシュ 1 つに相当し、`\{` は左括弧に相当します。 + 角括弧 (`[ ]`) は、一連の文字の中から、名前の要素の 1 文字に相当する角括弧式を作成します。たとえば、`[abc]` は `a`、`b`、または `c` に一致します。ハイフン (`-`) は、範囲を指定するために使用されます。つまり、`[a-z]` は `a` から `z` (この値を含みます) までに相当する範囲を指定します。これらのフォームは組み合わせることができます。そのため、[`abce-g`] は `a`、`b`、`c`、`e`、`f`、または `g` に一致します。角括弧 (`[`) の後の文字が感嘆符 (`!`) の場合、角括弧式は否定の意味になります。たとえば、`[!a-c]` は `a`、`b`、または `c` 以外のすべての文字に一致します。 角括弧式内では、`*`、`?`、および `\` 文字は、文字通りの意味です。ハイフン (`-`) 文字は、角括弧内で最初の文字だった場合、または式を否定する `!` の次の文字だった場合は、文字通りの意味です。 + 中括弧 (`{ }`) は、グループ内のサブパターンが一致する場合にグループが一致するサブパターンのグループを囲みます。カンマ (`,`) 文字は、サブパターンを分割するために使用されます。グループはネストできません。 + ファイル名の先頭のピリオドまたはドット文字は、マッチ操作では通常の文字として扱われます。たとえば、`*` 除外パターンは、ファイル名 `.hidden` に一致します。 **Example Amazon S3 除外パターンの例** 各除外パターンは、インクルードパスに対して評価されます。例えば、次の Amazon S3 ディレクトリ構造があるとします。 ``` /mybucket/myfolder/ departments/ finance.json market-us.json market-emea.json market-ap.json employees/ hr.json john.csv jane.csv juan.txt ``` インクルードパスが `s3://mybucket/myfolder/` の場合、以下は除外パターンのサンプル結果の一部です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/define-crawler-choose-data-sources.html) **Example Amazon S3 パーティションのサブセットの除外の例** データが日別に分割されていて、1 年の日別に異なる Amazon S3 パーティションに入っているとします。2015 年 1 月には、31 のパーティションがあります。ここで、1 月の第 1 週のみのデータをクロールするには、1 日〜7 日を除くすべてのパーティションを除外する必要があります。 ``` 2015/01/{[!0],0[8-9]}**, 2015/0[2-9]/**, 2015/1[0-2]/** ``` この glob パターンの各パートを見てみます。最初のパートは ` 2015/01/{[!0],0[8-9]}**` で、"0" で始まらないすべての日付、および 2015 年 01 月の 08 日目および 09 日目を除外しています。"\$1\$1" を日数パターンのサフィックスとして使用すると、下位レベルフォルダへのフォルダ境界を越えることに注意してください。"\$1" を使用すると、下位レベルフォルダは除外されます。 2 番目のパートは ` 2015/0[2-9]/**` で、2015 年 02 から 09 月までの日を除外します。 3 番目のパートは `2015/1[0-2]/**` で、2015 年 10、11、12 月の日を除外します。 **Example JDBC の除外パターン** 次のスキーマ構造を使用して JDBC データベースをクロールしているとします。 ``` MyDatabase/MySchema/ HR_us HR_fr Employees_Table Finance Market_US_Table Market_EMEA_Table Market_AP_Table ``` インクルードパスが `MyDatabase/MySchema/%` の場合、以下は除外パターンのサンプル結果の一部です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/define-crawler-choose-data-sources.html) **追加のクローラーソースパラメータ** 各ソースのタイプには、異なる追加パラメータのセットが必要です。 **接続** AWS Glue 接続を選択または追加します。接続の詳細については、「[データへの接続](glue-connections.md)」を参照してください **追加メタデータ - オプション (JDBC データストア用)** クローラーがクローリングするための追加のメタデータプロパティを選択します。 + [Comments] (コメント): 関連するテーブルレベルと列レベルのコメントをクローリングします。 + [Raw types] (未加工型): 表の列の未加工のデータ型を追加のメタデータに保持します。デフォルトの動作として、クローラーは未処理のデータ型を Hive 互換の型に変換します。 **JDBC ドライバークラス名 - オプション (JDBC データストア用)** クローラーがデータソースに接続するためのカスタム JDBC ドライバークラス名を入力します。 + Postgres: org.postgresql.Driver + MySQL: com.mysql.jdbc.Driver、com.mysql.cj.jdbc.Driver + Redshift: com.amazon.redshift.jdbc.Driver、com.amazon.redshift.jdbc42.Driver + Oracle: oracle.jdbc.driver.OracleDriver + SQL Server: com.microsoft.sqlserver.jdbc.SQLServerDriver **JDBC ドライバー S3 パス - オプション (JDBC データストア用)** `.jar` ファイルへの既存の Amazon S3 パスを選択します。クローラーがデータソースに接続するためのカスタム JDBC ドライバーを使用するときに、この場所に `.jar` ファイルが保存されます。 **データサンプリングを有効にする (Amazon DynamoDB、MongoDB、MongoDB Atlas、Amazon DocumentDB データストアのみ)** データサンプルのみをクロールするかどうかを選択します。選択しない場合は、テーブル全体がクロールされます。テーブルが高スループットテーブルではない場合、すべてのレコードのスキャンには時間がかかることがあります。 **クエリ用のテーブルを作成する (Delta Lake データストア用のみ)** Delta Lake テーブルの作成方法を次の中から選択します。 + [Create Native tables] (ネイティブテーブルの作成): Delta トランザクションログの直接クエリをサポートするクエリエンジンとの統合を可能にします。 + [Create Symlink tables] (Symlink テーブルの作成): 指定された設定パラメータに基づいて、マニフェストファイルを分割キーで分割して Symlink マニフェストを作成します。 **スキャンレート - オプション (DynamoDB データストア用のみ)** クローラーで使用する DynamoDB テーブル読み取りキャパシティーユニットの割合を指定します。読み取りキャパシティーユニットは、DynamoDB で定義されている用語で、テーブルに対して実行できる読み取り回数/秒のレート制限として機能する数値です。0.1～1.5 の値を入力します。指定しない場合、プロビジョニングされたテーブルの場合は 0.5、オンデマンドテーブルの場合は最大の設定済みキャパシティーの 1/4 にデフォルト設定されます。AWS Glue クローラーは、プロビジョニング容量モードでのみ使用できることにご注意ください。 DynamoDB データストアの場合、テーブルの読み取りと書き込みを処理するプロビジョニング容量モードを設定します。AWS Glue クローラーは、オンデマンド容量モードでは使用しないでください。 **ネットワーク接続 – オプション (Amazon S3、Delta、Iceberg、Hudi、Catalog のターゲットデータストア用)** 必要に応じて、この Amazon S3 ターゲットで使用するネットワーク接続を含めます。各クローラーは 1 つのネットワーク接続に制限されているため、他の Amazon S3 ターゲットも同じ接続を使用します (空欄の場合は接続なし)。 接続の詳細については、「[データへの接続](glue-connections.md)」を参照してください **ファイルのサブセットのみのサンプリングとサンプルサイズ (Amazon S3 データストア用のみ)** データセット内のサンプルファイルをクロールするときにクロールされる各リーフフォルダ内のファイル数を指定します。この機能をオンにすると、このデータセット内のすべてのファイルをクロールする代わりに、クローラーはクロールする各リーフフォルダ内の一部のファイルをランダムに選択します。 サンプリングするクローラーは、データ形式について事前に知識があり、フォルダ内のスキーマが変更されないことを知っているお客様に最適です。この機能をオンにすると、クローラーの実行時間が大幅に短縮されます。 有効な値は、1 から 249 までの整数です。指定しない場合、すべてのファイルがクロールされます。 **以降のクローラー実行** このフィールドは、すべての Amazon S3 データソースに影響するグローバルフィールドです。 + [Crawl all sub-folders] (すべてのサブフォルダをクローリング): 以降クローリングするたびに、すべてのフォルダを再度クローリングします。 + [Crawl new sub-folders only] (新しいサブフォルダのみをクローリング): 最近のクローリング以降に追加された Amazon S3 フォルダのみをクローリングします スキーマに互換性がある場合、新しいパーティションが既存のテーブルに追加されます。詳細については、「[新しいパーティションを追加するための増分クロールのスケジューリング](incremental-crawls.md)」を参照してください。 + [Crawl based on events] (イベントに基づいてクローリング): Amazon S3 イベントを利用して、クローリングするフォルダを制御します。詳細については、「[Amazon S3 イベント通知を使用した加速クロール](crawler-s3-event-notifications.md)」を参照してください。 **カスタム分類子 - オプション** クローラーを定義する前にカスタム分類子を定義します。分類子は、指定されたファイルがクローラーで処理可能な形式であるかどうかをチェックします。処理可能な場合、分類子は、そのデータ形式と一致する `StructType` オブジェクトの形式でスキーマを作成します。 詳細については、「[分類子の定義と管理](add-classifier.md)」を参照してください。 # ステップ 3: セキュリティ設定を構成する **IAM ロール** クローラーはこのロールを取得します。これは、AWS 管理ポリシー `AWSGlueServiceRole` と同様のアクセス許可を持っている必要があります。Amazon S3 および DynamoDB ソースの場合、データストアへのアクセス許可も必要です。クローラーが AWS Key Management Service (AWS KMS) で暗号化された Amazon S3 データを読み取る場合は、ロールには AWS KMS キーでの復号化のアクセス許可が必要です。 Amazon S3 データストアの場合、ロールにアタッチされた追加のアクセス許可は次のようになります。 **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucket/object*" ] } ] } ``` Amazon DynamoDB データストアの場合、ロールにアタッチされた追加のアクセス許可は次のようになります。 **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:DescribeTable", "dynamodb:Scan" ], "Resource": [ "arn:aws:dynamodb:*:111122223333:table/table-name*" ] } ] } ``` 自身の JDBC ドライバーを追加するには、アクセス許可を新たに追加する必要があります。 + ジョブアクション `CreateJob`、`DeleteJob`、`GetJob`、`GetJobRun`、`StartJobRun` にアクセス権限を付与します。 + Amazon S3 アクション `s3:DeleteObjects`、`s3:GetObject`、`s3:ListBucket`、`s3:PutObject` にアクセス権限を付与します。 **注記** Amazon S3 バケットポリシーが無効になっている場合、`s3:ListBucket` は必要ありません。 + サービスプリンシパルに Amazon S3 ポリシーのバケット/フォルダへのアクセス権限を付与します。 Amazon S3 ポリシーの例: **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/driver-parent-folder/driver.jar", "arn:aws:s3:::amzn-s3-demo-bucket" ] } ] } ``` AWS Glue は以下のフォルダ (`_crawler` と `_glue_job_crawler`) を Amazon S3 バケットに JDBC ドライバーと同じレベルで作成します。例えば、ドライバーパスが `` の場合、以下のフォルダがまだ存在しない場合は作成されます。 + + 必要に応じて、クローラーにセキュリティ設定を追加して、保管時の暗号化オプションを指定することができます。 詳細については、「[ステップ 2: AWS Glue 用の IAM ロールを作成する](create-an-iam-role.md)」および「[AWS Glue のアイデンティティとアクセスの管理](security-iam.md)」を参照してください。 **Lake Formation 設定 - オプション** クローラーが Lake Formation の認証情報をデータソースのクローリングに使用できるようにします。 **[Use Lake Formation credentials for crawling S3 data source]** (S3 データソースのクローリングに Lake Formation 認証情報を使用する) をオンにすると、クローラーは Lake Formation 認証情報を使用してデータソースをクローリングできるようになります。データソースが別のアカウントに属する場合は、登録されているアカウント ID を指定する必要があります。そうしないと、クローラーはアカウントに関連付けられているデータソースのみをクローリングします。Amazon S3 とデータカタログのデータソースにのみ適用されます。 **セキュリティ設定 - オプション** 設定にはセキュリティ設定が含まれます。詳細については次を参照してください: + [AWS Glue​ によって書き込まれたデータの暗号化](encryption-security-configuration.md) クローラーにセキュリティ設定を設定すると、変更できますが、削除することはできません。クローラーのセキュリティレベルを下げるには、設定内でセキュリティ機能を明示的に `DISABLED` に設定するか、新しいクローラーを作成します。 # ステップ 4: 出力とスケジュールを設定する **出力設定** オプションには、検出されたスキーマの変更、データストア内の削除されたオブジェクトをクローラーが処理する方法があります。詳細については、[クローラーの動作のカスタマイズ](crawler-configuration.md)を参照してください。 **クローラースケジュール** AWS Glue では、オンデマンドでクローラーを実行することも、クローラーとジョブの時間ベースのスケジュールを定義することもできます。これらのスケジュールの定義は、Unix と同様の cron 構文を使用します。詳細については、「[クローラのスケジュール](schedule-crawler.md)」を参照してください。 # ステップ 5: 確認して作成する 設定したクローラー設定を確認して、クローラーを作成します。 # クローラのスケジュール AWS Glue クローラは、オンデマンドで、または定期的なスケジュールで実行できます。スケジュールに基づいてクローラーを設定する場合は、クローラーの実行頻度、実行する曜日、実行時間などの特定の制約を指定できます。これらのカスタムスケジュールは *cron* 形式で作成できます。詳細については、Wikipedia の「[cron](http://en.wikipedia.org/wiki/Cron)」を参照してください。 クローラスケジュールを設定するときは、cron の機能と制限を考慮する必要があります。たとえば、毎月 31 日にクローラを実行することを選択した場合、いくつかの月には 31 日間はないことに注意してください。 **Topics** + [クローラースケジュールを作成する](create-crawler-schedule.md) + [既存のクローラーのスケジュールを作成する](Update-crawler-schedule.md) # クローラースケジュールを作成する AWS Glue コンソールまたは AWS CLI を使ってクローラーのスケジュールを作成できます。 ------ #### [ AWS マネジメントコンソール ] 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインで [**Crawlers (クローラー)**] を選択します。 1. セクション「[クローラーの設定](define-crawler.md)」のステップ 1～3 に従います。 1. [ステップ 4: 出力とスケジュールを設定する](define-crawler-set-output-and-scheduling.md) で、**クローラースケジュール**を選択し、実行頻度を設定します。クローラーの実行は毎時、毎日、毎週、毎月から選ぶことができますが、cron 式を使用してカスタムスケジュールを定義することもできます。 cron 式はスケジュールパターンを表す文字列で、スペースで区切られた 6 つのフィールド (\$1 \$1 \$1 \$1 \$1 ) で構成されます。 例えば、毎日午前 0 時にタスクを実行する場合、cron 式は 0 0 \$1 \$1 ? \$1 になります。 詳細については、「[Cron 式](https://docs.aws.amazon.com/glue/latest/dg/monitor-data-warehouse-schedule.html#CronExpressions)」を参照してください。 1. 設定したクローラー設定を確認し、スケジュールに従って実行されるクローラーを作成します。 ------ #### [ AWS CLI ] ``` aws glue create-crawler --name myCrawler \ --role AWSGlueServiceRole-myCrawler \ --targets '{"S3Targets":[{Path="s3://amzn-s3-demo-bucket/"}]}' \ --schedule cron(15 12 * * ? *) ``` ------ cron を使用してジョブおよびクローラをスケジュールする方法の詳細については、「[ジョブとクローラの時間ベースのスケジュール](monitor-data-warehouse-schedule.md)」を参照してください。 # 既存のクローラーのスケジュールを作成する 既存のクローラーの定期的なスケジュールを設定するには、次の手順に従います。 ------ #### [ AWS マネジメントコンソール ] 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインで [**Crawlers (クローラー)**] を選択します。 1. 使用可能なリストから、スケジュールするクローラーを選択します。 1. **[アクション]** メニューで、**[編集]** を選択します。 1. **[ステップ 4: 出力とスケジュールを設定する]** まで下にスクロールし、**[編集]** を選択します。 1. **[クローラースケジュール]** でクローラースケジュールを更新します。 1. **[更新]** を選択します。 ------ #### [ AWS CLI ] 既存のクローラー設定を更新するには、次の CLI コマンドを使用します。 ``` aws glue update-crawler-schedule --crawler-name myCrawler --schedule cron(15 12 * * ? *) ``` ------ # クローラーの結果と詳細の表示 クローラーが正常に実行されると、データカタログにテーブル定義が作成されます。クローラーの実行が完了したら、ナビゲーションペインで [**Tables**] (テーブル) をクリックして、指定したデータベースにクローラーにより作成されたテーブルを表示します。 クローラー自体に関連する情報は、次のように表示されます。 + AWS Glue コンソールの [**Crawlers**] (クローラー) ページに、クローラーの次のプロパティが表示されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/console-crawlers-details.html) + クローラーの履歴を表示するには、ナビゲーションペインで **[Crawlers]** (クローラー) を選択して、作成したクローラーを表示します。使用可能なクローラーのリストからクローラーを選択します。クローラーのプロパティとクローラーの履歴は **[Crawler runs]** (クローラーの実行) タブに表示されます。 [Crawler runs] (クローラーの実行) タブには、クローラーの各実行履歴に対して、**[Start time (UTC)]** (開始時刻 (UTC))、**[End time (UTC)]** (終了時刻 (UTC))、**[Duration]** (所要時間)、**[Status]** (ステータス)、**[DPU hours]** (DPU 時間)、**[Table changes]** (表の変更) などが表示されます。 [クローラーの実行] タブは、クローラー履歴機能の起動日以降に発生したクロールのみを表示し、最大 12 か月分のクロールのみを保持します。古いクロールは返されません。 + 追加情報を表示するには、クローラー詳細ページにあるタブを選択します。各タブには、クローラーに関連する情報が表示されます。 + **[Schedule]** (スケジュール): クローラー用に作成されたすべてのスケジュールがここに表示されます。 + **[Data sources]** (データソース): クローラーによってスキャンされたすべてのデータソースがここに表示されます。 + **[Classifiers]** (分類子): クローラーに割り当てられたすべての分類子がここに表示されます。 + **[Tags]** (タグ): タグが作成され、AWS リソースに割り当てられていれば、ここに表示されます。 # クローラーによって設定されたデータカタログテーブルのパラメータ これらのテーブルプロパティは、AWS Glue クローラーによって設定されます。ユーザーが `classification` および `compressionType` プロパティを使用することを想定しています。テーブルサイズの推定値など、その他のプロパティは内部計算に使用されるものであり、その精度やお客様のユースケースへの適用性は保証されません。これらのパラメータを変更すると、クローラーの動作が変わる可能性があるため、このワークフローはサポートされません。 | プロパティキー | プロパティ値 | | --- | --- | | UPDATED\$1BY\$1CRAWLER | 更新を実行するクローラーの名前。 | | connectionName | データストアに接続するために使用されるクローラーのデータカタログ内にある接続名。 | | recordCount | ファイルサイズとヘッダーに基づいた、テーブル内の推定レコード数。 | | skip.header.line.count | スキップヘッダーにスキップされた行数。CSV に分類されたテーブルに設定します。 | | CrawlerSchemaSerializerVersion | 内部使用目的 | | classification | クローラーによって推測されたデータの形式。AWS Glue クローラーでサポートされるデータ形式の詳細については、「[組み込み分類子](add-classifier.md#classifier-built-in)」を参照してください。 | | CrawlerSchemaDeserializerVersion | 内部使用目的 | | sizeKey | クロールされたテーブル内のファイルの合計サイズ。 | | averageRecordSize | テーブル内の行の平均サイズ (バイト単位)。 | | compressionType | テーブル内のデータで使用される圧縮タイプ。AWS Glue クローラーでサポートされる圧縮タイプの詳細については、「[組み込み分類子](add-classifier.md#classifier-built-in)」を参照してください。 | | typeOfData | `file`、`table`、または `view`。 | | objectCount | テーブルの Amazon S3 パスの下にあるオブジェクトの数。 | これらの追加のテーブルプロパティは、Snowflake データストアの AWS Glue クローラーによって設定されます。 | プロパティキー | プロパティ値 | | --- | --- | | aws:RawTableLastAltered | Snowflake テーブルの最後に変更されたタイムスタンプを記録します。 | | ViewOriginalText | SQL ステートメントを表示します。 | | ViewExpandedText | Base64 形式でエンコードされた SQL ステートメントを表示します。 | | ExternalTable:S3Location | Snowflake 外部テーブルの Amazon S3 の場所。 | | ExternalTable:FileFormat | Snowflake 外部テーブルの Amazon S3 ファイル形式。 | これらの追加のテーブルプロパティは、Amazon Redshift、Microsoft SQL Server、MySQL、PostgreSQL、Oracle などの JDBC タイプのデータストアの AWS Glue クローラーによって設定されます。 | プロパティキー | プロパティ値 | | --- | --- | | aws:RawType | クローラーがデータカタログにデータを保存すると、データ型が Hive 互換型に変換されるため、ネイティブデータ型の情報が失われることがよくあります。クローラーは、ネイティブレベルのデータ型を提供する `aws:RawType` パラメータを出力します。 | | aws:RawColumnComment | コメントがデータベース内の列に関連付けられている場合、クローラーはカタログテーブル内の対応するコメントを出力します。コメント文字列は 255 バイトに切り捨てられます。 Microsoft SQL Server ではコメントはサポートされていません。 | | aws:RawTableComment | コメントがデータベース内のテーブルに関連付けられている場合、クローラーはカタログテーブル内の対応するコメントを出力します。コメント文字列は 255 バイトに切り捨てられます。 Microsoft SQL Server ではコメントはサポートされていません。 | # クローラーの動作のカスタマイズ AWS Glue クローラー を設定する場合、クローラーの動作を定義するためのオプションをいくつか使用できます。 + **増分クロール** – テーブルスキーマに新しいパーティションのみを追加する増分クロールを実行するようにクローラーを設定できます。 + **パーティションインデックス** – クローラーは、特定のパーティションを効率的に検索するために、デフォルトで Amazon S3 および Delta Lake ターゲットのパーティションインデックスを作成します。 + **Amazon S3 イベントを使用してクロール時間を短縮する** – Amazon S3 または Data Catalog ターゲット全体を一覧表示するのではなく、Amazon S3 イベントを使用してイベントをトリガーしたサブフォルダからのすべてのファイルを一覧表示して 2 つのクロール間の変更を識別するようにクローラーを設定できます。 + **スキーマの変更の処理** – クローラーが既存のスキーマに対してスキーマの変更を行わないようにすることができます。AWS マネジメントコンソール または AWS Glue API を使用して、特定のタイプの変更をクローラーで処理する方法を設定できます。 + **複数の Amazon S3 パスの単一のスキーマ** – データに互換性がある場合は、各 S3 パスの単一のスキーマを作成するようにクローラーを設定できます。 + **テーブルの場所とパーティションレベル** – テーブルレベルのクローラーオプションを使用すると、クローラーにテーブルの配置場所やパーティションの作成方法を柔軟に指定できます。 + **テーブルしきい値** – テーブルしきい値を指定することで、クローラーが作成できるテーブルの最大数を指定できます。 + **AWS Lake Formation 認証情報** – Lake Formation 認証情報を使用するようにクローラーを設定すると、同じ AWS アカウント または別の AWS アカウント 内の Amazon S3 データストアまたは Data Catalog テーブルにアクセスできます。これらのテーブルは、Amazon S3 の場所を基盤としています。 AWS Glue コンソールを使用してクローラーを追加する方法の詳細については、「[クローラーの設定](define-crawler.md)」を参照してください。 **Topics** + [新しいパーティションを追加するための増分クロールのスケジューリング](incremental-crawls.md) + [パーティションインデックスの生成](crawler-configure-partition-indexes.md) + [クローラーによる既存のスキーマの変更を防止する](crawler-schema-changes-prevent.md) + [各 Amazon S3 インクルードパスの単一のスキーマを作成する](crawler-grouping-policy.md) + [テーブルの場所とパーティションレベルの指定](crawler-table-level.md) + [クローラーが作成できるテーブルの最大数を指定する](crawler-maximum-number-of-tables.md) + [Lake Formation 認証情報を使用するようにクローラーを設定する](crawler-lf-integ.md) + [Amazon S3 イベント通知を使用した加速クロール](crawler-s3-event-notifications.md) # 新しいパーティションを追加するための増分クロールのスケジューリング テーブルスキーマに新しいパーティションのみを追加する増分クロールを実行するように AWS Glue クローラー を設定できます。クローラーは、初回実行時にデータソース全体を処理するフルクロールを実行し、完全なスキーマと既存のすべてのパーティションを AWS Glue Data Catalog に記録します。 最初のフルクロールの後のクロールは増分となり、クローラーは前回のクロール以降に導入された新しいパーティションのみを識別して追加します。このアプローチにより、クローラーは実行ごとにデータソース全体を処理する必要がなくなり、代わりに新しいパーティションにだけ焦点を当てるため、クロール時間が短縮されます。 **注記** 増分クロールは、既存のパーティションの変更や削除を検出しません。この設定は、安定したスキーマを持つデータソースに最適です。大規模なスキーマ変更が発生した場合は、新しいスキーマを正確に取得するために、一時的にクローラーがフルクロールを実行するように設定し、その後増分クローリングモードに戻すことをお勧めします。 次の図は、増分クロール設定を有効にすると、クローラーが新しく追加されたフォルダ、month=March のみを検出してカタログに追加する状況を示しています。 ![\[次の図は、3 月のファイルが追加されていることを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/crawlers-s3-folders-new.png) クローラーを更新して増分クロールを実行するには、次の手順に従います。 ------ #### [ AWS マネジメントコンソール ] 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. **[Data Catalog]** で **[クローラー]** を選択します。 1. 増分的にクロールするように設定するクローラーを選択します。 1. **[編集]** を選択します。 1. **[ステップ 2] を選択します。データソースと分類子を選択します**。 1. 増分的にクロールするデータソースを選択します。 1. **[編集]** を選択します。 1. **[それ以降のクローラー実行]** で、**[新しいサブフォルダのみをクローリング]** を選択します。 1. **[更新]** を選択します。 クローラーのスケジュールを作成するには、「[クローラのスケジュール](schedule-crawler.md)」を参照してください。 ------ #### [ AWS CLI ] ``` aws glue update-crawler \ --name myCrawler \ --recrawl-policy RecrawlBehavior=CRAWL_NEW_FOLDERS_ONLY \ --schema-change-policy UpdateBehavior=LOG,DeleteBehavior=LOG ``` ------ **注意と制限** このオプションをオンにすると、クローラーの編集時に Amazon S3 ターゲットデータストアを変更できなくなります。このオプションは、ある特定のクローラー設定に影響します。オンにすると、クローラーの更新動作と削除動作が `LOG` になります。これにより、以下のように処理されます。 + スキーマに互換性がないオブジェクトを検出した場合、クローラーはデータカタログにオブジェクトを追加せず、この詳細を CloudWatch Logs のログとして追加します。 + データカタログで削除されたオブジェクトは更新されません。 # パーティションインデックスの生成 Data Catalog は、特定のパーティションを効率的に検索するためのパーティションインデックスの作成をサポートしています。詳細については、「[パーティションインデックスの作成](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html)」を参照してください。AWS Glue クローラーは、デフォルトで Amazon S3 および Delta Lake ターゲットのパーティションインデックスを作成します。 ------ #### [ AWS マネジメントコンソール ] 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. **[Data Catalog]** で **[クローラー]** を選択します。 1. クローラーを定義すると、**[出力とスケジュールを設定する]** ページの **[詳細オプション]** で、**[パーティションインデックスを自動的に作成]** オプションがデフォルトで有効になります。 このオプションを無効にするには、コンソールの **[パーティションインデックスを自動的に作成]** チェックボックスの選択を解除できます。 1. クローラー設定が完了したら、**[クローラーの作成]** を選択します。 ------ #### [ AWS CLI ] AWS CLI を使用し、`configuration` パラメータで `CreatePartitionIndex ` を設定してこのオプションを無効にすることもできます。デフォルト値は True です。 ``` aws glue update-crawler \ --name myCrawler \ --configuration '{"Version": 1.0, "CreatePartitionIndex": false }' ``` ------ ## パーティションインデックスの使用に関する注意事項 + クローラーによって作成されたテーブルには、デフォルトでは `partition_filtering.enabled` 変数がありません。詳細については、「[AWS Glue パーティションインデックスとフィルタリング](https://docs.aws.amazon.com/athena/latest/ug/glue-best-practices.html#glue-best-practices-partition-index)」を参照してください。 + 暗号化されたパーティションのパーティションインデックスの作成はサポートされていません。 # クローラーによる既存のスキーマの変更を防止する 実行時に、AWS Glue クローラー が Data Catalog に対してスキーマの変更を行わないようにすることができます。デフォルトでは、クローラーは Data Catalog 内のスキーマを更新して、クロールするデータソースと一致させます。ただし、特にデータを変換またはクリーンアップし、元のスキーマに変更を上書きしない場合は、クローラーが既存のスキーマを変更できないようにする必要があります。 テーブル定義の既存のスキーマを上書きしないようにクローラーを設定するには、次の手順に従います。 ------ #### [ AWS マネジメントコンソール ] 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. **[Data Catalog]** で **[クローラー]** を選択します。 1. リストからクローラーを選択したら、**[編集]** を選択します。 1. **[ステップ 4: 出力とスケジュールを設定する]** を選択します。 1. **[詳細オプション]** で、**[新しい列のみを追加]** または **[変更を無視し、Data Catalog のテーブルを更新しない]** を選択します。 1. **すべての新規パーティションと既存パーティションをテーブルのメタデータで更新**するように設定オプションを設定できます。この設定により、パーティションスキーマがテーブルから継承されます。 1. **[更新]** を選択します。 ------ #### [ AWS CLI ] 次の例は、既存のスキーマを変更せず、新しい列のみを追加するようにクローラーを設定する方法を示しています。 ``` aws glue update-crawler \ --name myCrawler \ --configuration '{"Version": 1.0, "CrawlerOutput": {"Tables": {"AddOrUpdateBehavior": "MergeNewColumns"}}}' ``` 次の例は、既存のスキーマを変更せず、新しい列を追加しないようにクローラーを設定する方法を示しています。 ``` aws glue update-crawler \ --name myCrawler \ --schema-change-policy UpdateBehavior=LOG \ --configuration '{"Version": 1.0, "CrawlerOutput": {"Partitions": { "AddOrUpdateBehavior": "InheritFromTable" }}}' ``` ------ #### [ API ] クローラーの実行時にテーブルスキーマを一切変更しない場合は、スキーマ変更ポリシーを `LOG` に設定します。 API を使用してクローラーを設定する場合は、以下のパラメータを設定します。 + `SchemaChangePolicy` 構造の `UpdateBehavior` フィールドを `LOG` に設定します。 + クローラー API で次の JSON オブジェクトの文字列表現を使用して `Configuration` フィールドを設定します。 ``` { "Version": 1.0, "CrawlerOutput": { "Partitions": { "AddOrUpdateBehavior": "InheritFromTable" } } } ``` ------ # 各 Amazon S3 インクルードパスの単一のスキーマを作成する デフォルトでは、Amazon S3 に保存されたデータのテーブルをクローラーが定義するときに、データの互換性とスキーマの類似性の両方が考慮されます。考慮されるデータ互換性要因には、データが同じ形式 (JSON など) かどうか、同じ圧縮タイプ (GZIP など) かどうか、Amazon S3 パスの構造、他のデータ属性などです。スキーマの類似性は、別個の Amazon S3 オブジェクトのスキーマがどれくらい似ているかの尺度です。 このオプションを説明するため、インクルードパス `s3://amzn-s3-demo-bucket/table1/` を使用してクローラーを定義するとします。クローラーが実行されると、次の特性を持つ 2 つの JSON ファイルが検索されます。 + **ファイル 1** – `S3://amzn-s3-demo-bucket/table1/year=2017/data1.json` + *ファイルのコンテンツ* – `{“A”: 1, “B”: 2}` + *スキーマ* – `A:int, B:int` + **ファイル 2** – `S3://amzn-s3-demo-bucket/table1/year=2018/data2.json` + *ファイルのコンテンツ* – `{“C”: 3, “D”: 4}` + *スキーマ* – `C: int, D: int` デフォルトでは、スキーマの類似性が十分ではないため、クローラーは `year_2017` および `year_2018` という 2 つのテーブルを作成します。ただし、オプション [**Create a single schema for each S3 path (各 S3 パスの単一のスキーマを作成する)**] を選択し、データに互換性がある場合、クローラーは 1 つのテーブルを作成します。テーブルにはスキーマ `A:int,B:int,C:int,D:int` と `partitionKey` `year:string` があります。 ------ #### [ AWS マネジメントコンソール ] 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. **[Data Catalog]** で **[クローラー]** を選択します。 1. 新しいクローラーを設定するときは、**[出力およびスケジューリング]** で、[詳細オプション] の **[各 S3 パスの単一のスキーマを作成する]** オプションを選択します。 ------ #### [ AWS CLI ] 可能な場合は、`CombineCompatibleSchemas` へのクローラーを共通テーブル定義に設定できます。このオプションを使用しても、クローラーはデータ互換性を考慮に入れますが、指定されたインクルードパスで Amazon S3 オブジェクトを評価するときに特定のスキーマの類似性を無視します。 AWS CLI を使用してクローラーを設定する場合は、以下の設定オプションを設定します。 ``` aws glue update-crawler \ --name myCrawler \ --configuration '{"Version": 1.0, "Grouping": {"TableGroupingPolicy": "CombineCompatibleSchemas" }}' ``` ------ #### [ API ] API を使用してクローラーを設定する場合は、以下の設定オプションを設定します。 クローラー API で次の JSON オブジェクトの文字列表現を使用して `Configuration` フィールドを設定します。 ``` { "Version": 1.0, "Grouping": { "TableGroupingPolicy": "CombineCompatibleSchemas" } } ``` ------ # テーブルの場所とパーティションレベルの指定 デフォルトでは、Amazon S3 に保存されたデータのテーブルをクローラーが定義するときに、クローラーはスキーマを結合して最上位テーブル (`year=2019`) を作成しようとします。場合によっては、フォルダ `month=Jan` のテーブルをクローラーが作成することを期待することがありますが、兄弟フォルダ (`month=Mar`) が同じテーブルにマージされているので、代わりにクローラーはパーティションを作成します。 テーブルレベルのクローラーオプションを使用すると、クローラーにテーブルの配置場所やパーティションの作成方法を柔軟に指定できます。**テーブルレベル** を指定すると、その絶対レベルにAmazon S3 バケットからテーブルが作成されます。 ![\[テーブルレベルがレベル 2 に指定されている場合のクローラーのグループ化\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/crawler-table-level1.jpg) コンソールでクローラーを設定するとき、**テーブルレベル** クローラーオプションの値を指定できます。値は、テーブルの場所 (データセット内の絶対レベル) を示す正の整数である必要があります。最上位レベルのフォルダのレベルは 1 です。例えば、`mydataset/year/month/day/hour` というパスで、レベルが 3 に設定されている場合、テーブルは `mydataset/year/month` という場所に作成されます。 ------ #### [ AWS マネジメントコンソール ] 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. **[Data Catalog]** で **[クローラー]** を選択します。 1. クローラーを設定するときは、**[出力とスケジューリング]** で、**[詳細オプション]** の **[テーブルレベル]** を選択します。 ![\[クローラー設定でのテーブルレベルの指定。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/crawler-configuration-console.png) ------ #### [ AWS CLI ] AWS CLI を使用してクローラーを設定するときは、次のサンプルコードに示すように `configuration` パラメータを設定します。 ``` aws glue update-crawler \ --name myCrawler \ --configuration '{"Version": 1.0, "Grouping": { "TableLevelConfiguration": 2 }}' ``` ------ #### [ API ] API を使用してクローラー設定をすると、次の JSON オブジェクトの文字列表現をする `Configuration` フィールドを設定します。例: ``` configuration = jsonencode( { "Version": 1.0, "Grouping": { TableLevelConfiguration = 2 } }) ``` ------ #### [ CloudFormation ] この例では、CloudFormation テンプレート内のコンソールで使用できる **[Table Level]** (テーブルレベル) オプションを設定します。 ``` "Configuration": "{ \"Version\":1.0, \"Grouping\":{\"TableLevelConfiguration\":2} }" ``` ------ # クローラーが作成できるテーブルの最大数を指定する (オプション) AWS Glue コンソールまたは AWS CLI を使用して `TableThreshold` を指定することで、クローラーが作成できるテーブルの最大数を指定できます。クローリング中にクローラーによって検出されたテーブルがこの入力値より多い場合、クローリングが失敗し、データカタログにデータが書き込まれません。 このパラメータは、クローラーによって検出および作成されるテーブルが予想よりもはるかに多い場合に役立ちます。これには、以下のような複数の理由が考えられます。 + AWS Glue ジョブを使用して Amazon S3 ロケーションに入力する場合、フォルダと同じレベルに空のファイルができる可能性があります。このような場合、この Amazon S3 ロケーションでクローラーを実行すると、ファイルとフォルダが同じレベルに存在するため、クローラーは複数のテーブルを作成します。 + `"TableGroupingPolicy": "CombineCompatibleSchemas"` を設定しない場合、予想よりも多くのテーブルが作成される可能性があります。 `TableThreshold` を 1 以上の整数値として指定します。この値はクローラーごとに設定されます。つまり、クローリングごとに、この値が考慮されます。例えば、あるクローラーでは `TableThreshold` 値を 5 に設定したとします。各クローリングで、AWS Glue は検出されたテーブルの数をこのテーブルのしきい値 (5) と比較します。検出されたテーブルの数が 5 未満の場合、AWS Glue はデータカタログにテーブルを書き込み、そうでない場合、データカタログに書き込むことなくクローリングが失敗します。 ------ #### [ AWS マネジメントコンソール ] **AWS マネジメントコンソール を使用して `TableThreshold` を設定する場合は、次のようになります。** 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. クローラーを設定するときに、**[出力とスケジューリング]** で、クローラーが生成できるテーブルの数に**最大テーブルしきい値**を設定します。 ![\[最大テーブルしきい値のパラメータを表示する AWS コンソールの [Output and scheduling] (出力およびスケジューリング) セクション。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/crawler-max-tables.png) ------ #### [ AWS CLI ] AWS CLI を使用して `TableThreshold` を設定する場合は、次のようになります。 ``` aws glue update-crawler \ --name myCrawler \ --configuration '{"Version": 1.0, "CrawlerOutput": {"Tables": { "TableThreshold": 5 }}}' ``` ------ #### [ API ] API を使用して `TableThreshold` を設定する場合は、次のようになります。 ``` "{"Version":1.0, "CrawlerOutput": {"Tables":{"AddOrUpdateBehavior":"MergeNewColumns", "TableThreshold":5}}}"; ``` ------ エラーメッセージはログに記録され、テーブルパスを特定してデータをクリーンアップするのに役立ちます。テーブル数が指定したテーブルしきい値を超えているためにクローラーが失敗した場合は、次のようなログの例がアカウントで確認できます。 ``` Table Threshold value = 28, Tables detected - 29 ``` CloudWatch では、検出されたすべてのテーブルの場所を INFO メッセージとしてログに記録します。失敗の理由としてエラーがログに記録されます。 ``` ERROR com.amazonaws.services.glue.customerLogs.CustomerLogService - CustomerLogService received CustomerFacingException with message The number of tables detected by crawler: 29 is greater than the table threshold value provided: 28. Failing crawler without writing to Data Catalog. com.amazonaws.services.glue.exceptions.CustomerFacingInternalException: The number of tables detected by crawler: 29 is greater than the table threshold value provided: 28. Failing crawler without writing to Data Catalog. ``` # Lake Formation 認証情報を使用するようにクローラーを設定する AWS Lake Formation 認証情報を使用するようにクローラーを設定すると、同じ AWS アカウント または別の AWS アカウント 内の基盤となる Amazon S3 ロケーションで Amazon S3 データストアまたはデータカタログテーブルにアクセスできます。クローラーとデータカタログテーブルが同じアカウントに存在する場合は、既存のデータカタログテーブルをクローラーのターゲットとして設定できます。現在、Data Catalog テーブルをクローラーのターゲットとして使用する場合、単一のカタログテーブルを含む単一のカタログターゲットのみが許可されています。 **注記** データカタログテーブルをクローラーターゲットとして定義する場合、データカタログテーブルの基盤となるロケーションが Amazon S3 ロケーションであることを確認してください。Lake Formation の認証情報を使用するクローラーは、基盤となる Amazon S3 ロケーションを備えたデータカタログターゲットのみをサポートしています。 ## クローラーと登録された Amazon S3 ロケーションまたはデータカタログテーブルが同じアカウントに存在する場合は、セットアップが必要になります (アカウント内クローリング) クローラーが Lake Formation の認証情報を使用してデータストアまたはデータカタログテーブルにアクセスできるようにするには、データロケーションを Lake Formation で登録する必要があります。また、クローラーの IAM ロールには、Amazon S3 バケットが登録されている送信先からデータを読み込む許可が付与されている必要があります。 AWS マネジメントコンソール または AWS Command Line Interface (AWS CLI) を使用して、次の設定手順を完了できます。 ------ #### [ AWS マネジメントコンソール ] 1. クローラーソースにアクセスするようにクローラーを設定する前に、データストアまたはデータカタログのデータロケーションを Lake Formation で登録します。Lake Formation コンソール ([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)) で、クローラーが定義されている AWS アカウント で Amazon S3 ロケーションをデータレイクのルートロケーションとして登録します。詳細については、「[Amazon S3 ロケーションの登録](https://docs.aws.amazon.com/lake-formation/latest/dg/register-location.html)」を参照してください。 1. クローラーの実行に使用される IAM ロールに**データロケーション**許可を付与し、クローラーが Lake Formation の送信先からデータを読み込めるようにします。詳細については、「[データロケーション許可の付与 (同じアカウント)](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-location-permissions-local.html)」を参照してください。 1. クローラーロールにデータベースへのアクセス権限 (`Create`) を付与します。 このデータベースは出力データベースとして指定されています。詳細については、「[Lake Formation コンソールと名前付きリソース方式を使用したデータベース許可の付与](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-database-permissions.html)」を参照してください。 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) で、クローラー用の IAM ロールを作成します。ロールに `lakeformation:GetDataAccess` ポリシーを追加します。 1. AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) で、クローラーを設定する際に、オプション **[Use Lake Formation credentials for crawling Amazon S3 data source]** (Amazon S3 データソースのクローリングに Lake Formation の認証情報を使用する) を選択してください。 **注記** accountId フィールドは、アカウント内クローリングのためのオプションです。 ------ #### [ AWS CLI ] ``` aws glue --profile demo create-crawler --debug --cli-input-json '{ "Name": "prod-test-crawler", "Role": "arn:aws:iam::111122223333:role/service-role/AWSGlueServiceRole-prod-test-run-role", "DatabaseName": "prod-run-db", "Description": "", "Targets": { "S3Targets":[ { "Path": "s3://amzn-s3-demo-bucket" } ] }, "SchemaChangePolicy": { "UpdateBehavior": "LOG", "DeleteBehavior": "LOG" }, "RecrawlPolicy": { "RecrawlBehavior": "CRAWL_EVERYTHING" }, "LineageConfiguration": { "CrawlerLineageSettings": "DISABLE" }, "LakeFormationConfiguration": { "UseLakeFormationCredentials": true, "AccountId": "111122223333" }, "Configuration": { "Version": 1.0, "CrawlerOutput": { "Partitions": { "AddOrUpdateBehavior": "InheritFromTable" }, "Tables": {"AddOrUpdateBehavior": "MergeNewColumns" } }, "Grouping": { "TableGroupingPolicy": "CombineCompatibleSchemas" } }, "CrawlerSecurityConfiguration": "", "Tags": { "KeyName": "" } }' ``` ------ # クローラーと登録された Amazon S3 ロケーションが異なるアカウントに存在する場合は、セットアップが必要になります (クロスアカウントクローリング) クローラーが Lake Formation の認証情報を使用して別のアカウントのデータストアにアクセスできるようにするには、まず Amazon S3 のデータロケーションを Lake Formation で登録する必要があります。次に、以下の手順を実行して、クローラーのアカウントにデータロケーション許可を付与します。 AWS マネジメントコンソール または AWS CLI を使用して、次のステップを実行できます。 ------ #### [ AWS マネジメントコンソール ] 1. Amazon S3 ロケーションが登録されているアカウント (アカウント B) では、次の操作を行います。 1. Lake Formation で Amazon S3 パスを登録します。詳細については、「[Amazon S3 ロケーションの登録](https://docs.aws.amazon.com/lake-formation/latest/dg/register-location.html)」を参照してください。 1. クローラーを実行するアカウント (アカウント A) に**データロケーション**許可を付与します。詳細については、「[Grant data location permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-location-permissions-local.html)」(データロケーション許可を付与する) を参照してください。 1. 基盤となるロケーションをターゲットの Amazon S3 ロケーションとして、Lake Formation に空のデータベースを作成します。詳細については、「[データベースの作成](https://docs.aws.amazon.com/lake-formation/latest/dg/creating-database.html)」を参照してください。 1. アカウント A (クローラーを実行するアカウント) に、前のステップで作成したデータベースへのアクセス権を付与します。詳細については、「[Granting database permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-database-permissions.html)」(データベース許可の付与) を参照してください。 1. クローラーが作成され実行されるアカウント (アカウント A) では、次の操作を行います。 1. AWS RAM コンソールを使用して、外部アカウント (アカウント B) から共有されたデータベースを受け入れます。詳細については、「[AWS Resource Access Manager からのリソース共有招待の承諾](https://docs.aws.amazon.com/lake-formation/latest/dg/accepting-ram-invite.html)」を参照してください。 1. クローラー用の IAM ロールを作成します。ロールに `lakeformation:GetDataAccess` ポリシーを追加します。 1. Lake Formation コンソール ([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)) で、ターゲットの Amazon S3 ロケーションに対する**データロケーション**許可をクローラーの実行に使用される IAM ロールに付与して、クローラーが Lake Formation の送信先からデータを読み込めるようにします。詳細については、「[Granting data location permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-location-permissions-local.html)」(データロケーション許可の付与) を参照してください。 1. 共有データベースでリソースリンクを作成します。詳細については、「[Create a resource link](https://docs.aws.amazon.com/lake-formation/latest/dg/create-resource-link-database.html)」(リソースリンクを作成する) を参照してください。 1. クローラーロールに共有データベースと (`Describe`) リソースリンクに対するアクセス許可 (`Create`) を付与します。リソースリンクはクローラーの出力で指定されます。 1. AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) で、クローラーを設定する際に、オプション **[Use Lake Formation credentials for crawling Amazon S3 data source]** (Amazon S3 データソースのクローリングに Lake Formation の認証情報を使用する) を選択してください。 クロスアカウントクローリングの場合は、ターゲットの Amazon S3 ロケーションが Lake Formation で登録されている AWS アカウント ID を指定します。アカウント内クローリングの場合、accountId フィールドはオプションです。 ![\[IAM role selection and Lake Formation configuration options for AWS Glue クローラー security settings.\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/cross-account-crawler.png) ------ #### [ AWS CLI ] ``` aws glue --profile demo create-crawler --debug --cli-input-json '{ "Name": "prod-test-crawler", "Role": "arn:aws:iam::111122223333:role/service-role/AWSGlueServiceRole-prod-test-run-role", "DatabaseName": "prod-run-db", "Description": "", "Targets": { "S3Targets":[ { "Path": "s3://amzn-s3-demo-bucket" } ] }, "SchemaChangePolicy": { "UpdateBehavior": "LOG", "DeleteBehavior": "LOG" }, "RecrawlPolicy": { "RecrawlBehavior": "CRAWL_EVERYTHING" }, "LineageConfiguration": { "CrawlerLineageSettings": "DISABLE" }, "LakeFormationConfiguration": { "UseLakeFormationCredentials": true, "AccountId": "111111111111" }, "Configuration": { "Version": 1.0, "CrawlerOutput": { "Partitions": { "AddOrUpdateBehavior": "InheritFromTable" }, "Tables": {"AddOrUpdateBehavior": "MergeNewColumns" } }, "Grouping": { "TableGroupingPolicy": "CombineCompatibleSchemas" } }, "CrawlerSecurityConfiguration": "", "Tags": { "KeyName": "" } }' ``` ------ **注記** Lake Formation 認証情報を使用するクローラーは、Amazon S3 およびデータカタログターゲットでのみサポートされます。 Lake Formation 認証情報供給を使用するターゲットの場合、基盤となる Amazon S3 ロケーションは同じバケットに属している必要があります。例えば、すべてのターゲットロケーションが同じバケット (amzn-s3-demo-bucket1) にある限り、ユーザーは複数のターゲット (s3://amzn-s3-demo-bucket1/folder1、s3://amzn-s3-demo-bucket1/folder2) を使用できます。別のバケット (s3://amzn-s3-demo-bucket1/folder1、s3://amzn-s3-demo-bucket2/folder2) を指定することはできません。 現在、データカタログのターゲットクローラーでは、単一のカタログテーブルを含む単一のカタログターゲットのみが許可されています。 # Amazon S3 イベント通知を使用した加速クロール Amazon S3 または Data Catalog ターゲットからオブジェクトを一覧表示する代わりに、Amazon S3 イベントを使用して変更を検索するようにクローラーを設定できます。この機能は、Amazon S3 または Data Catalog ターゲット全体を一覧表示するのではなく、Amazon S3 イベントを使用してイベントをトリガーしたサブフォルダからのすべてのファイルを一覧表示して 2 つのクロール間の変更を識別することによって、再クロール時間を短縮します。 最初のクロールでは、ターゲットからのすべての Amazon S3 オブジェクトを一覧表示します。最初のクロールの成功後、手動または設定されたスケジュールでリクロールを選択できます。クローラーは、すべてのオブジェクトをリストするのではなく、それらのイベントのオブジェクトのみをリストします。 ターゲットが Data Catalog テーブルの場合、クローラーは変更内容 (テーブル内の追加パーティションなど) で Data Catalog 内の既存のテーブルを更新します。 Amazon S3 イベントベースのクローラーに移行する利点は以下のとおりです。 + ターゲットからのすべてのオブジェクトの一覧表示を要しない場合は、より速く再クロールできます。その代わりに、オブジェクトが追加または削除される特定のフォルダが一覧表示されます。 + オブジェクトが追加または削除される特定のフォルダの一覧表示を行うと、全体的なクロールコストが削減されます。 Amazon S3 イベントクロールは、クローラーのスケジュールに基づいて SQS キューから Amazon S3 イベントを使うことで実行します。キューにイベントがない場合、費用はかかりません。Amazon S3 イベントは、SQS キューに直接送信するように設定できます。また、複数のコンシューマーが同じイベント、SNS と SQS の組み合わせを必要とする場合にも設定できます。詳細については、「[Amazon S3 イベント通知のアカウントを設定します。](#crawler-s3-event-notifications-setup)」を参照してください。 イベントモードでクローラーを作成して設定した後の最初のクロールは、Amazon S3 または Data Catalog ターゲットの完全な一覧表示を行う一覧表示モードで実行されます。次のログは、最初に成功したクロール、「クロールは Amazon S3 イベントを使用して実行します」の後に、Amazon S3 イベントを使用してクロールのオペレーションを確認します。 Amazon S3 イベントクロールを作成し、クロールに影響を与える可能性のあるクローラーのプロパティを更新すると、クロールがリストモードで動作し、「クロールは S3 イベントモードで実行されていません」というログが追加されます。 **注記** クロールごとに消費するメッセージの最大数は 100,000 メッセージです。 ## 考慮事項と制限事項 Amazon S3 イベント通知を使用して変更を検索するようにクローラーを設定する場合、以下の考慮事項と制限が適用されます。 + **削除されたパーティションの重要な動作** データカタログテーブルで Amazon S3 イベントクローラーを使用する場合: + `DeletePartition` API コールを使用してパーティションを削除する場合、そのパーティション内のすべての S3 オブジェクトも削除し、さらに S3 イベント通知を設定するときに **[すべてのオブジェクト削除イベント]** を選択する必要があります。削除イベントが設定されていない場合、クローラは次の実行時に削除されたパーティションを再作成します。 + ターゲットが Amazon S3 または Data Catalog であるかにかかわらず、クローラーがサポートするのは単一のターゲットのみです。 + プライベート VPC の SQS はサポートされていません。 + Amazon S3 サンプリングはサポートされていません。 + クローラーターゲットは、Amazon S3 ターゲットの場合はフォルダ、Data Catalog ターゲットの場合は 1 つ、または複数の AWS Glue Data Catalog テーブルにする必要があります。 + 「すべての」パスのワイルドカードをサポートしていません: s3: //% + Data Catalog ターゲットの場合、Amazon S3 イベントモードでは、すべてのカタログテーブルが同じ Amazon S3 バケットをポイントする必要があります。 + Data Catalog ターゲットの場合、カタログテーブルは Delta Lake 形式の Amazon S3 ロケーションをポイントしない必要があります (\$1symlink フォルダが含まれる、またはカタログテーブルの `InputFormat` を確認)。 **Topics** + [考慮事項と制限事項](#s3event-crawler-limitations) + [Amazon S3 イベント通知のアカウントを設定します。](#crawler-s3-event-notifications-setup) + [Amazon S3 ターゲットの Amazon S3 イベント通知用のクローラーを設定する](crawler-s3-event-notifications-setup-console-s3-target.md) + [Data Catalog テーブルの Amazon S3 イベント通知用のクローラーを設定する](crawler-s3-event-notifications-setup-console-catalog-target.md) ## Amazon S3 イベント通知のアカウントを設定します。 以下の設定タスクを実行します。括弧内の値は、スクリプトの構成可能な設定を参照している点に注意してください。 1. Amazon S3 バケットのイベント通知を設定する必要があります。 詳細については、「[Amazon S3 イベント通知](https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html)」を参照してください。 1. Amazon S3 イベントベースのクローラーを使用するには、S3 ターゲットと同じプレフィックスからフィルタリングされたイベントが含まれた Amazon S3 バケットでイベント通知を有効にし、SQS に保存する必要があります。SQS とイベント通知は、「[チュートリアル: 通知のバケットを設定する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ways-to-add-notification-config-to-bucket.html)」の手順に従って、コンソールから設定できます。 1. クローラーが使用するロールに次の SQS ポリシーを追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:GetQueueUrl", "sqs:ListDeadLetterSourceQueues", "sqs:ReceiveMessage", "sqs:GetQueueAttributes", "sqs:ListQueueTags", "sqs:SetQueueAttributes", "sqs:PurgeQueue" ], "Resource": "arn:aws:sqs:us-east-1:111122223333:cfn-sqs-queue" } ] } ``` ------ # Amazon S3 ターゲットの Amazon S3 イベント通知用のクローラーを設定する AWS マネジメントコンソール または AWS CLI を使用して Amazon S3 ターゲットの Amazon S3 イベント通知用のクローラーを設定するには、以下の手順を実行します。 ------ #### [ AWS マネジメントコンソール ] 1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) で GuardDuty コンソールを開きます。 1. クローラーのプロパティを設定します。詳細については、「[AWS Glue コンソールでのクローラー設定オプションの設定](https://docs.aws.amazon.com/glue/latest/dg/crawler-configuration.html#crawler-configure-changes-console)」を参照してください。 1. **[データソースの設定]** セクションに、[データは AWS Glue テーブルにマッピング済みですか?] という質問が表示されています。 デフォルトでは、**[Not yet]** (まだです) が選択されています。Amazon S3 のデータソースを使用しており、データがまだ AWS Glue テーブルにマップされていないため、これはデフォルトままにしておきます。 1. **[Data sources]** (データソース) セクションで、**[Add a data source]** (データソースを追加) を選択します。 ![\[Data source configuration interface with options to select or add data sources for crawling.\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/crawler-s3-event-console1.png) 1. **[Add data source]** (データソースの追加) ダイアログで、Amazon S3 データソースを以下のように設定します。 + **[Data source]** (データソース): デフォルトで、Amazon S3 が選択されています。 + **[Network connection]** (ネットワーク接続) (オプション): **[Add new connection]** (新しい接続を追加) を選択します。 + **[Location of Amazon S3 data]** (Amazon S3 データの場所): デフォルトで、**[In this account]** (このアカウント内) が選択されています。 + **[Amazon S3 path]** (Amazon S3 パス): フォルダとファイルがクロールされる Amazon S3 パスを指定します。 + **[Subsequent crawler runs]** (それ以降のクローラー実行): クローラーに関する Amazon S3 イベント通知を使用するには、**[Crawl based on events]** (イベントに基づくクロール) を選択します。 + **[Include SQS ARN]** (SQS ARN を含める): 有効な SQS ARN を含むデータストアパラメータを指定します。(例えば、`arn:aws:sqs:region:account:sqs`) + **[Include dead-letter SQS ARN]** (配信不能 SQS ARN を含める) (オプション): 有効な Amazon 配信不能 SQS ARN を指定します。(例えば、`arn:aws:sqs:region:account:deadLetterQueue`) + **[Add an Amazon S3 data source]** (Amazon S3 データソースを追加) を選択します。 ![\[Add data source dialog for S3, showing options for network connection and crawl settings.\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/crawler-s3-event-console2.png) ------ #### [ AWS CLI ] 次に示すのは、イベント通知を使用して Amazon S3 ターゲットバケットをクロールするようにクローラーを設定するための Amazon S3 AWS CLI コールの例です。 ``` Create Crawler: aws glue update-crawler \ --name myCrawler \ --recrawl-policy RecrawlBehavior=CRAWL_EVENT_MODE \ --schema-change-policy UpdateBehavior=UPDATE_IN_DATABASE,DeleteBehavior=LOG --targets '{"S3Targets":[{"Path":"s3://amzn-s3-demo-bucket/", "EventQueueArn": "arn:aws:sqs:us-east-1:012345678910:MyQueue"}]}' ``` ------ # Data Catalog テーブルの Amazon S3 イベント通知用のクローラーを設定する Data Catalog テーブルがある場合は、AWS Glue コンソールを使用して Amazon S3 イベント通知用のクローラーを設定します。 1. クローラーのプロパティを設定します。詳細については、「[AWS Glue コンソールでのクローラー設定オプションの設定](https://docs.aws.amazon.com/glue/latest/dg/crawler-configuration.html#crawler-configure-changes-console)」を参照してください。 1. **[データソースの設定]** セクションに、[データは AWS Glue テーブルにマッピング済みですか?] という質問が表示されています。 **[Yes]** (はい) を選択して、Data Catalog からの既存のテーブルをデータソースとして選択します。 1. **[Glue tables]** (Glue テーブル) セクションで、**[Add tables]** (テーブルを追加する) を選択します。 ![\[Data source configuration interface with options to select existing Glue tables or add new ones.\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/crawler-s3-event-console1-cat.png) 1. **[Add table]** (テーブルを追加する) モーダルで、データベースとテーブルを設定します。 + **[Network connection]** (ネットワーク接続) (オプション): **[Add new connection]** (新しい接続を追加) を選択します。 + **[Database]** (データベース): Data Catalog 内のデータベースを選択します。 + **[Tables]** (テーブル): Data Catalog 内のデータベースから 1 つ、または複数のテーブルを選択します。 + **[Subsequent crawler runs]** (それ以降のクローラー実行): クローラーに関する Amazon S3 イベント通知を使用するには、**[Crawl based on events]** (イベントに基づくクロール) を選択します。 + **[Include SQS ARN]** (SQS ARN を含める): 有効な SQS ARN を含むデータストアパラメータを指定します。(例えば、`arn:aws:sqs:region:account:sqs`) + **[Include dead-letter SQS ARN]** (配信不能 SQS ARN を含める) (オプション): 有効な Amazon 配信不能 SQS ARN を指定します。(例えば、`arn:aws:sqs:region:account:deadLetterQueue`) + [**確認**] を選択してください。 ![\[Add Glue tables dialog with network, database, tables, and crawler options.\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/crawler-s3-event-console2-cat.png) # チュートリアル: AWS Glue クローラの追加 この AWS Glue シナリオでは、主要な航空会社の到着データを分析して、各月の出発空港の人気度を計算するよう求められています。2016 年のフライトデータが CSV 形式で Amazon S3 に保存されています。データの変換と分析を行う前に、AWS Glue Data Catalog 内のそのメタデータをカタログ化します。 このチュートリアルでは、これらのフライトログからメタデータを推測し、データ Amazon S3 にテーブルを作成するクローラを追加します。 **Topics** + [前提条件](#tutorial-add-crawler-prerequisites) + [ステップ 1: クローラの追加](#tutorial-add-crawler-step1) + [ステップ 2: クローラを実行する](#tutorial-add-crawler-step2) + [ステップ 3: AWS Glue Data Catalog オブジェクトを表示する](#tutorial-add-crawler-step3) ## 前提条件 このチュートリアルでは、 AWS アカウントを持ち、AWS Glue にアクセスできることを前提としています。 ## ステップ 1: クローラの追加 Amazon S3 に保存されている CSV ファイルからメタデータを抽出するクローラを設定および実行するには、以下の手順に従ってください。 **Amazon S3 に保存されているファイルを読み込むクローラを作成するには** 1. AWS Glue サービスコンソールの左側のメニューで、[**Crawlers**] (クローラー) を選択します。 1. クローラーページで、**[Create crawler]** を選択します。これにより、クローラの詳細に関する入力を求める一連のページが表示されます。 ![\[スクリーンショットは、クローラーページが表示されています。ここから、クローラーを作成できるほか、既存のクローラーの編集、複製、削除、表示を実行できます。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/crawlers-create_crawler.png) 1. [クローラ名] フィールドに、「**Flights Data Crawler**」を入力して、 [**Next**] (次へ) を選択します。 クローラは分類子を呼び出して、データのスキーマを推測します。このチュートリアルでは、デフォルトの CSV 用の組み込みの分類子を使用します。 1. [クローラソースタイプ] で、[**Data stores**] (データストア) を選択し、[**Next**] (次へ) を選択します。 1. それでは、クローラをデータに指定します。[**Add a data store**] (データストアの追加) ページで、[Amazon S3 data store] (Amazon S3 データストア) を選択します。このチュートリアルでは接続を使用しないため、[**Connection**] (接続) フィールドが表示されている場合は、そのフィールドを空白のままにしてください。 [**Crawl data in**] (クロールするデータの場所) で、[**Specified path in another account**] (別のアカウントで指定されたパス) を選択します。次に、[**Include path**] (インクルードパス) に、クローラがフライトデータ（**s3://crawler-public-us-east-1/flight/2016/csv**）に対するパスを入力します。パスを入力すると、このフィールドのタイトルが [**Include path**] (インクルードパス) に変わります。[**次へ**] を選択します。 1. 単一のクローラで複数のデータストアをクロールできます。ただし、このチュートリアルでは 1 つのデータストアのみを使用しているため、[**No**] (なし) を選択して、次に [**Next**] (次へ) を選択します。 1. クローラーには、データストアにアクセスして AWS Glue Data Catalog でオブジェクトを作成するためのアクセス許可が必要です。これらのアクセス許可を設定するために、[**Create an IAM role**] (IAM ロールを作成する) を選択します。IAM ロール名は 「`AWSGlueServiceRole-`」で始まります。フィールドにロール名の後ろの部分を入力します。　 「**CrawlerTutorial**」と入力し、[**Next**] (次へ) を選択します。 **注記** IAM ロールを作成するには、AWS ユーザーは `CreateRole`、`CreatePolicy`、および `AttachRolePolicy` アクセス許可が必要です。 ウィザードが「`AWSGlueServiceRole-CrawlerTutorial`」という名前の IAM ロールを作成し、AWS 管理ポリシー `AWSGlueServiceRole` をこのロールにアタッチし、Amazon S3 ロケーション `s3://crawler-public-us-east-1/flight/2016/csv` への読み取りアクセスを許可するインラインポリシーを追加します。 1. クローラのスケジュールを作成します。[**Frequency**] (頻度) で、[**Run on demand** (オンデマンドで実行する) を選択してから、[**Next**] (次へ) を選択します。 1. クローラは Data Catalog 内にテーブルを作成します。テーブルは、Data Catalog 内のデータベースに格納されます。まず、**Add database** (データベースを追加する) を選択してデータベースを作成します。ポップアップウィンドウで、データベース名に 「**test-flights-db**」と入力し、[**Create**] (作成) を選択します。 次に、[**Prefix added to tables**] (テーブルに追加されたプレフィックス) に「**flights**」を入力します。残りのフィールドにはデフォルト値を使用し、[**Next**] (次へ) を選択します。 1. 選択した内容を確認するには、[**Add crawler**] (クローラの追加) ウィザードを使用します。誤りを見つけた場合は、**Back** (戻る) をクリックして前のページに戻り、修正します。 情報を確認したら、[**Finish**] (完了) をクリックしてクローラを作成します。 ## ステップ 2: クローラを実行する クローラを作成した後、ウィザードがクローラビューページを表示します。オンデマンドのスケジュールでクローラを作成するため、クローラを実行するオプションを使用できます。 **クローラを実行するには** 1. このページの上部にあるバナーでは、クローラが作成されたことが表示され、それを実行するかどうかを尋ねられます。[**Run it now?**] (今すぐ実行しますか？) をクリックしてクローラを実行します。 バナーでは、クローラの「Attempting to run (実行しようとしています)」および「Running (実行中)」というメッセージの表示に変わります。クローラの実行を開始すると、バナーが消え、クローラの表示が更新され、クローラの [Starting] (起動) ステータスが表示されます。1 分後、[Refresh] (更新) アイコンをクリックして、テーブルに表示されるクローラのステータスを更新できます。 1. クローラが完了すると、クローラの変更を説明する新しいバナーが表示されます。**test-flights-db** リンクを選択して、Data Catalog オブジェクトを表示できます。 ## ステップ 3: AWS Glue Data Catalog オブジェクトを表示する クローラがソースの場所からデータを読み込み、Data Catalog にテーブルを作成します。テーブルは、スキーマを含むデータを表すメタデータ定義です。Data Catalog のテーブルにはデータが含まれていません。代わりに、ジョブ定義のソースまたはターゲットとしてこれらのテーブルを使用します。 **クローラが作成した Data Catalog オブジェクトを表示する方法** 1. 左側のナビゲーションペインの [**Data catalog**] (データカタログ) で、[**Databases**] (データベース) を選択します。ここでは、クローラーによって作成された `flights-db` データベースを表示できます。 1. 左側のナビゲーションの [**Data catalog**] (データカタログ) で、 [**Databases**] (データベース) の下の **Tables** (テーブル) を選択します。ここでは、クローラーが作成した `flightscsv` テーブルを表示できます。テーブル名を選択すると、テーブルの設定、パラメータ、およびプロパティを表示できます。このビューで下にスクロールすると、スキーマを表示できます。スキーマとは、テーブルの列とデータ型に関する情報です。 1. テーブルビューページで [**View partitions**] (パーティションの表示) を選択すると、データ用に作成されたパーティションを表示できます。最初の列はパーティションキーです。 # メタデータの手動定義 AWS Glue データカタログは、データソースとデータセットに関するメタデータを保存する中央リポジトリです。クローラーは、サポートされているデータソースのメタデータを自動的にクロールして入力できますが、データカタログでメタデータを手動で定義する必要があるシナリオがいくつかあります。 + サポートされていないデータ形式 – クローラーでサポートされていないデータソースがある場合は、データカタログでそれらのデータソースのメタデータを手動で定義する必要があります。 + カスタムメタデータ要件 — AWS Glue クローラー は、事前定義されたルールと規則に基づいてメタデータを推測します。AWS Glue クローラー で推測されたメタデータでカバーされない特定のメタデータ要件がある場合は、ニーズに合わせてメタデータを手動で定義できます。 + データガバナンスと標準化 — データガバナンス、コンプライアンス、またはセキュリティ上の理由から、メタデータ定義をより細かくコントロールする必要がある場合があります。メタデータを手動で定義することで、そのメタデータが組織の標準とポリシーに準拠していることを保証できます。 + 将来のデータインジェストのためのプレースホルダー – すぐに使用またはアクセスできないデータソースがある場合は、プレースホルダーとして空のスキーマテーブルを作成できます。データソースが利用可能になったら、事前定義された構造を維持しながら、テーブルに実際のデータを入力できます。 メタデータを手動で定義するには、AWS Glue コンソール、Lake Formation コンソール、AWS Glue API、または AWS Command Line Interface (AWS CLI) を使用できます。データベース、テーブル、パーティションを作成し、列名、データ型、説明、その他の属性などのメタデータプロパティを指定できます。 # データベースの作成 データベースは、メタデータテーブルを AWS Glue で組織化するために使用されます。AWS Glue Data Catalog でテーブルを定義すると、データベースに追加します。1 つのテーブルは、1 つのデータベースにしか含まれません。 データベースには、数多くのさまざまなデータストアからのデータを定義するテーブルを含めることができます。このデータには、Amazon Simple Storage Service (Amazon S3) のオブジェクトと、Amazon Relational Database Service のリレーショナルテーブルを含めることができます。 **注記** データベースを AWS Glue Data Catalog から削除すると、データベース内のすべてのテーブルも削除されます。 データベースのリストを表示するには、AWS マネジメントコンソール にサインインして、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。[**Databases**] (データベース) を選択し、リスト内のデータベース名を選択して詳細を表示します。 ** コンソールの [**DatabasesAWS Glue] (データベース) タブからデータベースの追加、編集、削除ができます。 + 新しいデータベースを作成するには、[**Add database**] (データベースを追加) を選択し名前と説明を指定します。Apache Hive など、その他のメタデータストアとの互換性を考慮して、名前は小文字に変換されます。 **注記** Amazon Athena からデータベースにアクセスする場合は、英数字とアンダースコア文字のみを使用して名前を指定してください。詳細については、[Athena での名前](https://docs.aws.amazon.com/athena/latest/ug/tables-databases-columns-names.html#ate-table-database-and-column-names-allow-only-underscore-special-characters)を参照してください。 + データベースの説明を編集するには、データベース名の横にあるチェックボックスを選択し、**[Edit]** (編集) を選択します。 + データベースを削除するには、データベース名の横にあるチェックボックスを選択し、**[Remove]** (削除) を選択します。 + データベースに含まれるテーブルのリストを表示するには、データベース名を選択します。そうすると、データベースプロパティにデータベース内のすべてのテーブルが表示されます。 クローラーで書き込みが行われたデータベースを変更するには、クローラー定義を変更する必要があります。詳細については、「[クローラーを使用したデータカタログへの入力](add-crawler.md)」を参照してください。 ## データベースリソースリンク | | | --- | | AWS Glue コンソールの更新が行われました。コンソールの現行バージョンでは、データベースリソースリンクはサポートされません。 | Data Catalog にはデータベースへの*リソースリンク*を含めることもできます。データベースリソースリンクは、ローカルデータベースまたは共有データベースへのリンクです。現在、AWS Lake Formation のみでリソースリンクを作成できます。データベースへのリソースリンクを作成した後、データベース名を使用する任意の場所で、リソースリンク名を使用できます。所有しているデータベースまたは共有しているデータベースとともに、データベースリソースリンクは `glue:GetDatabases()` から返され、AWS Glue コンソールの [**Databases**] (データベース) ページにエントリとして表示されます。 Data Catalog には、テーブルリソースリンクを含めることもできます。 リソースリンクの詳細については、*AWS Lake Formation デベロッパーガイド*の「[Creating Resource Links](https://docs.aws.amazon.com/lake-formation/latest/dg/creating-resource-links.html)」を参照してください。 # テーブルの作成 データストア内のデータのインベントリを作成するには、クローラーの実行が推奨されますが、メタデータテーブルを手動で AWS Glue Data Catalog に追加できます。このアプローチにより、メタデータ定義をより詳細にコントロールし、特定の要件に応じてカスタマイズできます。 以下の方法で、データカタログにテーブルを手動で追加することもできます。 + AWS Glue コンソールを使用して AWS Glue Data Catalog に手動でテーブルを作成します。詳細については、「[コンソールを使用したテーブルの作成](#console-tables)」を参照してください。 + [AWS Glue API](aws-glue-api.md) の `CreateTable` オペレーションを使用し、AWS Glue Data Catalog にテーブルを作成します。詳細については、「[CreateTable アクション (Python: create\$1table)](aws-glue-api-catalog-tables.md#aws-glue-api-catalog-tables-CreateTable)」を参照してください。 + CloudFormation テンプレートを使用します。詳細については、「[AWS Glue 用の AWS CloudFormation](populate-with-cloudformation-templates.md)」を参照してください。 コンソールまたは API を使用して手動でテーブルを定義する場合、テーブルスキーマおよびデータソースでデータのタイプとフォーマットを示す分類フィールドの値を指定します、クローラーでテーブルを作成する場合、データ形式とスキーマは、組み込み分類子またはカスタム分類子のいずれかによって決定されます。AWS Glue コンソールを使用してテーブルを作成する方法の詳細については、[コンソールを使用したテーブルの作成](#console-tables) を参照してください。 **Topics** + [テーブルパーティション](#tables-partition) + [テーブルリソースリンク](#tables-resource-links) + [コンソールを使用したテーブルの作成](#console-tables) + [パーティションインデックスの作成](partition-indexes.md) + [クローラーを使用して手動で作成されたデータカタログテーブルを更新する](#update-manual-tables) + [Data Catalog テーブルのプロパティ](#table-properties) ## テーブルパーティション Amazon Simple Storage Service (Amazon S3) フォルダの AWS Glue テーブル定義によって、パーティションテーブルを記述できます。たとえば、クエリのパフォーマンスを向上させるために、パーティションテーブルでは月の名前をキーとして毎月のデータを別のファイルに分割する場合があります。AWS Glue では、テーブル定義にテーブルのパーティションキーが含まれています。AWS Glue は、Amazon S3 フォルダのデータを評価してテーブルをカタログ化するとき、個々のテーブルまたはパーティション化されたテーブルを追加するかどうかを決定します。 テーブル内のすべてのパーティションをロードする代わりに、テーブル上にパーティションインデックスを作成して、パーティションのサブセットを取得できます。パーティションインデックスの使用方法については、「[パーティションインデックスの作成](partition-indexes.md)」を参照してください。 AWS Glue によって Amazon S3 フォルダのパーティションテーブルを作成するには、次の条件がすべて満たされている必要があります。 + ファイルのスキーマは、AWS Glue によって決定されるものと似ている。 + ファイルのデータ形式が同じである。 + ファイルの圧縮形式が同じである。 例えば、iOS と Android 両方のアプリケーションの販売データを保存する `my-app-bucket` という名前の Amazon S3 バケットを所有しているとします。データは、年、月、日で分割されます。iOS および Android の販売に関するデータファイルは、同じスキーマ、データ形式、および圧縮形式です。AWS Glue Data Catalog では、AWS Glue クローラーが、年、月、日のパーティションキーを使用して 1 つのテーブル定義を作成します。 次の `my-app-bucket` の Amazon S3 リストでは、パーティションのいくつかが示されています。`=` シンボルは、パーティションキー値の割り当てに使用されます。 ``` my-app-bucket/Sales/year=2010/month=feb/day=1/iOS.csv my-app-bucket/Sales/year=2010/month=feb/day=1/Android.csv my-app-bucket/Sales/year=2010/month=feb/day=2/iOS.csv my-app-bucket/Sales/year=2010/month=feb/day=2/Android.csv ... my-app-bucket/Sales/year=2017/month=feb/day=4/iOS.csv my-app-bucket/Sales/year=2017/month=feb/day=4/Android.csv ``` ## テーブルリソースリンク | | | --- | | AWS Glue コンソールの更新が行われました。コンソールの現行バージョンでは、テーブルリソースリンクはサポートされません。 | Data Catalog には、テーブルへの*リソースリンク*を含めることができます。テーブルリソースリンクは、ローカルまたは共有テーブルへのリンクです。現在、AWS Lake Formation のみでリソースリンクを作成できます。テーブルへのリソースリンクを作成すると、テーブル名を使用する任意の場所で、リソースリンク名を使用できます。自分が所有している、または自分と共有しているテーブルに加えて、テーブルリソースリンクは `glue:GetTables()` から返され、AWS Glue コンソールの [**Tables**] (テーブル) ページにエントリとして表示されます。 Data Catalog には、データベースリソースリンクを含めることもできます。 リソースリンクの詳細については、「*AWS Lake Formation デベロッパーガイド*」の「[Creating Resource Links](https://docs.aws.amazon.com/lake-formation/latest/dg/creating-resource-links.html)」を参照してください。 ## コンソールを使用したテーブルの作成 AWS Glue Data Catalog のテーブルは、データストア内のデータを表すメタデータ定義です。クローラの実行時にテーブルを作成するか、または、AWS Glue コンソールで手動でテーブルを作成できます。** コンソールの [**TablesAWS Glue] (テーブル) リストに、テーブルのメタデータの値が表示されます。ETL (抽出、変換、ロード) ジョブを作成するときに、テーブル定義を使用してソースとターゲットを指定します。 **注記** AWS マネジメントコンソールの最新の変更に伴い、既存の IAM ロール を [https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-SearchTables](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-SearchTables) 許可を持つように変更することが必要になる場合があります。新しいロールを作成する場合、`SearchTables` API 許可は既にデフォルトとして追加されています。 開始するには、AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。[**Tables**] (テーブル) タブをクリックし、[**Add tables**] (テーブルの追加) ボタンを使用して、クローラで、または属性を手動で入力してテーブルを作成します。 ### コンソールでテーブルを追加する クローラを使用してテーブルを追加するには、[**Add tables**] (テーブルの追加)、[**Add tables using a crawler**] (クローラを使用してテーブルを追加) の順に選択します。次に、[**Add crawler**] (クローラの追加) ウィザードの手順に従います。クローラが実行されると、テーブルが AWS Glue Data Catalog に追加されます。詳細については、[クローラーを使用したデータカタログへの入力](add-crawler.md) を参照してください。 Data Catalog の Amazon Simple Storage Service (Amazon S3) テーブル定義の作成に必要な属性が分かっている場合は、テーブルウィザードで作成できます。[**Add tables**] (テーブルの追加)、[**Add table manually**] (手動でのテーブルを追加) の順に選択し、[**Add table**] (テーブルの追加) ウィザードの手順に従います。 コンソールで手動でテーブルを追加するときは、以下の点を考慮します。 + Amazon Athena からテーブルにアクセスする場合は、英数字とアンダースコア文字のみを使用して名前を指定してください。詳細については、「[テーブル、データベース、および列の名前](https://docs.aws.amazon.com/athena/latest/ug/tables-databases-columns-names.html#ate-table-database-and-column-names-allow-only-underscore-special-characters)」を参照してください。 + ソースデータの場所は Amazon S3 パスにする必要があります。 + データのデータ形式は、ウィザードに表示されているいずれかの形式と一致する必要があります。対応する分類、SerDe、およびその他のテーブルのプロパティは、選択された形式に基づいて自動的に入力されます。次の形式でテーブルを定義できます。 **Avro** Apache Avro JSON バイナリ形式。 **CSV** 文字で区切られた値。また、区切り文字として、カンマ、パイプ、セミコロン、タブ、または Ctrl-A を指定します。 **JSON** JavaScript Object Notation。 **XML** Extensible Markup Language 形式。データの行を定義する XML タグを指定します。列は行のタグ内で定義されます。 **Parquet** Apache Parquet 列指向ストレージ。 **ORC** Optimized Row Columnar (ORC) ファイル形式。Hive データを効率的に保存するために設計された形式。 + テーブルのパーティションキーを定義できます。 + 現在、コンソールで作成した分割されたテーブルは、ETL ジョブで使用することはできません。 ### テーブル属性 以下に重要なテーブル属性を示します。 **名前** 名前は、テーブルの作成時に決定され、変更することはできません。多くの AWS Glue オペレーションでテーブル名を参照します。 **データベース** テーブルが存在するコンテナオブジェクト。このオブジェクトには、AWS Glue Data Catalog 内に存在するテーブルの組織名が含まれ、データストアの組織名とは異なる場合があります。データベースを削除すると、データベースに含まれるすべてのテーブルも Data Catalog から削除されます。 **説明** テーブルの説明。テーブルの内容を理解しやすくするために説明を記入できます。 **テーブル形式** 標準 AWS Glue テーブル、または Apache Iceberg 形式のテーブルの作成を指定します。 データカタログには、テーブルストレージを管理し、Iceberg テーブルのクエリパフォーマンスを向上させるための次のテーブル最適化オプションが用意されています。 + **圧縮** – 古いデータを削除して、フラグメント化されたデータをより大規模で効率的なファイルに統合するために、データファイルはマージされ、書き換えられます。 + **スナップショット保持** - スナップショットは、Iceberg テーブルのタイムスタンプ付きバージョンです。スナップショット保持設定を使用すると、スナップショットを保持する期間と保持するスナップショットの数を強制できます。スナップショット保持オプティマイザーを設定すると、古い不要なスナップショットと、その基になる関連付けられたファイルを削除して、ストレージのオーバーヘッドを管理できます。 + **孤立ファイルの削除** — 孤立ファイルは、Iceberg テーブルメタデータによって参照されなくなったファイルです。これらのファイルは、特にテーブルの削除や ETL ジョブの失敗などのオペレーションの後、時間の経過と共に蓄積される可能性があります。孤立ファイルの削除を有効にすると、AWS Glue はこれらの不要なファイルを定期的に特定して削除できるため、ストレージが解放されます。 詳細については、「[Iceberg テーブルの最適化](table-optimizers.md)」を参照してください。 **最適化設定** デフォルト設定を使用するか、テーブルオプティマイザを有効にするための設定をカスタマイズできます。 **IAM ロール** テーブル最適化を実行するために、サービスはユーザーに代わって IAM ロールを引き受けます。IAM ロールは、ドロップダウンを使用して選択できます。圧縮を有効にするために必要な許可がロールに付与されているようにしてください。 IAM ロールに必要な許可の詳細については、「[テーブル最適化の前提条件](optimization-prerequisites.md)」を参照してください。 **場所** このテーブル定義が表すデータストア内のデータの場所へのポインタ。 **分類** テーブルの作成時に指定された分類の値。通常、これはクローラが実行されてソースデータの形式を指定するときに書き込まれます。 **最終更新日** Data Catalog でこのテーブルが更新された日付と時刻 (UTC)。 **追加された日付** Data Catalog にこのテーブルが追加された日付と時刻 (UTC)。 **非推奨** AWS Glue により、Data Catalog のテーブルは元のデータストアに存在しなくなったことが分かると、そのテーブルは廃止されたとしてデータカタログにマークされます。廃止されたテーブルを参照するジョブを実行する場合、ジョブは失敗する可能性があります。廃止されたテーブルを参照するジョブを編集し、ソースおよびターゲットとして削除します。廃止されたテーブルが不要になったら削除することをお勧めします。 **接続** AWS Glue でデータストアへの接続が必要な場合は、接続の名前がテーブルに関連付けられます。 ### テーブルの詳細の表示と管理 既存のテーブルの詳細を表示するには、リスト内のテーブル名を選択し、[**Action, View details**] (アクション、詳細を表示) を選択します。 テーブルの詳細にはテーブルのプロパティとスキーマが含まれます。このビューには、テーブルに定義された順序の列名、データ型、およびパーティションのキー列を含む、テーブルのスキーマが表示されます。列が複合型の場合は、以下の例に示すように、[**View properties**] (プロパティの表示) を選択して、そのフィールドの構造の詳細を表示します。 ``` { "StorageDescriptor": { "cols": { "FieldSchema": [ { "name": "primary-1", "type": "CHAR", "comment": "" }, { "name": "second ", "type": "STRING", "comment": "" } ] }, "location": "s3://aws-logs-111122223333-us-east-1", "inputFormat": "", "outputFormat": "org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat", "compressed": "false", "numBuckets": "0", "SerDeInfo": { "name": "", "serializationLib": "org.apache.hadoop.hive.serde2.OpenCSVSerde", "parameters": { "separatorChar": "|" } }, "bucketCols": [], "sortCols": [], "parameters": {}, "SkewedInfo": {}, "storedAsSubDirectories": "false" }, "parameters": { "classification": "csv" } } ``` `StorageDescriptor` などのテーブルのプロパティの詳細については、「[StorageDescriptor 構造](aws-glue-api-catalog-tables.md#aws-glue-api-catalog-tables-StorageDescriptor)」を参照してください。 テーブルのスキーマを変更するには、[**Edit schema**] (スキーマの編集) を選択し、列の追加および削除、列名の変更、データ型の変更をします。 スキーマを含め、テーブルの異なるバージョンを比較するには、[**Compare versions**] (バージョンの比較) を選択し、テーブルの 2 つのバージョンのスキーマを並べて比較します。詳細については、「[テーブルスキーマのバージョンの比較](#console-tables-schema-comparison)」を参照してください。 Amazon S3 パーティションを構成するファイルを表示するには、[**View partition**] (パーティションの表示) を選択します。Amazon S3 のテーブルでは、[**Key**] (キー) 列に、ソースデータストアでテーブルを分割するために使用されるパーティションキーが表示されます。パーティションは、日付、場所、または部門などのキー列の値に基づいて、テーブルを関連する部分に分割する方法です。パーティションの詳細については、インターネットで「hive パーティション」を検索してください。 **注記** テーブルの詳細を表示するための詳細な手順については、コンソールの [**Explore table**] (テーブルの確認) チュートリアルを参照してください。 ### テーブルスキーマのバージョンの比較 テーブルスキーマの 2 つのバージョンを比較する場合、展開・折りたたみによってネストされた行の変更点を比較、2 つのバージョンのスキーマを並べて比較、テーブルプロパティを並べて表示、などが行えます。 バージョンの比較方法 1. AWS Glue コンソールから **[テーブル]** > **[アクション]** の順に選択し、**[バージョンの比較]** を選択します。 ![\[このスクリーンショットは、[アクション] ボタンの選択時を示しています。ドロップダウンメニューに [バージョンの比較] オプションが表示されます。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/catalog-table-compare-versions.png) 1. バージョンのドロップダウンメニューから、比較するバージョンを選択します。スキーマを比較すると、[スキーマ] タブがオレンジ色で強調表示されます。 1. 2 つのバージョン間でテーブルを比較すると、テーブルスキーマが画面の左側と右側に表示されます。列名、データ型、キー、コメントの各フィールドを並べて比較することで、変更点を視覚的に判断できます。変更があると、色付きのアイコンでその変更の種類が表示されます。 + 削除済み — 赤いアイコンによる表示は、以前のバージョンのテーブルスキーマから列が削除されたことを示します。 + 編集済みまたは移動済み — 青いアイコンによる表示は、新しいバージョンのテーブルスキーマで列が変更または移動されたことを示します。 + 追加 — 緑色のアイコンによる表示は、新しいバージョンのテーブルスキーマに列が追加されたことを示します。 + ネストされた変更 — 黄色のアイコンによる表示は、ネストされた列に変更が含まれていることを示します。列を選択して展開すると、削除、編集、移動、追加のいずれかが実行された列が表示されます。 ![\[このスクリーンショットは、2 つのバージョン間のテーブルスキーマの比較を示しています。左側は古いバージョンです。右側は新しいバージョンです。列の横にある削除アイコンは、古いバージョンから削除されたため、新しいバージョンでは表示されていません。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/catalog-table-version-comparison.png) 1. 検索バーのフィルタフィールドを使用すると、ここに入力した文字に基づいてフィールドを表示できます。いずれかのテーブルバージョンで列名を入力すると、フィルタリングされたフィールドが両方のテーブルバージョンに表示され、変更が行われた箇所がわかります。 1. プロパティを比較するには、**[プロパティ]** タブを選択します。 1. バージョンの比較を停止するには、**[比較の停止]** を選択してテーブルのリストに戻ります。 # パーティションインデックスの作成 時間の経過とともに、数十万のパーティションがテーブルに追加されます。[GetPartitions API](https://docs.aws.amazon.com/glue/latest/webapi/API_GetPartitions.html) は、テーブル内のパーティションをフェッチするために使用されます。この API は、リクエストで指定された式と一致するパーティションを返します。 「国」、「カテゴリ」、「年」、「月」、「creationDate」のキーで分割された例として、sales\$1data テーブルを参考にします。2020 年の 2020 年 8 月 15 日以降に「書籍」のカテゴリで販売されたアイテムの売り上げデータを取得する場合、Data Catalog に「Category = 'Books' and creationDate > '2020-08-15'」という式で `GetPartitions` リクエストを行います。 テーブルにパーティションインデックスが存在しない場合、AWS Glue では、テーブルのすべてのパーティションがロードされ、`GetPartitions` リクエストでユーザーが指定したクエリ式を使用してロードされたパーティションがフィルタリングされます。インデックスのないテーブルでパーティション数が増えると、クエリの実行に時間がかかります。インデックスを使用すると、`GetPartitions` クエリでは、テーブル内のすべてのパーティションをロードするのではなく、パーティションのサブセットを取得しようとします。 **Topics** + [パーティションインデックスについて](#partition-index-1) + [パーティションインデックスを持つテーブルの作成](#partition-index-creating-table) + [パーティションインデックスの既存テーブルへの追加](#partition-index-existing-table) + [テーブル上のパーティションインデックスの説明](#partition-index-describing) + [パーティションインデックスの使用に関する制限事項](#partition-index-limitations) + [GetPartitions 呼び出しを最適化するためのインデックスの使用](#partition-index-getpartitions) + [エンジンとの統合](#partition-index-integration-engines) ## パーティションインデックスについて パーティションインデックスを作成する際、指定したテーブルに既に存在するパーティションキーのリストを指定します。パーティションインデックスは、テーブルで定義されているパーティションキーのサブリストです。パーティションインデックスは、テーブルで定義されたパーティションキーを任意の順序にして作成できます。上記の sales\$1data テーブルでは、可能なインデックスには (国、カテゴリ、creationDate)、(国、カテゴリ、年)、(国、カテゴリ)、(国)、(カテゴリ、国、年、月) などがあります。 Data Catalog は、インデックスの作成時に指定された順序でパーティション値を連結します。インデックスは、テーブルに追加されたパーティションと整合して構築されます。インデックスは文字列 (string、char、varchar)、数値 (int、bigint、long、tinyint、smallint)、日付 (yyyy-MM-dd) の列タイプに対して作成できます。 **サポートされているデータ型** + Date – `YYYY-MM-DD` などの ISO 形式の日付。たとえば、`2020-08-15` の日付。この形式では、ハイフン (‐) を使用して年、月、日を区切ります。インデックス用の日付の許容範囲は、`0000-01-01` から `9999-12-31` までです。 + String – 一重引用符または二重引用符で囲まれた文字列リテラルです。 + Char – char(10) など、1 から 255 までの指定された長さを持つ固定長の文字データです。 + Varchar – varchar(10) など、1 から 65535 までの指定された長さを持つ可変長の文字データです。 + Numeric — int、bigint、long、tinyint、smallint 「Numeric」、「String」、「Date」データ型のインデックスは、=、>、>=、<、<=、演算子間をサポートします。インデックス作成ソリューションは現在、`AND` 論理演算子のみをサポートしています。「LIKE」、「IN」、「OR」、および「NOT」の演算子のある部分式は、インデックスを使用してフィルタリングする場合、この式では無視されます。無視された部分式のフィルタリングは、インデックスフィルタリングを適用した後にフェッチされたパーティションに対して行われます。 テーブルに追加されたパーティションごとに、対応するインデックス項目が作成されます。「n」個のパーティションを持つテーブルの場合、1 つのパーティションインデックスは「n」個のパーティションインデックス項目になります。同じテーブルの「m」個のパーティションインデックスは、「m\$1n」個のパーティションインデックス項目になります。各パーティションインデックス項目は、現在のデータカタログストレージの AWS Glue 料金ポリシーに従って課金されます。ストレージオブジェクトの料金の詳細については、「[AWS Glue の料金](https://aws.amazon.com/glue/pricing/)」を参照してください。 ## パーティションインデックスを持つテーブルの作成 テーブルの作成中にパーティションインデックスを作成できます。`CreateTable` リクエストは、[`PartitionIndex` オブジェクト](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-PartitionIndex)のリストを入力として指定します。1 つのテーブルには、最大 3 つのパーティションインデックスを作成できます。各パーティションインデックスには、テーブルに対して定義された名前と `partitionKeys` のリストが必要です。テーブル上に作成されたインデックスは、[`GetPartitionIndexes` API](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-GetPartitionIndexes) を使用してフェッチできます。 ## パーティションインデックスの既存テーブルへの追加 既存のテーブルにパーティションインデックスを追加するには、`CreatePartitionIndex` オペレーションを使用します。`CreatePartitionIndex` オペレーションごとに、1 つの `PartitionIndex` を作成できます。インデックスを追加しても、テーブルの可用性には影響しません。これは、インデックスの作成中もテーブルが使用可能になるためです。 追加されたパーティションのインデックスステータスが CREATING に設定され、インデックスデータの作成が開始されます。インデックスの作成プロセスが正常に終了すると、indexStatus は ACTIVE に更新され、プロセスが正常に終了しなかった場合、インデックスステータスは FAILED に更新されます。インデックスが作成できない理由は、複数あり得ます。`GetPartitionIndexes` オペレーションを使用して、障害の詳細を取得できます。考えられる障害は次のとおりです。 + ENCRYPTED\$1PARTITION\$1ERROR – 暗号化されたパーティションを持つテーブルでのインデックスの作成はサポートされていません。 + INVALID\$1PARTITION\$1TYPE\$1DATA\$1ERROR – `partitionKey` の値が対応する `partitionKey` データ型に対して有効な値でない場合に発生します。例えば、「int」データ型の `partitionKey` の値が「foo」の場合などです。 + MISSING\$1PARTITION\$1VALUE\$1ERROR – `indexedKey` の `partitionValue` がない場合に発生します。これは、テーブルのパーティション化に整合性がない場合に発生します。 + UNSUPPORTED\$1PARTITION\$1CHARACTER\$1ERROR – インデックス付きパーティションキーの値に「\$1u0000」、「\$1u0001」、または「\$1u0002」という文字が含まれている場合に発生します。 + INTERNAL\$1ERROR – インデックスの作成中に内部エラーが発生しました。 ## テーブル上のパーティションインデックスの説明 テーブル上に作成されたパーティションインデックスを取得するには、`GetPartitionIndexes` オペレーションを使用します。レスポンスとして、テーブル上のすべてのインデックスと、各インデックスの現在のステータス (`IndexStatus`) が返ります。 パーティションインデックスの `IndexStatus` は、次のいずれかになります。 + `CREATING` – インデックスは現在作成されていますが、まだ使用することはできません。 + `ACTIVE` – インデックスは、すぐに使用できます。リクエストにインデックスを使用して最適化されたクエリを実行できます。 + `DELETING` – インデックスは現在削除されているため、使用できなくなっています。アクティブ状態のインデックスは、`DeletePartitionIndex` リクエストを使用してステータスを ACTIVE から DELETING に移行することによって削除できます。 + `FAILED` – 既存のテーブルでインデックスの作成に失敗しました。失敗したインデックスは、直近の 10 個まで各テーブルに保存されます。 既存のテーブルで作成されたインデックスには、次のような状態遷移があり得ます。 + CREATING → ACTIVE → DELETING + CREATING → FAILED ## パーティションインデックスの使用に関する制限事項 パーティションインデックスを作成したら、テーブルとパーティションの機能に対する次の変更点に注意してください。 **新規パーティションの作成 (インデックス追加後)** テーブルにパーティションインデックスが作成されると、テーブルに追加されたすべての新しいパーティションは、インデックス付きキーのデータ型チェックのために検証されます。インデックス付きキーのパーティション値は、データ型形式について検証されます。データ型のチェックが失敗すると、パーティションの作成操作は失敗します。*sales\$1data* テーブルに対して、キー (カテゴリ、年) のインデックスが作成され、カテゴリの型が `string`、年の型が `int` の場合、YEAR の値が「foo」であれば、新しいパーティションの作成は失敗します。 インデックスを有効にすると、U\$10000、U\$100001、U\$10002 という文字を含むインデックス付きキー値のパーティションの追加が失敗するようになります。 **テーブルの更新** テーブル上にパーティションインデックスを作成すると、既存のパーティションキーのパーティションキー名を変更することはできません。また、インデックスに登録されているキーのタイプまたは順序を変更することはできません。 ## GetPartitions 呼び出しを最適化するためのインデックスの使用 インデックス付きテーブルで `GetPartitions` を呼び出すとき、式を含めることができます。また、適用可能な場合は、Data Catalogで、可能であればインデックスが使用されます。インデックスの最初のキーは、フィルタリングに使用されるインデックスの式に含めて渡す必要があります。フィルタリングのインデックスの最適化は、ベストエフォートとして適用されます。Data Catalog では、可能な限りインデックスの最適化を使用しようとしますが、インデックスが見つからない場合、またはサポートされていない演算子の場合は、すべてのパーティションをロードする既存の実装に戻します。 上記の *sales\$1data* テーブルには、[Country, Category, Year] (国、カテゴリ、年) のインデックスを追加できます。式に「Country」が渡されない場合、登録されたインデックスは、インデックスを使用したパーティションのフィルタリングができません。最大 3 つのインデックスを追加して、さまざまなクエリパターンをサポートできます。 いくつかの式を例に取り、そこでインデックスが機能する様子を示します。 | 表現 | インデックスの使用方法 | | --- | --- | | Country = 'US' | インデックスは、パーティションをフィルタリングするために使用されます。 | | Country = 'US' and Category = 'Shoes' | インデックスは、パーティションをフィルタリングするために使用されます。 | | Category = 'Shoes' | 式に「country」が指定されていないため、インデックスは使用されません。レスポンスを返すため、すべてのパーティションがロードされます。 | | Country = 'US' and Category = 'Shoes' and Year > '2018' | インデックスは、パーティションをフィルタリングするために使用されます。 | | Country = 'US' and Category = 'Shoes' and Year > '2018' and month = 2 | インデックスを使用して、「country = "US" and category = "shoes" and year > 2018」に該当するすべてのパーティションがフェッチされます。その後、月に関する式によるフィルタリングが実行されます。 | | Country = 'US' AND Category = 'Shoes' OR Year > '2018' | `OR` 演算子が式に存在するため、インデックスは使用されません。 | | Country = 'US' AND Category = 'Shoes' AND (Year = 2017 OR Year = '2018') | インデックスを使用して、「country = "US" and category = "shoes"」に該当するのすべてのパーティションがフェッチされ、その後、年に関する式によるフィルタリングが実行されます。 | | Country in ('US', 'UK') AND Category = 'Shoes' | `IN` 演算子は現在サポートされていないため、インデックスはフィルタリングに使用されません。 | | Country = 'US' AND Category in ('Shoes', 'Books') | インデックスを使用して、「country = "US"」に該当するのすべてのパーティションが取得され、その後、カテゴリに関する式によるフィルタリングが実行されます。 | | Country = 'US' AND Category in ('Shoes', 'Books') AND (creationDate > '2023-9-01' | 「creationDate > '2023-9-01'」に設定し、インデックスを使用して「country = "US"」に該当するすべてのパーティションをフェッチしたら、カテゴリの式にフィルタリングが実行されます。 | ## エンジンとの統合 Redshift Spectrum、Amazon EMR、および AWS Glue ETL Spark DataFrames は、インデックスが AWS Glue で ACTIVE 状態になった後にパーティションを取得するためにインデックスを利用できます。[Athena](https://docs.aws.amazon.com/athena/latest/ug/glue-best-practices.html#glue-best-practices-partition-index) と [AWS Glue ETL DynamicFrame](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-partitions.html#aws-glue-programming-etl-partitions-cat-predicates) では、クエリを向上させるためにインデックスを利用するには追加のステップに従う必要があります。 ### パーティションのフィルタリングの有効化 Athena でパーティションフィルタリングを有効にするには、テーブルのプロパティを次のように更新する必要があります。 1. AWS Glue コンソールで、**[データカタログ]** の **[テーブル]** を選択します。 1. テーブルを選択します。 1. **[アクション]** で **[テーブルの編集]** を選択します。 1. **[テーブルのプロパティ]** で、次の内容を追加します。 + キー – `partition_filtering.enabled` + 値 – `true` 1. **[Apply]** (適用) を選択します。 または、Athena で [ALTER TABLE SET PROPERTIES](https://docs.aws.amazon.com/athena/latest/ug/alter-table-set-tblproperties.html) クエリを実行してこのパラメータを設定することもできます。 ``` ALTER TABLE partition_index.table_with_index SET TBLPROPERTIES ('partition_filtering.enabled' = 'true') ``` ## クローラーを使用して手動で作成されたデータカタログテーブルを更新する 手動で AWS Glue Data Catalog テーブルを作成し、AWS Glue クローラーを使用して更新された状態を維持することもできます。スケジュールで実行されているクローラーは、新しいパーティションを追加して、スキーマの変更によりテーブルを更新できます。これは Apache Hive メタストアから移行されたテーブルにも適用されます。 これを行うには、クローラーを定義するときに、1 つ以上のデータストアをクロールのソースとして指定する代わりに、既存のデータカタログテーブルを 1 つ以上指定します。クローラーは、カタログテーブルで指定されたデータストアをクロールします。この場合、新しいテーブルは作成されず、手動で作成されたテーブルが更新されます。 以下に、カタログテーブルを手動で作成し、クローラーソースとしてカタログテーブルを指定するその他の理由を示します。 + カタログテーブル名命名アルゴリズムに依存せず、カタログテーブル名を選択することをお勧めします。 + パーティションの検出を中断する可能性がある形式のファイルが誤ってデータソースパスに保存されないように、新しいテーブルが作成されないようにする必要があります。 詳細については、「[ステップ 2: データソースと分類子を選択する](define-crawler-choose-data-sources.md)」を参照してください。 ## Data Catalog テーブルのプロパティ AWS CLI で知られているテーブルのプロパティ、つまりパラメータは無効なキーと値の文字列です。AWS Glue の外部での Data Catalog の使用をサポートする場合は、テーブルに独自のプロパティを設定します。この操作は、Data Catalog を使用する他のサービスでも行うことができます。AWS Glue がジョブまたはクローラーの実行時に一部のテーブルプロパティを設定します。特に説明がない限り、これらのプロパティは内部使用のためのものであり、現在の形式での存続や、これらのプロパティを手動で変更した場合の製品の動作についてはサポートされません。 AWS Glue クローラーで設定できるテーブルプロパティの詳細については、「[クローラーによって設定されたデータカタログテーブルのパラメータ](table-properties-crawler.md)」を参照してください。 # Amazon S3 Tables との統合 AWS Glue Data Catalog と Amazon S3 Tables の統合により、単一のカタログを使用して Amazon S3 データレイク内のデータの検出、クエリ、そのデータと S3 Tables との結合を行えます。S3 Tables を Data Catalog と統合すると、サービスは S3 Tables リソースを AWS Glue カタログオブジェクトにマッピングするフェデレーテッドカタログ構造を作成します。 + S3 テーブルバケットが Data Catalog のカタログになる + S3 名前空間が AWS Glue データベースになる + S3 テーブルが AWS Glue テーブルになる ## アクセス制御 Data Catalog は、S3 Tables 統合の 2 つのアクセスコントロールモードをサポートしています。 + **IAM アクセスコントロール** – IAM ポリシーを使用して、S3 Tables と Data Catalog へのアクセスを制御します。このアプローチでは、リソースにアクセスするには、S3 Tables リソースと Data Catalog オブジェクトの両方に対する IAM アクセス許可が必要です。 + **AWS Lake Formation アクセスコントロール** – Data Catalog を介した S3 Tables へのアクセスを制御するために、AWS Glue IAM アクセス許可に加えて AWS Lake Formation 許可を使用します。このモードでは、プリンシパルは Data Catalog を操作するための IAM アクセス許可を必要とし、プリンシパルがアクセスできるカタログリソース (データベース、テーブル、列、行) は AWS Lake Formation 許可によって決まります。このモードは、粗粒度のアクセスコントロール (データベースレベルとテーブルレベルの権限) ときめ細かなアクセスコントロール (列レベルと行レベルのセキュリティ) の両方をサポートします。登録されたロールが設定され、認証情報の払い出しが有効になっている場合、S3 Tables IAM アクセス許可はプリンシパルには必要ありません。これは、登録されたロールを使用してプリンシパルの代わりに AWS Lake Formation が認証情報を払い出すからです。AWS Lake Formation アクセスコントロールは、サードパーティーの分析エンジンの認証情報の払い出しもサポートしています。詳細については、「*AWS Lake Formation デベロッパーガイド*」の「[Creating an S3 Tables catalog](https://docs.aws.amazon.com/lake-formation/latest/dg/create-s3-tables-catalog.html)」(S3 Tables カタログの作成) を参照してください。 要件の進展に応じて、アクセスコントロールモード間で移行できます。 ## 自動マウント用のカタログ階層 Amazon S3 マネジメントコンソールを使用して S3 Tables を Data Catalog と統合すると、コンソールは、その AWS リージョンのアカウントの Data Catalog に `s3tablescatalog` というフェデレーテッドカタログを作成します。このフェデレーテッドカタログは、そのアカウントとリージョンのすべての既存および将来の S3 テーブルバケットの親カタログとして機能します。統合は、Amazon S3 Tables のバケットリソースを次の階層にマッピングします。 + **フェデレーテッドカタログ** – `s3tablescatalog` (自動作成) + **子カタログ** – 各 S3 テーブルバケットは `s3tablescatalog` の子カタログになります + **データベース** – テーブルバケット内の各 S3 名前空間がデータベースになります + **テーブル** – 名前空間内の各 S3 テーブルがテーブルになります たとえば、テーブル「transactions」を含む名前空間「sales」を持つ「analytics-bucket」という名前の S3 テーブルバケットがある場合、Data Catalog のフルパスは次のようになります。`s3tablescatalog/analytics-bucket/sales/transactions` この 4 つの階層は、S3 Tables と Data Catalog が同じ AWS アカウントにある同一アカウントシナリオに適用されます。クロスアカウントシナリオでは、Data Catalog に個々の S3 テーブルバケットを手動でマウントし、3 つの部分からなる階層を作成します。 ## サポート対象のリージョン S3 Tables と Data Catalog の統合は、次の AWS リージョンで利用できます。 | リージョンコード | リージョン名 | | --- | --- | | us–east–1 | 米国東部 (バージニア北部) | | us-east-2 | 米国東部 (オハイオ) | | us-west-1 | 米国西部 (北カリフォルニア) | | us-west-2 | 米国西部 (オレゴン) | | af-south-1 | アフリカ (ケープタウン) | | ap-east-1 | アジアパシフィック (香港) | | ap-east-2 | アジアパシフィック (台北) | | ap-northeast-1 | アジアパシフィック (東京) | | ap-northeast-2 | アジアパシフィック (ソウル) | | ap-northeast-3 | アジアパシフィック (大阪) | | ap-south-1 | アジアパシフィック (ムンバイ) | | ap-south-2 | アジアパシフィック (ハイデラバード) | | ap-southeast-1 | アジアパシフィック (シンガポール) | | ap-southeast-2 | アジアパシフィック (シドニー) | | ap-southeast-3 | アジアパシフィック (ジャカルタ) | | ap-southeast-4 | アジアパシフィック (メルボルン) | | ap-southeast-5 | アジアパシフィック (マレーシア) | | ap-southeast-6 | アジアパシフィック (ニュージーランド) | | ap-southeast-7 | アジアパシフィック (タイ) | | ca-central-1 | カナダ (中部) | | ca-west-1 | カナダ西部 (カルガリー) | | eu-central-1 | 欧州 (フランクフルト) | | eu-central-2 | 欧州 (チューリッヒ) | | eu-north-1 | 欧州 (ストックホルム) | | eu-south-1 | 欧州 (ミラノ) | | eu-south-2 | 欧州 (スペイン) | | eu-west-1 | 欧州 (アイルランド) | | eu-west-2 | 欧州 (ロンドン) | | eu-west-3 | 欧州 (パリ) | | il-central-1 | イスラエル (テルアビブ) | | mx-central-1 | メキシコ (中部) | | sa-east-1 | 南米（サンパウロ） | **Topics** + [アクセス制御](#s3-tables-access-controls) + [自動マウント用のカタログ階層](#s3-tables-catalog-hierarchy) + [サポート対象のリージョン](#s3-tables-supported-regions) + [前提条件](s3tables-catalog-prerequisites.md) + [S3 Tables と Data Catalog の統合の有効化](enable-s3-tables-catalog-integration.md) + [S3 Tables カタログへのデータベースとテーブルの追加](create-databases-tables-s3-catalog.md) + [S3 Tables カタログオブジェクトの共有](share-s3-tables-catalog.md) + [S3 Tables 統合の管理](manage-s3-tables-catalog-integration.md) # 前提条件 AWS Glue Data Catalog で S3 Tables のフェデレーテッドカタログを作成する前に、IAM プリンシパル (ユーザーまたはロール) に必要なアクセス許可があることを確認してください。 ## 必要な IAM 許可 S3 Tables 統合を有効にするには、IAM プリンシパルに次のアクセス許可が必要です。 **AWS Glue アクセス許可**: + `glue:CreateCatalog` – `s3tablescatalog` フェデレーテッドカタログの作成に必要です + `glue:GetCatalog` – カタログの詳細を表示するために必要です + `glue:GetDatabase` – S3 名前空間をデータベースとして表示するために必要です + `glue:GetTable` – S3 テーブルを表示するために必要です + `glue:passConnection` – 呼び出し元プリンシパルに対し、`aws:s3tables` 接続を AWS Glue サービスに委任する権限を付与します **S3 Tables アクセス許可** (IAM アクセスコントロール用): + `s3tables:CreateTableBucket` + `s3tables:GetTableBucket` + `s3tables:CreateNamespace` + `s3tables:GetNamespace` + `s3tables:ListNamespaces` + `s3tables:CreateTable` + `s3tables:GetTable` + `s3tables:ListTables` + `s3tables:UpdateTableMetadataLocation` + `s3tables:GetTableMetadataLocation` + `s3tables:GetTableData` + `s3tables:PutTableData` ## IAM ポリシーの例 次の IAM ポリシーは、IAM モードで S3 Tables と Data Catalog の統合を有効にするために必要な最小限のアクセス許可を提供します。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "GlueDataCatalogPermissions", "Effect": "Allow", "Action": [ "glue:CreateCatalog", "glue:GetCatalog", "glue:GetDatabase", "glue:GetTable" ], "Resource": [ "arn:aws:glue:region:account-id:catalog/s3tablescatalog", "arn:aws:glue:region:account-id:database/s3tablescatalog/*/*", "arn:aws:glue:region:account-id:table/s3tablescatalog/*/*/*" ] }, { "Sid": "S3TablesDataAccessPermissions", "Effect": "Allow", "Action": [ "s3tables:GetTableBucket", "s3tables:GetNamespace", "s3tables:GetTable", "s3tables:GetTableMetadataLocation", "s3tables:GetTableData" ], "Resource": [ "arn:aws:s3tables:region:account-id:bucket/*", "arn:aws:s3tables:region:account-id:bucket/*/table/*" ] } ] } ``` # S3 Tables と Data Catalog の統合の有効化 Amazon S3 マネジメントコンソールまたは AWS CLI を使用して、AWS Glue Data Catalog との S3 Tables 統合を有効にできます。コンソールを使用して統合を有効にすると、AWS は `s3tablescatalog` という名前のフェデレーテッドカタログを作成し、AWS アカウントとリージョン内のすべての S3 テーブルバケットを自動的に検出してマウントします。 ## Amazon S3 マネジメントコンソールを使用した S3 Tables 統合の有効化 1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。 1. 左側のナビゲーションペインで、**[テーブルバケット]** を選択します。 1. **[テーブルバケットを作成]** を選択します。 1. **テーブルバケット名**を入力します。**[統合を有効にする]** チェックボックスがオンになっていることを確認してください。 1. **[テーブルバケットを作成]** を選択します。 Amazon S3 は、そのリージョンでテーブルバケットを自動的に統合します。任意のリージョンでテーブルバケットを初めて統合すると、Amazon S3 はそのリージョンの Data Catalog に `s3tablescatalog`　を作成します。 カタログが作成されると、アカウントとリージョン内のすべての S3 テーブルバケットが子カタログとして自動的にマウントされます。データベース (名前空間) とテーブルを表示するには、Data Catalog のカタログに移動します。 ## AWS CLI を使用した S3 Tables 統合の有効化 `s3tablescatalog` カタログを作成するには、`glue create-catalog` コマンドを使用します。 ``` aws glue create-catalog \ --name "s3tablescatalog" \ --catalog-input '{ "Description": "Federated catalog for S3 Tables", "FederatedCatalog": { "Identifier": "arn:aws:s3tables:region:account-id:bucket/*", "ConnectionName": "aws:s3tables" }, "CreateDatabaseDefaultPermissions": [{ "Principal": { "DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS" }, "Permissions": ["ALL"] }], "CreateTableDefaultPermissions": [{ "Principal": { "DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS" }, "Permissions": ["ALL"] }] }' ``` *region* と *account-id* をお使いの AWS リージョンと AWS アカウント ID に置き換えます。 ## 統合の検証 カタログを作成したら、子カタログを一覧表示することで、S3 テーブルバケットがマウントされていることを確認できます。 ``` aws glue get-catalogs \ --parent-catalog-id s3tablescatalog ``` # S3 Tables カタログへのデータベースとテーブルの追加 リージョンの Data Catalog でカタログ、データベース、テーブルを一覧表示および作成するために必要なアクセス許可があることを確認します。AWS アカウントとリージョンで S3 Tables 統合が有効になっていることを確認します。 ## S3 Tables カタログへのデータベースの追加 ### データベースの追加 (コンソール) 1. [https://console.aws.amazon.com/glue/home](https://console.aws.amazon.com/glue/home) で AWS Glue コンソール を開きます。 1. 左のナビゲーションペインの **[データベース]** を選択します。 1. **[データベースの追加]** を選択します。 1. **[Glue Database in S3 Tables Federated Catalog]** (S3 Tables Federated Catalog の Glue データベース) を選択します。 1. データベースに一意の名前を入力します。 1. S3 Tables のテーブルバケットにマッピングするターゲットカタログを選択します。 1. **[Create Database]** (データベースの作成) を選択します。 ### データベースの追加 (AWS CLI) ``` aws glue create-database \ --region region \ --catalog-id "account-id:s3tablescatalog/my-catalog" \ --database-input '{"Name": "my-database"}' ``` ## S3 Tables カタログへのテーブルの追加 ### テーブルの追加 (コンソール) 1. [https://console.aws.amazon.com/glue/home](https://console.aws.amazon.com/glue/home) で AWS Glue コンソール を開きます。 1. 左のナビゲーションペインで、**[テーブル]** を選択します。 1. カタログドロップダウンで適切な S3 Tables カタログを選択します。 1. [**Add table**] (テーブルの追加) を選択します。 1. テーブルの一意の名前を入力します。 1. カタログドロップダウンで正しい S3 Tables カタログが選択されていることを確認します。 1. データベースドロップダウンでデータベースを選択します。 1. JSON を入力するか、各列を個別に追加して、テーブルスキーマを入力します。 1. **[テーブルの作成]** を選択します。 ### テーブルの追加 (AWS CLI) ``` aws glue create-table \ --region region \ --catalog-id "account-id:s3tablescatalog/my-catalog" \ --database-name "my-database" \ --table-input '{ "Name": "my-table", "Parameters": { "classification": "", "format": "ICEBERG" }, "StorageDescriptor": { "Columns": [ {"Name": "id", "Type": "int", "Parameters": {}}, {"Name": "val", "Type": "string", "Parameters": {}} ] } }' ``` # S3 Tables カタログオブジェクトの共有 IAM アクセスコントロールを使用する場合、同一アカウント共有の AWS Glue リソースリンクを使用して、S3 Tables カタログオブジェクトを他のユーザーと共有できます。クロスアカウント共有では、S3 テーブルバケットを別の AWS アカウントと共有でき、受信者アカウントの IAM ロールまたはユーザーは、共有テーブルバケットを使用して AWS Glue カタログオブジェクトを作成できます。 ## リソースリンクを使用した同一アカウント内での共有 リソースリンクを使用すると、AWS Glue デフォルトカタログに表示される `s3tablescatalog` の AWS Glue データベースとテーブルへの参照を作成できます。これは、データアクセスの整理やテーブルの論理グループの作成に役立ちます。 ### リソースリンクの作成 (コンソール) 1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/) で AWS Glue コンソール を開きます。 1. ナビゲーションペインで、**[カタログ]** を選択します。 1. **[カタログ]** リストで、**[s3tablescatalog]** を選択します。 1. `s3tablescatalog` から共有するテーブルを選択します。 1. **[アクション]** で、**[リソースリンクの作成]** を選択します。 1. **[リソースリンク名]** にリソースリンクの名前を入力します。 1. **[ターゲットデータベース]** で、リソースリンクを作成するデータベースを選択します。 1. (オプション) **[説明]** に説明を入力します。 1. **[作成]** を選択します。 リソースリンクはターゲットデータベースに表示され、`s3tablescatalog` の元のテーブルを指します。 ### リソースリンクの作成 (AWS CLI) データベースリソースリンクの作成: ``` aws glue create-database \ --database-name "my-database-resource-link" \ --database-input '{ "Name": "sales_data_link", "TargetDatabase": { "CatalogId": "account-id:s3tablescatalog/analytics-bucket", "DatabaseName": "sales" } }' ``` テーブルリソースリンクの作成: ``` aws glue create-table \ --table-name "my-table-resource-link" \ --table-input '{ "Name": "sales_data_link", "TargetTable": { "CatalogId": "account-id:s3tablescatalog/analytics-bucket", "DatabaseName": "sales", "Name": "transactions" } }' ``` # S3 Tables 統合の管理 ## AWS Lake Formation の有効化 データガバナンス要件をスケールする場合は、S3 Tables カタログで AWS Lake Formation を有効にできます。AWS Lake Formation には、きめ細かなアクセスを管理し、タグベースのアクセスを使用してアクセス許可をスケールし、S3 Tables のテーブルへのグループ関連付けなどのユーザー属性に基づいてアクセス許可を付与するデータベーススタイルの許可が用意されています。 AWS Lake Formation マネジメントコンソールに移動して、AWS Glue で S3 Tables カタログの AWS Lake Formation を有効にします。詳細については、「*AWS Lake Formation デベロッパーガイド*」の「[Creating an S3 Tables catalog](https://docs.aws.amazon.com/lake-formation/latest/dg/create-s3-tables-catalog.html)」(S3 Tables カタログの作成) を参照してください。 ## S3 Tables 統合の削除 Data Catalog でカタログ統合を削除することで、S3 Tables 統合を削除できます。このオペレーションは、Data Catalog 内のメタデータのみを削除し、S3 Tables のリソースは削除しません。 AWS Glue でカタログオブジェクトを一覧表示、編集、削除するために必要なアクセス許可があることを確認します。 ### 統合の削除 (コンソール) 1. [https://console.aws.amazon.com/glue/home](https://console.aws.amazon.com/glue/home) で AWS Glue コンソール を開きます。 1. ナビゲーションペインで、**[カタログ]** を選択します。 1. **[カタログ]** リストで、**[s3tablescatalog]** を選択します。 1. **[削除]** を選択します。 1. カタログを削除すると、Data Catalog 内の関連するカタログオブジェクトもすべて削除されることを確認します。 1. **[削除]** を選択します。 ### 統合の削除 (AWS CLI) ``` aws glue delete-catalog \ --region region \ --catalog-id "s3tablescatalog" ``` # 他の AWS のサービスとの統合 AWS Glue クローラー を使用して AWS Glue Data Catalog にデータを入力することもできますが、いくつかの AWS サービスではカタログに自動的に統合し、データを入力することができます。以下のセクションでは、データカタログに入力できる AWS サービスでサポートされる特定のユースケースについて詳しく説明します。 **Topics** + [AWS Lake Formation](#lf-dc) + [Amazon Athena](#ate-dc) ## AWS Lake Formation AWS Lake Formation は、AWS で簡単にセキュアなデータレイクを構築できるサービスです。Lake Formation は AWS Glue 上に構築され、Lake Formation と AWS Glue は同じ AWS Glue Data Catalog を共有します。Amazon S3 データロケーションを Lake Formation に登録し、Lake Formation コンソールを使用して、AWS Glue データカタログにデータベースとテーブルを作成し、データアクセスポリシーを定義し、データレイク全体のデータアクセスを一元的に監査できます。Lake Formation の細粒度のアクセスコントロールを使用して、既存のデータカタログリソースと Amazon S3 データロケーションを管理できます。 Lake Formation に登録されたデータを使用すると、IAM プリンシパル、AWS アカウント、AWS 組織、組織単位間でデータカタログリソースを安全に共有できます。 Lake Formation を使用したデータカタログリソースの作成の詳細については、AWS Lake Formation デベロッパーガイドの「[データカタログのテーブルとデータベースの作成](https://docs.aws.amazon.com/lake-formation/latest/dg/populating-catalog.html)」を参照してください。 ## Amazon Athena Amazon Athena は、AWS アカウントの Amazon S3 データに関するテーブルメタデータの保存と取得にデータカタログを使用します。テーブルメタデータは、Athena クエリエンジンがクエリするデータの検索、読み込み、および処理方法を把握できるようにします。 Athena `CREATE TABLE` ステートメントを直接使用して、AWS Glue Data Catalog にデータを入力できます。クローラーを実行することなく、データカタログでスキーマとパーティションメタデータを手動で定義してデータを入力できます。 1. Athena コンソールで、テーブルメタデータをデータカタログに保存するデータベースを作成します。 1. `CREATE EXTERNAL TABLE` ステートメントを使用して、データソースのスキーマを定義します。 1. データがパーティション化されている場合は、`PARTITIONED BY` 句を使用してパーティションキーを定義します。 1. `LOCATION` 句を使用して、実際のデータファイルを保存する Amazon S3 パスを指定します。 1. `CREATE TABLE` ステートメントを実行します。 このクエリは、実際にデータをクロールすることなく、定義したスキーマとパーティションに基づいてデータカタログにテーブルメタデータを作成します。 Athena でテーブルにクエリを実行すると、データカタログのメタデータを使用して Amazon S3 のデータファイルにアクセスしてクエリを実行できます。 詳細については、Amazon Athena ユーザーガイドの「[データベースとテーブルの作成](https://docs.aws.amazon.com/athena/latest/ug/work-with-data.html)」を参照してください。 # データカタログの設定 データカタログの設定には、アカウントのデータカタログに対する暗号化およびアクセス許可のオプションが含まれています。 ![\[このスクリーンショットは、データカタログの設定モーダルを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/data_catalog_settings.png) **Data Catalog のきめ細かなアクセスコントロールを変更するには** 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. 暗号化オプションを選択します。 + **メタデータの暗号化** – データカタログのメタデータを暗号化するには、このチェックボックスをオンにします。メタデータは、指定した AWS Key Management Service​ (AWS KMS) キーを使用して、保存時に暗号化されます。詳細については、「[Data Catalog の暗号化](encrypt-glue-data-catalog.md)」を参照してください。 + **接続パスワードの暗号化** – 接続を作成または更新する際、AWS Glue 接続オブジェクトのパスワードを暗号化するには、このチェックボックスをオンにします。パスワードは、指定した AWS KMS キーを使用して暗号化されます。パスワードが返ったら、暗号化されます。このオプションは、Data Catalog のすべての AWS Glue 接続のグローバル設定です。このチェックボックスをオフにしても、以前暗号化したパスワードは、作成または更新する際に使用したキーを使用して暗号化された状態に維持されます。AWS Glue 接続の詳細については、「[データへの接続](glue-connections.md)」を参照してください。 このオプションを有効にする場合は、AWS KMS キーを選択するか、[**キーの ARN を入力**] を選択して、キーの Amazon リソースネーム (ARN) を指定します。` arn:aws:kms:region:account-id:key/key-id ` の形式で ARN を入力します。` arn:aws:kms:region:account-id:alias/alias-name ` など、キーのエイリアスで ARN を指定することもできます。 **重要** このオプションが選択されている場合は、接続を作成または更新するユーザーまたはロールに、指定された KMS キーの `kms:Encrypt` アクセス許可が必要です。 詳細については、「[接続パスワードの暗号化](encrypt-connection-passwords.md)」を参照してください。 1. [**Settings**] (設定) をクリックして、[**Permissions**] (アクセス権限) エディタで、アカウントの Data Catalog のきめ細かなアクセスコントロールを変更するポリシーステートメントを追加します。一度に Data Catalog にアタッチできるポリシーは 1 つだけです。JSON リソースポリシーをこのコンソールに貼り付けることができます。詳細については、「[AWS Glue 内のリソースベースのポリシー](security_iam_service-with-iam.md#security_iam_service-with-iam-resource-based-policies)」を参照してください。 1. [**Save**] (保存) をクリックして、行った変更を含めて Data Catalog を更新します。 また、AWS Glue API オペレーションを使用して、リソースポリシーを格納、取得、削除できます。詳細については、「[AWS Glue のセキュリティ API](aws-glue-api-jobs-security.md)」を参照してください。 # トランザクションテーブルへのデータ入力と管理 [Apache Iceberg](https://iceberg.apache.org/)、[Apache Hudi](https://hudi.incubator.apache.org/)、および Linux Foundation [Delta Lake](https://delta.io/) は、Apache Spark で大規模なデータ分析とデータレイクワークロードを処理するために設計されたオープンソースのテーブル形式です。 次の方法を使用して、AWS Glue Data Catalog で Iceberg、Hudi、および Delta Lake の各テーブルにデータを入力できます。 + AWS Glue クローラー – AWS Glue クローラー は、Iceberg、Hudi、Delta Lake のテーブルメタデータを自動的に検出してデータカタログに入力できます。詳細については、「[クローラーを使用したデータカタログへの入力](add-crawler.md)」を参照してください。 + AWS Glue ETL ジョブ – ETL ジョブを作成して Iceberg、Hudi、Delta Lake の各テーブルにデータを書き込み、そのメタデータをデータカタログに入力できます。詳細については、「[AWS Glue ETL ジョブでのデータレイクフレームワークの使用](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-datalake-native-frameworks.html)」を参照してください。 + AWS Glue コンソール、AWS Lake Formationコンソール、AWS CLI または API – AWS Glue コンソール、Lake Formation コンソール、または API を使用して、データカタログに Iceberg テーブル定義を作成し、管理できます。 **Topics** + [Apache Iceberg テーブルの作成](#creating-iceberg-tables) + [Iceberg テーブルの最適化](table-optimizers.md) + [Iceberg テーブルのクエリパフォーマンスの最適化](iceberg-column-statistics.md) ## Apache Iceberg テーブルの作成 Amazon S3 に格納されたデータにより、AWS Glue Data Catalog で Apache Parquet データ形式を使用する Apache Iceberg テーブルを作成できます。Data Catalog のテーブルは、データストア内のデータを表すメタデータ定義です。デフォルトでは、AWS Glue は Iceberg v2 テーブルを作成します。v1 テーブルと v2 テーブルの違いについては、Apache Iceberg ドキュメントの「[形式バージョンの変更](https://iceberg.apache.org/spec/#appendix-e-format-version-changes)」を参照してください。 [Apache Iceberg](https://iceberg.apache.org/) は、非常に大規模な分析データセット用のオープンテーブル形式です。Iceberg では、スキーマの変更 (スキーマ進化とも呼ばれます) を簡単に行うことができます。つまり、基になるデータを中断することなく、データテーブルの列を追加、名前変更、または削除できます。Iceberg はデータのバージョニングもサポートしているため、データの変更を経時的に追跡できます。これにより、タイムトラベル機能が有効になるため、過去のバージョンのデータにアクセスしてクエリを実行し、更新と削除の間に行われたデータの変更を分析できます。 AWS Glue または Lake Formation コンソールあるいは AWS Glue API の `CreateTable` オペレーションを使用して、データカタログに Iceberg テーブルを作成することができます。詳細については、「[CreateTable アクション (Python: create\$1table)](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-CreateTable)」を参照してください。 Data Catalog に Iceberg テーブルを作成する場合、読み取りと書き込みを実行できるように、Amazon S3 でテーブル形式とメタデータファイルのパスを指定する必要があります。 Amazon S3 のデータロケーションを AWS Lake Formation に登録すると、Lake Formation を使用してきめ細かなアクセス制御の許可により Iceberg テーブルを保護できます。Amazon S3 のソースデータと、Lake Formation に登録されていないメタデータへのアクセスは、Amazon S3 および AWS Glue アクションの IAM アクセス許可ポリシーによって決定されます。詳細については、「[アクセス許可の管理](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-permissions.html)」を参照してください。 **注記** Data Catalog は、パーティションの作成と Iceberg テーブルプロパティの追加をサポートしていません。 ### 前提条件 Data Catalog に Iceberg テーブルを作成し、Lake Formation のデータアクセス許可を設定するには、次の要件を満たす必要があります。 1. **Lake Formation にデータが登録されていない状態で Iceberg テーブルを作成するために必要なアクセス許可。** Data Catalog にテーブルを作成するために必要なアクセス許可に加えて、テーブル作成者には次のアクセス許可が必要です。 + リソース arn:aws:s3:::\$1bucketName\$1 での `s3:PutObject` + リソース arn:aws:s3:::\$1bucketName\$1 での `s3:GetObject` + リソース arn:aws:s3:::\$1bucketName\$1 での `s3:DeleteObject` 1. **Lake Formation にデータが登録されている状態で Iceberg テーブルを作成するために必要なアクセス許可:** Lake Formation を使用してデータレイク内のデータを管理および保護するには、テーブルのデータを含む Amazon S3 ロケーションを Lake Formation に登録します。これは、Lake Formation が Athena、Redshift Spectrum、Amazon EMR などの AWS 分析サービスに認証情報を提供して、データにアクセスできるようにするためです。Amazon S3 ロケーションの登録の詳細については、「[データレイクへの Amazon S3 ロケーションの追加](https://docs.aws.amazon.com/lake-formation/latest/dg/register-data-lake.html)」を参照してください。 Lake Formation に登録されている、基盤となるデータを読み書きするプリンシパルには、次のアクセス許可が必要です。 + `lakeformation:GetDataAccess` + `DATA_LOCATION_ACCESS` ロケーションに対するデータロケーション許可を持つプリンシパルは、すべての子ロケーションに対するロケーション許可も持っています。 データロケーション許可の詳細については、「[基盤となるデータのアクセスコントロール](https://docs.aws.amazon.com/lake-formation/latest/dg/access-control-underlying-data.html#data-location-permissions)」を参照してください。 圧縮を有効にするには、Data Catalog 内のテーブルを更新するアクセス許可を持つ IAM ロールを、サービスが引き受ける必要があります。詳細については、「[テーブル最適化の前提条件](optimization-prerequisites.md)」を参照してください。 ### Iceberg テーブルの作成 このページに記載されているように、AWS Glue または Lake Formation コンソールあるいは AWS Command Line Interface を使用して Iceberg v1 および v2 テーブルを作成できます。AWS Glue クローラー を使用して Iceberg テーブルを作成することもできます。詳細については、「AWS Glue デベロッパーガイド」の「[Data Catalog とクローラー](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)」を参照してください。 **Iceberg テーブルを作成するには** ------ #### [ Console ] 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. Data Catalog で **[テーブル]** を選択し、**[テーブルの作成]** ボタンを使用して次の属性を指定します。 + **テーブル名** - テーブルの名前を入力します。Athena を使用してテーブルにアクセスする場合は、「Amazon Athena ユーザーガイド」の[命名に関するヒント](https://docs.aws.amazon.com/athena/latest/ug/tables-databases-columns-names.html)を使用します。 + **データベース** - 既存のデータベースを選択するか、新しいデータベースを作成します。 + **説明** - テーブルの説明。テーブルの内容を理解しやすくするために説明を記入できます。 + **テーブル形式** - **[テーブル形式]** として、[Apache Iceberg] を選択します。 + **圧縮を有効にする** - **[圧縮を有効にする]** を選択すると、テーブル内の小さな Amazon S3 オブジェクトが圧縮されてより大きなオブジェクトにまとめられます。 + **IAM ロール**:- 圧縮を実行する場合、サービスはユーザーに代わって IAM ロールを引き受けます。IAM ロールは、ドロップダウンを使用して選択できます。圧縮を有効にするために必要なアクセス許可がロールにあることを確認します。 必要なアクセス許可の詳細については、「[テーブル最適化の前提条件](optimization-prerequisites.md)」を参照してください。 + **ロケーション** - メタデータテーブルを保存する Amazon S3 内のフォルダへのパスを指定します。Iceberg が読み取りと書き込みを実行するには、メタデータファイルと Data Catalog 内のロケーションが必要です。 + **スキーマ** - **[列の追加]** を選択して、列と、列のデータ型を追加します。空のテーブルを作成して、後でスキーマを更新することもできます。Data Catalog は Hive データ型をサポートしています。詳細については、「[Hive データ型](https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=27838462#content/view/27838462)」を参照してください。 Iceberg では、テーブルを作成した後でスキーマとパーティションを進化させることができます。[[Athena クエリ]](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-evolving-table-schema.html) を使用してテーブルスキーマを更新し、[[Spark クエリ]](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions) を使用してパーティションを更新できます。 ------ #### [ AWS CLI ] ``` aws glue create-table \ --database-name iceberg-db \ --region us-west-2 \ --open-table-format-input '{ "IcebergInput": { "MetadataOperation": "CREATE", "Version": "2" } }' \ --table-input '{"Name":"test-iceberg-input-demo", "TableType": "EXTERNAL_TABLE", "StorageDescriptor":{ "Columns":[ {"Name":"col1", "Type":"int"}, {"Name":"col2", "Type":"int"}, {"Name":"col3", "Type":"string"} ], "Location":"s3://DOC_EXAMPLE_BUCKET_ICEBERG/" } }' ``` ------ **Topics** + [前提条件](#iceberg-prerequisites) + [Iceberg テーブルの作成](#create-iceberg-table) # Iceberg テーブルの最適化 AWS Glue は、AWS 分析エンジンと ETL ジョブで使用される Apache Iceberg テーブルの管理とパフォーマンスを強化するための複数のテーブル最適化オプションをサポートしています。これらのオプティマイザーは、効率的なストレージの使用量、クエリパフォーマンスの向上、効率的なデータ管理を実現します。AWS Glue では、次の 3 種類のテーブルオプティマイザーを使用できます。 + **圧縮 **— データ圧縮では小さなデータファイルを圧縮して、ストレージの使用量を減らし、読み取りパフォーマンスを向上させます。古いデータを削除して、フラグメント化されたデータをより大規模で効率的なファイルに統合するために、データファイルはマージされ、書き換えられます。圧縮を自動的に実行するように設定できます。 Binpack は Apache Iceberg のデフォルト圧縮戦略です。より小さなデータファイルをより大きなデータファイルに結合し、最適なパフォーマンスを実現します。圧縮は、同様のデータをクラスター化する Sort 戦略と Z-order 戦略もサポートしています。Sort は、指定された列に基づいてデータを整理し、フィルタリングされた操作のクエリパフォーマンスを向上させます。Z-order は、複数の列を同時にクエリするときにクエリパフォーマンスを向上させるソートされたデータセットを作成します。binpack、sort、Z-order の 3 つの圧縮戦略はすべて、クエリエンジンによってスキャンされるデータ量を減らし、クエリ処理コストを削減します。 + **スナップショット保持** - スナップショットは、Iceberg テーブルのタイムスタンプ付きバージョンです。スナップショット保持設定を使用すると、スナップショットを保持する期間と保持するスナップショットの数を強制できます。スナップショット保持オプティマイザーを設定すると、古い不要なスナップショットと、その基になる関連付けられたファイルを削除して、ストレージのオーバーヘッドを管理できます。 + **孤立ファイルの削除** — 孤立ファイルは、Iceberg テーブルメタデータによって参照されなくなったファイルです。これらのファイルは、特にテーブルの削除や ETL ジョブの失敗などのオペレーションの後、時間の経過と共に蓄積される可能性があります。孤立ファイルの削除を有効にすると、AWS Glue はこれらの不要なファイルを定期的に特定して削除できるため、ストレージが解放されます。 カタログレベルの最適化設定は、Lake Formation コンソールと AWS Glue `UpdateCatalog` API 操作を介して使用できます。圧縮、スナップショット保持、孤立ファイル削除の各オプティマイザーは、AWS Glue コンソール、AWS CLI、または AWS Glue API オペレーションを使用して、データカタログ内の個々の Iceberg テーブルに対して有効または無効にすることができます。 次の動画は、データカタログで Iceberg テーブルのオプティマイザを設定する方法を示しています。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/xOXE7AS-pNA?si=lKvt_TSlPkoc6OXn/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/xOXE7AS-pNA?si=lKvt_TSlPkoc6OXn) **Topics** + [テーブル最適化の前提条件](optimization-prerequisites.md) + [カタログレベルのテーブルオプティマイザー](catalog-level-optimizers.md) + [圧縮の最適化](compaction-management.md) + [スナップショット保持の最適化](snapshot-retention-management.md) + [孤立ファイルの削除](orphan-file-deletion.md) + [最適化の詳細の表示](view-optimization-status.md) + [Amazon CloudWatch メトリクスの表示](view-optimization-metrics.md) + [オプティマイザーの削除](delete-optimizer.md) + [考慮事項と制限事項](optimizer-notes.md) + [テーブルオプティマイザーがサポートされているリージョン](regions-optimizers.md) # テーブル最適化の前提条件 テーブルオプティマイザーは、テーブルの最適化オプション (圧縮、スナップショット保持、孤立ファイル削除) を有効にする際に指定する AWS Identity and Access Management (IAM) ロールの許可を引き受けます。すべてのオプティマイザーに対して単一のロールを作成することも、オプティマイザーごとに個別のロールを作成することもできます。 **注記** 孤立ファイル削除オプティマイザには、`glue:updateTable` または `s3:putObject` アクセス許可は必要ありません。スナップショットの有効期限と圧縮オプティマイザには、同じアクセス許可セットが必要です。 IAM ロールには、データカタログ内のデータを読み取ったり、メタデータを更新したりするための許可が必要です。IAM ロールを作成し、次のインラインポリシーをアタッチできます。 + AWS Lake Formation に登録されていないデータの場所に対する Amazon S3 の読み取り/書き込み許可を付与する次のインラインポリシーを追加します。このポリシーには、データカタログ内のテーブルを更新するための許可、および AWS Glue が Amazon CloudWatch ログにログを追加したり、メトリクスを公開したりするのを許可するための許可も含まれています。Lake Formation に登録されていない Amazon S3 のソースデータへのアクセスは、Amazon S3 および AWS Glue アクションの IAM アクセス許可ポリシーによって決定されます。 次のインラインポリシーでは、`bucket-name` を Amazon S3 バケット名、`aws-account-id` および `region` をデータカタログの有効な AWS アカウント番号およびリージョン、`database_name` をデータベース名、`table_name` をテーブル名に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ] }, { "Effect": "Allow", "Action": [ "glue:UpdateTable", "glue:GetTable" ], "Resource": [ "arn:aws:glue:us-east-1:111122223333:table//", "arn:aws:glue:us-east-1:111122223333:database/", "arn:aws:glue:us-east-1:111122223333:catalog" ] }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:us-east-1:111122223333:log-group:/aws-glue/iceberg-compaction/logs:*", "arn:aws:logs:us-east-1:111122223333:log-group:/aws-glue/iceberg-retention/logs:*", "arn:aws:logs:us-east-1:111122223333:log-group:/aws-glue/iceberg-orphan-file-deletion/logs:*" ] } ] } ``` ------ + 次のポリシーを使用して、Lake Formation に登録されたデータの圧縮を有効にします。 テーブルに対する `IAM_ALLOWED_PRINCIPALS` グループアクセス許可が最適化ロールに付与されていない場合、ロールにはテーブルに対する Lake Formation の `ALTER`、`DESCRIBE`、`INSERT`、および `DELETE` アクセス許可が必要です。 Lake Formation に Amazon S3 バケットを登録する方法の詳細については、「[データレイクへの Amazon S3 ロケーションの追加](https://docs.aws.amazon.com/lake-formation/latest/dg/register-data-lake.html)」を参照してください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:UpdateTable", "glue:GetTable" ], "Resource": [ "arn:aws:glue:us-east-1:111122223333:table/databaseName/tableName", "arn:aws:glue:us-east-1:111122223333:database/databaseName", "arn:aws:glue:us-east-1:111122223333:catalog" ] }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:us-east-1:111122223333:log-group:/aws-glue/iceberg-compaction/logs:*", "arn:aws:logs:us-east-1:111122223333:log-group:/aws-glue/iceberg-retention/logs:*", "arn:aws:logs:us-east-1:111122223333:log-group:/aws-glue/iceberg-orphan-file-deletion/logs:*" ] } ] } ``` ------ + (オプション) [サーバー側の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)を使用して暗号化された Amazon S3 バケットにデータがある Iceberg テーブルを最適化するには、圧縮ロールに Amazon S3 オブジェクトを復号して、暗号化されたバケットにオブジェクトを書き込むための新しいデータキーを生成するアクセス許可が必要です。次のポリシーを目的の AWS KMS キーに追加します。バケットレベルの暗号化のみがサポートされています。 ``` { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:::role/" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*" } ``` + (オプション) Lake Formation で登録されたデータの場所については、場所を登録するために使用されるロールには、Amazon S3 オブジェクトを復号したり、暗号化されたバケットにオブジェクトを書き込むための新しいデータキーを生成したりする許可が必要です。詳細については、「[暗号化された Amazon S3 の場所の登録](https://docs.aws.amazon.com/lake-formation/latest/dg/register-encrypted.html)」を参照してください。 + (オプション) AWS KMS キーが別の AWS アカウントに保存されている場合は、圧縮ロールに次のアクセス許可を含める必要があります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:us-east-1:111122223333:key/key-id" ] } ] } ``` ------ + 圧縮を実行するために使用するロールには、そのロールに対する `iam:PassRole` アクセス許可が必要です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/" ] } ] } ``` ------ + 圧縮プロセスを実行する IAM ロールを引き受けるには、次の信頼ポリシーを AWS Glue サービスのロールに追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "glue.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ + (オプション) データカタログの設定を更新してカタログレベルのテーブル最適化を有効にするには、使用する IAM ロールに、ルートカタログに対する `glue:UpdateCatalog` アクセス許可または AWS Lake Formation `ALTER CATALOG` アクセス許可が必要になります。カタログのプロパティは、`GetCatalog` API を使用して確認できます。 # カタログレベルのテーブルオプティマイザー 1 回限りのカタログ設定では、AWS Glue Data Catalog にあるすべての新規および更新された Apache Iceberg テーブルに対して、圧縮、スナップショット保持、孤立ファイル削除などの自動オプティマイザーを設定できます。カタログレベルのオプティマイザー設定を使用すると、カタログ内のすべてのテーブルに一貫したオプティマイザー設定を適用できるため、テーブルごとにオプティマイザーを個別に設定する必要がなくなります。 データレイクの管理者は、Lake Formation コンソールでデフォルトのカタログを選択し、`Table optimization` オプションを使用してオプティマイザーを有効にすることで、統計の生成を設定できます。Data Catalog で新しいテーブルを作成したり、既存のテーブルを更新したりすると、Data Catalog はテーブルの最適化を自動的に実行して運用上の負担を軽減します。 テーブルレベルで最適化を設定した場合、またはテーブルのテーブル最適化設定を以前に削除した場合、それらのテーブル固有の設定は、テーブル最適化のデフォルトのカタログ設定よりも優先されます。設定パラメータがテーブルレベルまたはカタログレベルで定義されていない場合、Iceberg テーブルプロパティ値が適用されます。この設定は、スナップショットの保持および孤立ファイルの削除オプティマイザーに適用されます。 カタログレベルのオプティマイザーを有効にするときは、次の点を考慮してください。 + カタログの作成時に最適化設定を行い、その後 Update Catalog リクエストを通じて最適化を無効にすると、オペレーションはカタログ内のすべてのテーブルにカスケードします。 + 特定のテーブルにオプティマイザーを既に設定している場合、カタログレベルで無効化オペレーションを行ってもこのテーブルには影響しません。 + カタログレベルでオプティマイザーを無効にすると、既存のオプティマイザー設定を持つテーブルは特定の設定を維持し、カタログレベルの変更の影響を受けません。ただし、独自のオプティマイザー設定がないテーブルは、カタログレベルから無効状態を継承します。 + スナップショット保持オプティマイザーと孤立ファイル削除オプティマイザーはスケジュールベースであるため、更新によりスケジュールの開始がランダムに遅延します。これにより、各オプティマイザーがわずかに異なる時間に開始され、負荷が分散されるため、サービス制限を超える可能性が低くなります。 + AWS Glue Data Catalog 暗号化が有効になっている場合、カタログレベルのオプティマイザ設定はテーブルによって自動的に継承されません。カタログでメタデータ暗号化が有効になっている場合は、テーブルオプティマイザをテーブルごとに個別に設定する必要があります。カタログレベルのオプティマイザ継承を使用するには、カタログでメタデータ暗号化を無効にする必要があります。 **Topics** + [カタログレベルの自動テーブル最適化の有効化](enable-auto-table-optimizers.md) + [カタログレベルの最適化の表示](view-catalog-optimizations.md) + [カタログレベルのテーブル最適化の無効化](disable-auto-table-optimizers.md) # カタログレベルの自動テーブル最適化の有効化 データカタログ内のすべての新しい Apache Iceberg テーブルの自動テーブル最適化を有効にできます。テーブルを作成すると、テーブル最適化の設定を手動で明示的に更新することもできます。 データカタログの設定を更新してカタログレベルのテーブル最適化を有効にするには、使用する IAM ロールに、ルートカタログに対する `glue:UpdateCatalog` アクセス許可が必要になります。カタログのプロパティは、`GetCatalog` API を使用して確認できます。 Lake Formation マネージドテーブルの場合、カタログ最適化設定中に選択した IAM ロールには、新しいテーブルまたは更新されたテーブルに対する Lake Formation `ALTER`、`DESCRIBE`、`INSERT`、および `DELETE` のアクセス許可が必要です。 ## カタログレベルのオプティマイザーを有効にするには (コンソール) 1. Lake Formation コンソール (‭‬[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)‬) を開きます。 1. ナビゲーションペインで、**[データカタログ]** を選択します。 1. **[カタログ]** タブを選択します。 1. アカウントレベルのカタログを選択します。 1. **[テーブルの最適化]** タブで、**[テーブルの最適化]**、**[編集]** を選択します。また、**[アクション]** で **[最適化を編集]** を選択することもできます。 ![\[このスクリーンショットは、カタログレベルで最適化を有効にする編集オプションを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/catalog-edit-optimizations.png) 1. **[テーブルの最適化]** ページで、次のオプションを設定します。 ![\[このスクリーンショットは、カタログレベルの最適化オプションを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/catalog-optimization-options.png) 1. **[圧縮]** 設定を構成する: + 圧縮を有効または無効にします。 + オプティマイザーを実行するために必要なアクセス許可を持つ IAM ロールを選択します。 IAM ロールに必須のアクセス許可の詳細については、「[テーブル最適化の前提条件](optimization-prerequisites.md)」を参照してください。 1. **[スナップショットの保持]** 設定を構成する： + 保持を有効または無効にします。 + スナップショットの保持期間を日単位で設定します。デフォルトは 5 日です。 + 保持するスナップショットの数を設定します。デフォルトはスナップショット 1 個です。 + 期限切れファイルのクリーニングを有効または無効にします。 1. **[孤立ファイルの削除]** 設定を構成する： + 孤立ファイルの削除を有効または無効にします。 + 孤立ファイルの保持期間を日単位で設定します。デフォルトは 3 日です。 1. **[保存]** を選択します。 ## AWS CLI によるカタログレベルのオプティマイザーの有効化 次の CLI コマンドを使用して、オプティマイザー設定で既存のカタログを更新します。 **Example オプティマイザー設定でカタログを更新する** ``` aws glue update-catalog \ --name catalog-id \ --catalog-input \ '{ "CatalogId": "111122223333", "CatalogInput": { "CatalogProperties": { "CustomProperties": { "ColumnStatistics.Enabled": "false", "ColumnStatistics.RoleArn": "arn:aws:iam::111122223333:role/service-role/stats-role-name" }, "IcebergOptimizationProperties": { "RoleArn": "arn:aws:iam::111122223333:role/optimizer-role-name", "Compaction": { "enabled": "true" }, "Retention": { "enabled": "true", "snapshotRetentionPeriodInDays": "10", "numberOfSnapshotsToRetain": "5", "cleanExpiredFiles": "true" }, "OrphanFileDeletion": { "enabled": "true", "orphanFileRetentionPeriodInDays": "3" } } } } }' ``` カタログレベルのオプティマイザーで問題が発生した場合は、以下を確認してください。 + 前提条件セクションで説明されているように、IAM ロールに正しいアクセス許可が付与されていることを確認します。 + オプティマイザーオペレーションに関連するエラーメッセージがないか CloudWatch ログを確認します。 詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[使用可能なメトリクスを表示する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html)」を参照してください。 + カタログ設定を確認して、カタログ設定が正常に適用されたことを確認します。 + テーブルアクセスの失敗については、CloudWatch ログと EventBridge 通知で詳細なエラー情報を確認してください。 # カタログレベルの最適化の表示 カタログレベルのテーブル最適化が有効になっている場合、Apache Iceberg テーブルが、AWS マネジメントコンソール、SDK、AWS Glue クローラー のいずれかで `CreateTable` または `UpdateTable` API を介して作成または更新されるたびに、そのテーブルに対して同等のテーブルレベルの設定が作成されます。 テーブルを作成または更新したら、テーブルの詳細を検証してテーブル最適化を確定できます。`Table optimization` では、`Configuration source` プロパティが `Catalog` に設定されているところを示しています。 ![\[カタログレベルの最適化設定を持つ Apache Iceberg テーブルのイメージが適用されました。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/catalog-optimization-enabled.png) # カタログレベルのテーブル最適化の無効化 AWS Lake Formation コンソールと `glue:UpdateCatalog` API を使用して、新しいテーブルのテーブル最適化を無効にすることができます。 **カタログレベルでテーブルの最適化を無効にするには** 1. Lake Formation コンソール (‭‬[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)‬) を開きます。 1. 左のナビゲーションペインで **[カタログ]** を選択します。 1. **[カタログの概要]** ページの **[テーブルの最適化]** で **[編集]** を選択します。 1. **[最適化の編集]**ページで、**[最適化オプション]** の選択を解除します。 1. **[保存]** を選択します。 # 圧縮の最適化 Apache Iceberg などのオープンテーブル形式を使用する Amazon S3 データレイクは、データを S3 オブジェクトとして保存します。データレイクテーブルに数千の小さな Amazon S3 オブジェクトがある場合、メタデータのオーバーヘッドが増加し、読み取りパフォーマンスに悪影響が及びます。AWS Glue Data Catalog は Iceberg テーブル用のマネージド圧縮を提供し、小さなオブジェクトを圧縮してより大きなオブジェクトにまとめ、Amazon Athena、Amazon EMR、AWS Glue ETL ジョブなどの AWS 分析サービスによる読み取りパフォーマンスを向上させます。データカタログは、同時クエリに支障をきたすことなく圧縮を実行し、Parquet 形式のテーブルに対してのみ圧縮をサポートしています。 テーブルオプティマイザは、テーブルパーティションを継続的にモニタリングして、ファイル数とファイルサイズがしきい値を超えたときに圧縮プロセスを開始します。 データカタログでは、テーブル、またはそのいずれかのパーティションに 100 個を超えるファイルがある場合、圧縮プロセスが開始されます。各ファイルは、ターゲットのファイルサイズの 75% 未満である必要があります。ターゲットファイルサイズは、`write.target-file-size-bytes` テーブルプロパティによって定義されます。明示的に設定されていない場合、このプロパティはデフォルトで 512 MB に設定されます。 制限事項については、「[マネージドデータ圧縮でサポートされる形式と制限事項](optimizer-notes.md#compaction-notes)」を参照してください。 **Topics** + [圧縮オプティマイザの有効化](enable-compaction.md) + [圧縮オプティマイザの無効化](disable-compaction.md) # 圧縮オプティマイザの有効化 AWS Glue コンソール、AWS CLI、または AWS API を使用して、AWS Glue データカタログ内の Apache Iceberg テーブルの圧縮を有効にすることができます。新しいテーブルの場合は、テーブル形式として Apache Iceberg を選択し、テーブルの作成時に圧縮を有効にすることができます。圧縮は、新しいテーブルのためにデフォルトで無効になっています。 ------ #### [ Console ] **圧縮を有効にするには** 1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/) で AWS Glue コンソールを開き、データレイク管理者、テーブル作成者、またはテーブルに対する `glue:UpdateTable` および `lakeformation:GetDataAccess` の許可を付与されたユーザーとしてサインインします。 1. ナビゲーションペインの **[データカタログ]** で **[テーブル]** を選択します。 1. **[テーブル]** ページで、圧縮を有効にするオープンテーブル形式のテーブルを選択し、**[アクション]** メニューで **[最適化]**、**[有効にする]** を選択します。 **[テーブルの詳細]** ページで **[テーブルの最適化]** タブを選択して、圧縮を有効にすることもできます。ページの下部にある **[テーブル最適化]** タブを選択し、**[圧縮を有効にする]** を選択します。 **[最適化を有効にする]** オプションは、データカタログで新しい Iceberg テーブルを作成するときにも使用できます。 1. **[最適化を有効にする]** ページで、**[テーブル最適化オプション]** の **[圧縮]** を選択します。 ![\[[圧縮を有効にする] オプションを示す Apache Iceberg の [テーブルの詳細] ページ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/table-enable-compaction.png) 1. 次に、[テーブル最適化の前提条件](optimization-prerequisites.md) セクションに表示されたアクセス許可を持つ IAM ロールをドロップダウンから選択します。 また、**[新しい IAM ロールを作成]** オプションを選択して、圧縮の実行に必要なアクセス許可を持つカスタムロールを作成することもできます。 以下の手順に従って、既存の IAM ロールを更新します。 1. IAM ロールの許可ポリシーを更新するには、IAM コンソールで、圧縮の実行に使用されている IAM ロールにアクセスします。 1. **[アクセス許可の追加]** セクションで、[ポリシーの作成] を選択します。新しく開いたブラウザウィンドウで、ロールで使用する新しいポリシーを作成します。 1. [ポリシーの作成] ページで、[`JSON`] タブを選択します。前提条件に示している JSON コードをポリシーエディタフィールドにコピーします。 1. Iceberg テーブルオプティマイザーが、特定の仮想プライベートクラウド (VPC) から Amazon S3 バケットにアクセスする必要があるセキュリティポリシー設定がある場合は、AWS Glue ネットワーク接続を作成するか、既存のバケットを使用します。 AWS Glue VPC 接続をまだ設定していない場合は、AWS Glue コンソールまたは AWS CLI/SDK を使用して[コネクタ用の接続を作成する](https://docs.aws.amazon.com/glue/latest/dg/creating-connections.html)セクションの手順に従って、新しい接続を作成します。 1. 圧縮戦略を選択します。次のオプションを使用できます。 + **Binpack** – Binpack は Apache Iceberg のデフォルト圧縮戦略です。より小さなデータファイルをより大きなデータファイルに結合し、最適なパフォーマンスを実現します。 + **Sort** – Apache Iceberg でのソートは、指定された列に基づいてファイル内の情報をクラスター化するデータ整理手法であり、処理する必要があるファイルの数を減らすことでクエリのパフォーマンスを大幅に向上させます。ソート順序フィールドを使用して Iceberg のメタデータでソート順序を定義し、複数の列を指定すると、ソート順序で列が表示される順序でデータがソートされ、同様の値を持つレコードがファイル内にまとめて保存されます。ソート圧縮戦略では、パーティション内のすべてのファイル間でデータをソートすることで、最適化をさらに進めます。 + **Z-order** – Z-order は、重要度が同じ複数の列でソートする必要がある場合にデータを整理する方法です。1 つの列を他の列よりも優先する従来のソートとは異なり、Z-order は各列にバランスの取れた重みを与えるため、データを検索するときにクエリエンジンが読み取るファイルが少なくなります。 この手法は、異なる列の値の二進桁を組み合わせることによって機能します。例えば、2 つの列に数字 3 と 4 がある場合、Z-order は最初にそれらを二進数 (3 が 011 になり、4 が 100 になります) に変換し、これらの数字をインターリーブして新しい値 011010 を作成します。このインターリーブにより、関連するデータを物理的に近づけるパターンが作成されます。 Z-order は、多次元クエリに特に効果的です。例えば、収入、州、郵便番号で Z-order に並べられた顧客テーブルは、複数のディメンションをまたいでクエリする場合の階層ソートと比較して、優れたパフォーマンスを実現できます。このように整理することで、収入と地理的位置の特定の組み合わせをターゲットとするクエリを使用して、不要なファイルスキャンを最小限に抑えながら、関連するデータをすばやく見つけることができます。 1. **最小入力ファイル **– 圧縮がトリガーされる前にパーティションで必要なデータファイルの数。 1. **削除ファイルのしきい値** – データファイルが圧縮対象になる前に、データファイルで必要な最小の削除操作。 1. **[最適化を有効にする]** を選択します。 ------ #### [ AWS CLI ] 次の例は、圧縮を有効にする方法を示しています。アカウント ID を有効な AWS アカウント ID に置き換えます。データベース名とテーブル名を実際の Iceberg テーブル名とデータベース名に置き換えます。`roleArn` を、圧縮の実行に必要なアクセス許可を持つ IAM ロールの ARN (AWSリソースネーム) と IAM ロールの名前に置き換えます。圧縮戦略 `sort` は、`z-order` や `binpack` などサポートされている他の戦略に置き換えることができます。 要件に応じて順序を設定します。 ``` aws glue create-table-optimizer \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name iceberg_table \ --table-optimizer-configuration '{ "roleArn": "arn:aws:iam::123456789012:role/optimizer_role", "enabled": true, "vpcConfiguration": {"glueConnectionName": "glue_connection_name"}, "compactionConfiguration": { "icebergConfiguration": {"strategy": "sort"} } }'\ --type compaction ``` ------ #### [ AWS API ] [CreateTableOptimizer](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-table-optimizers.html#aws-glue-api-table-optimizers-CreateTableOptimizer) オペレーションを呼び出して、テーブルの圧縮を有効にします。 ------ 圧縮を有効にすると、圧縮の実行が完了後、**[テーブルの最適化]** タブに次の圧縮の詳細が表示されます。 開始時間 データカタログ内で圧縮プロセスが開始された時刻。値は UTC 時間のタイムスタンプです。 終了時刻 Data Catalog で圧縮処理が終了した時刻。値は UTC 時間のタイムスタンプです。 ステータス 圧縮実行のステータス。値は成功または失敗です。 圧縮ファイル数 圧縮したファイルの総数。 圧縮バイト数 圧縮したバイトの総数。 # 圧縮オプティマイザの無効化 AWS Glue コンソールまたは AWS CLI を使用して、特定の Apache Iceberg テーブルの自動圧縮を無効にできます。 ------ #### [ Console ] 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. 左のナビゲーションで、**[Data Catalog]** の **[テーブル]** を選択します。 1. テーブルリストから、圧縮を無効にする Iceberg テーブルを選択します。 1. **[テーブルの詳細]** ページの下部にある、**[テーブル最適化]** タブを選択します。 1. **[アクション]** から、**[無効にする]** を選択し、**[圧縮]** を選択します。 1. 確認メッセージで **[圧縮を無効にする]** を選択します。圧縮は後で再度有効にすることができます。 確認すると、圧縮が無効になり、テーブルの圧縮ステータスが `Disabled` に戻ります。 ------ #### [ AWS CLI ] 次の例で、アカウント ID を、有効な AWS アカウント ID に置き換えます。データベース名とテーブル名を、実際の Iceberg テーブル名とデータベース名に置き換えます。`roleArn` を、圧縮の実行に必要なアクセス許可を持つ IAM ロールの AWS リソースネーム (ARN) と IAM ロールの実際の名前に置き換えます。 ``` aws glue update-table-optimizer \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name iceberg_table \ --table-optimizer-configuration '{"roleArn":"arn:aws:iam::123456789012:role/optimizer_role", "enabled":'false', "vpcConfiguration":{"glueConnectionName":"glue_connection_name"}}'\ --type compaction ``` ------ #### [ AWS API ] [UpdateTableOptimizer](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-table-optimizers.html#aws-glue-api-table-optimizers-UpdateTableOptimizer) オペレーションを呼び出して、特定のテーブルの圧縮を無効にします。 ------ # スナップショット保持の最適化 Apache Iceberg スナップショット保持機能を使用すると、ユーザーは特定の時点で履歴データをクエリし、テーブルへの不要な変更を元に戻すことができます。AWS Glue データカタログでは、スナップショット保持設定により、これらのスナップショット (テーブルデータのバージョン) の有効期限が切れて削除されるまでの保持期間が制御されます。これは、設定された保持期間または保持するスナップショットの最大数に基づいて古いスナップショットを自動的に削除することで、ストレージコストとメタデータのオーバーヘッドを管理するのに役立ちます。 保持期間を日数で設定し、テーブルに保持するスナップショットの最大数を設定できます。AWS Glue は、最新のスナップショットを設定した上限まで保持しながら、指定された保持期間より古いスナップショットをテーブルメタデータから削除します。メタデータから古いスナップショットを削除すると、AWS Glue は、参照されなくなった、期限切れのスナップショットに固有の対応するデータとメタデータファイルを削除します。これにより、有効期限が切れたスナップショットデータで使用されていたストレージ領域を再利用しながら、保持されている残りのスナップショットまでのタイムトラベルクエリのみが可能になります。 **Topics** + [スナップショット保持オプティマイザーの有効化](enable-snapshot-retention.md) + [スナップショット保持オプティマイザーの更新](update-snapshot-retention.md) + [スナップショット保持オプティマイザーの無効化](disable-snapshot-retention.md) # スナップショット保持オプティマイザーの有効化 AWS Glue コンソール、AWS CLI、または AWS API を使用して、データカタログ内の Apache Iceberg テーブルのスナップショット保持オプティマイザーを有効にすることができます。新しいテーブルの場合は、テーブル形式として Apache Iceberg を選択し、テーブルの作成時にスナップショット保持オプティマイザーを有効にすることができます。新しいテーブルでは、スナップショットの保持はデフォルトで無効になっています。 ------ #### [ Console ] **スナップショット保持オプティマイザーを有効にするには** 1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/) で AWS Glue コンソールを開き、データレイク管理者、テーブル作成者、またはテーブルに対する `glue:UpdateTable` および `lakeformation:GetDataAccess` の許可を付与されたユーザーとしてサインインします。 1. ナビゲーションペインの **[データカタログ]** で **[テーブル]** を選択します。 1. **[テーブル]** ページで、スナップショット保持オプティマイザーを有効にする Iceberg テーブルを選択してから、**[アクション]** メニューで、**[最適化]** の **[有効化]** を選択します。 テーブルを選択して **[テーブルの詳細]** ページを開いて、最適化を有効にすることもできます。ページの下部にある **[テーブル最適化]** タブを選択し、**[スナップショットの保持を有効にする]** を選択します。 1. **[最適化を有効にする]** ページの **[最適化設定]** には、**[デフォルト設定の使用]** と **[設定のカスタマイズ]** の 2 つのオプションがあります。デフォルト設定を使用する場合、AWS Glue は Iceberg テーブル設定で定義されたプロパティを使用して、スナップショットの保持期間と保持するスナップショットの数を決定します。この設定がない場合、AWS Glue は 1 つのスナップショットを 5 日間保持し、期限切れのスナップショットに関連付けられたファイルを削除します。 1. 次に、オプティマイザーを実行するためにお客様に代わって AWS Glue が引き受けることのできる IAM ロールを選択します。IAM ロールに必要なアクセス許可の詳細については、「[テーブル最適化の前提条件](optimization-prerequisites.md)」セクションを参照してください。 以下の手順に従って、既存の IAM ロールを更新します。 1. IAM ロールの許可ポリシーを更新するには、IAM コンソールで、圧縮の実行に使用されている IAM ロールにアクセスします。 1. [アクセス許可の追加] セクションで、[ポリシーの作成] を選択します。新しく開いたブラウザウィンドウで、ロールで使用する新しいポリシーを作成します。 1. [Create policy] (ポリシーの作成) ページで、[JSON] タブを選択します。前提条件に示している JSON コードをポリシーエディタフィールドにコピーします。 1. **[スナップショット保持設定]** の値を手動で設定する場合は、**[設定のカスタマイズ]** を選択します。 ![\[[保持を有効にする] > [設定のカスタマイズ] オプションでの Apache Iceberg テーブルの詳細ページ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/table-enable-retention.png) 1. **[選択した IAM ロールを選択したオプティマイザーに適用]** オプションのボックスを選択して、すべてのオプティマイザーを有効にするために単一の IAM ロールを使用します。 1. Iceberg テーブルオプティマイザーが、特定の仮想プライベートクラウド (VPC) から Amazon S3 バケットにアクセスする必要があるセキュリティポリシー設定がある場合は、AWS Glue ネットワーク接続を作成するか、既存のバケットを使用します。 AWS Glue VPC 接続をまだ設定していない場合は、AWS Glue コンソールまたは AWS CLI/SDK を使用して[コネクタ用の接続を作成する](https://docs.aws.amazon.com/glue/latest/dg/creating-connections.html)セクションの手順に従って、新しい接続を作成します。 1. 次に、**[スナップショット保持設定]** で、[[Iceberg テーブル設定]](https://iceberg.apache.org/docs/1.5.2/configuration/#table-behavior-properties) で指定された値を使用するか、スナップショット保持期間 (history.expire.max-snapshot-age-ms) と保持するスナップショットの最小数 (history.expire.min-snapshots-to-keep) のカスタム値を連続するスナップショット削除ジョブが実行する間に指定します。 1. **[関連するファイルを削除]** を選択して、テーブルオプティマイザーがテーブルメタデータから古いスナップショットを削除するときに、基盤となるファイルを削除します。 このオプションを選択しない場合、古いスナップショットがテーブルメタデータから削除されたときに、関連するファイルが孤立ファイルとしてストレージに残ります。 1. 次に、注意書きを読み、**[同意します]** を選択して続行します。 **注記** データカタログでは、スナップショット保持オプティマイザーにより、ブランチおよびタグレベルの保持ポリシーによって制御されるライフサイクルが尊重されます。詳細については、Iceberg のドキュメントの「[Branching and tagging](https://iceberg.apache.org/docs/latest/branching/#overview)」セクションを参照してください。 1. 設定を確認し、**[最適化を有効にする]** を選択します。 保持オプティマイザーが実行され、設定に基づいて古いスナップショットの有効期限が切れるまで数分待ちます。 ------ #### [ AWS CLI ] AWS Glue で新しい Iceberg テーブルのスナップショット保持を有効にするには、タイプが `retention` のテーブルオプティマイザーを作成し、`table-optimizer-configuration` の `enabled` フィールドを `true` に設定する必要があります。これを行うには、AWS CLI コマンドの `create-table-optimizer` または `update-table-optimizer` を使用します。さらに、要件に基づいて、`snapshotRetentionPeriodInDays` や `numberOfSnapshotsToRetain` などの保持設定フィールドを指定する必要があります。 次の例は、スナップショット保持オプティマイザーを有効にする方法を示しています。アカウント ID を有効な AWS アカウント ID に置き換えます。データベース名とテーブル名を実際の Iceberg テーブル名とデータベース名に置き換えます。`roleArn` を、スナップショット保持オプティマイザーの実行に必要なアクセス許可を持つ IAM ロールの AWS リソースネーム (ARN) と IAM ロールの名前に置き換えます。 ``` aws glue create-table-optimizer \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name iceberg_table \ --table-optimizer-configuration '{"roleArn":"arn:aws:iam::123456789012:role/optimizer_role","enabled":'true', "vpcConfiguration":{ "glueConnectionName":"glue_connection_name"}, "retentionConfiguration":{"icebergConfiguration":{"snapshotRetentionPeriodInDays":7,"numberOfSnapshotsToRetain":3,"cleanExpiredFiles":'true'}}}'\ --type retention ``` このコマンドは、指定されたカタログ、データベース、およびリージョンの、指定された Iceberg テーブルの保持オプティマイザーを作成します。table-optimizer-configuration では、使用する IAM ロール ARN を指定し、オプティマイザーを有効にして、保持設定を設定します。この例では、スナップショットを 7 日間保持し、少なくとも 3 つのスナップショットを保持し、期限切れのファイルをクリーンアップします。 + snapshotRetentionPeriodInDays – 期限切れになるまでのスナップショットを保持する日数。デフォルト値は `5` です。 + numberOfSnapshotsToRetain – 保持期間より古い場合でも保持するスナップショットの最小数。デフォルト値は `1` です。 + cleanExpiredFiles – スナップショットの有効期限が切れた後に、期限切れのデータファイルを削除するかどうかを示すブール値。デフォルト値は `true` です。 true に設定した場合、古いスナップショットがテーブルメタデータから削除されると、基盤となるファイルが削除されます。このパラメータを false に設定した場合、古いスナップショットがテーブルメタデータから削除されても、基盤となるファイルは孤立ファイルとしてストレージに残ります。 ------ #### [ AWS API ] [CreateTableOptimizer](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-table-optimizers.html#aws-glue-api-table-optimizers-CreateTableOptimizer) オペレーションを呼び出して、テーブルのスナップショット保持オプティマイザーを有効にします。 ------ 圧縮を有効にすると、**[テーブル最適化]** タブに以下の圧縮の詳細が表示されます (約 15～20 分後)。 開始時刻 スナップショット保持オプティマイザーが開始された時刻。値は UTC 時間のタイムスタンプです。 実行時間 この時間は、オプティマイザーがタスクを完了するためにかかる時間を示します。値は UTC 時間のタイムスタンプです。 ステータス オプティマイザーの実行のステータス。値は成功または失敗です。 削除されたデータファイル 削除されたファイルの合計数。 削除されたマニフェストファイル 削除されたマニフェストファイルの合計数。 削除されたマニフェストリスト 削除されたマニフェストリストの合計数。 # スナップショット保持オプティマイザーの更新 AWS Glue コンソール、AWS CLI、または UpdateTableOptimizer API を使用して、特定の Apache Iceberg テーブルに対するスナップショット保持オプティマイザーの既存の設定を更新できます。 ------ #### [ Console ] **スナップショット保持設定を更新するには** 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. **[データカタログ]**、**[テーブル]** の順に選択します。Iceberg テーブルリストから、スナップショット保持オプティマイザー設定を更新するテーブルを選択します。 1. **[テーブルの詳細]** ページの下部セクションで、**[テーブルの最適化]** タブを選択し、**[編集]** を選択します。ページの右上隅にある **[アクション]**メニューから、**[最適化]** で **[編集]** を選択することもできます。 1. **[最適化の編集]** ページで、必要な変更を加えます。 1. **[保存]** を選択します。 ------ #### [ AWS CLI ] AWS CLI を使用してスナップショット保持オプティマイザーを更新するときは、次のコマンドを使用できます。 ``` aws glue update-table-optimizer \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name iceberg_table \ --table-optimizer-configuration '{"roleArn":"arn:aws:iam::123456789012:role/optimizer_role"","enabled":'true', "vpcConfiguration":{"glueConnectionName":"glue_connection_name"},"retentionConfiguration":{"icebergConfiguration":{"snapshotRetentionPeriodInDays":7,"numberOfSnapshotsToRetain":3,"cleanExpiredFiles":'true'}}}' \ --type retention ``` このコマンドは、指定されたカタログ、データベース、およびリージョンの、指定されたテーブルの保持設定を更新します。キーパラメータは次のとおりです。 + snapshotRetentionPeriodInDays – 期限切れになるまでのスナップショットを保持する日数。デフォルト値は `1` です。 + numberOfSnapshotsToRetain – 保持期間より古い場合でも保持するスナップショットの最小数。デフォルト値は `5` です。 + cleanExpiredFiles – スナップショットの有効期限が切れた後に、期限切れのデータファイルを削除するかどうかを示すブール値。デフォルト値は `true` です。 true に設定した場合、古いスナップショットがテーブルメタデータから削除されると、基盤となるファイルが削除されます。このパラメータを false に設定した場合、古いスナップショットがテーブルメタデータから削除されても、基盤となるファイルは孤立ファイルとしてストレージに残ります。 ------ #### [ API ] テーブルオプティマイザーを更新するときは、`UpdateTableOptimizer` API を使用できます。この API を使用すると、圧縮、保持、または孤立ファイル削除のために既存のテーブルオプティマイザーの設定を更新できます。リクエストパラメータには以下が含まれます。 + catalogId (必須): テーブルを含むカタログの ID + databaseName (オプション): テーブルを含むデータベースの名前 + tableName (オプション): テーブルの名前 + type (必須): テーブルオプティマイザーのタイプ (compaction、retention、または orphan\$1file\$1deletion) + retentionConfiguration (必須): ロールの ARN、有効ステータス、保持設定、孤立ファイル削除設定など、テーブルオプティマイザーの更新された設定。 ------ # スナップショット保持オプティマイザーの無効化 AWS Glue コンソールまたは AWS CLI を使用して、特定の Apache Iceberg テーブルのスナップショット保持オプティマイザーを無効にすることができます。 ------ #### [ Console ] **スナップショットの保持を無効にするには** 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. **[データカタログ]**、**[テーブル]** の順に選択します。テーブルリストから、スナップショットの保持用のオプティマイザーを無効にする Iceberg テーブルを選択します。 1. **[テーブルの詳細]** ページの下部で、**[アクション]** の下にある **[スナップショットの保持]**、**[テーブルの最適化]**、**[無効にする]** を選択します。 ページの右上隅にある **[アクション]** メニューから、**[最適化]** で **[無効にする]** を選択することもできます。 1. 確認メッセージで **[無効化]** を選択します。スナップショット保持オプティマイザーは後から再度有効にできます。 確認後、スナップショット保持オプティマイザーが無効になり、スナップショット保持のステータスが `Not enabled` に戻ります。 ------ #### [ AWS CLI ] 次の例で、アカウント ID を、有効な AWS アカウント ID に置き換えます。データベース名とテーブル名を、実際の Iceberg テーブル名とデータベース名に置き換えます。`roleArn` を、保持オプティマイザーの実行に必要なアクセス許可を持つ IAM ロールの AWS リソースネーム (ARN) と IAM ロールの実際の名前に置き換えます。 ``` aws glue update-table-optimizer \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name iceberg_table \ --table-optimizer-configuration '{"roleArn":"arn:aws:iam::123456789012:role/optimizer_role", "vpcConfiguration":{"glueConnectionName":"glue_connection_name"}, "enabled":'false'}'\ --type retention ``` ------ #### [ AWS API ] [UpdateTableOptimizer](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-table-optimizers.html#aws-glue-api-table-optimizers-UpdateTableOptimizer) オペレーションを呼び出して、特定のテーブルのスナップショット保持オプティマイザーを無効にします。 ------ # 孤立ファイルの削除 AWS Glue Data Catalog では、Iceberg テーブルから孤立ファイルを削除できます。孤立ファイルとは、指定されたテーブルの場所の Amazon S3 データソースに存在し、Iceberg テーブルメタデータによって追跡されず、設定された経過時間制限よりも古い参照されていないファイルのことを指します。これらの孤立ファイルは、圧縮、パーティションの削除、テーブルの書き換えなどのオペレーションの障害により、時間の経過と共に蓄積され、不要なストレージスペースを占める可能性があります。 AWS Glue の孤立ファイル削除オプティマイザーは、テーブルメタデータと実際のデータファイルをスキャンして孤立ファイルを識別し、それらを削除してストレージ領域を再利用します。オプティマイザーは、オプティマイザーの作成日以降に作成された、設定された削除基準を満たすファイルのみを削除します。つまり、オプティマイザーの作成日より前に作成されたファイルは削除されません。 **孤立ファイルの削除ロジック** 1. 日付チェック – ファイル作成日をオプティマイザー作成日と比較します。ファイルがオプティマイザー作成日より古い場合、そのファイルはスキップされます。 1. オプティマイザー設定チェック – ファイルがオプティマイザー作成日より新しい場合、設定された経過期限に対してファイルを評価します。オプティマイザーは、削除基準に一致したファイルを削除します。基準と一致しない場合は、ファイルをスキップします。 データカタログで孤立ファイル削除テーブルオプティマイザーを作成することで、孤立ファイルの削除を開始できます。 **重要** デフォルトでは、孤立ファイルを削除すると、AWS Glue テーブルの場所全体のファイルを評価します。API パラメーターを使用することで、評価の範囲を制限するためにサブプレフィックスを設定できますが、テーブルの場所に他のデータソースやテーブルのファイルが含まれていないことを確認する必要があります。テーブルの場所が他のデータソースと重複している場合、関係のないファイルが孤立ファイルとして識別されて削除される可能性があります。 **Topics** + [孤立ファイルの削除の有効化](enable-orphan-file-deletion.md) + [孤立ファイル削除オプティマイザーの更新](update-orphan-file-deletion.md) + [孤立ファイルの削除の無効化](disable-orphan-file-deletion.md) # 孤立ファイルの削除の有効化 AWS Glue コンソール、AWS CLI、または AWS API を使用して、データカタログ内の Apache Iceberg テーブルの孤立ファイルの削除を有効にすることができます。新しいテーブルの場合は、テーブル形式として Apache Iceberg を選択し、テーブルの作成時に孤立ファイル削除オプティマイザーを有効にすることができます。新しいテーブルでは、スナップショットの保持はデフォルトで無効になっています。 ------ #### [ Console ] **孤立ファイルの削除を有効にするには** 1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/) で AWS Glue コンソールを開き、データレイク管理者、テーブル作成者、またはテーブルに対する `glue:UpdateTable` および `lakeformation:GetDataAccess` の許可を付与されたユーザーとしてサインインします。 1. ナビゲーションペインの **[データカタログ]** で **[テーブル]** を選択します。 1. **[テーブル]** ページで、孤立ファイルの削除を有効にする Iceberg テーブルを選択します。 ページの下部にある **[テーブル最適化]** タブを選択し、**[アクション]** から **[孤立ファイルの削除]**、**[有効にする]** を選択します。 ページの右上隅にある **[アクション]** メニューから、**[最適化]** で **[有効にする]** することもできます。 1. **[最適化を有効にする]** ページで、**[最適化オプション]** の **[孤立ファイルの削除]** を選択します。 1. **[デフォルト設定]** を使用する場合、すべての孤立ファイルは 3 日後に削除されます。孤立ファイルを特定の日数保持する場合は、**[設定をカスタマイズ]** を選択します。 1. 次に、孤立ファイルを削除するために必要なアクセス許可を持つ IAM ロールを選択します。 1. Iceberg テーブルオプティマイザーが、特定の仮想プライベートクラウド (VPC) から Amazon S3 バケットにアクセスする必要があるセキュリティポリシー設定がある場合は、AWS Glue ネットワーク接続を作成するか、既存のバケットを使用します。 AWS Glue VPC 接続をまだ設定していない場合は、AWS Glue コンソールまたは AWS CLI/SDK を使用して[コネクタ用の接続を作成する](https://docs.aws.amazon.com/glue/latest/dg/creating-connections.html)セクションの手順に従って、新しい接続を作成します。 1. **[設定をカスタマイズ]** を選択した場合は、**[孤立ファイルの削除設定]** で、削除前にファイルを保持する日数を入力します。2 つの連続するオプティマイザーの実行時の間隔を指定することもできます。デフォルト値は 24 時間です。 1. **[最適化を有効にする]** を選択します。 ------ #### [ AWS CLI ] AWS Glue で Iceberg テーブルの孤立ファイルの削除を有効にするには、タイプが `orphan_file_deletion` のテーブルオプティマイザーを作成し、`enabled` フィールドを true に設定する必要があります。AWS CLI を使用して Iceberg テーブルの孤立ファイル削除オプティマイザーを作成するには、次のコマンドを使用します。 ``` aws glue create-table-optimizer \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name iceberg_table \ --table-optimizer-configuration '{"roleArn":"arn:aws:iam::123456789012:role/optimizer_role","enabled":true, "vpcConfiguration":{ "glueConnectionName":"glue_connection_name"}, "orphanFileDeletionConfiguration":{"icebergConfiguration":{"orphanFileRetentionPeriodInDays":3, "location":'S3 location'}}}'\ --type orphan_file_deletion ``` このコマンドにより、指定した Iceberg テーブルの孤立ファイル削除オプティマイザーが作成されます。キーパラメータは次のとおりです。 + roleArn – S3 バケットと Glue リソースへのアクセス許可を持つ IAM ロールの ARN。 + enabled – オプティマイザーを有効にするには、true に設定します。 + orphanFileRetentionPeriodInDays – 孤立ファイルが削除されるまでの保持日数 (最小で 1 日)。 + type – 孤立ファイル削除オプティマイザーを作成するには、orphan\$1file\$1deletion に設定します。 テーブルオプティマイザーを作成した後は、孤立ファイルの削除が定期的に (有効のままにした場合は 1 日に 1 回) 実行されます。`list-table-optimizer-runs` API を使用して実行を確認できます。孤立ファイルの削除ジョブでは、テーブルの Iceberg メタデータで追跡されていないファイルが識別されて削除されます。 ------ #### [ API ] [CreateTableOptimizer](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-table-optimizers.html#aws-glue-api-table-optimizers-CreateTableOptimizer) オペレーションを呼び出して、特定のテーブルの孤立ファイル削除オプティマイザーを作成します。 ------ # 孤立ファイル削除オプティマイザーの更新 AWS Glue コンソール、AWS CLI、または `UpdateTableOptimizer` オペレーションを使用して、孤立ファイルの保持期間やオプティマイザーが使用する IAM ロールを変更するなど、孤立ファイル削除オプティマイザーの設定を変更できます。 ------ #### [ AWS マネジメントコンソール ] **孤立ファイル削除オプティマイザーを更新するには** 1. **[データカタログ]**、**[テーブル]** の順に選択します。テーブルリストから、孤立ファイル削除オプティマイザー設定を更新するテーブルを選択します。 1. **[テーブルの詳細]** ページの下部セクションで、**[テーブルの最適化]**、**[編集]** を選択します。 1. **[最適化の編集]** ページで、必要な変更を加えます。 1. **[保存]** を選択します。 ------ #### [ AWS CLI ] `update-table-optimizer` 呼び出しを使用して AWS Glue の孤立ファイル削除オプティマイザーを更新できます。呼び出しを使用できます。これにより、`icebergConfiguration` フィールドで `OrphanFileDeletionConfiguration` を変更して、更新後の `OrphanFileRetentionPeriodInDays` で孤立ファイルを保持する日数を設定し、孤立ファイルを削除する Iceberg テーブルの場所を指定できます。 ``` aws glue update-table-optimizer \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name Iceberg_table \ --table-optimizer-configuration '{"roleArn":"arn:aws:iam::123456789012:role/optimizer_role","enabled":true, "vpcConfiguration":{"glueConnectionName":"glue_connection_name"},"orphanFileDeletionConfiguration":{"icebergConfiguration":{"orphanFileRetentionPeriodInDays":5}}}' \ --type orphan_file_deletion ``` ------ #### [ API ] [UpdateTableOptimizer](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-table-optimizers.html#aws-glue-api-table-optimizers-UpdateTableOptimizer) オペレーションを呼び出して、テーブルの孤立ファイルの削除オプティマイザーを更新します。 ------ # 孤立ファイルの削除の無効化 AWS Glue コンソールまたは AWS CLI を使用して、特定の Apache Iceberg テーブルの孤立ファイル削除オプティマイザーを無効にすることができます。 ------ #### [ Console ] **孤立ファイルの削除を無効にするには** 1. **[データカタログ]**、**[テーブル]** の順に選択します。テーブルリストから、孤立ファイルの削除用のオプティマイザーを無効にする Iceberg テーブルを選択します。 1. **[テーブルの詳細]** ページの下部のセクションで、**[テーブル最適化]** を選択します。 1. **[アクション]** を選択し、**[無効にする]**、**[孤立ファイルの削除]** を選択します。 また、**[アクション]** メニューから **[最適化]** の下部にある **[無効化]** を選択することもできます。 1. 確認メッセージで **[無効化]** を選択します。孤立ファイル削除オプティマイザーは後から再度有効にできます。 確認後、孤立ファイル削除オプティマイザーが無効になり、孤立ファイル削除のステータスが `Not enabled` に戻ります。 ------ #### [ AWS CLI ] 次の例で、アカウント ID を、有効な AWS アカウント ID に置き換えます。データベース名とテーブル名を、実際の Iceberg テーブル名とデータベース名に置き換えます。`roleArn` を、オプティマイザーの無効化に必要なアクセス許可を持つ IAM ロールの AWS リソースネーム (ARN) と IAM ロールの実際の名前に置き換えます。 ``` aws glue update-table-optimizer \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name iceberg_table \ --table-optimizer-configuration '{"roleArn":"arn:aws:iam::123456789012:role/optimizer_role", "enabled":'false'}'\ --type orphan_file_deletion ``` ------ #### [ API ] [UpdateTableOptimizer](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-table-optimizers.html#aws-glue-api-table-optimizers-UpdateTableOptimizer) オペレーションを呼び出して、特定のテーブルのスナップショット保持オプティマイザーを無効にします。 ------ # 最適化の詳細の表示 Apache Iceberg テーブルの最適化ステータスは、AWS Glue コンソール、AWS CLI、または AWS API オペレーションで表示できます。 ------ #### [ Console ] **Iceberg テーブルの最適化ステータスを表示するには (コンソール)** + **[データカタログ]** の **[テーブル]** リストから Iceberg テーブルを選択すると、AWS Glue コンソールで Iceberg テーブルの最適化ステータスを表示できます。**[テーブルの最適化]** の下。**[すべて表示]** を選択する ![\[[圧縮を有効にする] オプションを示す Apache Iceberg の [テーブルの詳細] ページ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/table-list-compaction-status.png) ------ #### [ AWS CLI ] AWS CLI を使用して最適化の詳細を表示できます。 次の例では、アカウントID を有効な AWS アカウント ID、データベース名、テーブル名を実際の Iceberg テーブル名に置き換えます。`type` には、最適化タイプを指定します。許容値は、`compaction`、`retention`、および `orphan-file-deletion` です。 + **テーブルの前回の圧縮実行の詳細を取得するには** ``` aws get-table-optimizer \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name iceberg_table \ --type compaction ``` + 次の例を使用して、特定のテーブルのオプティマイザーの履歴を取得します。 ``` aws list-table-optimizer-runs \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name iceberg_table \ --type compaction ``` + 次の例は、複数のオプティマイザーの最適化実行と設定の詳細を取得する方法を示しています。最大 20 個のオプティマイザを指定できます。 ``` aws glue batch-get-table-optimizer \ --entries '[{"catalogId":"123456789012", "databaseName":"iceberg_db", "tableName":"iceberg_table", "type":"compaction"}]' ``` ------ #### [ API ] + `GetTableOptimizer` オペレーションを使用して、前回実行したオプティマイザの詳細を取得します。 + 特定のテーブル上の特定のオプティマイザーの履歴を取得するには、`ListTableOptimizerRuns` オペレーションを使用します。1 回の API 呼び出しで 20 個のオプティマイザーを指定できます。 + [BatchGetTableOptimizer](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-table-optimizers.html#aws-glue-api-table-optimizers-BatchGetTableOptimizer) オペレーションを使用して、アカウント内の複数のオプティマイザーの設定の詳細を取得します。 ------ # Amazon CloudWatch メトリクスの表示 テーブルオプティマイザーが正常に実行されると、サービスは最適化ジョブのパフォーマンスに関する Amazon CloudWatch メトリクスを作成します。**[CloudWatch メトリクス]** に移動し、**[メトリクス]**、**[すべてのメトリクス]** の順に選択できます。メトリクスは、特定の名前空間 (AWS Glue など)、テーブル名、またはデータベース名でフィルタリングできます。 詳細については、「Amazon CloudWatch ユーザーガイド」の「[使用可能なメトリクスを表示する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html)」を参照してください。 ****圧縮**** + 圧縮されたバイト数 + 圧縮ファイル数 + ジョブに割り当てられた DPU 数 + ジョブの期間 (時間数) ****スナップショット保持期限**** + 削除されたデータファイルの数 + 削除されたマニフェストファイルの数 + 削除されたマニフェストリストの数 + ジョブの期間 (時間数) ****孤立ファイルの削除**** + 削除された孤立ファイルの数 + ジョブの期間 (時間数) # オプティマイザーの削除 AWS CLI または AWS API オペレーションを使用して、テーブルのオプティマイザーと関連するメタデータを削除できます。 テーブルの最適化履歴を削除するには、次の AWS CLI コマンドを実行します。オプティマイザーの `type` を、カタログ ID、データベース名、テーブル名と共に指定する必要があります。許容値は、`compaction`、`retention`、および `orphan_file_deletion` です。 ``` aws glue delete-table-optimizer \ --catalog-id 123456789012 \ --database-name iceberg_db \ --table-name iceberg_table \ --type compaction ``` テーブルのオプティマイザーを削除するには、`DeleteTableOptimizer` オペレーションを使用します。 # 考慮事項と制限事項 このセクションでは、AWS Glue Data Catalog 内でテーブルオプティマイザーを使用する際に考慮すべき点について説明します。 ## 耐久性と正確性 **S3 テーブルロケーション:** 複数の AWS Glue Data Catalog テーブルが同じ Amazon S3 ロケーションを共有しており、オプティマイザが有効になっている場合、1 つのテーブルのスナップショット保持または孤立ファイル削除オプティマイザにより、別のテーブルによって現在も参照されているファイルが削除される可能性があります。オプティマイザが有効になっている各テーブルに、他のテーブル (異なるデータベースのテーブルを含む) と共有されていない一意の Amazon S3 ロケーションがあることを確認してください。 **S3 ライフサイクルの有効期限:** Iceberg テーブルストレージロケーションに適用される Amazon S3 ライフサイクル有効期限ルールでは、アクティブなスナップショットによって現在も参照されているマニフェストファイルとデータファイルを削除できます。バケットにライフサイクル有効期限ルールがある場合は、Iceberg テーブルストレージパスが除外されることを確認してください。 ## マネージドデータ圧縮でサポートされる形式と制限事項 データ圧縮は、暗号化されたテーブルからのデータの読み取りなど、データの読み書きのためのさまざまなデータ型と圧縮形式をサポートしています。 **同時実行制御:** Apache Iceberg は楽観的同時実行制御をサポートしているため、複数のライターが同時にオペレーションを実行できます。競合はコミット時に検出され、解決されます。ストリーミングパイプラインを使用する場合は、テーブルプロパティと圧縮設定を使用して適切な再試行設定を行い、同時書き込みを効果的に処理します。詳細なガイダンスについては、[Iceberg テーブルでの同時書き込みの管理](https://aws.amazon.com/blogs/big-data/manage-concurrent-write-conflicts-in-apache-iceberg-on-the-aws-glue-data-catalog/)に関する AWS ビッグデータブログを参照してください。 **圧縮の再試行:** 圧縮オペレーションが 4 回連続して失敗すると、不要なコンピューティングリソースの消費を防ぐため、AWS Glue カタログテーブルの最適化によってオプティマイザが自動的に一時停止されます。まずログを調べ、圧縮が繰り返し失敗する理由を見つけてみてください。圧縮の最適化を再開するには、AWS Glue コンソールまたは API を使用してオプティマイザを再度有効にします。 **データ圧縮は以下をサポートします。** + **暗号化** - データ圧縮では、デフォルトの Amazon S3 暗号化 (SSE-S3) とサーバー側 KMS 暗号化 (SSE-KMS) のみがサポートされます。 + **圧縮戦略** – ビンパック、ソート、Z オーダーソート + 基礎となるデータを保存する Amazon S3 バケットが別のアカウントにある場合、データカタログが存在するアカウントから圧縮を実行できます。これを実行するには、圧縮ロールが Amazon S3 バケットにアクセスできる必要があります。 **データ圧縮は現在、次をサポートしていません。** + **クロスアカウントテーブルでの圧縮** - クロスアカウントテーブルでは圧縮を実行できません。 + **クロスリージョンテーブルでの圧縮** - クロスリージョンテーブルでは圧縮を実行できません。 + **リソースのリンクでの圧縮の有効化** + **Amazon S3 Express One Zone ストレージクラスのテーブル ** – Amazon S3 Express One Zone Iceberg テーブルでは圧縮を実行できません。 + **Z オーダー圧縮戦略では、次のデータ型がサポートされていません:** + 10 進数 + TimestampWithoutZone ## スナップショット保持と孤立ファイル削除オプティマイザに関する考慮事項 スナップショット保持と孤立ファイル削除のオプティマイザーには、次の考慮事項が適用されます。 + スナップショットの保持と孤立ファイルの削除プロセスでは、実行ごとに最大 1,000,000 個のファイルを削除できます。期限切れのスナップショットを削除するときに、削除の対象となるファイルの数が 1,000,000 を超えると、そのしきい値を超える残りのファイルは、孤立ファイルとしてテーブルストレージに引き続き存在します。 + スナップショットは、保持するスナップショットの最小数と指定された保持期間という両方の基準が満たされた場合にのみ、スナップショット保持オプティマイザによって保持されます。 + スナップショット保持オプティマイザは、Apache Iceberg から期限切れのスナップショットメタデータを削除し、期限切れのスナップショットのタイムトラベルクエリを防ぎ、オプションで関連するデータファイルを削除します。 + オーファンファイル削除オプティマイザは、作成時間がオプティマイザ実行時からオーファンファイル削除保持期間より前である場合、Iceberg メタデータによって参照されなくなった孤立したデータとメタデータファイルを削除します。 + Apache Iceberg は、特定のスナップショット状態へのポインターという名前のブランチとタグを使用してバージョン管理を容易にします。各ブランチとタグは、それぞれのレベルで定義された保持ポリシーによって管理される、独自の独立したライフサイクルに従います。AWS Glue Data Catalog オプティマイザは、これらのライフサイクルポリシーを考慮し、指定された保持ルールを確実に遵守します。ブランチおよびタグレベルの保持ポリシーは、オプティマイザ設定よりも優先されます。 詳細については、Apache Iceberg のドキュメントの「[分岐とタグ付け](https://iceberg.apache.org/docs/nightly/branching/)」を参照してください。 + スナップショット保持と孤立ファイル削除オプティマイザは、設定されたパラメータに従ってクリーンアップの対象となるファイルを削除します。適切なバケットに S3 バージョニングポリシーとライフサイクルポリシーを実装することで、ファイル削除の制御を強化します。 バージョニングの設定とライフサイクルルールの作成に関する詳細な手順については、「[https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html)」を参照してください。 + 孤立ファイルについて適切な判断を行うには、指定されたテーブルの場所とサブパスが他のテーブルやデータソースと重複したり、他のテーブルやデータソースのデータを含んでいないことを確認してください。パスが重複すると、ファイルの意図しない削除によって回復不可能なデータ損失が発生する可能性があります。 ## OversizedAllocationException 例外のデバッグ `OversizedAllocationException` 例外を解決するには： + ベクトル化されたリーダーのバッチサイズを減らして確認します。デフォルトバッチサイズは 5000 です。これは `read.parquet.vectorization.batch-size` で制御されます。 + 複数のバリエーションがあってもこれが機能しない場合は、ベクトル化をオフにします。これは `read.parquet.vectorization.enabled` で制御されます。 # テーブルオプティマイザーがサポートされているリージョン AWS Glue Data Catalog のテーブル最適化機能 (圧縮、スナップショット保持、孤立ファイルの削除) は、次の AWS リージョン で使用できます。 + アジアパシフィック (東京) + アジアパシフィック (ソウル) + アジアパシフィック (ムンバイ) + アジアパシフィック (シンガポール) + アジアパシフィック (シドニー) + アジアパシフィック (ジャカルタ) + カナダ (中部) + 欧州 (アイルランド) + 欧州 (ロンドン) + 欧州 (フランクフルト) + 欧州 (ストックホルム) + 米国東部 (バージニア北部) + 米国東部 (オハイオ) + 米国西部 (オレゴン） + 南米 (サンパウロ） # Iceberg テーブルのクエリパフォーマンスの最適化 Apache Iceberg は、膨大な分析データセット用の高性能なオープンテーブル形式です。AWS Glue は、Iceberg テーブルの各列に対する個別の値の数 (NDV) の計算と更新をサポートしています。これらの統計により、大規模データセットを扱うデータエンジニアやサイエンティストにとって、クエリの最適化、データ管理、パフォーマンス効率が改善されます。 AWS Glue は、Iceberg テーブルの各列の個別の値の数を推定し、Iceberg テーブルスナップショットに関連付けられた Amazon S3 の [Puffin](https://iceberg.apache.org/puffin-spec/) ファイルに保存します。Puffin は、インデックス、統計、スケッチなどのメタデータを保存するように設計された Iceberg ファイル形式です。スナップショットに関連付けられた Puffin ファイルにスケッチを保存すると、トランザクションの一貫性と NDV 統計の鮮度が確保されます。 AWS Glue コンソールまたは AWS CLI を使用して列統計生成タスクを実行するように設定できます。プロセスを開始すると、AWS Glue はバックグラウンドで Spark ジョブを開始し、データカタログ内の AWS Glue テーブルメタデータを更新します。列統計は、AWS Glue コンソールもしくは AWS CLI を使用して、または [GetColumnStatisticsForTable](https://docs.aws.amazon.com/glue/latest/webapi/API_GetColumnStatisticsForTable.html) API オペレーションを呼び出すことによって表示できます。 **注記** AWS Lake Formation の許可を使用してテーブルに対するアクセスを制御している場合、列統計タスクによって引き受けられるロールには、統計を生成するための完全なテーブルアクセスが必要です。 **Topics** + [列統計を生成するための前提条件](iceberg-column-stats-prereqs.md) + [Iceberg テーブルの列統計の生成](iceberg-generate-column-stats.md) + [関連情報](#see-also-iceberg-stats) # 列統計を生成するための前提条件 Iceberg テーブルの列統計を生成または更新するために、統計生成タスクはユーザーに代わって AWS Identity and Access Management (IAM) ロールを引き受けます。ロールに付与された許可に基づいて、列統計生成タスクは Amazon S3 データストアからデータを読み取ることができます。 AWS Glue では、列統計生成タスクを設定するときに、`AWSGlueServiceRole` AWS 管理ポリシーと指定されたデータソースに必要なインラインポリシーを含むロールを作成できます。 列統計の生成に既存のロールを指定する場合は、そのロールに `AWSGlueServiceRole` ポリシーまたは同等のポリシー (またはこのポリシーのスコープダウンバージョン) と、必要なインラインポリシーが含まれてることを確認します。 必要な許可の詳細については、「[列統計を生成するための前提条件](column-stats-prereqs.md)」を参照してください。 # Iceberg テーブルの列統計の生成 以下の手順に従って、AWS Glue コンソールまたは AWS CLI を使用してデータカタログで統計を生成するスケジュールを設定するか、**StartColumnStatisticsTaskRun** オペレーションを実行します。 **列統計を生成するには** 1. AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) にサインインします。 1. [データカタログ] の下の **[テーブル]** を選択します。 1. リストから Iceberg テーブルを選択します。 1. **[アクション]** メニューで、**[列の統計]** の **[オンデマンドで生成]** を選択します。 **[テーブル]** ページの下のセクションにある **[列統計]** タブで **[統計を生成]** ボタンを選択することもできます。 1. **[統計を生成]** ページで、統計の生成の詳細を入力します。「[スケジュールで列統計の生成](generate-column-stats.md)」セクションのステップ 6～11 に従って、Iceberg テーブルの統計生成にスケジュールを設定します。 [オンデマンドでの列統計の生成](column-stats-on-demand.md) の手順に従って、オンデマンドで列統計を生成することも選択できます。 **注記** [サンプリング] オプションは Iceberg テーブルでは使用できません。 AWS Glue は、Amazon S3 の場所内の指定されたスナップショット ID にコミットされた新しい Puffin ファイルに対して、Iceberg テーブルの各列にある個別の値の数を計算します。 ## 関連情報 + [列統計の表示](view-column-stats.md) + [列統計タスクの実行の表示](view-stats-run.md) + [列統計タスクの実行の停止](stop-stats-run.md) + [列統計の削除](delete-column-stats.md) # データカタログの管理 AWS Glue Data Catalog は、Amazon S3 データセットの構造メタデータと運用メタデータを保存する中央メタデータリポジトリです。データカタログを効果的に管理することは、データ品質、パフォーマンス、セキュリティ、ガバナンスを維持する上で重要です。 これらのデータカタログ管理プラクティスを理解して適用することで、データランドスケープの進化に合わせて、メタデータが正確でパフォーマンスが高く、安全で、十分に管理されるようにすることができます。 このセクションでは、データカタログ管理の以下の側面について説明します。 + テーブルスキーマとパーティションの更新: データの進化に伴い、データカタログで定義されているテーブルスキーマまたはパーティション構造を更新する必要が生じる場合があります。AWS Glue ETL を使用してプログラムでこれらの更新を行う方法の詳細については、「[AWS Glue ETL ジョブを使用してデータカタログのスキーマを更新し、新規パーティションを追加する](update-from-job.md)」を参照してください。 + 列統計の管理: 正確な列統計は、クエリプランの最適化とパフォーマンスの向上に役立ちます。列統計を生成、更新、管理する方法については、「[列統計を使用したクエリのパフォーマンスの最適化](column-statistics.md)」を参照してください。 + データカタログの暗号化: 機密メタデータを保護するために、AWS Key Management Service (AWS KMS) を使用してデータカタログを暗号化できます。このセクションでは、データカタログの暗号化を有効にして管理する方法について説明します。 + AWS Lake Formation を使用したデータカタログの保護: Lake Formation には、データレイクのセキュリティとアクセスコントロールに対する包括的なアプローチが用意されています。Lake Formation を使用して、データカタログおよび基盤となるデータへのアクセスを保護および管理できます。 **Topics** + [AWS Glue ETL ジョブを使用してデータカタログのスキーマを更新し、新規パーティションを追加する](update-from-job.md) + [列統計を使用したクエリのパフォーマンスの最適化](column-statistics.md) + [Data Catalog の暗号化](catalog-encryption.md) + [Lake Formation を使用したデータカタログの保護](secure-catalog.md) + [AWS Glue での AWS Glue Data Catalog ビューの使用](catalog-views.md) # AWS Glue ETL ジョブを使用してデータカタログのスキーマを更新し、新規パーティションを追加する 抽出、変換、ロード (ETL) ジョブによって、ターゲットデータストアに新しいテーブルパーティションが作成される場合があります。データセットスキーマは、時間の経過とともに AWS Glue Data Catalog スキーマから進化し、拡散する可能性があります。AWS GlueETL ジョブには、ETL スクリプト内で使用できるいくつかの機能が用意され、Data Catalog でスキーマおよびパーティションを更新できるようになりました。これらの機能を使用すると、クローラを再実行することなく、Data Catalog での ETL 作業の結果を確認できます。 ## 新しいパーティション AWS Glue Data Catalog で新しいパーティションを表示するには、次のいずれかを実行します。 + ジョブが終了したら、クローラを再実行し、クローラの完了時にコンソールで新しいパーティションを表示します。 + ジョブが終了すると、クローラを再実行することなく、コンソールで新しいパーティションがすぐに表示されます。この機能は、次の例に示すように、ETL スクリプトに数行のコードを追加して有効にすることができます。このコードは `enableUpdateCatalog` 引数を使用して、新しいパーティションの作成時のジョブ実行中に Data Catalog を更新する必要があることを示します。 **方式 1** オプション引数に `enableUpdateCatalog` と `partitionKeys` を渡します。 ``` additionalOptions = {"enableUpdateCatalog": True} additionalOptions["partitionKeys"] = ["region", "year", "month", "day"] sink = glueContext.write_dynamic_frame_from_catalog(frame=last_transform, database=, table_name=, transformation_ctx="write_sink", additional_options=additionalOptions) ``` ``` val options = JsonOptions(Map( "path" -> , "partitionKeys" -> Seq("region", "year", "month", "day"), "enableUpdateCatalog" -> true)) val sink = glueContext.getCatalogSink( database = , tableName = , additionalOptions = options)sink.writeDynamicFrame(df) ``` **方式 2** `enableUpdateCatalog` に `partitionKeys` と `getSink()` を渡して、`DataSink` オブジェクトで `setCatalogInfo()` を呼び出します。 ``` sink = glueContext.getSink( connection_type="s3", path="", enableUpdateCatalog=True, partitionKeys=["region", "year", "month", "day"]) sink.setFormat("json") sink.setCatalogInfo(catalogDatabase=, catalogTableName=) sink.writeFrame(last_transform) ``` ``` val options = JsonOptions( Map("path" -> , "partitionKeys" -> Seq("region", "year", "month", "day"), "enableUpdateCatalog" -> true)) val sink = glueContext.getSink("s3", options).withFormat("json") sink.setCatalogInfo(, ) sink.writeDynamicFrame(df) ``` クローラを再実行することなく、AWS Glue ETLジョブ自体を使用して、Data Catalog での新しいカタログテーブルの作成、変更されたスキーマによる既存のテーブルの更新、および新しいテーブルパーティションの追加が可能になりました。 ## テーブルスキーマの更新 Data Catalog テーブルのスキーマを上書きする場合は、次のいずれかを実行します。 + ジョブが終了したら、クローラを再実行し、テーブル定義も更新するようにクローラが設定されていることを確認します。クローラが終了したら、新しいパーティションをスキーマの更新とともにコンソールに表示します。詳細については、「[API を使用したクローラの設定](https://docs.aws.amazon.com/glue/latest/dg/crawler-configuration.html#crawler-configure-changes-api)」を参照してください。 + ジョブが終了すると、クローラを再実行することなく、コンソールで変更済みスキーマがすぐに表示されます。この機能は、次の例に示すように、ETL スクリプトに数行のコードを追加して有効にすることができます。このコードでは `enableUpdateCatalog` を true に設定し、`updateBehavior` を `UPDATE_IN_DATABASE` に設定しています。これは、ジョブ実行中にスキーマを上書きし、Data Catalog に新しいパーティションを追加することを示します。 ------ #### [ Python ] ``` additionalOptions = { "enableUpdateCatalog": True, "updateBehavior": "UPDATE_IN_DATABASE"} additionalOptions["partitionKeys"] = ["partition_key0", "partition_key1"] sink = glueContext.write_dynamic_frame_from_catalog(frame=last_transform, database=, table_name=, transformation_ctx="write_sink", additional_options=additionalOptions) job.commit() ``` ------ #### [ Scala ] ``` val options = JsonOptions(Map( "path" -> outputPath, "partitionKeys" -> Seq("partition_0", "partition_1"), "enableUpdateCatalog" -> true)) val sink = glueContext.getCatalogSink(database = nameSpace, tableName = tableName, additionalOptions = options) sink.writeDynamicFrame(df) ``` ------ テーブルスキーマが上書きされないようにして、新しいパーティションを追加する場合は、`updateBehavior` 値を `LOG` に設定することもできます。`updateBehavior` のデフォルト値は `UPDATE_IN_DATABASE` です。そのため、明示的に定義しない場合、テーブルスキーマは上書きされます。 `enableUpdateCatalog` が true に設定されていない場合、`updateBehavior` で選択したオプションに関係なく、ETL ジョブは Data Catalog 内のテーブルを更新しません。 ## 新しいテーブルの作成 同じオプションを使用して、Data Catalog で新しいテーブルを作成することもできます。`setCatalogInfo` を使用して、データベースと新しいテーブル名を指定できます。 ------ #### [ Python ] ``` sink = glueContext.getSink(connection_type="s3", path="s3://path/to/data", enableUpdateCatalog=True, updateBehavior="UPDATE_IN_DATABASE", partitionKeys=["partition_key0", "partition_key1"]) sink.setFormat("") sink.setCatalogInfo(catalogDatabase=, catalogTableName=) sink.writeFrame(last_transform) ``` ------ #### [ Scala ] ``` val options = JsonOptions(Map( "path" -> outputPath, "partitionKeys" -> Seq("", ""), "enableUpdateCatalog" -> true, "updateBehavior" -> "UPDATE_IN_DATABASE")) val sink = glueContext.getSink(connectionType = "s3", connectionOptions = options).withFormat("") sink.setCatalogInfo(catalogDatabase = “”, catalogTableName = “”) sink.writeDynamicFrame(df) ``` ------ ## 制限事項 次の制限事項に注意してください。 + Amazon Simple Storage Service (Amazon S3) のターゲットのみがサポートされています。 + `enableUpdateCatalog` 機能は、管理対象テーブルでは、サポートされていません。 + `json`、`csv`、`avro`、および `parquet` の形式のみがサポートされます。 + `parquet` 分類でテーブルを作成または更新するには、AWS Glue に最適化された DynamicFrames 用 parquet ライターを使用する必要があります。これは、次のいずれかの方法で実現できます。 + `parquet` 分類を使用してカタログ内の既存のテーブルを更新する場合は、更新前にテーブルでは `"useGlueParquetWriter"` テーブルプロパティを `true` に設定する必要があります。このプロパティは、AWS Glue API/SDK、コンソール、または Athena DDL ステートメントから設定できます。 ![\[AWS Glue コンソールのカタログテーブルプロパティの編集フィールド。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/edit-table-property.png) カタログテーブルプロパティを設定したら、次のコードスニペットを使用して新しいデータでカタログテーブルを更新します。 ``` glueContext.write_dynamic_frame.from_catalog( frame=frameToWrite, database="dbName", table_name="tableName", additional_options={ "enableUpdateCatalog": True, "updateBehavior": "UPDATE_IN_DATABASE" } ) ``` + テーブルがカタログ内にまだ存在しない場合は、`connection_type="s3"` を用いた `getSink()` メソッドをスクリプトで使用して、データを Amazon S3 に書き込むとともに、テーブルとそのパーティションをカタログに追加します。ワークフローに適切な `partitionKeys` と `compression` を指定します。 ``` s3sink = glueContext.getSink( path="s3://bucket/folder/", connection_type="s3", updateBehavior="UPDATE_IN_DATABASE", partitionKeys=[], compression="snappy", enableUpdateCatalog=True ) s3sink.setCatalogInfo( catalogDatabase="dbName", catalogTableName="tableName" ) s3sink.setFormat("parquet", useGlueParquetWriter=True) s3sink.writeFrame(frameToWrite) ``` + `glueparquet` フォーマットの値は、AWS Glue parquet ライターを有効にする従来のメソッドです。 + `updateBehavior` を `LOG` に設定した場合、`DynamicFrame` スキーマが Data Catalog テーブルのスキーマに定義されている列のサブセットと同等であるか、またはそのサブセットを含んでいる場合にのみ、新しいパーティションが追加されます。 + スキーマの更新は、パーティション化されていないテーブル (「partitionKeys」オプションを使用していない) ではサポートされていません。 + partitionKeys は、ETL スクリプトで渡されるパラメータと Data Catalog テーブルスキーマの partitionKeys で同等で、同じ順序でなければなりません。 + この機能は、現在、更新スキーマがネストされているテーブルの更新/作成をサポートしていません (例えば、構造体の内部の配列)。 詳細については、[Spark スクリプトのプログラミング](aws-glue-programming.md) を参照してください。 # ETL ジョブでの MongoDB 接続の操作 MongoDB の接続を作成し、その接続を AWS Glue ジョブで使用します。詳細については、「AWS Glue プログラミングガイド」の「[MongoDB 接続](aws-glue-programming-etl-connect-mongodb-home.md)」を参照してください。接続の `url`、`username`、および `password` は MongoDB 接続に保存されます。ETL ジョブスクリプトで `glueContext.getCatalogSource` という `additionalOptions` パラメータを使用して、その他のオプションを指定できます。その他のオプションには次のようなものがあります。 + `database`: (必須) 読み込み元の MongoDB データベース。 + `collection`: (必須) 読み込み元の MongoDB コレクション。 ETL ジョブスクリプト内に `database` および `collection` 情報を書き込むと、複数のジョブに同じ接続を使用できます。 1. AWS Glue Data Catalog 接続を MongoDB データソース用に作成します。接続パラメータの説明については、「["connectionType": "mongodb"](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-connect.html#aws-glue-programming-etl-connect-mongodb)」を参照してください。接続は、コンソール、API、または CLI を使用して作成できます。 1. AWS Glue Data Catalog でデータベースを作成して MongoDB データのテーブル定義を格納します。詳細については「[データベースの作成](define-database.md)」を参照してください。 1. MongoDB に接続するための接続内の情報を使用して、MongoDB 内のデータをクロールするクローラを作成します。クローラによって、ジョブで使用する MongoDB データベース内のテーブルを記述するテーブルが AWS Glue Data Catalog に作成されます。詳細については「[クローラーを使用したデータカタログへの入力](add-crawler.md)」を参照してください。 1. カスタムスクリプトを使用してジョブを作成します。ジョブは、コンソール、API、または CLI を使用して作成できます。詳細については、「[AWS Glue でジョブを追加する](https://docs.aws.amazon.com/glue/latest/dg/add-job.html)」を参照してください。 1. ジョブ用のデータターゲットを選択します。データターゲットを表すテーブルは、Data Catalog で定義することも、ジョブを実行するときに作成することもできます。ジョブを作成するときに、ターゲットの場所を選択します。ターゲットに接続が必要な場合、接続もジョブ内で参照されます。ジョブに複数のデータターゲットが必要な場合、後でスクリプトを編集して追加できます。 1. ジョブと生成されたスクリプトの引数を指定することで、ジョブ処理環境をカスタマイズします。 Data Catalog で定義されたテーブル構造に基づいて、MongoDB データベースから `DynamicFrame` を作成する例を次に示します。このコードは `additionalOptions` を使用して、追加のデータソースの情報を指定しています。 ------ #### [ Scala ] ``` val resultFrame: DynamicFrame = glueContext.getCatalogSource( database = catalogDB, tableName = catalogTable, additionalOptions = JsonOptions(Map("database" -> DATABASE_NAME, "collection" -> COLLECTION_NAME)) ).getDynamicFrame() ``` ------ #### [ Python ] ``` glue_context.create_dynamic_frame_from_catalog( database = catalogDB, table_name = catalogTable, additional_options = {"database":"database_name", "collection":"collection_name"}) ``` ------ 1. オンデマンドで、またはトリガーを使用してジョブを実行します。 # 列統計を使用したクエリのパフォーマンスの最適化 追加のデータパイプラインを設定することなく、Parquet、ORC、JSON、ION、CSV、XML などのデータ形式で AWS Glue Data Catalog テーブルの列レベルの統計を計算できます。列統計は、列内の値に関するインサイトを得ることで、データプロファイルを理解するのに役立ちます。 データカタログは、列値（最小値、最大値、null 値の合計、個別の値の合計、値の平均長、真値の合計出現数など）の統計の生成をサポートします。Amazon Redshift や Amazon Athena などの AWS 分析サービスでは、これらの列統計を使用してクエリの実行プランを生成でき、クエリのパフォーマンスを向上させる最適なプランを選択できます。 列統計の生成には次の 3 つのシナリオがあります。 **Auto** AWS Glue は、カタログレベルで列統計の自動生成をサポートしているため、AWS Glue Data Catalog で新しいテーブルの統計を自動的に生成できます。 **Scheduled (スケジュール済み)** AWS Glue は、列統計の生成を定期的なスケジュールで自動的に実行できるようにサポートします。 スケジュールされた統計計算では、列統計タスクは、最小、最大、平均などのテーブルレベルの統計全体を新しい統計で更新し、クエリエンジンに正確かつ最新の統計を提供して、クエリの実行を最適化します。 **[オンデマンド]** このオプションを使用して、必要に応じて列統計をオンデマンドで生成します。これは、アドホック分析や統計をすぐに計算する必要がある場合に役立ちます。 AWS Glue コンソール、AWS CLI、AWS Glue API オペレーションを使用して列統計の生成タスクを実行するように設定できます。プロセスを開始すると、AWS Glue はバックグラウンドで Spark ジョブを開始し、データカタログ内の AWS Glue テーブルメタデータを更新します。列統計は、AWS Glue コンソールもしくは AWS CLI を使用して、または [GetColumnStatisticsForTable](https://docs.aws.amazon.com/glue/latest/webapi/API_GetColumnStatisticsForTable.html) API オペレーションを呼び出すことによって表示できます。 **注記** Lake Formation の許可を使用してテーブルに対するアクセスを制御している場合、列統計タスクによって引き受けられるロールには、統計を生成するための完全なテーブルアクセスが必要です。 次の動画では、列統計を使用してクエリのパフォーマンスを向上させる方法が示されます。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/zUHEXJdHUxs?si=HjyhpoALR6RXJz2i/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/zUHEXJdHUxs?si=HjyhpoALR6RXJz2i) **Topics** + [列統計を生成するための前提条件](column-stats-prereqs.md) + [列統計の自動生成](auto-column-stats-generation.md) + [スケジュールで列統計の生成](generate-column-stats.md) + [オンデマンドでの列統計の生成](column-stats-on-demand.md) + [列統計の表示](view-column-stats.md) + [列統計タスクの実行の表示](view-stats-run.md) + [列統計タスクの実行の停止](stop-stats-run.md) + [列統計の削除](delete-column-stats.md) + [考慮事項と制限事項](column-stats-notes.md) # 列統計を生成するための前提条件 列統計を生成または更新するために、統計生成タスクはユーザーに代わって AWS Identity and Access Management (IAM) ロールを引き受けます。ロールに付与された許可に基づいて、列統計生成タスクは Amazon S3 データストアからデータを読み取ることができます。 AWS Glue では、列統計生成タスクを設定するときに、`AWSGlueServiceRole` AWS 管理ポリシーと指定されたデータソースに必要なインラインポリシーを含むロールを作成できます。 列統計の生成に既存のロールを指定する場合は、そのロールに `AWSGlueServiceRole` ポリシーまたは同等のポリシー (またはこのポリシーのスコープダウンバージョン)、および必要なインラインポリシーが含まれてることを確認します。次のステップに従って、新しい IAM ロールを作成します。 **注記** Lake Formation によって管理されるテーブルの統計を生成するには、統計の生成に使用される IAM ロールに完全なテーブルアクセスが必要です。　 AWS Glue では、列統計生成タスクを設定するときに、`AWSGlueServiceRole` AWS 管理ポリシーと指定されたデータソースに必要なインラインポリシーを含むロールを作成できます。また、ロールを作成して、以下のポリシーにリストされているアクセス許可をアタッチし、そのロールを列統計生成タスクに追加することもできます。 **列統計を生成するための IAM ロールを作成するには** 1. IAM ロールを作成するには、「[AWS Glue の IAM ロールを作成する](https://docs.aws.amazon.com/glue/latest/dg/create-an-iam-role.html)」を参照してください。 1. 既存のロールを更新するには、IAM コンソールで、列統計の生成プロセスで使用されている IAM ロールにアクセスします。 1. **[許可を追加]** セクションで、**[ポリシーをアタッチ]** を選択します。新しく開いたブラウザウィンドウで、`AWSGlueServiceRole` AWS マネージドポリシーを選択します。 1. Amazon S3 のデータの場所からデータを読み取るための許可も含める必要があります。 **[Add permissions]** (アクセス許可の追加) セクションで、**[Create policy]** (ポリシーの作成) を選択します。新しく開いたブラウザウィンドウで、ロールで使用する新しいポリシーを作成します。 1. **[ポリシーを作成]** ページで、**[JSON]** タブを選択します。次の `JSON` コードをポリシーエディタフィールドにコピーします。 **注記** 次のポリシーでは、アカウント ID を有効な AWS アカウント に置き換え、`region` をテーブルのリージョンに置き換え、`bucket-name` を Amazon S3 バケット名に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "S3BucketAccess", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*", "arn:aws:s3:::amzn-s3-demo-bucket" ] } ] } ``` ------ 1. (オプション) Lake Formation の許可を使用してデータに対するアクセスを提供している場合、IAM ロールには `lakeformation:GetDataAccess` 許可が必要です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "LakeFormationDataAccess", "Effect": "Allow", "Action": "lakeformation:GetDataAccess", "Resource": [ "*" ] } ] } ``` ------ Amazon S3 のデータの場所が Lake Formation に登録されており、テーブルに対する `IAM_ALLOWED_PRINCIPALS` グループ許可が、列統計生成タスクによって引き受けられる IAM ロールに付与されていない場合、そのロールには、テーブルに対する Lake Formation `ALTER` および `DESCRIBE` 許可が必要です。Amazon S3 バケットの登録に使用されるロールには、テーブルに対する Lake Formation `INSERT` および `DELETE` 許可が必要です。 Amazon S3 のデータの場所が Lake Formation に登録されておらず、テーブルに対する `IAM_ALLOWED_PRINCIPALS` グループ許可が IAM ロールに付与されていない場合、そのロールには、テーブルに対する Lake Formation `ALTER`、`DESCRIBE`、`INSERT`、および `DELETE` 許可が必要です。 1. カタログレベルの `Automatic statistics generation` オプションを有効にしている場合、IAM ロールには、デフォルトのデータカタログに対する `glue:UpdateCatalog` アクセス許可または Lake Formation `ALTER CATALOG` アクセス許可が必要になります。カタログのプロパティは、`GetCatalog` オペレーションを使用して確認できます。 1. (オプション) 暗号化された Amazon CloudWatch Logs を書き込む列統計生成タスクには、キーポリシーで次の許可が必要です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "CWLogsKmsPermissions", "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", "logs:AssociateKmsKey" ], "Resource": [ "arn:aws:logs:us-east-1:111122223333:log-group:/aws-glue:*" ] }, { "Sid": "KmsPermissions", "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Decrypt", "kms:Encrypt" ], "Resource": [ "arn:aws:kms:us-east-1:111122223333:key/arn of key used for ETL cloudwatch encryption" ], "Condition": { "StringEquals": { "kms:ViaService": [ "glue.us-east-1.amazonaws.com" ] } } } ] } ``` ------ 1. 列統計の実行に使用するロールには、そのロールに対する `iam:PassRole` のアクセス許可が必要です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/columnstats-role-name" ] } ] } ``` ------ 1. 列統計を生成するための IAM ロールを作成する場合、そのロールには、サービスがそのロールを引き受けることを可能にする次の信頼ポリシーも必要です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TrustPolicy", "Effect": "Allow", "Principal": { "Service": "glue.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ # 列統計の自動生成 列統計を自動で生成することにより、AWS Glue Data Catalog の新しいテーブルで、統計をスケジュールして自動的に計算することができます。統計の自動生成を有効にすると、データカタログが、特定のデータ形式 (Parquet、JSON、CSV、XML、ORC、ION、Apache Iceberg など) を持つ新しいテーブルを、それぞれのバケットパスとともに検出します。1 回限りのカタログ設定を使用すると、データカタログがこれらのテーブルの統計を生成します。 データレイクの管理者は、Lake Formation コンソールでデフォルトのカタログを選択し、`Optimization configuration` オプションを使用してテーブル統計を有効にすることで、統計の生成を設定できます。データカタログで新しいテーブルを作成したり既存のテーブルを更新したりすると、データカタログが Apache Iceberg テーブルの個別値の数 (NDV) と、サポートされている他のファイル形式の NULL、最大長、最小長、平均長など、追加の統計を毎週収集します。 テーブルレベルで統計生成を設定している場合、またはテーブルの統計生成の設定を以前に削除している場合、これらテーブル固有の設定は、列統計の自動生成のデフォルトのカタログ設定より優先されます。 統計の自動生成タスクは、テーブル内のレコードの 50% を分析して統計を計算します。列統計の自動生成により、データカタログは Amazon Athena や Amazon Redshift Spectrum などのクエリエンジンで使用できるメトリクスを週単位で保守でき、クエリのパフォーマンスを向上させ潜在的なコストを削減することができます。AWS Glue API またはコンソールを使用して統計の生成をスケジュールできるため、手動による介入なしにプロセスを自動的に実行できます。 **Topics** + [カタログレベルでの統計の自動生成を有効化](enable-auto-column-stats-generation.md) + [自動化されたテーブルレベルの設定を表示](view-auto-column-stats-settings.md) + [カタログレベルの列統計の生成の無効化](disable-auto-column-stats-generation.md) # カタログレベルでの統計の自動生成を有効化 データカタログのすべての新しい Apache Iceberg テーブルと、OTF 以外のテーブル (Parquet、JSON、CSV、XML、ORC、ION) 形式のテーブルに対して、列統計の自動生成を有効にできます。テーブルを作成すると、列統計の設定を手動で明示的に更新することもできます。 データカタログの設定を更新してカタログレベルを有効にするには、使用する IAM ロールに、ルートカタログに対する `glue:UpdateCatalog` アクセス許可または AWS Lake Formation `ALTER CATALOG` アクセス許可が必要になります。カタログのプロパティは、`GetCatalog` API を使用して確認できます。 ------ #### [ AWS マネジメントコンソール ] **アカウントレベルで列統計の自動生成を有効にするには** 1. Lake Formation コンソール (‭‬[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)‬) を開きます。 1. 左のナビゲーションペインで **[カタログ]** を選択します。 1. **[カタログの概要]** ページの **[最適化の設定]** で **[編集]** を選択します。 ![\[このスクリーンショットは、列統計の生成に使用できるオプションを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/edit-column-stats-auto.png) 1. **[テーブル最適化の設定]** ページで、**[カタログのテーブルの自動統計生成を有効にする]** を選択します。 ![\[このスクリーンショットは、列統計の生成に使用できるオプションを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/edit-optimization-option.jpg) 1. 既存の IAM ロールを選択するか、列統計タスクを実行するための必要なアクセス許可を持つ新しいロールを作成します。 1. **[送信]** を選択します。 ------ #### [ AWS CLI ] AWS CLI を使ってカタログレベルの統計収集を有効にすることもできます。AWS CLI を使用してテーブルレベルの統計収集を設定するには、次のコマンドを実行します。 ``` aws glue update-catalog --cli-input-json '{ "name": "123456789012", "catalogInput": { "description": "Updating root catalog with role arn", "catalogProperties": { "customProperties": { "ColumnStatistics.RoleArn": "arn:aws:iam::"123456789012":role/service-role/AWSGlueServiceRole", "ColumnStatistics.Enabled": "true" } } } }' ``` 上記のコマンドは AWS Glue の `UpdateCatalog` オペレーションを呼び出します。これにより、カタログレベルの統計を生成するために、次のキーと値のペアを持つ `CatalogProperties` 構造が取り込まれます。 + ColumnStatistics.RoleArn – カタログレベルの統計生成でトリガーされるすべてのタスクで使用する IAM ロール ARN + ColumnStatistics.Enabled – カタログレベルの設定が有効か無効かを示すブール値 ------ # 自動化されたテーブルレベルの設定を表示 カタログレベルの統計収集が有効になっている場合、Apache Hive テーブルまたは Apache Iceberg テーブルが、AWS マネジメントコンソール、SDK、AWS Glue クローラー のいずれかで `CreateTable` または `UpdateTable` API を介して作成または更新されるたびに、そのテーブルに対して同等のテーブルレベルの設定が作成されます。 統計の自動生成が有効になっているテーブルは、次のいずれかのプロパティに従う必要があります。 + org.apache.hadoop で始まり、`TableType` が `EXTERNAL_TABLE` である `InputSerdeLibrary` を使用する + `com.amazon.ion` で始まり、`TableType` が `EXTERNAL_TABLE` である `InputSerdeLibrary` を使用する + 自身のパラメータ構造に table\$1type: "ICEBERG" を含める テーブルを作成または更新したら、テーブルの詳細を検証して統計の生成を確定できます。`Statistics generation summary` では、`Schedule` プロパティが `AUTO` に設定され、`Statistics configuration` 値が `Inherited from catalog` を示しています。次の設定を持つテーブル設定は、Glue によって内部で自動的にトリガーされます。 ![\[カタログレベルの統計収集を含む Hive テーブルのイメージが適用され、統計が収集されました。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/auto-stats-summary.png) # カタログレベルの列統計の生成の無効化 新しいテーブルの列統計の自動生成は、AWS Lake Formation コンソール、`glue:UpdateCatalogSettings` API、`glue:DeleteColumnStatisticsTaskSettings` API のいずれかを使用して無効にすることができます。 **アカウントレベルで列統計の自動生成を無効にするには** 1. Lake Formation コンソール (‭‬[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)‬) を開きます。 1. 左のナビゲーションペインで **[カタログ]** を選択します。 1. **[カタログの概要]** ページの **[最適化の設定]** で **[編集]** を選択します。 1. **[テーブル最適化の設定]** ページで、**[カタログのテーブルの自動統計生成を有効にする]** の選択を解除します。 1. [**Submit**] を選択します。 # スケジュールで列統計の生成 以下の手順に従い、AWS Glue コンソール、AWS CLI、[CreateColumnStatisticsTaskSettings](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-column-statistics.html#aws-glue-api-crawler-column-statistics-CreateColumnStatisticsTaskSettings) オペレーションを使用して、AWS Glue Data Catalog で列統計を生成するスケジュールを設定します。 ------ #### [ Console ] **コンソールを使用して列統計を生成するには** 1. AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) にサインインします。 1. データカタログテーブルを選択します。 1. リストからテーブルを選択します。 1. **[テーブル]** ページの下部にある **[列統計]** タブを選択します。 1. **[アクション]** の **[列統計]** で **[スケジュールに応じて生成]** を選択することもできます。 1. **[スケジュールに応じて統計を生成]** ページで、頻度および開始時間を選択して、列統計タスクを実行する定期的なスケジュールを設定します。時間単位、日単位、週単位で頻度を選択するか、cron 式を定義してスケジュールを指定できます。 cron 式は、スペースで区切られた 6 つのフィールドで構成されるスケジュールパターンを表す文字列で、「\$1 \$1 \$1 \$1 \$1 」のように表示されます。例えば、毎日午前 0 時にタスクを実行する場合、cron 式は「0 0 \$1 \$1 ? \$1」になります。 詳細については、「[Cron 式](https://docs.aws.amazon.com/glue/latest/dg/monitor-data-warehouse-schedule.html#CronExpressions)」を参照してください。 ![\[このスクリーンショットは、列統計の生成に使用できるオプションを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/generate-column-stats-schedule.png) 1. 次に、列のオプションを選択して統計を生成します。 + **すべての列** - テーブル内のすべての列の統計を生成するには、このオプションを選択します。 + **選択された列** – 特定の列の統計を生成するには、このオプションを選択します。ドロップダウンリストから列を選択できます。 1. IAM ロールを選択するか、統計を生成するアクセス許可がある既存のロールを作成します。AWS Glue はこのロールを引き受けて列統計を生成します。 ユーザーに代わって、AWS Glue コンソールにロールを作成させる手取り早いアプローチがあります。作成されるロールは列統計の生成専用に使用され、`AWSGlueServiceRole` AWS 管理ポリシーに加え、指定されたデータソースに必要なインラインポリシーが含まれています。 列統計の生成に既存のロールを指定する場合は、そのロールに `AWSGlueServiceRole` ポリシーまたは同等のポリシー (またはこのポリシーのスコープダウンバージョン)、および必要なインラインポリシーが含まれてることを確認します。 1. (オプション) 次に、ログの保管中の暗号化を有効にするセキュリティ設定を選択します。 1. (オプション) テーブルから行の特定の割合のみを指定し、統計を生成することで、サンプルサイズを選択できます。デフォルトは、すべての行です。上矢印と下矢印を使用してパーセント (%) の値を増減します。 正確な統計を計算するには、テーブル内のすべての行を含めることをお勧めします。近似値が許容される場合にのみ、サンプル行を使用して列統計を生成します。 1. **[統計を生成]** を選択して、列統計の生成タスクを実行します。 ------ #### [ AWS CLI ] 次の AWS CLI 例を使用して、列統計の生成スケジュールを作成できます。database-name、table-name、role は必須パラメータであり、オプションのパラメータは schedule、column-name-list、catalog-id、sample-size、security-configuration です。 ``` aws glue create-column-statistics-task-settings \ --database-name 'database_name' \ --table-name table_name \ --role 'arn:aws:iam::123456789012:role/stats-role' \ --schedule 'cron(0 0-5 14 * * ?)' \ --column-name-list 'col-1' \ --catalog-id '123456789012' \ --sample-size '10.0 ' \ --security-configuration 'test-security' ``` [StartColumnStatisticsTaskRun](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-column-statistics.html#aws-glue-api-crawler-column-statistics-StartColumnStatisticsTaskRun) オペレーションを呼び出して列統計を生成することもできます。 ------ # 列統計の生成のスケジュール管理 AWS Glue の列統計の生成におけるスケジュールの更新、開始、停止、削除などのスケジューリング操作を管理できます。AWS Glue コンソール、AWS CLI、[AWS Glue 列統計の API 操作](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-column-statistics.html)を使用して、これらのタスクを実行できます。 **Topics** + [列統計の生成スケジュールの更新](#update-column-stats-shedule) + [列統計の生成スケジュールの停止](#stop-column-stats-schedule) + [列統計の生成スケジュールの再開](#resume-column-stats-schedule) + [列統計の生成スケジュールの削除](#delete-column-stats-schedule) ## 列統計の生成スケジュールの更新 作成後に列統計の生成タスクがトリガーされるように、スケジュールを更新できます。AWS Glue コンソールまたは AWS CLI を使用するか、[UpdateColumnStatisticsTaskSettings](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-column-statistics.html#aws-glue-api-crawler-column-statistics-UpdateColumnStatisticsTaskSettings) 操作を実行してテーブルのスケジュールを更新できます。スケジュールタイプ (オンデマンドまたはスケジュールされたもの) やその他のオプションのパラメータなど、既存のスケジュールのパラメータを変更できます。 ------ #### [ AWS マネジメントコンソール ] **列統計の生成タスクの設定を更新する方法** 1. AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) にサインインします。 1. テーブルリストで、更新するテーブルを選択します。 1. テーブルの詳細ページの下部セクションで、**[列統計]** を選択します。 1. **[アクション]** で **[編集]** を選択し、スケジュールを更新します。 1. スケジュールに必要な変更を行い、**[保存]** を選択します。 ------ #### [ AWS CLI ] コンソールで AWS Glue の統計生成機能を使用していない場合、`update-column-statistics-task-settings` コマンドを使用してスケジュールを手動で更新できます。次の例は、AWS CLI を使用して列統計を更新する方法を示しています。 ``` aws glue update-column-statistics-task-settings \ --database-name 'database_name' \ --table-name 'table_name' \ --role arn:aws:iam::123456789012:role/stats_role \ --schedule 'cron(0 0-5 16 * * ?)' \ --column-name-list 'col-1' \ --sample-size '20.0' \ --catalog-id '123456789012'\ --security-configuration 'test-security' ``` ------ ## 列統計の生成スケジュールの停止 増分統計が不要になった場合、スケジュールされた生成を停止してリソースおよびコストを節約できます。スケジュールを一時停止しても、以前に生成された統計は影響されません。必要に応じてスケジュールはいつでも再開できます。 ------ #### [ AWS マネジメントコンソール ] **列統計の生成タスクのスケジュールを停止する方法** 1. AWS Glue コンソールで、[データカタログ] の下の **[テーブル]** を選択します。 1. 列統計を含むテーブルを選択します。 1. **[テーブルの詳細]** ページで、**[列統計]** を選択します。 1. **[アクション]** で、**[スケジュールされた生成]** および **[一時停止]** を選択します。 1. **[一時停止]** を選択して確認します。 ------ #### [ AWS CLI ] AWS CLI を使用して列統計タスクの実行スケジュールを停止するには、次のコマンドを使用できます。 ``` aws glue stop-column-statistics-task-run-schedule \ --database-name ''database_name' \ --table-name 'table_name' ``` `database_name` および `table_name` は、列統計のタスク実行スケジュールを停止するデータベースおよびテーブルの実際の名前に置き換えます。 ------ ## 列統計の生成スケジュールの再開 統計の生成スケジュールを一時停止した場合、AWS Glue は必要に応じてスケジュールを再開できるようにします。AWS Glue コンソール、AWS CLI、[StartColumnStatisticsTaskRunSchedule](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-column-statistics.html#aws-glue-api-crawler-column-statistics-StartColumnStatisticsTaskRunSchedule) 操作を使用してスケジュールを再開できます。 ------ #### [ AWS マネジメントコンソール ] **列統計の生成スケジュールを再開する方法** 1. AWS Glue コンソールで、[データカタログ] の下の **[テーブル]** を選択します。 1. 列統計を含むテーブルを選択します。 1. **[テーブルの詳細]** ページで、**[列統計]** を選択します。 1. **[アクション]** で **[スケジュールされた生成]** を選択し、**[再開]** を選択します。 1. **[再開]** を選択して確認します。 ------ #### [ AWS CLI ] `database_name` および `table_name` は、列統計のタスク実行スケジュールを停止するデータベースおよびテーブルの実際の名前に置き換えます。 ``` aws glue start-column-statistics-task-run-schedule \ --database-name 'database_name' \ --table-name 'table_name' ``` ------ ## 列統計の生成スケジュールの削除 最適なクエリパフォーマンスを得るために最新の統計を維持することが一般的に推奨されますが、自動生成スケジュールを削除すると、有益になる特定のユースケースがあります。 + データが比較的に静的な状態が維持される場合、既存の列統計が長期間にわたって正確さが維持される可能性があり、頻繁な更新の必要性が軽減されます。スケジュールを削除すると、変更されていないデータに関する統計の再生成に関連する、不要なリソース消費およびオーバーヘッドを防ぐことができます。 + 統計の生成より手動の制御が望ましい場合。自動スケジュールを削除することで、特定の間隔または大幅なデータ変更後に、管理者は列統計を選択的に更新し、メンテナンス戦略およびリソース割り当てのニーズに合わせてプロセスを調整することができます。 ------ #### [ AWS マネジメントコンソール ] **列統計の生成のスケジュールを削除するには:** 1. AWS Glue コンソールで、[データカタログ] の下の **[テーブル]** を選択します。 1. 列統計を含むテーブルを選択します。 1. **[テーブルの詳細]** ページで、**[列統計]** を選択します。 1. **[アクション]** で、**[スケジュールされた生成]** と **[削除]** を選択します。 1. **[削除]** を選択して確定します。 ------ #### [ AWS CLI ] `database_name` および `table_name` は、列統計のタスク実行スケジュールを停止するデータベースおよびテーブルの実際の名前に置き換えます。 [DeleteColumnStatisticsTaskSettings](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-column-statistics.html#aws-glue-api-crawler-column-statistics-DeleteColumnStatisticsTaskSettings) の API オペレーションまたは AWS CLI を使用して、列統計のスケジュールを削除できます。次の例では、AWS Command Line Interface (AWS CLI) を使用して列統計を生成するスケジュールを削除する方法について示されています。 ``` aws glue delete-column-statistics-task-settings \ --database-name 'database_name' \ --table-name 'table_name' ``` ------ # オンデマンドでの列統計の生成 スケジュールを設定せず、AWS Glue Data Catalog テーブルタスクの列統計タスクをオンデマンドで実行できます。アドホック分析や統計をすぐに計算する必要がある場合、このオプションは便利です。 AWS Glue コンソールまたは AWS CLI を使用し、データカタログのテーブルに列統計をオンデマンドで生成するには、以下の手順を実行してください。 ------ #### [ AWS マネジメントコンソール ] **コンソールを使用して列統計を生成するには** 1. AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) にサインインします。 1. データカタログテーブルを選択します。 1. リストからテーブルを選択します。 1. **[アクション]** メニューで **[統計を生成]** を選択します。 **[テーブル]** ページの下部セクションにある **[列統計]** タブの **[生成]** または **[オンデマンドで生成]** オプションを選択することもできます。 1. [スケジュールで列統計の生成](generate-column-stats.md) のステップ 7～11 に従ってテーブルの列統計を生成します。 1. **[統計を生成]** ページで、次のオプションを指定します。 ![\[このスクリーンショットは、列統計の生成に使用できるオプションを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/generate-column-stats.png) + **すべての列** - テーブル内のすべての列の統計を生成するには、このオプションを選択します。 + **選択された列** – 特定の列の統計を生成するには、このオプションを選択します。ドロップダウンリストから列を選択できます。 + **IAM ロール** – 列統計の生成タスクを実行するために必要なアクセス許可ポリシーを持つ **[新しい IAM ロールを作成]** を選択します。[アクセス許可の詳細を表示] を選択して、ポリシーステートメントを確認します。リストから IAM ロールを選択することもできます。必要な許可の詳細については、「[列統計を生成するための前提条件](column-stats-prereqs.md)」を参照してください。 AWS Glue は、統計を生成するために指定したロールのアクセス許可を引き受けます。 AWS Glue へのロール提供の詳細については、「[AWS Glue のアイデンティティベースポリシー」を参照してください。](https://docs.aws.amazon.com/glue/latest/dg/security_iam_service-with-iam.html#security_iam_service-with-iam-id-based-policies) + (オプション) 次に、ログの保管中の暗号化を有効にするセキュリティ設定を選択します。 + **サンプル行** – テーブルから特定の割合の行のみを選択して統計を生成します。デフォルトは、すべての行です。上矢印と下矢印を使用してパーセント (%) の値を増減します。 **注記** 正確な統計を計算するには、テーブル内のすべての行を含めることをお勧めします。近似値が許容される場合にのみ、サンプル行を使用して列統計を生成します。 **[統計を生成]** を選択してタスクを実行します。 ------ #### [ AWS CLI ] このコマンドにより、指定されたテーブルに対して列統計タスクの実行がトリガーされます。データベース名、テーブル名、統計を生成するアクセス許可がある IAM ロールを指定する必要があり、必要に応じて統計の計算用に列名およびサンプルサイズの割合を指定します。 ``` aws glue start-column-statistics-task-run \ --database-name 'database_name \ --table-name 'table_name' \ --role 'arn:aws:iam::123456789012:role/stats-role' \ --column-name 'col1','col2' \ --sample-size 10.0 ``` このコマンドにより、指定されたテーブルの列統計を生成するタスクが開始されます。 ------ ## オンデマンドで列統計の更新 列統計を最新に維持することは、クエリオプティマイザーが効率的な実行計画を生成し、クエリパフォーマンスの向上、リソース消費量の削減、システム全体のパフォーマンス向上を実現するうえで不可欠です。既存の統計が古くなる可能性をもたらす大幅なデータ変更 (一括のロードや広範な変更など) の後に、このプロセスは特に重要です。 列の統計を更新するには、AWS Glue コンソールから **[統計を生成]** タスクを明示的に実行する必要があります。データカタログは統計を自動的に更新しません。 コンソールで AWS Glue の統計生成機能を使用していない場合は、[UpdateColumnStatisticsForTable](https://docs.aws.amazon.com/glue/latest/webapi/API_UpdateColumnStatisticsForTable.html) API オペレーションまたは AWS CLI を使用して列統計を手動で更新できます。次の例は、AWS CLI を使用して列統計を更新する方法を示しています。 ``` aws glue update-column-statistics-for-table --cli-input-json: { "CatalogId": "111122223333", "DatabaseName": "database_name", "TableName": "table_name", "ColumnStatisticsList": [ { "ColumnName": "col1", "ColumnType": "Boolean", "AnalyzedTime": "1970-01-01T00:00:00", "StatisticsData": { "Type": "BOOLEAN", "BooleanColumnStatisticsData": { "NumberOfTrues": 5, "NumberOfFalses": 5, "NumberOfNulls": 0 } } } ] } ``` # 列統計の表示 統計が正常に生成されると、データカタログは、Amazon Athena と Amazon Redshift のコストベースのオプティマイザーがクエリを実行する際に最適な選択を行うことができるように、この情報を保存します。統計は列のタイプによって異なります。 ------ #### [ AWS マネジメントコンソール ] **テーブルの列統計を表示するには** + 列統計タスクを実行すると、**[テーブルの詳細]** ページの **[列統計]** タブにテーブルの統計が表示されます。 ![\[スクリーンショットは、最新の実行から生成された列を示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/view-column-stats.png) 次の統計を使用できます。 + [列名]: 統計を生成するために使用される列名 + [最終更新日時]: 統計が生成された日時 + [平均長]: 列内の値の平均長 + [個別の値]: 列内の個別の値の合計数。列内の個別の値の数を 5% の相対誤差で推定します。 + [最大値]: 列内の最大値。 + [最小値]: 列内の最小値。 + [最大長]: 列内の最大値の長さ。 + [Null 値]: 列内の null 値の合計数。 + [True 値]: 列内の true 値の合計数。 + [False 値]: 列内の false 値の合計数。 + [numFiles]: テーブル内のファイルの合計数。この値は、**[詳細プロパティ]** タブで使用できます。 ------ #### [ AWS CLI ] 次の例は、AWS CLI を使用して列統計を取得する方法を示しています。 ``` aws glue get-column-statistics-for-table \ --database-name database_name \ --table-name table_name \ --column-names ``` [GetColumnStatisticsForTable](https://docs.aws.amazon.com/glue/latest/webapi/API_GetColumnStatisticsForTable.html) API オペレーションを使用して列統計を表示することもできます。 ------ # 列統計タスクの実行の表示 列統計タスクを実行した後、AWS Glue コンソール、AWS CLI、または [GetColumnStatisticsTaskRuns](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-column-statistics.html#aws-glue-api-crawler-column-statistics-GetColumnStatisticsTaskRun) オペレーションを使用して、テーブルのタスク実行の詳細を調査できます。 ------ #### [ Console ] **列統計タスクの実行の詳細を表示するには** 1. AWS Glue コンソールで、[データカタログ] の下の **[テーブル]** を選択します。 1. 列統計を含むテーブルを選択します。 1. **[テーブルの詳細]** ページで、**[列統計]** を選択します。 1. **[実行を表示]** を選択します。 指定されたテーブルに関連付けられたすべての実行に関する情報を確認できます。 ![\[スクリーンショットは、列統計の生成に使用できるオプションを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/view-column-stats-task-runs.png) ------ #### [ AWS CLI ] 次の例では、`DatabaseName` と `TableName` の値を、実際のデータベースとテーブルの名前に置き換えます。 ``` aws glue get-column-statistics-task-runs --input-cli-json file://input.json { "DatabaseName": "database_name", "TableName": "table_name" } ``` ------ # 列統計タスクの実行の停止 テーブルについての列統計タスクの実行は、AWS Glue コンソール、AWS CLI、または [StopColumnStatisticsTaskRun](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-column-statistics.html#aws-glue-api-crawler-column-statistics-StopColumnStatisticsTaskRun) オペレーションを使用して停止できます。 ------ #### [ Console ] **列統計タスクの実行を停止するには** 1. AWS Glue コンソールで、[データカタログ] の下の **[テーブル]** を選択します。 1. 列統計タスクの実行が進行中のテーブルを選択します。 1. **[テーブルの詳細]** ページで、**[列統計]** を選択します。 1. **[停止]** を選択します。 実行が完了する前にタスクを停止すると、テーブルの列統計は生成されません。 ------ #### [ AWS CLI ] 次の例では、`DatabaseName` と `TableName` の値を、実際のデータベースとテーブルの名前に置き換えます。 ``` aws glue stop-column-statistics-task-run --input-cli-json file://input.json { "DatabaseName": "database_name", "TableName": "table_name" } ``` ------ # 列統計の削除 [DeleteColumnStatisticsForTable](https://docs.aws.amazon.com/glue/latest/webapi/API_DeleteColumnStatisticsForTable.html) API オペレーションまたは AWS CLI を使用して、列統計を削除できます。次の例は、AWS Command Line Interface (AWS CLI) を使用して列統計を削除する方法を示しています。 ``` aws glue delete-column-statistics-for-table \ --database-name 'database_name' \ --table-name 'table_name' \ --column-name 'column_name' ``` # 考慮事項と制限事項 列統計の生成には、次の考慮事項と制限事項が適用されます。 **考慮事項** + サンプリングを使用して統計を生成すると、実行時間は短縮されますが、不正確な統計が生成される可能性があります。 + データカタログは、異なるバージョンの統計を保存しません。 + テーブルごとに一度に 1 つの統計生成タスクのみを実行できます。 + データカタログに登録されているカスタマー AWS KMS キーを使用してテーブルが暗号化されている場合、AWS Glue は同じキーを使用して統計を暗号化します。 **列統計タスクは、次の場合に統計の生成をサポートします。** + 完全なテーブル許可が IAM ロールに付与されている場合 (IAM または Lake Formation)。 + Lake Formation ハイブリッドアクセスモードを使用するテーブルに対する許可が IAM ロールに付与されている場合。 **列統計タスクは、次についての統計の生成をサポートしていません。** + Lake Formation のセルベースのアクセスコントロールを備えたテーブル + トランザクションのデータレイク – Linux Foundation Delta Lake、Apache Hudi + フェデレーテッドデータベース内のテーブル - Hive メタストア、Amazon Redshift データ共有 + ネストされた列、配列、および構造体のデータ型。 + 別のアカウントからユーザーと共有されるテーブル # Data Catalog の暗号化 AWS Key Management Service (AWS KMS) によって管理される暗号化キーを使用して、保管中の AWS Glue Data Catalog に保存されているメタデータを保護できます。**データカタログ設定**を使用して、新しいデータカタログのデータカタログ暗号化を有効にできます。必要に応じて、既存のデータカタログの暗号化を有効または無効にできます。有効にすると、AWS Glue はカタログに書き込まれたすべての新しいメタデータを暗号化しますが、既存のメタデータは暗号化されません。 データカタログの暗号化の詳細については、「[Data Catalog の暗号化](encrypt-glue-data-catalog.md)」を参照してください。 # Lake Formation を使用したデータカタログの保護 AWS Lake Formation は、AWS で簡単にセキュアなデータレイクを構築できるサービスです。きめ細かなアクセスコントロール許可を定義することで、データレイクを作成および安全に管理するための一元的な場所を提供します。Lake Formation は、データカタログを使用して、テーブル定義、スキーマ情報、データアクセスコントロール設定など、データレイクに関するメタデータを保存および取得します。 メタデータテーブルまたはデータベースの Amazon S3 データロケーションを Lake Formation に登録し、それを使用してデータカタログリソースに対するメタデータレベルのアクセス許可を定義できます。また、Lake Formation を使用して、統合された分析エンジンに代わって、Amazon S3 に保存されている基盤となるデータへのストレージアクセス許可も管理できます。 詳細については、「[AWS Lake Formation とは](lake-formation/latest/dg/what-is-lake-formation.html)」を参照してください。 # AWS Glue での AWS Glue Data Catalog ビューの使用 AWS Glue Data Catalog ではビューを作成および管理できます。これは一般的に AWS Glue Data Catalog ビューと呼ばれます。これらのビューは複数の SQL クエリエンジンをサポートしているため、Amazon Athena、Amazon Redshift、AWS Glue などのさまざまな AWS サービス間で同じビューにアクセスできるため便利です。Apache Iceberg、Apache Hudi、Delta Lake に基づくビューを使用できます。 データカタログでビューを作成することで、AWS Lake Formation でのリソース許可とタグベースのアクセスコントロールを使用して、データカタログビューへのアクセスを許可できます。このアクセスコントロール方法を使用すれば、ビューの作成時に参照したテーブルへの追加のアクセスを設定する必要はありません。アクセス許可を付与するこの方法は、definer セマンティクスと呼ばれ、これらのビューは definer ビューと呼ばれます。AWS Lake Formation でのアクセスコントロールの詳細は、「AWS Lake Formation デベロッパーガイド」の「[Granting and revoking permissions on Data Catalog resources](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html)」を参照してください。 データカタログビューは、次のユースケースに役立ちます。 + **細やかなアクセス制御** – ユーザーが必要とするアクセス許可に基づいてデータアクセスを制限するビューを作成できます。例えば、データカタログのビューを使用して、人事 (HR) 部門に属さない従業員が個人を特定できる情報 (PII) を表示できないようにすることができます。 + **完全なビュー定義** – データカタログのビューに特定のフィルターを適用することで、ビュー内のデータレコードを常に完全な状態にすることができます。 + **セキュリティの強化** – ビューの作成に使用するクエリ定義は完全である必要があります。これにより、データカタログのビューが有害なアクターによる SQL コマンドの影響を受けにくくなります。 + **シンプルなデータ共有** – AWS Lake Formation でのアカウント間データ共有により、データを移動せずに他の AWS アカウントとデータを共有することができます。 ## データカタログビューの作成 Spark SQL による AWS CLI および AWS Glue ETL スクリプトを使用して、データカタログビューを作成できます。データカタログビューを作成するための構文には、ビュータイプを `MULTI DIALECT` に、`SECURITY` 述語を `DEFINER` に指定して定義者ビューを示すことが含まれます。 データカタログビューを作成する SQL ステートメントの例: ``` CREATE PROTECTED MULTI DIALECT VIEW database_name.catalog_view SECURITY DEFINER AS SELECT order_date, sum(totalprice) AS price FROM source_table GROUP BY order_date; ``` データカタログビューを作成したら、当該ビューに対する AWS Lake Formation SELECT アクセス許可を持つ IAM ロールを使用して、Amazon Athena、Amazon Redshift、または AWS Glue ETL ジョブなどのサービスからクエリを実行できます。ビューで参照される基盤となるテーブルへのアクセスを許可する必要はありません。 データカタログビューの作成と設定の詳細については、「AWS Lake Formation デベロッパーガイド」の「[Building AWS Glue Data Catalog views](https://docs.aws.amazon.com/lake-formation/latest/dg/working-with-views.html)」を参照してください。 ## サポートされているビュー操作 以下のコマンドフラグメントは、データカタログビューを操作するさまざまな方法を示します。 **CREATE VIEW** データカタログビューを作成します。以下は、既存のテーブルからビューを作成する例です。 ``` CREATE PROTECTED MULTI DIALECT VIEW catalog_view SECURITY DEFINER AS SELECT * FROM my_catalog.my_database.source_table ``` **ALTER VIEW** 使用可能な構文: ``` ALTER VIEW view_name [FORCE] ADD DIALECT AS query ALTER VIEW view_name [FORCE] UPDATE DIALECT AS query ALTER VIEW view_name DROP DIALECT ``` `FORCE ADD DIALECT` オプションを使用して、新しいエンジンダイアレクトに従ってスキーマとサブオブジェクトを強制的に更新できます。ただし、これを行うと、他のエンジンダイアレクトの更新にも `FORCE` を使用しないと、クエリエラーが発生する可能性があることに注意してください。サンプルを以下に示します。 ``` ALTER VIEW catalog_view FORCE ADD DIALECTAS SELECT order_date, sum(totalprice) AS priceFROM source_tableGROUP BY orderdate; ``` 以下は、ダイアレクトを更新するためにビューを変更する方法を示します。 ``` ALTER VIEW catalog_view UPDATE DIALECT AS SELECT count(*) FROM my_catalog.my_database.source_table; ``` **DESCRIBE VIEW** ビューを記述するために使用できる構文: `SHOW COLUMNS {FROM|IN} view_name [{FROM|IN} database_name]` – ユーザーがビューの記述に必要な AWS Glue および AWS Lake Formation のアクセス許可を持っている場合、列を一覧表示できます。列を表示するためのいくつかのサンプルコマンドを以下に示します。 ``` SHOW COLUMNS FROM my_database.source_table; SHOW COLUMNS IN my_database.source_table; ``` `DESCRIBE view_name` – ユーザーがビューの記述に必要な AWS Glue および AWS Lake Formation のアクセス許可を持っている場合、列およびメタデータをビュー内で一覧表示できます。 **DROP VIEW** 使用可能な構文: ``` DROP VIEW [ IF EXISTS ] view_name ``` 次のサンプルは、ビューを削除する前にビューが存在するかどうかをテストする `DROP` ステートメントを示します。 ``` DROP VIEW IF EXISTS catalog_view; ``` `SHOW CREATE VIEW view_name` – 指定したビューを作成する SQL ステートメントを示します。以下は、データカタログビューの作成を示すサンプルです。 ``` SHOW CREATE TABLE my_database.catalog_view;CREATE PROTECTED MULTI DIALECT VIEW my_catalog.my_database.catalog_view ( net_profit, customer_id, item_id, sold_date) TBLPROPERTIES ( 'transient_lastDdlTime' = '1736267222') SECURITY DEFINER AS SELECT * FROM my_database.store_sales_partitioned_lf WHERE customer_id IN (SELECT customer_id from source_table limit 10) ``` **SHOW VIEWS** 通常のビュー、マルチダイアレクトビュー (MDV)、Spark ダイアレクトのない MDV など、カタログ内のすべてのビューを一覧表示します。使用可能な構文は次のとおりです。 ``` SHOW VIEWS [{ FROM | IN } database_name] [LIKE regex_pattern]: ``` ビューを表示するサンプルコマンドを以下に示します。 ``` SHOW VIEWS IN marketing_analytics LIKE 'catalog_view*'; ``` データカタログビューの作成と設定の詳細については、「AWS Lake Formation デベロッパーガイド」の「[Building AWS Glue Data Catalog views](https://docs.aws.amazon.com/lake-formation/latest/dg/working-with-views.html)」を参照してください。 ## データカタログビューをクエリする データカタログビューの作成後は、ビューをクエリできるようになります。AWS Glue ジョブで設定された IAM ロールには、データカタログビューに対する Lake Formation **SELECT** アクセス許可が必要です。ビューで参照される基盤となるテーブルへのアクセスを許可する必要はありません。 すべてをセットアップしたら、ビューをクエリできます。たとえば、次のクエリを実行してビューにアクセスできます。 ``` SELECT * from my_database.catalog_view LIMIT 10; ``` ## 制限 データカタログビューを使用する場合は、次の制限を考慮してください。 + AWS Glue 5.0 以上では、データカタログビューのみを作成できます。 + Data Catalog ビュー定義者は、ビューによってアクセスされる基盤となるベーステーブルに対する `SELECT` アクセスを持っている必要があります。特定のベーステーブルに定義者ロールに対する Lake Formation フィルターが適用されている場合、データカタログビューの作成は失敗します。 + ベーステーブルには AWS Lake Formation 内の `IAMAllowedPrincipals` データレイクのアクセス許可を付与してはいけません。付与されている場合は、**Multi Dialect views may only reference tables without IAMAllowedPrincipals permissions** というエラーが表示されます。 + テーブルの Amazon S3 の場所は、AWS Lake Formation データレイクの場所として登録する必要があります。テーブルが登録されていない場合、エラー `Multi Dialect views may only reference AWS Lake Formation managed tables` が発生します。AWS Lake Formation で Amazon S3 の場所を登録する方法については、「AWS Lake Formation デベロッパーガイド」の「[Registering an Amazon S3 location](https://docs.aws.amazon.com/lake-formation/latest/dg/register-data-lake.html)」を参照してください。 + `PROTECTED` データカタログビューのみを作成できます。`UNPROTECTED` ビューはサポートされていません。 + データカタログビュー定義では別の AWS アカウント内のテーブルを参照することはできません。また、別のリージョンにあるのと同じアカウントのテーブルを参照することはできません。 + アカウントまたはリージョン間でデータを共有するには、AWS Lake Formation リソースリンクを使用してビュー全体をクロスアカウントおよびクロスリージョンで共有する必要があります。 + ユーザー定義関数 (UDF) はサポートされていません。 + データカタログビューで他のビューを参照できません。 # データカタログにアクセスする AWS Glue Data Catalog (データカタログ) を使用すると、データを検出してこれを理解することができます。データカタログは、スキーマの定義、データ型、場所などのメタデータを一貫して維持する方法を提供します。次の方法を使用してデータカタログにアクセスできます。 + AWS Glue コンソール – ウェブベースのユーザーインターフェイスである AWS Glue コンソールからデータカタログにアクセスして管理できます。コンソールでは、データベース、テーブル、および関連するメタデータを参照および検索したり、メタデータ定義を作成、更新、削除したりできます。 + AWS Glue クローラー – クローラーは、データソースを自動的にスキャンし、データカタログにメタデータを入力するプログラムです。クローラーを作成して実行し、Amazon S3、Amazon RDS、Amazon DynamoDB、Amazon CloudWatch、および MySQL や PostgreSQL などの JDBC 準拠のリレーショナルデータベース、Snowflake や Google BigQuery などのいくつかの非 AWS ソースからのデータを検出してカタログ化できます。 + AWS Glue API - AWS Glue API を使用してプログラムでデータカタログにアクセスできます。これらの API を使用すると、プログラムでデータカタログを操作し、自動化と他のアプリケーションやサービスとの統合が可能になります。 + AWS Command Line Interface (AWS CLI) – AWS CLI を使用して、コマンドラインからデータカタログにアクセスして管理できます。CLI には、メタデータ定義の作成、更新、削除、メタデータ情報のクエリと取得のためのコマンドが用意されています。 + 他の AWS サービスとの統合 – データカタログは他のさまざまな AWS サービスと統合されるため、カタログに保存されているメタデータにアクセスして利用できます。たとえば、Amazon Athena を使用してデータカタログのメタデータを使用してデータソースをクエリし、AWS Lake Formation を使用してデータカタログリソースのデータアクセスとガバナンスを管理できます。 **Topics** + [AWS Glue Iceberg REST エンドポイントを使用したデータカタログへの接続方法](connect-glu-iceberg-rest.md) + [AWS Glue Iceberg REST 拡張エンドポイントを使用したデータカタログへの接続](connect-glue-iceberg-rest-ext.md) + [AWS Glue Apache Iceberg 用の REST API の仕様](iceberg-rest-apis.md) + [スタンドアロンの Spark アプリケーションからデータカタログへの接続](connect-gludc-spark.md) + [Amazon Redshift と Apache Iceberg 間のデータマッピング](data-mapping-rs-iceberg.md) + [AWS Glue Iceberg REST Catalog API を使用する際の考慮事項と制限事項](limitation-glue-iceberg-rest-api.md) # AWS Glue Iceberg REST エンドポイントを使用したデータカタログへの接続方法 AWS Glue の Iceberg REST エンドポイントは、Apache Iceberg REST 仕様で指定された API オペレーションに対応しています。Iceberg REST クライアントを使用すると、分析エンジンで実行されているアプリケーションをデータカタログでホストされている REST カタログに接続することができます。 エンドポイントは、Apache Iceberg テーブル仕様の両方 (v1 と v2) をサポートしており、デフォルトでは v2 に設定されています。Iceberg テーブル v1 仕様を使用する場合は、API コールで v1 を指定する必要があります。API オペレーションを使用すると、Amazon S3 オブジェクトストレージと Amazon S3 テーブルストレージの両方に保存されている Iceberg テーブルにアクセスできます。 **エンドポイント設定** サービスエンドポイントを使用して AWS Glue Iceberg REST カタログにアクセスできます。リージョン固有のエンドポイントについては、「[AWS Glue サービスエンドポイントのリファレンスガイド](https://docs.aws.amazon.com/general/latest/gr/glue.html#glue_region)」を参照してください。例えば、us-east-1 リージョンの AWS Glue に接続する場合、エンドポイント URI プロパティを次のように設定する必要があります。 ``` Endpoint : https://glue.us-east-1.amazonaws.com/iceberg ``` **追加の設定プロパティ** – Iceberg クライアントを使用して Spark などの分析エンジンをサービスエンドポイントに接続する場合は、次のアプリケーション設定プロパティを指定する必要があります。 ``` catalog_name = "mydatacatalog" aws_account_id = "123456789012" aws_region = "us-east-1" spark = SparkSession.builder \ ... \ .config("spark.sql.defaultCatalog", catalog_name) \ .config(f"spark.sql.catalog.{catalog_name}", "org.apache.iceberg.spark.SparkCatalog") \ .config(f"spark.sql.catalog.{catalog_name}.type", "rest") \ .config(f"spark.sql.catalog.{catalog_name}.uri", "https://glue.{aws_region}.amazonaws.com/iceberg") \ .config(f"spark.sql.catalog.{catalog_name}.warehouse", "{aws_account_id}") \ .config(f"spark.sql.catalog.{catalog_name}.rest.sigv4-enabled", "true") \ .config(f"spark.sql.catalog.{catalog_name}.rest.signing-name", "glue") \ .config("spark.sql.extensions","org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \ .getOrCreate() ``` AWS Glue Iceberg エンドポイント ` https://glue.us-east-1.amazonaws.com/iceberg` は、次の Iceberg REST API をサポートします。 + GetConfig + ListNamespaces + CreateNamespace + LoadNamespaceMetadata + UpdateNamespaceProperties + DeleteNamespace + ListTables + CreateTable + LoadTable + TableExists + UpdateTable + DeleteTable ## プレフィックスとカタログパスパラメータ Iceberg REST Catalog API のリクエスト URL には、自由形式のプレフィックスが含まれます。例えば、`ListNamespaces` API コールは `GET/v1/{prefix}/namespaces` の URL 形式を使用します。AWS Glue プレフィックスは、REST パスが AWS Glue マルチカタログ階層に確実に一致するように常に `/catalogs/{catalog}` 構造に従います。`{catalog}` パスパラメータは、次のルールに基づいて派生できます。 | **アクセスパターン** | **Glue カタログ ID スタイル** | **プレフィックススタイル** | **デフォルトのカタログ ID の例** | **REST ルートの例** | | --- | --- | --- | --- | --- | | 現在のアカウントのデフォルトカタログにアクセスする | 不要 | : | 該当なし | GET /v1/catalogs/:/namespaces | | 特定のアカウントのデフォルトカタログにアクセスする | accountID | accountID | 111122223333 | GET /v1/catalogs/111122223333/namespaces | | 現在のアカウントのネストされたカタログにアクセスする | catalog1/catalog2 | catalog1/catalog2 | rmscatalog1:db1 | GET /v1/catalogs/rmscatalog1:db1/namespaces | | 特定のアカウントのネストされたカタログにアクセスする | accountId:catalog1/catalog2 | accountId:catalog1/catalog2 | 123456789012/rmscatalog1:db1 | GET /v1/catalogs/123456789012:rmscatalog1:db1/namespaces | このカタログ ID からプレフィックスへのマッピングは、REST API を直接呼び出す場合にのみ必要です。エンジンを介して AWS Glue Iceberg REST Catalog API を使用する場合、Iceberg REST Catalog API 設定の `warehouse` パラメータまたは AWS Glue 拡張機能 API 設定の `glue.id` パラメータで AWS Glue カタログ ID を指定する必要があります。例えば、EMR Spark での使用方法については、「[Use an Iceberg cluster with Spark](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-iceberg-use-spark-cluster.html)」を参照してください。 ## 名前空間パスパラメータ Iceberg REST Catalog API パスの名前空間には、複数のレベルを含めることができます。ただし、AWS Glue は単一レベルの名前空間のみをサポートします。マルチレベルカタログ階層の名前空間にアクセスするには、名前空間の上にあるマルチレベルカタログに接続して名前空間を参照します。これにより、`catalog.namespace.table` の 3 つの部分で構成される表記をサポートするクエリエンジンが AWS Glue の複数レベルカタログ階層内のオブジェクトにアクセスできます。マルチレベルの名前空間を使用する場合とは異なり、互換性の問題はありません。 # AWS Glue Iceberg REST 拡張エンドポイントを使用したデータカタログへの接続 AWS Glue Iceberg REST 拡張エンドポイントは、Apache Iceberg REST 仕様には含まれていない追加の API と、サーバー側のスキャン計画機能を提供します。これらの追加の API は、Amazon Redshift マネージドストレージに保存されているテーブルにアクセスするときに使用します。エンドポイントには、Apache Iceberg AWS Glue Data Catalog 拡張機能を使用して、アプリケーションからアクセスすることができます。 **エンドポイント設定** – Redshift マネージドストレージ内にあるテーブル付カタログは、サービスエンドポイントを使用してアクセスできます。リージョン固有のエンドポイントについては、「[AWS Glue サービスエンドポイントのリファレンスガイド](https://docs.aws.amazon.com/general/latest/gr/glue.html#glue_region)」を参照してください。例えば、us-east-1 リージョンの AWS Glue に接続する場合、エンドポイント URI プロパティを次のように設定する必要があります。 ``` Endpoint : https://glue.us-east-1.amazonaws.com/extensions ``` ``` catalog_name = "myredshiftcatalog" aws_account_id = "123456789012" aws_region = "us-east-1" spark = SparkSession.builder \ .config("spark.sql.defaultCatalog", catalog_name) \ .config(f"spark.sql.catalog.{catalog_name}", "org.apache.iceberg.spark.SparkCatalog") \ .config(f"spark.sql.catalog.{catalog_name}.type", "glue") \ .config(f"spark.sql.catalog.{catalog_name}.glue.id", "{123456789012}:redshiftnamespacecatalog/redshiftdb") \ .config("spark.sql.extensions","org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \ .getOrCreate() ``` # AWS Glue Apache Iceberg 用の REST API の仕様 このセクションでは、AWS Glue Iceberg REST カタログと AWS Glue 拡張 API に関する仕様と、これらの API を使用する際の考慮事項について説明します。 AWS Glue Data Catalog エンドポイントへの API リクエストは、AWS Signature Version 4 (SigV4) を使用して認証されます。AWS SigV4 の詳細については「[API リクエストに対する AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」のセクションを参照してください。 AWS Glue サービスエンドポイントと AWS Glue メタデータにアクセスする場合、アプリケーションは `glue:getCatalog` IAM アクションを必要とする IAM ロールを引き受けます。 データカタログとそのオブジェクトへのアクセスは、IAM、Lake Formation、または Lake Formation ハイブリッドモードのアクセス許可を使用して管理できます。 データカタログのフェデレーティッドカタログには、Lake Formation に登録されたデータロケーションがあります。Lake Formation は Data Catalog と連動して、データカタログに対するユーザーアクセスを管理するためのデータベーススタイルのアクセス許可を提供します。 IAM、AWS Lake Formation、Lake Formation のいずれかのハイブリッドモードのアクセス許可を使用することで、デフォルトのカタログデータとそのオブジェクトへのアクセスを管理できます。 Lake Formation のマネージド型オブジェクトでデータを作成、挿入、または削除するには、IAM ユーザーまたはロールに特定のアクセス許可を設定する必要があります。 + CREATE\$1CATALOG – カタログの作成に必要 + CREATE\$1DATABASE – データベースの作成に必要 + CREATE\$1TABLE – テーブルの作成に必要 + DELETE – テーブルからのデータの削除に必要 + DESCRIBE – メタデータの読み取りに必要 + DROP – テーブルまたはデータベースのドロップ/削除に必要 + INSERT – プリンシパルがデータをテーブルに挿入する必要がある場合に必要 + SELECT – プリンシパルがテーブルからデータを選択する必要がある場合に必要 詳細については、「AWS Lake Formation デベロッパーガイド」の「[Lake Formation permissions reference](https://docs.aws.amazon.com/lake-formation/latest/dg/lf-permissions-reference.html)」を参照してください。 # GetConfig **一般情報** | | | | --- |--- | | オペレーション名 | GetConfig | | Type | Iceberg REST Catalog API | | REST パス | GET /iceberg/v1/config | | IAM アクション | glue:GetCatalog | | Lake Formation 許可 | 該当しない | | CloudTrail のイベント | glue:GetCatalog | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L67 | ****考慮事項と制限事項**** + `warehouse` クエリパラメータはカタログ AWS Glue ID に設定する必要があります。設定されていない場合、現在のアカウントのルートカタログを使用してレスポンスが返されます。詳細については、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」を参照してください。 # GetCatalog **一般情報** | | | | --- |--- | | オペレーション名 | GetCatalog | | Type | AWS Glue 拡張機能 API | | REST パス | GET/extensions/v1/catalogs/\$1catalog\$1 | | IAM アクション | glue:GetCatalog | | Lake Formation 許可 | DESCRIBE | | CloudTrail のイベント | glue:GetCatalog | | Open API の定義 | https://github.com/awslabs/glue-extensions-for-iceberg/blob/main/glue-extensions-api.yaml\$1L40 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 # ListNamespaces **一般情報** | | | | --- |--- | | オペレーション名 | ListNamespaces | | Type | Iceberg REST Catalog API | | REST パス | GET/iceberg/v1/catalogs/\$1catalog\$1/namespaces | | IAM アクション | glue:GetDatabase | | Lake Formation 許可 | ALL, DESCRIBE, SELECT | | CloudTrail のイベント | glue:GetDatabase | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L205 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + 次のレベルの名前空間のみが表示されます。より深いレベルで名前空間を一覧表示するには、ネストされたカタログ ID をカタログパスパラメータで指定します。 # CreateNamespace **一般情報** | | | | --- |--- | | オペレーション名 | CreateNamespace | | Type | Iceberg REST Catalog API | | REST パス | POST/iceberg/v1/catalogs/\$1catalog\$1/namespaces | | IAM アクション | glue:CreateDatabase | | Lake Formation 許可 | ALL, DESCRIBE, SELECT | | CloudTrail のイベント | glue:CreateDatabase | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L256 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + 作成できるのは単一レベルの名前空間のみです。マルチレベルの名前空間を作成するには、各レベルを繰り返し作成して、カタログパスパラメータを使用してレベルに接続する必要があります。 # StartCreateNamespaceTransaction **一般情報** | | | | --- |--- | | オペレーション名 | StartCreateNamespaceTransaction | | Type | AWS Glue 拡張機能 API | | REST パス | POST/extensions/v1/catalogs/\$1catalog\$1/namespaces | | IAM アクション | glue:CreateDatabase | | Lake Formation 許可 | ALL, DESCRIBE, SELECT | | CloudTrail のイベント | glue:CreateDatabase | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L256 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + 作成できるのは単一レベルの名前空間のみです。マルチレベル名前空間を作成するには、各レベルを繰り返し作成し、カタログパスパラメータを使用してレベルに接続する必要があります。 + API は非同期で、`CheckTransactionStatus` API コールを使用して追跡するために使用できるトランザクション ID を返します。 + この API を呼び出すことができるのは、`GetCatalog` API コールにレスポンスの `use-extensions=true` パラメータが含まれている場合のみです。 ## LoadNamespaceMetadata **一般的な情報** | | | | --- |--- | | オペレーション名 | LoadNamespaceMetadata | | タイプ | Iceberg REST Catalog API | | REST パス | GET/iceberg/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1 | | IAM アクション | glue:GetDatabase | | Lake Formation 許可 | ALL, DESCRIBE, SELECT | | CloudTrail のイベント | glue:GetDatabase | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L302 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 ## UpdateNamespaceProperties **一般的な情報** | | | | --- |--- | | オペレーション名 | UpdateNamespaceProperties | | タイプ | Iceberg REST Catalog API | | REST パス | POST /iceberg/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/properties | | IAM アクション | glue:UpdateDatabase | | Lake Formation 許可 | ALL, ALTER | | CloudTrail のイベント | glue:UpdateDatabase | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L400 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 # DeleteNamespace **一般情報** | | | | --- |--- | | オペレーション名 | DeleteNamespace | | Type | Iceberg REST Catalog API | | REST パス | DELETE/iceberg/v1/catalogs/\$1catalog\$1/namespces/\$1ns\$1 | | IAM アクション | glue:DeleteDatabase | | Lake Formation 許可 | ALL, DROP | | CloudTrail のイベント | glue:DeleteDatabase | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L365 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + データベースにオブジェクトがある場合、オペレーションは失敗します。 + API は非同期で、`CheckTransactionStatus` API コールを使用して追跡するために使用できるトランザクション ID を返します。 + API は、`GetCatalog` API コールがレスポンスで `use-extensions=true` を示す場合にのみ使用できます。 # StartDeleteNamespaceTransaction **一般情報** | | | | --- |--- | | オペレーション名 | StartDeleteNamespaceTransaction | | Type | AWS Glue 拡張機能 API | | REST パス | DELETE /extensions/v1/catalogs/\$1catalog\$1/namespces/\$1ns\$1 | | IAM アクション | glue:DeleteDatabase | | Lake Formation 許可 | ALL, DROP | | CloudTrail のイベント | glue:DeleteDatabase | | Open API の定義 | https://github.com/awslabs/glue-extensions-for-iceberg/blob/main/glue-extensions-api.yaml\$1L85 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + データベースにオブジェクトがある場合、オペレーションは失敗します。 + API は非同期で、`CheckTransactionStatus` API コールを使用して追跡するために使用できるトランザクション ID を返します。 + API は、`GetCatalog` API コールがレスポンスで `use-extensions=true` を示す場合にのみ使用できます。 # ListTables **一般情報** | | | | --- |--- | | オペレーション名 | ListTables | | Type | Iceberg REST Catalog API | | REST パス | GET /iceberg/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables | | IAM アクション | glue:GetTables | | Lake Formation 許可 | ALL, SELECT, DESCRIBE | | CloudTrail のイベント | glue:GetTables | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L463 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + Iceberg 以外のテーブルを含むすべてのテーブルが一覧表示されます。テーブルを Iceberg テーブルとしてロードできるかどうかを確認するには、 `LoadTable` オペレーションを呼び出します。 # CreateTable **一般情報** | | | | --- |--- | | オペレーション名 | CreateTable | | Type | Iceberg REST Catalog API | | REST パス | GET /iceberg/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables | | IAM アクション | glue:CreateTable | | Lake Formation 許可 | ALL, CREATE\$1TABLE | | CloudTrail のイベント | glue:CreateTable | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L497 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + ステージングを使用した `CreateTable` はサポートされていません。`stageCreate` クエリパラメータを指定するとオペレーションは失敗します。`CREATE TABLE AS SELECT` のようなオペレーションはサポートされていないため、回避策として `CREATE TABLE` と `INSERT INTO` の組み合わせを使用できます。 + `CreateTable` API オペレーションはオプション `state-create = TRUE` をサポートしていません。 # StartCreateTableTransaction **一般情報** | | | | --- |--- | | オペレーション名 | CreateTable | | Type | AWS Glue 拡張機能 API | | REST パス | POST/extensions/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables | | IAM アクション | glue:CreateTable | | Lake Formation 許可 | ALL, CREATE\$1TABLE | | CloudTrail のイベント | glue:CreateTable | | Open API の定義 | https://github.com/awslabs/glue-extensions-for-iceberg/blob/main/glue-extensions-api.yaml\$1L107 | ****考慮事項と制限事項**** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + ステージングを使用した `CreateTable` はサポートされていません。`stageCreate` クエリパラメータを指定するとオペレーションは失敗します。`CREATE TABLE AS SELECT` のようなオペレーションはサポートされていないため、ユーザーは問題を回避するために `CREATE TABLE` と `INSERT INTO` を組み合わせて使用する必要があります。 + API は非同期で、`CheckTransactionStatus` API コールを使用して追跡するために使用できるトランザクション ID を返します。 + API は、`GetCatalog` API コールがレスポンスで `use-extensions=true` を示す場合にのみ使用できます。 # LoadTable **一般情報** | | | | --- |--- | | オペレーション名 | LoadTable | | タイプ | Iceberg REST Catalog API | | REST パス | GET /iceberg/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables/\$1table\$1 | | IAM アクション | glue:GetTable | | Lake Formation 許可 | ALL, SELECT, DESCRIBE | | CloudTrail のイベント | glue:GetTable | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L616 | **考慮事項** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + ステージングを使用した `CreateTable` はサポートされていません。`stageCreate` クエリパラメータを指定するとオペレーションは失敗します。`CREATE TABLE AS SELECT` のようなオペレーションはサポートされていないため、ユーザーは問題を回避するために `CREATE TABLE` と `INSERT INTO` を組み合わせて使用する必要があります。 + API は非同期で、`CheckTransactionStatus` API コールを使用して追跡するために使用できるトランザクション ID を返します。 + API は、`GetCatalog` API コールがレスポンスで `use-extensions=true` を示す場合にのみ使用できます。 # ExtendedLoadTable **一般情報** | | | | --- |--- | | オペレーション名 | LoadTable | | タイプ | AWS Glue 拡張機能 API | | REST パス | GET /extensions/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables/\$1table\$1 | | IAM アクション | glue:GetTable | | Lake Formation 許可 | ALL, SELECT, DESCRIBE | | CloudTrail のイベント | glue:GetTable | | Open API の定義 | https://github.com/awslabs/glue-extensions-for-iceberg/blob/main/glue-extensions-api.yaml\$1L134 | **考慮事項** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + スナップショットクエリパラメータでは `all` モードのみがサポートされます。 + `LoadTable` API と比較すると、`ExtendedLoadTable` API は次の点が異なります。 + すべてのフィールドが利用可能になるよう厳密に強制されません。 + レスポンスの設定フィールドに以下の追加パラメータを提供します。 **追加パラメータ** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/extended-load-table.html) # PreplanTable **一般情報** | | | | --- |--- | | オペレーション名 | PreplanTable | | タイプ | AWS Glue 拡張機能 API | | REST パス | POST /extensions/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables/\$1table\$1/preplan | | IAM アクション | glue:GetTable | | Lake Formation 許可 | ALL, SELECT, DESCRIBE | | CloudTrail のイベント | glue:GetTable | | Open API の定義 | https://github.com/awslabs/glue-extensions-for-iceberg/blob/main/glue-extensions-api.yaml\$1L211 | **考慮事項** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + この API の呼び出し元は、ページトークンに基づいて、取得する残りの結果があるかどうかを常に判断する必要があります。サーバー側がまだ処理中で指定された応答時間内に結果を生成できない場合、ページ分割トークンを含む空白のページが返されることがあります。 + この API は、API `ExtendedLoadTable` レスポンスに `aws.server-side-capabilities.scan-planning=true` が含まれている場合にのみ使用できます。 # PlanTable **一般情報** | | | | --- |--- | | オペレーション名 | PlanTable | | タイプ | AWS Glue 拡張機能 API | | REST パス | POST /extensions/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables/\$1table\$1/plan | | IAM アクション | glue:GetTable | | Lake Formation 許可 | ALL, SELECT, DESCRIBE | | CloudTrail のイベント | glue:GetTable | | Open API の定義 | https://github.com/awslabs/glue-extensions-for-iceberg/blob/main/glue-extensions-api.yaml\$1L243 | **考慮事項** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + この API の呼び出し元は、ページトークンに基づいて、取得する残りの結果があるかどうかを常に判断する必要があります。サーバー側がまだ処理中で指定された応答時間内に結果を生成できない場合、ページ分割トークンを含む空白のページが返されることがあります。 + この API は、API `ExtendedLoadTable` レスポンスに `aws.server-side-capabilities.scan-planning=true` が含まれている場合にのみ使用できます。 # TableExists **一般情報** | | | | --- |--- | | オペレーション名 | TableExists | | タイプ | Iceberg REST Catalog API | | REST パス | HEAD/iceberg/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables/\$1table\$1 | | IAM アクション | glue:GetTable | | Lake Formation 許可 | ALL, SELECT, DESCRIBE | | CloudTrail のイベント | glue:GetTable | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L833 | **考慮事項** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 # UpdateTable **一般情報** | | | | --- |--- | | オペレーション名 | UpdateTable | | タイプ | Iceberg REST Catalog API | | REST パス | POST /iceberg/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables/\$1table\$1 | | IAM アクション | glue:UpdateTable | | Lake Formation 許可 | ALL, ALTER | | CloudTrail のイベント | glue:UpdateTable | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L677 | **考慮事項** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 # StartUpdateTableTransaction **一般情報** | | | | --- |--- | | オペレーション名 | StartUpdateTableTransaction | | タイプ | AWS Glue 拡張機能 API | | REST パス | POST/extensions/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables/\$1table\$1 | | IAM アクション | glue:UpdateTable | | Lake Formation 許可 | ALL, ALTER | | CloudTrail のイベント | glue:UpdateTable | | Open API の定義 | https://github.com/awslabs/glue-extensions-for-iceberg/blob/main/glue-extensions-api.yaml\$1L154 | **考慮事項** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + API は非同期で、`CheckTransactionStatus` API コールを使用して追跡するために使用できるトランザクション ID を返します。 + この API を使用して `RenamTable` オペレーションを実行することもできます。この場合、呼び出し元は、名前を変更するテーブルの glue:CreateTable または LakeFormation CREATE\$1TABLE アクセス許可も取得する必要があります。 + この API は、API `ExtendedLoadTable` レスポンスに `aws.server-side-capabilities.scan-planning=true` が含まれている場合にのみ使用できます。 # DeleteTable **一般情報** | | | | --- |--- | | オペレーション名 | DeleteTable | | タイプ | Iceberg REST Catalog API | | REST パス | DELETE/iceberg/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables/\$1table\$1 | | IAM アクション | glue:DeleteTable | | Lake Formation 許可 | ALL, DROP | | CloudTrail のイベント | glue:DeleteTable | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L793 | **考慮事項** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + `DeleteTable` API オペレーションはパージオプションをサポートします。パージが `true` に設定されている場合、テーブルデータは削除されます。設定されていない場合は削除されません。Amazon S3 のテーブルの場合、このオペレーションでテーブルデータが削除されることはありません。テーブルが Amazon S3 と `purge = TRUE,` に保存されている場合、このオペレーションは失敗します。 テーブルが Amazon Redshift マネージドストレージに保存されている場合、Amazon Redshift での `DROP TABLE` の動作と同様に、このオペレーションによりテーブルデータは削除されます。テーブルが Amazon Redshift と `purge = FALSE` に保存されている場合、このオペレーションは失敗します。 + `purgeRequest=true` はサポートされていません。 # StartDeleteTableTransaction **一般情報** | | | | --- |--- | | オペレーション名 | StartDeleteTableTransaction | | タイプ | AWS Glue 拡張機能 API | | REST パス | DELETE /extensions/v1/catalogs/\$1catalog\$1/namespaces/\$1ns\$1/tables/\$1table\$1 | | IAM アクション | glue:DeleteTable | | Lake Formation 許可 | ALL, DROP | | CloudTrail のイベント | glue:DeleteTable | | Open API の定義 | https://github.com/apache/iceberg/blob/apache-iceberg-1.6.1/open-api/rest-catalog-open-api.yaml\$1L793 | **考慮事項** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 + REST Path パラメータでは、単一レベルの名前空間のみを指定できます。詳細については「[名前空間パスパラメータ](connect-glu-iceberg-rest.md#ns-path-param)」セクションを参照してください。 + `purgeRequest=false` はサポートされていません。 + API は非同期で、`CheckTransactionStatus` を介して追跡できるトランザクション ID を返します。 # CheckTransactionStatus **一般情報** | | | | --- |--- | | オペレーション名 | CheckTransactionStatus | | タイプ | AWS Glue 拡張機能 API | | REST パス | POST/extensions/v1/transactions/status | | IAM アクション | トランザクションを開始するアクションと同じアクセス許可 | | Lake Formation 許可 | トランザクションを開始するアクションと同じアクセス許可 | | Open API の定義 | https://github.com/awslabs/glue-extensions-for-iceberg/blob/main/glue-extensions-api.yaml\$1L273 | **考慮事項** + カタログパスパラメータは、「[プレフィックスとカタログパスパラメータ](connect-glu-iceberg-rest.md#prefix-catalog-path-parameters)」セクションで説明されているスタイルに従う必要があります。 # スタンドアロンの Spark アプリケーションからデータカタログへの接続 Apache Iceberg コネクタを使用することで、スタンドアロンのアプリケーションからデータカタログに接続することができます。 1. Spark アプリケーションの IAM ロールを作成します。 1. Iceberg コネクタを使用して AWS Glue Iceberg Rest エンドポイントに接続します。 ``` # configure your application. Refer to https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html for best practices on configuring environment variables. export AWS_ACCESS_KEY_ID=$(aws configure get appUser.aws_access_key_id) export AWS_SECRET_ACCESS_KEY=$(aws configure get appUser.aws_secret_access_key) export AWS_SESSION_TOKEN=$(aws configure get appUser.aws_secret_token) export AWS_REGION=us-east-1 export REGION=us-east-1 export AWS_ACCOUNT_ID = {specify your aws account id here} ~/spark-3.5.3-bin-hadoop3/bin/spark-shell \ --packages org.apache.iceberg:iceberg-spark-runtime-3.4_2.12:1.6.0 \ --conf "spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions" \ --conf "spark.sql.defaultCatalog=spark_catalog" \ --conf "spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkCatalog" \ --conf "spark.sql.catalog.spark_catalog.type=rest" \ --conf "spark.sql.catalog.spark_catalog.uri=https://glue.us-east-1.amazonaws.com/iceberg" \ --conf "spark.sql.catalog.spark_catalog.warehouse = {AWS_ACCOUNT_ID}" \ --conf "spark.sql.catalog.spark_catalog.rest.sigv4-enabled=true" \ --conf "spark.sql.catalog.spark_catalog.rest.signing-name=glue" \ --conf "spark.sql.catalog.spark_catalog.rest.signing-region=us-east-1" \ --conf "spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO" \ --conf "spark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.SimpleAWSCredentialProvider" ``` 1. データカタログのデータをクエリします。 ``` spark.sql("create database myicebergdb").show() spark.sql("""CREATE TABLE myicebergdb.mytbl (name string) USING iceberg location 's3://bucket_name/mytbl'""") spark.sql("insert into myicebergdb.mytbl values('demo') ").show() ``` # Amazon Redshift と Apache Iceberg 間のデータマッピング Redshift と Iceberg は、さまざまなデータ型をサポートしています。次の互換性マトリクスは、この 2 つのデータシステム間でデータをマッピングする際のサポートと制限の概要を示しています。各データシステムでサポートされているデータ型の詳細については、「[Amazon Redshift データ型](https://docs.aws.amazon.com/redshift/latest/dg/c_Supported_data_types.html)」と「[Apache Iceberg Table Specifications](https://iceberg.apache.org/spec/#primitive-types)」を参照してください。 | Redshift データ型 | エイリアス | Iceberg データ型 | | --- | --- | --- | | SMALLINT | INT2 | int | | INTEGER | INT、INT4 | int | | BIGINT | INT8 | long | | DECIMAL | NUMERIC | decimal | | REAL | FLOAT4 | フロート | | REAL | FLOAT4 | フロート | | DOUBLE PRECISION | FLOAT8、FLOAT | double | | CHAR | CHARACTER, NCHAR | 文字列 | | VARCHAR | CHARACTER VARYING, NVARCHAR | 文字列 | | BPCHAR | | 文字列 | | TEXT | | 文字列 | | DATE | | date | | TIME | TIME WITHOUT TIMEZONE | 時間 | | TIME | TIME WITH TIMEZONE | サポート外 | | TIMESTAMP | TIMESTAMP WITHOUT TIMEZONE | TIMESTAMP | | TIMESTAMPZ | TIMESTAMP WITH TIMEZONE | TIMESTAMPZ | | INTERVAL YEAR TO MONTH | | サポートされていません | | INTERVAL DAY TO SECOND | | サポートされていません | | BOOLEAN | BOOL | ブール | | HLLSKETCH | | サポートされていません | | SUPER | | サポートされていません | | VARBYTE | VARBINARY、BINARY VARYING | バイナリ | | GEOMETRY | | サポートされていません | | GEOGRAPHY | | サポートされていません | # AWS Glue Iceberg REST Catalog API を使用する際の考慮事項と制限事項 Apache Iceberg REST Catalog データ定義言語 (DDL) オペレーション動作を使用する際の考慮事項と制限事項は次のとおりです。 **考慮事項** + **`RenameTable` API の動作** – `RenameTable` オペレーションは Amazon Redshift のテーブルではサポートされていますが、Amazon S3 のテーブルではサポートされていません。 + **Amazon Redshift の名前空間とテーブルの DDL オペレーション** – Amazon Redshift の名前空間とテーブルの作成、更新、削除のオペレーションは、Amazon Redshift のマネージドワークグループがいつ利用可能か、および競合する DDL と DML トランザクションが進行中かどうかに依存し、オペレーションはロックを待機してから変更のコミットを試みる必要があるため、非同期オペレーションとなります。 **制限** + Apache Iceberg REST 仕様の View API は、AWS Glue Iceberg REST Catalog ではサポートされていません。 # AWS Glue データカタログのベストプラクティス このセクションでは、AWS Glue Data Catalog を効果的に管理および活用するためのベストプラクティスについて説明します。効率的なクローラーの使用、メタデータの整理、セキュリティ、パフォーマンスの最適化、自動化、データガバナンス、他の AWS サービスとの統合などのプラクティスについて重点的に説明します。 + **クローラーを効果的に使用する** – クローラーを定期的に実行して、データソースの変更に応じてデータカタログを最新の状態に保ちます。頻繁に変化するデータソースには増分クロールを使用してパフォーマンスを向上させます。変更が検出されたときに新しいパーティションを自動的に追加したり、スキーマを更新したりするようにクローラーを設定します。 + **メタデータテーブルの整理と名前付け** — データカタログのデータベースとテーブルについて一貫した命名規則を確立します。関連データソースを論理データベースまたはフォルダにグループ化して、より適切に整理します。各テーブルの目的と内容を伝えるわかりやすい名前を使用します。 + **スキーマを効果的に管理する** — AWS Glue クローラーのスキーマ推論機能を活用します。ダウンストリームアプリケーションが破損しないように、スキーマの変更を適用する前に確認および更新します。スキーマ進化機能を使用して、スキーマの変更を適切に処理します。 + **データカタログの保護** — データカタログの保管中および転送中のデータ暗号化を有効にします。きめ細かなアクセスコントロールポリシーを実装し、機密データへのアクセスを制限します。データカタログのアクセス許可とアクティビティログを定期的に監査して確認します。 + **他の AWS サービスとの統合** - データカタログを Amazon Athena、Redshift Spectrum、AWS Lake Formation などのサービスを一元管理できるメタデータレイヤーとして使用します。AWS Glue ETL ジョブを活用して、データカタログのメタデータを維持しながら、データを変換してさまざまなデータストアにロードします。 + **パフォーマンスのモニタリングと最適化** - Amazon CloudWatch メトリクスを使用してクローラーと ETL ジョブのパフォーマンスをモニタリングします。大きなデータセットをデータカタログにパーティション分割して、クエリのパフォーマンスを向上します。頻繁にアクセスされるメタデータのパフォーマンス最適化を実装します。 + **AWS Glue ドキュメントとベストプラクティスの最新情報を入手** - AWS Glue ドキュメントと AWS Glue リソースで最新の更新、ベストプラクティス、推奨事項を定期的に確認します。AWS Glue ウェビナー、ワークショップ、その他のイベントに参加して、エキスパートから学び、新機能について最新情報を得ます。 # Amazon CloudWatch での Data Catalog 使用状況メトリクスのモニタリング AWS Glue Data Catalog の使用状況メトリクスが Amazon CloudWatch で利用可能になり、Data Catalog でのリソース使用率のモニタリングと理解が簡素化されました。カタログ、データベース、テーブル、パーティション、接続の Glue Catalog API 使用状況がすぐに可視化され、Data Catalog を容易に監視できるようになりました。 ## Data Catalog メトリクスの概要 AWS Glue Data Catalog は、使用状況メトリクスを Amazon CloudWatch に自動的に発行します。CloudWatch メトリクスの統合を使用すると、次のような重要なパフォーマンス指標を 1 分ごとに追跡できます。 + テーブルリクエスト + 作成されたパーティションインデックス + 更新された接続 + 更新された統計 これらのメトリクスを使用して、ボトルネックの特定、異常の検出、データ駆動型の意思決定を行い、データカタログ全体の信頼性を向上させることができます。メトリクスが指定されたしきい値を超えたときに通知を受信するように CloudWatch アラームを設定することもでき、デプロイをプロアクティブに管理できます。 ## CloudWatch ダッシュボードにメトリクスを追加する カスタムダッシュボードを作成して AWS Glue Data Catalog リソースをモニタリングし、異常なアクティビティを通知するアラームを設定できます。 以下の手順に従って、CloudWatch ダッシュボードに Data Catalog メトリクスを追加できます。 1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。 1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。 1. **[すべてのメトリクス]** を選択します。 1. **[使用状況] > AWS[リソース]** を選択します。 1. **Glue** でフィルタリングして、使用可能なメトリクスを表示します。 1. ダッシュボードに追加したいメトリクスを選択します。 1. CloudWatch グラフにカタログ、データベース、テーブル、パーティション、接続のメトリクスを追加します。 ![\[CloudWatch ダッシュボードの AWS Glue Data Catalog メトリクス\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/glue-cloudwatch-metrics.png) API 使用量が定義されたしきい値を超えたときに自動的にトリガーされるカスタムアラームを設定して、データカタログ使用状況の異常を特定できます。 アラームの設定に関する詳細については、「[Metrics Insights CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-alarm-create.html)」を参照してください。 # AWS Glue スキーマレジストリ **注記** AWS Glue スキーマレジストリは、中東 (UAE) リージョンの AWS Glue コンソールではサポートされていません。 AWS Glue スキーマレジストリを使用すると、データストリームスキーマを一元的に検出、制御、展開できます。*スキーマ* は、データレコードの構造と形式を定義します。AWS Glue のスキーマレジストリを使用すると、Apache Kafka、[Amazon Managed Streaming for Apache Kafka](https://aws.amazon.com/msk/)、[Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/)、[Amazon Managed Service for Apache Flink](https://aws.amazon.com/kinesis/data-analytics/)、[AWS Lambda](https://aws.amazon.com/lambda/) と便利な統合を使用するデータストリームアプリケーションでスキーマを管理して実施することができます。 スキーマレジストリは、AVRO (v1.11.4) データ形式、[Everit ライブラリ](https://github.com/everit-org/json-schema)を使用した JSON スキーマ検証を含むスキーマ用 (Draft-04、Draft-06、Draft-07 仕様) の [JSON スキーマ形式](https://json-schema.org/)の JSON データ形式、`extensions` または `groups` のサポートが含まれないプロトコルバッファ (Protobuf) バージョンの proto2 および proto3、Java 言語対応をサポートしており、今後は他のデータ形式や言語にも対応していきます。サポートされている機能には、互換性、メタデータを介したスキーマのソーシング、スキーマの自動登録、IAM 互換性、ストレージとデータ転送を削減する ZLIB 圧縮のオプションがあります。スキーマレジストリはサーバーレスで無料で使用できます。 プロデューサとコンシューマの間のデータ形式契約としてスキーマを使用すると、データガバナンスおよびデータ品質の向上につながります。さらにデータのコンシューマは、上流で行われる互換性に関する変更に対する復旧力を得ることができます。 スキーマレジストリを使用すると、異なるシステムでシリアル化と非シリアル化用のスキーマを共有できます。例えば、データのプロデューサーとコンシューマーを考えてみます。データの公開時、プロデューサーはスキーマを把握しています。スキーマレジストリは、Amazon MSK や Apache Kafka などの特定のシステム用に、シリアル化と非シリアル化の機能を提供します。 詳しくは、「[スキーマレジストリの仕組み](schema-registry-works.md) 」を参照してください。 **Topics** + [スキーマ](#schema-registry-schemas) + [レジストリ](#schema-registry-registries) + [スキーマのバージョニングと互換性](#schema-registry-compatibility) + [オープンソース Serde ライブラリ](#schema-registry-serde-libraries) + [スキーマレジストリのクォータ](#schema-registry-quotas) + [スキーマレジストリの仕組み](schema-registry-works.md) + [スキーマレジストリの開始方法](schema-registry-gs.md) ## スキーマ *スキーマ* は、データレコードの構造と形式を定義します。スキーマは、信頼性の高いデータの公開、利用、または保存のための仕様をバージョニングしたものです。 この例の Avro のスキーマでは、形式と構造はレイアウトとフィールド名によって定義され、フィールド名の形式はデータ型 (例:`string`、`int`) により定義されています ``` { "type": "record", "namespace": "ABC_Organization", "name": "Employee", "fields": [ { "name": "Name", "type": "string" }, { "name": "Age", "type": "int" }, { "name": "address", "type": { "type": "record", "name": "addressRecord", "fields": [ { "name": "street", "type": "string" }, { "name": "zipcode", "type": "int" } ] } } ] } ``` この例の JSON 用の JSON スキーマ draft-07 では、形式を [JSON スキーマ組織](https://json-schema.org/)が定義しています。 ``` { "$id": "https://example.com/person.schema.json", "$schema": "http://json-schema.org/draft-07/schema#", "title": "Person", "type": "object", "properties": { "firstName": { "type": "string", "description": "The person's first name." }, "lastName": { "type": "string", "description": "The person's last name." }, "age": { "description": "Age in years which must be equal to or greater than zero.", "type": "integer", "minimum": 0 } } } ``` この例の Protobuf では、データ形式を [Protocol Buffers l言語のバージョン 2 (proto2)](https://developers.google.com/protocol-buffers/docs/reference/proto2-spec) で定義しています。 ``` syntax = "proto2"; package tutorial; option java_multiple_files = true; option java_package = "com.example.tutorial.protos"; option java_outer_classname = "AddressBookProtos"; message Person { optional string name = 1; optional int32 id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { optional string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phones = 4; } message AddressBook { repeated Person people = 1; } ``` ## レジストリ *レジストリ* は、スキーマの論理コンテナです。レジストリを使用すると、スキーマを整理したり、アプリケーションのアクセス制御を管理したりできます。レジストリは Amazon リソースネーム (ARN) を持っており、これにより、レジストリ内のスキーマ操作に対するさまざまなアクセス許可の整理と設定を可能にしています。 レジストリはデフォルトのまま使用することも可能ですが、必要な数の新しいレジストリを作成することもできます。 **AWS Glue スキーマレジストリでの階層** | | | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/schema-registry.html) | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/schema-registry.html) | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/schema-registry.html) | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/schema-registry.html) | ## スキーマのバージョニングと互換性 各スキーマは、複数のバージョン作成することができます。バージョニングは、スキーマに適用される互換性ルールによって制御されます。新しいスキーマバージョンの登録に関するリクエストについては、この規則に対するチェックがスキーマレジストリにより行われ後で処理が続行されます。 チェックポイントとしてマークされたスキーマバージョンは、スキーマの新しいバージョンを登録する際の互換性判断のために使用されます。スキーマが最初に作成されると、最初のバージョンがデフォルトのチェックポイントになります。スキーマのバージョンが増加した場合には、CLI/SDK により、一連の制約に従う `UpdateSchema` APIを使用しながら、チェックポイントに使用するスキーマのバージョンを変更できます。デフォルトでは、コンソールでスキーマの定義または互換モードを編集することで、チェックポイントが最新バージョンに変更されます。 互換モードを使用すると、スキーマを時間の経過とともにどのように増加させるか、あるいは増加させないかを制御できます。これらのモードは、データのプロデューサおよびコンシューマである、アプリケーション間の契約を形成します。スキーマの新しいバージョンがレジストリに送信されると、そのスキーマ名に適用されている互換性規則を使用して、新しいバージョンの受け付が可能かどうかが判断されます。互換モードには、NONE、DISABLED、BACKWARD、BACKWARD\$1ALL、FORWARD、FORWARD\$1ALL、FULL、FULL\$1ALL の 8 種類があります Avro データ形式では、フィールドはオプションまたは必須の両方の場合があります。フィールドがオプションの場合、`Type` には null が含まれます。必須フィールドでは、`Type` は null に設定されません。 Protobuf のデータ形式の場合、 proto2 構文ではフィールドを (繰り返しを含み) オプションまたは必須にすることができます。一方、proto3 構文ではすべてのフィールドが (繰り返しを含み) オプションとなります。すべての互換性ルールは、Protocol Buffers の仕様と、[Google の Protocol Buffers ドキュメント](https://developers.google.com/protocol-buffers/docs/overview#updating)を詳細に把握した上で定義されています。 + *NONE*: 互換モードは適用されません。このモードは、開発向けのシナリオか、スキーマに適用する互換モードがわからない場合に使用できます。新しいバージョンが追加されたとき、互換性チェックを受けずに受け入れられます。 + *DISABLED*: 互換性についてこの選択をすると、特定のスキーマのバージョン管理が不要になります。新しいバージョンを追加することはできません。 + *BACKWARD*: これは推奨の互換性モードで、コンシューマは、現在および過去のスキーマバージョンの両方からの読み取りが可能です。このモードを使用すると、フィールドの削除や任意のフィールドの追加を行う際に、以前のスキーマバージョンとの互換性をチェックできます。アプリケーションが最新のスキーマ用に作成された場合などが、BACKWARD の一般的なユースケースです。 **AVRO** 例えば、名前 (必須)、姓 (必須)、E メール (必須)、電話番号 (オプション) で定義されているスキーマがあるとします。 次のスキーマバージョンで、必須である E メールフィールドが削除されたとしても、これは正常に登録されます。後方互換性のために、コンシューマは、現在および 1 つ前のスキーマバージョンを読み取れることが必要です。古いメッセージの余分な E メールフィールドが無視されるため、コンシューマーは新しいスキーマを読み取ることができます。 仮に、郵便番号などのフィールドを必須として追加する新しいスキーマバージョンが提案された場合、BACKWARD の互換モードでは正常に登録されません。新しいバージョンのコンシューマーは、必須な郵便番号フィールドを含まない、スキーマが変更される前の古いメッセージを読み取ることができないためです。ただし、新しいスキーマで郵便番号フィールドがオプションとして設定されていれば、提案されたバージョンは正常に登録されます。郵便番号フィールドはオプションなので、コンシューマーはこのフィールドなしでも古いスキーマを読み取れるためです。 **JSON** 例えば、あるスキーマバージョンが、名 (オプション)、姓 (オプション)、E メール (オプション)、電話番号 (オプション)で定義されているとします。 仮に、次に続くスキーマバージョンで電話番号プロパティがオプションとして追加された場合でも、元のスキーマバージョンで `additionalProperties` フィールドを false に設定しプロパティの追加を禁止しているのであれば、この新しいバージョンは正しく登録されます。後方互換性のために、コンシューマは、現在および 1 つ前のスキーマバージョンを読み取れることが必要です。コンシューマは、電話番号プロパティが存在しない元のスキーマで生成されたデータを読み取ることができます。 BACKWARD の互換モードで、オプションの電話番号プロパティを追加する新しいスキーマバージョンが提案された際に、元のスキーマバージョンで `additionalProperties` フィールドを true に設定し任意のプロパティの追加を許可していると、このバージョンは正しく登録されません。新しいバージョンのコンシューマは、スキーマが変更される前の古いメッセージを読み取ることができません。これは、別の型 (数ではなく文字列など) で記述された電話番号プロパティデータを、読み取ることができないためです。 **PROTOBUF** 例えば、`first name` (必須)、`last name` (必須)、`email` (必須) `phone number` (オプション) フィールドを持つ、proto2 構文の Message `Person` で定義されているスキーマバージョンを考えます。 AVRO での場合と同様に、次に続くスキーマバージョンで、必須である `email` フィールドが削除されたとしても、これは正常に登録されます。後方互換性のために、コンシューマは、現在および 1 つ前のスキーマバージョンを読み取れることが必要です。古いメッセージでは、余分な `email` フィールドが無視されるため、コンシューマーは新しいスキーマを読み取ることができます。 BACKWARD の互換モードでは、仮に `zip code` などのフィールドを必須として追加する新しいスキーマバージョンが提案された場合、これは正常に登録されません。スキーマが変更される前の古いメッセージには、必須な `zip code` フィールドが含まていないため、新しいバージョンのコンシューマーは、そのメッセージを読み取ることができないためです。ただし、新しいスキーマで `zip code` フィールドがオプションとして設定されていれば、提案されたバージョンは正常に登録されます。`zip code` フィールドはオプションなので、コンシューマーはこのフィールドなしでも古いスキーマを読み取れます。 gRPC ユースケースの場合、新しい RPC サービスまたは RPC メソッドを追加することで、後方互換性が変更されます。例えば、2 つの RPC メソッド `Foo` および `Bar` を使用する RPC サービス `MyService` で定義されている、スキーマバージョンがあるとします。 次に続くスキーマバージョンで、`Baz` という新しい RPC メソッドが追加された場合、これは正常に登録されます。新しく追加された RPC メソッド `Baz` はオプションのため、コンシューマーは元のスキーマで生成されたデータを、BACKWARD 互換性に従って読み取ることができます。 提案された新しいスキーマバージョンで、既存の RPC メソッド `Foo` を削除する場合、BACKWARD 互換性では正常に登録されません。新しいバージョンのコンシューマーは、スキーマが変更される前の古いメッセージを読み取ることができません。これは、gRPC アプリケーション内に RPC メソッド `Foo` が存在せず、データを理解して読み取れないためです。 + *BACKWARD\$1ALL*: この互換モードでは、コンシューマは現在および過去のすべてのスキーマバージョンの読み取りが可能です。このモードを使用すると、フィールドを削除したり任意のフィールドを追加する際に、以前のすべてのスキーマバージョンとの互換性をチェックできます。 + *FORWARD*: この互換モードにより、コンシューマは現在とその次のスキーマバージョンの両方を読み取ることができますが、それより後に続くバージョンを必ずしも読み取れる訳ではありません。このオプションを使用すると、フィールドを追加したり、任意のフィールドを削除したりする際に、最新のスキーマバージョンとの互換性をチェックできます。過去のスキーマ用に作成されたアプリケーションが、より新しいスキーマを処理できる必要がある場合などが、FORWARD の一般的なユースケースです。 **AVRO** 例えば、あるスキーマバージョンが、名 (必須)、姓 (必須)、E メール (オプション) で定義されているとします。 この場合、電話番号などのフィールドを必須として追加する新しいスキーマバージョンは正常に登録されます。FORWARD 互換モードでは、新しいスキーマで生成されたデータを、コンシューマーが以前のバージョンを使用して読み取れることが必要です。 必須である名 (ファーストネーム) のフィールドを削除するスキーマバージョンが提案されとしても、FORWARD 互換モードでは正常に登録されません。名の必須フィールドがないので、以前のバージョンのコンシューマーが提案されたスキーマを読み取ることができなくなるためです。しかし、名 (ファーストネーム) のフィールドが本来オプションであれば、オプションの名のフィールドを持たない新しいスキーマに基づいたデータをコンシューマーが読み取りできるため、提案された新しいスキーマは正常に登録されます。 **JSON** 例えば、あるスキーマバージョンが、名 (オプション)、姓 (オプション)、E メール (オプション)、電話番号 (オプション)で定義されているとします。 オプションの電話番号プロパティを削除する新しいスキーマバージョンの場合、このスキーマバージョンで `additionalProperties` フィールドを false に設定しプロパティの追加を禁止しているのであれば、正しく登録されます。FORWARD 互換モードでは、新しいスキーマで生成されたデータを、コンシューマーが以前のバージョンを使用して読み取れることが必要です。 オプションの電話番号プロパティを削除するスキーマバージョンが提案された際に、この新しいスキーマバージョンで `additionalProperties` フィールドを true に設定し任意のプロパティの追加を許可していると、FORWARD の互換モードでは正しく登録されません。提案されたスキーマが、異なる型 (数ではなく文字列など) の電話番号プロパティを持つ場合には、以前のバージョンを使用するコンシューマで、このスキーマの読み取りが不可能になるためです。 **PROTOBUF** 例えば、`first name` (必須)、`last name` (必須)、`email` (オプション) のフィールドを持つ、proto2 構文の Message `Person` で定義されているスキーマバージョンを考えます。 AVRO の場合と同様に、`phone number` などの必須フィールドを追加する新しいスキーマバージョンの場合、これは正常に登録されます。FORWARD 互換モードでは、新しいスキーマで生成されたデータを、コンシューマーが以前のバージョンを使用して読み取れることが必要です。 必須である名 `first name` フィールドを削除するスキーマバージョンが提案されとしても、FORWARD 互換モードでは正常に登録されません。必須である `first name` フィールドがないので、以前のバージョンのコンシューマーは、提案されたスキーマを読み取ることができなくなるためです。しかし、`first name` フィールドが本来オプションであれば、新しいスキーマに `first name` フィールドがないとしてもこれはオプションであるため、コンシューマーはこのスキーマ基づいたデータを読み取ることが可能であり、したがって提案された新しいスキーマは正常に登録されます。 gRPC ユースケースの場合、RPC サービスまたは RPC メソッドを削除すると、前方互換性が変更されます。例えば、2 つの RPC メソッド `Foo` および `Bar` を使用する RPC サービス `MyService` で定義されている、スキーマバージョンがあるとします。 次に続くスキーマバージョンが、`Foo` という名前の既存の RPC メソッドを削除する場合も、これは FORWARD 互換性に従って正常に登録されます。コンシューマーは、新しいスキーマで生成されたデータを、以前のバージョンを使用して読み取ることが可能です。RPC メソッド `Baz` を追加するスキーマバージョンが提案され場合、これは FORWARD 互換モードでは正常に登録されません。RPC メソッド `Baz` がないので、以前のバージョンのコンシューマーは、この提案されたスキーマを読み取ることができないためです。 + *FORWARD\$1ALL*: この互換モードでは、任意の新しい登録済みスキーマのプロデューサーによって書き込まれたデータを読み取ることを、コンシューマに許可します。この選択は、フィールドを追加したり、オプションフィールドを削除したり、以前のすべてのスキーマバージョンとの互換性を確認したりする必要がある場合に使用できます。 + *FULL*: この互換モードにより、コンシューマーは、1 つ前または次のバージョンのスキーマを使用するプロデューサーによって書き込まれたデータを読み取ることができますが、それ以前またはそれ以降のバージョンについては読み取れません。このモードでは、任意のフィールドを追加または削除する際に、最新のスキーマバージョンとの互換性をチェックできます。 + *FULL\$1ALL*: この互換モードにより、コンシューマーは、過去の任意のスキーマバージョンを使用するプロデューサーによって書き込まれたデータを読み取ることができます。このモードは、オプションのフィールドを追加または削除する際に、過去のすべてのスキーマバージョンとの互換性をチェックするために使用できます。 ## オープンソース Serde ライブラリ AWS では、データをシリアル化および非シリアル化するためのフレームワークとして、オープンソースの Serde ライブラリが用意されています。このオープンソースなライブラリ設計により、一般的なオープンソースのアプリケーションやフレームワークが、それぞれのプロジェクトでこれらのライブラリをサポートできるようにしています。 Serde ライブラリの仕組みの詳細については、「[スキーマレジストリの仕組み](schema-registry-works.md)」を参照してください。 ## スキーマレジストリのクォータ AWS のクォータ (制限とも呼ばれます) は、AWS アカウントのリソース、アクション、および制限の最大値です。以下に、AWS Glue のスキーマレジストリにおけるソフト制限を示します。 **スキーマバージョンのメタデータでのキー値ペアの数。** AWS リージョンごとの各 SchemaVersion において、最大 10 個のキーと値のペアを使用できます。 メタデータでのキーと値のペアは、[QuerySchemaVersionMetadata アクション (Python: query\$1schema\$1version\$1metadata)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-QuerySchemaVersionMetadata) または [PutSchemaVersionMetadata アクション (Python: put\$1schema\$1version\$1metadata)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-PutSchemaVersionMetadata) APIを使用して表示または設定できます。 AWS Glue のスキーマレジストリでのハード制限は次のとおりです。 **レジストリ** このアカウントでは、AWS リージョンごとに最大 100 のレジストリを使用できます。 **SchemaVersion** このアカウントでは、AWS リージョンごとに最大 10000 のスキーマバージョンを使用できます。 各新しいスキーマは新しいスキーマバージョンを作成します。したがって、各スキーマに 1 つのバージョンしかない場合、リージョンごとの各アカウントには理論的に最大 10000 のスキーマを使用できます。 **スキーマペイロード** スキーマペイロードには、170 KB のサイズ制限があります。 # スキーマレジストリの仕組み このセクションでは、スキーマレジストリでシリアル化および非シリアル化のプロセスの仕組みについて説明します。 1. スキーマの登録: スキーマがレジストリにまだ存在しない場合、スキーマを保存先の名前と同じスキーマ名で登録することができます (test\$1topic、test\$1stream、prod\$1firehose など)。あるいは、プロデューサーがスキーマのカスタム名を指定することも可能です。プロデューサーは、source: msk\$1kafka\$1topic\$1A などのメタデータとしてスキーマにキーと値のペアを追加したり、スキーマ作成時に AWS タグをそのスキーマに追加したりできます。スキーマが登録されると、Schema Registry はスキーマのバージョン ID をシリアライザに返します。スキーマが存在するものの、シリアライザが存在しない新しいバージョンを使用している場合、それを新しいバージョンとして登録する前に、Schema Registry はスキーマ参照で互換性ルールを確認して、新しいバージョンに関する互換性を確保します。 スキーマの登録には、手動登録と自動登録の 2 つの方法があります。スキーマを手動で登録するには、AWS Glue コンソールまたは CLI/SDK を使用します。 シリアライザ設定で自動登録が有効化されている場合は、スキーマの自動登録が実行されます。プロデューサ設定で `REGISTRY_NAME` が指定されていない場合、自動登録はデフォルトのレジストリ (default-registry) の下に新しいスキーマバージョンを登録します。自動登録プロパティの指定については、「[SerDe ライブラリのインストール](schema-registry-gs-serde.md)」を参照してください。 1. シリアライザがスキーマに関してデータレコードを検証: データを生成するアプリケーションがそのスキーマを登録した場合、Schema Registry のシリアライザは、アプリケーションによって生成されるレコードが、登録されたスキーマに一致するフィールドとデータ型で構造化されていることを検証します。レコードのスキーマが登録されたスキーマと一致しない場合、シリアライザは例外を出力し、アプリケーションは、そのレコードを送信先にデリバリすることに失敗します。 スキーマが存在せず、プロデューサー設定を介してスキーマ名が指定されてもいない場合は、スキーマがトピック名 (Apache Kafka または Amazon MSK の場合) あるいはストリーム名 (Kinesis Data Streams の場合) と同じ名前で作成されます。 すべてのレコードは、スキーマ定義とデータを含みます。スキーマ定義は、Schema Registry 内の既存のスキーマおよびバージョンに関して照会されます。 デフォルトでは、プロデューサは、登録済みスキーマのスキーマ定義とスキーマバージョン ID をキャッシュします。レコードのスキーマバージョン定義がキャッシュ内に保存されたものと一致しない場合、プロデューサーは Schema Registry を使用してスキーマの検証を試みます。スキーマのバージョンが有効と認められた場合、そのバージョン ID と定義はプロデューサにローカルにキャッシュされます。 [SerDe ライブラリのインストール](schema-registry-gs-serde.md) のステップ 3 のように、オプションのプロデューサプロパティにより、デフォルトのキャッシュ期間 (24 時間) を調整することが可能です。 1. レコードのシリアル化と配信: レコードがスキーマに準拠している場合、シリアライザは各レコードをスキーマのバージョン ID で装飾し、選択したデータ形式 (AVRO、JSON、Protobuf 他の形式は追加予定) に基づいてシリアル化した上で、そのレコードを (プロデューサーのオプション設定により) 圧縮し送信先に送ります。 1. コンシューマーがデータを非シリアル化: このデータを読み取るコンシューマーは、レコードペイロードからのスキーマバージョン ID を解析する、Schema Registry のデシリアライザ用ライブラリを使用します。 1. デシリアライザが Schema Registry からのスキーマをリクエスト: デシリアライザが特定のスキーマバージョン ID を持つレコードを初めて認識すると、そのデシリアライザは、スキーマバージョン ID を使用してスキーマレジストリからスキーマを要求します。その後、そのスキーマをコンシューマ上でローカルにキャッシュします。Schema Registry でレコードの非シリアル化が不可能な場合、コンシューマはレコードからのデータをログに記録し、処理を続行するかアプリケーションを停止できます。 1. デシリアライザがスキーマを使用してレコードを非シリアル化: デシリアライザは、Schema Registry からスキーマバージョン ID を取得する際に (プロデューサーによって送信されたレコードが圧縮されている場合は) レコードを解凍し、スキーマを使用してレコードを非シリアル化します。これで、アプリケーションはレコードを処理できます。 **注記** 暗号化: クライアントは、HTTPS 上での TLS 暗号化を使用して転送中のデータを暗号化する API 呼び出しを介して Schema Registry と通信します。Schema Registry に保存されているスキーマは、サービス管理のAWS Key Management Service(AWS KMS) キーにより常に暗号化されます。 **注記** ユーザー認可: Schema Registry は、アイデンティティベースの IAM ポリシーをサポートします。 # スキーマレジストリの開始方法 以下のセクションでは、Schema Registry のセットアップと使用に関する概要とチュートリアルを示します。スキーマレジストリの概念および各コンポーネントの詳細については、「[AWS Glue スキーマレジストリ](schema-registry.md)」を参照してください。 **Topics** + [SerDe ライブラリのインストール](schema-registry-gs-serde.md) + [AWS Glue Schema Registry との統合](schema-registry-integrations.md) + [サードパーティー製のスキーマレジストリから AWS Glue Schema Registry への移行](schema-registry-integrations-migration.md) # SerDe ライブラリのインストール SerDe ライブラリは、データのシリアル化と非シリアル化のためのフレームワークを提供します。 データを生成するアプリケーション (総称してシリアライザ) 用の、オープンソースのシリアライザをインストールします。シリアライザは、シリアル化、圧縮、および Schema Registry とのやり取りを処理します。シリアライザは、Schema Registry 対応の送信先 (Amazon MSK など) に書き込まれるレコードから、スキーマを自動的に抽出します。同様に、データを利用するアプリケーションには、オープンソースのデシリアライザをインストールします。 # Java 実装 **注記** 前提条件: 次のステップを実行する前に、Amazon Managed Streaming for Apache Kafka (Amazon MSK) または Apache Kafka クラスターを起動しておく必要があります。使用するプロデューサーとコンシューマーは、Java 8 以上で実行する必要があります。 プロデューサとコンシューマにライブラリをインストールするには 1. プロデューサとコンシューマ両方の pom.xml ファイルの中で、以下のコードにより依存関係を追加します。 ``` software.amazon.glue schema-registry-serde 1.1.5 ``` または、[AWS Glue Schema Registry GitHub リポジトリ](https://github.com/awslabs/aws-glue-schema-registry)からクローンを作成することもできます。 1. 次の必須プロパティを使用してプロデューサをセットアップします。 ``` props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName()); // Can replace StringSerializer.class.getName()) with any other key serializer that you may use props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, GlueSchemaRegistryKafkaSerializer.class.getName()); props.put(AWSSchemaRegistryConstants.AWS_REGION, "us-east-2"); properties.put(AWSSchemaRegistryConstants.DATA_FORMAT, "JSON"); // OR "AVRO" ``` 既存のスキーマがない場合は、自動登録を有効にします (次のステップ)。適用できるスキーマがある場合は、「my-schema」をそのスキーマ名に置き換えます。また、スキーマの自動登録が無効になっている場合は、「registry-name」を指定する必要もあります。スキーマが「default-registry」の下に作成されている場合は、レジストリ名を省略できます。 1. (オプション) これらのオプションのプロデューサープロパティのいずれかを設定します。プロパティの詳細については、[ReadMe ファイル](https://github.com/awslabs/aws-glue-schema-registry/blob/master/README.md) を参照してください。 ``` props.put(AWSSchemaRegistryConstants.SCHEMA_AUTO_REGISTRATION_SETTING, "true"); // If not passed, uses "false" props.put(AWSSchemaRegistryConstants.SCHEMA_NAME, "my-schema"); // If not passed, uses transport name (topic name in case of Kafka, or stream name in case of Kinesis Data Streams) props.put(AWSSchemaRegistryConstants.REGISTRY_NAME, "my-registry"); // If not passed, uses "default-registry" props.put(AWSSchemaRegistryConstants.CACHE_TIME_TO_LIVE_MILLIS, "86400000"); // If not passed, uses 86400000 (24 Hours) props.put(AWSSchemaRegistryConstants.CACHE_SIZE, "10"); // default value is 200 props.put(AWSSchemaRegistryConstants.COMPATIBILITY_SETTING, Compatibility.FULL); // Pass a compatibility mode. If not passed, uses Compatibility.BACKWARD props.put(AWSSchemaRegistryConstants.DESCRIPTION, "This registry is used for several purposes."); // If not passed, constructs a description props.put(AWSSchemaRegistryConstants.COMPRESSION_TYPE, AWSSchemaRegistryConstants.COMPRESSION.ZLIB); // If not passed, records are sent uncompressed ``` 自動登録では、スキーマのバージョンがデフォルトのレジストリ (default-registry) に登録されます。`SCHEMA_NAME` が前のステップで指定されていない場合、トピック名は `SCHEMA_NAME` として推定されます。 互換モードの詳細については、[スキーマのバージョニングと互換性](schema-registry.md#schema-registry-compatibility) を参照してください。 1. 以下の必須プロパティを使用してコンシューマを設定します。 ``` props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName()); props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, GlueSchemaRegistryKafkaDeserializer.class.getName()); props.put(AWSSchemaRegistryConstants.AWS_REGION, "us-east-2"); // Pass an AWS リージョン props.put(AWSSchemaRegistryConstants.AVRO_RECORD_TYPE, AvroRecordType.GENERIC_RECORD.getName()); // Only required for AVRO data format ``` 1. (オプション) これらのオプションのコンシューマプロパティを設定します。プロパティの詳細については、[ReadMe ファイル](https://github.com/awslabs/aws-glue-schema-registry/blob/master/README.md) を参照してください。 ``` properties.put(AWSSchemaRegistryConstants.CACHE_TIME_TO_LIVE_MILLIS, "86400000"); // If not passed, uses 86400000 props.put(AWSSchemaRegistryConstants.CACHE_SIZE, "10"); // default value is 200 props.put(AWSSchemaRegistryConstants.SECONDARY_DESERIALIZER, "com.amazonaws.services.schemaregistry.deserializers.external.ThirdPartyDeserializer"); // For migration fall back scenario ``` # C\$1 実装 **注記** 前提条件: 次のステップを実行する前に、Amazon Managed Streaming for Apache Kafka (Amazon MSK) または Apache Kafka クラスターを起動しておく必要があります。使用するプロデューサーとコンシューマーは、.NET 8.0 以上で実行する必要があります。 ## インストール C\$1 アプリケーションの場合は、次のいずれかの方法を使用して AWS Glue Schema Registry SerDe NuGet パッケージをインストールします。 **.NET CLI:** パッケージをインストールするには、次のコマンドを使用します。 ``` dotnet add package Aws.Glue.SchemaRegistry --version 1.0.0- ``` ここで、`` は `1.0.0-linux-x64`、`1.0.0-linux-musl-x64` または `1.0.0-linux-arm64` です。 **PackageReference (.csproj ファイル内):** プロジェクトファイルに次の内容を追加します。 ``` ``` ここで、`` は `1.0.0-linux-x64`、`1.0.0-linux-musl-x64` または `1.0.0-linux-arm64` です。 ## 設定ファイルのセットアップ 必要な設定で設定プロパティファイル (`gsr-config.properties` など) を作成します。 **最小限の設定:** 以下に最小限の設定例を示します。 ``` region=us-east-1 registry.name=default-registry dataFormat=AVRO schemaAutoRegistrationEnabled=true ``` ## Kafka SerDes 用の C\$1 Glue スキーマクライアントライブラリの使用 **シリアライザーの使用例:** 次の例は、シリアライザーの使用方法を示しています。 ``` private static readonly string PROTOBUF_CONFIG_PATH = ""; var protobufSerializer = new GlueSchemaRegistryKafkaSerializer(PROTOBUF_CONFIG_PATH); var serialized = protobufSerializer.Serialize(message, message.Descriptor.FullName); // send serialized bytes to Kafka using producer.Produce(serialized) ``` **デシリアライザーの使用例:** 次の例は、デシリアライザーの使用方法を示しています。 ``` private static readonly string PROTOBUF_CONFIG_PATH = ""; var dataConfig = new GlueSchemaRegistryDataFormatConfiguration( new Dictionary { { GlueSchemaRegistryConstants.ProtobufMessageDescriptor, message.Descriptor } } ); var protobufDeserializer = new GlueSchemaRegistryKafkaDeserializer(PROTOBUF_CONFIG_PATH, dataConfig); // read message from Kafka using serialized = consumer.Consume() var deserializedObject = protobufDeserializer.Deserialize(message.Descriptor.FullName, serialized); ``` ## SerDes 用の KafkaFlow での C\$1 Glue スキーマクライアントライブラリの使用 **シリアライザーの使用例:** 次の例は、シリアライザーを使用して KafkaFlow を設定する方法を示しています。 ``` services.AddKafka(kafka => kafka .UseConsoleLog() .AddCluster(cluster => cluster .WithBrokers(new[] { "localhost:9092" }) .AddProducer(producer => producer .DefaultTopic("customer-events") .AddMiddlewares(m => m .AddSerializer>( () => new GlueSchemaRegistryKafkaFlowProtobufSerializer("config/gsr-config.properties") ) ) ) ) ); ``` **デシリアライザーの使用例:** 次の例は、デシリアライザーを使用して KafkaFlow を設定する方法を示しています。 ``` .AddConsumer(consumer => consumer .Topic("customer-events") .WithGroupId("customer-group") .WithBufferSize(100) .WithWorkersCount(10) .AddMiddlewares(middlewares => middlewares .AddDeserializer>( () => new GlueSchemaRegistryKafkaFlowProtobufDeserializer("config/gsr-config.properties") ) .AddTypedHandlers(h => h.AddHandler()) ) ) ``` ## オプションのプロデューサープロパティ 追加のオプションプロパティを使用して、設定ファイルを拡張できます。 ``` # Auto-registration (if not passed, uses "false") schemaAutoRegistrationEnabled=true # Schema name (if not passed, uses topic name) schema.name=my-schema # Registry name (if not passed, uses "default-registry") registry.name=my-registry # Cache settings cacheTimeToLiveMillis=86400000 cacheSize=200 # Compatibility mode (if not passed, uses BACKWARD) compatibility=FULL # Registry description description=This registry is used for several purposes. # Compression (if not passed, records are sent uncompressed) compressionType=ZLIB ``` ## サポートされている日付書式 Java と C\$1 の両方の実装は、同じデータ形式をサポートしています。 + *AVRO*: Apache Avro バイナリ形式 + *JSON*: JSON スキーマ形式 + *PROTOBUF*: プロトコルバッファ形式 ## 注意事項 + ライブラリの使用を開始するには、[https://www.nuget.org/packages/AWS.Glue.SchemaRegistry](https://www.nuget.org/packages/AWS.Glue.SchemaRegistry) にアクセスしてください + ソースコードは、[https://github.com/awslabs/aws-glue-schema-registry](https://github.com/awslabs/aws-glue-schema-registry) で入手できます # レジストリを作成する AWS Glue API または AWS Glue コンソールを使用して、デフォルトのレジストリを使用することも、必要な数の新しいレジストリを作成することもできます。 **AWS Glue API** ここでの手順により、AWS Glue API を使用しながら対象のタスクを実行できます。 AWS Glue Schema Registry API で AWS CLI を使用するには、最新バージョンの AWS CLI 使用する必要が有ります。 新しいレジストリを追加するには、[CreateRegistry アクション (Python: create\$1registry)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-CreateRegistry) APIを使用します。`RegistryName` では、作成するレジストリの名前を指定します。この文字数は最大 255 までで、文字、数字、ハイフン、アンダースコア、ドル記号、およびハッシュ記号のみ使用できます。 2,048 バイト以下で「[URI アドレスの複数行の文字列パターン](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-common.html#aws-glue-api-common-_string-patterns)」に一致する文字列として `Description` を指定します。 オプションで、キーと値のペアのマップ配列として、1 つ以上の `Tags` をレジストリに指定します。 ``` aws glue create-registry --registry-name registryName1 --description description ``` 作成されたレジストリには、Amazon リソースネーム (ARN) が割り当てられます。これは、`RegistryArn` API 応答により表示することが可能です。この段階でレジストリ作成が完了しているので、そのレジストリのために 1 つ以上のスキーマを作成します。 **AWS Glue コンソール** AWS Glue コンソールで新しいレジストリを追加するには 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインの [**Data catalog**] (データカタログ) で、[**Schema registries**] (スキーマレジストリ) をクリックします。 1. [**Add registry**] (レジストリを追加) をクリックします。 1. [**Registry name**] (レジストリ名) に、文字、数字、ハイフン、アンダースコアを含むレジストリの名前を入力します。この名前は変更できません。 1. レジストリの [**Description**] (説明) を入力します　(オプション)。 1. オプションで、1 つ以上のタグをレジストリに適用します。[**Add new tag**] (新しいタグを追加) を選択し、[**Tag key**] (タグキー) とオプションの [**Tag value**] (タグ値) を指定します。 1. [**Add registry**] (レジストリを追加) をクリックします。 ![\[レジストリの作成例。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/schema_reg_create_registry.png) 作成されたレジストリには、Amazon リソースネーム (ARN) が割り当てられます。これは、[**Schema registries**] (スキーマレジストリ) のリストから選択して表示することが可能です。この段階でレジストリ作成が完了しているので、そのレジストリのために 1 つ以上のスキーマを作成します。 # JSON の特定のレコード (JAVA POJO) 処理する 従来の単純な Java オブジェクト (POJO) を使用して、オブジェクトをレコードとして渡すことができます。これは、AVRO における特定のレコードの概念と類似しています。[mbknor-jackson-jsonschema](https://github.com/mbknor/mbknor-jackson-jsonSchema) により、渡された POJO の JSON スキーマを生成できます。また、このライブラリでは、JSON スキーマに追加情報を挿入することもできます。 AWS Glue Schema Registry ライブラリは、スキーマに注入された「className」フィールドを使用して、完全に分類されたクラス名を提供します。「className」フィールドは、そのクラスのオブジェクト内での非シリアル化のために、デシリアライザによって使用されます。 ``` Example class : @JsonSchemaDescription("This is a car") @JsonSchemaTitle("Simple Car Schema") @Builder @AllArgsConstructor @EqualsAndHashCode // Fully qualified class name to be added to an additionally injected property // called className for deserializer to determine which class to deserialize // the bytes into @JsonSchemaInject( strings = {@JsonSchemaString(path = "className", value = "com.amazonaws.services.schemaregistry.integrationtests.generators.Car")} ) // List of annotations to help infer JSON Schema are defined by https://github.com/mbknor/mbknor-jackson-jsonSchema public class Car { @JsonProperty(required = true) private String make; @JsonProperty(required = true) private String model; @JsonSchemaDefault("true") @JsonProperty public boolean used; @JsonSchemaInject(ints = {@JsonSchemaInt(path = "multipleOf", value = 1000)}) @Max(200000) @JsonProperty private int miles; @Min(2000) @JsonProperty private int year; @JsonProperty private Date purchaseDate; @JsonProperty @JsonFormat(shape = JsonFormat.Shape.NUMBER) private Date listedDate; @JsonProperty private String[] owners; @JsonProperty private Collection serviceChecks; // Empty constructor is required by Jackson to deserialize bytes // into an Object of this class public Car() {} } ``` # スキーマの作成 スキーマは、AWS Glue API または AWS Glue コンソールを使用して作成できます。 **AWS Glue API** ここでの手順により、AWS Glue API を使用しながら対象のタスクを実行できます。 新しいスキーマを追加するには [CreateSchema アクション (Python: create\$1schema)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-CreateSchema) API を使用します。 `RegistryId` 構造体を使用して、スキーマのレジストリを指定します。または、`RegistryId` を省略すると、デフォルトのレジストリが使用されます。 文字、数字、ハイフン、アンダースコアを使用し、`DataFormat` として **AVRO** または **JSON** を設定しながら `SchemaName` を指定します。一度スキーマに設定された `DataFormat` は変更できません。 `Compatibility` モードを指定する。 + *Backward (推奨)* – コンシューマは、現在のバージョンと 1 つ前のバージョンの両方を読み取ることができます。 + *Backward all* – コンシューマは、現在のバージョンと過去のすべてのバージョンを読み取ることができます。 + *Forward* – コンシューマは、現在のバージョンと次に続くバージョンの両方を読み取ることができます。 + *Forward all* – コンシューマは、現在のバージョンと後続のすべてのバージョンの両方を読み取ることができます。 + *Full* – Backward all と Forward all を組み合わせたモードです。 + *Full all* – Backward all と Forward all を組み合わせたモードです。 + *None* – 互換性チェックは実行されません。 + *Disabled* – このスキーマのバージョニングを抑止します。 オプションで、スキーマに `Tags` を指定します。 `SchemaDefinition` を指定することで、スキーマのデータ形式を Avro、JSON、もしくは Protobuf として定義します。例を参照してください。 Avro データ形式の場合: ``` aws glue create-schema --registry-id RegistryName="registryName1" --schema-name testschema --compatibility NONE --data-format AVRO --schema-definition "{\"type\": \"record\", \"name\": \"r1\", \"fields\": [ {\"name\": \"f1\", \"type\": \"int\"}, {\"name\": \"f2\", \"type\": \"string\"} ]}" ``` ``` aws glue create-schema --registry-id RegistryArn="arn:aws:glue:us-east-2:901234567890:registry/registryName1" --schema-name testschema --compatibility NONE --data-format AVRO --schema-definition "{\"type\": \"record\", \"name\": \"r1\", \"fields\": [ {\"name\": \"f1\", \"type\": \"int\"}, {\"name\": \"f2\", \"type\": \"string\"} ]}" ``` JSON データ形式の場合: ``` aws glue create-schema --registry-id RegistryName="registryName" --schema-name testSchemaJson --compatibility NONE --data-format JSON --schema-definition "{\"$schema\": \"http://json-schema.org/draft-07/schema#\",\"type\":\"object\",\"properties\":{\"f1\":{\"type\":\"string\"}}}" ``` ``` aws glue create-schema --registry-id RegistryArn="arn:aws:glue:us-east-2:901234567890:registry/registryName" --schema-name testSchemaJson --compatibility NONE --data-format JSON --schema-definition "{\"$schema\": \"http://json-schema.org/draft-07/schema#\",\"type\":\"object\",\"properties\":{\"f1\":{\"type\":\"string\"}}}" ``` Protobuf データ形式の場合: ``` aws glue create-schema --registry-id RegistryName="registryName" --schema-name testSchemaProtobuf --compatibility NONE --data-format PROTOBUF --schema-definition "syntax = \"proto2\";package org.test;message Basic { optional int32 basic = 1;}" ``` ``` aws glue create-schema --registry-id RegistryArn="arn:aws:glue:us-east-2:901234567890:registry/registryName" --schema-name testSchemaProtobuf --compatibility NONE --data-format PROTOBUF --schema-definition "syntax = \"proto2\";package org.test;message Basic { optional int32 basic = 1;}" ``` **AWS Glue コンソール** AWS Glue コンソールを使用して新しいスキーマを追加するには 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインの [**Data catalog**] (データカタログ) で、[**Schemas**] (スキーマ) をクリックします。 1. [**Add schema**] (スキーマを追加) をクリックします。 1. [**Schema name**] (スキーマ名) に、文字、数字、ハイフン、アンダースコア、ドル記号、ハッシュマークで構成された名前を入力します。この名前は変更できません。 1. [**Registry**] (レジストリ) ドロップダウンメニューから、スキーマの保存先となるレジストリを選択します。作成後は、親レジストリを変更することはできません。 1. [**Data format**] (データ形式) は、「*Apache Avro*」または「*JSON*」のままにしておきます。この形式は、このスキーマのすべてのバージョンに適用されます。 1. [**Compatibility mode**] (互換モード) をクリックします。 + *Backward (推奨)* – レシーバーは、現在のバージョンと 1 つ前のバージョンの両方を読み取ることができます。 + *Backward All* – レシーバーは、現在および過去のすべてのバージョンを読み取ることができます。 + *Forward* – センダーは、現在のバージョンと 1 つ前のバージョンの両方に書き込むことができます。 + *Forward All* – センダーは、現在のバージョンと過去のすべてのバージョンに書き込むことができます。 + *Full* – Backward と Forward を組み合わせたモードです。 + *Full All* – Backward All と Forward All を組み合わせたモードです。 + *None* – 互換性チェックは実行されません。 + *Disabled* – このスキーマのバージョニングを抑止します。 1. [**Description**] (説明) に、レジストリのための説明 (オプション) を、最大 250 文字で入力します。 ![\[スキーマの作成例。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/schema_reg_create_schema.png) 1. オプションで、1 つ以上のタグをスキーマに適用します。[**Add new tag**] (新しいタグを追加) を選択し、[**Tag key**] (タグキー) とオプションの [**Tag value**] (タグ値) を指定します。 1. [**First schema バージョニング**] (最初のスキーマバージョン) ボックスに、初期スキーマを入力するか貼り付けます。 Avro 形式については「[Avro データ形式での作業](#schema-registry-avro)」を参照 JSON 形式については「[JSON データ形式での操作](#schema-registry-json)」を参照 1. 必要に応じて、[**Add metadata**] (メタデータを追加) をクリックして、スキーマバージョンの注釈付けや分類を行うためのバージョンメタデータを追加します。 1. [**Create schema and version**] (スキーマとバージョンを作成する) をクリックします。 ![\[スキーマの作成例。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/schema_reg_create_schema2.png) スキーマが作成され、[**Schemas**] (スキーマ) の下に一覧表示されます。 ## Avro データ形式での作業 Avro では、データのシリアル化とデータ交換サービスが利用できます。Avro は、可読性と解釈しやすさのために、データ定義が JSON 形式で格納されます。データ自体はバイナリ形式で保存されます。 Apache Avro スキーマの定義については、「[Apache Avro specification](http://avro.apache.org/docs/current/spec.html)」を参照してください。 ## JSON データ形式での操作 JSON 形式では、データをシリアル化できます。JSON スキーマ形式の標準は、「[JSON Schema format](https://json-schema.org/)」で定義されています。 # スキーマまたはレジストリの更新 作成したスキーマ、スキーマバージョン、またはレジストリは、編集することができます。 ## レジストリの更新 レジストリは、AWS Glue API または AWS Glue コンソールを使用して更新できます。既存のレジストリの名前は変更できません。レジストリの説明は編集が可能です。 **AWS Glue API** 既存のレジストリを更新するには、[UpdateRegistry アクション (Python: update\$1registry)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-UpdateRegistry) API を使用します。 `RegistryId` 構造体を使用して、更新するレジストリを指定します。レジストリの説明を変更するには、`Description` を渡します。 ``` aws glue update-registry --description updatedDescription --registry-id RegistryArn="arn:aws:glue:us-east-2:901234567890:registry/registryName1" ``` **AWS Glue コンソール** AWS Glue コンソールを使用してレジストリを更新するには 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインの [**Data catalog**] (データカタログ) で、[**Schema registries**] (スキーマレジストリ) をクリックします。 1. レジストリの一覧から、そのチェックボックスをオンにして、レジストリを選択します。 1. [**Action**] (アクション) メニューで、[**Edit registry**] (レジストリの編集) を選択します。 # スキーマの更新 スキーマでは、説明または互換性設定の更新が行えます。 既存のスキーマを更新するには、[UpdateSchema アクション (Python: update\$1schema)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-UpdateSchema) API を使用します。 `SchemaId` 構造体を使用して、更新するスキーマを指定します。`VersionNumber` または `Compatibility` のいずれかを指定する必要があります。 コード例 11: ``` aws glue update-schema --description testDescription --schema-id SchemaName="testSchema1",RegistryName="registryName1" --schema-version-number LatestVersion=true --compatibility NONE ``` ``` aws glue update-schema --description testDescription --schema-id SchemaArn="arn:aws:glue:us-east-2:901234567890:schema/registryName1/testSchema1" --schema-version-number LatestVersion=true --compatibility NONE ``` # スキーマバージョンの追加。 スキーマバージョンを追加する際は、そのバージョンを比較して、新しいスキーマが受け入れられることを確認する必要があります。 既存のスキーマに新しいバージョンを追加するには、[RegisterSchemaVersion アクション (Python: register\$1schema\$1version)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-RegisterSchemaVersion) API を使用します。 `SchemaId` 構造体を使用して、バージョンを追加するスキーマを指定し、`SchemaDefinition` によりスキーマを定義します。 コード例 12: ``` aws glue register-schema-version --schema-definition "{\"type\": \"record\", \"name\": \"r1\", \"fields\": [ {\"name\": \"f1\", \"type\": \"int\"}, {\"name\": \"f2\", \"type\": \"string\"} ]}" --schema-id SchemaArn="arn:aws:glue:us-east-1:901234567890:schema/registryName/testschema" ``` ``` aws glue register-schema-version --schema-definition "{\"type\": \"record\", \"name\": \"r1\", \"fields\": [ {\"name\": \"f1\", \"type\": \"int\"}, {\"name\": \"f2\", \"type\": \"string\"} ]}" --schema-id SchemaName="testschema",RegistryName="testregistry" ``` 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインの [**Data catalog**] (データカタログ) で、[**Schemas**] (スキーマ) をクリックします。 1. チェックボックスをオンにして、スキーマのリストからスキーマを選択します。 1. チェックボックスをクリックして、リストから 1 つ以上のスキーマを選択します。 1. [**Action**] (アクションメニュー) から、[**Register new version**] (新しいバージョンを登録) を選択します。 1. [**New version**] (新しいバージョン) ボックスに、新しいスキーマを入力または貼り付けます。 1. **[Compare with previous version]** (過去のバージョンと比較) をクリックして、以前のスキーマのバージョンとの違いを確認します。 1. 必要に応じて、[**Add metadata**] (メタデータを追加) をクリックして、スキーマバージョンの注釈付けや分類を行うためのバージョンメタデータを追加します。[**Key**] (キー) および (オプションの) [**Value**] (値) を入力します。 1. [**Register version**] (バージョンの登録) をクリックします。 ![\[スキーマバージョンの追加。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/schema_reg_add_schema_version.png) バージョンの一覧の中に、スキーマのバージョンが表示されます。バージョンで互換モードが変更された場合、そのバージョンはチェックポイントとしてマークされます。 ## スキーマのバージョン比較の例。 [**Compare with previous version**] (過去のバージョンと比較) をクリックすると、以前のバージョンと新しいバージョンが一緒に表示されます。変更された情報は、次のように強調表示されます。 + *黄色*: 変更された情報を示します。 + *緑*: 最新バージョンで追加されたコンテンツを示します。 + *赤*: 最新バージョンで削除されたコンテンツを示します。 より古いバージョンと比較することも可能です。 ![\[スキーマのバージョン比較の例。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/schema_reg_version_comparison.png) # スキーマまたはレジストリの削除 スキーマ、スキーマバージョン、またはレジストリの削除は永続的な操作であり、元に戻すことはできません。 ## スキーマの削除 レジストリ内で使用する必要がなくなったスキーマは、AWS マネジメントコンソール または [DeleteSchema アクション (Python: delete\$1schema)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-DeleteSchema) API を使用して削除することができます。。 1 つ以上のスキーマを削除することは永続的なアクションであり、元に戻すことはできません。(1 つあるいは複数の) スキーマが不要になったことを確認します。 レジストリからスキーマを削除するには、`SchemaId` 構造体により対象のスキーマを特定しながら [DeleteSchema アクション (Python: delete\$1schema)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-DeleteSchema) API を呼び出します。 例: ``` aws glue delete-schema --schema-id SchemaArn="arn:aws:glue:us-east-2:901234567890:schema/registryName1/schemaname" ``` ``` aws glue delete-schema --schema-id SchemaName="TestSchema6-deleteschemabyname",RegistryName="default-registry" ``` **AWS Glue コンソール** AWS Glue コンソールからスキーマを削除するには 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインの [**Data catalog**] (データカタログ) で、[**Schema registries**] (スキーマレジストリ) をクリックします。 1. レジストリのリストから、自分のスキーマを含むレジストリを選択します。 1. チェックボックスをクリックして、リストから 1 つ以上のスキーマを選択します。 1. [**Action**] (アクション) メニューで、[**Delete schema**] (スキーマの削除) をクリックします。 1. フィールドに「**Delete**」というテキストを入力して、削除を確定します。 1. **[削除]** を選択します。 指定した (1 つ以上の) スキーマがレジストリから削除されます。 ## スキーマバージョンの削除 スキーマはレジストリに蓄積されるので、不要なスキーマバージョンは、AWS マネジメントコンソール または [DeleteSchemaVersions アクション (Python: delete\$1schema\$1versions)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-DeleteSchemaVersions) API を使用して削除できます。1 つ以上のスキーマバージョンを削除することは永続的なアクションであり、元に戻すことはできません。そのスキーマバージョンが不要であることを確認します。 スキーマのバージョンを削除する場合は、以下の制約に注意してください。 + チェックポイントとなっているバージョンを削除することはできません。 + 25 を超えて連続するバージョンの範囲を削除することはできません。 + 最新のスキーマバージョンが保留状態にある場合は、削除は行えません。 `SchemaId` 構造体を使用してスキーマを指定し、削除するバージョンの範囲を `Versions` で指定します。バージョンまたはバージョンの範囲の指定の詳細については、「[DeleteRegistry アクション (Python: delete\$1registry)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-DeleteRegistry)」を参照してください。指定したスキーマバージョンがレジストリから削除されます。 この呼び出しの後に [ListSchemaVersions アクション (Python: list\$1schema\$1versions)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-ListSchemaVersions) API を呼び出すと、削除されたバージョンのステータスが一覧表示されます。 例: ``` aws glue delete-schema-versions --schema-id SchemaName="TestSchema6",RegistryName="default-registry" --versions "1-1" ``` ``` aws glue delete-schema-versions --schema-id SchemaArn="arn:aws:glue:us-east-2:901234567890:schema/default-registry/TestSchema6-NON-Existent" --versions "1-1" ``` 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインの [**Data catalog**] (データカタログ) で、[**Schema registries**] (スキーマレジストリ) をクリックします。 1. レジストリのリストから、自分のスキーマを含むレジストリを選択します。 1. チェックボックスをクリックして、リストから 1 つ以上のスキーマを選択します。 1. [**Action**] (アクション) メニューで、[**Delete schema**] (スキーマの削除) をクリックします。 1. フィールドに「**Delete**」というテキストを入力して、削除を確定します。 1. **[削除]** を選択します。 指定したスキーマバージョンがレジストリから削除されます。 # レジストリの削除 レジストリに含まれるスキーマの整理の必要性がなくなった場合は、そのレジストリを削除することができます。これらのスキーマは、別のレジストリに再割り当てする必要があります。 1 つ以上のレジストリを削除することは永続的なアクションであり、元に戻すことはできません。(1 つもしくは複数の) レジストリが不要であることを確認します。 デフォルトのレジストリは、AWS CLI を使用して削除できます。 **AWS Glue API** レジストリ全体を、登録されたスキーマとそのすべてのバージョンとともに削除するには、[DeleteRegistry アクション (Python: delete\$1registry)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-DeleteRegistry) API を呼び出します。`RegistryId` 構造体を使用し、レジストリを特定します。 例: ``` aws glue delete-registry --registry-id RegistryArn="arn:aws:glue:us-east-2:901234567890:registry/registryName1" ``` ``` aws glue delete-registry --registry-id RegistryName="TestRegistry-deletebyname" ``` 削除オペレーションのステータスを取得するには、非同期呼び出し後に `GetRegistry` API を呼び出します。 **AWS Glue コンソール** AWS Glue コンソールからレジストリの削除を行うには 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインの [**Data catalog**] (データカタログ) で、[**Schema registries**] (スキーマレジストリ) をクリックします。 1. チェックボックスをオンにして、リストからレジストリを選択します。 1. [**Action**] (アクション) メニューで、[**Delete registry**] (レジストリの削除) を選択します。 1. フィールドに「**Delete**」というテキストを入力して、削除を確定します。 1. **[削除]** を選択します。 選択したレジストリが AWS Glue から削除されます。 ## シリアライザ用の IAM の例 **注記** AWS 管理ポリシーは、一般的ユースケースに必要なアクセス許可を付与します。管理ポリシーを使用してスキーマのレジストリを管理する方法については、「[AWS Glue の AWS マネージド (事前定義) ポリシー](security-iam-awsmanpol.md#access-policy-examples-aws-managed)」を参照してください。 シリアライザの場合、以下と同様の最小限のポリシーを作成して、特定のスキーマ定義のために `schemaVersionId` を検索できるようにします。レジストリ内のスキーマを読み取るには、そのレジストリに対する読み取り許可が必要であることに注意してください。読み取り可能なレジストリは、`Resource` 句を使用して制限できます。 コード例 13: ``` { "Sid" : "GetSchemaByDefinition", "Effect" : "Allow", "Action" : [ "glue:GetSchemaByDefinition" ], "Resource" : ["arn:aws:glue:us-east-2:012345678:registry/registryname-1", "arn:aws:glue:us-east-2:012345678:schema/registryname-1/schemaname-1", "arn:aws:glue:us-east-2:012345678:schema/registryname-1/schemaname-2" ] } ``` さらに、以下の新しいメソッドを追加して、プロデューサに対し新しいスキーマとバージョンの作成を許可することもできます。レジストリ内でスキーマを追加/削除/拡大させるためには、そのレジストリを調査できることが必要です。調査することが可能なレジストリは、`Resource` 句を使用して制限できます。 コード例 14: ``` { "Sid" : "RegisterSchemaWithMetadata", "Effect" : "Allow", "Action" : [ "glue:GetSchemaByDefinition", "glue:CreateSchema", "glue:RegisterSchemaVersion", "glue:PutSchemaVersionMetadata", ], "Resource" : ["arn:aws:glue:aws-region:123456789012:registry/registryname-1", "arn:aws:glue:aws-region:123456789012:schema/registryname-1/schemaname-1", "arn:aws:glue:aws-region:123456789012:schema/registryname-1/schemaname-2" ] } ``` ## デシリアライザー用の IAM の例 デシリアライザ (コンシューマ側) の場合、以下のようなポリシーを作成する必要があります。これにより、非シリアル化のために Schema Registry からスキーマを取得することを、デシリアライザに対し許可します。レジストリ内のスキーマを取得するためには、そのレジストリを調査することが許可されている必要があります。 コード例 15: ``` { "Sid" : "GetSchemaVersion", "Effect" : "Allow", "Action" : [ "glue:GetSchemaVersion" ], "Resource" : ["*"] } ``` ## AWS PrivateLink を使用したプライベート接続 AWS Glue でインターフェイス VPC エンドポイントを定義しながら AWS PrivateLinkを使用すると、データのプロデユーサの VPC を AWS Glue に接続することができます。VPC インターフェイスエンドポイントにより、AWS ネットワーク内全体で VPC と AWS Glue 間の通信を処理します。詳細については、「[Using AWS Glue with VPC Endpoints](https://docs.aws.amazon.com/glue/latest/dg/vpc-endpoint.html)」を参照してください。 # Amazon CloudWatch メトリクスへのアクセス Amazon CloudWatch メトリクスは、CloudWatch の無料利用枠の一部として利用できます。これらのメトリクスは CloudWatch コンソールでアクセスできます。APIレベルのメトリクスとしては、CreateSchema (Success および Latency)、GetSchemaByDefinition (Success および Latency)、GetSchemaVersion (Success および Latency)、RegisterSchemaVersion (Success および Latency)、PutSchemaVersionMetadata (Success および Latency) があります。リソースレベルのメトリクスには、Registry.ThrottledByLimit、SchemaVersion.ThrottledByLimit、SchemaVersion.Size があります。 # スキーマレジストリの CloudFormation テンプレート例 以下に、CloudFormation で Schema Registry リソースを作成するためのテンプレート例を示します。アカウントにこのスタックを作成するには、上記のテンプレートを `SampleTemplate.yaml` ファイルにコピーした上で、次のコマンドを実行します。 ``` aws cloudformation create-stack --stack-name ABCSchemaRegistryStack --template-body "'cat SampleTemplate.yaml'" ``` この例では、レジストリを作成するために `AWS::Glue::Registry` を、スキーマを作成するために `AWS::Glue::Schema` を、スキーマバージョンを作成するために `AWS::Glue::SchemaVersion` を使用し、`AWS::Glue::SchemaVersionMetadata` によりスキーマバージョンのメタデータを記述しています。 ``` Description: "A sample CloudFormation template for creating Schema Registry resources." Resources: ABCRegistry: Type: "AWS::Glue::Registry" Properties: Name: "ABCSchemaRegistry" Description: "ABC Corp. Schema Registry" Tags: Project: "Foo" ABCSchema: Type: "AWS::Glue::Schema" Properties: Registry: Arn: !Ref ABCRegistry Name: "TestSchema" Compatibility: "NONE" DataFormat: "AVRO" SchemaDefinition: > {"namespace":"foo.avro","type":"record","name":"user","fields":[{"name":"name","type":"string"},{"name":"favorite_number","type":"int"}]} Tags: Project: "Foo" SecondSchemaVersion: Type: "AWS::Glue::SchemaVersion" Properties: Schema: SchemaArn: !Ref ABCSchema SchemaDefinition: > {"namespace":"foo.avro","type":"record","name":"user","fields":[{"name":"status","type":"string", "default":"ON"}, {"name":"name","type":"string"},{"name":"favorite_number","type":"int"}]} FirstSchemaVersionMetadata: Type: "AWS::Glue::SchemaVersionMetadata" Properties: SchemaVersionId: !GetAtt ABCSchema.InitialSchemaVersionId Key: "Application" Value: "Kinesis" SecondSchemaVersionMetadata: Type: "AWS::Glue::SchemaVersionMetadata" Properties: SchemaVersionId: !Ref SecondSchemaVersion Key: "Application" Value: "Kinesis" ``` # AWS Glue Schema Registry との統合 これらのセクションでは、AWS Glue スキーマレジストリとの統合について説明します。このセクションの例では、AVRO データ形式のスキーマを使用します。JSON データ形式のスキーマなど、その他の例については、「[AWS Glue Schema Registry open source repository](https://github.com/awslabs/aws-glue-schema-registry)」で、統合テストと ReadMe に関する情報をご覧ください。 **Topics** + [ユースケース: Schema Registry を Amazon MSK または Apache Kafka に接続する](#schema-registry-integrations-amazon-msk) + [ユースケース: Amazon Kinesis Data Streams と AWS Glue Schema Registry との統合](#schema-registry-integrations-kds) + [Amazon Managed Service for Apache Flink のユースケース](#schema-registry-integrations-kinesis-data-analytics-apache-flink) + [ユースケース: AWS Lambda との統合](#schema-registry-integrations-aws-lambda) + [ユースケース: AWS Glue Data Catalog](#schema-registry-integrations-aws-glue-data-catalog) + [ユースケース: AWS Glue ストリーミング](#schema-registry-integrations-aws-glue-streaming) + [ユースケース: Apache Kafka ストリーム](#schema-registry-integrations-apache-kafka-streams) ## ユースケース: Schema Registry を Amazon MSK または Apache Kafka に接続する Apache Kafka トピックにデータを書き込む場合には、以下の手順に従い作業を開始します。 1. Amazon Managed Streaming for Apache Kafka(Amazon MSK) または Apache Kafka のクラスターを作成し、少なくとも 1 つのトピックを含めます。Amazon MSK クラスターを作成する場合は、AWS マネジメントコンソール を使用します。「*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*」の「[Getting Started Using Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/getting-started.html)」にある手順に従います。 1. 上記の [SerDe ライブラリのインストール](schema-registry-gs-serde.md) ステップを実行します。 1. スキーマのレジストリ、スキーマ、またはスキーマバージョンを作成するには、このドキュメントにある [スキーマレジストリの開始方法](schema-registry-gs.md) セクションの手順に従います。 1. Amazon MSK または Apache Kafka のトピックとの間で、レコードの書き込みや読み取りを行うために、Schema Registry を使用してプロデューサとコンシューマを起動します。プロデューサとコンシューマのコード例は、Serdeライブラリの [ReadMe ファイル](https://github.com/awslabs/aws-glue-schema-registry/blob/master/README.md)から入手できます。プロデューサの Schema Registry ライブラリは、レコードを自動的にシリアル化し、スキーマバージョン ID でそのレコードを修飾します。 1. このレコードにスキーマが入力済みの場合、または自動登録が有効になっている場合には、スキーマが Schema Registry に登録されます。 1. AWS Glue Schema Registry ライブラリを使用して、Amazon MSK または Apache Kafka のトピックからスキーマの読み取りを行うコンシューマは、自動的に Schema Registry からスキーマを検索します。 ## ユースケース: Amazon Kinesis Data Streams と AWS Glue Schema Registry との統合 この統合には、既存の Amazon Kinesis データストリーム が必要です。詳細については、「*Amazon Kinesis Data Streams デベロッパーガイド*」の「[Getting Started with Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/getting-started.html)」を参照してください。 Kinesis データストリームでは、データの操作用に以下の 2 つの方法があります。 + Java の Kinesis Producer Library (KPL) および Kinesis Client Library (KCL) ライブラリを使用します。多言語サポートは提供されていません。 + AWS SDK for Java に用意されている `PutRecords`、`PutRecord`、および `GetRecords` Kinesis Data Streams API を使用します。 現在、KPL/KCL ライブラリを使用中であれば、そのメソッドを引き続き使用することをお勧めします。ここでの例に示すように、Schema Registry が統合済みの、更新された KCL および KPL バージョンを使用できます。それ以外で、KDS API を直接使用している場合には、サンプルコードを通じて AWS Glue Schema Registry を利用します。 Schema Registry との統合は、KPL v0.14.2 以降と KCL v2.3 以降でのみ使用できます。JSON データ形式による Schema Registry との統合は、KPL v0.14.8 以降および KCL v2.3.6 以降で使用できます。 ### Kinesis SDK V2 を使用したデータの操作 このセクションでは、Kinesis SDK V2 による Kinesis の操作について説明します。 ``` // Example JSON Record, you can construct a AVRO record also private static final JsonDataWithSchema record = JsonDataWithSchema.builder(schemaString, payloadString); private static final DataFormat dataFormat = DataFormat.JSON; //Configurations for Schema Registry GlueSchemaRegistryConfiguration gsrConfig = new GlueSchemaRegistryConfiguration("us-east-1"); GlueSchemaRegistrySerializer glueSchemaRegistrySerializer = new GlueSchemaRegistrySerializerImpl(awsCredentialsProvider, gsrConfig); GlueSchemaRegistryDataFormatSerializer dataFormatSerializer = new GlueSchemaRegistrySerializerFactory().getInstance(dataFormat, gsrConfig); Schema gsrSchema = new Schema(dataFormatSerializer.getSchemaDefinition(record), dataFormat.name(), "MySchema"); byte[] serializedBytes = dataFormatSerializer.serialize(record); byte[] gsrEncodedBytes = glueSchemaRegistrySerializer.encode(streamName, gsrSchema, serializedBytes); PutRecordRequest putRecordRequest = PutRecordRequest.builder() .streamName(streamName) .partitionKey("partitionKey") .data(SdkBytes.fromByteArray(gsrEncodedBytes)) .build(); shardId = kinesisClient.putRecord(putRecordRequest) .get() .shardId(); GlueSchemaRegistryDeserializer glueSchemaRegistryDeserializer = new GlueSchemaRegistryDeserializerImpl(awsCredentialsProvider, gsrConfig); GlueSchemaRegistryDataFormatDeserializer gsrDataFormatDeserializer = glueSchemaRegistryDeserializerFactory.getInstance(dataFormat, gsrConfig); GetShardIteratorRequest getShardIteratorRequest = GetShardIteratorRequest.builder() .streamName(streamName) .shardId(shardId) .shardIteratorType(ShardIteratorType.TRIM_HORIZON) .build(); String shardIterator = kinesisClient.getShardIterator(getShardIteratorRequest) .get() .shardIterator(); GetRecordsRequest getRecordRequest = GetRecordsRequest.builder() .shardIterator(shardIterator) .build(); GetRecordsResponse recordsResponse = kinesisClient.getRecords(getRecordRequest) .get(); List consumerRecords = new ArrayList<>(); List recordsFromKinesis = recordsResponse.records(); for (int i = 0; i < recordsFromKinesis.size(); i++) { byte[] consumedBytes = recordsFromKinesis.get(i) .data() .asByteArray(); Schema gsrSchema = glueSchemaRegistryDeserializer.getSchema(consumedBytes); Object decodedRecord = gsrDataFormatDeserializer.deserialize(ByteBuffer.wrap(consumedBytes), gsrSchema.getSchemaDefinition()); consumerRecords.add(decodedRecord); } ``` ### KPL/KCL ライブラリを使用したデータの操作 このセクションでは、KPL/KCL ライブラリを使用しての Kinesis Data Streams と Schema Registry の統合について説明します。KPL/KCL の使用方法については、「*Amazon Kinesis Data Streams デベロッパーガイド*」の「[Developing Producers Using the Amazon Kinesis Producer Library](https://docs.aws.amazon.com/streams/latest/dev/developing-producers-with-kpl.html)」を参照してください。 #### KPL で Schema Registry を設定する 1. AWS Glue Schema Registryで作成したデータ、データ形式、スキーマ名のスキーマ定義を行います。 1. 必要に応じて、`GlueSchemaRegistryConfiguration` オブジェクトも構成します。 1. `addUserRecord API` にスキーマオブジェクトを渡します。 ``` private static final String SCHEMA_DEFINITION = "{"namespace": "example.avro",\n" + " "type": "record",\n" + " "name": "User",\n" + " "fields": [\n" + " {"name": "name", "type": "string"},\n" + " {"name": "favorite_number", "type": ["int", "null"]},\n" + " {"name": "favorite_color", "type": ["string", "null"]}\n" + " ]\n" + "}"; KinesisProducerConfiguration config = new KinesisProducerConfiguration(); config.setRegion("us-west-1") //[Optional] configuration for Schema Registry. GlueSchemaRegistryConfiguration schemaRegistryConfig = new GlueSchemaRegistryConfiguration("us-west-1"); schemaRegistryConfig.setCompression(true); config.setGlueSchemaRegistryConfiguration(schemaRegistryConfig); ///Optional configuration ends. final KinesisProducer producer = new KinesisProducer(config); final ByteBuffer data = getDataToSend(); com.amazonaws.services.schemaregistry.common.Schema gsrSchema = new Schema(SCHEMA_DEFINITION, DataFormat.AVRO.toString(), "demoSchema"); ListenableFuture f = producer.addUserRecord( config.getStreamName(), TIMESTAMP, Utils.randomExplicitHashKey(), data, gsrSchema); private static ByteBuffer getDataToSend() { org.apache.avro.Schema avroSchema = new org.apache.avro.Schema.Parser().parse(SCHEMA_DEFINITION); GenericRecord user = new GenericData.Record(avroSchema); user.put("name", "Emily"); user.put("favorite_number", 32); user.put("favorite_color", "green"); ByteArrayOutputStream outBytes = new ByteArrayOutputStream(); Encoder encoder = EncoderFactory.get().directBinaryEncoder(outBytes, null); new GenericDatumWriter<>(avroSchema).write(user, encoder); encoder.flush(); return ByteBuffer.wrap(outBytes.toByteArray()); } ``` #### Kinesis Client Library のセットアップ Kinesis Client Library コンシューマーを、Java により構築します。詳細については、「*Amazon Kinesis Data Streams デベロッパーガイド*」の「[Developing a Kinesis Client Library Consumer in Java](https://docs.aws.amazon.com/streams/latest/dev/kcl2-standard-consumer-java-example.html)」を参照してください。 1. `GlueSchemaRegistryConfiguration` オブジェクトを渡すことで `GlueSchemaRegistryDeserializer` インスタンスを作成します。 1. `GlueSchemaRegistryDeserializer` を `retrievalConfig.glueSchemaRegistryDeserializer` に渡します。 1. `kinesisClientRecord.getSchema()` を呼び出して、受信メッセージのスキーマにアクセスします。 ``` GlueSchemaRegistryConfiguration schemaRegistryConfig = new GlueSchemaRegistryConfiguration(this.region.toString()); GlueSchemaRegistryDeserializer glueSchemaRegistryDeserializer = new GlueSchemaRegistryDeserializerImpl(DefaultCredentialsProvider.builder().build(), schemaRegistryConfig); RetrievalConfig retrievalConfig = configsBuilder.retrievalConfig().retrievalSpecificConfig(new PollingConfig(streamName, kinesisClient)); retrievalConfig.glueSchemaRegistryDeserializer(glueSchemaRegistryDeserializer); Scheduler scheduler = new Scheduler( configsBuilder.checkpointConfig(), configsBuilder.coordinatorConfig(), configsBuilder.leaseManagementConfig(), configsBuilder.lifecycleConfig(), configsBuilder.metricsConfig(), configsBuilder.processorConfig(), retrievalConfig ); public void processRecords(ProcessRecordsInput processRecordsInput) { MDC.put(SHARD_ID_MDC_KEY, shardId); try { log.info("Processing {} record(s)", processRecordsInput.records().size()); processRecordsInput.records() .forEach( r -> log.info("Processed record pk: {} -- Seq: {} : data {} with schema: {}", r.partitionKey(), r.sequenceNumber(), recordToAvroObj(r).toString(), r.getSchema())); } catch (Throwable t) { log.error("Caught throwable while processing records. Aborting."); Runtime.getRuntime().halt(1); } finally { MDC.remove(SHARD_ID_MDC_KEY); } } private GenericRecord recordToAvroObj(KinesisClientRecord r) { byte[] data = new byte[r.data().remaining()]; r.data().get(data, 0, data.length); org.apache.avro.Schema schema = new org.apache.avro.Schema.Parser().parse(r.schema().getSchemaDefinition()); DatumReader datumReader = new GenericDatumReader<>(schema); BinaryDecoder binaryDecoder = DecoderFactory.get().binaryDecoder(data, 0, data.length, null); return (GenericRecord) datumReader.read(null, binaryDecoder); } ``` #### Kinesis Data Streams API を使用したデータの操作 このセクションでは、Kinesis Data Streams API を使用しての、Kinesis Data Streams と Schema Registry の統合について説明します。 1. Maven の以下の依存関係を更新します。 ``` com.amazonaws aws-java-sdk-bom 1.11.884 pom import com.amazonaws aws-java-sdk-kinesis software.amazon.glue schema-registry-serde 1.1.5 com.fasterxml.jackson.dataformat jackson-dataformat-cbor 2.11.3 ``` 1. `PutRecords` または Kinesis Data Streams の `PutRecord` API を使用しながら、プロデューサ内にスキーマヘッダー情報を追加します。 ``` //The following lines add a Schema Header to the record com.amazonaws.services.schemaregistry.common.Schema awsSchema = new com.amazonaws.services.schemaregistry.common.Schema(schemaDefinition, DataFormat.AVRO.name(), schemaName); GlueSchemaRegistrySerializerImpl glueSchemaRegistrySerializer = new GlueSchemaRegistrySerializerImpl(DefaultCredentialsProvider.builder().build(), new GlueSchemaRegistryConfiguration(getConfigs())); byte[] recordWithSchemaHeader = glueSchemaRegistrySerializer.encode(streamName, awsSchema, recordAsBytes); ``` 1. プロデューサ内で `PutRecords` または `PutRecord` API を使用して、レコードをデータストリームに配置します。 1. コンシューマ内で、ヘッダーからスキーマレコードを削除し、Avro スキーマレコードをシリアル化します。 ``` //The following lines remove Schema Header from record GlueSchemaRegistryDeserializerImpl glueSchemaRegistryDeserializer = new GlueSchemaRegistryDeserializerImpl(DefaultCredentialsProvider.builder().build(), getConfigs()); byte[] recordWithSchemaHeaderBytes = new byte[recordWithSchemaHeader.remaining()]; recordWithSchemaHeader.get(recordWithSchemaHeaderBytes, 0, recordWithSchemaHeaderBytes.length); com.amazonaws.services.schemaregistry.common.Schema awsSchema = glueSchemaRegistryDeserializer.getSchema(recordWithSchemaHeaderBytes); byte[] record = glueSchemaRegistryDeserializer.getData(recordWithSchemaHeaderBytes); //The following lines serialize an AVRO schema record if (DataFormat.AVRO.name().equals(awsSchema.getDataFormat())) { Schema avroSchema = new org.apache.avro.Schema.Parser().parse(awsSchema.getSchemaDefinition()); Object genericRecord = convertBytesToRecord(avroSchema, record); System.out.println(genericRecord); } ``` #### Kinesis Data Streams API を使用したデータの操作 以下に、`PutRecords` および `GetRecords` API を使用するコード例を示します。 ``` //Full sample code import com.amazonaws.services.schemaregistry.deserializers.GlueSchemaRegistryDeserializerImpl; import com.amazonaws.services.schemaregistry.serializers.GlueSchemaRegistrySerializerImpl; import com.amazonaws.services.schemaregistry.utils.AVROUtils; import com.amazonaws.services.schemaregistry.utils.AWSSchemaRegistryConstants; import org.apache.avro.Schema; import org.apache.avro.generic.GenericData; import org.apache.avro.generic.GenericDatumReader; import org.apache.avro.generic.GenericDatumWriter; import org.apache.avro.generic.GenericRecord; import org.apache.avro.io.Decoder; import org.apache.avro.io.DecoderFactory; import org.apache.avro.io.Encoder; import org.apache.avro.io.EncoderFactory; import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider; import software.amazon.awssdk.services.glue.model.DataFormat; import java.io.ByteArrayOutputStream; import java.io.File; import java.io.IOException; import java.nio.ByteBuffer; import java.util.Collections; import java.util.HashMap; import java.util.Map; public class PutAndGetExampleWithEncodedData { static final String regionName = "us-east-2"; static final String streamName = "testStream1"; static final String schemaName = "User-Topic"; static final String AVRO_USER_SCHEMA_FILE = "src/main/resources/user.avsc"; KinesisApi kinesisApi = new KinesisApi(); void runSampleForPutRecord() throws IOException { Object testRecord = getTestRecord(); byte[] recordAsBytes = convertRecordToBytes(testRecord); String schemaDefinition = AVROUtils.getInstance().getSchemaDefinition(testRecord); //The following lines add a Schema Header to a record com.amazonaws.services.schemaregistry.common.Schema awsSchema = new com.amazonaws.services.schemaregistry.common.Schema(schemaDefinition, DataFormat.AVRO.name(), schemaName); GlueSchemaRegistrySerializerImpl glueSchemaRegistrySerializer = new GlueSchemaRegistrySerializerImpl(DefaultCredentialsProvider.builder().build(), new GlueSchemaRegistryConfiguration(regionName)); byte[] recordWithSchemaHeader = glueSchemaRegistrySerializer.encode(streamName, awsSchema, recordAsBytes); //Use PutRecords api to pass a list of records kinesisApi.putRecords(Collections.singletonList(recordWithSchemaHeader), streamName, regionName); //OR //Use PutRecord api to pass single record //kinesisApi.putRecord(recordWithSchemaHeader, streamName, regionName); } byte[] runSampleForGetRecord() throws IOException { ByteBuffer recordWithSchemaHeader = kinesisApi.getRecords(streamName, regionName); //The following lines remove the schema registry header GlueSchemaRegistryDeserializerImpl glueSchemaRegistryDeserializer = new GlueSchemaRegistryDeserializerImpl(DefaultCredentialsProvider.builder().build(), new GlueSchemaRegistryConfiguration(regionName)); byte[] recordWithSchemaHeaderBytes = new byte[recordWithSchemaHeader.remaining()]; recordWithSchemaHeader.get(recordWithSchemaHeaderBytes, 0, recordWithSchemaHeaderBytes.length); com.amazonaws.services.schemaregistry.common.Schema awsSchema = glueSchemaRegistryDeserializer.getSchema(recordWithSchemaHeaderBytes); byte[] record = glueSchemaRegistryDeserializer.getData(recordWithSchemaHeaderBytes); //The following lines serialize an AVRO schema record if (DataFormat.AVRO.name().equals(awsSchema.getDataFormat())) { Schema avroSchema = new org.apache.avro.Schema.Parser().parse(awsSchema.getSchemaDefinition()); Object genericRecord = convertBytesToRecord(avroSchema, record); System.out.println(genericRecord); } return record; } private byte[] convertRecordToBytes(final Object record) throws IOException { ByteArrayOutputStream recordAsBytes = new ByteArrayOutputStream(); Encoder encoder = EncoderFactory.get().directBinaryEncoder(recordAsBytes, null); GenericDatumWriter datumWriter = new GenericDatumWriter<>(AVROUtils.getInstance().getSchema(record)); datumWriter.write(record, encoder); encoder.flush(); return recordAsBytes.toByteArray(); } private GenericRecord convertBytesToRecord(Schema avroSchema, byte[] record) throws IOException { final GenericDatumReader datumReader = new GenericDatumReader<>(avroSchema); Decoder decoder = DecoderFactory.get().binaryDecoder(record, null); GenericRecord genericRecord = datumReader.read(null, decoder); return genericRecord; } private Map getMetadata() { Map metadata = new HashMap<>(); metadata.put("event-source-1", "topic1"); metadata.put("event-source-2", "topic2"); metadata.put("event-source-3", "topic3"); metadata.put("event-source-4", "topic4"); metadata.put("event-source-5", "topic5"); return metadata; } private GlueSchemaRegistryConfiguration getConfigs() { GlueSchemaRegistryConfiguration configs = new GlueSchemaRegistryConfiguration(regionName); configs.setSchemaName(schemaName); configs.setAutoRegistration(true); configs.setMetadata(getMetadata()); return configs; } private Object getTestRecord() throws IOException { GenericRecord genericRecord; Schema.Parser parser = new Schema.Parser(); Schema avroSchema = parser.parse(new File(AVRO_USER_SCHEMA_FILE)); genericRecord = new GenericData.Record(avroSchema); genericRecord.put("name", "testName"); genericRecord.put("favorite_number", 99); genericRecord.put("favorite_color", "red"); return genericRecord; } } ``` ## Amazon Managed Service for Apache Flink のユースケース Apache Flinkは、無制限および制限付きのデータストリームに対するステートフルな計算に広く使用されている、オープンソースフレームワークの分散処理エンジンです。Amazon Managed Service for Apache Flink は、ストリーミングデータを処理するため、Apache Flink アプリケーションを構築して管理できるようにする完全マネージド型の AWS サービスです。 オープンソースの Apache Flink では、多数のソースとシンクを利用できます。例えば、事前定義済みのデータソースには、ファイル、ディレクトリ、およびソケットからの読み込みや、コレクションとイテレータからのデータの取り込みなどが含まれています。Apache Flink DataStream Connector は、Apache Flinkが、Apache Kafka や Kinesis などの各種サードパーティー製システムと、ソースおよび/またはシンクとしてインターフェースするためのコードを提供します。 詳細については、「[Amazon Kinesis Data Analytics デベロッパーガイド](https://docs.aws.amazon.com/kinesisanalytics/latest/java/what-is.html)」を参照してください。 ### Apache Flink Kafka Connector Apache Flinkは、Kafka のトピックに対するデータの読み取りおよび書き込みを、正確に一度で行えるようにするための、Apache Kafka データストリームのコネクタを提供します。Flink の Kafka コンシューマ `FlinkKafkaConsumer` では、1 つ以上の Kafka トピックから読み取りを行うアクセスが提供されます。Apache Flink の Kafka プロデューサ `FlinkKafkaProducer` では、1 つ以上の Kafka トピックに対しレコードのストリームを書き込むことができます。詳細については、「[Apache Kafka Connector](https://ci.apache.org/projects/flink/flink-docs-stable/dev/connectors/kafka.html)」を参照してください。 ### Apache Flink Kinesis Streams Connector Kinesis データストリームのコネクタは、Amazon Kinesis Data Streams へのアクセスを提供します。並列ストリーミングデータソース `FlinkKinesisConsumer` は、同じAWS のサービスリージョン内で複数の Kinesis ストリームにサブスクライブされ、ジョブの実行中にストリームの再シャーディングを透過的に (確実に 1 回で) 処理できます。コンシューマーの各サブタスクが、複数の Kinesis シャードからのデータレコードの取得を受け持ちます。各サブタスクによって取得されるシャードの数は、Kinesis によってシャードが閉じられ、また作成されるたびに変化します。`FlinkKinesisProducer` は Kinesis Producer Library (KPL) を使用して、Kinesis ストリーム内に Apache Flink ストリームからのデータを配置します。詳細については、「[Amazon Kinesis Streams Connector](https://ci.apache.org/projects/flink/flink-docs-release-1.11/dev/connectors/kinesis.html)」を参照してください。 詳細については、[AWS Glue のGitHub リポジトリ](https://github.com/awslabs/aws-glue-schema-registry)を参照してください。 ### Apache Flink との統合 Schema Registry で提供されている SerDes ライブラリは、Apache Flink と統合されています。Apache Flink を使用するには、[https://github.com/apache/flink/blob/master/flink-streaming-java/src/main/java/org/apache/flink/streaming/util/serialization/SerializationSchema.java](https://github.com/apache/flink/blob/master/flink-streaming-java/src/main/java/org/apache/flink/streaming/util/serialization/SerializationSchema.java) および [https://github.com/apache/flink/blob/8674b69964eae50cad024f2c5caf92a71bf21a09/flink-core/src/main/java/org/apache/flink/api/common/serialization/DeserializationSchema.java](https://github.com/apache/flink/blob/8674b69964eae50cad024f2c5caf92a71bf21a09/flink-core/src/main/java/org/apache/flink/api/common/serialization/DeserializationSchema.java) のインターフェイス (`GlueSchemaRegistryAvroSerializationSchema` および `GlueSchemaRegistryAvroDeserializationSchema`) を実装する必要があります。これらは、Apache Flink コネクタにプラグインして使用します。 ### Apache Flink アプリケーションへの AWS Glue Schema Registry の依存関係の追加 Apache Flink アプリケーション内で AWS Glue Schema Registry との統合の依存関係をセットアップするには 1. `pom.xml` ファイルに依存関係を追加します。 ``` software.amazon.glue schema-registry-flink-serde 1.0.0 ``` #### Kafka または Amazon MSK を Apache Flink と統合する Kafka をソースまたはシンクとしながら、Apache Flink 対応の Managed Service for Apache Flink を使用できます。 **Kafka をソースとする場合** 次の図は、Kafka をソースとしながら、Kinesis Data Streams と Apache Flink 対応の Managed Service for Apache Flink を統合した様子です。 ![\[Kafka をソースとする場合。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/gsr-kafka-source.png) **Kafka をシンクとする場合** 次の図は、Kafka をシンクとしながら、Kinesis Data Streams と Apache Flink 対応の Managed Service for Apache Flink を統合した様子です。 ![\[Kafka をシンクとする場合。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/gsr-kafka-sink.png) Kafka をソースまたはシンクとしながら、Kafka (または Amazon MSK) を Apache Flink 対応の Managed Service for Apache Flink と統合するには、以下のコード変更を行います。太字で示されたコードブロックを、類似するセクション内の対応するコードにそれぞれ追加します。 Kafka をソースとする場合は、デシリアライザ用コード (ブロック 2) を使用します。Kafka をシンクとする場合は、シリアライザコード (ブロック 3) を使用します。 ``` StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); String topic = "topic"; Properties properties = new Properties(); properties.setProperty("bootstrap.servers", "localhost:9092"); properties.setProperty("group.id", "test"); // block 1 Map configs = new HashMap<>(); configs.put(AWSSchemaRegistryConstants.AWS_REGION, "aws-region"); configs.put(AWSSchemaRegistryConstants.SCHEMA_AUTO_REGISTRATION_SETTING, true); configs.put(AWSSchemaRegistryConstants.AVRO_RECORD_TYPE, AvroRecordType.GENERIC_RECORD.getName()); FlinkKafkaConsumer consumer = new FlinkKafkaConsumer<>( topic, // block 2 GlueSchemaRegistryAvroDeserializationSchema.forGeneric(schema, configs), properties); FlinkKafkaProducer producer = new FlinkKafkaProducer<>( topic, // block 3 GlueSchemaRegistryAvroSerializationSchema.forGeneric(schema, topic, configs), properties); DataStream stream = env.addSource(consumer); stream.addSink(producer); env.execute(); ``` #### Kinesis Data Streams と Apache Flink との統合 Kinesis Data Streams をソースまたはシンクとしながら、Apache Flink 対応の Managed Service for Apache Flink を使用できます。 **Kinesis Data Streams をソースとする場合** 次の図は、Kinesis Data Streams をソースとしながら、Kinesis Data Streams と Apache Flink 対応の Managed Service for Apache Flink を統合した様子です。 ![\[Kinesis Data Streams をソースとする場合。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/gsr-kinesis-source.png) **Kinesis Data Streams をシンクとする場合** 次の図は、Kinesis Data Streams をシンクとしながら、Kinesis Data Streams と Apache Flink 対応の Managed Service for Apache Flink を統合した様子です。 ![\[Kinesis Data Streams をシンクとする場合。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/gsr-kinesis-sink.png) Kinesis Data Streams をソースまたはシンクとしながら、Kinesis Data Streams と Apache Flink 対応の Managed Service for Apache Flink を統合するには、以下のコード変更を行います。太字で示されたコードブロックを、類似するセクション内の対応するコードにそれぞれ追加します。 Kinesis Data Streams をソースとする場合は、デシリアライザコード (ブロック 2) を使用します。Kinesis Data Streams をシンクとする場合は、シリアライザコード (ブロック 3) を使用します。 ``` StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); String streamName = "stream"; Properties consumerConfig = new Properties(); consumerConfig.put(AWSConfigConstants.AWS_REGION, "aws-region"); consumerConfig.put(AWSConfigConstants.AWS_ACCESS_KEY_ID, "aws_access_key_id"); consumerConfig.put(AWSConfigConstants.AWS_SECRET_ACCESS_KEY, "aws_secret_access_key"); consumerConfig.put(ConsumerConfigConstants.STREAM_INITIAL_POSITION, "LATEST"); // block 1 Map configs = new HashMap<>(); configs.put(AWSSchemaRegistryConstants.AWS_REGION, "aws-region"); configs.put(AWSSchemaRegistryConstants.SCHEMA_AUTO_REGISTRATION_SETTING, true); configs.put(AWSSchemaRegistryConstants.AVRO_RECORD_TYPE, AvroRecordType.GENERIC_RECORD.getName()); FlinkKinesisConsumer consumer = new FlinkKinesisConsumer<>( streamName, // block 2 GlueSchemaRegistryAvroDeserializationSchema.forGeneric(schema, configs), properties); FlinkKinesisProducer producer = new FlinkKinesisProducer<>( // block 3 GlueSchemaRegistryAvroSerializationSchema.forGeneric(schema, topic, configs), properties); producer.setDefaultStream(streamName); producer.setDefaultPartition("0"); DataStream stream = env.addSource(consumer); stream.addSink(producer); env.execute(); ``` ## ユースケース: AWS Lambda との統合 AWS Lambda 関数を Apache Kafka/Amazon MSK のコンシューマーとして使用し、Avro でエンコードされたメッセージを AWS Glue Schema Registry により非シリアル化するには、[MSK ラボのページ](https://amazonmsk-labs.workshop.aws/en/msklambda/gsrschemareg.html)をご覧ください。 ## ユースケース: AWS Glue Data Catalog AWS Glue テーブルは、手動による指定、または AWS Glue Schema Registry への参照によって指定できる、スキーマをサポートしています。AWS Glue テーブルまたは Data Catalog のパーティションを作成または更新する際に、オプションで Schema Registry に格納されているスキーマを使用できるように、Schema Registry には Data Catalog が統合されています。Schema Registry のスキーマ定義を特定するには、少なくとも、対象となるスキーマの ARN を知る必要があります。スキーマ定義を含むスキーマのスキーマバージョンは、UUID またはバージョン番号により参照が可能です。スキーマバージョンの中でも「最新」バージョンについては、バージョン番号または UUID を把握しなくても常に参照することができます。 `CreateTable` または `UpdateTable` オペレーションの呼び出し時は、Schema Registry 内の既存のスキーマに対する `TableInput` を指定するために `SchemaReference` 構造体 (`StorageDescriptor` を含む) を渡します。同様に、`GetTable` または `GetPartition` API を呼び出す場合は、そのレスポンスにスキーマと `SchemaReference` が含まれます。スキーマ参照を使用してテーブルまたはパーティションが作成されると、Data Catalog はこのスキーマ参照のスキーマ取得を試みます。Schema Registry 内にスキーマが見つからない場合は、`GetTable` レスポンスで空のスキーマを返します。それ以外では、このレスポンスにスキーマとスキーマ参照の両方が出力されます。 また、AWS Glue コンソールからアクションを実行することも可能です。 これらのオペレーションを実行し、スキーマ情報を作成、更新、表示するには、呼び出しユーザーに、`GetSchemaVersion` API へのアクセス権限を付与する、IAM ロールを付与する必要があります。 ### テーブルの追加またはテーブルのスキーマの更新 既存のスキーマから新しいテーブルを追加すると、そのテーブルは特定のスキーマバージョンにバインドされます。新しいスキーマバージョンの登録が完了すると、このテーブル定義が、AWS Glue コンソールの [View table] (テーブルの表示) ページ、もしくは [UpdateTable アクション (Python: update\$1table)](aws-glue-api-catalog-tables.md#aws-glue-api-catalog-tables-UpdateTable) API を使用して更新できるようになります。 #### 既存のスキーマからのテーブルの追加 AWS Glue コンソールまたは `CreateTable` API を使用して、レジストリ内のスキーマバージョンから AWS Glue を作成できます。 **AWS Glue API** `CreateTable` API を呼び出す際に、(`StorageDescriptor` に`SchemaReference` が指定されている) `TableInput` を、スキーマレジストリの既存のスキーマに追加します。 **AWS Glue コンソール** AWS Glue コンソールを使用してテーブルを作成するには 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインの [**Data catalog**] (データカタログ) で、[**Tables**] (テーブル) をクリックします。 1. [**Add Tables**] (テーブルの追加) メニューで、[**Add table from existing schema**] (既存のスキーマからテーブルを追加する) をクリックします。 1. テーブルのプロパティとデータストアを、AWS Glue デベロッパーガイドに沿って設定します。 1. [**Choose a Glue schema**] (Glue スキーマの選択) ページで、スキーマが置かれている [**Registry**] (レジストリ) を選択します。 1. [**Schema name**] (スキーマ名) をクリックし、適用するスキーマの [**Version**] (バージョン) を選択します。 1. スキーマのプレビューを確認し、[**Next**] (次へ) をクリックします。 1. テーブルを確認し、作成します。 作成したテーブルに適用されたスキーマとバージョンは、テーブルの一覧内で [**Glue schema**] (Glue スキーマ) 列に表示されます。テーブルを表示すると、さらに詳細を確認できます。 #### テーブルのスキーマの更新 新しいスキーマバージョンが使用可能になったら、テーブルのスキーマを [UpdateTable アクション (Python: update\$1table)](aws-glue-api-catalog-tables.md#aws-glue-api-catalog-tables-UpdateTable) API または AWS Glue コンソールにより更新することができます **重要** 手動で指定された AWS Glue スキーマを含む既存のテーブル用にスキーマを更新する場合、Schema Registry で参照される新しいスキーマは互換性を持たない可能性があります。この場合、ジョブが失敗することがあります。 **AWS Glue API** `UpdateTable` API を呼び出す際に、(`StorageDescriptor` に`SchemaReference` が指定されている) `TableInput` を、スキーマレジストリの既存のスキーマに追加します。 **AWS Glue コンソール** AWS Glue コンソールからテーブルのスキーマを更新するには 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue\)) を開きます。 1. ナビゲーションペインの [**Data catalog**] (データカタログ) で、[**Tables**] (テーブル) をクリックします。 1. テーブルの一覧でテーブルを表示します。 1. 新しいバージョンの情報が表示されたボックスで、[**Update schema**] (スキーマの更新) をクリックします。 1. 現在のスキーマと更新後のスキーマの違いを確認します。 1. さらに詳細を表示するには、[**Show all schema differences**] (スキーマの違いをすべて表示) をクリックします。 1. [**Save table**] (テーブルを保存) をクリックし、新しいバージョンを受け入れます。 ## ユースケース: AWS Glue ストリーミング AWS Glue ストリーミングは、ストリーミングソースからのデータを消費し、出力シンクに書き込む前に ETL オペレーションを実行します。入力ストリーミングソースは、データテーブルを使用して指定するか、ソース構成を指定して直接指定することができます。 AWS Glue ストリーミングは、AWS Glue スキーマレジストリに存在するスキーマで作成されたストリーミングソースのデータカタログテーブルをサポートします。AWS Glue スキーマレジストリにスキーマを作成し、そのスキーマを使用してストリーミングソースで AWS Glue テーブルを作成できます。この AWS Glue テーブルは、 AWS Glue ストリーミングジョブへの入力として使用し、入力ストリーミングのデータを逆シリアル化することができます。 注意すべき点は、AWS Glue スキーマレジスト内のスキーマが変化した場合、AWS Glue ストリーミングジョブを再度開始して、スキーマの変更を反映させる必要があることです。 ## ユースケース: Apache Kafka ストリーム Apache Kafka Streams APIは、Apache Kafka に格納されているデータを処理・分析するためのクライアントライブラリです。このセクションでは、Apache Kafka Streams と AWS Glue Schema Registry の統合について説明します。これにより、データストリーミングアプリケーションのスキーマを、管理および適用できるようになります。Apache Kafka Streams の詳細については、「[Apache Kafka Streams](https://kafka.apache.org/documentation/streams/)」を参照してください。 ### SerDes ライブラリとの統合 `GlueSchemaRegistryKafkaStreamsSerde` クラスにより、Streams のアプリケーションを設定できます。 #### Kafka Streams アプリケーションのコード例 Apache Kafka Streams アプリケーション内で AWS Glue Schema Registry を使用するには 1. Kafka Streams アプリケーションを設定します。 ``` final Properties props = new Properties(); props.put(StreamsConfig.APPLICATION_ID_CONFIG, "avro-streams"); props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092"); props.put(StreamsConfig.CACHE_MAX_BYTES_BUFFERING_CONFIG, 0); props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG, Serdes.String().getClass().getName()); props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG, AWSKafkaAvroSerDe.class.getName()); props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest"); props.put(AWSSchemaRegistryConstants.AWS_REGION, "aws-region"); props.put(AWSSchemaRegistryConstants.SCHEMA_AUTO_REGISTRATION_SETTING, true); props.put(AWSSchemaRegistryConstants.AVRO_RECORD_TYPE, AvroRecordType.GENERIC_RECORD.getName()); props.put(AWSSchemaRegistryConstants.DATA_FORMAT, DataFormat.AVRO.name()); ``` 1. トピック avro-input からストリームを作成します。 ``` StreamsBuilder builder = new StreamsBuilder(); final KStream source = builder.stream("avro-input"); ``` 1. データレコードを処理します (favorite\$1color の値がピンクであるか、値が 15 となっているレコードの除外など)。 ``` final KStream result = source .filter((key, value) -> !"pink".equals(String.valueOf(value.get("favorite_color")))); .filter((key, value) -> !"15.0".equals(String.valueOf(value.get("amount")))); ``` 1. トピック avro-output に結果を書き込みます。 ``` result.to("avro-output"); ``` 1. Apache Kafka Streams アプリケーションを起動します。 ``` KafkaStreams streams = new KafkaStreams(builder.build(), props); streams.start(); ``` #### 実装結果 以下の結果は、ステップ 3 において (favorite\$1color が「pink」であるか値が「15.0」であるために) 除外されたレコードに関するフィルタリング処理を示しています。 フィルタリング前のレコード: ``` {"name": "Sansa", "favorite_number": 99, "favorite_color": "white"} {"name": "Harry", "favorite_number": 10, "favorite_color": "black"} {"name": "Hermione", "favorite_number": 1, "favorite_color": "red"} {"name": "Ron", "favorite_number": 0, "favorite_color": "pink"} {"name": "Jay", "favorite_number": 0, "favorite_color": "pink"} {"id": "commute_1","amount": 3.5} {"id": "grocery_1","amount": 25.5} {"id": "entertainment_1","amount": 19.2} {"id": "entertainment_2","amount": 105} {"id": "commute_1","amount": 15} ``` フィルタリング後のレコード: ``` {"name": "Sansa", "favorite_number": 99, "favorite_color": "white"} {"name": "Harry", "favorite_number": 10, "favorite_color": "black"} {"name": "Hermione", "favorite_number": 1, "favorite_color": "red"} {"name": "Ron", "favorite_number": 0, "favorite_color": "pink"} {"id": "commute_1","amount": 3.5} {"id": "grocery_1","amount": 25.5} {"id": "entertainment_1","amount": 19.2} {"id": "entertainment_2","amount": 105} ``` ### ユースケース: Apache Kafka Connect Apache Kafka Connect と AWS Glue Schema Registry を統合することで、コネクタからスキーマ情報を取得できるようになります。Apache Kafka のコンバータにより、Apache Kafka 内のデータ形式と、Apache Kafka Connect データへの変換方法を指定します。すべての Apache Kafka Connect ユーザーは、これらのコンバータを Apache Kafka との間でロードまたは保存する際に、データに適用する形式に基づいた設定を行う必要があります。これにより、Apache Kafka Connect データを AWS Glue Schema Registry で使用する型 (例: Avro) に変換する独自のコンバータを定義し、さらにシリアライザを使用してスキーマを登録しシリアル化を実行します。その後コンバータはデシリアライザを使用して、Apache Kafka から受信したデータを逆シリアル化し、元の Apache Kafka Connect データに変換することができます。ワークフローの例を以下の図に示します。 ![\[Apache Kafka Connect ワークフロー。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/schema_reg_int_kafka_connect.png) 1. [AWS Glue Schema Registry 用 Githubリポジトリ](https://github.com/awslabs/aws-glue-schema-registry)をクローンして、`aws-glue-schema-registry` プロジェクトをインストールします。 ``` git clone git@github.com:awslabs/aws-glue-schema-registry.git cd aws-glue-schema-registry mvn clean install mvn dependency:copy-dependencies ``` 1. Apache Kafka Connect を *Standalone* モードで使用する予定の場合、このステップで以下に示した手順を使用して、**connect-standalone.properties** を更新します。Apache Kafka Connect を *Distributed* モードで使用する予定の場合は、同じ手順により **connect-avro-distributed.properties** を更新します。 1. Apache Kafka の接続プロパティファイルにも、これらのプロパティを追加します。 ``` key.converter.region=aws-region value.converter.region=aws-region key.converter.schemaAutoRegistrationEnabled=true value.converter.schemaAutoRegistrationEnabled=true key.converter.avroRecordType=GENERIC_RECORD value.converter.avroRecordType=GENERIC_RECORD ``` 1. 以下のコマンドを、[**kafka-run-class.sh**] の下の [**Launch mode**] (起動モード) セクションに追加します。 ``` -cp $CLASSPATH:"/target/dependency/*" ``` 1. [**kafka-run-class.sh**] の下の [**Launch mode**] (起動モード) セクションに以下のコマンドを追加する ``` -cp $CLASSPATH:"/target/dependency/*" ``` プリンシパルは以下のようになります。 ``` # Launch mode if [ "x$DAEMON_MODE" = "xtrue" ]; then nohup "$JAVA" $KAFKA_HEAP_OPTS $KAFKA_JVM_PERFORMANCE_OPTS $KAFKA_GC_LOG_OPTS $KAFKA_JMX_OPTS $KAFKA_LOG4J_OPTS -cp $CLASSPATH:"/Users/johndoe/aws-glue-schema-registry/target/dependency/*" $KAFKA_OPTS "$@" > "$CONSOLE_OUTPUT_FILE" 2>&1 < /dev/null & else exec "$JAVA" $KAFKA_HEAP_OPTS $KAFKA_JVM_PERFORMANCE_OPTS $KAFKA_GC_LOG_OPTS $KAFKA_JMX_OPTS $KAFKA_LOG4J_OPTS -cp $CLASSPATH:"/Users/johndoe/aws-glue-schema-registry/target/dependency/*" $KAFKA_OPTS "$@" fi ``` 1. bash を使用している場合は、以下のコマンドを実行して、bash\$1profile で CLASSPATH を設定します。他のシェルの場合は、それに応じて環境を更新します。 ``` echo 'export GSR_LIB_BASE_DIR=<>' >>~/.bash_profile echo 'export GSR_LIB_VERSION=1.0.0' >>~/.bash_profile echo 'export KAFKA_HOME=' >>~/.bash_profile echo 'export CLASSPATH=$CLASSPATH:$GSR_LIB_BASE_DIR/avro-kafkaconnect-converter/target/schema-registry-kafkaconnect-converter-$GSR_LIB_VERSION.jar:$GSR_LIB_BASE_DIR/common/target/schema-registry-common-$GSR_LIB_VERSION.jar:$GSR_LIB_BASE_DIR/avro-serializer-deserializer/target/schema-registry-serde-$GSR_LIB_VERSION.jar' >>~/.bash_profile source ~/.bash_profile ``` 1. (オプション) 単純なファイルをソースとして使用しテストを行う場合は、ファイルソースコネクタのクローンを作成します。 ``` git clone https://github.com/mmolimar/kafka-connect-fs.git cd kafka-connect-fs/ ``` 1. ソースコネクタの設定で、データ形式を Avro に、ファイルリーダーを `AvroFileReader` に変更します。さらに、読み込んでいるファイルパスからサンプルの Avro オブジェクトを更新します。例: ``` vim config/kafka-connect-fs.properties ``` ``` fs.uris= policy.regexp=^.*\.avro$ file_reader.class=com.github.mmolimar.kafka.connect.fs.file.reader.AvroFileReader ``` 1. ソースコネクタをインストールします。 ``` mvn clean package echo "export CLASSPATH=\$CLASSPATH:\"\$(find target/ -type f -name '*.jar'| grep '\-package' | tr '\n' ':')\"" >>~/.bash_profile source ~/.bash_profile ``` 1. `/config/connect-file-sink.properties` のシンクのプロパティを更新し、トピック名と出力ファイル名を更新します。 ``` file= topics= ``` 1. Source Connector (この例では、ソースファイルのコネクタ) を起動します。 ``` $KAFKA_HOME/bin/connect-standalone.sh $KAFKA_HOME/config/connect-standalone.properties config/kafka-connect-fs.properties ``` 1. Sink Connector (この例では、シンクファイルのコネクタ) を実行します。 ``` $KAFKA_HOME/bin/connect-standalone.sh $KAFKA_HOME/config/connect-standalone.properties $KAFKA_HOME/config/connect-file-sink.properties ``` Kafka Connect の使用例については、[AWS Glue Schema Registry 用 Githubリポジトリ](https://github.com/awslabs/aws-glue-schema-registry/tree/master/integration-tests)の、integration-tests フォルダにある run-local-tests.sh スクリプトでご確認ください。 # サードパーティー製のスキーマレジストリから AWS Glue Schema Registry への移行 サードパーティー製スキーマレジストリから AWS Glue Schema Registry への移行作業は、その時点での既存のサードパーティー製スキーマレジストリにより異なります。サードパーティーのスキーマレジストリを使用して送信された Apache Kafka トピック内にレコードがある場合、コンシューマはサードパーティーのスキーマレジストリを使用して、それらのレコードを非シリアル化する必要があります。`AWSKafkaAvroDeserializer` には、セカンダリのデシリアライザクラスを定義する機能があります。このクラスは、サードパーティーのデシリアライザを特定し、対象のレコードを非シリアル化するために使用できます、 サードパーティー製スキーマには、使用停止に関して 2 つの基準があります。1 つ目の基準では、サードパーティー製スキーマレジストリを使用する Apache Kafka トピックのレコードを必要とするコンシューマが、なくなった後にのみ使用停止となります。2 つ目の基準では、トピックに指定された保持期間に応じ、Apache Kafka トピックの試用期間が終了することで使用停止となります。無制限の保持期間を持つトピックの場合は、AWS Glue Schema Registry への移行は可能ですが、サードパーティー製スキーマレジストリを使用停止にすることはできません。この回避策としては、アプリケーションまたは Mirror Maker 2 により現在のトピックを読み取り、AWS Glue Schema Registry を使用する新しいトピックとして作成し直すことができます。 サードパーティー製スキーマレジストリから AWS Glue Schema Registry へ移行するには 1. AWS Glue Schema Registry にレジストリを作成するか、デフォルトのレジストリを使用します。 1. コンシューマを停止します。AWS Glue Schema Registry をプライマリのデシリアライザとして含めるように、コンシューマを変更します、サードパーティーのスキーマレジストリをセカンダリに変更します。 + コンシューマのプロパティを設定します。この例では、secondary\$1decerializer は別のデシリアライザに設定されています。動作は次のとおりです。コンシューマは Amazon MSK からレコードを取得し、最初に `AWSKafkaAvroDeserializer` の使用を試みます。AWS Glue Schema Registry のスキーマの、Avro スキーマ ID を含むマジックバイトを読み取ることができない場合、`AWSKafkaAvroDeserializer`は、secondary\$1deserializer で指定されるデシリアライザクラスの使用を試みます。セカンダリのデシリアライザに固有のプロパティは、以下に示すように、schema\$1registry\$1url\$1config や specific\$1avro\$1reader\$1config などのコンシューマプロパティでも指定する必要があります。 ``` consumerProps.setProperty(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName()); consumerProps.setProperty(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, AWSKafkaAvroDeserializer.class.getName()); consumerProps.setProperty(AWSSchemaRegistryConstants.AWS_REGION, KafkaClickstreamConsumer.gsrRegion); consumerProps.setProperty(AWSSchemaRegistryConstants.SECONDARY_DESERIALIZER, KafkaAvroDeserializer.class.getName()); consumerProps.setProperty(KafkaAvroDeserializerConfig.SCHEMA_REGISTRY_URL_CONFIG, "URL for third-party schema registry"); consumerProps.setProperty(KafkaAvroDeserializerConfig.SPECIFIC_AVRO_READER_CONFIG, "true"); ``` 1. コンシューマを再起動します。 1. プロデューサを停止し、そのプロデューサで AWS Glue Schema Registry を指定します。 1. プロデューサのプロパティを設定します。この例のプロデューサでは、デフォルトのレジストリと自動登録スキーマバージョンを使用しています。 ``` producerProps.setProperty(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName()); producerProps.setProperty(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, AWSKafkaAvroSerializer.class.getName()); producerProps.setProperty(AWSSchemaRegistryConstants.AWS_REGION, "us-east-2"); producerProps.setProperty(AWSSchemaRegistryConstants.AVRO_RECORD_TYPE, AvroRecordType.SPECIFIC_RECORD.getName()); producerProps.setProperty(AWSSchemaRegistryConstants.SCHEMA_AUTO_REGISTRATION_SETTING, "true"); ``` 1. (オプション) 既存のスキーマおよびスキーマバージョンを、現在のサードパーティー製スキーマレジストリから AWS Glue Schema Registry (AWS Glue Schema Registry のデフォルトレジストリ、または AWS Glue Schema Registry 内の特定の非デフォルトレジストリ) に手動で移行します。これには、サードパーティーのスキーマレジストリから JSON 形式でスキーマをエクスポートし、AWS マネジメントコンソール または AWS CLI を使用しながら AWS Glue Schema Registry の新しいスキーマを作成します。 このステップは、AWS CLI および AWS マネジメントコンソール を使用して、新しく作成されたスキーマバージョンについて、以前のスキーマバージョンとの互換性チェックを有効にする必要がある場合、またはスキーマバージョンの自動登録を有効にした新しいスキーマで、プロデユーサがメッセージを送信する場合に重要です。 1. プロデューサを起動します。