Free Trial

Blog - Deutsch

Erkenntnisse und Ideen von den besten Analytics-Experten.
RolandSchubert
16 - Nebula
16 - Nebula

Natürlich nutzt jeder gern die Tools, die er kennt, das ist bei mir nicht anders. Auch wenn es vielleicht Lösungen gibt, die eleganter oder technisch anspruchsvoller sein mögen, ohne einen konkreten Vorteil bleibe ich meistens bei den bewährten Ansätzen.

 

Bei den In-Database-Tools gibt es aber Anwendungsfälle, in denen sie einen echten Vorteil bieten.  Um welchen Vorteil es hier geht und wie man die entsprechenden Fälle identifizert soll heute unser  Thema sein.

 

Den Vorteil kann man sehr klar benennen: Performance! Mit In-Database kann man Workflows deutlich beschleunigen - und zumindest bei mir hat sich noch nie jemand beschwert, weil ein Workflow zu schnell ist. 

 

Der Unterschied lässt sich an einem kleinen Bespiel leicht zeigen.  Nehmen wir einmal an, wir möchten die Ergebnisse einer Werbekampagne messen. Zu diesem Zweck haben wir eine Excel-Tabelle mit den beworbenen Produkten (etwa 50 von insgesamt 1000) und eine zweite Excel-Tabelle mit dem Aktionszeitraum (5 Tage). Außerdem haben wir eine Datenbanktabelle mit den Transaktionen eines Jahres (ca. 30 Millionen Datensätze).

 

Ein Lösungsansatz könnte sein, die Transaktionsdaten und die Produkte über jeweils ein Input Data Tool zu laden und ein Join-Tool zu verwenden, um die beworbenen Produkte zu selektieren (der "J" Output Anchor liefert nur die Produkte, die in der Excel-Datei enthalten sind). Den Werbezeitraum laden wir über ein weiteres Input Data Tool, erzeugen mit dem Generate Rows Tool eine Zeile mit dem entsprechenden Datum und wählen wiederum über ein  Join Tool die Datensätze aus, die in den Werbezeitraum fallen. Dann können wir noch summieren - fertig. Insgesamt sieht das so aus:

 

P01.jpg

 

Wenn wir diesen Workflow ausführen, haben wir nach knapp 40 Sekunden ein Ergebnis - für 30 Millionen Datensätze eigentlich nicht schlecht. Aber schauen wir uns mal an, wo die Zeit verbraucht wird:

 

P02.jpg

 

 Klare Sache: Bei der Abfrage der Transaktionsdaten, schließlich werden hier 30 Millionen Datensätze in Alteryx gezogen. Anzumerken ist noch, dass bei diesem  Test keine Verzögerung durch Netzwerk oder Serverbelastung auftrat - in der Realität ist der Anteil also eher höher. 

 

Genau hier können die In-Database Tools helfen. Unser größtes Problem ist, dass wir eine große Anzahl von Datensätzen vom Server in Alteryx laden, um dort zwei Joins mit sehr kleinen Anzahlen von Datensätzen eauszuführen, Mit In-DB kehren wir das einfach um. Wir ziehen nicht die große Zahl Datensätze von der Datenbank in Alteryx, sondern wir schieben die kleinen Tabellen in die Datenbank und führen die Join-Operationen dort durch.

 

P03.jpg Für den "Upload" gibt es das Data Stream In Tool, mit dessen Hilfe wir zwei kleine Tabellen auf dem SQL-Server erzeugen. Join wird dann durch das entsprechende In-Database-Gegenstück ersetzt, auch die Summierung kann hier stattfinden. Am Schluß brauchen wir dann nur noch ein Data Stream Out Tool, um die Ergebnisse wieder vom Server in Alteryx zu ziehen. 

 

Wieder gibt es ein Tool, dass den Großteil der Zeit verbraucht - diesmal ist es das Data Stream Out Tool. Allerdings ist ein Großteil hier etwas mehr als eine Sekunde, insgesamt benötigt der Workflow knapp 2 Sekunden. Mal eben Faktor 20!!!

 

P04.jpg

 

Hier hat es sich also gelohnt, In-Database Tools zu nutzen. Lassen sich daraus allgemeine Regeln ableiten, in welchen Fällen man den Anstz in Erwägung ziehen sollte?

 

Generell gilt - wenn eine sehr große Anzahl Datensätze von einem SQL-Server gezogen wird, um mit einer kleinen Anzahl von Datensätzen, die lokal vorliegen, verknüpft zu werden, und das Ergebnis nur noch einen kleinen Teil der SQL-Tabelle enthält, sollte man darüber nachdenken (wenn von den 30 Millionen Datensätzen am Ende noch 29 Milliuonen übrigbleiben, lohnt es sich vielleicht eher nicht - der Data Stream Out wird dann die eingesparte Zeit verbrauchen. 

 

Auch wenn alle Tabellen schon auf dem SQL-Server liegen, kann In-DB eine sinnvolle Lösung sein. Klar, das entsprechende SQL-Statement könnte man auch direkt in ein Input Data Tool schreiben - aber eben auch über In-Database Tools abbilden. Und dann sieht man direkt, was passiert, so wie man es von Alteryx gewohnt ist.

 

  

Weitere Tipps Tuesday Beiträge

Dieser Eintrag ist Teil der Tipps Tuesday-Serie, alle Einträge dieser Serie findest du in unserem Index aufgelistet.

Beschriftungen