Trifacta Enterprise: Wrangeln bis der Arzt kommt

In Trifacta existieren folgende Objekte, um das Wrangling zu realisieren:

• Connections
• Datasets
• Recipes
• Outputs
• Flows

Connections repräsentieren die Datenquellen, welche für die Verarbeitung verwendet werden können. Dabei können diese von unterschiedlicher Art sein. Von einer relationalen Datenbank (Bspw. MySQL, Postgresql oder MS SQL-Server) über Cloud-Speicher (Bspw. Amazon S3) bis hin zu Hadoop-Technologien (HDFS und Hive) kann alles angebunden werden. Mit den Connections können Datasets definiert werden. Diese beinhalten die konkrete Spezifikation von z.B. einer Tabelle in MySQL, einer CSV-Datei im HDFS oder aber einer Tabelle in Hive. Bei Datenquellen, welche über SQL angesprochen werden, sind auch sogenannte Custom SQL Queries möglich. Heißt also, dass keine explizite Tabelle angegeben werden muss, sondern ein eigenes Select-Statement, welches dann durch das Quellsystem ausgeführt wird und die Ergebnismenge an Trifacta zurückgibt.
Bevor eine Verarbeitung der Daten stattfinden kann, müssen die Verarbeitungsschritte definiert werden. Diese können auch als Transformationsschritte bezeichnet werden. Dies findet in sogenannten Recipes statt. In so einem Recipe können auf den Daten Operationen ausgeführt werden. Dafür wird die Wrangle Language verwendet, welche eine domänenspezifische Sprache ist, und extra für die Datentransformation entwickelt wurde. Dabei werden verschiedene Bereiche abgedeckt. Die Vielfalt reicht von mathematischen und trigonometrischen Funktionen über Aggregatfunktionen bis hin zu Funktionen, welche sich auf z.B. Strings und Timestamps beziehen. [2] Die Liste der verschiedenen Gruppen ist lang und das hier ist auch nur ein Auszug. Die definierten Schritte können entweder auf die Daten eines Datasets angewendet werden oder auf das Ergebnis eines anderen Recipes. Heißt also, dass z.B. mehrere Recipes in einer sequenziellen Kette verbunden werden können. Somit obliegt es dem Anwender, ob alles in einem Recipe definiert oder aber eine Verteilung der Transformationsschritte auf verschiedene Recipes vorgenommen werden soll, welche dann miteinander verbunden werden.
Nach der Durchführung der Verarbeitungsschritte soll das Ergebnis in der Regel persistiert werden. Dafür können die Outputs verwendet werden, welche direkt auf einem Recipe folgen. Dort wird festgelegt, wo das Ergebnis gespeichert werden soll. Dabei können die vorher besprochenen Connections verwendet werden, um z.B. eine Tabelle in MySQL, eine Datei im HDFS oder aber eine Tabelle in Hive zu definieren, in der die Daten dann gespeichert werden.
Über die Outputs kann die Verarbeitung manuell gestartet werden. Dann wird eine Jobgroup gestartet, welche i.d.R. 2 Jobs enthält. Der erste Job ist die Transformation und der zweite Job ist das Publishen in das in dem Output definierte Ziel. Darüber hinaus existieren noch ein Profile Job, welcher statistische Auswertungen von der Transformation erstellt, und ein Ingestion Job, der dafür sorgt, dass die Daten für die Verarbeitung zuerst in das verarbeitende System gebracht werden, bevor der Transformationsjob startet. Das Profiling kann durch den Anwender aktiviert werden und die Ingestion wird nur bei bestimmten Datenquellen gestartet. Als Beispiel sei z.B. MS SQL genannt. Neben der manuellen existiert noch die Möglichkeit einer zeitgesteuerten Ausführung, welche für den produktiven Betrieb einer Verarbeitung interessant ist.
Damit Recipes und Outputs erstellt werden können, werden Flows benötigt. Man kann einen Flow wie einen Container verstehen, welcher Datasets, Recipes und Outputs zusammen gruppiert. Somit muss erst ein Flow erstellt werden, damit darin dann die Datasets hinzugefügt, die Recipes definiert und die Outputs erstellt werden können. Als Beispiel sei auf Abbildung 1 verwiesen. Diese enthält zwei Verarbeitungsketten, welche jeweils aus einem Dataset, einem Recipe und einem Output bestehen. Dabei wird einmal eine CSV-Datei im HDFS als Dataset verwendet und einmal eine Hive-Tabelle. Das Ergebnis soll dann jeweils in eine CSV-Datei im HDFS publiziert werden.
Bevor jetzt der Eindruck entsteht, dass Wrangle Language und Funktionen stark an Programmierung erinnern, kann ich hier mitteilen, dass diese Transformationsschritte komplett über das User Interface definiert werden können, sodass eine klassische Programmierung über ein leeres Textfeld bzw. eine leere Datei nicht nötig ist. Einen Eindruck über das User Interface vermittelt Abbildung 2. Dort ist die Transformation Page zu sehen, welche betrachtet werden kann, wenn ein Recipe geöffnet wird. Dort wird dann ein Auszug der Daten angezeigt, welcher durch sogenannte Samples definiert wird. Jeder hinzugefügte Transformationsschritt wird sofort auf das Sample angewendet und das Ergebnis dem Anwender präsentiert. Es können auch neue Samples nach bestimmten Kriterien neu zusammengestellt werden, sodass die Transformationsschritte optimal auf Basis der Daten geprüft werden können.
Somit schafft Trifacta die Möglichkeit, einfach ganze Transformationsprozesse zu definieren und dann auch noch diese auszuführen. Der Anwender benötigt nur einen Webbrowser, um sich mit Trifacta Enterprise zu verbinden. Dabei werden Chrome und Firefox unterstützt.[3]

Trifacta Enterprise besteht aus unterschiedlichen Diensten und Komponenten. In diesem Abschnitt sollen einige wenige vorgestellt werden:

• Webapp Service
• Data Service
• Photon
• Spark Job Runner
• Optimizer Service

Der Webapp Service dient als Schnittstelle zwischen Anwender und Trifacta. Darüber wird das Frontend bereitgestellt und alle Client-Anfragen vom Browser verarbeitet. Als Backend für die Metadaten wird eine relationale Datenbank verwendet. Der Data Service ist für die Beschaffung von Daten von externen Datenquellen zuständig. Dabei wird das JDBC-Framework verwendet. Photon ist die lokale Execution Engine, welche für kleinere Datenmengen gewählt werden kann (<=1GB). Dann wird die Transformation lokal auf dem Trifacta Host ausgeführt. Der Spark Job Runner ist für die Ausführung von Spark-Jobs zuständig, welche auch als Execution Engine für die Trifacta-Jobs verwendet werden können. Diese eignet sich für größere Datenmengen. Voraussetzung ist eine Möglichkeit Spark-Jobs auszuführen, also z.B. eine auf Hadoop basierende Plattform. Der Optimizer Service wurde mit Trifacta Enterprise 7.6 eingeführt. Dieser führt Optimierungen an den Queries für relationale Datenquellen durch. Durch die Aufteilung in unterschiedliche Dienste existieren zu diesen auch Logdateien, welche dann je nach Problem für die Analyse herangezogen werden können. Das ist vorteilhaft, da je nach Problem die Komplexität zunehmen kann und eine Eingrenzung auf die jeweiligen Dienste vorteilhaft ist.