All Products
Search
Document Center

MaxCompute:Object table definition

Last Updated:Aug 28, 2026

MaxCompute introduces the object table feature, which enables the data warehouse compute engine to access unstructured data and its metadata in data lake storage. This topic describes the command syntax and provides usage examples.

Background

In many AI workflows, data warehouse developers who are familiar with the data and business logic must preprocess or process unstructured data for large models. These tasks leverage the low-cost, large-scale computing power of big data platforms. The processes and their results often interact with data in the data warehouse or data lake.

Using SQL to process unstructured data presents several challenges:

  • When reading from object storage, big data SQL engines cannot determine object sizes, which complicates execution plan optimization and makes it difficult to control concurrency or launch an appropriate number of concurrent tasks. Without effective predicate pushdown, the computing power cannot be fully utilized, especially in cases of data skew.

  • Reading metadata from object storage introduces high latency because each query requires a remote call to the storage service.

  • File lists from object storage can only be retrieved serially within a single process in a user-defined table function (UDTF), which results in poor data read performance.

  • You must implement authorization and network connectivity logic within user-defined functions (UDFs) to connect to storage services.

  • Traditional data warehouses do not provide features for securely uploading custom images or a safe execution environment for UDFs. Additionally, remote calls require complex concurrency management with the distributed computing service.

Features

MaxCompute introduces the object table feature, which enables the data warehouse compute engine to access unstructured data and its metadata in data lake storage. This feature provides the following capabilities:

  • Lets the engine read the metadata of OSS files as a table.

  • Leverages a metadata table to cache versioned metadata of OSS files. The SQL engine can then use this metadata for query optimizations, such as data filtering and predicate pushdown.

  • Provides built-in functions to read the content of unstructured data files in various ways.

  • Lets the MaxCompute SQL engine create concurrent splits based on object table metadata, unlocking large-scale distributed computing to improve data reading and processing efficiency.

  • Lets you upload a custom image to build UDFs that process unstructured data read by the engine.

  • Supports processing unstructured data to generate structured results and write them to internal or external tables in the data warehouse. Future versions will also support generating unstructured results and writing them back to OSS through object tables.

  • Supports the Maxframe engine from the Python ecosystem.

Limitations

  • The MaxCompute project must have schemas enabled. For more information, see Enable schema.

  • MaxCompute must support Type System 2.0.

  • Object tables do not currently support partitions.

Billing

  • An Object Table stores a collection of metadata for files in OSS. Storage fees are charged for the metadata that is refreshed and stored in the Object Table. For more information, see Storage pricing. Because the files from OSS are not stored within MaxCompute, MaxCompute does not charge for their storage. OSS charges for storing and accessing the data. For more information, see OSS storage pricing.

  • For tasks that extract and refresh OSS metadata, the inputsize for each scanned file is based on its metadata size, not its actual file size. Therefore, the total cost of the refresh job depends on the number of files, not their total size. For more information, see SQL billing for external tables.

  • You incur computing fees when you use an Object Table and its metadata to analyze and extract unstructured data from OSS.

    • In a pay-as-you-go subscription, analyzing Object Table metadata is billed in the same way as an internal table. For more information, see Standard SQL billing. Processing the content of unstructured data from OSS is billed as an external table. For more information, see SQL billing for external tables.

    • In a subscription billing plan, you use prepaid subscription resources. For more information, see Computing fees (subscription).

Create an Object Table

Syntax

CREATE OBJECT TABLE [IF NOT EXISTS] <objecttable_name> 
WITH SERDEPROPERTIES ('<key>' = '<value>') 
LOCATION '<location>' 
[TBLPROPERTIES ('<key>' = '<value>')] 
[COMMENT '<comment>'] 
;
Note
  • Object tables must be used in a project that has schemas enabled, and you must turn on the schema syntax switch.

  • You do not need to define columns for an Object Table because its metadata columns are system-provided.

Parameters

Parameter

Required

Description

objecttable_name

Yes

The name of the table.

SERDEPROPERTIES ('<key>'='<value>')

Yes

Specifies properties for the serializer-deserializer (SerDe). You can specify a RAM role for authorization by setting the odps.properties.rolearn key. If you omit this key, MaxCompute uses the AliyunODPSDefaultRole RAM role of the current Alibaba Cloud account to access OSS.

Example: 'odps.properties.rolearn'='acs:ram::uid:role/aliyunodpsdefaultrole'.

Before you use this feature, ensure that you have completed one-click authorization for AliyunODPSDefaultRole. This authorization allows the MaxCompute project to directly access OSS resources owned by the current cloud account through an STS token.

Note

One-click authorization is only possible if the MaxCompute project owner and the OSS account owner are the same.

location

Yes

  • The OSS path to which the Object Table maps. The format is oss://<oss_endpoint>/<bucket_name>/<oss_directory_name>/. For example, oss://oss-cn-hangzhou-internal.aliyuncs.com/odps-external-****/ottest/.

  • The Object Table extracts the metadata of files in the specified directory.

  • To obtain the oss_endpoint:

    • Log in to the OSS console.

    • On the Buckets page, click the target Bucket Name to open its Objects page.

    • In the Port area on the Overview page, obtain the Endpoint for Access from ECS over the Classic Network (internal network).

TBLPROPERTIES ('<key>'='<value>')

No

  • metadata.cache.mode: The cache refresh mode.

    • manual: Manual trigger (default).

    • periodic: Periodic trigger. This mode requires the metadata.staleness.seconds parameter to specify the refresh interval.

  • metadata.staleness.seconds: The refresh interval in seconds. The value can range from 1 to 604800 (1 second to 1 week). This parameter is a best-effort guarantee, and the scheduler attempts to execute the refresh as close to the specified interval as possible.

comment

No

A comment for the table.

Example

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

View Object Table properties

Syntax

DESC <object_table_name>

Parameters

object_table_name: Required. The name of the table.

Example

SET odps.namespace.schema=true; 
DESC ot_demo_day; 

The following result is returned:

+------------------------------------------------------------------------------------+
| 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.       |
+------------------------------------------------------------------------------------+

The following table describes key columns in the result.

Parameter

Type

Null allowed

Description

key

VARCHAR(2048)

The length constraint in OSS is 1,023 characters.

For more information, see OSS object naming rules and examples.

False

The relative path of the object within the Object Table.

size

BIGINT

False

The size of the object in bytes.

type

VARCHAR(32)

False

The type of the object in OSS: Normal, Multipart, Appendable, or Symlink.

last_modified

TIMESTAMP_NTZ

False

The time when the object's data was last modified in OSS.

storage_class

VARCHAR(32)

False

The storage class of the object in OSS. For a list of storage classes, see Storage classes.

etag

VARCHAR(64)

False

The ETag is an entity tag generated for an object. It identifies if an object's content has changed between updates, but it is not a unique identifier.

restore_info

VARCHAR(256)

True

Indicates whether an object has been restored from cold storage. If an object is being restored, this column provides relevant information.

owner_id

BIGINT

True

The ID of the object's owner.

owner_display_name

VARCHAR(256)

True

The display name of the object's owner.

View CREATE TABLE statement

Syntax

SHOW CREATE TABLE <object_table_name>;

Parameters

object_table_name: Required. The name of the table.

Example

SET odps.namespace.schema=true; 
SHOW CREATE TABLE ot_demo_day; 

The following result is returned:

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

Refresh Object Table metadata

The actual data for an Object Table is stored in OSS. MaxCompute caches the metadata of these objects and uses this cached metadata for queries and computations. Therefore, you must refresh the cache before using an Object Table. You can refresh metadata manually or configure periodic refreshes when you create the table.

Note

Both manual and periodic refreshes are full refreshes.

Manual refresh

Each refresh performs a full synchronization of the metadata. You can control the timing and frequency of these refreshes.

  • Syntax

    ALTER TABLE <objecttable_name> REFRESH METADATA;
  • Parameters

    objecttable_name: Required. The name of the table.

  • Example

    SET odps.namespace.schema=true; 
    ALTER TABLE ot_demo_day REFRESH METADATA;

Periodic refresh

If the files in the OSS directory that the Object Table maps to change frequently, you can configure periodic metadata refreshes. This reduces maintenance costs by specifying the relevant parameters when you create the table.

  • Syntax

    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'
    );
    
  • Parameters

    • metadata.staleness.seconds: The refresh interval. This parameter is required for the periodic mode. The value can range from [1, 604800], which represents a range from 1 second to 1 week. This parameter is a best-effort guarantee, and the scheduler will try to execute the refresh as close to the specified interval as possible.

    • metadata.cache.mode: The refresh mode. The available options are:

      • periodic: Periodic trigger.

      • crontab: Scheduled refresh.

      • manual: Manual trigger (default). You can control the trigger timing.

Scheduled refresh

If the files in the OSS directory that the Object Table maps to change frequently, you can schedule metadata refreshes. This reduces maintenance costs by specifying the relevant parameters when you create the table.

  • Syntax

    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'
    );
  • Parameters

    • metadata.crontab.expression: A cron expression that defines the schedule. For example, to trigger a refresh at 2:00 PM every day, you can use the expression 0 0 14 * * ?, which means 0 seconds, 0 minutes, hour 14 (2:00 PM), every day, every month, and ? to not specify a day of the week (mutually exclusive with the day-of-month field to avoid conflicts).

    • metadata.cache.mode: The refresh mode. The available options are:

      • crontab: Scheduled refresh.

      • periodic: Periodic trigger.

      • manual: Manual trigger (default). You can control the trigger timing.

View refresh tasks

You can run the following command to view the history of refresh tasks.

SHOW refresh task history FOR object TABLE <object_table_name>;
  • Parameters

    • <object_table_name> must be an object table.

    • Return values: The instance ID of the refresh task (InstanceId), the creation time (CreateTime), the end time (EndTime), and the status (Status).

    • If the Status is Failed, you can run wait InstanceId; to view the log and check for error details.

  • Example

    -- View the historical refresh tasks for the Object Table.
    SET odps.namespace.schema=true; 
    SHOW refresh task history for object table ot_demo_day04;
    
    -- The following result is returned.
    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

Querying Object Tables

After an Object Table fetches the metadata of files from an OSS directory, you can query the table to browse this metadata. You can also use SQL statements to perform calculations on the metadata, such as filtering, matching, aggregations, joins, window functions, ORDER BY, and LIMIT.

Syntax

SELECT * FROM <object_table_name>;

Parameters

object_table_name: Required. The name of the table.

Example

-- You can query the data uploaded to the specified OSS directory. If the amount of data is large, you can limit the result to five rows.
SET odps.namespace.schema=true; 
SELECT * FROM  ot_demo_day [limit 5];

Delete an Object Table

An Object Table caches user metadata, which consumes storage and incurs costs. If you no longer need the cached data, you can delete the Object Table. You can recreate the Object Table later if needed.

Syntax

DROP TABLE [IF EXISTS] <object_table_name>; 

Parameters

object_table_name: Required. The name of the table.

Example

SET odps.namespace.schema=true; 
DROP TABLE IF EXISTS ot_demo_day;

FAQ

ODPS-0010000:System internal error

  • Symptom

    The following error message is reported:

    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
  • Cause

    You used a public endpoint for OSS when creating the Object Table.

  • Solution

    When you create an Object Table, the location parameter must contain an internal endpoint for the oss_endpoint. For information about how to obtain the internal endpoint, see Parameter description. If the error persists after you change the address to an internal endpoint, contact the MaxCompute technical support team by submitting a ticket for support.

Periodic refresh fails

  • Symptom

You set periodic refresh parameters when you created the Object Table. However, the refresh does not run when the interval is reached.

  • Solution

Ensure that the location parameter used to create the Object Table specifies an OSS internal endpoint. For more information about creating an Object Table, see Parameters.