ETL-Job: Datenbanken mit verschiedenen Schemas

[DBMaster]

Möchte mit 2 Datenbanken - verschiedene DB-Typen (FB und MySQL) und verschiedene Schemas - Datentransfer zwischen ausgewählten Tabellen-Spalten ausführen. Mit tMap funktioniert das bei mir nicht. Ist Talend OpenStudio oder TMDMCE (aktuelle Version) überhaupt dazu geeignet? Wenn ja, wie geht es dann?

[java_duke]

Das sollte problemlos mit TOS möglich sein. Stimmen denn die Tabellen-Schemata von Quell- und Zielsystem überein?

[DBMaster]

Wie gesagt handelt sich hier um verschiedene Schemas/Schematas, sonst wäre der Datentransfer natürlich kein Problem.
Das ist ein komplexer ETL-Job wie er bei der Professional Version in einem White Paper ausgelobt wird.
Vielleicht kann die Open Source Edition das überhaupt nicht?

[martin]

Aus der Beschreibung sehe ich an dieser Stelle auch kein Problem einen solchen Job aufzusetzen. Ein Unterschied zwischen TOS und der kostenpflichtigen Variante ist hier definitiv nicht gegeben!
Ich vermute das Problem kommt liegt an einer anderen Stelle? Evtl. hilft folgendes Vorgehen:
1. Wichtig! Wenn noch keine Erfahrung mit TOS, dann IMMER eine GA(derzeit 4.0.2) Version verwenden! Niemals eine M oder RC Version installieren, auch wenn der Funktionsumfang noch so vielversprechend erscheint.
2. Linke Seite Repository->Metadata->Db Connections->Create Connection für die erste Datenbank erstellen.
3. Auf der neu angelegten Connection mittels DB-Connection->Recht Klick->Retrieve Schema die relevante(n) Tabellen auswählen.
4. Schritt 2 und 3 für die andere Datenbank wiederholen
5. Um zu testen ob der Zugriff auf die Source-DB funktioniert eine "Retrived" Tabelle aus dem Repository mittels D&D in einen Prozess ziehen, im sich öffnenden Fenster eine t<DB>Input Komponente wählen und den Main-Pfad der t<DB>Input Komponente mit einem tLogRow verknüpfen. Sollte nach der Ausführung kein Ergebnis kommen, so liegt hier ein DB-Problem vor.
6. Aus dem Repository die Source-Tabelle auswählen mit D&D in den Job ziehen und dann t<DB>Input wählen.
7. Aus dem Repository die Target-Tabelle auswählen mit D&D in den Job ziehen und dann t<DB>Output wählen.
8. Die beiden DB-Komponenten mit einem tMap verknüpfen. tMap->Rechts Klick->Row->New Output mit der Target Komponente verbinden und einen passenden Namen wählen(z.B. toDB).
9. Das Fenster mit "Do you want to retrieve the schema of the Target component" mit Yes bestätigen.
10. Von der Input-Komponente auch einen Main-Pfad auf den tMap legen. t<DB>Input->Rechts Klick->Row->Main
11. Anschließend das Mapping innerhalb vom tMap aufbauen.

Wichtig! Bitte auf die jeweiligen Typen-Konventionen achten. Eine Spalte vom Type Integer lässt sich nicht 1:1 auf einen BigDecimal platzieren.

Unter http://www.talendforge.org/tutorials/menu.php sind einige nette Beispiele wie mit Talend gearbeitet werden kann.

Martin

[DBMaster]

Vielen Dank für die ausführliche Anleitung - so hatte ich das auch vorher schon versucht.
Es kommt dann nach der Job-Ausführung die Fehlermeldung:
Exception in thread "main" java.lang.Error: Unaufgelöstes Kompilierungsproblem:
Typabweichung: Konvertierung von String auf double nicht möglich.

Damit ist nun geklärt, dass die TOS CE-Edtion den ETL-Job nicht kann.
Schade um die lange Zeitverschwendung damit.

[martin]

Hätte ich die Fehlermeldung gleich gesehen, dann hätte ich nicht den langen Text tippen müssen.

Bei dem Problem handelt es sich um einen typischen Konvertierungsfehler. Betrachtet man die Tatsache das es sich bei Talend um einen Codegenerator handelt, so ist an dieser Stelle natürlich kein 1:1 Mapping eines String-Werts auf einen numerischen Wert möglich.
Wie bei jeder Lösung muss auch bei TOS eine Konvertierung in das jeweilige Format erfolgen. Angenommen wir haben als Input einen Datums-String und wollen diesen in ein Datumsfeld schreiben so benötigt der Umwandler das entsp. Format (z.B. "dd.MM.yyyy HH:mm:ss").

Um das Problem jetzt in den Griff zu bekommen, gibt es zwei Möglichkeiten.
1. Man definiert beim Input-Schema bereits das Feld als Double. Hat natürlich dann ein Problem wenn bereits beim Lesen Text-Werte angeliefert und diese nicht konvertiert werden können.

2. Man bildet innerhalb des Mappers die Konvertierung nach. Hat hier die Möglichkeit noch zusätzliche Replaces ( , nach . ) und den Errorzweig gezielt für Aussteuerungen zu verwenden.

Um direkt einen Überblick bei Konvertierungsfehler zu erhalten, kann eine Option in den "Preferences" aktiviert werden.
   
Wichtig! Das aktivieren kann zu einer erheblichen Verzögerung führen, daher ist die Option per Default deaktiviert.

Im Mapper erhält man anschließend die Problemfelder mit Rot hinterlegt.
   

Um das Mapping doch durchzuführen wird einen Konvertierung auf dem jeweiligen Feld mittels dem Expression-Editor umgesetzt.
   
Um Werte die definitiv nicht konvertiert werden können(z.B. "Hello World") auszusteueren, verwendet man den Reject Pfad. tMap->Die on Error

Nach der Ausführung sollte dann folgendes Ergebnis vorliegen.
   

Im Anhang das beschriebene Projekt (TOS 4.0.2)
Martin

[DBMaster]

Sorry, dass ich anfangs keine Fehlermeldung dazu geschickt habe aber ein Job mit verschiedenen Schemas beinhaltet eben die Konvertierungs-Problematik. Danke für die ausführliche Beschreibung. Mit manueller Konvertierung gehts natürlich (fast) immer.

Der Aufwand 40 Tabellen mit 800 rows zu prüfen und fallweise anzupassen ist mir dann aber zu gross, und die Performace ist mit "Check the property fields" tatsächlich nicht mehr akzeptabel.

Den Job sollte eingentlich eine ETL-Anwendung automatisch für mich erledigen. Ich bevorzuge dann eine der folgenden Lösungen:
http://www.dbsoftlab.com (ETL-Processor)
http://www.spectralcore.com (Omega Sync Pro Version 3 ab Okt.2010)