MaxCompute:Blob data type and multimodal storage

Use cases

• AI training dataset management: Store images, audio, or video files along with their corresponding labels and annotations in a single table, and use SQL to filter for specific data samples.

• Multimodal data processing pipelines: Unify the storage of intermediate and final results from multi-step pipelines, such as video frame extraction, audio-to-text transcription, and content labeling.

• Multimodal processing cache layer: Act as a caching layer for data sources like object storage to improve the throughput of large-scale parallel computing with MaxFrame and SQL, overcoming the QPS limits associated with batch requests for small files.

• Unstructured data ingestion: Import files from various external storage systems into MaxCompute and enrich them with metadata to build an enterprise-level unstructured asset library, benefiting from transaction guarantees and unified access control.

Specifications

Limitations

• You must enable MaxCompute 2.0 data types: SET odps.sql.type.system.odps2=true;.

• The Blob type cannot be nested within complex types such as ARRAY, MAP, or STRUCT.

• A Blob column cannot be used as a primary key or a partition key.

• A Blob column cannot be used in ORDER BY, GROUP BY, or JOIN ON clauses.

Traditional vs. MaxCompute multimodal approaches

Traditional architectures distribute multimodal data—such as raw files, metadata, and annotations—across various systems like object storage, data warehouses, and data lakes. MaxCompute solves these challenges by using the Blob column type to unify all data into a single table:

Storage model

MaxCompute Blob uses a reference-entity separated storage model, which separates structured data columns from Blob large object columns into different physical files. As shown in the following figure, the architecture has three layers:

• The access layer provides multiple access methods, including SQL, MaxFrame, odpscmd, SDK, and the Storage API.

• The service layer handles compaction, Blob reference routing, ACID transaction management, storage tiering, and backups.

• The storage layer splits data into:

  • Data File (structured data file): Stores non-Blob column data (such as id, label, and metadata) and a reference pointer (Reference) to the Blob column. These files use a standard columnar storage format that supports efficient predicate pushdown and column pruning.

  • Blob File (large object file): Stores the raw binary content of Blob objects, along with data checksums and index information. Storage files are dynamically split or merged based on the size of each Blob object.

When writing data, the system uploads the binary content to a Blob File and writes a reference pointer to the structured Data File. When reading data, the system first retrieves the reference pointer from the structured column and then loads the binary content from the Blob File as needed. The Blob upload and reference write are completed atomically in a single session commit, and MaxCompute manages the read/write operations as one transaction to ensure atomicity.

This process is transparent to you and requires no special handling.

Performance benefits

• Small file merging and compression

  • Blob storage automatically merges many small objects (such as images, HTML snippets, and JSON session logs) into larger Blob Files, supporting batch read and write operations. This resolves the QPS limitations associated with requests for a large number of small files.

  • Text-based objects are automatically compressed on write and decompressed on read. For example, for HTML snippets and JSON text, this can reduce storage space by an average of 50%, lowering storage costs.

• Efficient filtering on metadata without scanning large file objects

  When filtering data based on metadata or label columns (for example, finding samples with a specific label), storing objects as the Blob type instead of as STRING or BINARY types can double end-to-end performance on average.

  For example, consider a dataset of 1 million images with an average size of 1.4 MB. The following table compares the query overhead of storing the image as a BINARY type versus a Blob type:

  Storage method	Scanned data
  Image stored in a BINARY column	Approx. 1,400 GB (full table scan)
  Image stored in a BLOB column	Approx. 30 GB (Data File only)

  When you run the following label filtering query, the table with the BINARY type performs a full table scan of 1,400 GB. In contrast, the table with the Blob type scans only 30 GB of data, a 45-fold reduction.

  -- Image stored as BINARY type
  SELECT id, image FROM multimodal_dataset_binary Where label = "cat";
  -- Image stored as Blob type
  SELECT id, read_blob(image) FROM multimodal_dataset_blob Where label = "cat";

DDL

You can define multiple Blob columns in a CREATE TABLE statement.

CREATE TABLE video_dataset (
    id        BIGINT,
    video     BLOB,
    thumbnail BLOB,
    title     STRING
) TBLPROPERTIES('table.format.version'='2');

Blob functions

-- Create a Blob from a string
SELECT to_blob('hello world'); -- Returns: Blob{reference=CAEQAxqqAgEAAAAJA...}

-- Create a Blob from hexadecimal binary data
SELECT to_blob(X'89504E47');   -- PNG file header

-- Substring with an offset
SELECT to_blob('hello world', 6);           -- Result: 'world'
SELECT to_blob('hello world', 0, 5);        -- Result: 'hello'

-- Read the content of a Blob
SELECT id, read_blob(image) FROM image_dataset WHERE label = 'cat' LIMIT 10;

-- Read partial content (for example, to check the file header)
SELECT id, read_blob(content, 0, 4) AS file_header FROM media_library;

-- Nested usage
SELECT read_blob(to_blob('hello world'));  -- Returns 'hello world'

-- Gets the length of a Blob in bytes
SELECT id, length(read_blob(image)) AS image_size FROM image_dataset;

Quick start

-- Create a table with a Blob column
CREATE TABLE blob_table (col1 BLOB)
TBLPROPERTIES (
  "table.format.version"="2" 
);

-- Write data
INSERT INTO blob_table VALUES (to_blob("hello world"));

-- Read data
SELECT read_blob(col1) FROM blob_table;