.Rhino ETL voor prijsvergelijker

[Joppiesaus2]

Op dit moment wordt de laatste hand gelegd aan een prijsvergelijker die voor mij is ontwikkeld. Deze prijsvergelijker is gebaseerd op .net en leest datafeeds in van verschillende webshops om zo actuele prijzen en aanbiedingen naar de database te halen.

Momenteel zijn er twee parsers geschreven voor 2 soorten specifieke feeds. Voorbeelden van deze formaten:
1. Tradetracker formaat: http://pf.tradetracker.ne...ryType=2&additionalType=2
2. Affiliate4you formaat: http://affiliate4you.nl/p...dv=143&subid=884&type=xml

De bedoeling is juist dat we voornamelijk rechtstreeks afspraken gaan maken met webshops en ook rechtstreeks feeds van vele verschillende partijen gaan inlezen. Dit betekend dat er naar onze database vele verschillende formaten correct ingelezen moeten worden. Een kenner qua ETL weet dat datafeeds onderling op een hoop ‘punten’ van elkaar kunnen verschillen.

Ik zoek daarom een flexibel systeem welke het mogelijk maakt voor mij om de juiste data uit de feeds te koppelen aan de juiste data in eigen database zodat er niet voor iedere nieuwe klant een programmeur aan te pas hoeft te komen om alles in te stellen.

Ik heb me laten vertellen dat .rhino een prima open source ETL code is om dit probleem te tackelen.

Vraagjes:
1. Is .Rhino ETL hier een geschikte keuze voor?
2. Welke problemen kan ik verwachten met het inlezen van verschillende feeds (eigenlijk gewoon een korte samenvatting met ervaringen betreffende dit probleem en hoe dit het beste kan worden opgelost) waar ik ook rekening mee moet houden wanneer ik deze klus zou uitbesteden
3. Aan hoeveel uur moet ik denken om een dergelijk systeem te implementeren door een professional (als .Rhino hier niet geschikt voor is met een ander)
4. Heeft iemand hier ervaring mee en kun je me hier meer handige tips over geven / ervaringen delen?

Hopelijk zitten hier mensen die bekend zijn met het probleem! Tips hoor ik dan ook erg graag!

groet.

[cariolive23]

Offtopic: Het voorbeeldje dat je hier geeft van de XML van Tradetracker voldoet niet aan hun eigen DTD. Het is dus een ongeldig bestand... field eist een attribuut "value", deze ontbreekt echter.

De XML van Affiliate4you is een soortgelijk drama, zij zetten alles maar in CDATA zodat je helemaal niets meer kunt valideren....

Met dit soort XML's kun je dus de nodige problemen verwachten, genoemde bedrijven hebben niet de kennis in huis om fatsoenlijke XML op te stellen. Daar kun jij (of diegene die jij inhuurt) niets aan doen, maar het gaat wel extra tijd en dus geld kosten.

.rhino ken ik niet, kan ik geen oordeel over vellen. XML is (normaal gesproken) eenvoudig met XSLT om te zetten naar SQL en dus eenvoudig in een database weg te schrijven. Per feed mag dat niet meer dan 1 á 2 uur tijd kosten. Per feed heb je dan een eigen XSLT nodig, dat geeft je veel flexibiliteit en dit is eenvoudig te implementeren.

Welke database gebruik je?

[Joppiesaus2]

- Offtopic: deze feedlink komt rechtstreeks uit mijn tradetracker account, komt er dus op neer dat zij verkeerde formats aanleveren? Momenteel wordt dit formaat ook gebruikt om te testen en met de huidige parser werkt dit wel...

- Naast XML is CSV ook eenveelgebruikt format, deze zou dus ook moeten werken. Als het 1 a 2 uur er feed kost is het wellicht beter om per feed een programmeur te vinden die dit wil koppelen?

- Toch ben ik geinteresseerd om te weten wat zo'n totaaloplossing met zich meebrengt en of .Rhino hier geschikt voor is (kreeg dit als advies mee van iemand die vrij veel ervaring heeft dat het hiermee wel moet kunnen, maar hij is zelf niet beschikbaar dus kan ook geen indicatie krijgen wat er bij komt kijken of wat de overige mogelijkheden zijn)

- Ik meen dat de database SQL is, maar ik zal dit morgen nog even navragen.

[cariolive23]

csv is een handiger formaat voor grote hoeveelheden data en in dit geval voegt XML ook niks toe. Normaal is XML handig omdat je het kunt valideren, dat wordt door beide leveranciers reeds onmogelijk gemaakt. Wanneer dat voordeel wegvalt, hou je alleen de nadelen over: veel overhead. Met CSV is nog eenvoudiger om een import te maken, iedere database kent mogelijkheden om csv-bestanden te importeren. Gooi dit in een tijdelijke tabel en ga vervolgens de boel netjes normaliseren.

Ik zou per feed een/de programmeur een opdracht geven, dat houdt het voor jou overzichtelijk. Wanneer je een complex datamodel hebt, is het wel handig om slechts één programmeur te gebruiken. Die kent na een paar feeds het datamodel wel.

- Ik meen dat de database SQL is, maar ik zal dit morgen nog even navragen.

En over welk smaakje SQL heb je het dan? PostgreSQL, SQL Server, MySQL, etc. etc. etc. SQL is een taal, geen database.

[Joppiesaus2]

Dank voor je antwoord.

- Ik zit qua formats ten eerste veelal vast aan wat ik aangeleverd ga krijgen. Ik moet dus kunnen "lezen" wat ik kan krijgen..

- Jij denkt dat het 1 á 2 ur is om een feed goed te zetten voor implementatie? Ik keeg 8 uur voorgerekend, dat leek mij al wat pittig..maar dat is het dan ook echt?

- Zou .Rhino (http://ayende.com/Blog/archive/2008/01/16/Rhino-ETL-2.0.aspx) nog een in zoverre een toevoeging kunnen zijn dat wanneer het geimplementeerd is het de 1/2 uur koppeltijd drastisch doet verminderen? Zo ja, hoe lang vermoed je dat het duurt om deze code te installeren in een "vreemde" database (dus die van mij wanneer een programmeur aan het werk gaat?)

Is het daarnaast mogelijk om er een GUI omheen te maken zodat iemand zonder code kennis (lees ik ) ook kan koppelen?

- Smaak SQL ga ik navragen, ik vermoed MySQL, maar weet het niet zeker.

[ Voor 7% gewijzigd door Joppiesaus2 op 03-09-2009 18:00 ]

[D-Raven]

Wij gebruiken een afgeleide van Rhino ETL.

1. Is .Rhino ETL hier een geschikte keuze voor?

Ja. Rhino ETL is een framework gemaakt om formaat x naar formaat y om te zetten. of x nu een database of textfile is maakt niet uit, zelfde geld voor y.
Maar wat jij verder wilt is een applicatie waarin jij wat kan rondklikken en rondslepen en zo een import voor jou database structuur in elkaar te zetten.
Dat is iets wat Rhino ETL niet doet en iets wat je dus helemaal zelf van scratch moet opbouwen.

2. Welke problemen kan ik verwachten met het inlezen van verschillende feeds (eigenlijk gewoon een korte samenvatting met ervaringen betreffende dit probleem en hoe dit het beste kan worden opgelost) waar ik ook rekening mee moet houden wanneer ik deze klus zou uitbesteden

De opbouw en indeling van de feeds onderling kunnen natuurlijk behoorlijk verschillen. Hoe groter het verschil tussen de data structuur in de feed en je datamodel hoe meer werk. Je moet immers meer operaties implementeren. Verder kan ik er weinig over zeggen, de specifieke problemen zijn namelijk direct gelieerd aan jou datastructuur en de structuur waarvan je het wilt converteren.

3. Aan hoeveel uur moet ik denken om een dergelijk systeem te implementeren door een professional (als .Rhino hier niet geschikt voor is met een ander)

Een professional, daarmee bedoel je iemand die al ervaring heeft met Rhino ETL.
Zo iemand zal iig geen probleem hebben om een custom process te bouwen met de bijbehorende operaties voor het inlezen en wegschrijven van de data. Daar zul je dus tijd uitsparen.
Maar je moet er wel rekening mee houden dat voor elk nieuwe import formaat op zijn minst een eigen set operations geschreven moeten worden.
_{Tenzij je natuurlijk iets maakt wat die dingen voor je kan genereren (via code generation of het dynamisch genereren van boo code files en deze dan runtime te laten interpreteren).}
Hoeveel dat dan kost is weer afhankelijk van het import formaat. Als je iets simpels hebt, zoals een csv bestand. Dan zal het bouwen van een ETL process waarschijnlijk een stuk minder lang duren als dat je een of ander gaar XML bestand hebt.

In ieder geval kun je 1 a 2 uur rustig uit je hoofd zetten. De 8 uur die er eerder genoemd werd is meer realistisch getal (per import formaat). Je moet naast het implementeren ook dat ding testen. Dat kost allemaal extra tijd.
Bottomline, hoe complexer het import formaat hoe langer het gaat duren.

[D-Raven]

Joppiesaus2 schreef op donderdag 03 september 2009 @ 17:57:
- Zou .Rhino (http://ayende.com/Blog/archive/2008/01/16/Rhino-ETL-2.0.aspx) nog een in zoverre een toevoeging kunnen zijn dat wanneer het geimplementeerd is het de 1/2 uur koppeltijd drastisch doet verminderen? Zo ja, hoe lang vermoed je dat het duurt om deze code te installeren in een "vreemde" database (dus die van mij wanneer een programmeur aan het werk gaat?)

Als je het hebt over direct csv importeren. Als je MSSQL gebruikt dan zal er weinig aan zijn wat daar aan kan tippen kwa snelheid. Maargoed dan hebben we het over een csv bestand wat al helemaal aan jou datastructuur voldoet. Hoe wil je immers achteraf nog (serieuze) data (structuur) aanpassingen doen?

Je zou met Rhino ETL een import formaat kunnen omzetten naar een standaard formaat csv bestand. En dan dat csv bestand in je database importeren. Maar of dat een optie is voor jou kan ik niet beoordelen. Dat hangt namelijk van jouw unieke situatie af.

Wij kunnen alleen maar advies geven over Rhino ETL en mogelijke oplossingen. Als je echt specifieke wilt weten zoals wat er echt nodig is om het werkend te krijgen, en wat de implementatie precies omvat. Dan zul je toch echt met een van je eigen ontwikkelaars moeten gaan praten.