翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Lake Formation の既知の問題

AWS Lake Formation のこれらの既知の問題を確認します。

テーブルメタデータのフィルタリングの制限

AWS Lake Formation の列レベルの許可は、テーブル内の特定の列へのアクセスを制限するために使用できます。ユーザーがコンソールや glue:GetTable のような API を使用してテーブルに関するメタデータを取得する場合、テーブルオブジェクトの列リストには、ユーザーがアクセスできるフィールドのみが含まれます。このメタデータフィルタリングの制限を理解しておくことが重要です。

Lake Formation は、統合サービスが列の許可に関するメタデータを利用できるようにしますが、クエリ応答内の列の実際のフィルタリングは統合サービスの責任になります。Amazon Athena、Amazon Redshift Spectrum、および Amazon EMR などの列レベルのフィルタリングをサポートする Lake Formation クライアントは、Lake Formation に登録された列の許可に基づいてデータをフィルタリングします。ユーザーが、アクセス権を持つべきではないデータを読み取ることはできません。現在、AWS Glue ETL は列フィルタリングをサポートしていません。

特定のアプリケーションまたはフォーマットでは、列の名前やタイプなどの追加のメタデータが、テーブルのプロパティとして Parameters マップに保存される場合があります。これらのプロパティは変更されずに返され、いずれかの列に対して SELECT 許可を持っていれば、どのユーザーでもアクセスすることができます。

例えば、Avro SerDe は avro.schema.literal というテーブルプロパティにテーブルスキーマの JSON 表現を保存し、このテーブルにアクセスできるすべてのユーザーが利用できます。機密情報をテーブルプロパティに保存することは避け、ユーザーが Avro 形式のテーブルの完全なスキーマを把握できることに留意することが推奨されます。この制限は、テーブルに関するメタデータに固有のものです。

呼び出し元がテーブル内のすべての列に対する SELECT 許可を持っていない場合、AWS Lake Formation は、glue:GetTable、またはこれに似たリクエストに応答するときに、spark.sql.sources.schema で始まるすべてのテーブルプロパティを削除します。これは、ユーザーが Apache Spark で作成されたテーブルに関する追加のメタデータにアクセスできないようにします。Apache Spark アプリケーションは、Amazon EMR で実行しても引き続きこれらのテーブルを読み取ることができますが、特定の最適化が適用されない場合があり、大文字と小文字を区別する列名はサポートされません。ユーザーがテーブル内のすべての列にアクセスできる場合、Lake Formation は、変更されていないテーブルをすべてのテーブルプロパティと共に返します。

除外された列の名前変更に関する問題

列レベルの許可を使用して列を除外してから列の名前を変更すると、その列は SELECT * などのクエリから除外されなくなります。

CSV テーブルの列の削除に関する問題

CSV 形式で Data Catalog のテーブルを作成した後でスキーマから列を削除すると、クエリが誤ったデータを返し、列レベルの許可が守られない場合があります。

回避方法: その代わりに新しいテーブルを作成します。

テーブルパーティションを共通パスの下に追加する必要性

Lake Formation は、テーブルのすべてのパーティションが、テーブルの [location] (ロケーション) フィールドに設定されている共通のパスの下にあることを期待します。これは、クローラを使用してカタログにパーティションを追加する場合は問題なく機能しますが、パーティションを手動で追加し、これらのパーティションが親テーブルに設定されたロケーションの下にない場合はデータアクセスが機能しません。

ワークフロー作成時におけるデータベースの作成に関する問題

Lake Formation コンソールを使用してブループリントからワークフローを作成するときは、ターゲットデータベースが存在しなければ、それを作成することができます。これを実行するとき、作成されるデータベースに対する CREATE_TABLE 許可を取得するのは、サインインしているユーザーです。しかし、ワークフローが生成するクローラは、テーブルの作成試行時にワークフローのロールを引き受けます。このロールにはデータベースに対する CREATE_TABLE 許可がないことから、テーブルの作成は失敗します。

回避方法: ワークフローのセットアップ中にコンソールからデータベースを作成する場合は、ワークフローを実行する前に、作成したばかりのデータベースに対する CREATE_TABLE 許可をワークフローに関連付けられているロールに付与する必要があります。

ユーザーの削除後での再作成に関する問題

以下のシナリオは、lakeformation:ListPermissions によって返される誤った Lake Formation 許可の原因になります。

ListPermissions は、古いユーザー向けのエントリと、新しいユーザー向けのエントリの 2 つのエントリを返します。古いユーザーに付与された許可を取り消そうとすると、それらの許可は新しいユーザーからも取り消されます。

Data Catalog API 操作が IsRegisteredWithLakeFormation パラメータの値を更新しない

GetTables および SearchTables などの Data Catalog API 操作が IsRegisteredWithLakeFormation パラメータの値を更新せず、デフォルト値の false を返すという既知の制限があります。IsRegisteredWithLakeFormation パラメータの正しい値を表示するには、GetTable API を使用することが推奨されます。

Lake Formation 操作が AWS Glue スキーマレジストリをサポートしない

Lake Formation 操作は、StorageDescriptor に SchemaReference が含まれる AWS Glue テーブルのスキーマレジストリでの利用をサポートしません。