資料類型概述
Blob(Binary Large Object)資料類型是MaxCompute提供的一種用於在表中儲存圖片、音頻、視頻、文檔等非結構化二進位大對象的資料類型。通過 Blob 類型,可以將多模態資料的原始檔案、元資訊和標註資訊統一儲存在同一張MaxCompute表中,使用 SQL 統一查詢和維護,通過MaxFrame 和 SQL UDF 批量加工處理。
適用情境
AI 訓練資料集管理:將圖片、音頻、視頻與標註標籤儲存在同一張表中,通過 SQL 過濾所需樣本資料集。
多模態資料處理流水線:視頻切幀、音頻轉文本、內容打標等多步驟流水線的中間結果和最終產物統一儲存。
多模態加工緩衝層:作為Object Storage Service等資料來源的緩衝層,提升 MaxFrame、SQL 大規模並行計算的吞吐效能,解決小檔案批量請求的 QPS 限制。
非結構化資料入湖:將分散在外部儲存中的檔案統一匯入 MaxCompute,擴充元資訊建立企業非結構化資產庫,獲得事務保障和統一許可權管控。
功能規格
特性 | 規格說明 |
大小限制 | 每個儲存格 Blob 對象最大 5 GB |
儲存格式 | 二進位格式 |
支援Blob的表格式 | Append Delta Table。Blob 列繼承表格式特性,支援 ACID 事務、階層式存放區和 Snapshot。 |
Blob最佳化服務 |
|
使用限制
必須開啟 MaxCompute 2.0 資料類型:
SET odps.sql.type.system.odps2=true;。Blob 類型不可嵌套在 ARRAY、MAP、STRUCT 等複雜類型中。
Blob 列不可作為主鍵列和分區鍵。
Blob 列不支援用於 ORDER BY、GROUP BY 和 JOIN ON 條件。
多模態混合儲存
下圖展示了傳統分散儲存架構與 MaxCompute 多模態統一儲存架構的對比。
左側為傳統方案,原始檔案儲存在Object Storage Service中,元資訊和標註資訊分散在不同的資料倉儲和資料湖中,查詢和處理需要跨多個系統協調。
右側為 MaxCompute 方案,通過 Blob 列類型將圖片、音頻、視頻等二進位檔案與結構化元資訊統一儲存在同一張表中,支援 SQL 查詢、MaxFrame 批處理和 SDK 資料匯入等操作。
MaxCompute 通過原生支援 Blob 列類型,將所有資料統一儲存在同一張表中,實現原始檔案、元資訊和標註資訊的同表格儲存體:
-- 多模態資料集表示例
CREATE TABLE multimodal_dataset (
id BIGINT NOT NULL,
image BLOB, -- 原始圖片二進位
label STRING, -- 分類標籤
bbox STRING, -- 標註邊界框 (JSON)
resolution STRING, -- 解析度元資訊
created_at DATETIME -- 入庫時間
) TBLPROPERTIES("table.format.version"="2");傳統方案與 MaxCompute 多模態方案對比
在傳統架構中,多模態資料的原始檔案、元資訊、標註資訊分散在Object Storage Service、資料倉儲、資料湖等多個引擎中。MaxCompute 通過原生支援 Blob 列類型,將所有資料統一儲存在同一張表中,解決了以下問題:
傳統方案的問題 | MaxCompute 多模態方案 |
維護成本高:多引擎架構導致資料分散在各處,難以統一管理。 | 統一儲存管理:原始檔案、元資訊、標註資訊儲存在同一張表中,無需維護多套系統。 |
跨引擎查詢延遲高:例如根據標籤篩選圖片時,需先查資料庫再去Object Storage Service讀檔案,屬於多跳查詢。 | SQL 直接過濾:按標籤、時間等條件查詢資料,無需跨系統多跳訪問。 |
缺乏統一 ACID 保障:資料一致性、存取權限和資料血緣無法集中管控。 | 完整 ACID 事務及統一許可權管控:每次寫入具有原子性和一致性保障,所有資料納入 MaxCompute 許可權體系管理。 |
處理流水線割裂:典型的多模態工作流程(視頻 → 音頻提取 → 文本轉寫 → 切幀 → 內容打標 → 元資訊提取)跨越多個系統,中間資料搬運頻繁。 | 統一處理流水線:多步驟流水線的中間結果和最終產物集中在一張表中,消除跨系統資料搬運。 |
儲存模式與效能收益
儲存模式
MaxCompute Blob 採用引用-實體分離的儲存模式,將結構化資料列與 Blob 大對象列拆分到不同的物理檔案中。如下圖所示,整體架構分為三層:
接入層提供 SQL、MaxFrame、ODPSCMD、SDK、StorageAPI 等多種訪問方式;
服務層負責 Compaction、Blob Reference 路由、ACID 交易管理、階層式存放區(Storage Tier)和備份;
儲存層將資料拆分為
Data File(結構化資料檔案):儲存表中的非 Blob 列資料(如 id、label、metadata 等)以及 Blob 列的引用指標(Reference)。這些檔案採用標準列式儲存,支援高效的謂詞下推和列裁剪。
Blob File(大對象檔案):儲存 Blob 對象的原始二進位內容、資料校正資訊和索引資訊。根據每個 Blob 對象大小動態拆分或合并隱藏檔。

資料寫入時,系統將二進位內容上傳到 Blob File,並將引用指標寫入結構化資料列Data File;讀取時,先通過結構化列擷取引用指標,再按需從 Blob File 載入二進位內容。Blob 上傳和引用寫入在同一個 Session Commit 中完成,讀寫操作會在 MaxCompute 內部完成交易管理,保證原子性。
上述邏輯對使用者透明,日常使用中無需關注底層儲存差異。
效能收益
小檔案合并與壓縮
Blob 儲存體會自動將大量小對象(圖片、HTML 片段、JSON 會話日誌等)合并成 Blob File,支援批量讀寫,解決大量小檔案請求的 QPS 限制問題。
文本類對象寫入時自動壓縮,訪問時自動解壓。例如 HTML 片段和 JSON 文本,平均可節約約 2 倍儲存空間,降低儲存成本。
標籤點查過濾資料集情境,檔案對象不影響列式掃描效能
當根據元資訊、標籤列過濾資料時(如尋找特定標籤的樣本),將Object Storage Service成 Blob 類型相比用 String/Binary 類型儲存位元據,端到端效能平均提升 2 倍(根據實際資料評估)。
例如,對 100 萬張平均大小 1.4 MB 的圖片建立資料集,對比將 image 儲存為 Binary 和 Blob 類型的查詢開銷:
儲存方式
標籤過濾掃描資料量
image 儲存為 BINARY 列
約 1,400 GB(全表掃描)
image 儲存為 BLOB 列
約 30 GB(僅 Data File)
執行如下標籤過濾查詢,Binary類型表將執行全表掃描,TableScan 數量 1400 GB,Blob 表 TableScan 數量 30 GB,掃描資料量降低了 45 倍。
-- image儲存為Binary類型 SELECT id, image FROM multimodal_dataset_binary Where label = "cat"; -- image儲存為Blob類型 SELECT id, read_blob(image) FROM multimodal_dataset_blob Where label = "cat";
資料匯入匯出
方式一:通過 SDK 批量上傳和下載
適用於大規模資料的高吞吐批量讀寫。使用MaxCompute Java SDK:0.57.1-public 及以上版本。
對於 1 MB 以下的 Blob 對象,推薦使用 Batch 批量上傳介面,SDK 會自動組裝成 64 MB 一批上傳。
<dependency>
<groupId>com.aliyun.odps</groupId>
<artifactId>odps-sdk-storage-api</artifactId>
<version>0.57.1-public</version>
</dependency>方式二:通過 Object Table 從Object Storage Service大量匯入
適用於將Object Storage Service中已有的大量非結構化檔案(圖片、音視頻、文檔等)大量匯入 MaxCompute 包含 Blob 資料類型的表。通過建立 OBJECT TABLE擷取Object Storage Service Bucket 中的對象和元資訊,然後批量插入到 MaxCompute 多模態表,整個過程無需二次中轉。
樣本如下:
-- Step 1: 建立 Object Table 關聯 OSS 資料
SET odps.namespace.schema=true;
SET odps.sql.type.system.odps2 = true;
CREATE OBJECT TABLE oss_images
LOCATION 'oss://<accessKeyId>:<accessKeySecret>@<endpoint>/<bucket>/<path>/';
-- 重新整理中繼資料
ALTER TABLE oss_images REFRESH METADATA;
-- Step 2: 建立包含Blob類型的多模態表
CREATE TABLE ods_dataset_images (
key VARCHAR(2048) COMMENT '對象鍵',
size BIGINT COMMENT '對象大小',
type VARCHAR(32) COMMENT '物件類型',
last_modified TIMESTAMP_NTZ COMMENT '最後修改時間',
storage_class VARCHAR(32) COMMENT '儲存類別',
etag VARCHAR(64) COMMENT 'ETag資訊',
restore_info VARCHAR(256) COMMENT '恢複資訊',
owner_id BIGINT COMMENT '所有者ID',
owner_display_name VARCHAR(256) COMMENT '所有者顯示名稱',
data_file BLOB COMMENT '資料檔案'
) COMMENT '多模態表'
tblproperties ('table.format.version'='2') ;
-- Step 3: 大量匯入到 Blob 表
INSERT OVERWRITE ods_dataset_images
SELECT key, size, type, last_modified, storage_class, etag, restore_info, owner_id, owner_display_name,
to_blob(get_data_from_oss('<project_name>.default.oss_images', key)) AS data_file
FROM oss_images;SQL文法
DDL
建表語句支援多 Blob 列。
CREATE TABLE video_dataset (
id BIGINT,
video BLOB,
thumbnail BLOB,
title STRING
) TBLPROPERTIES('table.format.version'='2');Blob 函數
to_blob() — 建立 Blob 對象
to_blob函數用於將字串或位元據轉換為 Blob 對象。
函數 | 說明 |
| 將字串整體轉為 Blob |
| 將二進位值整體轉為 Blob |
| 從 |
| 從 |
| 從 |
| 從 |
-- 從字串建立 Blob
SELECT to_blob('hello world'); -- 返回結果:Blob{reference=CAEQAxqqAgEAAAAJA...}
-- 從十六進位二進位建立 Blob
SELECT to_blob(X'89504E47'); -- PNG 檔案頭
-- 帶位移截取
SELECT to_blob('hello world', 6); -- 結果:'world'
SELECT to_blob('hello world', 0, 5); -- 結果:'hello'read_blob() — 讀取 Blob 內容
read_blob函數用於將 Blob 對象內容以 STRING 或 BINARY 形式返回。
函數 | 說明 |
| 讀取完整 Blob 內容為 STRING |
| 從 |
| 從 |
-- 讀取 Blob 內容
SELECT id, read_blob(image) FROM image_dataset WHERE label = 'cat' LIMIT 10;
-- 讀取部分內容(如檔案頭判斷類型)
SELECT id, read_blob(content, 0, 4) AS file_header FROM media_library;
-- 嵌套使用
SELECT read_blob(to_blob('hello world')); -- 返回 'hello world'length() — 擷取 Blob 位元組長度
-- 擷取 Blob 的位元組長度
SELECT id, length(read_blob(video)) AS image_size FROM image_dataset;使用樣本
-- 建立包含Blob類型的Table
CREATE TABLE blob_table (col1 BLOB)
TBLPROPERTIES (
"table.format.version"="2"
);
-- 資料寫入
INSERT INTO blob_table VALUES (to_blob("hello world"));
-- 資料讀取
SELECT read_blob(col1) FROM blob_table;