256bit.org Blog

Ich dachte ja eigentlich, ich kenne mich mit Regulären Ausdrücken etwas aus. Ich benutze sie ja schließlich schon ein paar Jahre und damit meine ich nicht nur einfache sondern auch ziemlich komplexe (Vim User eben ;)).

In vielen Programmen vermisste ich denn auch die Möglichkeit, reguläre Ausdrücke zu verwenden. So auch in Informatica und ich muß sagen, allein dieses Feature wäre es mir wert gewesen, auf Informatica 8 zu wechseln, mit dem Reguläre Ausdrücke (perl kompatible) dort eingeführt worden. Letztens wolle ich sie dann auch verwenden, aber irgendwie, hat das nicht hingehauen.

Wenn selbst ein einfaches REG_EXTRACT(Spalte, '.') einen Fehler wirft, dann frag ich mich schon, wozu man Reguläre Ausdrücke in Informatica benutzen soll. Nachdem ich so einen kompletten Nachmittag die Logik debugged habe und auch die Informatica Knowledgebase gewälzt habe, habe ich es bleiben gelassen und benutze weiterhin die guten alten SUBSTR() und INSTR() Funktionen. Sauber sieht das zwar nicht aus, aber wenigstens funktioniert es jetzt.

Wer sich wundert, wenn Informatica bei einer Update/Delete Session plötzlich schnarchlangsam wird, der sollte mal den verwendeten ODBC-Treiber überprüfen. Bei einem Update einer vorhandenen Session hat das auch einem Job, der gut 20.000 Records in 10 Sekunden schreibt, einen Job gemacht, der nach 7 Stunden noch nicht fertig war. Sowas ist freitags auf einem produktiven Server extrem unlustig.

Man erkannte den falschen ODBC-Treiber daran, dass er beim Import der Tabellen jedes Feld in der Länge verdreifachte und aus VARCHAR Feldern NVARCHAR Felder macht.

Der Open Source Business Intelligence Day 2010 ist nun auch schon eine Woche vorbei. Zeit, ein kleines Fazit zu ziehen.

Die Lokation, das Hambacher Schloss, war sehr nett. Als Veranstaltungsort für Tagungen ist es durchaus zu empfehlen. Leider spielte das Wetter nicht so mit, so dass der Zuweg sehr vereist und glatt war. Der Regen und grauer Himmel taten ihr Übriges.

Die Vorträge waren allesamt gelungen. Für micht am interessantesten waren vor allem die Vorträge zu den ETL Lösungen von Talend und das Reporting von Jaspersoft. Den Produkten sehen zwar im Vergleich zu den kommerziellen Anbietern wie Informatica noch nicht so "rund" aus, aber die scheinen eine vergleichbare Leistungsfähigkeit zu besitzen. Vom Gefühl her würde ich behaupten, Informatica hat mehr spezielle Transformationslogiken eingebaut, aber bei Talend kann man daher komplett in den Flow eingreifen und zur Not eigene Transformationslogiken in Java und Perl programmieren. Es wäre zu untersuchen, wie performant Talend im Vergleich zu den etablierten Anbietern wie Informatica, DataStage oder Ab Initio ist. Das wäre mal ein Projekt, was mich interessieren würde. Einige ausgewählte Transformationslogiken und dazu Massendaten von mehreren hundert Millionen Datensätzen...

Man sieht Talend (und auch Pentaho, was ich nur ganz kurz sehen konnte) noch ihren Ursprung an (Talend basiert auch auf dem Eclipse Framework) und so sieht man überall den Einfluss von Java. Für Java Entwickler könnte es genau deshalb sehr interessant sein. Informatica scheint eine besser integrierte Lösung zu sein, wo alles unter einer einheitlicheren Oberfläche vorhanden ist. Nun kenne ich Informatica ziemlich gut und bei Talend muß ich mich auf die kurze Demo beschränken, aber beide scheinen gleich mächtig zu sein. Und wenn man Informatica kann, dann kann man glaub ich auch schnell mit Talend und Pentaho arbeiten.

Auch die Reporting Lösung von Talend und Jaspersoft sehen recht vielversprechend aus, wobei ich auch hier das Gefühl habe, mit Cognos schneller komplexe Reports hinstellen zu können. Da muß bei den Open Source Alternativen noch viel von Hand und manuell gemacht werden.

Aber am spannendsten fand ich die Vorträge zu Rapidminer bzw. der neuen Storage Engine von [url=http://www.ingres.com[/url] Ingres, VectorWise. Vereinfacht gesprochen, werden dabei die Daten nicht zeilenorientiert gespeichert, sondern nach Spalten. Durch Ausnutzung von Komprimierung und diversen Fähigkeiten moderner Prozessoren kann man so extrem schnelle Auswertungen auf Massendaten durchführen. Bei solchen Analysen aggregiert man typischerweise die Daten stark und arbeitet mit Summen, Maximum, Durchschnitt, etc. Und genau hierbei haben Spaltenorientierte Storage Engines einen Vorteil und können diese Analysen viel schneller liefern (man sprach von einem Faktor 50). Leider scheint das Ganze aber für normale transaktionsorientierte Prozesse nicht geeignet zu sein. Das ist auf jeden Fall ein spannendes Thema, das sich dort entwickelt.

Im Großen und Ganzen kann die Veranstaltung als gelungen bezeichnet werden. Ich habe viel gelernt. Auch, dass OpenSource nicht kostenlos bedeutet. Aber von irgendwas wollen die Menschen, die hinter diesen Firmen stehen halt auch leben.

Gestattet, dass ich mich mal kurz aufrege, ja?

Ich arbeite ja jetzt schon einige Zeit mit Informatica und hin und wieder muß ich dort auch Administration machen. Meine Güte ist das furchtbar. Jedesmal fliegt einem die Installation/Backup/Restore wegen eines anderen Fehlers um die Ohren. Und dann jedesmal mit dem Support telefonieren und schreiben.
Erwarte ich eigentlich zuviel davon, dass teuer bezahlte Software auch funktionieren sollte? Menno, einmal funktionierende Software haben.

He, darauf habe ich so lange gewartet. Informatica 8 unterstüzt endlich reguläre Ausdrücke. Das kann die Arbeit sehr vereinfachen. Das ist echt mal praktisch. Fehlt nur noch bei Oracle. Das kanns erst ab Version 10 und ich muß hier immernoch Version 9 benutzen.

Ich muß mal kurz einen kleinen Rant loswerden.

In den letzten 2 Wochen habe ich 2 komplexere Probleme in 2 Flows untersucht. Das Killerfeature was dabei immer genannt wird ist der eingebaute Debugger. Damit kann man einem Datensatz zusehen, wie die Transformationslogik angewandt wird. So richtig schön grafisch und mit Breakpoints. Zumindest theoretisch. Praktischerweise funktioniert das Teil nämlich nicht verläßlich, zumindest, wenn in der Mappinglogik ein Outer-Join enthalten ist. Dann beendet sich der Debugger nämlich einfach ohne ersichtlichen Grund. Wenn man Glück hat, kann man wenigstens noch durch einen Teil der Logik durchsteppen. Was hab ich geflucht, aufgrund dieses Bugs, der schon mindestens seit Version 7 drin ist.

Man kann in diesem Fall also nicht mit dem Debugger debuggen. Was macht man? Richtig, wie früher in der guten alten Zeit(™) das Loglevel hochdrehen auf "Verbose Data" (damit loggt Informatica praktisch für jede Transformation den eingehenden und ausgehenden Datensatz) und dann Logfiles lesen. Lustigerweise hat Informatica mit Version 8 auf eine Art binäres Logfile umgestellt. Man kann diese Dinger nicht mehr anständig mit einem stinknormalen Editor oder Pager lesen, sondern muß den eingebauten Logfile Viewer nutzen. Der ist schon umständlich genug zu nutzen, nur leider ist das Teil auch nicht mal richtig stabil. Während ich also das Loglevel auf Verbose Data hochdrehte und mit ein paar Testdatensatz den ganzen Flow nochmal laufen lies, stellte ich fest, dass das Logfile auf enorme 2 GB angewachsen war. Und das mit nur einer Handvoll Testdatensätze. Aber wartet, es kommt noch besser: Als ich versuchte, das Logfile mit dem eingebauten Logfileviewer zu öffen, ist mit der Viewer gnadenlos abgestürzt. Also Loglevel wieder runtergedreht auf Normal und nur bei vereinzelten Transformationen "Verbose Data" angeschaltet. Danach war das Logfile immer noch mehrere Hundert MB groß, doch zumindest konnte man es betrachten.

Ich glaube jedes Problem hat ca: 1 Arbeitstag gekostet, bis ich den Fehler gefunden hatte. Da gibt es noch Verbesserungspotential.

Wenn man Informatica als ETL-Lösung zur Beladung eines Datawarehouse nutzt, kann es sinnvoll sein, hin und wieder die Metadaten des Repositories zu entrümpeln. Dort werden nämlich die Statistiken über alle durchgeführten Läufe gespeichert und, falls eingerichtet, auch die Versionsinformationen.
Wenn jetzt der Ladeprozess täglich läuft und dabei jedesmal um die 100 Workflows mit mehreren Sessions laufen (was weder unüblich noch besonder viel ist), dann kann der Platz im Tablespace der darunter liegenden Datenbank des Informatica Repositories arg eng werden. Deshalb empfiehlt es sich, hin und wieder mal die Statistiken zu löschen. Das geschieht typischerweise mittels pmrep truncatelog. Näheres weiß die sehr gute Dokumentation zum Thema.

Ich wollte es nur mal gesagt haben, damit ich das nicht wieder vergesse.

Informatica ist ein Hersteller von Datenintegrationssoftware. Sowas benötigt man im Allgemeinen, wenn man ein Daten-Warehouse beladen möchte. Damit kann man dann die Daten normalisieren und Regeln anwenden, ohne sich mit komplexen SQL-Statements rumzuschlagen (ETL-Prozess).

Für ein Projekt kam jetzt die Anforderung auf, dynamisch Regeln auszuwerten. Im Idealfall sieht das dann so aus. Man hat z.B. folgende Tabelle:


In Spalte FELD1 und FELD2 steht jeweils ein Wert und in der Spalte Formel befindet sich die Berechnung (z.B. FELD1/FELD2 * 100 um den Prozentsatz des Verhältnisses zu bestimmen). Beim Beladen möchte man nun optimalerweise die Formel gleich anwenden, also dynamisch auswerten. Obwohl man mit Informatica PowerCenter durchaus komplexe Transformationen durchführen kann, fehlt die Funktionalität solche Ausdrücke zur Laufzeit auswerten zu können.

Der Workaround besteht darin, eine StoredProcedure Transformation einzubauen (in Informatica 8 sollte auch eine SQL-Transformation existieren, mit der man das auch erreichen kann) , die in der Datenbank eine Stored Procedure ablegt, die das dynamisch auswertet.
Bsp (für Oracle):Diese PL/SQL Funktion macht nichts weiter als den übergebenen Ausdruck auszuwerten, im Prinzip also ein eval(). So kann man z.B. einfache Formel berechnen:

CODE:
SQL> select 7*10/2 from dual;
7*10/2
------
    35

Theoretisch kann man so jegliche SQL-Ausdrücke auswerten lassen, dazu muß der Rückgabewert bei Bedarf noch auf Varchar geändert werden.

In Informatica kann die Prozedur dann so eingebunden werden:


Übersicht über das Mapping Design:
In der Expression Transformation (rot), werden die String-Variablen FELD1 und FELD2 im Feld FORMULA durch ihren Inhalt ersetzt. Diese aufgelöste Formel, wird danach an die Stored Procedure CALC übergeben (unconnected)