Yop, Chargement et processing de données... sujet souvent mal aimé et mal connu :) Mais il se trouve que j'en ai fait pas mal. A l'époque j'avais codé ça (avec mes collègues de l'époque)...
http://sk.idm.fr/opensource/doc/skprod/ Je ne te recommande pas de t'en servir. C'est à l'abandon, c'est obsolète et c'est difficile. Mais j'ajouterais quelques pistes et réflexions, un peu en vrac. D'abord assure toi que tu sois bien CPU bound et pas IO bound, auquel cas le reste de la discussion deviendrait plus ou moins caduque. Performance "brute" et ruby ne font pas bon ménage. C'est embarrassant et frustrant, mais une réalité, et il faut faire avec. Donc partir sur du script ruby, avec ou sans AR pour gagner en perf... tu gagnerais au mieux marginalement, mais pas du tout un facteur d'échelle, et tu ne peux finalement scaler qu'en mettant un proc plus rapide. Heureusement, ruby n'est qu'un microcosme dont on a le droit de sortir :) En changeant d'environnement (donc exit ruby) tu peux déjà gagner un facteur constant si tu fais ton import sur un truc JVM based. On parle de langage qui compile nativement vers la JVM, là, donc java, scala, closure. (Pas JRuby, pas BeanShell. Pour Groovy c'est moins clair.) En java ou scala, tu peux raisonnablement espérer diviser ton temps d'éxecution par 2, 5 voire 10 si tu as de la chance. Perl ou Python se placeraient vraisemblablement quelque part entre ruby et la jvm. Pour pas se taper du code en java ou scala (moi j'aime bien scala, mais c'est pas le langage le plus facile à apprendre): - Talend, si je me souviens bien, c'est un IDE et un runtime dédié ETL. Tu définis ton process avec des rectangles et des flèches... (pas trop mon truc, je préfère le code au rectangles, je n'ai pas regardé depuis des années) - Hadoop... 1M de lignes, 1000 colonnes, on commence à arriver dans le domaine ou la grosse bertha peut être pertinente. Hadoop a en plus le mérite de scaler presque indéfiniment, ce qui peut être intéressant pour le processing, moins pour le loading parce qu'une fois que tu sature l'entrée de ta BDD... Même pour utiliser Hadoop, pas besoin d'écrire du java pour faire de l'ETL: entre pig (mon préféré), Hive (sql-like), et CSS, tu as au moins trois langages orientés manipulation de donnée. Il y a des "loaders" pour lire du CSV direct, des "connecteurs" hadoop/jdbc pour pousser directement tes données dans le SQL en fin de traitement. A noter qu'utiliser pig sur un laptop avec un setup hadoop standalone minimal ne pose aucune difficulté. Tu peux donc être opérationnel très vite. Une autre approche, complètement orthogonale, c'est de charger tes CSV directement dans des tables temporaires (pas temporaires au sens d'oracle) de faire les checks et corrections dans le SQL (soit avec des requêtes + des updates pour corriger chaque erreur détectée) puis de faire des SELECT INTO pour pousser les données corrigées dans la bonne table. En espérant trouver un ordre qui marche bien pour les foreign keys :) -- 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]
