Wichtige Details bei der Anbindung von DataStage an Snowflake | Umzug eines DWH auf eine Snowflake - Teil 6

Partitioned Read 

Bei einer Oracle ConnectorStage gibt es bei einer lesenden Stage die Einstellung „Enable partitioned reads“. Wird das gesetzt und gibt man beispielsweise eine „Partitioned reads method“ von „Rowid hash“ an, wird diese Stage mehrfach gestartet, um den lesenden Durchsatz zu erhöhen.

MOD(ROWID, [[node-count]]) = [[node-number]]

[[node-count]] ist die Anzahl der Knoten

[[node-number]] gibt die Node an, auf der die Stage gestartet wird

Du kannst diesen Parameter aktivieren, aber dann musst da das SQL selber um die notwendigen Anweisungen erweitern. 

Link:  https://www.ibm.com/docs/en/iis/11.7?topic=r-partitioned-reads-1

Würde bei der Job-Migration die Einstellungen der Stage weitestgehend 1:1 übernommen werden, so würde die Snowflake Stage Partitioned Reads machen. Da das SQL durch die ConnectorStage zur Laufzeit aber nicht angepasst wird, wird das SQL identisch mehrfach ausgeführt! Das kannst du in einem Testjob auch sehen!

DataStage Runtime Column Propagation (RCP) 

In der aktuellen Version der Snowflake ConnectorStage gibt es endlich die Einstellung „Generate all columns as Unicode“, sodass bei RCP alle Textspalten als UNICODE generiert werden. 

Bei DataStage ist der Standard „No“. Das ist leider schade, da ein „Yes“ sinnvoller wäre. Mit dieser Einstellung gibt es weniger Probleme mit Spalten, die Umlaute enthalten und/oder Sonderzeichen, die in UTF-8 mehr als ein Byte benötigen. Das gilt für Oracle genauso wie für Snowflake. 

LOAD, Merge, CSV-Dateien „and all that Jazz“ 

In Teil 3 hatten wir schon erwähnt, dass DataStage bei einer Snowflake wie bei anderen nativen Datenbank ConnectorStages auch einen „Load from file“ Modus unterstützt. 

Die Parametrisierung ist ähnlich wie bei den anderen ConnectorStages, es gibt aber ein paar Besonderheiten: 

• Zum einen kann und muss(!) das Format der temporär erzeugten Dateien, die auf dem Server geschrieben und dann per Snowflake PUT-Befehl hochgeladen werden, gesteuert werden. 
• Zum anderen stellt DataStage eine Variante des „Load from file“ Schreibmodus bereit, die das Performance-Problem der single-row UPDATE/DELETE Befehle beheben kann: „Use merge statement = Yes“

Parametrisierung des LOAD 

Hier ist ein beispielhafter Aufruf in der Snowflake ConnectorStage im „Load from file“ Modus: 

In den „Load from file Properties“ kannst du sehen, wie du die INTERNAL STAGE ansprichst. In DataStage wird das „Snowflake internal location“ bzw. „staging area“ genannt. Es ist beides Mal das gleiche und bezeichnet eine INTERNAL STAGE von Snowflake. 

Format der CSV-Dateien 

Der Parameter „Stage area format type options“ steuert das Format der Zwischendatei. Die Dateien sind einfache Dateien (analog zu CSV-Dateien), die einen „Field delimiter“ als Trennzeichen für Spalten und „Record Delimiter“ als Trennzeichen für Sätze nutzen. 

Tipps: 

• Die in der Abbildung (oben) angegebenen Werte für die Delimiter haben sich bewährt. Glücklicherweise können hier mehrere Zeichen als Delimiter genutzt werden, um sicherzustellen, dass diese garantiert nicht in den Daten vorkommen. 
• Snowflake nutzt zwei verschiedene Einstellungen für ein Escape-Zeichen. Es sollten beide gelöscht werden. Deswegen ist „Escape“ leer und die Einstellung unter „Other file format options“ eingetragen. 

Mehr zu den Optionen für CSV-Dateien stehen in der Snowflake Dokumentation. 

Link:  https://docs.snowflake.com/en/sql-reference/sql/create-file-format.html#type-csv 

Parameter “Use merge statement” 

Dieser Parameter ist ebenfalls erst ab dem DataStage Release V11.7.1.1 verfügbar. Er verbindet den Schreibmodus „Load from file“ mit normalen SQL-Befehlen, um Daten in der Zieltabelle sehr performant zu verändern.  

Beim „Load from file“ arbeitet DataStage mit einer INTERNAL STAGE in Snowflake. Snowflake behandelt die INTERNAL STAGE wie eine Tabelle. Also kannst du aus der INTERNAL STAGE heraus nicht nur Daten mittels COPY INTO in die Zieltabelle kopieren, sondern du kannst auch mit den SQL-Befehlen wie UPDATE, DELETE oder MERGE arbeiten. 

Ist der Parameter aktiviert, werden die Daten vom Link nicht direkt in die Zieltabelle geschrieben, sondern analog zum Schreibmodus „Load from file“ verarbeitet. 

Also noch mal kurz zusammengefasst: 

• Die Daten vom Link werden in eine temporäre Datei auf dem Server geschrieben und dann per PUT in eine INTERNAL STAGE von Snowflake geladen.  
• Dann werden diese Daten mittels eines SQL-Befehls von der INTERNAL STAGE in die Zieltabelle übertragen.  
• Abhängig vom Schreibmodus generiert DataStage dann den notwendigen SQL-Befehl: DELETE, UPDATE oder MERGE. 

Handling des Oracle-Schreibmodus „Insert new rows only“ 

Bei der Oracle ConnectorStage führt dieser Modus dazu, dass Daten per INSERT eingefügt werden und wenn es eine Verletzung eines UNIQUE Constraints gibt, wird dieser Satz ignoriert. 

Die Snowflake ConnectorStage erlaubt keinen Schreibmodus „Insert new rows only“. Da Snowflake keinen Unique-Constraint anwendet, können problemlos ohne Vorkehrung doppelte Datensätze/Keys in die Tabelle geschrieben werden!  

Bei der Snowflake gibt es zwei andere Schreibmodi, die stattdessen genutzt werden könnten. Allerdings erzeugen sie einen anderen Datenstand als unter Oracle und es müssen Key-Felder definiert werden! 

• „Insert then Update“: Dahinter steht ein MERGE-Befehl, der Daten einfügt, oder falls sie schon existieren, ändert. 
• „Delete then Insert“: In der Zieltabelle werden die Daten über den KEY gesucht und gelöscht und dann neu eingefügt. 

Es gibt auch noch den „Insert Overwrite“ Modus, aber Vorsicht: da wird vor dem INSERT ein TRUNACTE durchgeführt! 

Snowflake:  https://docs.snowflake.com/en/sql-reference/sql/insert.html