Chaque semaine, découvrez de nouvelles astuces et bonnes pratiques pour devenir un expert !
Voir l'indexHello, all is in the title 🙂
I have two yxdb files, with same data inside (I made a comparison workflow, row by row, field by field).
But filesizes are quite different, for example 140120 Ko and 155396 Ko
I suppose it depend on the file format itself, using some compression algorithm.
It is so difficult to use this file format for data snapshots, because we intend to think there is data difference between files, whereas there is no.
Résolu ! Accéder à la solution.
Bonjour Nicolas,
I guess if you are posting on the French forum you are speaking French. If not you should post your question here: English Designer Forum
So I am switching in French.
1er point. A données et format équivalent l'algorythme de compression du .yxdb donne la même taille.
Comment es tu arrivé à la conclusion que ce sont les mêmes données ?
Cette hypothèse est importante. Le processus de création de ces 2 Yxdb est important.
j'ai l'impression aussi que tu as 2 workflows, voir 2 fichiers sources distincts si qui peux causer de nombreux écarts.
Pour moi le seul vrai test est de lancer 2 fois le MEME workflow sur le même fichier source. Si tu n'as pas la même taille de .yxdb à la sortie alors oui il y a un souci. Sinon c'est une autre cause.
Et je pense au formatage des données ou au formatage du fichier source.
On peut avoir les mêmes données dans 2 fichiers qui ont des tailles différentes du fait du formatage des champs de stockage. Un champs V_String(200) prends plus de place qu'un champs V_String(190). Un 0, un NULL ou un EMPTY ne prennent pas non plus le même stockage.
Il se peut que les workflows ne génèrent ou ne gèrent pas exactement les mêmes formats ou que les fichiers sources aussi n'ai pas ce même format.
Typiquement certains classeurs Excel, pour des mêmes données peuvent avoir une petite différence de format qui au final impactera la taille de ton .yxdb
Pour valider ce point tu peux étudier les formats via ce menu dans ton designer:
Si pour une raison X ou Y tes formats varient (ex: utilisation du bloc "Champs automatique" dont l'objet est justement de générer des formats variables pour optimiser le stockage) il y a des méthodes pour éviter ces variations.
A noter aussi qu'avec la dernière version d'Aleryx tu peux comparer automatiquement des workflows... Trés pratique dans ton cas.
N'hésites pas à revenir avec plus de précision pour que nous puissions investiguer ensemble.
Bonjour Stéphane,
Désolé pour l'erreur de forum, en fait j'ai pris l'habitude poster en anglais pensant que les réponses de la communauté "US" étaient plus pertinentes que celles de la français, mais je vois que ce n'est pas forcément le cas 😉
_ Pour revenir à mon point, c'est le même WF qui a créé les 2 fichiers, à 6min d'intervalle, par une "photo" de données de prod d'une table SAP HANA.
_ Je viens de vérifier les méta données avec le field info, elles sont identiques.
_ J'ai le même nb de lignes, et j'ai vérifié champ par champ (suite à une transposition) et toutes les valeurs sont identiques.
_ Plus le fichier est gros, plus l'écart est grand : sur un fichier de 140 Mo la différence atteint 5 Mo
_ Ci-joint ex. de 2 fichiers plus petits
Le WF qui a pris les photo est très basique :
Bonjour @NicolasFabre81 ,
Effectivement c'est étrange...
Je ne vois pas d'écart ni coté data, ni coté métadata...
Lorsque je réécris ces données je retombe sur les mêmes tailles pour les 2 fichiers.
Utilises tu le mode AMP pour ce workflow ? Cela peux impacter les tailles des fichiers.
(je ne pense pas que cela vienne de là puisque je ne suis pas dans ce mode et que je génère la même taille, mais dans le doute...)
Je penche pour des métadatas du fichier qu'on ne vois pas. Je continu de mener l'enquête.
Bonne journée,
Non je ne connais pas AMP ... A mon avis c'est soit effectivement des méta données (mais l'écart en taille semble très important quand même), soit un aléa induit par l'algorithme de compression qui génère le format YXDB ... Je parie là-dessus !
Pour avancer dans notre enquête peux tu tester en décochant cette option lorsque tu génères les .yxdb à la sortie ?
Et voir si cela continu de varier ?
Si non c'est que cela vient des descriptions, si oui c'est que cela vient du mode de compression je dirai.
Du coup, j'ai l'explication.
En fait le niveau de compression dépend des ressources machine à disposition lors de cette étape.
Ce qui explique qu'à même données le niveau de compression varie (si moins de Ram ou de proc).
Donc bonne nouvelles il n'y a pas d'altération des données.
En revanche dans le cas des fichiers compressés type .yxdb (et sans doute Zip aussi) suivre la taille des fichiers n'est pas un indicateur direct de la taille du contenu source.
A ne pas utiliser pour détecter les variations donc.
Hope it helps.
Merci pour votre implication dans la recherche ! Mais dommage car ce format est bien pratique et approprié pour des snapshot de données vu qu'il y a la compression. La prochaine fois je passerai en CSV pour ce genre de besoin.
Il est possible aussi de comparer les données des 2 fichiers de données via un workflow (en utilisant le Unique tool ou le Transpose) mais cela peut être gourmand en temps de traitement. A voir donc ce qui est le plus rapide dans ton cas. Générer un .csv ou ouvrir les .yxdb et les comparer.
Pour info, un lien vers des méthodes de comparaison de données via Alteryx: https://community.alteryx.com/t5/Alteryx-Designer-Discussions/Comparing-Data-from-Two-Sets-of-Data-C...
oui j'ai fait avec le transpose, c'est là que je me suis rendu compte que les fichiers étaient identiques malgré la taille différente...