- キー接頭辞に一致するすべてのファイルは、必ず同じ種類のデータ形式(csv、json、またはParquet)になります。
- 異なる形式の関連データは、異なるキー接頭辞の場所に置く必要があります(例:
- Amazon S3: /S3/YOUR-BUCKET.URI/csv-table1および/S3/YOUR-BUCKET.URI/json-table-1
- Azure BlobストレージおよびAzure Data Lake Storage Gen2: /AZ/YOUR-STORAGE-ACCOUNT.URI/csv-table1および/az/YOUR-STORAGE-ACCOUNT.URI/json-table-1
- Google Cloud Storage: /gs/URI/YOUR-BUCKET/csv-table1および/gs/URI/YOUR-BUCKET/json-table-1
- 異なる論理テーブルの一部であるファイルは、異なるキー接頭辞の場所にある必要があります。例:
- Amazon S3: /S3/YOUR-BUCKET.URI/emp-tableおよび/S3/YOUR-BUCKET.URI/dept-table
- Azure BlobストレージおよびAzure Data Lake Storage Gen2: /AZ/YOUR-STORAGE-ACCOUNT.URI/emp-tableおよび/az/YOUR-STORAGE-ACCOUNT.URI/dept-table
- Google Cloud Storage: /gs/URI/YOUR-BUCKET/emp-tableおよび/gs/URI/YOUR-BUCKET/dept-table
- データ ファイルはバケットに追加されるので、特定形式のファイルが変更される場合があります。例えば、同じバケットに追加された新しいCSVデータにフィールドが追加される場合や、フィールドの順序が変わる場合があります。このような場合、ベストプラクティスは、外部テーブルのCSVスキーマを定義してすべてのCSVファイルを同じフィールド パターンの使用に制限するよりも、各CSVファイルにヘッダー行を含めてフィールド(列タイトル)を識別するようにすることです。
- CSVファイルに異なるデータ フィールドがありながら個々のファイル ヘッダーがない場合は、同じフィールドを持つファイルを別のキー接頭辞の場所にグループ化する必要があります。
- 外部テーブル内のCSVデータに対してスキーマを定義する場合は、その場所にあるすべてのファイルが同じフィールドを持つようにします。バケット内のファイルに異なるフィールドがある場合は、外部データにアクセスする前に、バケット内のファイルを別のキー接頭辞の場所に整理します。
- 1つのキー接頭辞の場所に異なる種類のデータが含まれる場合は、そのデータにクエリーを実行するのは非効率的です。例えば、部門と従業員のデータを1つのキー接頭辞の場所に混在させる場合、特定の従業員を探すクエリーでは、Vantageがその場所にあるすべてのファイル(部門データのみを含んだファイルを含む)を読み取る必要があります。
ベスト プラクティスは、同じ種類のデータを含むファイルを1つの外部ストレージのキー接頭辞の場所にグループ化し、そのキー接頭辞の場所を使用して単一の外部テーブルを作成するか、単一のREAD_NOSクエリー内に作成することを推奨します。これは、あらゆる種類の外部データ、JSON、CSV、およびParquetで該当します。(Parquet形式の外部データは、ダイレクトREAD_NOSクエリーによってではなく、外部テーブルの作成のみによって読み取ることができます。)
同じ論理は、異なるヘッダーを持つCSVファイルが混在する場合にも該当します。キー接頭辞の場所には、これらのCSVファイルのいくつかが含まれる場合がありますが、そのデータにクエリーを行なうのは異なるフィールド パターンのために非効率です。
同じ理由から、同じキー接頭辞の場所に異なるスキーマを持つCSVファイルまたはParquetファイルを混在させないでください。このような場合、そのデータにクエリーを 行なうのは非効率なだけでなく、スキップされたレコードやファイルを示す多くの警告も発生します。