MaxCompute では、オブジェクトテーブル機能が導入されました。この機能により、データウェアハウスのコンピュートエンジンがデータレイクストレージ内の非構造化データとそのメタデータにアクセスできるようになります。本トピックでは、オブジェクトテーブルのコマンド構文を説明し、使用例を示します。
背景
多くの AI プロセスでは、データおよびビジネス運用に精通したデータウェアハウス開発者が必要です。これらの開発者は、ビッグデータプラットフォームの低コストかつ大規模なコンピューティング能力を活用して、大規模言語モデル向けのデータ前処理や非構造化データの処理を行います。これらのプロセスとその結果は、データウェアハウスまたはデータレイク内のデータと相互作用します。
SQL を使用して非構造化データを処理する際には、以下の課題があります。
ビッグデータ SQL エンジンは、Object Storage Service (OSS) からファイルを読み取る際にオブジェクトサイズを認識できません。そのため、実行計画の最適化、同時実行数の制御、適切な同時タスク数の自動起動が困難です。また、フィルター条件を効果的に述語プッシュダウンできません。これにより、データスキューが発生した場合にコンピューティング能力を十分に活用できません。
Object Storage Service からのメタデータ読み取りは非効率的です。各クエリでストレージサービスへのリモートアクセスが必要となるため、高遅延が発生します。
Object Storage Service (OSS) からのファイルリストは、ユーザー定義テーブル関数 (UDTF) 内の単一プロセスでしかシリアルに取得できません。これにより、データ読み取りパフォーマンスが低下します。
ストレージサービスへの権限およびネットワーク接続を処理するロジックを、ユーザー定義関数 (UDF) 内で実装する必要があります。
UDF による非構造化データ処理の機能は限定的です。従来のデータウェアハウスには、カスタムイメージを柔軟かつ安全にアップロードする方法がなく、UDF の安全な実行環境も不足しています。さらに、リモート呼び出しには分散コンピューティングサービスとの同時統合が必要です。
特徴
MaxCompute では、オブジェクトテーブル機能が導入されました。この機能により、データウェアハウスのコンピュートエンジンがデータレイクストレージ内の非構造化データとそのメタデータにアクセスできるようになります。主な機能は以下のとおりです。
OSS オブジェクトのメタデータをテーブルとして読み取ることができます。
メタデータテーブル機能に基づき、さまざまなタイプの OSS オブジェクトメタデータをバージョン管理された形でキャッシュします。SQL エンジンはこのメタデータテーブルを使用して、データフィルタリングや述語プッシュダウンなどの効果的なクエリ最適化を実行できます。
組み込みのドキュメント関数を使用して、非構造化データファイルの内容を複数の方法で読み取ることができます。
MaxCompute SQL エンジンは、オブジェクトテーブルのメタデータを使用して同時チャンキングを実行します。これにより、大規模分散コンピューティングによってデータ読み取りおよび処理の効率が向上します。
カスタムイメージをアップロードして UDF を構築し、エンジンによって読み取られた非構造化データを処理できます。
エンジンが非構造化データを処理し、構造化データの結果をデータウェアハウス内の内部テーブルおよび外部テーブルに書き込むことができます。また、将来的には非構造化データの結果を生成し、オブジェクトテーブル経由で Object Storage Service に書き戻すこともサポートされる予定です。
Python エコシステム向けの Maxframe エンジンをサポートします。
制限事項
MaxCompute プロジェクトはスキーマ機能をサポートしている必要があります。詳細については、「スキーマ機能の有効化」をご参照ください。
MaxCompute は 2.0 データ型システムをサポートしている必要があります。
オブジェクトテーブルはパーティションをサポートしていません。
課金
オブジェクトテーブルは、OSS からのオブジェクトメタデータのコレクションです。リフレッシュされオブジェクトテーブルに保存されたメタデータに対してストレージ料金が発生します。詳細については、「ストレージ料金」をご参照ください。OSS 上のファイルは MaxCompute 内に保存されないため、MaxCompute ではストレージ料金は発生しません。OSS ではデータストレージおよびアクセスに対して料金が発生します。詳細については、「OSS ストレージ料金」をご参照ください。
OSS メタデータを抽出およびリフレッシュするタスクでは、スキャンされた各ファイルの
inputsizeは実際のファイルサイズではなくメタデータに関連する値となります。したがって、リフレッシュタスクの総コストはファイル数に関連し、OSS 上の実際のファイルサイズには関連しません。詳細については、「外部テーブルの SQL 課金」をご参照ください。オブジェクトテーブルとそのメタデータを使用して OSS から非構造化データを分析・抽出・処理する際に計算料金が発生します。
従量課金モードでは、オブジェクトテーブルに対するメタデータ分析は内部テーブルとして課金されます。詳細については、「標準 SQL 課金」をご参照ください。OSS からの非構造化データの内容を処理する場合は、外部テーブルとして課金されます。詳細については、「外部テーブルの SQL 課金」をご参照ください。
サブスクリプションモードでは、サブスクリプション計算リソースが使用されます。詳細については、「計算料金 (サブスクリプション)」をご参照ください。
OBJECT TABLE の作成
構文
CREATE OBJECT TABLE [IF NOT EXISTS] <objecttable_name>
WITH SERDEPROPERTIES ('<key>' = '<value>')
LOCATION '<location>'
[TBLPROPERTIES ('<key>' = '<value>')]
[COMMENT '<comment>']
;オブジェクトテーブルは、スキーマモードをサポートするプロジェクトで使用する必要があり、スキーマ構文スイッチを有効にする必要があります。
オブジェクトテーブルではカラムを定義する必要はありません。システムがメタデータカラムを提供します。
パラメーター
パラメーター | 必須 | 説明 |
objecttable_name | 必須 | テーブル名 |
SERDEPROPERTIES ('<key>'='<value>') | 必須 | 認証用の RAM ロールを指定します。このパラメーターを指定しない場合、デフォルトで現在の Alibaba Cloud アカウント下の 例: ロールを使用する前に、Security Token Service (STS) トークンを使用して MaxCompute プロジェクトが現在の Alibaba Cloud アカウントの OSS リソースに直接アクセスできるように、
説明 ワンクリック権限付与は、MaxCompute プロジェクトの ProjectOwner が OSS の Alibaba Cloud アカウントである場合にのみ実行できます。 |
location | 必須 |
|
TBLPROPERTIES ('<key>'='<value>') | 任意 |
|
comment | 任意 | テーブルコメント |
例
SET odps.namespace.schema=true;
CREATE OBJECT TABLE ot_demo_day
WITH serdeproperties (
'odps.properties.rolearn'='acs:ram::xxxxxx:role/aliyunodpsdefaultrole')
LOCATION 'oss://oss-cn-hangzhou-internal.aliyuncs.com/odps-external-****/ottest/';OBJECT TABLE プロパティの表示
構文
DESC <object_table_name>パラメーター
object_table_name: 必須。テーブル名。
例
DESC ot_demo_day; 以下の結果が返されます。
+------------------------------------------------------------------------------------+
| Owner: ALIYUN$****@test.aliyunid.com |
| Project: test_objecttable |
| Schema: default |
| TableComment: |
+------------------------------------------------------------------------------------+
| CreateTime: 2024-09-02 20:01:56 |
| LastDDLTime: 2024-09-02 20:01:56 |
| LastModifiedTime: 2024-09-02 20:01:56 |
+------------------------------------------------------------------------------------+
| InternalTable: YES | Size: 0 |
+------------------------------------------------------------------------------------+
| Native Columns: |
+------------------------------------------------------------------------------------+
| Field | Type | Label | Comment |
+------------------------------------------------------------------------------------+
| key | varchar(2048) | | The name of the object. |
| size | bigint | | The size of the returned object in bytes. |
| type | varchar(32) | | The type of the object and valid values: Normal, Multipart, Appendable, and Symlink. |
| last_modified | timestamp | | The last modified time of the object. |
| storage_class | varchar(32) | | The storage class of the object. |
| etag | varchar(64) | | The entity tag (ETag). When an object is created, an ETag is created to identify the content of the object. |
| restore_info | varchar(256) | | The restoration status of the object. |
| owner_id | bigint | | The ID of the bucket owner. |
| owner_display_name | varchar(256) | | The display name of the bucket owner. |
+------------------------------------------------------------------------------------+返された結果の一部のカラムについて以下に説明します。
カラム名 | 型の説明 | NULL 許容 | 説明 |
key | VARCHAR(2048) ネイティブの長さ制約は 1023 です。 詳細については、「OSS オブジェクトの命名規則と例」をご参照ください。 | False | オブジェクトテーブル内のオブジェクトの相対パス名 |
size | BIGINT | False | オブジェクトのサイズ (バイト単位) |
type | VARCHAR(32) | False | OSS 内のオブジェクトのファイルタイプ: Normal、Multipart、Appendable、Symlink |
last_modified | TIMESTAMP_NTZ | False | OSS 上でオブジェクトデータが最後に変更された時刻 |
storage_class | VARCHAR(32) | False | OSS 上のオブジェクトのストレージクラス。具体的なタイプの詳細については、「ストレージクラス」をご参照ください。 |
etag | VARCHAR(64) | False | ETag は、各オブジェクトが生成される際に作成されるエンティティタグです。これは、2 回の更新間でオブジェクトの内容が変更されたかどうかを識別するための署名ですが、一意の識別子ではありません。 |
restore_info | VARCHAR(256) | True | オブジェクトがコールドストレージから復元されたかどうかを示します。オブジェクトが復元中の場合、このフィールドにはプロセスに関する情報が含まれます。 |
owner_id | BIGINT | True | オブジェクト所有者の ID |
owner_display_name | VARCHAR(256) | True | オブジェクト所有者の表示名 |
OBJECT TABLE の DDL 文の表示
構文
SHOW CREATE TABLE <object_table_name>;パラメーター
object_table_name: 必須。テーブル名。
例
SHOW CREATE TABLE ot_demo_day; 以下の結果が返されます。
CREATE OBJECT TABLE IF NOT EXISTS yunqi_object_****.`default`.ot_demo_day
WITH SERDEPROPERTIES (
'serialization.format'='1',
'odps.properties.rolearn'='acs:ram::139699392458****:role/aliyunodpsdefaultrole')
LOCATION
'oss://oss-cn-hangzhou-internal.aliyuncs.com/odps-external-****/ottest/'
TBLPROPERTIES (
'last_modified_time'='1731478307',
'transient_lastDdlTime'='1731478307',
'metadata.cache.mode'='manual',
'metadata.staleness.seconds'='3600');OBJECT TABLE メタデータのリフレッシュ
オブジェクトテーブルの実際のオブジェクトデータは OSS に保存されています。MaxCompute はこれらのオブジェクトのメタデータをキャッシュし、キャッシュされたメタデータに基づいてクエリおよび計算を実行します。したがって、オブジェクトテーブルを使用する前に、キャッシュをリフレッシュする必要があります。キャッシュのリフレッシュは手動で行うか、テーブル作成時に定期リフレッシュを設定できます。
手動リフレッシュおよび定期リフレッシュの両方が完全更新です。
手動リフレッシュ
各リフレッシュはメタデータの完全同期です。リフレッシュのタイミングと頻度を制御できます。
構文
ALTER TABLE <objecttable_name> REFRESH METADATA;パラメーター
objecttable_name: 必須。テーブル名。
例
ALTER TABLE ot_demo_day REFRESH METADATA;
定期リフレッシュ
オブジェクトテーブルにマッピングされた OSS ディレクトリ内のファイルが頻繁に変更される場合は、メタデータを定期的にリフレッシュできます。これを行うには、テーブル作成時に関連パラメーターを指定します。これにより、メンテナンスコストを削減できます。
構文
SET odps.namespace.schema=true; SET odps.sql.type.system.odps2 = true; CREATE OBJECT TABLE ot_demo_day WITH serdeproperties ( 'odps.properties.rolearn'='acs:ram::xxxxxx:role/aliyunodpsdefaultrole' ) location 'oss://oss-cn-hangzhou-internal.aliyuncs.com/odps-external-****/ottest/' tblproperties ( 'metadata.cache.mode' = 'periodic', 'metadata.staleness.seconds' = '3600' );パラメーター
metadata.staleness.seconds: リフレッシュ期間。periodicモードでは、このパラメーターを指定する必要があります。値は[1, 604800](1 秒から 1 週間) の範囲内である必要があります。このパラメーターは厳密な保証ではなく、スケジューラはこのパラメーターに基づいてリフレッシュを実行しようとします。metadata.cache.mode: リフレッシュのトリガー方法を指定します。以下の 3 つのオプションがあります。periodic: 定期トリガーcrontab: スケジュールされたリフレッシュmanual: 手動トリガー (デフォルト)。トリガーのタイミングを制御できます。
スケジュールされたリフレッシュ
オブジェクトテーブルにマッピングされた OSS ディレクトリ内のファイルが頻繁に変更される場合は、メタデータを固定時刻にリフレッシュするようにスケジュールできます。これを有効にするには、テーブル作成時に関連パラメーターを指定します。これにより、メンテナンスコストを削減できます。
構文
SET odps.namespace.schema=true; SET odps.sql.type.system.odps2 = true; CREATE OBJECT TABLE ot_demo_day WITH SERDEPROPERTIES ( 'odps.properties.rolearn'='acs:ram::xxxxxx:role/aliyunodpsdefaultrole' ) LOCATION 'oss://oss-cn-region-internal.aliyuncs.com/odps-external-****/ottest/' TBLPROPERTIES ( 'metadata.cache.mode' = 'crontab', 'metadata.crontab.expression' = 'your_timed_expression' );パラメーター
metadata.crontab.expression: スケジュールタスクの cron 式。たとえば、毎日午後 2 時にタスクをトリガーする場合、式は0 0 14 * * ?です。この式は、秒に0、分に0、時 (午後 2 時) に14、月の日に*、月に*を指定します。曜日には?を使用し、月の日と相互排他になるようにして競合を防ぎます。metadata.cache.mode: リフレッシュをトリガーする方法。以下の 3 つのオプションがあります。crontab: スケジュールされたリフレッシュperiodic: 定期的にトリガーmanual: 手動トリガー (デフォルト)。トリガーのタイミングを制御できます。
リフレッシュタスクの表示
次のコマンドを使用して、過去のリフレッシュタスクのステータスを表示できます。
SHOW refresh task history FOR object TABLE <object_table_name>;パラメーター
<object_table_name> はオブジェクトテーブルである必要があります。
戻り値: このコマンドは、各リフレッシュタスクのインスタンス ID (InstanceId)、開始時刻 (CreateTime)、終了時刻 (EndTime)、ステータス (Status) を返します。
ステータスが Failed の場合、
wait InstanceId;を実行してからログビューを出力し、エラーの詳細を確認できます。
例
-- オブジェクトテーブルの過去のリフレッシュタスクを表示します。 SHOW refresh task history for object table ot_demo_day04; -- 以下の結果が返されます。 ID = 20260105*******f +---------------------------------------------------------------------------------------------------+ | Project: test_project | | Schema: default | | Task: *** | +---------------------------------------------------------------------------------------------------+ | History: | +---------------------------------------------------------------------------------------------------+ | InstanceId | CreateTime | EndTime | Status | +---------------------------------------------------------------------------------------------------+ | 20260105******************ks | 2026-01-05 14:12:00 | 2026-01-05 14:12:04 | Terminated | | 20260105******************y3 | 2026-01-05 14:10:00 | 2026-01-05 14:10:03 | Terminated | +---------------------------------------------------------------------------------------------------+ OK
OBJECT TABLE を照会する
オブジェクトテーブルは OSS ディレクトリ内のファイルのメタデータを取得します。オブジェクトテーブルをクエリしてこのメタデータを表示できます。また、SQL ステートメントを使用してメタデータに対してフィルタリングやマッチングなどの計算を実行できます。これらの計算には、集約、結合、ウィンドウ関数、ORDER BY 句、LIMIT 句などが含まれますが、これらに限定されません。
構文
SELECT * FROM <object_table_name>;パラメーター
object_table_name: 必須。テーブル名。
例
-- 指定された OSS ディレクトリにアップロードされたデータをクエリできます。データ量が多い場合は、5 件のレコードを表示します。
SELECT * FROM ot_demo_day [limit 5];ビジネス計算のためのオブジェクトコンテンツのクエリ
クエリプロセスはオブジェクトメタデータに対してのみ計算を実行し、オブジェクトの実際のコンテンツは関与しません。ただし、計算プロセスではオブジェクトの実際のコンテンツを読み取る必要があります。MaxCompute には組み込みのダウンロード関数があり、計算プロセスに統合できます。
GET_DATA_FROM_OSS 関数の構文
GET_DATA_FROM_OSS 関数は、オブジェクトのコンテンツの一部またはすべてを読み取り、バイナリ形式で返します。
BINARY GET_DATA_FROM_OSS (
STRING <full_object_table_name>,
STRING <key>
[, BIGINT <offset>]
[, BIGINT <length>]
[, STRING <object_not_found_policy>]
)パラメーター
パラメーター | 必須 | データ型 | 説明 | デフォルト値 |
full_object_table_name | はい | STRING | 3 階層モデルにおけるOBJECT TABLEの完全なパス。プロジェクト名とスキーマ名を含みます (例: テーブル作成時に RoleARN を使用して認証する場合、このパラメーターにより OSS へのアクセス用の Security Token Service (STS) トークンが自動的に生成されます。 | なし |
key | はい | STRING | オブジェクトテーブル内でアクセスされるオブジェクトの名前。「OBJECT TABLE プロパティの表示」で説明されている応答の `key` パラメーターの説明をご参照ください。 | なし |
offset | いいえ | BIGINT | オブジェクトコンテンツを読み取る開始位置。値は 0 以上である必要があります。 | 0。つまり、オブジェクトの先頭から読み取りを開始します。 |
length | いいえ | BIGINT | 読み取るバイト数 | -1。つまり、長さに制限はありません。 |
object_not_found_policy | いいえ | STRING | キャッシュデータ内にオブジェクトキーが存在するが、OSS 内にオブジェクトが存在しなくなった場合に、MaxCompute が関数呼び出しの結果をどのように返すかを指定します。有効な値:
| デフォルト値は OUTPUT_NULL です。 |
例 1
GET_DATA_FROM_OSS 関数の結果を STRING 型として出力するには、`STRING` 関数内でネストします。
SELECT STRING(
GET_DATA_FROM_OSS('<project_name>.default.ot_demo_day', key, 0, -1, 'OUTPUT_NULL')
)
FROM ot_demo_day;例 2
オブジェクトテーブルのすべてのコンテンツを読み取り、バイナリ値として返します。オブジェクトテーブルの完全なパスは <project_name>.default.ot_demo_day です。以下のコードは、異なるパラメーターの組み合わせを示しています。
-- 完全な形式。
SELECT GET_DATA_FROM_OSS('<project_name>.default.ot_demo_day', key, 0, -1, 'OUTPUT_NULL') FROM ot_demo_day;
-- 以下の文は get_data_from_oss('<project_name>.default.ot_demo_day', key, 0, -1, 'OUTPUT_NULL') と同等です。
SELECT GET_DATA_FROM_OSS('<project_name>.default.ot_demo_day', key) FROM ot_demo_day;
SELECT GET_DATA_FROM_OSS('<project_name>.default.ot_demo_day', key, 0) FROM ot_demo_day;
SELECT GET_DATA_FROM_OSS('<project_name>.default.ot_demo_day', key, 0, -1) FROM ot_demo_day;
SELECT GET_DATA_FROM_OSS('<project_name>.default.ot_demo_day', key, 'OUTPUT_NULL') FROM ot_demo_day;
SELECT GET_DATA_FROM_OSS('<project_name>.default.ot_demo_day', key, 0, 'OUTPUT_NULL') FROM ot_demo_day;クエリ最適化によるパフォーマンス向上
デフォルトでは、MaxCompute SQL ステートメントでテーブルにアクセスする際、MaxCompute はレコード数、レコードのバイトサイズ、クォータ下で利用可能な合計コンピューティングリソースに基づいて均等なサイズのチャンクを作成します。これにより、異なるシャードに対して並列計算機能が提供され、並列タスクにおけるロングテール問題を効果的に制御し、全体的なクエリパフォーマンスを向上させます。
このチャンキング方法は、オブジェクトテーブルからオブジェクトのコンテンツをダウンロードしてインメモリ計算を行う必要がある SQL ステートメントには理想的ではありません。パフォーマンスが最適ではなく、I/O 操作がボトルネックになりやすく、ロングテール問題を引き起こす可能性があります。以下のケースを考えてみましょう。
key | size |
a0000.jpg | 10 MB |
a0001.jpg | 10 MB |
a0002.jpg | 10 MB |
... | ... |
a1022.jpg | 10 MB |
a1023.jpg | 10 MB |
b.avi | 10 GB |
ワーカーリソースが 2 つしか利用できないと仮定します。標準の内部テーブルと同様に、行数またはレコードバイト数に基づいてチャンクを作成すると、split1 ([a0000.jpg ~ a0511.jpg]) と split2 ([a0512.jpg ~ a1023.jpg, b.avi]) の 2 つの split オブジェクトが作成される可能性があります。split1 のダウンロードする実際のデータ量は 10 MB × 512 = 5 GB です。split2 のデータ量は 5 GB + 10 GB = 15 GB です。split2 の計算負荷は split1 よりも大幅に高いため、深刻なロングテール問題が発生します。
より論理的なアプローチは、SQL ステートメントでオブジェクトをダウンロードする必要がある場合、実際のオブジェクトサイズに基づいてチャンクを作成することです。これにより、ロングテール問題を制御できます。OSS オブジェクトデータを消費するロジックがより時間がかかる場合は、より柔軟なチャンキング機能が必要です。上記のケースでは、split1 ([a0000.jpg ~ a1023.jpg]) と split2 ([b.avi]) の 2 つの split を作成できます。両方の split のダウンロード量は 10 GB です。
MaxCompute オブジェクトテーブルはこの機能を提供し、デフォルトで実際のオブジェクトサイズに基づいてチャンクを作成します。デフォルト値は 1 GB です。必要に応じて、KB、MB、GB の粒度でこの値を調整できます。
# デフォルト値は 1 GB です。調整できます。
SET odps.sql.object.table.split.unit.gb = 1;
SELECT get_data_from_oss('project.default.ot_demo_day', key) FROM ot_demo_da WHERE ...
# または、MB 単位で制御できます。これは GB パラメーターより優先度が高くなります。
SET odps.sql.object.table.split.unit.mb = 1;
SELECT get_data_from_oss('project.default.ot_demo_day', key) FROM ot_demo_da WHERE ...
# または、KB 単位で制御できます。これは GB および MB パラメーターより優先度が高くなります。
SET odps.sql.object.table.split.unit.kb = 1;
SELECT get_data_from_oss('project.default.ot_demo_day', key) FROM ot_demo_da WHERE ...場合によっては、このクエリ最適化ソリューションを無効にしたいことがあります。このソリューションは 2 つのジョブを開始します。最初のジョブは前処理を実行し、その情報は Logview で確認できます。MaxCompute オブジェクトテーブルはこれを行う方法を提供します。
SET odps.sql.object.table.split.by.object.size.enabled = false;
SELECT get_data_from_oss('project.default.ot_demo_day', key) FROM ot_demo_day WHERE ...OBJECT TABLE メタデータのクリア
構文
TRUNCATE TABLE <object_table_name>;パラメーター
object_table_name: 必須。テーブル名。
例
TRUNCATE TABLE ot_demo_day;オブジェクトテーブルの名前変更
構文
ALTER TABLE <object_table_name> RENAME TO <new_object_table_name>;パラメーター
object_table_name: 必須。元のテーブル名。
new_object_table_name: 必須。新しいテーブル名。
例
ALTER TABLE ot_demo_day RENAME TO new_ot_demo_day;OBJECT TABLE の削除
オブジェクトテーブルはメタデータをキャッシュするため、ストレージスペースを消費し、ストレージコストが発生します。ビジネスでこのキャッシュデータが不要になった場合は、オブジェクトテーブルを削除できます。後で再度データを使用する必要がある場合は、オブジェクトテーブルを再作成できます。
構文
DROP TABLE [IF EXISTS] <object_table_name>; パラメーター
object_table_name: 必須。テーブル名。
例
DROP TABLE IF EXISTS ot_demo_day;よくある質問
ODPS-0010000:System internal error
症状
以下のエラーメッセージが返されます。
ODPS-0010000:System internal error - ActionHandler job failed with failinfo storage service worker error occured: common/io/oss/oss_file_system_cppsdk.cpp(919): OSSRequestException: Status: -50, RequestId: , ErrorCode: ClientError:-50, Message: E_HTTP_ERROR_CONN_REFUSED原因
オブジェクトテーブル作成時に OSS のパブリックエンドポイントが使用されました。
解決策
オブジェクトテーブルを作成する際、
locationパラメーター内のoss_endpointは内部ネットワークアドレスである必要があります。アドレスの取得方法の詳細については、「パラメーター」をご参照ください。
定期リフレッシュが失敗する
症状
オブジェクトテーブル作成時に定期リフレッシュのパラメーターを設定しましたが、リフレッシュ期間に達してもリフレッシュが実行されません。
解決策
オブジェクトテーブルに設定された location パラメーターの値が OSS の内部ネットワークドメイン名であるかどうかを確認してください。オブジェクトテーブルの作成方法の詳細については、「パラメーター」をご参照ください。
定期リフレッシュタスクでエラーが発生する
エラーメッセージ
FAILED: ODPS-0010000:System internal error - ActionHandler job failed with failinfo storage service worker error occured: common/io/oss/oss_file_system_cppsdk.cpp(877): OSSRequestException: Status: -50, RequestId: , ErrorCode: ClientError:-50, Message:
解決策
これは内部エラーです。チケットを送信して MaxCompute テクニカルサポートチームにお問い合わせください。