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 |
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 tableau lieu deSELECT * FROM table.Filtrez sur les colonnes de partition. Ajoutez des conditions de partition dans votre clause
WHEREpour 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.
Les tables avec clustering par hachage et par plage partagent les mêmes contraintes que les tables avec clustering par hachage :
Utilisez
INSERT OVERWRITEpour écrire les données.INSERT INTOn'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 |
|
|
512 (max : 1024) |
Nombre maximal de partitions analysées par requête. Une valeur trop élevée dégrade les performances. |
|
|
8192 |
Taille du lot pour chaque lecture depuis une table MaxCompute. |
|
|
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. |
|
|
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. |
|
|
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. |
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;