MaxCompute:OSS 外部テーブル

構文

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>';

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>',...)];

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>';

パラメーター

以下は、さまざまな形式の外部テーブルに共通のパラメーターです。固有のパラメーターについては、各外部テーブル形式のドキュメントをご参照ください。

• 基本構文パラメーター

  パラメーター	必須	説明
  mc_oss_extable_name	はい	作成する OSS 外部テーブルの名前。 テーブル名は大文字と小文字を区別しません。外部テーブルをクエリする際に大文字と小文字を区別する必要はなく、強制的に大文字小文字を変換することはできません。
  col_name	はい	OSS 外部テーブルの列の名前。 OSS からデータを読み取る際、作成された OSS 外部テーブルのスキーマは OSS データファイルのスキーマと同じでなければなりません。そうでない場合、データは読み取れません。
  data_type	はい	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 パス。デフォルトでは、このパス内のすべてのデータファイルが読み取られます。 形式は oss://<oss_endpoint>/<Bucket name>/<OSS directory name>/ です。 oss_endpoint： OSS ドメイン名。OSS が提供するクラシックネットワークエンドポイントを使用する必要があり、これには -internal が含まれます。 例：oss://oss-cn-beijing-internal.aliyuncs.com/xxx。 OSS クラシックネットワークドメイン名の詳細については、「リージョンとエンドポイント」をご参照ください。 データファイルが保存されている OSS リージョンは、MaxCompute プロジェクトのリージョンと同じにしてください。異なるリージョンにある場合、ネットワーク接続の問題が発生する可能性があります。 エンドポイントを指定しない場合、システムは現在のプロジェクトが配置されているリージョンのエンドポイントを使用します。 この方法は、リージョンをまたいだファイルストレージがネットワーク接続の問題を引き起こす可能性があるため、推奨されません。 バケット名：OSS バケットの名前。バケット名は oss_endpoint の後に続く必要があります。 例：oss://oss-cn-beijing-internal.aliyuncs.com/your_bucket/path/。 バケット名の表示方法については、「バケットのリスト表示」をご参照ください。 ディレクトリ名：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 ロールの ARN を指定します。 RAM コンソールのロール詳細から ARN を取得します。例：acs:ram::xxxxxx:role/aliyunodpsdefaultrole。	MaxCompute と OSS のオーナーが同じアカウントの場合： テーブル作成ステートメントで odps.properties.rolearn を指定しない場合、デフォルトで aliyunodpsdefaultrole ロールの ARN が使用されます。まず、STS 認証を使用して aliyunodpsdefaultrole ロールを作成する必要があります。 カスタムロールの ARN を使用するには、まずカスタムロールを作成する必要があります。詳細については、「OSS の STS 認証 (カスタム認証)」をご参照ください。 MaxCompute と OSS のオーナーが異なるアカウントの場合、カスタムロールの ARN を指定する必要があります。詳細については、「OSS の STS 認証 (カスタム認証)」をご参照ください。

OSS 外部テーブルへのパーティションの追加

パーティション化された OSS 外部テーブルを作成した場合、パーティションデータをインポートするための追加操作を実行する必要があります。

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

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

  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 に対応します。1 つの add partition 句は 1 つのサブディレクトリに対応します。複数の OSS サブディレクトリに対しては、複数の add partition 句を使用する必要があります。

  

注意事項

• OSS 外部テーブルを作成した後、外部テーブルを介して OSS からデータを読み取ることができます。サポートされている 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 消費を引き起こし、データ処理時間を増加させる可能性があります。この問題は 2 つの方法で解決できます。

• 方法 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/';

クエリの最適化

• 動的統計収集

  データは外部データレイクに保存されており、既存の統計情報がないため、クエリオプティマイザーは保守的な戦略を使用し、クエリ効率が低くなります。動的統計収集機能により、オプティマイザーはクエリ実行中に一時的にテーブル統計を収集して小規模なテーブルを識別できます。その後、ハッシュ結合などの手法を積極的に使用し、結合順序を最適化し、シャッフルを削減し、実行パイプラインを短縮してクエリの最適化を実現します。

  以下のパラメーターは、Paimon、Hudi、または Delta Lake 外部テーブルには適用されません。

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

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

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

  • テーブルのデータ量が非常に大きく、毎回読み取るデータ量が少なすぎる場合、分割数が多すぎて過剰な並列処理が発生します。その結果、インスタンスはほとんどの時間をリソースの待機に費やします。

  • テーブルのデータ量が非常に少なく、毎回読み取るデータ量が多すぎる場合、分割数が少なすぎて同時実行性が不足します。その結果、ほとんどのリソースがアイドル状態になります。

  -- 以下のパラメーターのいずれかを使用できます。
  
  -- 単位：MiB。デフォルト値：256 MiB。内部または外部テーブルに適用されます。
  SET odps.stage.mapper.split.size=<value>;
  SELECT * FROM <tablename>;
  
  -- 単位：MiB。デフォルト値：256 MiB。外部テーブルにのみ適用されます。
  SET odps.sql.unstructured.data.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 にデータを書き込むことができます。

OSS マルチパートアップロード機能を有効にするには、次のように設定します。

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

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

odps.sql.unstructured.oss.commit.mode プロパティのデフォルト値は false です。異なる値の実装原則は次のとおりです。

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

動的パーティションを使用した大容量ファイルの書き込み

-- service.mode はオフにする必要があります。
SET odps.service.mode=off;

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

-- 各レデューサーの目的のデータ消費量を設定します。各ファイルを 4 GB にしたいと仮定します。
SET odps.adaptive.shuffle.desired.partition.size=4096;	

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

• MaxCompute 上で OSS 外部テーブルにアクセスする UDF をアップロードした後、ローカルテストは合格したにもかかわらずメモリオーバーフローエラーが発生する場合、どうすれば解決できますか？

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

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

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

• OSS マルチパートアップロード機能を使用しているときに、古いデータは削除されるが新しいデータが書き込まれない問題を解決するにはどうすればよいですか？

• Spark から OSS 外部テーブルにアクセスする際の「table not found」エラーの解決策。

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

• 問題

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

• 原因

  OSS Store には各小規模ファイルのサイズ制限があります。ファイルが 3 GB を超えるとエラーが報告されます。

• 解決策

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

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

MaxCompute 上で OSS 外部テーブルにアクセスする UDF をアップロードした後、ローカルテストは合格したにもかかわらずメモリオーバーフローエラーが発生する場合、どうすれば解決できますか？

• 問題

  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 外部テーブルを使用して複数の小規模ファイルを単一ファイルにマージするにはどうすればよいですか？

Logview ログを確認して、SQL 実行計画の最終ステージがレデューサーかジョイナーかを確認します。

• レデューサーの場合、set odps.stage.reducer.num=1; という文を実行します。

• ジョイナーの場合、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 外部テーブル作成ステートメントの oss_location パラメーターの oss_endpoint が内部エンドポイントであるか確認します。パブリックエンドポイントの場合は、内部エンドポイントに変更します。パラメーターの詳細については、「パラメーター」をご参照ください。

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

  • 原因 2 の場合：

    OSS 外部テーブル作成ステートメントの oss_location パラメーターの oss_endpoint がアクセスしたいリージョンのエンドポイントであるか確認します。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 ステージで計算を実行しているマッパーが少なすぎるため、SQL 処理速度が遅くなっています。

  • 解決策

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

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

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

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

  • 症状

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

  • 解決策

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

OSS マルチパートアップロード機能を使用しているときに、古いデータは削除されるが新しいデータが書き込まれない問題を解決するにはどうすればよいですか？

• 問題

  insert overwrite シナリオで、極端な場合にジョブが失敗すると、結果が期待と一致しないことがあります。古いデータは削除されますが、新しいデータは書き込まれません。

• 原因

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

• 解決策

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

  • insert overwrite ジョブが再送信可能な場合は、ジョブが失敗した場合に単に再送信します。

Spark から OSS 外部テーブルにアクセスする際の「table not found」エラーの解決策

• 問題

  Spark を使用して OSS 外部テーブルにアクセスすると、タスクが「table not found」エラーで失敗します。

• 解決策

  • 次のパラメーターを追加します。

    • 外部テーブル構成を有効にする：spark.sql.catalog.odps.enableExternalTable=true;

    • OSS が配置されているリージョンを構成する：spark.hadoop.odps.oss.region.default=cn-<region>

  • 上記のパラメーターを追加してもエラーが解決しない場合は、以下のようにします。

    

    OSS 外部テーブルを再作成してから、再度アクセスします。