Bonjour à tous, je poste ici suite à un appel téléphonique avec Sylvain pour mieux comprendre sa situation :)
J'applique le principe suivant depuis 2006: j'utilise ruby pour sa souplesse (généralement avec activewarehouse-etl ou avec une version légère que je n'ai pas publié, ou du ruby maison qui fonctionne sur les mêmes principes), et j'optimise au fil de l'eau selon le besoin. Après avoir travaillé pas mal avec des ETL plus classique (comme SSIS chez Microsoft), je travaille beaucoup en mode "ligne à ligne" ce qui reprend un peu l'esprit de ces ETL (voir ici pour un exemple<https://github.com/activewarehouse/activewarehouse-etl-sample/blob/master/etl/import_new_commits.ctl> et ici pour un autre<https://github.com/activewarehouse/activewarehouse-etl-sample/blob/master/etl/prepare_user_dimension.ctl> ). Quand et si la perf pose problème à un moment (ce n'est pas toujours le cas loin de là), je mesure le bottleneck et j'optimise graduellement avec différentes techniques: - je sous-traite à d'autres commandes ou outils (ex: iconv, grep, tail/head, bcp/freebcp) - j'utilise du bulk insert - j'utilise du bulk upsert: sortie en fichier délimité, puis import dans une copie de la table cible, puis utilisation de commandes comme MERGE dans SQLServer ou INSERT ON DUPLICATE KEY UPDATE dans MySQL par exemple - je passe en incrémental: je conserve le timestamp du dernier extract, puis je n'extrait que ce qui a été ajouté, modifié ou effacé depuis ce dernier timestamp (pour les effacements il existe différentes techniques) - je pré-process pour réduire la taille et ne conserver que les données utiles (rarement vraiment utile sauf cas extrême, fichiers très pollués etc) - j'utilise du cache ou de la RAM - je booste la perf brute (passage à Ruby 1.9, machine plus puissante etc) - plus exotique et pas vraiment nécessaire en général si on a déjà travaillé avec les points ci-dessus: paralléléliser en multi-process, ou multi-machines, ou faire une extension custom dans un langage comme Java, C# ou C/C++... - il m'est déjà arrivé d'utiliser Ruby et de sous-traiter à un autre ETL (ex: SSIS), mais je n'ai plus eu ce besoin depuis longtemps Plutôt que d'utiliser ActiveRecord ligne à ligne, je vais plutôt travailler avec des screens comme décrits dans le livre de Ralph Kimball cité par Archiloque. Exemples: - il est plus rapide de faire un screen qui va faire un select distinct sur la table temporaire avant son merge dans la table finale, que de demander à ActiveRecord de vérifier l'inclusion de tel champ à chaque ligne - il est plus rapide de mettre en cache des ids dans une variable d'instance ruby, voire, dans Redis, que de vérifier l'existence en base plusieurs fois - et ainsi de suite Par ailleurs il faut bien identifier son besoin, par exemple: - export de données d'un système pas souple pour faire une géolocalisation dans une appli sinatra/rails (lecture seule + enrichissement)? - synchro complète de données dont la cible est une appli où les records doivent être valides pour AR? - glue Ruby pour faire parler deux systèmes rigides (ex: un CRM en Java d'un côté, un mainframe COBOL de l'autre)? - extraction d'un modèle applicatif (= "transactionnel") vers un modèle plus "dimensionnel" ou orienté reporting? - quel volume actuel et quel volume prévu? Si on ne comprend pas bien le besoin on va se compliquer à respecter des contraintes non nécessaires ou à optimiser là ou ça n'est pas (encore, ou peut être jamais) utile. Côté activewarehouse-etl, voici ma position: - j'ai récupéré le projet en maintenance depuis juin 2011 - j'ai consolidé les différents patchs pour Rails 3 / Ruby 1.9 - je prépare tranquillement une nouvelle release qui contiendra tout ça et je vais continuer à le maintenir - par ailleurs je vais débuter un fork inspiré qui reprendra de zéro, en appliquant grosso modo les mêmes principes mais avec une codebase mieux testée et plus flexible dans le but de faciliter la contribution et la maintenance, et de pérenniser le projet (même si activewarehouse-etl est facile à étendre aujourd'hui) Voilà - en espérant avoir été utile! Thibaut -- http://www.logeek.fr -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected]
