Action Vector 7.0 wird ab Version 8.0 in Actian Analytics Engine umbenannt


Der Nutzen einer Analytics Database eng mit ihrer Fähigkeit zusammen, riesige Datenmengen zu erfassen, zu speichern und zu verarbeiten. Die Daten stammen in der Regel aus verschiedenen Quellen, wie beispielsweise operativen Datenbanken, CSV-Dateien und kontinuierlichen Datenströmen. In den meisten Fällen belaufen sich die täglichen Datenmengen auf mehrere zehn oder hundert Millionen Zeilen, sodass der herkömmliche SQL-INSERT-Mechanismus für diese Datenmengen nicht gut geeignet ist.

In this blog post, we’ll look at Actian Vector, our columnar database ideally suited for analytic applications, and evaluate a variety of CSV data ingestion options that operate at the required data rates. In future posts, we’ll examine Actian VectorH executing in a Hadoop environment and ingestion from streaming data sources.

Der Zweck dieses Tests besteht nicht darin, Dateneingang zu messen, sondern die relative Geschwindigkeit verschiedener Methoden in derselben Hardwareumgebung zu bewerten. Wir werden SQL INSERT als Referenzwert heranziehen und SQL COPY TABLE, das Befehlszeilenprogramm vwload sowie die ETL-/Workflow-Tools Pentaho Data Integration (auch bekannt als Kettle), Talend Open Studio for Data Integration und Apache NiFi bewerten. Talend und Pentaho sind traditionelle ETL-Tools, die weiterentwickelt wurden und nun eine Vielzahl von Bulk-Loadern sowie andere sogenannte Big Data und -Technologien umfassen; beide basieren auf der Eclipse-Benutzeroberfläche. NiFi wurde von der US-amerikanischen National Security Agency (NSA) als Open-Source-Projekt an die Apache Foundation übergeben und ist ein universelles Tool zur Automatisierung des Datenflusses zwischen Softwaresystemen; es nutzt eine webbasierte Nutzer .

Alle drei setzen ein Konzept eines gerichteten Graphen um, bei dem Daten von einem Operator zum nächsten fließen und die Operatoren parallel ausgeführt werden. Pentaho und Talend bieten Community- und Abonnement-Editionen an, während NiFi als Open-Source-Projekt von Apache verfügbar ist.

Der Vector-Server besteht aus einem AMD Opteron 6234 Hex-Core-Prozessor der Desktop-Klasse, 64 GB Arbeitsspeicher und SATA-Festplatten (Hardwarekosten ca. 2.500 $) und läuft mit der Single-Node-Version 5.0 von Vector.

Als Vergleichsgrundlage werden wir etwa 24 Millionen Datensätze in die TPCH-Benchmark-Tabelle „lineitem“ einfügen. Die Struktur dieser Tabelle ist wie folgt:

l_orderkey bigint NOT NULL,
l_partkey INT NOT NULL,
l_suppkey INT NOT NULL,
l_linenumber INT NOT NULL,
l_quantity NUMERIC(19,2) NOT NULL,
l_extendedprice NUMERIC(19,2) NOT NULL,
l_discount NUMERIC(19,2) NOT NULL,
l_tax NUMERIC(19,2) NOT NULL,
l_returnflag CHAR(1) NOT NULL,
l_linestatus CHAR(1) NOT NULL,
l_shipdate DATE NOT NULL,
l_commitdate DATE NOT NULL,
l_receiptdate DATE NOT NULL,
l_shipinstruct CHAR(25) NOT NULL,
l_shipmode CHAR(10) NOT NULL,
l_comment VARCHAR(44) NOT NULL

SQL INSERT

Da Vector ANSI-SQL-konform ist, ist der Standard-SQL-INSERT-Befehl wohl der naheliegendste Mechanismus zur Dateneingabe. Dies ist in der Regel die leistungsschwächste Option, da sie zu einzelnen Einfügevorgängen führt. Einfügungen lassen sich zwar durch Parametrisierung und das Einfügen von Datensätzen in Stapeln bis zu einem gewissen Grad optimieren, doch selbst dies reicht möglicherweise nicht aus, um die erforderliche Leistungsfähigkeit zu erreichen.

Für den SQL-INSERT-Test erstellen wir einen einfachen Pentaho-Workflow mit zwei Schritten: einem zum Einlesen der CSV-Datendatei und einem zum Einfügen dieser Zeilen in eine Vector-Datenbank. Wir führen den Workflow sowohl auf demselben Knoten wie die Vector-Instanz als auch auf einem Remote-Knoten aus, um die Auswirkungen des Netzwerk-Overheads zu messen.

SQL-Einfügen aus CSV

In dieser Situation schneidet das Laden von einem Remote-Knoten geringfügig besser ab als das Laden vom lokalen Knoten, und die Leistung verbessert sich im Allgemeinen mit steigender Stapelgröße bis zu etwa 100.000 Datensätzen, um dann abzuflachen. Das soll nicht heißen, dass 100.000 immer die optimale Stapelgröße ist; sie variiert höchstwahrscheinlich je nach Zeilengröße.

Vektor COPY TABLE

Das Vector-Konstrukt „COPY TABLE“ dient dazu, Daten aus einer CSV-Datei in großen Mengen in die Datenbank zu laden. Bei Ausführung von einem Remote-Knoten aus erfordert dieser Ansatz die Installation der Vector Client Runtime, nämlich Ingres Net und den Ingres SQL-Terminalmonitor. Die Client Runtime ist kostenlos verfügbar und unterliegt keinen Lizenzanforderungen. Sowohl Pentaho als auch Talend bieten integrierte Unterstützung für dieses Konstrukt, wobei sich die Implementierung geringfügig unterscheidet. Pentaho verwendet Named Pipes, um Daten in den Operator zu leiten, während Talend eine Zwischenspeicherdatei auf der Festplatte erstellt und dann den Operator aufruft.

Die Talend-Implementierung nutzt zwei Operatoren: „tFileInputDelimited“, einen Leser für getrennte Dateien, und „tIngresOutputBulkExec“, einen Loader für Ingres/Vector COPY TABLE

Talend-Implementierung

Der Loader ist mit den Daten für die Datenbankverbindung, der Zieltabelle und der Zwischen-Staging-Datei konfiguriert.

Ausgabe der Loader-Details

Die Pentaho-Implementierung nutzt zwei gleichwertige Operatoren: die CSV-Dateieingabe, den Reader für getrennte Dateien, sowie den Ingres VectorWise Bulk Loader, den Datenbank-Tabellenlader.

Pentaho-Implementierung

Der Loader ist mit einer Vector-Verbindung und einer Zieltabelle konfiguriert. Im Gegensatz zu Talend verwendet der Pentaho-Loader keine Zwischen-Staging-Datei.

Pentaho Loader-Tabelle

Die Leistung beider Tools ist im Wesentlichen gleich, jedoch etwa sechsmal schneller als ein SQL-INSERT. Apache NiFi bietet keine native Unterstützung für „Vector COPY TABLE“, und die Simulation dieses Ansatzes durch das separate Starten des Terminal-Monitors und die Verbindung über Named Pipes ist relativ umständlich.

Vector vwload

Das von Vector bereitgestellte Dienstprogramm „vwload“ ist ein High-Performance Tool High-Performance für Actian Vector und VectorH. Es handelt sich um ein Befehlszeilenprogramm, mit dem eine oder mehrere Dateien aus dem lokalen Dateisystem oder aus HDFS in eine Vector- oder VectorH-Tabelle geladen werden können. Die HDFS-Variante werden wir in einem späteren Beitrag näher betrachten.

Vwload kann eigenständig oder als Datenlademechanismus für die von Pentaho, Talend oder NiFi generierten Workflow-Datenströme aufgerufen werden. Pentaho bietet integrierte Unterstützung für vwload, während Talend und NiFi einen Mechanismus bereitstellen, mit dem Workflow-Datenströme direkt an vwload weitergeleitet werden können, ohne sie zuvor auf der Festplatte zu speichern.

Bei der Talend-Implementierung wird „tFileInputDelimited“ zum Einlesen der CSV-Quelldatei und „tFileOutputDelimited“ zum Schreiben der Zeilen der Quelldatei in eine Named Pipe verwendet. Um den Datenstrom in Vector zu laden, müssen wir „vwload“ mit derselben Named Pipe wie bei der Quelldatei ausführen.

Talend-Implementierung

Um vwload zu starten, verwenden wir das Prejob-Konstrukt, um den tSystem-Operator auszulösen. tSystem ist der Mechanismus zur Ausführung von Befehlen auf Betriebssystemebene oder von Shell-Skripten. Der Prejob-Operator wird automatisch beim Start des Jobs vor allen anderen Workflow-Operatoren ausgelöst und ist so konfiguriert, dass er den tSystem-Operator auslöst.

tfileoutput

Der Operator „tFileOutputDelimited“ ist so konfiguriert, dass er in die durch die Umgebungsvariable „context.pipeName“ definierte Named Pipe schreibt. Die Named Pipe muss zum Zeitpunkt der Jobausführung vorhanden sein, und die Option „Append“ muss aktiviert sein.

tsystem

In diesem Fall führt der Operator „tSystem“ das Shell-Skript „talend_load.sh“ aus und übergibt dabei Parameter für den Tabellennamen, den Datenbanknamen, den Pipe-Namen und das Verzeichnis für die resultierende Protokolldatei. Die „context.“-Notation dient dazu, auf Umgebungsvariablen zu verweisen, die mit dem Job verknüpft sind; dadurch können Jobs parametrisiert werden. Das Shell-Skript lautet:

#!/bin/bash
nohup vwload -m -t $1 $2 $3 > $4/log_`date +%Y%m%d_%H%M%S`.log 2>&1 &

Die daraus resultierende Ausführungsreihenfolge lautet:

  1. Prejob-Operator ausführen
  2. Prejob-Trigger tSystem-Operator
  3. Der Systemoperator führt ein Shell-Skript aus
  4. Das Shell-Skript startet vwload im Hintergrund und kehrt zurück; vwload liest nun aus der Named Pipe und wartet auf eintreffende Zeilen
  5. Starten Sie „tFileInputDelimited“, um Zeilen aus der Quelldatei zu lesen
  6. Starten Sie „tFileOutputDelimited“, um eingehende Zeilen zu empfangen und in eine Named Pipe zu schreiben

Die Pentaho-Implementierung nutzt wie im Fall von COPY TABLE die Operatoren für die CSV-Dateieingabe und den Ingres VectorWise Loader, jedoch ist der Bulk Loader so konfiguriert, dass er stattdessen vwload verwendet.

Ingres-Vektorlader

Die Option „use vwload“ ist ausgewählt, und das Feld „Pfad zum SQL-Befehl“ ist leer. Auf diese Weise wird das Dienstprogramm vwload aufgerufen.

Die Apache NiFi-Implementierung nutzt drei Operatoren: „GetFile“, einen Verzeichnis-Listener, „FetchFile“, der die eigentliche Datei liest, und „ExecuteStreamCommand“, der die Streaming der Datei an den im Hintergrund laufenden vwload-Prozess weiterleitet.

Apache NiFi

FetchFile leitet den Quelldatenstrom an ExecuteStreamCommand weiter, das für die Ausführung eines Shell-Skripts konfiguriert ist.

Datei abrufen

Das Shell-Skript startet vwload im Hintergrund und leitet den Datenstrom über eine Named Pipe an vwload weiter. Die Notation ${} dient dazu, auf Eigenschaften zu verweisen, die in einer externen Eigenschaftsdatei konfiguriert wurden. Dies ermöglicht die Konfiguration des Flow-Prozessors zur Laufzeit.

#!/bin/bash

tableName=$1
dbName=$2
loadPipe=$3
logDir=$4

echo "`date +%Y-%m-%d\ %H:%M:%S` vwload -m -t $tableName db $dbName $loadPipe "
>> $logDir/load.log
vwload -uactian -m -t $tableName $dbName $loadPipe >> $logDir/load.log 2>&1 &
cat /dev/stdin >>$loadPipe

Der Befehl „vwload“ wird in den vorangegangenen Pentaho-, Talend- und NiFi-Workflows als Lademekanismus verwendet. Zum Vergleich laden wir denselben Datensatz sowohl Datensatz dem eigenständigen „vwload“ auf dem lokalen Vector-Rechner als auch vom Remote-Client aus über Ingres Net.

vwload

Die genauen Durchlaufzeiten und Verarbeitungsraten variieren stark je nach Hardware und Zeilenlänge.

Zusammenfassend lässt sich sagen, dass Dateneingang in der Reihenfolge steigender Leistung SQL INSERT, SQL COPY TABLE und vwload sind. Bei großen Datenmengen ist vwload in Verbindung mit einem geeigneten ETL-Tool in der Regel die richtige Wahl. Die Wahl des ETL-Tools hängt in der Regel von der Leistung und der Funktionalität ab. Es sollte zumindest eine Schnittstelle zur gewählten Erfassungsmethode vorhanden sein. Die Anforderungen an die Funktionalität richten sich hauptsächlich nach dem Umfang und der Art der Transformationen, die am eingehenden Datenstrom durchgeführt werden müssen. Selbst wenn eingehende Daten unverändert geladen werden sollen, kann ein ETL-Tool dennoch nützlich sein, beispielsweise für die Erkennung eingehender Dateien, die Jobplanung und die Fehlerberichterstattung.

Die oben genannten Workflows stellen den einfachsten Fall der CSV-Datei-Eingabe dar, bei dem in der Regel lediglich eine Quelldatendatei gelesen und in Vector geladen wird. Als solche repräsentieren sie auch die optimale Leistung für jede der Eingabemethoden. In den meisten praktischen Anwendungsfällen wird der Workflow eine gewisse Transformationslogik beinhalten, wobei die Datenflussraten in Abhängigkeit von der Komplexität der Transformation abnehmen. Durch die Messung der Datenflussraten der Workflows können wir die Eingabemethode auswählen, die diesen Anforderungen entspricht.

Erfahren Sie mehr über Actian Vector

Weitere Informationen zu Actian Vector finden Sie unter den folgenden Links:

Erfahren Sie mehr über unsere Actian Vector Community-Editionen unter: