Journal Le cauchemard de l'ETL

Posté par .
Tags : aucun
13
30
oct.
2009
De part mon activité, j'ai à travailler avec des flux de données provenant de sources multiples.
Introduction au cauchemard de l'Extract_Transform_Load avec des données formatées approxi-miteu-sement !

* Des fichiers XML ou les champs sont à 100% en CDATA..... (ils se sont déjà fait chier à faire des balises XML, alors faut pas leur demander de se préoccuper de la conformité de ce qu'elles contiennent! on ne parlera même pas de schema...)

* Des mix d'encodage de caractères dans un document XML

* Des mix d'encodage de caractères dans des champs CDATA ! (irrécupérable)

* Le problème précédent réparé par une suppression simple des caractères non ascii !

* De l'html dans des champs purement texte (ça vous va pas, démerdez vous)

* Des clés de données qui ... changent ! Tiens 100% des entrées on changé !? (je vous parle même pas des clés non uniques...)

* Des clés étrangères dont la cible... n'existe pas: ces clés étant calculées automatiquement pas rapport à la clé principale !

* des gens qui mettent des valeurs arbitraires pour des valeurs inconnues... (imaginez une quantité à 1.000.000, les dégats un prix à 1.00, des dates "bientot, sous peu" )

* Un génie qui décide que son application source limitera les requêtes à 3/jour en bloquant la réponse pendant 3 minutes et renvoyant un code HTTP 409 (Un au pif dans la RFC, sans se soucier du fait que c'était implicitement une demande de ré-essai ! On l'a tenu 2 mois ce bug avant son retour d'informations !)

* des jolis fichiers csv comme on faisait il y a 10ans, le tout produit en HTML. Si, Si, c'est possible: une ligne csv par paragraphe !

* Des génies qui ont tout compris à l'XML:
< a >
< nomchamp >bidule< /nomchamp >
< valeurchamp >valeur< /valeurchamp >
< nomchamp >bidule2< /nomchamp >
< valeurchamp >valeur2< /valeurchamp >
< / a >


Et on ne parle que des formats. Je ne vous relate pas les hérésies quand les champs de données doivent avoir une valeur explicite ou un minimum qualitatif.

Le plus grave dans tout cela ? Il s'agit principalement d'enseignes bien connues de l'internet ou de leurs intermédaires.

"xmllint"... hein ?!? Des dev à mettre dans le même panier que les admins tutos, les web cébo, ...

Et vous, le "ça nous semble correct, si ça va pas démerdez vous" c'est aussi au quotidien ?
  • # Pour un titre sans faute

    Posté par . Évalué à 10.

    et parce que c'est malheureusement une erreur trop courante ; cauchemar ne prend pas de 'd'.
  • # XML

    Posté par . Évalué à 1.

    Le top que j'ai vu, c'est des messages XML reçus par JMS qui n'étaient pas valide XML....

    Si c'est valide XML, de quoi tu te plains ?
    • [^] # Re: XML

      Posté par (page perso) . Évalué à 4.

      Si les encodages sont foireux, je doute que ça soit valide XML (ou alors, par chance, ils n'utilisent que des valeurs qui ont un sens dans le charset déclaré au hasard ;-).
      • [^] # Re: XML

        Posté par . Évalué à 3.

        Bien sur que l'XML est valide ! Du point de la syntaxe... car pas de schéma ni de DTD.

        Le charset du document ne valide que les balises: Comme tout est en CDATA, impossible d'avoir une gestion du charset présent dans ces sections par du xml ou xslt...

        Quand le charset ne diffère pas entre les sections !
  • # presque pareil

    Posté par . Évalué à 4.

    moi c'est plutot ,juste la fin :
    si ça va pas démerdez vous
  • # Pareil

    Posté par (page perso) . Évalué à 5.

    Je fais de l'analyse vidéo, et combien de fichiers pourris je peux trouver...

    Côté norme :
    * Des normes qui laissent un nombre de questions en suspens (et donc la réponse est différente suivant qui implémente)
    * Des normes qui compliquent la vie, peu lisibles, donc les développeurs simplifient ou comprennent de manière différentes (et je les comprend)
    * Des normes qui utilisent plusieurs nom pour un même champs, mais dans des chapitres différents (à toi de retrouver qui va avec qui)
    * Des normes US-centric (codage de caractères? Bah US-ASCII, allez je laisse du 8 bit mais gardez vos fichiers dans votre pays, sinon ça va merder)
    * Pareil pour l'heure, UTC c'est chiant, allez on force la structure du champs en oubliant la partie "timezone", c'est pas utile (norme... Américaine! ils ont plusieurs timezone chez eux mais n'en voient pas l'utilité...)

    Côté développeurs :
    * Une norme? Bah tant que ça marche dans un player laxiste, c'est bon, c'est que ça doit être valide
    * une norme spécifie un codage de caractère? Trop chiant je met le codage local, rien à faire de la norme.
    * 02/03/2009 ne veut pas dire 2 mars 2009, mais 3 février 2009, mais les américains sont le centre du monde, donc tout le monde doit faire pareil... Sympa les échanges informatique ensuite. Utiliser 2009-02-03 est trop chiant, la flemme.
    * ...

    Et ce, que ce soit grand organisme (ISO...) ou grandes entreprises (et pas que Microsoft...).

    Bref, c'est partout pareil, et il faut vivre avec, c'est la communication entre le gens... Et on se démerde.
    • [^] # Re: Pareil

      Posté par . Évalué à 4.

      Sache que tout ce que tu as dit peut aussi s'appliquer dans les normes télécoms (3GPP par exemple). Un certain nombre de bugs viennent d'interprétation des normes différentes selon chacun.
      • [^] # Re: Pareil

        Posté par . Évalué à 5.

        Aaaaaaaaah les normes 3GPP et leurs interprétations. Croyez moi, j'ai le nez dedans, vous êtes pas prêt de téléphoner en 4G !
  • # Fais en profiter d'autres...

    Posté par . Évalué à 10.

    Envoie ton histoire sur The Daily WTF notamment (http://thedailywtf.com/) qui a d'ailleurs ouvert une section française il y a de cela quelques temps. Ton histoire colle bien avec ce qu'on y trouve d'habitude.

    The Daily WTF est un recueil d'histoires et de moments de vie dans le milieu des DSI, des développeurs et des daissïdors pressés qui ne comprennent rien à l'informatique. Les histoires relatent moult projets foireux, mal ficelés ou gérés par des incompétents. Avec - entre autres - les mots de passe vérifiés côté client en Javascript, le développeur qui utilisait sa base de données SQL comme un classeur Excel, l'entreprise de 1.000 personnes dont tout le carnet de commandes était géré dans un fichier Access de 700 Mo (ouvert sur plusieurs postes, cela va de soi), etc etc etc...

    Depuis que je lis The Daily WTF, je n'ai plus honte de coder "salement", l'expérimentation et le crade ne me font plus peur, car je sais qu'il y a beaucoup, beaucoup plus fort que moi sur la planète.

    Voilà voilà, bonne perte de productivité à la lecture de ce site et à bientôt !
    • [^] # Re: Fais en profiter d'autres...

      Posté par . Évalué à 3.

      Depuis que je lis The Daily WTF, je n'ai plus honte de coder "salement", l'expérimentation et le crade ne me font plus peur, car je sais qu'il y a beaucoup, beaucoup plus fort que moi sur la planète.

      C'est vieux, ç'a été dit et redit mais...

      ... sous prétexte qu'il y a pire, tu ne fais pas d'efforts ?
  • # C'est plutôt sympa

    Posté par . Évalué à 3.

    Ca arrive...

    Perso, j'aime bien, ça me donne l'opportunité de changer ça en qqch de propre. Un beau code bien fait, à la fin, ça fait plaisir :-)

    En revanche, d'expérience, un client qui te fournit du code comme ça n'est pas un bon client. Ca signifie qu'il n'a pas de contrôle interne au niveau dev, et probablement pas dans le reste de son activité. Dans 2 ans, il sera crevé ; ou il y aura eu une réorganisation qui, en plus de théoriquement faire améliorer le code, te retirera ton contrat. Par exemple, confier une réécriture totale à une SSII.
  • # Te plain pas !

    Posté par (page perso) . Évalué à 3.

    Oui tu n'as aucune raison de te plaindre parce que toi au moins tu as un ETL pour faire ça !
    Tout les jours on m'envoie des fichier CSV qui doivent être transformé en SQL qui va bien puis injecté dans des tables MySQL et tout ça uniquement avec du PHP ...

    Notre solution est une agression directement a la source pour envisager qu'on nous fournissent directement quelque chose d'exploitable.
    • [^] # Re: Te plain pas !

      Posté par . Évalué à 2.

      Ben non justement, les ETL ne savent pas gérer ces fichiers "pourris".
      On se retrouve à faire des heures de développement de code pour corriger leurs lacunes, quand c'est possible.

      Tiens j'ai oublié de mentionner: Le fichier simple "compressé" mais dans un tar.gz ou un zip...
  • # Problème inverse pour moi...

    Posté par . Évalué à 2.

    Moi, c'est pas le XML qui était tout pourri, c'était l'appli en face qui ne savait récupérer correctement... une date [[ISO 8601]] !

    Explication : j'avais une appli en Java à faire évoluer. Elle devait parler à un Web-Service (développé en .Net, ça a son importance), via SOAP. Pour ce dernier, c'est la librairie Axis qui était utilisée.
    Cette librairie génère des classes Java, en fonction d'un WSDL (et de XSD) donnés en entrée. Pour un champ "xsd:DateTime", elle utilise la classe Calendar de Java.
    Lors de l'envoi des données, la date est générée au format ISO 8601, en utilisatn le fuseau 'Z' (heure UTC), après avoir appliqué correctement le décalage horaire heure française -> heure UTC.

    Mais en face, c'est une classe DateTime de .Net, qui est utilisée ! Et cette dernière ne sait pas gérer les fuseaux : elle garde telle quelle la date (et l'heure) qu'on lui donne... et la stocke telle quelle ensuite en base de données !

    "Facile : y a qu'à utiliser la classe Calendar de .Net, au lieu de la classe DateTime !"... Sauf que non ! D'autres applis utilisent déjà ce Web-Service, et fonctionnent toutes avec la classe "DateTime", donc le bug n'apparait pas. Et donc impossible de modifier le Web-Service, car effets de bord garantis...

    Bref, il a fallu pourrir la seule appli qui fonctionnait correctement, en faisant la seule chose à ne pas faire : rajouter le décalage "heure française -> heure UTC" dans l'objet Calendar, avant de l'envoyer...
    /me a honte !
    • [^] # Re: Problème inverse pour moi...

      Posté par (page perso) . Évalué à 4.

      c'est une classe DateTime de .Net, qui est utilisée ! Et cette dernière ne sait pas gérer les fuseaux
      Ah si, DateTime sait gérer les fuseaux. Après que le développeur sache pas utiliser DateTime c'est un autre problème.
    • [^] # Re: Problème inverse pour moi...

      Posté par (page perso) . Évalué à 5.

      Exemple :

      [WebMethod]
      public string HelloWorld(DateTime dt)
      {
      var alt = dt.ToUniversalTime();
      return String.Format("{0} ({1}) <=> {2} ({3})", dt, dt.Kind, alt, alt.Kind);
      }


      requête SOAP avec en paramètre : 2009-03-02T17:55:13.47Z
      résultat obtenu :
      02/03/2009 18:55:13 (Local) <=> 02/03/2009 17:55:13 (Utc)
      • [^] # Re: Problème inverse pour moi...

        Posté par . Évalué à 4.

        Et "fromUniversalTime()", c'est possible ? Parce que quand j'ai dit que DateTime ne gérait pas les fuseaux, c'était parce que le développeur du Web-Service me l'avait affirmé...
        Après, j'ai pas cherché non plus, vu qu'il m'avait dit qu'il était hors de question de toucher au code, parce que "ça marche très bien comme ça, actuellement"
        • [^] # Re: Problème inverse pour moi...

          Posté par (page perso) . Évalué à 2.

          Si si y'a moyen de bidouiller, mais le comportement par défaut est tout à fait correct. Après je sais pas comment il a codé son web-service, il bidouille peut être le datetime avant de le stocker, va savoir.
  • # plist

    Posté par . Évalué à 7.

    * Des génies qui ont tout compris à l'XML:
    < a >
    < nomchamp >bidule< /nomchamp >
    < valeurchamp >valeur< /valeurchamp >
    < nomchamp >bidule2< /nomchamp >
    < valeurchamp >valeur2< /valeurchamp >
    < / a >
    [...]
    Le plus grave dans tout cela ? Il s'agit principalement d'enseignes bien connues de l'internet ou de leurs intermédaires.


    Moi je sais, moi je sais ! C'est appeul pas vrai ? http://developer.apple.com/mac/library/documentation/Darwin/(...)
  • # Reccord à battre

    Posté par . Évalué à 2.

    De mémoire ca donnait un truc comme çà :



    </rapport values="toto='1',tutu='{if tata<>0 then 1 else select monchamps from matable where truc end}', .... , rendu='echo \"\<html\>\<body\>{$tutu}\</br\>{$tata}....\</html\>\"' '"



    De façon général toutes les branches de l'arbre s'appellaient rapport. On a vu trainer une branche debug une fois (mais après un appel au support, les fonctions de debug ne sont pas accessibles sur le logiciel client).

    Pour un logiciel de reporting...

    Et je compte pas les innombrables cas de transformation XML qui transforment
    [section]
    requete = 'select pleinsdetruc from matable'
    droits='users'
    destination='\\fileserver\disque\repertoire'
    ....

    En

    requete = 'select pleinsdetruc from matable'
    droits='users'
    destination='\\fileserver\disque\repertoire'
    ....
  • # Compassion

    Posté par . Évalué à 1.

    J'ai donné aussi un peu dans le domaine et sous prétexte d'avoir mis leur *merde* dans le XML ben c'est de l'or en barre !

    Je trouve que l'on retrouve beaucoup trop de XML sans XSD ou RelaxNG digne de ce nom qui éviterait bien des complications.

    Personnellement, j'ai utilisé SSIS (de chez M$) et je crois que je n'en suis pas encore remis...
  • # CSV FTW

    Posté par . Évalué à 2.

    On dira ce qu'on voudra, mais un fichier CSV ça a de nombreux avantages :
    * pérenne tout autant que son mapping (le plus pérenne possible)
    * facile à traiter
    * facile à analyser par Kevin du service IT quand son batch plante
    * facile à archiver

    C'est pas la solution idéale, bien entendu qu'on a pensé à mieux depuis et heureusement que tous les échanges ne se font pas par fichiers CSV (manquerait plus que ça), MAIS en entreprise et surtout pour du one-shot ça fonctionne et ça permet de tenir les délais sans bullshit et/ou prise de tête entre services.
    • [^] # Re: CSV FTW

      Posté par . Évalué à 2.

      Le CSV est un moindre mal mais le support multiligne est souvent manquant dans beaucoup de librairies.
    • [^] # Re: CSV FTW

      Posté par . Évalué à 2.

      * des colonnes qui s'insèrent ou disparaissent comme bon leur semble
      * pas de charset
      * une redondance d'informations en relation directe avec la cardinalité des éléments
      * J'ai besoin de te citer le nombre de cas où on trouve le délimiteur dans les champs ?
      • [^] # Re: CSV FTW

        Posté par (page perso) . Évalué à 2.

        * J'ai besoin de te citer le nombre de cas où on trouve le délimiteur dans les champs ?

        Virer le développeur : la norme est précise sur ce point. (comme pour les retours à la ligne)
        • [^] # Re: CSV FTW

          Posté par . Évalué à 3.

          Il n'y a pas de norme officielle pour le CSV, c'est bien le problème.
          Déjà tu as généralement le choix entre la virgule (comme le nom l'indique) le point-virgule et la tabulation comme séparateur de champ, ensuite le caractère qui protège les champs (pour le multiligne notamment) peut être un simple ou double quote et tout le monde n'est pas d'accord sur la façon de protéger ce caractère à l'intérieur des champs (j'ai vu des cas où il était précédé d'un backslash plutôt que de le doubler, probablement un développeur qui a fait ça en vitesse sans chercher de doc).
          • [^] # Re: CSV FTW

            Posté par (page perso) . Évalué à 2.

            Il n'y a pas de norme officielle pour le CSV, c'est bien le problème.

            Il y a la RFC 4180 :
            http://www.rfc-editor.org/rfc/rfc4180.txt
            "Common Format and MIME Type for Comma-Separated Values (CSV) Files"
            (bon, OK, "que" 2005, mais elle existe)
            Si il n'y a pas de norme pour le CSV aujourd'hui, il n'y a pas de norme pour HTTP non plus alors (RFC aussi, pas plus).

            Et c'est en tous cas celle qu'on me demande aujourd'hui de respecter quand je fournis du CSV à des organisations.

            Tes exemple sont du CSV "fait maison" (Microsoft fait du "fait maison" sur les version non-US d'Office, quelle plaie.), il est certes vrai qu'avant 2005 il n'y avait pas de norme précise donc chacun (dont moi) faisait un peu comme il voulait... Mais ce n'est plus le cas depuis 4 ans, les nouveaux projets n'ont plus d'excuse.
            • [^] # Re: CSV FTW

              Posté par . Évalué à 5.

              Ah intéressant.
              Sauf que ça arrive trop tard, à peu près à cette période je cherchais une petite bibliothèque en java pour lire/écrire facilement du CSV, j'ai pas trouvé et je l'ai écrit moi-même (c'est pas franchement compliqué, ce qui est une des raison de toutes les variantes) et j'ai cherché une spécification. Je n'ai pas trouvé cette RFC mais plusieurs explications et j'ai décidé qu'il fallait prendre en compte les différentes variantes, donc trois séparateurs différents et deux quotes différents.

              Et même avec ça on a des clients qui ne s'en sortent pas, quand ils exportent en CSV avec excel celui-ci choisit automatiquement le séparateur de champ en fonction des paramètres régionaux et les clients ne savent pas quoi choisir lors de l'import. C'est pire dans l'autre sens, si on n'a pas choisi le bon ils ont toute la ligne dans la première cellule.
              Au moins OOo (et tous les autres tableurs que je connaisse) proposent automatiquement de choisir les options de chargement.

              De toute façon, depuis les décennies que que des programmeurs font du pseudo-CSV chacun à leur sauce, cette RFC bien tardive risque de ne rester que ça, une request for comment<:i>.
          • [^] # Re: CSV FTW

            Posté par . Évalué à 0.

            http://tools.ietf.org/html/rfc4180

            6. Fields containing line breaks (CRLF), double quotes, and commas
            should be enclosed in double-quotes. For example:

            "aaa","b CRLF
            bb","ccc" CRLF
            zzz,yyy,xxx

            7. If double-quotes are used to enclose fields, then a double-quote
            appearing inside a field must be escaped by preceding it with
            another double quote. For example:

            "aaa","b""bb","ccc"
      • [^] # Re: CSV FTW

        Posté par (page perso) . Évalué à 2.

        * J'ai besoin de te citer le nombre de cas où on trouve le délimiteur dans les champs ?

        le caractère µ est bien pratique pour cela ;-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.