Dieser Blogbeitrag wurde verfasst von: Sahaj Saini, PM im Microsoft Analytics Platform System (APS) Team.

In diesem Blogbeitrag geben wir einen kurzen Überblick über Symmetric Multi-Processing (SMP) vs. Massively Parallel Processing (MPP)-Systeme, wie man Auslöser für die Migration von SMP zu MPP erkennt, wichtige Überlegungen bei der Umstellung auf Microsoft Analytics Platform System (APS) und eine Diskussion darüber, wie man die Leistung einer MPP-Lösung wie APS nutzen kann.

Beginnen wir mit einem Szenario. Emma ist die Datenbankadministratorin bei Adventure Works Cycles, einem Unternehmen, das Fahrräder herstellt. Bei Adventure Works verwenden Emma und ihr Team den traditionellen SQL Server SMP als Data Warehousing-Lösung. Das Unternehmen ist schnell gewachsen, und angesichts des zunehmenden Wettbewerbs in der Fahrradbranche wünschen sich die Business-Analysten von Adventure Works Cycles einen schnelleren Einblick in ihre Daten. Emma steht mit der SMP-Bereitstellung vor folgenden Herausforderungen: –

• Hohes Datenvolumen und Datenwachstum: Mit steigenden Umsätzen und einem wachsenden Kundenstamm ist das Datenvolumen schnell auf über 10 TB angewachsen.
• Längere Datenlade-/ETL-Zeiten: Da Emma täglich Berichte für das Management erstellen muss, ist die derzeitige ETL-Geschwindigkeit unzureichend, um die wachsende Datenmenge aus anderen OLTP- und nicht-relationalen Systemen aufzunehmen und zu verarbeiten.
• Langsame Abfrageausführung: Die Ausführungszeiten für Abfragen verlangsamen sich aufgrund der zunehmenden Datenmenge, und es wird immer schwieriger, zeitnah Erkenntnisse für die tägliche Berichterstattung zu gewinnen.
• Lange Cube-Verarbeitungszeit: Mit der derzeitigen Cube-Verarbeitungszeit ist es schwierig, die Echtzeitanforderungen des Unternehmens an die Berichterstattung zu erfüllen.

Um diese Herausforderungen zu bewältigen, erwägen Emma und ihr Team die Anschaffung einer größeren, teuren und leistungsfähigeren Server- und Speicherhardware für ihr Rechenzentrum. Dieser Ansatz würde das Problem zwar lösen, aber nur kurzfristig, da das Datenwachstum in den nächsten 12 Monaten explodieren dürfte. Bei dem Datenwachstum, das Adventure Works erwartet, würden selbst die größeren und leistungsfähigeren SMP-Lösungen sehr schnell an ihre Grenzen stoßen. Emma wünscht sich eine Lösung, die mit den wachsenden Datenanforderungen mitwächst.

Bevor wir uns an die Lösung der Probleme von Emma machen, sollten wir kurz definieren, was SMP und MPP sind. Symmetrisches Multi-Processing (SMP) ist ein eng gekoppeltes Multiprozessorsystem, bei dem sich die Prozessoren Ressourcen teilen – einzelne Instanzen des Betriebssystems, Speicher, E/A-Geräte – und über einen gemeinsamen Bus verbunden sind. SMP ist die primäre parallele Architektur, die in Servern eingesetzt wird und in der folgenden Abbildung dargestellt ist.

Massiv parallele Verarbeitung (MPP) ist die koordinierte Verarbeitung einer einzelnen Aufgabe durch mehrere Prozessoren, wobei jeder Prozessor sein eigenes Betriebssystem und seinen eigenen Speicher nutzt und über eine Art Nachrichtenschnittstelle miteinander kommuniziert. MPP kann mit einer „Shared Nothing“- oder „Shared Disk“-Architektur eingerichtet werden.

In einer „Shared Nothing“-Architektur gibt es im gesamten System keinen einzigen Streitpunkt, und die Knoten teilen sich weder den Speicher noch den Plattenspeicher. Die Daten werden horizontal auf die Knoten aufgeteilt, so dass jeder Knoten über eine Teilmenge von Zeilen aus jeder Tabelle in der Datenbank verfügt. Jeder Knoten verarbeitet dann nur die Zeilen auf seinen eigenen Festplatten. Systeme, die auf dieser Architektur basieren, können einen enormen Umfang erreichen, da es keinen einzelnen Engpass gibt, der das System verlangsamt. Das ist es, wonach Emma sucht.

MPP mit Shared-Nothing-Architektur ist im folgenden Bild dargestellt.

Microsoft Parallel Data Warehouse (PDW), das auf einer Microsoft Analytics Platform System-Appliance läuft, ist als MPP-Shared-Nothing-Architektur implementiert. Sie besteht aus einem Kontrollknoten und an den Speicher angeschlossenen Rechenknoten, die über Ethernet und Infiniband miteinander verbunden sind. Der Kontrollknoten beherbergt die PDW-Engine – das Gehirn des MPP-Systems -, die parallele Abfragepläne erstellt, die Abfrageausführung auf den Rechenknoten und die Datenaggregation in der gesamten Appliance koordiniert. Alle Knoten, einschließlich Steuer- und Rechenknoten, hosten einen Data Movement Service (DMS), um Daten zwischen den Knoten zu übertragen.

Weitere Details zur PDW-Architektur finden Sie im Beitrag Architektur des Microsoft Analytics Platform Systems.

Umstellung auf MPP

Um den von MPP gebotenen Wert zu realisieren, kaufen Emma und ihr Team eine Microsoft APS-Appliance und beginnen mit der Umstellung auf MPP. Sehen wir uns an, wie sie ihre Lösung anpassen, um die Vorteile der MPP-Architektur von APS voll auszuschöpfen.

Table Design

Wie bereits erwähnt, basiert APS auf einer MPP-Architektur ohne gemeinsame Nutzung, was bedeutet, dass die Knoten autark sind und weder Speicher noch Festplatten gemeinsam nutzen. Die Architektur erfordert daher, dass Sie Ihre großen Tabellen auf die Knoten verteilen, um die Vorteile der massiv parallelen Verarbeitung zu nutzen. APS erlaubt es, eine Tabelle entweder als verteilt oder als repliziert zu definieren. Die Entscheidung für das eine oder das andere hängt von der Datenmenge und der Notwendigkeit des Zugriffs auf alle Daten auf einem einzigen Knoten ab.

Verteilte Tabellen

Eine verteilte Tabelle ist eine Tabelle, bei der die Zeilendaten innerhalb der Tabelle über die Knoten innerhalb der Appliance verteilt sind, um eine massive Skalierung zu ermöglichen. Jede Zeile landet in einer Verteilung in einem Rechenknoten, wie in der folgenden Abbildung dargestellt.

Um die Vorteile der verteilten Natur von APS zu nutzen, modifiziert Emma die großen Tabellen, typischerweise Fakt- und große Dimensionstabellen, so, dass sie in APS wie folgt verteilt werden:

CREATE TABLE .( NOT NULL, NOT NULL, . . NULL) WITH( DISTRIBUTION = HASH(ProductKey),CLUSTERED COLUMNSTORE INDEX);

Wie Sie sehen können, ist dies eine typische DDL-Anweisung für die Tabellenerstellung mit einem kleinen Zusatz für verteilte Tabellen. Tabellen werden durch eine deterministische Hash-Funktion verteilt, die auf die für diese Tabelle gewählte Verteilungsspalte angewendet wird. Emma wählt Product Key als Verteilungsspalte in der Tabelle FactInternetSales wegen der hohen Kardinalität und der fehlenden Schiefe, so dass die Tabelle gleichmäßig auf die Knoten verteilt wird.

Replizierte Tabellen

Wären jedoch alle Tabellen verteilt, müssten vor der Durchführung von Join-Operationen für alle Operationen sehr viele Daten zwischen den Knoten verschoben werden. Daher ist es bei kleineren Dimensionstabellen wie Sprachen, Ländern usw. sinnvoll, die gesamte Tabelle auf jedem Rechenknoten zu replizieren. Das heißt, die Vorteile lokaler Verknüpfungsoperationen mit diesen Tabellen überwiegen die Kosten für den zusätzlichen Speicherbedarf. Eine replizierte Tabelle ist eine Tabelle, die über alle Rechenknoten hinweg repliziert wird, wie unten dargestellt.

Emma entwirft die kleinen Tabellen, typischerweise Dimensionstabellen, so, dass sie wie folgt repliziert werden:

 CREATE TABLE .( NOT NULL, . . (10) NOT NULL,)WITH(CLUSTERED COLUMNSTORE INDEX);

Indem sie verteilte und replizierte Tabellen angemessen entwirft, richtet Emma ihre Lösung an den gängigen Best Practices für MPP-Design aus und ermöglicht die effiziente Verarbeitung großer Datenmengen. Beispielsweise würde eine Abfrage von 100 Milliarden Zeilen in einer SQL Server SMP-Umgebung die Verarbeitung aller Daten in einem einzigen Ausführungsbereich erfordern. Mit MPP wird die Arbeit auf viele Knoten verteilt, um das Problem in überschaubare und einfacher auszuführende Aufgaben aufzuteilen. In einer Appliance mit vier Knoten (siehe Abbildung oben) muss jeder Knoten nur etwa 25 Milliarden Zeilen verarbeiten – eine viel schnellere Aufgabe. Infolgedessen konnte Emma erhebliche Verbesserungen bei der Ausführungszeit von Abfragen feststellen, und ihr Unternehmen kann nun schneller bessere Entscheidungen treffen. Darüber hinaus kann Emma das Data Warehouse durch Hinzufügen von „Skalierungseinheiten“ zu APS auf einige Terabytes bis zu über 6 Petabytes an Daten erweitern.

Datenladen

Mit SQL Server SMP verwendeten Emma und ihr Team ETL-Prozesse über eine Reihe von SSIS-Paketen, um Daten in das Data Warehouse zu laden – (1) Extrahieren von Daten aus dem OLTP- und anderen Systemen; (2) Transformieren der Daten in ein Dimensionsformat; und (3) Laden der Daten in Zieldimensionen oder Faktentabellen im Data Warehouse. Mit zunehmendem Datenvolumen wird der SSIS-Server in der Mitte zu einem Engpass bei der Durchführung von Transformationen, was zu einem langsamen Laden der Daten führt.

Mit APS können Emma und ihr Team stattdessen ELT verwenden, um die Daten aus dem OLTP und anderen Systemen zu extrahieren und in einen Staging-Speicher auf APS zu laden. Anschließend können die Daten nicht mit SSIS, sondern mit der APS-Engine in ein dimensionales Format umgewandelt werden, wobei die verteilte Natur der Appliance und die Leistung der Parallelverarbeitung genutzt werden. In einer Appliance mit vier Knoten führen vier Server die Transformationen an Teilmengen von Daten durch, im Gegensatz zu einem SSIS-Server mit einem Knoten.

Diese parallele Verarbeitung führt zu einer erheblichen Leistungssteigerung beim Laden von Daten. Emma kann dann die CTAS-Anweisung (Create Table As Select) verwenden, um die Tabelle aus der Staging-Tabelle wie folgt zu erstellen.

CREATE TABLE . WITH( CLUSTERED COLUMN INDEX, DISTRIBUTION = HASH (CustomerKey))ASSELECT * FROM .;

Durch den Wechsel zu einem ELT-Prozess nutzt Emma die parallele Verarbeitungsleistung von APS, um Leistungssteigerungen beim Laden von Daten zu erzielen.

Zusammenfassend lässt sich sagen, dass Emma und ihr Team mit MPP Antworten auf ihre SMP-Probleme gefunden haben. Sie können nun das Datenvolumen und das Wachstum von Adventure Works mit der Fähigkeit, das Data Warehouse nach Bedarf zu skalieren, problemlos bewältigen. Mit ELT und der Leistung der Parallelverarbeitung in APS können sie Daten schneller und innerhalb des erwarteten Zeitfensters in APS laden. Und durch die Anpassung an das MPP-Design von APS können sie eine bahnbrechende Abfrageleistung erzielen, die Echtzeitberichte und Einblicke in ihre Daten ermöglicht.