How to tune data import for different scenarios - AnalyticDB

AnalyticDB for MySQL propose diverses méthodes d'importation de données adaptées à différents scénarios. Toutefois, les performances d'importation peuvent souffrir de facteurs tels qu'une modélisation inappropriée des tables entraînant une distorsion des données (data skew), ou une utilisation inefficace des ressources due à des configurations d'importation sous-optimales. Cette rubrique décrit comment optimiser les performances d'importation des données dans différents scénarios.

Optimisation de l'importation via une table externe

Vérification de la clé de distribution

La clé de distribution détermine la répartition des données entre les shards pour une importation simultanée. Si les données ne sont pas réparties uniformément, les shards recevant un volume plus important peuvent devenir des goulets d'étranglement, provoquant une distorsion des données et ralentissant l'ensemble du job d'importation. Pour éviter ce problème, assurez-vous que vos données sont distribuées équitablement lors de l'importation. Pour savoir comment choisir une clé de distribution, consultez la rubrique Choix d'une clé de distribution.

Vérifiez si la clé de distribution est appropriée :

Avant d'importer les données, évaluez la clé de distribution choisie en fonction de la logique métier. Par exemple, dans la table Lineitem, si vous choisissez la colonne l_discount comme clé de distribution, sa faible cardinalité (seulement 11 valeurs distinctes) entraînera une forte distorsion des données. Toutes les données partageant la même valeur de remise seront envoyées vers le même shard, créant ainsi un goulot d'étranglement et dégradant les performances. Il vaut mieux choisir la colonne l_orderkey, car les identifiants de commande sont uniques et permettent une répartition plus homogène des données.
Après l'importation des données, si le rapport Data Modeling Diagnostics indique une distorsion au niveau du champ de distribution, cela signifie que votre clé de distribution provoque une répartition inégale des données. Pour savoir comment consulter ces diagnostics, reportez-vous à la rubrique Diagnostics de stockage.

Vérification de la clé de partitionnement

Lorsque vous utilisez INSERT OVERWRITE SELECT, la partition importée écrase toute partition existante portant le même nom dans la table cible. Au sein de chaque shard, les données sont ensuite importées dans leur partition respective en fonction de la clé de partitionnement. Pour éviter de déclencher un processus de tri externe qui dégraderait les performances, n'importez pas trop de partitions en une seule fois. Pour savoir comment choisir une clé de partitionnement, consultez la rubrique Choix d'une clé de partitionnement.

Vérifiez si la clé de partitionnement est appropriée :

Avant d'importer les données, évaluez votre clé de partitionnement en fonction des besoins métier et de la distribution des données. Par exemple, si vous partitionnez la table Lineitem par la colonne l_shipdate sur une période de 7 ans, un partitionnement quotidien créerait plus de 2 000 partitions, ce qui s'avère inefficace. Un partitionnement mensuel ou annuel constitue une approche plus adaptée.
Après l'importation des données, si le rapport Data Modeling Diagnostics affiche un nombre de partitions déraisonnable, cela signifie que votre clé de partitionnement n'est pas appropriée. Pour savoir comment consulter ces diagnostics, reportez-vous à la rubrique Diagnostics des tables partitionnées.

Vérification de l'index

Par défaut, AnalyticDB for MySQL indexe toutes les colonnes lors de la création d'une table. La construction d'un index complet sur une table large consomme beaucoup de ressources. Lorsque vous importez des données dans une table large, utilisez un index de clé primaire. Un index de clé primaire sert à la déduplication, mais l'utilisation d'un trop grand nombre de colonnes dans la clé primaire peut ralentir ce processus. Pour savoir comment choisir une clé primaire, consultez la rubrique Choix d'une clé primaire.

Vérifiez si l'index est approprié :

Dans les scénarios d'importation hors ligne, un index de clé primaire n'est généralement pas nécessaire, car un job de calcul hors ligne a déjà effectué la déduplication des données.
Dans l'onglet Monitoring Information > Table Information Statistics, consultez la taille des données de la table, des données d'index et des données d'index de clé primaire. Si la taille des données d'index dépasse celle des données de la table, vérifiez la présence de colonnes contenant des chaînes de caractères longues. L'indexation de ces colonnes prend du temps et consomme un espace de stockage important. Vous pouvez supprimer ces index. Pour plus d'informations, consultez la rubrique ALTER TABLE.

Remarque
Un index de clé primaire ne peut pas être supprimé. Vous devez reconstruire la table.

Ajout d'un indice pour accélérer l'importation

Ajoutez l'indice direct_batch_load=true à votre instruction d'importation pour accélérer le processus.

Remarque

Cet indice est pris en charge uniquement pour les clusters Data Warehouse Edition élastiques de version 3.1.5 ou ultérieure. Si vous ne constatez pas d'amélioration significative des performances, Soumettez un ticket.

Exemple :

SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM adb_external_table;

Accélération des importations avec l'importation élastique

Remarque

La fonctionnalité d'importation élastique est disponible uniquement pour les clusters disposant d'une version du noyau 3.1.10.0 ou ultérieure.
Cette fonctionnalité est prise en charge sur les clusters Enterprise Edition, Basic Edition, and Data Lakehouse Edition dotés d'un groupe de ressources de jobs.
L'importation élastique prend en charge uniquement les données provenant de MaxCompute ainsi que les données CSV, Parquet ou ORC issues d'Object Storage Service (OSS).
Lors de l'utilisation de l'importation élastique, assurez-vous que le groupe de ressources de jobs dispose de ressources suffisantes pour éviter des temps d'attente prolongés, une exécution lente et des échecs de jobs.

La fonctionnalité d'importation élastique vous permet d'exécuter plusieurs jobs d'importation simultanément. Vous pouvez également accélérer un job d'importation unique en lui allouant davantage de ressources. Pour plus d'informations, consultez la rubrique Méthodes d'importation de données.

Exemple :

/*+ elastic_load=true, elastic_load_configs=[adb.load.resource.group.name=resource_group]*/
submit job insert overwrite adb_table select * from adb_external_table;

Pour plus d'informations sur les paramètres, consultez la rubrique Paramètres des indices.

Optimisation de l'importation de données via DataWorks

Optimisation des configurations de jobs

Optimisation du paramètre Data Records Per Write

Ce paramètre spécifie la taille du lot pour chaque importation. Dans la plupart des cas, nous vous recommandons de conserver la valeur par défaut de 2048.

Toutefois, si un enregistrement unique est volumineux (par exemple 512 Ko), envisagez de définir ce paramètre sur 16. Cela maintient la taille du lot inférieure à 8 Mo et évite une utilisation élevée de la mémoire sur les nœuds frontaux.
Optimisation du paramètre channel control
- Les performances de synchronisation des données sont directement proportionnelles à la valeur du paramètre Expected Maximum Concurrency. Nous vous recommandons d'augmenter la valeur de Expected Maximum Concurrency autant que possible.
  
  Important
  Une valeur plus élevée pour Expected Maximum Concurrency consomme davantage de ressources DataWorks. Choisissez une valeur adaptée à vos besoins.
- Pour de meilleures performances de synchronisation, activez l'option Distributed Execution.

Problèmes courants et solutions

Si le client envoie les données trop lentement, l'utilisation du CPU du cluster, les E/S disque et le temps de réponse en écriture seront également faibles. Bien que le serveur de base de données puisse traiter les données envoyées par le client, le faible volume entrant entraîne un TPS en écriture inférieur aux attentes.

Solution : Augmentez les valeurs des paramètres Data Records Per Write et Expected Maximum Concurrency. Les performances d'importation des données s'améliorent linéairement à mesure que la pression d'importation augmente.
Si une distorsion des données existe dans la table cible, certains nœuds du cluster deviennent surchargés, ce qui dégrade les performances d'importation. Dans ce cas, l'utilisation du CPU et des E/S disque est faible, mais le temps de réponse en écriture est élevé. Vous pouvez identifier les tables présentant une distorsion sur la page Diagnostics and Optimization > Data Modeling Diagnostics.

Solution : Redéfinissez le schéma de la table, puis réimportez les données. Pour plus d'informations, consultez la rubrique Conception du schéma de table.

Optimisation de l'importation de données via JDBC

Optimisation côté client

Regroupement des données dans votre application
- Lors de l'importation de données à l'aide d'un programme JDBC, utilisez des importations par lots pour réduire la surcharge réseau et celle des connexions. Évitez les importations ligne par ligne, sauf si vous avez des exigences spécifiques.
- Une taille de lot de 2048 enregistrements est recommandée. Si un enregistrement unique est volumineux, maintenez la taille totale du lot inférieure à 8 Mo. Vous pouvez calculer le nombre d'enregistrements par lot en divisant 8 Mo par la taille d'un enregistrement unique. Un lot trop volumineux peut consommer trop de mémoire sur le nœud frontal et dégrader les performances d'importation.
Configuration de la concurrence de l'application
- Lors de l'importation de données depuis une application, utilisez plusieurs threads concurrents. Un thread unique ne peut pas exploiter pleinement les ressources du client et ne parvient souvent pas à suivre la vitesse d'importation de la base de données en raison du traitement et du regroupement des données côté client. Les importations concurrentes peuvent augmenter considérablement la vitesse.
- Le niveau optimal de concurrence dépend de facteurs tels que le regroupement, la source de données et la charge de la machine cliente. Il n'existe pas de valeur unique idéale. Effectuez des tests pour trouver la concurrence optimale pour votre charge de travail. Si la vitesse d'importation est inférieure aux attentes, essayez de doubler la concurrence. Si la vitesse diminue ensuite, réduisez-la progressivement pour trouver le paramétrage optimal.

Problèmes courants et solutions

Si vous rencontrez des problèmes de performances lors de l'importation de données dans AnalyticDB for MySQL depuis un programme personnalisé, commencez par vérifier l'existence de goulots d'étranglement côté client.

Assurez-vous que votre source de données peut fournir les données à un débit suffisant. Si les données proviennent d'autres systèmes ou de fichiers, vérifiez s'il existe des goulots d'étranglement en sortie côté client.
Assurez-vous que la vitesse de traitement des données est adéquate, vérifiez que la production et la consommation des données sont synchronisées, et garantissez qu'une quantité suffisante de données attend d'être importée dans AnalyticDB for MySQL.
Vérifiez la charge de la machine cliente pour vous assurer que les ressources système, telles que le CPU et les E/S disque, sont suffisantes.