Optimisation Traitement BDD

[David_1]

Bonjour,

Je dispose d'un dataset constitué de plusieurs archives (10 fichiers .gz de 1,4 Go).

Ce dataset n'a pas d'entête de colonne et compte près de 2 000 colonnes.

Je récupère les noms des colonnes (à partir d'un fichier de dessin) les affecte aux colonnes, je conserve uniquement les colonnes qui me sont utiles. J'utilise aussi un fichier de configuration pour optimiser le typage et la taille des champs produit avec l'objet Champ automatique.

Et je mets ça dans une base PostgreSQL (autant de ligne sur 600 colonnes environ).

Jusque là, tout va bien, le job est fait mais j'observe une durée de traitement relativement longue.

Ca prend un peu plus de 3h pour réaliser ces opérations en insertion en masse (PostgreSQL bulk Loader).

Je voudrais savoir si il ne serait pas possible d'optimiser ce traitement pour faire gagner du temps à ce traitement.

Cordialement,

[Toons]

@David_1 : tu pourrais peut-être monter tes données dans PostrGreSQL dès le départ pour ensuite utiliser les outils in-db qui délègueront les transformations à la base de données ?

[carlosteixeira]

Salut @David_1 

Quelle version de votre Alteryx ?
Quelle est la version de votre pilote (odbc/oledb) pour postgree ?

Vous pouvez jeter un œil à ce lien, il contient peut-être des informations qui vous aideront.

https://community.alteryx.com/t5/Alteryx-Designer-Discussions/Best-way-to-approach-update-insert-wit...

Salutations

[StephaneP · Accepted solution]

Hello @David_1 ,

Pour mieux comprendre où est consommé le temps lors d'un traitement tu peux activier l'option "Activer l'option de profilage" dans le menu Exécution de ton workflow.

ceci rajoute à la fin de tes logs la liste des objets avec le temps en % passé sur chacun d'eux. Tu peux donc voir si le temps est passé en lecture écriture... ou autre.
Du coup cela t'aide à voir si c'est la conversion du Zip qui prends du temps, l'écriture dans PostGre...et ainsi investiguer sur ces postes particuliers.

Est ce mon poste qui mérite d'être amélioré (si c'est sur l'extraction, nettoyage des zips), est ce le driver en écriture (si c'est l'écriture PostGre)...

Il peut aussi être intéressant de tester dézippé pour voir la part que le zip prends dans l'exécution.

Et après effectivement de réfléchir à des solutions alternatives.

Hope it helps.

Bye

[David_1]

Merci à Toons et Carlos pour vos propositions.

L'option proposée par Toons me fait consommer beaucoup plus d'espace disk. Je suis en phase de POC pour l'instant et je n'ai pas forcement l'infrastructure que va avec.

Bien que l'option de Carlos nous renvoie sur une  problématique SQL Server, c'est déjà un levier que j'utilise en pré-requête SQL de mon mass loader :

ALTER TABLE nom_de_table SET UNLOGGED;

TRUNCATE nom_de_table;

L'option proposée par Stéphane m'a permis de réduire un peu la durée du traitement en voyant que mes transformations sur le fichier gz prenaient +/- 25% du temps. J'ai donc corrigé mon workflow.

J'ai fait des tests avec d'autres outils aussi.

C'est surtout la lecture et la transformation qui pèsent dans le traitement. L'écriture en base prend à peine 1 heure.

J'en arrive à la conclusion que travailler quelques 26 millions de lignes sur 650 colonnes, et de les pousser en base, ca prend du temps.

Merci à tous,

[mathieuf]

Bonjour @David_1,

En complément des réponses très pertinentes que tu as déjà reçu, as-tu fais des tests avec le moteur AMP :

Nous obtenons de beau gain en fonction du workflow et des outils utilisés : https://community.alteryx.com/t5/Engine-Works/AMPlify-your-Workflows/ba-p/617590

[David_1]

Bonjour mathieuf,

Merci pour ton suivi.

Effectivement j'utilise la fonctionnalité AMP pour ma partie Data Préparation.

J'ai compartimenté mes tâches :

1. Récupération des archives sur sftp et décompression en local (10 x 1,5Go qui deviennent 10 x 13Go) : 45 min

2. Lecture des fichiers et nettoyage (attribution de noms d'entête, sélection de colonnes, normalisation de certaines colonnes) : 1h50

=> pour cette partie là, l'AMP engine apporte beaucoup

=> j'ai aussi modifié la mémoire allouée au traitement en ajustant le paramètre à 8Go (au lieu des 2Go / 4Go par défaut)

=> les résultats de la data prép sont stockés aux formats optimises Database Alteryx (.yxdb) (10 x 3Go)

3. Mise en base des datasets via un bulk postgresql : 1h23

=> truncate table

=> drop des index

=> insert des lignes

=> création des index

Pour mémoire on est sur une base de 27 millions de lignes x 580 colonnes.

Dans l'idéal, je suis en "négo" pour accéder à un fichier différentiel. Ce qui serait bien plus optimum à mon sens.

Et par ailleurs, je test aussi une mise en base dans une mongo. Mais là faut que je réfléchisse encore un peu au modèle de données, en fonction des applications à mettre en place derrière.

Après, tous les prétextes sont bons pour éprouver les fonctionnalités d'Alteryx 😁. A chaque fois je constate que le potentiel de l'outil est énorme !!!😍😍😍

A+

[StephV]

Bonjour @David_1, 

Merci beaucoup pour ta participation au forum et ta question !

Si les réponses de @mathieuf , @StephaneP , @carlosteixeira , @Toons t'ont aidé, pourrais-tu les "Accepter comme solution", tu aideras ainsi d'autres utilisateurs Alteryx.

Merci beaucoup à toi et une très bonne journée !