Microsoft Parallel Data Warehouse

Ist die Nacht zu kurz oder schlafen Sie bei Abfragen ein? Immer größere Datenmengen bringen bestehende Data Warehouse Plattformen an ihre Leistungsgrenzen. Sie erfordern neue Strategien, um auch zukünftigen Anforderungen gewachsen zu sein. Gleichzeitig steigen die Ansprüche bezüglich Datenaktualität und auswertbarer Datenzeiträume. Nachfolgend werden Strategien aufgezeigt, um für die wachsende Datenflut gewappnet zu sein.

1. Ständig wachsendes Datenaufkommen

Immer größere Datenmengen bringen viele existierende Data Warehouse Plattformen (DWH) an ihre Leistungsgrenzen. Aus dem TDWI Report „Next Generation DW“ (siehe Abbildung 1) ist ersichtlich, welche Mengengerüste in den nächsten drei Jahren zu erwarten sind. So rechnen immerhin 34 Prozent der befragten Unternehmen mit einem Datenvolumen, das größer als 10 Terabyte ist. Das bringt einige Herausforderungen mit sich: Wenn beim aktuellen Datenvolumen die Nacht heute gerade knapp ausreicht, um alle Daten zu verarbeiten – wie wird es dann sein, wenn sich das Volumen verdoppelt oder verdreifacht? Es kommt hinzu, dass die Fachabteilungen immer mehr Werkzeuge bekommen, um Daten direkt aus dem DWH selbst auszuwerten. Als Beispiele im Microsoft Umfeld seien hier Excel und PowerPivot in Zusammenhang mit „Self-Service BI“ genannt. Dies bedeutet, dass die Anzahl der Anwender sowie die Anzahl der Abfragen und deren Komplexität neben der Datenmenge ebenfalls zunehmen werden. Viele DWH-Betreiber stellen deshalb Überlegungen an, ob die vorhandene Plattform ausgebaut werden kann. Sie wägen ab, ob es sinnvoll und an der Zeit ist, einen Technologiesprung zu machen.

Durchschnittliches Datenvolumen eines Datenwarehouse

Abbildung 1: Durchschnittliches Datenvolumen eines Data Warehouse.
Quelle: TDWI Report – Next Generation DW

Welche Möglichkeiten gibt es, oben skizzierte Anforderungen abzudecken? Dazu gibt es folgende Beispiele:

  • Ausbau des bestehenden Systems
  • Ablösung noch bestehender 32-bit Server durch 64-bit Server. Ein Hauptvorteil von 64-bit Systemen ist, dass sie mehr als 4 Gigabyte Arbeitsspeicher adressieren können. Hiervon profitieren Anwendungen mit hohem Speicherbedarf, zum Beispiel Datenbanksysteme. Mit 64 Bit lassen sich bis zu 16 Exabyte adressieren.
  • Umstellung auf Massive Parallel Verarbeitung (MPP). Die wichtigsten Hersteller von MPP-Systemen sind EMC Greenplum, Teradata, Oracle Exadata, HP Vertica und IBM Netezza sowie Microsoft Parallel Data Warehouse (HP, Dell).
  • Einsatz eines für den DWH-Betrieb optimierten Systems wie zum Beispiel Fast Track. Dies ist eine Architektur für ein ausgewogenes System, siehe nächsten Abschnitt.

1.1 Fast Track – Bauplan für ein ausgewogenes System

Fast Track GrundregelnFast Track ist die Microsoft Referenzarchitektur, um Software und Hardware für ein Data Warehouse optimal aufeinander abzustimmen – mit Microsoft SQL Server. Daneben beinhaltet Fast Track Best Practices für das Datenlayout, das Laden selbst und die Verwaltung der Daten. Fast Track Version 3.0 basiert auf der Technologie Microsoft SQL Server 2008 R2. Die Version 4.0 der Fast Track Referenzarchitektur korrespondiert mit Microsoft SQL Server 2012. Von diversen Herstellern kann ein Fast Track System vorproduziert als Appliance bestellt werden. Eine Appliance ist eine Einheit aus Hardware, Software und Services. Es besteht jedoch auch die Möglichkeit, sich ein System gemäß der Fast Track Referenzarchitektur selbst zusammenzustellen und zusammenzubauen. Fertig assemblierte Fast Track Systeme sind erhältlich von Dell, HP, Bull, IBM, EMC und anderen führenden Herstellern. Der Hauptvorteil eines fertig assemblierten Systems ist die schnelle Verfügbarkeit. Es ist innert wenigen Wochen einsatzfähig. Es ist nicht zwingend notwendig, bei einem Fast Track System die teuersten und besten Komponenten einzusetzen. Vielmehr ist es sinnvoll, Komponenten zu verwenden, die optimal aufeinander abgestimmt sind. Dies gilt in Bezug auf die Storage- und Leistungsanforderungen, die typischerweise bei einem Data Warehouse Betrieb gefordert werden. Es lohnt sich also, die Prozessoren, den Arbeitsspeicher, die lokalen Festplatten, das DAS (Direct Attached Storage) oder das SAN (Storage Area Network) sowie die Datenbank und das Betriebssystem so auszuwählen und zu konfigurieren, dass sie bestmöglich zusammenarbeiten. Auch sollte keine Komponente zu einem Flaschenhals werden. Dies ist etwa der Fall, wenn der Storage des Servers zu langsam ist, die Prozessoren dagegen mehr Daten verarbeiten könnten. Der Storage ist jedoch nicht in der Lage, eine höhere Leistung zu erbringen.

Das Ergebnis ist ein System mit einem optimalen Gesamtdurchsatz, welches die vorliegenden Anforderungen nachhaltig erfüllt.

1.2 SMP versus MPP

Vereinfacht ausgedrückt kann man sagen, dass ein SMP-System  auf einem einzigen Server mit mehreren CPUs (Cores) läuft. Bei MPP (massiv parallele Verarbeitung) hingegen wird die Skalierbarkeit und die Abfrage-Performance dadurch erreicht, dass mehrere unabhängige Server parallel betrieben werden. Herkömmliche Datenbankserver sind in der Regel als SMP-System ausgelegt.

Schema eines SMP Systems

Abbildung 2: Schema eines SMP Systems

Ein solches SMP-System zeichnet sich durch eine Multi-Prozessor Rechnerarchitektur aus, bei welcher der Arbeitsspeicher, der Storage und die Netzwerkkarten von den CPUs gemeinsam verwendet werden (shared). Ein großer Nachteil besteht darin, dass Anwendungen nicht beliebig skaliert werden können und laufende Prozesse sich gegenseitig beeinflussen. Das Parallel Data Warehouse, kurz PDW, von Microsoft ist hingegen ein massiv-parallel verarbeitendes System (MPP). Es basiert auf einer Shared Nothing Architektur: Das System besteht aus mehreren, baugleichen Server-Knoten, die alle ihre eigenen Prozessoren, Hauptspeicher, Storage und Netzwerkkarten besitzen. Da die Ressourcen nicht geteilt werden müssen, kann ein MPP System hervorragend skalieren.

1.3 Vorteile eines massiv parallelen Systems

Warum ist ein Parallel Data Warehouse (PDW) um ein vielfaches schneller als ein herkömmliches SMP-System? Was ist zu beachten, um eine optimale Performance zu erzielen? Alle Komponenten einer PDW sind auf Geschwindigkeit getrimmt. Im Prinzip kommen mehrere Fast Track Systeme parallel zum Einsatz. Konkret bedeutet dies, dass die Serverknoten, der Storage und das Netzwerk so ausgewählt wurden, damit das Auftreten eines Flaschenhalses vermieden werden kann. Durch den parallelen Einsatz optimierter Komponenten skaliert das System horizontal. Das bedeutet in der Praxis, dass die Antwortzeiten auch bei sehr großen BI-Lösungen schnell und prognostizierbar bleiben. Die nachfolgende Grafik veranschaulicht schematisch das Verhalten eines PDWs im Vergleich zu SMP-basierten Systemen, wie ein Fast Track System oder ein nicht optimiertes System.

Skalierung Parallel Data Warehouse im Vergleich zu SMP-Systemen.

Abbildung 3: Skalierung Parallel Data Warehouse im Vergleich zu SMP-Systemen. Quelle: Trivadis

2. Parallel Data Warehouse (PDW)

Im Sommer 2008 hat Microsoft die Firma DATAllegro und ihre Lösung im Bereich MPP akquiriert. Zwei Jahre später brachte Microsoft die Appliance Parallel Data Warehouse (PDW) auf den Markt, basierend auf der Lösung von DATAllegro. Seither sind zwei Jahre vergangen. Am Produkt wurde viel verbessert und seit dem Frühjahr 2012 ist die PDW bereits in der Version AU3 (Appliance Update 3) erhältlich. Eine PDW ist für ein sehr großes Data Warehouse ausgerichtet und lässt sich bis in den Petabyte-Bereich skalieren.

Eine Appliance wie die PDW besteht aus Hardware, Software und Services und wird betriebsbereit vom Hersteller geliefert. Bei einer PDW kommen die Architektur und die Software von Microsoft, die Hardware von HP oder von Dell. Es kann durchaus sein, dass in Zukunft weitere Hardwarehersteller ebenfalls eine PDW anbieten. Das System ist grundsätzlich offen. Es kommt ausschließlich Industrie-Standardhardware zum Einsatz.

2.1 Hardware Architektur

Eine PDW besteht grundsätzlich aus zwei Racks: Einem Control Rack und einem Data Rack. Das Control Rack enthält alle Komponenten, welche der Administration, Steuerung und Kommunikation mit der PDW dienen. Das Data Rack besteht aus baugleichen Serverknoten. Auf jedem dieser Serverknoten ist eine spezielle SQL Server 2008-Instanz installiert. Jedem Serverknoten ist ein dedizierter Storage Knoten zugewiesen (shared nothing). Die Datenbank und ihre Tabellen sind über diese physikalischen Server hinweg verteilt, erscheinen aber in einer Client Applikation als eine einzige (logische) Datenbank mit ihren dazugehörigen Tabellen und Objekten. Der Control Node steuert und verwaltet die Ausführung der Abfragen. Auf dem Control Node wird auch die Information gehalten, welche Daten auf welchem Knoten gespeichert werden.

Die massiv parallele Architektur des Parallel Data Warehouse

Abbildung 4: Die massiv parallele Architektur des Parallel Data Warehouse

2.2 Transparente Verteilung der Daten

Die Performance der PDW Appliance ist exzellent und prognostizierbar, auch für feingranulare Daten. Es können Analysen und Auswertungen erstellt werden, die mit einem herkömmlichen System (SMP) aufgrund von Kapazitätsrestriktionen oder Einschränkungen bezüglich der Verarbeitungszeit nicht durchführbar sind. Der Schlüssel hierfür liegt in der (richtigen) Verteilung der Daten. Ein bedeutender Vorteil von PDW ist, dass die Verteilung der Daten von PDW transparent übernommen wird. Zudem ist die Komplexität, die hinter der Verteilung steht, für den Anwender nicht sichtbar. Mit zwei einfachen, deklarativen Einstellungen kann zwischen replizierten und verteilten Objekten unterschieden werden. Kleine Tabellen (gewöhnlich Dimensionen) werden auf jeden Compute Node repliziert. Dies bedeutet, dass auf jedem Knoten eine vollständige Kopie der Daten einer Tabelle abgelegt wird. Große Tabellen, es handelt sich meist um Faktentabellen, werden hingegen verteilt (distributed). Auf einem Knoten wird hier jeweils nur ein Segment der Daten gespeichert.

Von außen betrachtet erscheint die Appliance wie ein einzelner Datenbank Server. Es spielt keine Rolle, wie die Daten physikalisch auf den einzelnen Knoten verteilt sind. Der Entwickler der Client Applikation muss sich mit diesen Details nicht beschäftigen. Die PDW übernimmt die Auflösung und das Management, welcher Teil der Abfrage auf welchen Knoten zur Ausführung geschickt wird. Diese Transparenz gibt es auch für Entwickler des Datenbank-Designs auf der Appliance: Beim Anlegen der Datenbank und der Tabellen müssen sie sich nicht um Filegroups und die Implementierung der physischen Ablage kümmern. Das macht die Appliance selbst.

Fazit

Wenn das eingesetzte Data Warehouse (DWH) an seine Grenzen stößt, gibt es zielführende Strategien, um auch zukünftige Anforderungen abdecken zu können. Bei kleineren DWHs kann die Lösung darin liegen, alle Komponenten eines SMP-Systems optimal aufeinander abzustimmen. Für sehr große, skalierbare Systeme im Terabyte-Bereich sind massiv parallele Systeme (MPP) ideal. Bei Systemen dieser Grösse spricht man auch von Enterprise Data Warehouse. Als Beispiel seien hier Oracle Exadata, Teradata Data Warehouse Appliance, IBM Netezza oder Microsoft Parallel Data Warehouse genannt. Die angebotenen Systeme der verschiedenen Hersteller sind ausgereift. Somit ist es durchaus sinnvoll, jetzt in neue Technologie zu investieren.

Literatur und Links

Trivadis
http://www.trivadis.com/

Fast Track Reference Guide für Microsoft SQL Server 2008 R2
http://msdn.microsoft.com/en-us/library/gg605238.aspx

Fast Track Reference Guide für Microsoft SQL Server 2012
http://technet.microsoft.com/en-us/library/hh918452.aspx

Microsoft Parallel Data Warehouse
http://www.microsoft.com/sqlserver/en/us/solutions-technologies/data-warehousing/pdw.aspx

HP Enterprise Data Warehouse Solution for Microsoft SQL Server
http://h71028.www7.hp.com/enterprise/us/en/partners/microsoft-enterprise-data-warehouse-solution.html?jumpid=ex_r2858_us/en/large/tsg/microsoft_edw

Dell Parallel Data Warehouse Appliance
http://www.microsoft.com/sqlserver/en/us/solutions-technologies/Appliances/Dell-pdw.aspx

Microsoft Case Study for SQL Server 2008 R2 Parallel Data Warehouse
http://www.microsoft.com/casestudies/Microsoft-SQL-Server-2008-R2-Enterprise/Hy-Vee/Hy-Vee-Boosts-Performance-Speeds-Data-Delivery-and-Increases-Competitiveness/710000000776

  1. 12. Februar 2013 um 9:56 pm

    I consider this specific article , “Microsoft Parallel Data Warehouse datatipp”, extremely compelling and the blog post was indeed a
    superb read. Thanks for the post-Tonia

  2. BD Architekt
    29. April 2013 um 2:03 pm

    OK und was ist daran so NEU? Diese Architektur gibt es seit den 70er Jahren (Tandem Computer) und seit den 80ern mit einer leistungsfähigen SQL Datenbank. Diese Systeme werden heute von HP als Nonstop Server überwiegend im Finanz und Telco Bereich aber auch für große BI Anwendungen angeboten und bewerkstelligen neben der parallelen Verarbeitung auch die größten Datenvolumen überhaupt.

  1. No trackbacks yet.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: