Dennis Mausbach

Seit dem Appliance Update 4 (AU4) des Analytics Platform Systems (APS) steht mit bcp eine weitere Methode neben dem DWLoader für die Beladung zur Verfügung. Hieraus lassen sich einige interessante Aspekte ableiten, die im Folgenden näher betrachtet werden sollen.

Der Modellaufbau:

Das Zielsystem ist ein APS Half Rack also eine Ausbaustufe mit 4 Compute Nodes von Dell. Eine txt.-Datei mit einer Größe von 1,7 Gb (36 Millionen Zeilen) und insgesamt 5 Spalten soll geladen werden. Diese Datei wird in eine verteilte Tabelle übertragen, die nach dem ROUND_ROBIN-Verfahren gehashed ist. Gegenüber einem expliziten Hashwert erlaubt diese Verteilung eine merklich schnellere Belieferung. Aus Performance-Gründen wird zudem auf etwaige Indizes verzichtet.

DDL Zieltabelle:

CREATE TABLE [dbo].[traffic] (
[Timestamp] datetime2(7) NOT NULL,
[SensorID] int NOT NULL,
[Lane1] float NOT NULL,
[Lane2] float NOT NULL,
[Lane3] float NOT NULL,
[Lane4] float NOT NULL
) With (Distribution = ROUND_ROBIN)

Die Datei wird jeweils mit DWLoader und bcp transferiert. Folgende cmd-Zeile initiiert den DWLoader:
-S Server -U Small -P xxx -T database.schema.table -i localpath\loadfile -R localpath\errorfile -fh 1 -t \t -r \r\n -M fastappend -m -D „M/d/yyyy h:mm:ss tt“

Der bcp-Aufruf erfolgt über:
bcp database.schema.table in localpath\loadfile -c -q -U Small -P xxx -S Server -h „TABLOCK“ -a 65535

Performance-Indikatoren
Die Tabelle gibt Aufschluss über die wichtigsten Performance-Indikatoren:

APS Lademethoden Übersicht

Hier die Ladedetails des DWLoader aus der Admin Console der APS:
(dwloader Round Robin)

APS dwLoader RoundRobin

Der Query-Plan für die bcp-Lademethode sieht wie folgt aus:
(2 bcp Round Robin)

APS bcp RoundRobin

Zum Vergleich die Beladungsdauer in eine strukturgleiche Tabelle mit explizitem Hash. Der Geschwindigkeitsvorteil einer nach Round Robin verteilten Tabelle wird deutlich. Allerdings bleibt der praktische Nutzen fraglich, da für nahezu jede Operation, die auf diese Tabelle zugreift, der Shuffle Mechanismus des internen DMS (Data Movement Service) greift:
(bcp Hash (SensorID) )

bcp Hash

Zunächst fällt der Geschwindigkeitsvorteil der DWLoader-Methode ins Auge. Aufgrund der sehr hohen Datenübertragungsraten des DWLoader hat es sich bewährt, eher große Files auf einen Schlag zu importieren. Sollen jedoch in hoher Frequenz kleinere Files mit großem Gesamtvolumen importiert werden, entsteht schnell ein gewisser Overhead für die Konsolidierung dieser Dateien. Da die DWLoader-Lademethoden in den Bereich der Data Loads fallen, können maximal 10 Beladungen zeitglich ausgeführt werden. Zudem ist das Queue-Limit auf maximal 40 begrenzt. Loads, die darüber hinaus gehen, werden nicht mehr berücksichtigt und somit verworfen, was in produktiven Prozessen oftmals keine Alternative ist.

Hingegen werden die durch bcp.exe ausgeführten Inserts als Abfrage verstanden. Die Kapazitätsgrenze kann also auf 32 parallele Inserts angehoben werden. Entsprechend gilt dann auch das Limit für maximal 40 aufgestaute Beladungen nicht mehr. Somit ist theoretisch ein unendliches Queuing möglich. Allerdings bedeutet das auch, dass die bcp-Beladungen andere Abfragen womöglich aufstauen, wenn das Limit von 32 aktiven Abfragen erreicht ist. Daher ist die Wahl der Ressourcenklasse zu berücksichtigen. Möchte man die maximale Parallelität erreichen, sollte mit der Default Ressourcenklasse „Small“ geladen werden. Dies kann über die Wahl des Users innerhalb des bcp-Befehls über den Parameter –U gesteuert werden. Eine detaillierte Beschreibung des bcp Befehls ist hier zu finden: https://msdn.microsoft.com/de-de/library/ms162802(v=sql.120).aspx

Bei den Tests hat sich zudem herauskristallisiert, dass eine Package Size (Parameter –a) auf 32.767 Bytes die optimalste Einstellung ist. Dies kann aber abhängig von der Systemkonfiguration differieren und sollte individuell getestet werden. Die Batchsize belassen wir auf der Default-Einstellung, sodass alle Zeilen der Datei in einem Batch transferiert werden.