Qu'en est-il des performances attendues à Pentaho?

Question

J'utilise Pentaho pour créer des ETL et je suis très concentré sur les performances. Je développe un processus ETL qui copie 163.000.000 lignes du serveur Sql 2088 vers PostgreSQL et cela prend 17h.

Je ne sais pas si cette performance est bonne ou mauvaise. Savez-vous comment mesurer si le temps qui prend un certain processus est bon? Au moins comme une référence pour savoir si je dois continuer à travailler fortement sur la performance ou non.

En outre, je voudrais savoir s'il est normal que dans les 2 premières minutes du processus ETL, il charge 2M lignes. Je calcule combien de temps il faudra pour charger toutes les lignes. Le résultat attendu est de 6 heures, mais la performance diminue et cela prend 17h.

J'ai enquêté sur goole et je ne trouve aucune référence de temps ni aucune explication sur la performance.

Answer 1

17H c'est trop. Beaucoup trop. Pour 200 millions de lignes, 6 heures c'est même beaucoup.

Conseils pour l'optimisation:

1. Vérifiez la taille de la mémoire: modifier le spoon.bat, trouver la ligne contenant -Xmx et changer la moitié de votre taille de la mémoire de la machine. Les détails varient avec la version java. Example for PDI V7.1.
2. Vérifiez si la requête de la base de données source n'est pas trop longue (car trop complexe, ou la taille de la mémoire du serveur, ou?).
3. Vérifiez la taille de validation cible (essayez 25000 pour PostgreSQL), le Use batch update for inserts sur activé, et également que l'index et les contraintes sont désactivés. Jouez avec le Enable lazy conversion dans le Table input. Attention, vous risquez de produire des erreurs d'identification et de débogage difficiles à cause de la diffusion de données.
4. Dans la propriété de transformation, vous pouvez régler le Nr of rows in rowset (cliquez n'importe où, sélectionnez Propriété, puis l'onglet Miscelaneous). Sur le même onglet, vérifiez que la transformation n'est PAS transactional.

Answer 2

Diviser et vaincre, et procéder par élimination. Tout d'abord, ajoutez une LIMITE à votre requête de sorte que cela prend 10 minutes au lieu de 17 heures, ce qui rendra beaucoup plus facile d'essayer différentes choses.

Les processus s'exécutent-ils sur des machines différentes? Si tel est le cas, mesurez l'utilisation de la bande passante réseau pour vous assurer qu'il ne s'agit pas d'un goulot d'étranglement. Transférer un gros fichier, assurez-vous que la bande passante est vraiment là.

Les processus s'exécutent-ils sur la même machine? Peut-être que l'un affame l'autre pour IO. La source et la destination sont-elles le même disque dur? Différents disques durs? SSD? Vous devez expliquer ...

Examinez l'utilisation des E/S et du processeur des deux processus. Est-ce que l'on traite un maximum d'un cpu?

Est-ce qu'un processus max sur un des disques? Vérifiez iowait, iops, bande passante d'E/S, etc.

Combien de colonnes? Deux INT, 500 FLOAT, ou un énorme BLOB avec un PDF de 12 mégaoctets dans chaque rangée? Les performances peuvent varier entre ces cas ...

Maintenant, je suppose que le problème est du côté POSTGRES.

Créer une table factice, identique à votre table cible, qui a:

• mêmes colonnes exactes (CREATE factice TABLE comme la table)
• Aucun index, Pas de contraintes (je pense qu'il est la valeur par défaut, vérifiez la table créée)
• AVANT d'INSÉRER le déclencheur qui renvoie NULL et dépose la ligne.

Les lignes seront traitées, mais pas insérées.

Est-ce rapide maintenant? OK, donc le problème était l'insertion.

Répétez cette opération, mais cette fois en utilisant une table UNLOGGED (ou une TABLE TEMPORAIRE). Ceux-ci n'ont aucune résistance aux crashs car ils n'utilisent pas le journal, mais pour importer des données, c'est OK ... s'il se bloque pendant l'insertion, vous l'effacerez et le redémarrerez quand même.

Toujours Pas d'index, pas de contrainte. Est-ce rapide?

Si lent => E/S, problème de bande passante d'écriture, peut-être causé par autre chose touchant les disques Si rapide => IO est OK, problème non encore trouvé! Avec la table chargée de données, ajoutez les index et les contraintes un par un, vérifiez si vous avez, par exemple, un CHECK qui utilise une fonction SQL lente, ou un FK dans une table qui n'a pas d'index, ce type de des trucs. Vérifiez simplement combien de temps il faut pour créer la contrainte.

Remarque: pour une importation comme celle-ci, vous devez normalement ajouter des indices et des contraintes après l'importation. Mon intuition est que PG est en train de checkpointing comme un fou en raison du grand volume de données, en raison de réglages de point de contrôle trop bas dans la config. Ou une question comme celle-là, probablement des E/S aléatoires liées. Vous mettez le WAL sur un SSD rapide, non?