MaxCompute:OSS 外部テーブル

OSS 外部テーブルは、パーティション化されている場合とされていない場合があります。作成する外部テーブルのタイプは、データファイルが OSS にどのように格納されているかによって決まります。データファイルがパーティション化されたディレクトリに格納されている場合は、パーティション化された外部テーブルを作成します。それ以外の場合は、パーティション化されていない外部テーブルを作成します。

注意

CREATE EXTERNAL TABLE 文は、データファイル形式によって異なるパラメーターを必要とします。読み取りまたは書き込み操作中にエラーを回避するために、特定のビジネスニーズに合わせて正しい構文とパラメーターを使用していることを確認してください。

構文

• シナリオ: 組み込みのテキストデータパーサーを使用して外部テーブルを作成する

  構文	データファイル形式	例
  CREATE EXTERNAL TABLE [IF NOT EXISTS] <mc_oss_extable_name> ( <col_name> <data_type>, ... ) [comment <table_comment>] [partitioned BY (<col_name> <data_type>, ...)] stored BY '<StorageHandler>' WITH serdeproperties ( ['<property_name>'='<property_value>',...] ) location '<oss_location>';	OSS からのデータの読み取りまたは OSS へのデータの書き込みでサポートされているデータファイル形式: CSV TSV GZIP、SNAPPY、または LZO 形式で圧縮された CSV または TSV ファイル	OSS 外部テーブルの作成 - 非パーティションテーブル OSS 外部テーブルの作成 - パーティションテーブル OSS 外部テーブルの作成 - データファイルの圧縮

• シナリオ: 組み込みのオープンソースデータパーサーを使用して外部テーブルを作成する

  構文	データファイル形式	例
  CREATE EXTERNAL TABLE [IF NOT EXISTS] <mc_oss_extable_name> ( <col_name> <data_type>, ... ) [comment <table_comment>] [partitioned BY (<col_name> <data_type>, ...)] [row format serde '<serde_class>' [WITH serdeproperties ( ['<property_name>'='<property_value>',...]) ] ] stored AS <file_format> location '<oss_location>' [USING '<resource_name>'] [tblproperties ('<tbproperty_name>'='<tbproperty_value>',...)];	OSS からのデータの読み取りまたは OSS へのデータの書き込みでサポートされているデータファイル形式: PARQUET TEXTFILE ORC RCFILE AVRO JSON SEQUENCEFILE Hudi (Data Lake Formation (DLF) によって生成された Hudi データの読み取りのみをサポートします。) ZSTD、SNAPPY、または GZIP 形式で圧縮された PARQUET ファイル SNAPPY または ZLIB 形式で圧縮された ORC ファイル GZIP、SNAPPY、または LZO 形式で圧縮された TEXTFILE ファイル	PARQUET 外部テーブルの作成 ORC 外部テーブルの作成

• シナリオ: カスタムパーサーを使用して外部テーブルを作成する

  構文	データファイル形式	例
  CREATE EXTERNAL TABLE [IF NOT EXISTS] <mc_oss_extable_name> ( <col_name> <date_type>, ... ) [comment <table_comment>] [partitioned BY (<col_name> <data_type>, ...)] stored BY '<StorageHandler>' WITH serdeproperties ( ['<property_name>'='<property_value>',...] ) location '<oss_location>' USING '<jar_name>';	OSS からのデータの読み取りまたは OSS へのデータの書き込みでサポートされているデータファイル形式: 上記以外の形式のデータファイル。	OSS 外部テーブルの作成 OSS 外部テーブルの作成 - 非テキストデータ

パラメーター

次の表に、すべての形式の外部テーブルに共通のパラメーターを示します。特定の形式に固有のパラメーターについては、その形式のドキュメントをご参照ください。

• 基本構文パラメーター

  パラメーター	必須	説明
  mc_oss_extable_name	はい	作成する OSS 外部テーブルの名前。 テーブル名では大文字と小文字は区別されません。外部テーブルをクエリする場合、大文字と小文字を区別する必要はありません。強制的な大文字と小文字の変換はサポートされていません。
  col_name	はい	OSS 外部テーブルの列の名前。 OSS からデータを読み取る場合、作成された OSS 外部テーブルのスキーマは、OSS データファイルのスキーマと同じでなければなりません。そうでない場合、OSS データを読み取ることはできません。
  data_type	はい	OSS 外部テーブルの列のデータ型。 OSS からデータを読み取る場合、OSS 外部テーブルの列のデータ型は、OSS データファイルの列のデータ型と同じでなければなりません。そうでない場合、OSS データを読み取ることはできません。
  table_comment	いいえ	テーブルのコメント。コメントは、最大 1,024 バイトの有効な文字列である必要があります。そうでない場合、エラーが返されます。
  partitioned by (col_name data_type, ...)	いいえ	OSS のデータファイルがパーティション化されたディレクトリに格納されている場合、このパラメーターはパーティションテーブルを作成するために必須です。 col_name: パーティションキー列の名前。 data_type: パーティションキー列のデータ型。
  '<(tb)property_name>' = '<(tb)property_value>'	はい	OSS 外部テーブルの拡張プロパティ。パラメーターの詳細については、特定の形式のドキュメントをご参照ください。
  oss_location	はい	データファイルが格納されている OSS パス。デフォルトでは、MaxCompute はこのパス内のすべてのデータファイルを読み取ります。 フォーマット: oss://<oss_endpoint>/<Bucket name>/<OSS directory name>/。 oss_endpoint: OSS エンドポイント。OSS が提供するクラシックネットワークのエンドポイントを使用します。これは -internal を含むエンドポイントです。 例: oss://oss-cn-beijing-internal.aliyuncs.com/xxx。 OSS クラシックネットワークのエンドポイントの詳細については、「OSS のリージョンとエンドポイント」をご参照ください。 データファイルが格納されている OSS リージョンは、MaxCompute プロジェクトが配置されているリージョンと同じにすることをお勧めします。異なるリージョンにある場合、データ接続性の問題が発生する可能性があります。 エンドポイントは省略できます。エンドポイントを指定しない場合、システムはデフォルトで現在のプロジェクトが配置されているリージョンのエンドポイントを使用します。 ファイルストレージがリージョンをまたぐ場合、データ接続性の問題が発生する可能性があるため、この方法は推奨されません。 Bucket name: OSS バケットの名前。 例: oss://oss-cn-beijing-internal.aliyuncs.com/your_bucket/path/。 バケット名の詳細については、「バケットのリスト」をご参照ください。 Directory name: OSS ディレクトリの名前。ディレクトリの後にファイル名を指定しないでください。 例: oss://oss-cn-beijing-internal.aliyuncs.com/oss-mc-test/Demo1/。 不正な例: -- HTTP 接続はサポートされていません。 http://oss-cn-shanghai-internal.aliyuncs.com/oss-mc-test/Demo1/ -- HTTPS 接続はサポートされていません。 https://oss-cn-shanghai-internal.aliyuncs.com/oss-mc-test/Demo1/ -- エンドポイントが無効です。 oss://oss-cn-shanghai-internal.aliyuncs.com/Demo1 -- ファイル名を指定しないでください。 oss://oss-cn-shanghai-internal.aliyuncs.com/oss-mc-test/Demo1/vehicle.csv 権限仕様 (RamRole): 明示的に指定 (推奨): カスタムロールを作成し、それにアクセスポリシーをアタッチして、その ARN を使用します。詳細については、「STS パターン権限付与」をご参照ください。 デフォルトロールを使用 (非推奨): aliyunodpsdefaultrole ロールの ARN を使用します。

• WITH serdeproperties プロパティ

  property_name	シナリオ	property_value	デフォルト値
  odps.properties.rolearn	セキュリティトークンサービス (STS) 権限付与を使用する場合、このプロパティを追加します。	OSS へのアクセス権限が付与された RAM ロールの Alibaba Cloud リソースネーム (ARN)。ARN は RAM コンソール のロール詳細から取得できます。例: acs:ram::xxxxxx:role/aliyunodpsdefaultrole。	MaxCompute と OSS のオーナーが同じ Alibaba Cloud アカウントの場合: テーブルを作成するために使用される文で odps.properties.rolearn を指定しない場合、デフォルトで aliyunodpsdefaultrole ロールの ARN が使用されます。 カスタムロールの ARN を使用したい場合は、事前にカスタムロールを作成する必要があります。詳細については、「OSS の STS 権限付与 (方法 2)」をご参照ください。 MaxCompute と OSS のオーナーが異なる Alibaba Cloud アカウントの場合、カスタムロールの ARN を指定する必要があります。カスタムロールの作成方法の詳細については、「OSS の STS 権限付与 (方法 3)」をご参照ください。

OSS 外部テーブルにパーティションデータを追加するための構文

パーティション化された OSS 外部テーブルを作成した場合、次のいずれかの方法を使用してパーティションデータを追加する必要があります:

• 方法 1 (推奨): OSS ディレクトリを自動的に解析してパーティションを識別し、パーティション情報を OSS 外部テーブルに追加する。

  この方法は、不足しているすべての履歴パーティションを一度に追加したいシナリオに適しています。MaxCompute は、OSS 外部テーブルを作成したときに指定したパーティションディレクトリに基づいて、OSS 外部テーブルにパーティションを自動的に追加します。パーティションキー列の名前と値に基づいてパーティションを 1 つずつ追加する必要はありません。

  MSCK REPAIR TABLE <mc_oss_extable_name> ADD PARTITIONS [ WITH properties (key:VALUE, key: VALUE ...)];

  この方法は、増分データの処理には適していません。特に、OSS ディレクトリに 1,000 を超えるような多数のパーティションが含まれている場合は適していません。新しいパーティションの数が既存のパーティションの数よりもはるかに少ない場合、msck コマンドを頻繁に使用すると、OSS ディレクトリの繰り返しスキャンとメタデータの頻繁な更新が発生し、コマンドの実行効率が低下します。増分パーティションを更新する必要があるシナリオでは、方法 2 を使用することをお勧めします。

• 方法 2: 手動でコマンドを実行して、パーティション情報を OSS 外部テーブルに追加する。

  この方法は、履歴パーティションがすでに作成されており、新しいパーティションを頻繁に追加する必要があるシナリオに適しています。データ書き込みタスクを実行する前に、パーティションを作成する必要があります。新しいデータが OSS に書き込まれたときにパーティションをリフレッシュする必要はありません。外部テーブルは、OSS ディレクトリから最新のデータを直接読み取ることができます。

  ALTER TABLE <mc_oss_extable_name> 
    ADD PARTITION (<col_name>=<col_value>)[
    ADD PARTITION (<col_name>=<col_value>)...][location URL];

  col_name と col_value の値は、パーティションデータファイルが格納されているディレクトリの名前と一致する必要があります。

  たとえば、パーティションデータファイルの OSS ディレクトリ構造が次の図のようになっているとします。col_name は direction に対応し、col_value は N, NE, S, SW, W に対応します。各 add partition 文は 1 つのサブディレクトリに対応します。複数の OSS サブディレクトリを追加するには、複数の add partition 文を実行する必要があります。

  

注意

• OSS 外部テーブルを作成した後、それを使用して OSS からデータを読み取ることができます。MaxCompute でサポートされている OSS データファイル形式と OSS 外部テーブルを作成するための構文の詳細については、「構文」をご参照ください。

• SQL 文に複雑なデータ型が含まれている場合は、SQL 文の前に set odps.sql.type.system.odps2=true; コマンドを追加して、それらを一緒に送信する必要があります。データ型の詳細については、「データ型バージョンガイド」をご参照ください。

• オープンソースデータにマッピングされている OSS 外部テーブルの場合、OSS からデータを読み取る前に、セッションレベルで set odps.sql.hive.compatible=true; を設定する必要があります。そうしないと、エラーが返されます。

• OSS は限られたアウトバウンド帯域幅を提供します。短期間にインスタンスの帯域幅制限をデータ読み取りおよび書き込みトラフィックが超えると、OSS 外部テーブルの読み取りおよび書き込み速度が影響を受けます。OSS の帯域幅の詳細については、「制限とパフォーマンスメトリック」をご参照ください。

構文

<select_statement> FROM <from_statement>;

• select_statement: 宛先テーブルに挿入されるソーステーブルからデータをクエリするために使用される SELECT 句。

• from_statement: 外部テーブル名など、データソースを指定する FROM 句。

非パーティションデータ

非パーティション化された OSS 外部テーブルを作成した後、次のいずれかの方法で OSS からデータを読み取ることができます:

• 方法 1 (推奨): OSS から MaxCompute 内部テーブルにデータをインポートし、その後、内部テーブルをクエリする。

  この方法は、データを繰り返し計算する必要がある場合や、計算パフォーマンスに対する要件が高いシナリオに適しています。MaxCompute プロジェクトに OSS 外部テーブルと同じスキーマを持つ内部テーブルを作成し、OSS から内部テーブルにデータをインポートしてから、複雑なクエリを実行できます。この方法により、内部ストレージに対する MaxCompute の最適化メカニズムを最大限に活用して、計算パフォーマンスを向上させることができます。例:

  CREATE TABLE <table_internal> LIKE <mc_oss_extable_name>;
  INSERT OVERWRITE TABLE <table_internal> SELECT * FROM <mc_oss_extable_name>;

• 方法 2: MaxCompute 内部テーブルからデータを読み取るのと同じ方法で、OSS から直接データを読み取る。

  この方法は、計算パフォーマンスに対する要件が高くないシナリオに適しています。内部テーブルからデータを読み取るのとは異なり、各読み取り操作は OSS から直接データを取得します。

パーティションデータ

OSS 外部テーブルをクエリすると、MaxCompute はサブディレクトリ内のデータを含む、OSS ディレクトリ内のすべてのデータに対して全表スキャンを実行します。データ量が大きい場合、完全なディレクトリスキャンは不要な I/O 消費を引き起こし、データ処理時間を増加させます。この問題を解決するには、次のいずれかの方法を使用できます:

• 方法 1 (推奨): 標準パーティションパスまたはカスタムパーティションパス形式のいずれかを使用して OSS にデータを格納する。

  OSS 外部テーブルを作成するときは、作成文でパーティションと oss_location 情報を指定する必要があります。OSS データを標準のパーティションディレクトリに格納することをお勧めします。

• 方法 2: 複数のデータストレージパスを使用する。

  複数の OSS 外部テーブルを作成して、異なるパスからデータを読み取ります。各 OSS 外部テーブルは、OSS データのサブセットにマッピングされます。この方法は面倒で、データ管理が不十分になるため、お勧めしません。

oss://<oss_endpoint>/<Bucket name>/<Directory name>/<partitionKey1=value1>/<partitionKey2=value2>/...

oss://oss-odps-test/log_data/year=2016/month=06/day=01/logfile
oss://oss-odps-test/log_data/year=2016/month=06/day=02/logfile
oss://oss-odps-test/log_data/year=2016/month=07/day=10/logfile
oss://oss-odps-test/log_data/year=2016/month=08/day=08/logfile
...

oss://oss-odps-test/log_data_customized/2016/06/01/logfile
oss://oss-odps-test/log_data_customized/2016/06/02/logfile
oss://oss-odps-test/log_data_customized/2016/07/10/logfile
oss://oss-odps-test/log_data_customized/2016/08/08/logfile
...

ALTER TABLE log_table_external ADD PARTITION (year = '2016', month = '06', day = '01')
location 'oss://oss-cn-hangzhou-internal.aliyuncs.com/bucket-name/oss-odps-test/log_data_customized/2016/06/01/';
ALTER TABLE log_table_external ADD PARTITION (year = '2016', month = '06', day = '02')
location 'oss://oss-cn-hangzhou-internal.aliyuncs.com/bucket-name/oss-odps-test/log_data_customized/2016/06/02/';
ALTER TABLE log_table_external ADD PARTITION (year = '2016', month = '07', day = '10')
location 'oss://oss-cn-hangzhou-internal.aliyuncs.com/bucket-name/oss-odps-test/log_data_customized/2016/07/10/';
ALTER TABLE log_table_external ADD PARTITION (year = '2016', month = '08', day = '08')
location 'oss://oss-cn-hangzhou-internal.aliyuncs.com/bucket-name/oss-odps-test/log_data_customized/2016/08/08/';

クエリの最適化

• 動的統計収集

  データは外部データレイクに格納されており、事前に計算された統計情報がないため、クエリオプティマイザーは保守的な戦略を採用し、クエリ効率が低くなる可能性があります。動的統計収集機能により、オプティマイザーはクエリ実行中にテーブル統計を一時的に収集して、小さなテーブルを識別できます。オプティマイザーはこの情報を使用して、ハッシュ結合を積極的に使用し、結合順序を最適化し、データシャッフルを減らし、実行パイプラインを短縮してクエリを最適化できます。

  SET odps.meta.exttable.stats.onlinecollect=true;
  SELECT * FROM <tablename>;

• 外部テーブルの分割の最適化

  分割サイズパラメーターを設定することで、クエリ効率を最適化できます。これにより、単一の同時タスクによって処理されるデータ量が調整されます。分割サイズの設定には次の効果があります:

  • テーブルに大量のデータが含まれており、分割サイズが小さすぎると、作成される分割が多すぎます。これにより、並列処理の次数が高くなり、インスタンスはほとんどの時間をリソースのキューイングに費やします。

  • テーブルに含まれるデータが少なく、分割サイズが大きすぎると、作成される分割が少なすぎます。これにより、同時実行性が不十分になり、ほとんどのリソースがアイドル状態のままになります。

  SET odps.stage.mapper.split.size=<value>;
  SELECT * FROM <tablename>;

構文

INSERT {INTO|OVERWRITE} TABLE <table_name> PARTITION (<ptcol_name>[, <ptcol_name> ...]) 
<select_statement> FROM <from_statement>;

動的パーティションにデータを挿入するには、「動的パーティションデータの挿入または上書き (DYNAMIC PARTITION)」をご参照ください。

OSS マルチパートアップロード機能を使用した OSS へのデータ書き込み

オープンソース形式で OSS にデータを書き込むには、オープンソースデータパーサーに基づく OSS 外部テーブルと OSS のマルチパートアップロード機能を使用して INSERT 操作を実行できます。

次の設定を使用して、OSS マルチパートアップロード機能を有効にできます:

setproject odps.sql.unstructured.oss.commit.mode =true;

set odps.sql.unstructured.oss.commit.mode =true;

odps.sql.unstructured.oss.commit.mode プロパティのデフォルト値は false です。次の表に、このプロパティの各値の実装原則を示します:

エクスポートされたファイルの管理

動的パーティションへの大きなファイルの書き込み

-- 動的パーティション機能を有効にする必要があります。
set odps.sql.reshuffle.dynamicpt=true; 	

-- 各 Reducer が消費するデータの希望量を設定します。各ファイルを 4 GB にすると仮定します。
set odps.adaptive.shuffle.desired.partition.size=4096;	

• 外部テーブルを使用して OSS データを処理する際に「Inline data exceeds the maximum allowed size」エラーを解決するにはどうすればよいですか？

• ローカルテストに合格した UDF を使用して MaxCompute の OSS 外部テーブルにアクセスするとメモリ不足エラーが発生する場合、どうすれば解決できますか？

• OSS 外部テーブルを使用して複数の小さなファイルを 1 つのファイルにマージするにはどうすればよいですか？

• OSS 外部テーブルを読み取る際に「Couldn't connect to server」エラーを解決するにはどうすればよいですか？

• OSS 外部テーブルを作成する際に「Network is unreachable (connect failed)」エラーを解決するにはどうすればよいですか？

• マルチパートアップロードのシナリオで、古いデータは削除されたが新しいデータが書き込まれない問題を解決するにはどうすればよいですか？

外部テーブルを使用して OSS データを処理する際に「Inline data exceeds the maximum allowed size」エラーを解決するにはどうすればよいですか？

• 現象

  OSS データを処理する際に、Inline data exceeds the maximum allowed size というエラーが報告されます。

• 原因

  OSS 内の単一ファイルのサイズが 3 GB を超えることはできません。ファイルがこの制限を超えると、このエラーが報告されます。

• 解決策

  この問題を解決するには、次の 2 つのプロパティを調整できます。目的は、これらのプロパティ値を使用して実行計画を調整し、各 Reducer が OSS 外部テーブルに書き込むデータのサイズを制御して、OSS ファイルが 3 GB の制限を超えないようにすることです。

  set odps.sql.mapper.split.size=256; # 各 Mapper が読み取るデータのサイズを調整します (MB 単位)。
  set odps.stage.reducer.num=100; # Reduce ステージのワーカー数を調整します。

ローカルテストに合格した UDF を使用して MaxCompute の OSS 外部テーブルにアクセスするとメモリ不足エラーが発生する場合、どうすれば解決できますか？

• 現象

  MaxCompute の OSS 外部テーブルにアクセスする際、ローカルテストに合格した UDF がアップロード後に次のエラーを返します。

  FAILED: ODPS-0123131:User defined function exception - Traceback:
  java.lang.OutOfMemoryError: Java heap space        

  次のパラメーターを設定した後、実行時間は長くなりますが、エラーは解決しません。

  set odps.stage.mapper.mem = 2048; 
  set odps.stage.mapper.jvm.mem = 4096;       

• 原因

  外部テーブルにオブジェクトファイルが多すぎ、テーブルがパーティション化されていないため、過剰なメモリ使用量が発生します。

• 解決策

  • より少量のデータをクエリします。

  • オブジェクトファイルをパーティション化して、メモリ使用量を削減します。

OSS 外部テーブルを使用して複数の小さなファイルを 1 つのファイルにマージするにはどうすればよいですか？

Logview ログをチェックして、SQL 実行計画の最後のステージが Reducer または Joiner であるかどうかを確認します。

• Reducer の場合は、set odps.stage.reducer.num=1; という文を実行します。

• Joiner の場合は、set odps.stage.joiner.num=1; という文を実行します。

OSS 外部テーブルを読み取る際に「Couldn't connect to server」エラーを解決するにはどうすればよいですか？

• 現象

  OSS 外部テーブルからデータを読み取る際に、ODPS-0123131:User defined function exception - common/io/oss/oss_client.cpp(95): OSSRequestException: req_id: , http status code: -998, error code: HttpIoError, message: Couldn't connect to server というエラーが報告されます。

• 原因

  • 原因 1: OSS 外部テーブルを作成する際、oss_location アドレスの oss_endpoint が内部エンドポイントではなくパブリックエンドポイントを使用していました。

  • 原因 2: OSS 外部テーブルを作成する際、oss_location アドレスの oss_endpoint が別のリージョンのエンドポイントを使用していました。

• 解決策

  • 原因 1 の場合:

    OSS 外部テーブルの CREATE TABLE 文の oss_location パラメーターの oss_endpoint が内部ネットワークアドレスであるかどうかを確認します。パブリックネットワークアドレスの場合は、内部ネットワークアドレスに変更する必要があります。パラメーターの詳細については、「パラメーターの説明」セクションをご参照ください。

    たとえば、インドネシア (ジャカルタ) リージョンのユーザーがアドレス oss://oss-ap-southeast-5.aliyuncs.com/<bucket>/.... を使用して外部テーブルを作成した場合、対応する内部アドレス oss://oss-ap-southeast-5-internal.aliyuncs.com/<bucket>/.... に変更する必要があります。

  • 原因 2 の場合:

    OSS 外部テーブルの `CREATE TABLE` 文の `oss_location` パラメーターの `oss_endpoint` が、アクセスしたいリージョンのエンドポイントであることを確認します。OSS クラシックネットワークのドメイン名の詳細については、「OSS のリージョンとエンドポイント」をご参照ください。

OSS 外部テーブルを作成する際に「Network is unreachable (connect failed)」エラーを解決するにはどうすればよいですか？

• 現象

  OSS 外部テーブルを作成する際に、ODPS-0130071:[1,1] Semantic analysis exception - external table checking failure, error message: Cannot connect to the endpoint 'oss-cn-beijing.aliyuncs.com': Connect to bucket.oss-cn-beijing.aliyuncs.com:80 [bucket.oss-cn-beijing.aliyuncs.com] failed: Network is unreachable (connect failed) というエラーが報告されます。

• 原因

  OSS 外部テーブルを作成する際、oss_location アドレスの oss_endpoint が内部エンドポイントではなくパブリックエンドポイントを使用していました。

• 解決策

  OSS 外部テーブルの作成文の `oss_location` パラメーターの oss_endpoint が内部ネットワークアドレスであるかどうかを確認します。パブリックネットワークアドレスの場合は、内部ネットワークアドレスに変更する必要があります。パラメーターの詳細については、「パラメーターの説明」セクションをご参照ください。

  たとえば、中国 (北京) リージョンのユーザーがアドレス oss://oss-cn-beijing.aliyuncs.com/<bucket>/.... を使用して外部テーブルを作成した場合、対応する内部アドレス oss://oss-cn-beijing-internal.aliyuncs.com/<bucket>/.... に変更する必要があります。

OSS 外部テーブルでの SQL ジョブの実行が遅い問題を解決するにはどうすればよいですか？

• OSS 外部テーブル内の GZ 圧縮ファイルの読み取りが遅い

  • 現象

    OSS 内の 200 GB の GZ 圧縮ファイルをデータソースとして使用する OSS 外部テーブルからのデータ読み取りが遅い。

  • 原因

    Map ステージで計算を実行している Mapper が少なすぎるため、SQL 処理が遅くなっています。

  • 解決策

    • 構造化データの場合、次のパラメーターを設定して、単一の Mapper が読み取るデータ量を調整し、SQL の実行を高速化できます。

      set odps.sql.mapper.split.size=256; # 各 Mapper が読み取るテーブルデータのサイズを調整します (MB 単位)。       

    • 非構造化データの場合、OSS 外部テーブルのパスに OSS ファイルが 1 つしかないかどうかを確認します。1 つしかない場合、圧縮形式の非構造化データは分割できないため、Mapper は 1 つしか生成できず、処理が遅くなります。大きな OSS ファイルを、OSS 上の対応する外部テーブルパスにある小さなファイルに分割することをお勧めします。これにより、外部テーブルを読み取る際に生成される Mapper の数が増え、読み取り速度が向上します。

• SDK を使用した MaxCompute 外部テーブルでのデータ検索が遅い

  • 現象

    SDK を使用して MaxCompute 外部テーブルでデータを検索するのが遅い。

  • 解決策

    外部テーブルは全表スキャンのみをサポートしており、これは遅いです。代わりに MaxCompute 内部テーブルを使用することをお勧めします。

マルチパートアップロードのシナリオで、古いデータは削除されたが新しいデータが書き込まれない問題を解決するにはどうすればよいですか？

• 現象

  insert overwrite 操作では、ジョブが失敗した場合、極端なケースで予期しない問題が発生する可能性があります。問題は、古いデータが削除されたが、新しいデータが書き込まれないことです。

• 原因

  まれなハードウェア障害またはメタデータ更新の失敗により、新しいデータが宛先テーブルに正常に書き込まれませんでした。OSS の削除操作はロールバックをサポートしていないため、削除された古いデータを回復することはできません。

• 解決策

  • 既存のデータに基づいて OSS 外部テーブルを上書きする場合、たとえば insert overwrite table T select * from table T; のように、事前に OSS データをバックアップする必要があります。ジョブが失敗した場合、バックアップしたデータを使用して OSS 外部テーブルを上書きできます。

  • insert overwrite ジョブを複数回送信できる場合は、ジョブが失敗した場合に再送信できます。