MaxCompute は、データウェアハウスのコンピュートエンジンがデータレイクストレージ内の非構造化データとそのメタデータにアクセスできるようにするオブジェクトテーブル機能を導入しました。このトピックでは、コマンドの構文と使用例について説明します。
背景情報
多くの AI ワークフローでは、データとビジネスロジックに精通したデータウェアハウス開発者が、大規模モデルのために非構造化データを前処理または処理する必要があります。これらのタスクでは、ビッグデータプラットフォームの低コストで大規模なコンピューティング能力が活用されます。そのプロセスと結果は、多くの場合、データウェアハウスやデータレイク内のデータと相互作用します。
SQL を使用して非構造化データを処理する際には、いくつかの課題があります:
オブジェクトストレージから読み取る際、ビッグデータ SQL エンジンはオブジェクトサイズを特定できないため、実行計画の最適化が複雑になり、適切な同時実行数を制御したり、起動したりすることが困難になります。効果的な述語プッシュダウンがない場合、特にデータスキューが発生すると、コンピューティング能力を十分に活用できません。
オブジェクトストレージからメタデータを読み取ると、各クエリがストレージサービスへのリモートコールを必要とするため、高いレイテンシーが発生します。
オブジェクトストレージからのファイルリストは、ユーザー定義テーブル関数 (UDTF) 内の単一プロセスでシリアルにしか取得できないため、データ読み取り性能が低下します。
ストレージサービスに接続するには、ユーザー定義関数 (UDF) 内で権限付与とネットワーク接続のロジックを実装する必要があります。
従来のデータウェアハウスは、カスタムイメージを安全にアップロードする機能や、UDF のための安全な実行環境を提供していません。さらに、リモートコールには分散コンピューティングサービスとの複雑な同時実行管理が必要です。
特徴
MaxCompute は、データウェアハウスのコンピュートエンジンがデータレイクストレージ内の非構造化データとそのメタデータにアクセスできるようにするオブジェクトテーブル機能を導入しました。この機能は、以下の能力を提供します:
エンジンが OSS ファイルのメタデータをテーブルとして読み取れるようになります。
メタデータテーブルを活用して、OSS ファイルのバージョン管理されたメタデータをキャッシュします。SQL エンジンは、このメタデータをデータフィルタリングや述語プッシュダウンなどのクエリ最適化に使用できます。
さまざまな方法で非構造化データファイルの内容を読み取るためのビルトイン関数を提供します。
MaxCompute SQL エンジンがオブジェクトテーブルのメタデータに基づいて同時スプリットを作成できるようにし、大規模な分散コンピューティングを解放してデータ読み取りと処理の効率を向上させます。
カスタムイメージをアップロードして、エンジンが読み取った非構造化データを処理する UDF を構築できます。
非構造化データを処理して構造化された結果を生成し、それをデータウェアハウスの内部テーブルまたは外部テーブルに書き込むことをサポートします。将来のバージョンでは、非構造化された結果を生成し、オブジェクトテーブルを介して OSS に書き戻すこともサポートする予定です。
Python エコシステムの Maxframe エンジンをサポートします。
制限事項
MaxCompute プロジェクトでスキーマが有効になっている必要があります。詳細については、「スキーマの有効化」をご参照ください。
MaxCompute は Type System 2.0 をサポートしている必要があります。
オブジェクトテーブルは現在、パーティションをサポートしていません。
課金
オブジェクトテーブルは、OSS 内のファイルのメタデータのコレクションを格納します。オブジェクトテーブルにリフレッシュされて格納されたメタデータに対してストレージ料金が課金されます。詳細については、「ストレージ料金」をご参照ください。OSS からのファイルは MaxCompute 内に格納されないため、MaxCompute はそのストレージに対して課金しません。OSS はデータの格納とアクセスに対して課金します。詳細については、「OSS ストレージ料金」をご参照ください。
OSS メタデータを抽出してリフレッシュするタスクの場合、スキャンされる各ファイルの
inputsizeは、実際のファイルサイズではなく、そのメタデータサイズに基づきます。したがって、リフレッシュジョブの総コストは、ファイルの合計サイズではなく、ファイルの数に依存します。詳細については、「」外部テーブルの SQL 課金をご参照ください。オブジェクトテーブルとそのメタデータを使用して OSS から非構造化データを分析および抽出する場合、コンピューティング料金が発生します。
従量課金サブスクリプションでは、オブジェクトテーブルのメタデータの分析は内部テーブルと同じ方法で課金されます。詳細については、「」標準 SQL 課金をご参照ください。OSS からの非構造化データの内容の処理は、外部テーブルとして課金されます。詳細については、「」外部テーブルの SQL 課金をご参照ください。
サブスクリプション課金プランでは、前払いのサブスクリプションリソースを使用します。詳細については、「コンピューティング料金 (サブスクリプション)」をご参照ください。
オブジェクトテーブルの作成
構文
CREATE OBJECT TABLE [IF NOT EXISTS] <objecttable_name>
WITH SERDEPROPERTIES ('<key>' = '<value>')
LOCATION '<location>'
[TBLPROPERTIES ('<key>' = '<value>')]
[COMMENT '<comment>']
;オブジェクトテーブルは、スキーマが有効になっているプロジェクトで使用する必要があり、スキーマ構文スイッチをオンにする必要があります。
オブジェクトテーブルのメタデータ列はシステムによって提供されるため、列を定義する必要はありません。
パラメーター
パラメーター | 必須 | 説明 |
objecttable_name | はい | テーブルの名前。 |
SERDEPROPERTIES ('<key>'='<value>') | はい | シリアライザー/デシリアライザー (SerDe) のプロパティを指定します。 例: この機能を使用する前に、
説明 ワンクリック認可は、MaxCompute プロジェクトの所有者と OSS アカウントの所有者が同じ場合にのみ可能です。 |
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/';オブジェクトテーブルのプロパティの表示
構文
DESC <object_table_name>パラメーター
object_table_name:必須。テーブルの名前。
例
SET odps.namespace.schema=true;
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) OSS での長さの制約は 1,023 文字です。 詳細については、「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 は、オブジェクトに対して生成されるエンティティタグです。更新間でオブジェクトの内容が変更されたかどうかを識別しますが、一意の識別子ではありません。 |
restore_info | VARCHAR(256) | True | オブジェクトがコールドストレージから解凍されたかどうかを示します。オブジェクトが解凍中の場合、この列は関連情報を提供します。 |
owner_id | BIGINT | True | オブジェクトの所有者の ID。 |
owner_display_name | VARCHAR(256) | True | オブジェクトの所有者の表示名。 |
CREATE TABLE 文の表示
構文
SHOW CREATE TABLE <object_table_name>;パラメーター
object_table_name:必須。テーブルの名前。
例
SET odps.namespace.schema=true;
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');オブジェクトテーブルのメタデータのリフレッシュ
オブジェクトテーブルの実際のデータは OSS に格納されます。MaxCompute はこれらのオブジェクトのメタデータをキャッシュし、このキャッシュされたメタデータをクエリや計算に使用します。したがって、オブジェクトテーブルを使用する前にキャッシュをリフレッシュする必要があります。メタデータは手動でリフレッシュするか、テーブル作成時に定期的なリフレッシュを設定できます。
手動リフレッシュと定期的リフレッシュはどちらも完全更新です。
手動リフレッシュ
各リフレッシュはメタデータの完全な同期を実行します。これらのリフレッシュのタイミングと頻度を制御できます。
構文
ALTER TABLE <objecttable_name> REFRESH METADATA;パラメーター
objecttable_name:必須。テーブルの名前。
例
SET odps.namespace.schema=true; 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:更新モード。利用可能なオプションは次のとおりです: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分、14時 (午後 2 時)、毎日、毎月、そして?は曜日を指定しない (競合を避けるために月の日フィールドと相互排他的) ことを意味します。metadata.cache.mode:更新モード。利用可能なオプションは次のとおりです:crontab:スケジュールされたリフレッシュ。periodic:定期的トリガー。manual:手動トリガー (デフォルト)。トリガーのタイミングを制御できます。
リフレッシュタスクの表示
次のコマンドを実行して、リフレッシュタスクの履歴を表示できます。
SHOW refresh task history FOR object TABLE <object_table_name>;パラメーター
<object_table_name> はオブジェクトテーブルでなければなりません。
戻り値:リフレッシュタスクのインスタンス ID (InstanceId)、作成時刻 (CreateTime)、終了時刻 (EndTime)、およびステータス (Status)。
ステータスが Failed の場合は、
wait InstanceId;を実行してログを表示し、エラーの詳細を確認できます。
例
-- オブジェクトテーブルの履歴リフレッシュタスクを表示します。 SET odps.namespace.schema=true; 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
オブジェクトテーブルのクエリ
オブジェクトテーブルが OSS ディレクトリからファイルのメタデータをフェッチした後、テーブルをクエリしてこのメタデータを閲覧できます。また、SQL ステートメントを使用して、フィルタリング、マッチング、集約、結合、ウィンドウ関数、ORDER BY、LIMIT などの計算をメタデータに対して実行することもできます。
構文
SELECT * FROM <object_table_name>;パラメーター
object_table_name:必須。テーブルの名前。
例
-- 指定された OSS ディレクトリにアップロードされたデータをクエリできます。データ量が多い場合は、結果を 5 行に制限できます。
SET odps.namespace.schema=true;
SELECT * FROM ot_demo_day [limit 5];バイナリデータのクエリ
オブジェクトテーブル内のオブジェクトのバイナリデータは、次の 2 つの方法のいずれかでクエリできます:
_data 列
_data列は、イメージのバイナリ ストリームなど、オブジェクトの完全なバイナリデータを返します。そのデータ型は BINARY です。メモリ不足エラーを避けるため、単一オブジェクトのバイナリデータは大きすぎないようにしてください。次のサンプルコードは、この列の使用方法を示しています:
SET odps.namespace.schema=true; SELECT _data FROM test_ot1;_blob 列
_blob列は、バイナリデータ自体ではなく、バイナリデータをダウンロードするための一時的な認証情報を返します。_blob列は、_data列よりも計算の安定性が高く、リソース消費が少ないです。平均的に小さいオブジェクト (1 MB 未満) には_data列を直接使用し、大きいオブジェクトには_blob列を使用することを推奨します。使用方法は次のとおりです:SET odps.namespace.schema=true; SELECT _blob FROM test_ot1;
例
_data 列
テストファイルをダウンロードして OSS にアップロードします: ot_test.txt
オブジェクトテーブルを作成します。
SET odps.namespace.schema=true; SET odps.sql.type.system.odps2=true; SET odps.mcqa.disable=TRUE; DROP TABLE IF EXISTS test_ot1; CREATE OBJECT TABLE test_ot1 LOCATION 'oss://oss-cn-<region>-internal.aliyuncs.com/<bucket name>/<file path>/'; -- テーブルキャッシュをリフレッシュします。 ALTER TABLE test_ot1 REFRESH METADATA; SET odps.mcqa.disable=TRUE; SET odps.namespace.schema=true; SELECT * FROM test_ot1; -- 次の結果が返されます: +------+------------+------+---------------+---------------+------+--------------+------------+--------------------+ | key | size | type | last_modified | storage_class | etag | restore_info | owner_id | owner_display_name | +------+------------+------+---------------+---------------+------+--------------+------------+--------------------+ | ot_test.txt | 286 |Normal|2026-07-21 06:49:59| Standard | 3*01 | NONE | 1***279014 | 1***279014 | +------+------------+------+---------------+---------------+------+--------------+------------+--------------------+_data列を読み取ります。SET odps.namespace.schema=true; SELECT _data FROM test_ot1; -- 次の結果が返されます: +-------+ | _data | +-------+ | {=0A=20=20"id":=20**1,=0A=20=20"title":=20"Hello=20World",=0A=20=20"description":=20"=E8=BF**E4=BE=8B=20JSON=20=**82",=0A=20=20"tags":=20[=0A*=20"=E7**=8B",=0A=20=20=20=20"JSON",=0A=20=20=20=20"Example"=0A=20=20],=0A=20=20"metadata":=20{=0A=20=20=20=20"author":=20"AI=20Assistant",=0A=20=20=20=20"created_at":=20"2023-10-01T12:00:00Z",=0A=20=20=20=20"is_active":=20true=0A=20=20}=0A} | +-------+テキストコンテンツを表示します。
SET odps.namespace.schema=true; SELECT CAST(_data AS STRING) FROM test_ot1; -- 次の結果が返されます: +-----+ | _c0 | +-----+ | { "id": 1001, "title": "Hello World", "description": "This is sample JSON data that contains both Chinese and English.", "tags": [ "Programming", "JSON", "Example" ], "metadata": { "author": "AI Assistant", "created_at": "2023-10-01T12:00:00Z", "is_active": true } } | +-----+
_blob 列
テストファイルをダウンロードして OSS にアップロードします: ot_test.txt
オブジェクトテーブルを作成します。
SET odps.namespace.schema=true; SET odps.sql.type.system.odps2=true; SET odps.mcqa.disable=TRUE; DROP TABLE IF EXISTS test_ot1; CREATE OBJECT TABLE test_ot1 LOCATION 'oss://oss-cn-<region>-internal.aliyuncs.com/<bucket name>/<file path>/'; -- テーブルキャッシュをリフレッシュします。 ALTER TABLE test_ot1 REFRESH METADATA; SET odps.mcqa.disable=TRUE; SET odps.namespace.schema=true; SELECT * FROM test_ot1; -- 次の結果が返されます: +------+------------+------+---------------+---------------+------+--------------+------------+--------------------+ | key | size | type | last_modified | storage_class | etag | restore_info | owner_id | owner_display_name | +------+------------+------+---------------+---------------+------+--------------+------------+--------------------+ | ot_test.txt | 286 |Normal|2026-07-21 06:49:59| Standard | 3*01 | NONE | 1***279014 | 1***279014 | +------+------------+------+---------------+---------------+------+--------------+------------+--------------------+_blob列を読み取ります。SET odps.namespace.schema=true; SELECT _blob FROM test_ot1; -- 次の結果が返されます: +-------+ | _blob | +-------+ | CAEQAxruAgEAAAANA**AAEb2svMjAy3CIAKhR5WVBc/0S4GmxSm4psPJ5CV3k4STIeCgl***FyYTQ1ZXEx | +-------+テキストコンテンツを表示します。
SET odps.namespace.schema=true; SELECT CAST(read_blob(_blob) AS STRING) FROM test_ot1; -- 次の結果が返されます: +-----+ | _c0 | +-----+ | { "id": 1001, "title": "Hello World", "description": "This is sample JSON data that contains both Chinese and English.", "tags": [ "Programming", "JSON", "Example" ], "metadata": { "author": "AI Assistant", "created_at": "2023-10-01T12:00:00Z", "is_active": true } } | +-----+
オブジェクトコンテンツのクエリ
デフォルトでは、クエリはオブジェクトのメタデータのみを計算し、オブジェクトのコンテンツは読み取りません。しかし、実際の計算ではオブジェクトの実際のコンテンツが必要になることがよくあります。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>]
)パラメーター
パラメーター | 必須 | データの型 | 説明 | デフォルト |
| はい | STRING | 3 層モデルにおける OBJECT TABLE への完全なパス。Project 名と Schema 名を含みます。例: | なし |
| はい | STRING | オブジェクトテーブル内の OSS オブジェクトのオブジェクトキー (名前)。正確な値については、「OBJECT TABLE のプロパティの表示」の | なし |
| いいえ | BIGINT | 読み取りを開始するバイト位置。>= 0 である必要があります。 |
|
| いいえ | BIGINT | 読み取るバイト数。 |
|
| いいえ | STRING | オブジェクトキーがメタデータキャッシュに存在するが、オブジェクトが OSS から削除されている場合の動作。有効な値については、以下の表をご参照ください。 |
|
例 1
GET_DATA_FROM_OSS は BINARY を返します。コンテンツをテキストとして扱うには、STRING() 関数でラップします。
SET odps.namespace.schema=true;
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 の全コンテンツを読み取ります。6 つの形式はすべて同等です — それぞれ offset を 0、length を -1、object_not_found_policy を OUTPUT_NULL にデフォルト設定します。
SET odps.namespace.schema=true;
-- すべてのパラメーターを明示的に指定した完全な形式
SELECT GET_DATA_FROM_OSS('<project_name>.default.ot_demo_day', key, 0, -1, 'OUTPUT_NULL') FROM ot_demo_day;
-- 以下のステートメントは上記と同等です
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 クエリでテーブルにアクセスすると、システムはレコード数、バイト単位のサイズ、および利用可能な総コンピューティングリソース (クォータによって制限) に基づいて均一なデータスプリットを作成します。このアプローチにより、異なるスプリットの並列処理が可能になり、ロングテール問題を効果的に軽減し、全体的なクエリパフォーマンスを向上させます。
しかし、この分割方法は、インメモリ計算のためにオブジェクトテーブルからオブジェクトコンテンツをダウンロードする必要がある SQL クエリには最適ではありません。このような場合、I/O 操作が容易にボトルネックとなり、ロングテール問題を引き起こす可能性があります。次のシナリオを考えてみましょう:
キー | サイズ |
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 つしかないと仮定します。標準の内部テーブルのように行数やレコードバイトに基づいてスプリットが作成される場合、システムは 2 つの split を作成する可能性があります:split1 ([a0000.jpg ~ a0511.jpg]) と split2 ([a0512.jpg ~ a1023.jpg, b.avi])。split1 のダウンロードデータ量は 10 MB * 512 = 5 GB であり、split2 のデータ量は 5 GB + 10 GB = 15 GB です。その結果、split2 の計算負荷は split1 よりも大幅に高くなり、深刻なロングテール問題を引き起こします。
より論理的なアプローチは、オブジェクトをダウンロードするクエリに対して、オブジェクトの実際のサイズに基づいてスプリットを作成することです。この戦略はロングテール問題を最小限に抑えます。OSS オブジェクトデータを消費するロジックがさらに時間のかかるものである場合、柔軟な分割機能が重要です。上記のシナリオでは、より良いアプローチは 2 つのスプリットを作成することです:split1 に [a0000.jpg ~ a1023.jpg]、split2 に [b.avi] を含めます。この場合、両方のスプリットのダウンロードサイズは 10 GB です。
これをサポートするため、デフォルトでは、MaxCompute オブジェクトテーブルはオブジェクトの実際のサイズに基づいてタスクを分割します。デフォルトのスプリットサイズは 1 GB ですが、必要に応じて KB、MB、または GB レベルに調整できます。
SET odps.namespace.schema=true;
-- デフォルトは 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 レベルでスプリットサイズを制御することもでき、これが最も高い優先度を持ちます。
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.namespace.schema=true;
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 ...オブジェクトテーブルの削除
オブジェクトテーブルはユーザーメタデータをキャッシュし、ストレージを消費してコストが発生します。キャッシュされたデータが不要になった場合は、オブジェクトテーブルを削除できます。後で必要になった場合は、オブジェクトテーブルを再作成できます。
構文
DROP TABLE [IF EXISTS] <object_table_name>; パラメーター
object_table_name:必須。テーブルの名前。
例
SET odps.namespace.schema=true;
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の内部エンドポイントを含める必要があります。内部エンドポイントの取得方法については、「パラメーターの説明」をご参照ください。アドレスを内部エンドポイントに変更してもエラーが解決しない場合は、チケットを送信して MaxCompute テクニカルサポートチームにお問い合わせください。
定期的リフレッシュの失敗
症状
オブジェクトテーブルを作成する際に定期的なリフレッシュパラメーターを設定しましたが、間隔に達してもリフレッシュが実行されません。
ソリューション
オブジェクトテーブルの作成に使用した location パラメーターが OSS の内部エンドポイントを指定していることを確認してください。オブジェクトテーブルの作成に関する詳細については、「パラメーター」をご参照ください。