Tous les produits
Search
Centre de documentation

Hologres:Accelerate MaxCompute queries

Dernière mise à jour :Aug 11, 2026

Hologres s'intègre nativement à MaxCompute. Son moteur lit directement les données MaxCompute en appliquant un filtrage hiérarchique des partitions et une poussée d'opérateurs pour accélérer les requêtes.

Deux approches permettent d'accélérer les requêtes MaxCompute dans Hologres :

Approche

Gain de performance

Surcoût de stockage

Cas d'usage idéal

Importer les données dans Hologres (recommandé)

10 à 100 fois plus rapide que les requêtes directes sur MaxCompute

Nécessite du stockage pour une copie des données

Requêtes analytiques fréquentes, jointures avec des tables internes

Interroger via une table externe

2 à 5 fois plus rapide que les requêtes directes sur MaxCompute

Aucun stockage supplémentaire

Requêtes ponctuelles, accès peu fréquents, jeux de données trop volumineux pour être copiés

Remarque

Les requêtes sur les tables externes sont toujours plus lentes que celles exécutées sur les tables internes de Hologres. Si la performance est votre priorité absolue, importez les données. Recourez aux tables externes lorsque le coût de stockage ou les exigences de fraîcheur des données rendent l'importation peu pratique.

Importer les données dans Hologres (recommandé)

L'importation des données MaxCompute dans une table interne Hologres offre des performances de requête 10 à 100 fois supérieures à celles des requêtes sur tables externes. Privilégiez cette approche pour les requêtes analytiques fréquentes ou les jointures entre les données MaxCompute et les tables internes Hologres.

Pour importer les données, créez une table interne Hologres avec une clé de distribution et des propriétés d'index appropriées, puis chargez les données depuis MaxCompute via SQL. Pour plus de détails, consultez Importer des données depuis MaxCompute à l'aide de SQL.

Interroger via une table externe

Lorsque l'importation des données n'est pas envisageable, par exemple en raison d'exigences strictes de fraîcheur des données ou d'un volume trop important pour être copié, interrogez les données MaxCompute via des tables externes et optimisez leurs performances en suivant les bonnes pratiques ci-dessous.

Bonne pratique

Cas d'utilisation

Impact sur les performances

Utiliser le calcul serverless

ETL à grande échelle, imports groupés, requêtes sur de grands jeux de données

Décharge le calcul ; prévient les erreurs OOM

Utiliser le moteur d'exécution HQE

Tables au format ORC, Hologres V0.10 et versions ultérieures

Amélioration de 30 à 100 %

Éviter les analyses complètes de table

Toutes les requêtes

Réduit immédiatement le volume de données analysées

Optimiser la structure des tables MaxCompute pour SQE

Lorsque HQE n'est pas pris en charge (format non-ORC, transactionnel, évolution du schéma)

Permet l'élagage et la poussée d'agrégation

Fusionner les petits fichiers

Tables contenant >100 fichiers avec une taille moyenne inférieure à 64 Mo

Réduit la surcharge d'analyse

Ajuster les paramètres de requête

Caractéristiques spécifiques de la charge de travail

Contrôle granulaire des ressources

Utiliser le calcul serverless

Pour les charges de travail importantes, telles que l'importation de volumes massifs de données MaxCompute, l'exécution de tâches ETL (extraction, transformation et chargement) ou l'interrogation de grandes tables, utilisez le calcul serverless (disponible à partir de Hologres V2.1.17).

Le calcul serverless puise des ressources de calcul supplémentaires hors de votre instance, ce qui permet :

  • De laisser les ressources de votre instance disponibles pour d'autres charges de travail.

  • D'éviter de réserver une capacité de calcul supplémentaire pour les pics de charge.

  • De réduire la probabilité d'erreurs OOM (mémoire insuffisante).

  • D'être facturé uniquement pour le calcul utilisé par la tâche.

Pour plus de détails, consultez Calcul serverless et Utiliser le calcul serverless.

Utiliser le moteur d'exécution HQE

À partir de Hologres V0.10, le moteur Hologres Query Engine (HQE) est utilisé par défaut pour les requêtes sur les tables MaxCompute, améliorant les performances d'environ 30 à 100 % par rapport aux versions précédentes.

HQE présente les limitations suivantes :

  • HQE n'accélère que les requêtes sur les tables MaxCompute au format ORC. Les autres formats, tels que CFile, ne sont pas pris en charge.

  • HQE n'accélère pas les requêtes sur les tables transactionnelles MaxCompute ni sur les tables utilisant l'évolution de schéma. Dans ces cas, Hologres bascule automatiquement vers le moteur SQE.

  • Un mappage des types de données correct entre MaxCompute et Hologres est requis. Tout écart réduit l'effet d'accélération.

Éviter les analyses complètes de table

Les analyses complètes de table constituent la cause la plus fréquente de lenteur des requêtes sur tables externes. Pour les éviter :

  • Interrogez uniquement les colonnes nécessaires. Utilisez SELECT col1, col2 FROM table au lieu de SELECT * FROM table.

  • Filtrez sur les colonnes de partition. Ajoutez des conditions de partition dans votre clause WHERE pour limiter le nombre de partitions analysées.

Nous recommandons vivement d'utiliser des filtres de partition dans chaque requête portant sur des tables partitionnées. L'élagage de partition est le moyen le plus efficace pour réduire la quantité de données que Hologres doit lire depuis MaxCompute.

Optimiser la structure des tables MaxCompute pour SQE

Lorsque HQE ne prend pas en charge une requête, Hologres revient au moteur Seahawks Query Engine (SQE). Pour améliorer les performances de SQE, restructurez la table MaxCompute sous-jacente. Deux stratégies de clustering sont disponibles :

Stratégie

Cas d'usage idéal

Contrainte

Clustering par hachage

Requêtes d'agrégation, élagage par bucket

Aucune garantie contre le déséquilibre des données

Clustering par plage

Requêtes de plage, requêtes sur clés composites, prévention du déséquilibre

Disposition ordonnée globalement

Convertir en table avec clustering par hachage

Le clustering par hachage permet l'élagage par bucket, l'optimisation des agrégations et l'optimisation du stockage. Lors de la création ou de la modification d'une table avec CLUSTERED BY, MaxCompute hache les colonnes spécifiées et distribue les données dans des buckets.

Pour la clé de hachage, choisissez des colonnes présentant peu de valeurs de clé dupliquées.

ALTER TABLE <table_name>
  [CLUSTERED BY (<col_name> [, <col_name>, ...])
  [SORTED BY (<col_name> [ASC | DESC] [, <col_name> [ASC | DESC] ...])]
  INTO <number_of_buckets> BUCKETS];

Après l'instruction ALTER TABLE, seules les nouvelles partitions utilisent le clustering par hachage. Pour plus d'informations, consultez Clustering par hachage dans la documentation MaxCompute.

Convertir en table avec clustering par plage

Le clustering par plage distribue les données selon une disposition ordonnée globalement, ce qui évite le déséquilibre des données que peut provoquer le clustering par hachage. Sa distribution ordonnée crée un index à deux niveaux qui prend en charge les requêtes de plage et les requêtes sur clés composites.

ALTER TABLE <table_name>
  [RANGE CLUSTERED BY (<col_name> [, <col_name>, ...])
  [SORTED BY (<col_name> [ASC | DESC] [, <col_name> [ASC | DESC] ...])]
  [INTO <number_of_buckets> BUCKETS];

Après l'instruction ALTER TABLE, seules les nouvelles partitions utilisent le clustering par plage. Pour plus d'informations, consultez Clustering par plage.

Important

Les tables avec clustering par hachage et par plage partagent les mêmes contraintes que les tables avec clustering par hachage :

  • Utilisez INSERT OVERWRITE pour écrire les données. INSERT INTO n'est pas pris en charge.

  • Ne téléchargez pas de données dans ces tables via Tunnel. Les données téléchargées via Tunnel ne sont pas ordonnées et sont incompatibles avec les exigences de clustering.

Compacter les petits fichiers

Un nombre excessif de petits fichiers dans une table MaxCompute ralentit les requêtes car Hologres doit ouvrir et lire chaque fichier individuellement. Exécutez la commande suivante dans MaxCompute pour vérifier le nombre de fichiers :

DESC EXTENDED <table_name>;

Dans la sortie, FileNum indique le nombre de fichiers et Size indique la taille totale en octets. Si la table contient plus de 100 fichiers et que la taille moyenne des fichiers est inférieure à 64 Mo, fusionnez les petits fichiers. Pour plus d'informations, consultez FAQ : Optimisation des petits fichiers et diagnostic des tâches.

Pour savoir comment fusionner les fichiers, consultez FAQ sur l'optimisation des petits fichiers et le diagnostic des tâches.

Ajuster les paramètres de requête

Hologres définit des valeurs de paramètre par défaut basées sur des tests de référence internes. Ces valeurs par défaut conviennent à la plupart des charges de travail ; ne les modifiez que si vous avez une raison spécifique.

Paramètre

Valeur par défaut

Notes

hg_foreign_table_max_partition_limit

512 (max : 1024)

Nombre maximal de partitions analysées par requête. Une valeur trop élevée dégrade les performances.

hg_experimental_query_batch_size

8192

Taille du lot pour chaque lecture depuis une table MaxCompute.

hg_foreign_table_split_size

64 Mo

Taille par fraction lors de l'accès à une table MaxCompute. Pour les grandes tables, augmentez cette valeur pour éviter un nombre excessif de fractions. Disponible à partir de Hologres V1.1.

hg_foreign_table_executor_max_dop

Nombre de vCPU de l'instance (max : 128)

Concurrence maximale pour l'accès aux tables externes. Maintenez cette valeur basse pour empêcher les requêtes sur tables externes d'affamer les autres charges de travail. Disponible à partir de Hologres V1.1.

hg_foreign_table_executor_dml_max_dop

32

Concurrence maximale pour les instructions DML sur les tables externes. Limite la consommation de ressources lors de l'importation et de l'exportation de données. Disponible à partir de Hologres V1.1.

Important

Ne définissez pas hg_foreign_table_executor_max_dop sur une valeur très faible telle que 1. Cela pourrait concentrer la charge sur des workers spécifiques lors des opérations de lecture et d'écriture simultanées, déclenchant ainsi des erreurs OOM.

Exemple : Ajuster la limite maximale de partitions :

-- Default: 512. Maximum: 1024. Do not set too high.
SET hg_foreign_table_max_partition_limit = 128;

Exemple : Ajuster la taille de fraction pour les grandes tables :

-- Default: 64 MB. Increase for large tables to reduce the number of splits.
SET hg_foreign_table_split_size = 128;

Exemple : Limiter la concurrence pour l'accès aux tables externes :

-- Default: number of instance cores. Maximum: 128.
SET hg_foreign_table_executor_max_dop = 32;