MaxCompute は OBJECT TABLE 機能を導入しました。この機能により、データウェアハウスのコンピュートエンジンは、データレイクストレージ内の非構造化データとそのメタデータにアクセスできます。このトピックでは、OBJECT TABLE のコマンド構文について説明し、例を示します。
背景情報
多くの AI プロセスでは、データとビジネス運用に精通したデータウェアハウス開発者が必要です。これらの開発者は、ビッグデータプラットフォームの低コストで大規模な計算能力を利用して、大規模モデルのデータを前処理したり、非構造化データを処理したりします。これらのプロセスとその結果は、データウェアハウスまたはデータレイク内のデータと相互作用します。
SQL を使用して非構造化データを処理するには、次の課題があります。
ビッグデータ SQL エンジンは、Object Storage Service (OSS) からファイルを読み取る際にオブジェクトサイズを認識しません。これにより、実行計画の最適化、同時実行性の制御、または適切な数の同時タスクの自動開始が困難になります。さらに、フィルター条件を効果的にプッシュダウンできません。これにより、データスキューが発生した場合に計算能力を十分に活用できなくなります。
Object Storage Service からのメタデータの読み取りは非効率です。各クエリではストレージサービスへのリモートアクセスが必要となり、高いレイテンシーが発生します。
Object Storage Service (OSS) からのファイルリストは、ユーザー定義のテーブル値関数 (UDTF) 内の単一プロセスでシリアルにしか取得できません。これにより、データ読み取りパフォーマンスが低下します。
ストレージサービスへの権限とネットワーク接続を処理するロジックは、ユーザー定義関数 (UDF) 内に実装する必要があります。
UDF は、非構造化データを処理する機能が限られています。従来のデータウェアハウスには、カスタムイメージを柔軟かつ安全にアップロードする方法がありません。また、UDF のための安全なランタイム環境もありません。さらに、リモート呼び出しには、分散コンピューティングサービスとの同時統合が必要です。
機能
MaxCompute は OBJECT TABLE 機能を導入しました。この機能により、データウェアハウスのコンピュートエンジンは、データレイクストレージ内の非構造化データとそのメタデータにアクセスできます。次の機能を提供します:
エンジンが OSS オブジェクトのメタデータをテーブルとして読み取ることを許可します。
メタデータテーブル機能に基づいて、さまざまな種類の OSS オブジェクトのメタデータをバージョン管理された方法でキャッシュします。SQL エンジンは、メタデータテーブルを使用して、データフィルタリングや条件プッシュダウンなどの効果的なクエリ最適化を実行できます。
組み込みのドキュメント関数を使用して、複数の方法で非構造化データファイルの内容を読み取ることができます。
MaxCompute SQL エンジンは、OBJECT TABLE のメタデータを使用して同時チャンキングを実行します。これにより、大規模な分散コンピューティングが可能になり、データ読み取りと処理の効率が向上します。
カスタムイメージをアップロードして UDF を構築し、エンジンによって読み取られた非構造化データを処理することをサポートします。
エンジンが非構造化データを処理し、構造化データの結果を生成し、それらをデータウェアハウスの内部テーブルおよび外部テーブルに書き込むことを許可します。また、非構造化データの結果を生成し、OBJECT TABLE を介して Object Storage Service に書き戻すこともサポートする予定です。
Python エコシステム向けの Maxframe エンジンをサポートします。
制限事項
MaxCompute プロジェクトは Schema 機能をサポートする必要があります。詳細については、「Schema 機能の有効化」をご参照ください。
MaxCompute は 2.0 データ型システムをサポートする必要があります。
OBJECT TABLE はパーティションをサポートしていません。
課金
OBJECT TABLE は、OSS からのオブジェクトのメタデータのコレクションです。OBJECT TABLE でリフレッシュおよび保存されるメタデータに対してストレージ料金が課金されます。詳細については、「ストレージ料金」をご参照ください。OSS 上のファイルは MaxCompute 内に保存されないため、MaxCompute はストレージ料金を請求しません。OSS はデータストレージとアクセスに対して課金します。詳細については、「OSS ストレージ料金」をご参照ください。
OSS のメタデータを抽出してリフレッシュするタスクでは、スキャンされる各ファイルの
inputsizeは、実際のファイルサイズではなく、メタデータに関連する値です。したがって、リフレッシュタスクの総コストは、OSS 上のファイルの実際のサイズではなく、ファイルの数に関連します。詳細については、「」外部テーブルの SQL 課金をご参照ください。OBJECT TABLE とそのメタデータを使用して OSS からの非構造化データを分析、抽出し、処理すると、コンピューティング料金が発生します。
従量課金モードでは、OBJECT TABLE でのメタデータ分析は内部テーブルとして課金されます。詳細については、「」標準 SQL 課金をご参照ください。OSS からの非構造化データの内容の処理は、外部テーブルとして課金されます。詳細については、「」外部テーブルの SQL 課金をご参照ください。
サブスクリプションモードでは、サブスクリプションのコンピューティングリソースが使用されます。詳細については、「コンピューティング料金 (サブスクリプション)」をご参照ください。
OBJECT TABLE の作成
構文
CREATE OBJECT TABLE [IF NOT EXISTS] <objecttable_name>
WITH SERDEPROPERTIES ('<key>' = '<value>')
LOCATION '<location>'
[TBLPROPERTIES ('<key>' = '<value>')]
[COMMENT '<comment>']
;OBJECT TABLE は、Schema モードをサポートするプロジェクトで使用する必要があり、Schema 構文スイッチを有効にする必要があります。
OBJECT TABLE の列を定義する必要はありません。システムがメタデータ列を提供します。
パラメーター
パラメーター | 必須 | 説明 |
objecttable_name | 必須。 | テーブル名。 |
SERDEPROPERTIES ('<key>'='<value>') | 必須。 | 認証用の RAM ロールを指定します。このパラメーターを指定しない場合、デフォルトで現在の Alibaba Cloud アカウント下の 例: ロールを使用する前に、
説明 ワンクリック権限付与は、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 | OBJECT TABLE 内のオブジェクトの相対パス名。 |
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 のメタデータのリフレッシュ
OBJECT TABLE の実際のオブジェクトデータは OSS に保存されます。MaxCompute はこれらのオブジェクトのメタデータをキャッシュし、キャッシュされたメタデータに基づいてクエリと計算を実行します。したがって、OBJECT TABLE を使用する前に、そのキャッシュをリフレッシュする必要があります。キャッシュは手動でリフレッシュするか、テーブル作成時に定期的なリフレッシュを設定できます。
手動リフレッシュと定期リフレッシュはどちらも完全更新です。
手動リフレッシュ
各リフレッシュは完全なメタデータ同期です。リフレッシュのタイミングと頻度を制御できます。
構文
ALTER TABLE <objecttable_name> REFRESH METADATA;パラメーター
objecttable_name:必須。テーブル名。
例
ALTER TABLE ot_demo_day REFRESH METADATA;
定期リフレッシュ
OBJECT TABLE にマッピングされている 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:リフレッシュは定期的にトリガーされます。manual:リフレッシュは手動でトリガーされます (デフォルト)。トリガーのタイミングを制御できます。
リフレッシュタスクの表示
次のコマンドを使用して、過去のリフレッシュタスクのステータスを表示できます。
SHOW refresh task history FOR object TABLE <object_table_name>;パラメーター
<object_table_name> は OBJECT TABLE である必要があります。
戻り値:コマンドは、各リフレッシュタスクのインスタンス ID (InstanceId)、開始時刻 (CreateTime)、終了時刻 (EndTime)、およびステータス (Status) を返します。
ステータスが Failed の場合は、
wait InstanceId;を実行してからログビューを印刷してエラーの詳細を確認できます。
例
-- OBJECT TABLE の過去のリフレッシュタスクを表示します。 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 のクエリ
OBJECT TABLE は、OSS ディレクトリ内のファイルのメタデータを取得します。OBJECT TABLE をクエリして、このメタデータを表示できます。また、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 にアクセスするためのセキュリティトークンサービス (STS) トークンを自動的に生成するのに役立ちます。 | なし |
key | はい | STRING | OBJECT TABLE 内のアクセスされるオブジェクトの名前。「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
OBJECT TABLE のすべてのコンテンツを読み取り、バイナリ値として返します。OBJECT TABLE の完全なパスは <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 はレコード数、レコードのバイトサイズ、およびクォータ下で利用可能な総コンピューティングリソースに基づいて、均等なサイズのチャンクを作成します。これにより、さまざまなシャードに対して並列計算機能が提供され、並列タスクのロングテール問題を効果的に制御し、全体的なクエリパフォーマンスを向上させます。
このチャンキング方法は、メモリ内での計算のために OBJECT TABLE からオブジェクトのコンテンツをダウンロードする必要がある 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 つしかないと仮定します。標準の内部テーブルのように行数またはレコードバイトに基づいてチャンクが作成される場合、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 よりも大幅に高くなり、深刻なロングテール問題を引き起こします。
より論理的なアプローチは、SQL 文がオブジェクトをダウンロードする必要がある場合に、オブジェクトの実際のサイズに基づいてチャンクを作成することです。これにより、ロングテール問題を制御できます。OSS オブジェクトデータを消費するロジックがより時間のかかるものである場合、より柔軟なチャンキング機能が必要です。前述のケースでは、2つのスプリットを作成できます:split1 ([a0000.jpg から a1023.jpg]) と split2 ([b.avi])。両方のスプリットのダウンロード量は 10 GB です。
MaxCompute OBJECT TABLE はこの機能を提供し、デフォルトで実際のオブジェクトサイズに基づいてチャンクを作成します。デフォルト値は 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 OBJECT TABLE は、これを行う方法を提供します:
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 の削除
OBJECT TABLE はメタデータをキャッシュし、ストレージスペースを消費し、ストレージコストが発生します。ビジネスでこのキャッシュデータが不要になった場合は、OBJECT TABLE を削除できます。後でデータを再度使用するには、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原因
OBJECT TABLE の作成時に OSS のパブリックエンドポイントが使用されました。
ソリューション
OBJECT TABLE を作成する際、
locationパラメーターのoss_endpointは内部ネットワークアドレスである必要があります。アドレスの取得方法については、「パラメーター」をご参照ください。
定期リフレッシュの失敗
症状
OBJECT TABLE の作成時に定期リフレッシュのパラメーターを設定しました。しかし、リフレッシュ期間になってもリフレッシュが行われません。
ソリューション
OBJECT TABLE に設定された `location` パラメーターの値が OSS の内部ネットワークドメイン名であるか確認してください。OBJECT TABLE の作成方法の詳細については、「パラメーター」をご参照ください。
定期リフレッシュタスクのエラー報告
エラーメッセージ
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 技術サポートチームに連絡してください。