ORC external tables
This topic describes how to create, read from, and write to ORC external tables for OSS.
Constraints
OSS external tables do not support the cluster property.
The size of a single file cannot exceed 2 GB. You must split files that are larger than 2 GB.
MaxCompute and OSS must be in the same region.
Create an external table
syntax
If the ORC file schema and the external table schema do not match, MaxCompute handles the differences as follows:
Fewer columns in the file than in the table: Missing columns are filled with NULL.
More columns in the file than in the table: Extra columns are discarded.
Type mismatch: STRING can read INT data from ORC files, but this is not recommended. INT reading STRING data converts non-numeric values to NULL and accepts numeric values.
Use either the simplified syntax or the full syntax to create an ORC external table.
Simplified syntax (recommended)
Use this syntax when you want MaxCompute to handle authorization automatically using the default RAM role.
CREATE EXTERNAL TABLE [IF NOT EXISTS] <mc_oss_extable_name>
(
<col_name> <data_type>,
...
)
[COMMENT <table_comment>]
[PARTITIONED BY (<col_name> <data_type>, ...)]
STORED AS orc
LOCATION '<oss_location>';Full syntax
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 'org.apache.hadoop.hive.ql.io.orc.OrcSerde'
WITH serdeproperties(
'odps.properties.rolearn'='acs:ram::<uid>:role/aliyunodpsdefaultrole'
)
STORED AS orc
LOCATION '<oss_location>'
tblproperties (
'<xxx>'='<yyy>'
);Common parameters
For more information about common parameters, see Basic syntax parameters.
Format-specific parameters
WITH serdeproperties
Property | When to use | Value | Default |
| The ORC files in the same external table have inconsistent schemas. |
|
|
tblproperties
Property | When to use | Description | Value | Default |
| Write ORC data to OSS in a compressed format. | Compression algorithm for ORC output files. |
| None |
| OSS data files are in Raw-Snappy format. | Enables MaxCompute to read Raw-Snappy compressed data. |
| None |
| Add a custom prefix to output files. | Prefix string. Allowed characters: letters, digits, and underscores (a–z, A–Z, 0–9, _). Length: 1–10 characters. | Example: | None |
| Control whether output files include a file extension. |
|
|
|
| Add a custom suffix to output files. | Suffix string. Allowed characters: letters, digits, and underscores. | Example: | None |
| Add a custom extension to output files. Takes priority over | Extension string. Allowed characters: letters, digits, and underscores. Length: 1–10 characters. | Example: | None |
| Tune memory usage and processing throughput. | Number of rows processed per batch (ORC batch size). | Non-negative integer |
|
Write data
For details about the write syntax in MaxCompute, see Write syntax.
Query data
See Query syntax for details on SELECT syntax.
See Query optimization for details on optimizing query plans.
Enable predicate pushdown
Predicate pushdown (PPD) improves query performance on ORC external tables by pushing filter conditions down to the data scan layer. PPD requires native mode (
odps.ext.oss.orc.native=true).Add the following statements before your SQL query:
-- Enable the ORC native reader SET odps.ext.oss.orc.native=true; -- Enable ORC predicate pushdown SET odps.storage.orc.use.predicate.pushdown=true;
Example
This example creates an ORC external table with SNAPPY compression, adds an existing partition, reads data, and writes a new row.
Prerequisites
-
You have created a MaxCompute project.
-
You have prepared an OSS bucket and directory. For more information, see Create a bucket and Manage directories.
Ensure your bucket is in the same region as your MaxCompute project.
-
Grant permissions.
-
You have permission to access OSS. You can access an OSS external table by using an Alibaba Cloud account, a RAM user, or a RAM role. For more information about how to grant permissions, see STS-mode authorization for OSS.
-
You have the CreateTable permission in the MaxCompute project. For more information about table-related permissions, see MaxCompute permissions.
-
Step 1: Prepare the data file
Using the provided sample data, create the folder path orc_snappy/dt=20250526 in the oss-mc-test bucket. Upload the snappy file to the dt=20250526 partition folder.
Step 2: Create the external table
CREATE EXTERNAL TABLE orc_data_type_snappy
(
vehicleId INT,
recordId INT,
patientId INT,
calls INT,
locationLatitute DOUBLE,
locationLongitude DOUBLE,
recordTime STRING,
direction STRING
)
PARTITIONED BY (dt STRING)
ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.orc.OrcSerde'
WITH serdeproperties (
'odps.properties.rolearn'='acs:ram::<uid>:role/aliyunodpsdefaultrole'
)
STORED AS ORC
LOCATION 'oss://oss-cn-hangzhou-internal.aliyuncs.com/oss-mc-test/orc_snappy/'
tblproperties (
'mcfed.orc.compress'='SNAPPY'
);Step 3: Add existing partitions
For partitioned external tables, run MSCK REPAIR TABLE to register existing OSS partitions with MaxCompute. For the full syntax, see Adding partitions to an OSS external table.
MSCK REPAIR TABLE orc_data_type_snappy ADD PARTITIONS;Step 4: Read data
SELECT * FROM orc_data_type_snappy WHERE dt = '20250526' LIMIT 10;The query returns:
+------------+------------+------------+------------+------------------+-------------------+----------------+------------+------------+
| vehicleid | recordid | patientid | calls | locationlatitute | locationlongitude | recordtime | direction | dt |
+------------+------------+------------+------------+------------------+-------------------+----------------+------------+------------+
| 1 | 12 | 76 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:10 | SW | 20250526 |
| 1 | 1 | 51 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:00 | S | 20250526 |
| 1 | 2 | 13 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:01 | NE | 20250526 |
| 1 | 3 | 48 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:02 | NE | 20250526 |
| 1 | 4 | 30 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:03 | W | 20250526 |
| 1 | 5 | 47 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:04 | S | 20250526 |
| 1 | 6 | 9 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:05 | S | 20250526 |
| 1 | 7 | 53 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:06 | N | 20250526 |
| 1 | 8 | 63 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:07 | SW | 20250526 |
| 1 | 9 | 4 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:08 | NE | 20250526 |
| 1 | 10 | 31 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:09 | N | 20250526 |
+------------+------------+------------+------------+------------------+-------------------+----------------+------------+------------+Step 5: Write data
INSERT INTO orc_data_type_snappy PARTITION (dt = '20250526')
VALUES (1, 16, 76, 1, 46.81006, -92.08174, '9/14/2014 0:10', 'SW');
-- Verify the inserted row
SELECT * FROM orc_data_type_snappy WHERE dt = '20250526' AND recordid = 16;The query returns:
+------------+------------+------------+------------+------------------+-------------------+----------------+------------+------------+
| vehicleid | recordid | patientid | calls | locationlatitute | locationlongitude | recordtime | direction | dt |
+------------+------------+------------+------------+------------------+-------------------+----------------+------------+------------+
| 1 | 16 | 76 | 1 | 46.81006 | -92.08174 | 9/14/2014 0:10 | SW | 20250526 |
+------------+------------+------------+------------+------------------+-------------------+----------------+------------+------------+Supported data types
For a complete list of MaxCompute data types, see Data type version 1.0 and Data type version 2.0.
MaxCompute supports two modes for reading ORC external tables:
JNI mode (
SET odps.ext.oss.orc.native=false;): Supports both read and write operations.Native mode (
SET odps.ext.oss.orc.native=true;): Supports read operations only.
Data type | JNI mode (read and write) | Native mode (read only) |
TINYINT | Supported | Supported |
SMALLINT | Supported | Supported |
INT | Supported | Supported |
BIGINT | Supported | Supported |
BINARY | Supported | Supported |
FLOAT | Supported | Supported |
DOUBLE | Supported | Supported |
DECIMAL(precision,scale) | Supported | Supported |
VARCHAR(n) | Supported | Supported |
CHAR(n) | Supported | Supported |
STRING | Supported | Supported |
DATE | Supported | Supported |
DATETIME | Not supported | Supported |
TIMESTAMP | Not supported | Not supported |
TIMESTAMP_NTZ | Supported | Not supported |
BOOLEAN | Supported | Supported |
ARRAY | Supported | Supported |
MAP | Supported | Supported |
STRUCT | Supported | Supported |
JSON | Not supported | Not supported |
Supported compression formats
To read or write compressed ORC files, add the
mcfed.orc.compressproperty to thewith serdepropertiessection when creating the table, see WITH serdeproperties.Supported formats: ORC compressed using SNAPPY, ZLIB, or ZSTD.
Schema evolution
ORC external tables support two methods for mapping table columns to ORC file fields: position-based mapping and name-based mapping.
Position-based mapping (default): Set
'mcfed.orc.schema.resolution'='position'or omit the property. Columns are matched by their order, so the table column order must exactly match the field order in the ORC file.Name-based mapping: Set
'mcfed.orc.schema.resolution'='name'. Columns are matched by name, independent of order.
The table below shows which schema change operations are compatible with each mapping method. "Compatible" means both newly written data and historical data can be read correctly after the operation.
Schema change | Mapping mode | Supported | Description | Data compatibility |
Add column | By position | Supported |
|
For example, after a column is added, historical rows that lack the new column return NULL for that column. |
By name | Supported | |||
Delete column | By position | Not supported | Not recommended. Position-based mapping requires column order in the DDL to match the file. After a column is deleted, the DDL and file schemas diverge, causing read errors. |
For example, after a column is deleted, historical data that still contains the deleted column causes read errors. |
By name | Supported | Name-based mapping matches columns by name, independent of column order. | Compatible | |
Modify column order | By position | Not supported | Not recommended. Position-based mapping requires column order in the DDL to match the file. After columns are reordered, the DDL and file schemas diverge, causing read errors. |
For example, after columns are reordered, historical data retains the original order, causing schema-data misalignment. |
By name | Supported | Name-based mapping matches columns by name, independent of column order. | Compatible | |
Change column data type | By position | Supported | For allowed type conversions, see Change column data type. | Compatible |
By name | Supported | |||
Rename column | By position | Supported | Compatible | |
By name | Not supported | Not recommended. Name-based mapping matches columns by name. After a column is renamed, existing files that use the original name can no longer match. |
For example, after a column is renamed, if the ORC file schema still uses the original name, the column returns NULL on read. | |
Modify column comment | By position | Supported | Comment must be a valid string no longer than 1,024 bytes. | Compatible |
By name | Supported | |||
Modify column nullability | By position | Not supported | Columns are nullable by default. | Not applicable |
By name | Not supported |