MaxCompute:Type de données Blob et stockage multimodal

Cas d'utilisation

• Gestion des jeux de données d'entraînement IA : Stockez des images, des fichiers audio ou vidéo ainsi que leurs libellés et annotations correspondants dans une seule table, et utilisez SQL pour filtrer des échantillons de données spécifiques.

• Pipelines de traitement de données multimodales : Unifiez le stockage des résultats intermédiaires et finaux issus de pipelines en plusieurs étapes, tels que l'extraction d'images vidéo, la transcription audio-texte et l'étiquetage du contenu.

• Couche de cache pour le traitement multimodal : Servez de couche de mise en cache pour des sources de données telles que le stockage d'objets afin d'améliorer le débit du calcul parallèle à grande échelle avec MaxFrame et SQL, en contournant les limites de QPS associées aux demandes par lots de petits fichiers.

• Ingestion de données non structurées : Importez des fichiers depuis divers systèmes de stockage externes vers MaxCompute et enrichissez-les avec des métadonnées pour créer une bibliothèque d'actifs non structurés de niveau entreprise, en tirant parti des garanties transactionnelles et du contrôle d'accès unifié.

Spécifications

Limitations

• Activez les types de données MaxCompute 2.0 : SET odps.sql.type.system.odps2=true;.

• Le type Blob ne peut pas être imbriqué dans des types complexes tels que ARRAY, MAP ou STRUCT.

• Une colonne Blob ne peut pas servir de clé primaire ou de clé de partition.

• Une colonne Blob ne peut pas être utilisée dans les clauses ORDER BY, GROUP BY ou JOIN ON.

Comparaison entre les approches traditionnelles et MaxCompute pour le multimodal

Les architectures traditionnelles répartissent les données multimodales (fichiers bruts, métadonnées, annotations) sur divers systèmes comme le stockage d'objets, les entrepôts de données et les lacs de données. MaxCompute résout ces défis en utilisant le type de colonne Blob pour unifier toutes les données dans une seule table :

Modèle de stockage

MaxCompute Blob utilise un modèle de stockage séparant la référence de l'entité, qui sépare les colonnes de données structurées des colonnes d'objets volumineux Blob en fichiers physiques distincts. Comme illustré dans la figure suivante, l'architecture comporte trois couches :

• La couche d'accès fournit plusieurs méthodes d'accès, notamment SQL, MaxFrame, odpscmd, SDK et l'API Storage.

• La couche de service gère la compaction, le routage des références Blob, la gestion des transactions ACID, la hiérarchisation du stockage et les sauvegardes.

• La couche de stockage divise les données en :

  • Data File (fichier de données structurées) : Stocke les données des colonnes non-Blob (telles que id, label et metadata) et un pointeur de référence (Reference) vers la colonne Blob. Ces fichiers utilisent un format de stockage colonnaire standard qui prend en charge le pushdown de prédicats efficace et l'élagage de colonnes.

  • Blob File (fichier d'objet volumineux) : Stocke le contenu binaire brut des objets Blob, ainsi que les sommes de contrôle des données et les informations d'index. Les fichiers de stockage sont dynamiquement fractionnés ou fusionnés en fonction de la taille de chaque objet Blob.

Lors de l'écriture des données, le système télécharge le contenu binaire vers un fichier Blob et écrit un pointeur de référence dans le fichier de données structuré. Lors de la lecture des données, le système récupère d'abord le pointeur de référence de la colonne structurée, puis charge le contenu binaire du fichier Blob selon les besoins. Le téléchargement Blob et l'écriture de référence sont effectués de manière atomique lors d'un seul commit de session, et MaxCompute gère les opérations de lecture/écriture comme une seule transaction pour garantir l'atomicité.

Ce processus est transparent pour vous et ne nécessite aucune manipulation spéciale.

Avantages en matière de performances

• Fusion et compression des petits fichiers

  • Le stockage Blob fusionne automatiquement de nombreux petits objets (tels que des images, des extraits HTML et des journaux de session JSON) en fichiers Blob plus grands, prenant en charge les opérations de lecture et d'écriture par lots. Cela résout les limitations de QPS associées aux demandes pour un grand nombre de petits fichiers.

  • Les objets basés sur du texte sont automatiquement compressés à l'écriture et décompressés à la lecture. Par exemple, pour les extraits HTML et le texte JSON, cela peut réduire l'espace de stockage de 50 % en moyenne, diminuant ainsi les coûts de stockage.

• Filtrage efficace sur les métadonnées sans analyser les grands objets fichiers

  Lors du filtrage des données en fonction des colonnes de métadonnées ou de libellés (par exemple, pour trouver des échantillons avec un libellé spécifique), le stockage des objets en tant que type Blob au lieu des types STRING ou BINARY peut doubler les performances de bout en bout en moyenne.

  Par exemple, considérons un jeu de données de 1 million d'images d'une taille moyenne de 1,4 Mo. Le tableau suivant compare la surcharge de requête du stockage de l'image en tant que type BINARY par rapport à un type Blob :

  Méthode de stockage	Données analysées
  Image stockée dans une colonne BINARY	Environ 1 400 Go (analyse complète de la table)
  Image stockée dans une colonne BLOB	Environ 30 Go (fichier Data File uniquement)

  Lorsque vous exécutez la requête de filtrage par libellé suivante, la table avec le type BINARY effectue une analyse complète de la table de 1 400 Go. En revanche, la table avec le type Blob n'analyse que 30 Go de données, soit une réduction de 45 fois.

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

Vous pouvez définir plusieurs colonnes Blob dans une instruction CREATE TABLE.

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

Fonctions Blob

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

Démarrage rapide

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