In den ersten beiden Teilen dieser Blog-Reihe haben wir uns den Kontext angeschaut, in dem wir uns mit dem Umzug von Oracle zur Snowflake beschäftigen. In diesem Teil geht es jetzt um die Anbindung von DataStage an Snowflake.

DataStage Version 

Mit DataStage V11.5 wurde die Snowflake ConnectorStage eingeführt, die auf den JDBC-Treiber von Snowflake aufsetzt und die Erweiterungen von Snowflake unterstützt. 

Jetzt aber ein paar „Abers“ zu dieser Version: 

  • Diese ConnectorStage gibt es generell nur für Parallel Jobs und nicht für Server Jobs. 

  • Die Unterstützung einer Snowflake ist nur rudimentär in V11.5 implementiert. Sehr wichtige Funktionen (s.a. das nächste Kapitel und Teil 6 zum LOAD und MERGE) sind erst in späteren DataStage Releases hinzugekommen.

Achtung

Um es deutlich zu sagen: Mit einer V11.5. (oder niedriger) solltest du gar nicht erst starten.  Es ist mindestens die V11.7.1.1 notwendig! Aktualisiere auf den neuesten JDBC-Treiber, da die von IBM mitgelieferte Version V3.5 des JDBC Treibers von Snowflake nicht mehr unterstützt wird! 

Fazit 

Plane eine Phase vor deinem Projekt ein, um DataStage auf die richtige Version zu bringen und die notwendigen Treiber für Snowflake zu aktualisieren und zu testen. 

JDBC, ODBC, Server Jobs und Parallel Jobs 

Die folgenden Möglichkeiten gibt es, um einen DataStage Job an eine Snowflake anzubinden:

Connectorstage

Erklärung 

  • Ja – das geht 

  • Nein – das geht nicht 

  • Jeindas kannst du so machen, aber dann ist es $§&?/&/§%/(& nicht gut. Im Hinblick auf Performance willst du das nicht machen, niemals! 

ODBC Connector Stage 

Für Parallel und Server Jobs gibt es theoretisch die Möglichkeit, die ODBC-Stage zu nutzen. Da DataStage unter Linux die ODBC-Treiber von DataDirect benutzt, müsste entweder dieser Treiber genutzt werden oder DataStage wird komplett auf einen anderen Treiber-Manager konfiguriert. Das betrifft dann aber alle ODBC-Datenquellen! 

Dieses Verfahren ist von IBM dokumentiert: 

Link https://www.ibm.com/docs/en/iis/11.7?topic=ahul-configuring-other-odbc-drivers 

Technisch kannst du den einen oder den andern Weg gehen, aber das sind beides keine sinnvollen Wege. DataStage nutzt „nur“ den ODBC-Standard. Bei Änderung von Daten werden die normalen UPDATE/DELETE Befehle ausgeführt. Und die haben bei einer Snowflake eine sehr schlechte, eigentlich eine nicht vorhandene Performance (darüber hatten wir schon in Teil 2 gesprochen). Noch mal zur Wiederholung: Wir reden hier von maximal 1 Zeile pro Sekunde bei UPDATE und DELETE Befehlen! 

Mal eben 30.000 Sätze per DataStage Job zu verändern, dauert schon mal 8h. Und die Parallelität in DataStage zu erhöhen, bringt nichts, da die Tabelle bei einem UPDATE-Befehl gesperrt wird. 

JDBC ConnectorStage 

Die JDBC ConnectorStage ist eine generische Stage, um beliebige Datenbanken, für die ein JDBC-Treiber existiert, anzubinden. Grundsätzlich funktioniert sie auch mit Snowflake, aber alles, was zur UPDATE/DELETE-Performance bei ODBC gesagt wurde, gilt auch hier. 

Snowflake ConnectorStage 

Erst mit den individuellen Erweiterungen, die von Snowflake im JDBC-Treiber eingebaut sind und die von DataStage erst in der V11.7.1.1 richtig unterstützt werden, ist es möglich einen DataStage Job performant mit einer Snowflake arbeiten zu lassen. Mehr dazu im nächsten Kapitel und in Teil 5. 

Fazit 

  • Server Jobs können nicht sinnvoll migriert werden.  Arbeitet eins deiner DataStage Projekte hauptsächlich mit Server Jobs, dann musst du den Refactoring-Weg gehen 

  • Die Standard-Datenbank Connectoren für ODBC und JDBC können nicht sinnvoll genutzt werden. 

  • Die Snowflake ConnectorStage ist die einzige sinnvolle Datenbank-Stage bei Snowflake! 

Snowflake und die Snowflake ConnectorStage 

Im Teil 2 hatten wir einige Besonderheiten der Snowflake aufgeführt, die sich auch auf die ETL-Verarbeitung auswirken. Wir wollen uns das hier jetzt genauer anschauen. 

Die Snowflake ConnectorStage erlaubt keine Reject-Links!  

Eine Verarbeitung, die auf Reject-Links aufbaut, muss entfernt werden. 

Manuell ist das ein mühsamer Prozess.  

Job Manipulator

Mit dem JobManipulator kannst du Reject-Links und alle direkt davon abhängigen Stages (automatisiert) entfernen! 

Schreibmodus “Load from file 

DataStage bietet analog zu Db2 oder Oracle ConnectorStages auch bei der Snowflake einen Schreibmodus „Load from file an, der nicht mit einem „normalen“ SQL INSERT arbeitet, sondern ein Lade-Verfahren passend zur Datenbank nutzt. In der Regel wird damit eine viel bessere Performance als mit einem INSERT erzielt.

Datastage und Snowflake

Bei Snowflake wird dazu der PUT und COPY Befehl und eine Snowflake INTERNAL STAGE genutzt und mit temporären Dateien auf dem DataStage Server gearbeitet. 

 Ablauf: 

  1. Die ConnectorStage schreibt die Daten vom Eingabelink in eine temporäre Datei. 

  1. Diese Datei wird mittels des Snowflake PUT-Befehl in eine INTERNAL STAGE geschrieben. 

  1. Im letzten Schritt werden die Daten mittels COPY INTO in die Zieltabelle geschrieben. 

Hier die Snowflake Dokumentation dazu: 

Im Teil 6 werden wir genauer auf die Parametrisierung dazu eingehen. 

jb

Der JobManipulator unterstützt diesen Schreibmodus und kann Stages, die mit generiertem INSERT arbeiten, auf den „Load from file“ umstellen. 

SQL-Dialekt 

In einem DataStage Job kann ein Entwickler manuelles SQL vorgeben oder das SQL von DataStage generieren lassen. Typisch ist, dass schreibende Stages das SQL generieren. In lesenden Stages ist es sehr beliebt komplexe SELECT Anweisungen zu schreiben, um das Design des DataStage Jobs einfacher zu halten. Das ist grundsätzlich nicht verwerflich, führt aber dazu, dass bei einer Migration von ETL-Abläufen der Entwickler sich diese SQLs sehr genau ansehen muss. 

Je mehr manuelle SQL-Statements in den ConnectorStages genutzt werden, desto schwieriger wird eine Job-Migration, da sich das SQL zwischen einer Oracle und Snowflake doch unterscheiden kann. Mehr dazu in Teil 5, wo wir für einige SQL-Elemente einen Vergleich zwischen Oracle und Snowflake machen.  

jb

Beim JobManipulator haben wir eine Manipulation am SQL implementiert, um einige (aber nicht alle) Fälle umstellen zu können. 

Verwaltungs-SQL 

In einem Datenintegrationsprozess gibt es nicht nur „die Daten-verarbeitenden ETL-Jobs, sondern viele funktionale Komponenten, die ebenfalls umgestellt werden müssen: 

  • Häufig werden einige Funktionen per Datenbank-Skript aus DataStage Sequenzen oder aus Shell-Skripts heraus aufgerufen. Bei einer Snowflake gibt es zwar SnowSQL, aber es ist in der Funktionalität und im Fehlerhandling nicht mit Oracle SQL*Plus zu vergleichen. 

  • Sehr häufig werden in ETL-Jobs Partitionen bearbeitet oder nach einer Verarbeitung Statistiken gesammelt. Beispiel: Daten werden gelesen, transformiert und in eine Tabelle geschrieben, die per PARTITION EXCHANGE dann in eine größere Tabelle gehängt wird. Auf dem Weg werden Indizes neu erstellt und Statistiken gesammelt. Bei einer Snowflake fällt das alles ersatzlos weg! 

  • Es gibt Projekte, die Materialized Views im ETL-Prozess verwenden. Diese können mit Snowflake so nicht genutzt werden. 

Häufig werden bei DataStage diese Funktionen in den sogenannten before/after SQL-Anweisungen ausgeführt. Im Rahmen der Migration von ETL-Abläufen müssen auch diese Anweisungen angepasst werden. 

jb

Im JobManipulator haben wir Funktionen eingebaut, um diese Einstellungen in der ConnectorStage zu löschen, zu setzen oder zu verändern.

Fazit 

  • Eine Job-Migration ist mehr als nur die ConnectorStage in einem ETL-Job auszutauschen. 

  • Für einige Besonderheiten der Snowflake DB sowie der Snowflake ConnectorStage sind im JobManipulator Funktionen eingebaut, um den Umstellungsprozess automatisiert durchführen zu können (da gehen wir in den nächsten Teilen genauer drauf ein). 

  • Insbesondere durch die unterschiedlichen SQL-Dialekte und wenn viel manuelles SQL implementiert wurde  (insbesondere in Teil 5 schauen wir uns einige Unterschiede vom SQL von Oracle und Snowflake an), können auch nach der Umstellung mit dem JobManipulator noch Anpassungen per manuellem Eingriff erforderlich sein.  

Neuen Kommentar schreiben

Ihre E-Mail Adresse wird nicht veröffentlicht.

NEUESTE BEITRÄGE

Lasst uns in die Snowflake abtauchen | Umzug eines DWH auf eine Snowflake - Teil 5
09.09.2022

Lasst uns in die Snowflake abtauchen | Umzug eines DWH auf eine Snowflake - Teil 5

Christian Hagen

In den ersten Teilen der Blogreihe haben wir beschrieben, wie du DataStage Jobs von (beispielweise) Oracle auf Snowflake umstellen kannst. In diesem Teil wollen wir uns auf Besonderheiten und Probleme stürzen, die bei einem Schwenk von Oracle zu Snowflake auftreten können und die sich als „Schätzchen“ in den Jobs und manuellem SQL verstecken können.

Data Engineering
ITGAIN UX UI
08.09.2022

Wie wir deinen Benutzer glücklich machen können

Lea Brauner

„UI is the sadle, the stirrups and the reins. UX is the feeling you get being able to ride the horse“, hat Dain Miller, ein Web Developer, einmal gesagt. In anderen Worten heißt das, dass man zwar ein User Interface braucht, um ein Programm oder eine Software zu bedienen, das aber noch nicht heißt, dass es mit diesem User Interface auch Spaß macht, die Software zu bedienen. Denn beim User Interface, der Benutzeroberfläche, handelt es sich lediglich um die Schnittstelle zwischen dem Benutzer und der Maschine, die ihn zum Ziel navigiert. Über die Optik oder Benutzbarkeit sagt das jedoch noch nichts aus.

Applications
Lasttests mit Shift-Left-Verschiebung
31.08.2022

Lasttests mit Shift-Left-Verschiebung

Sören Schmock

Lasttests gehören gemäß ISTQB® zu den nicht funktionalen Tests, mit denen Zeitverhalten, Ressourcenverbrauch, Stabilität und Skalierbarkeit einer Software oder Webseite (im folgenden „Anwendung“ genannt) überprüft werden. Der Lasttest wird durch Testspezialisten durchgeführt, um unter anderem zu bestimmen, ob die Anwendung einer erwarteten oder für die Zukunft geplanten Anzahl von Benutzern in der Performance (z. B. Anzeigegeschwindigkeit) noch Rechnung trägt. Schließlich möchte niemand auf die lange Rückmeldung einer Anwendung warten müssen.

Expertise