Archiv

Archive for the ‘Parallel Data Warehouse’ Category

Bericht vom Azure Data Lake Event

Am 2.3.2018 habe ich am Azure Data Lake Event, durchgeführt von Microsoft und Trivadis, teilgenommen. Die Referenten gaben einen Überblick über das Potential und die Möglichkeiten von Microsoft Azure Data Lake und unterlegten dies auch gleich mit live Code-Beispielen, die sie während der Veranstaltung zeigten.

Speaker waren:

  • Michael Rys, Principal Program Manager Big Data Team, Microsoft
  • Patrik Borosch, Technical Solution Professional Data Platform, Microsoft
  • Marco Amhof, Senior Consultant für Azure Data Lake Analytics und Busines Intelligence, Trivadis

Mit Hilfe des Azure Data Lakes können einerseits unterschiedlichste Daten gespeichert, andererseits aber auch analysiert und weiterverarbeitet werden. Microsoft hat eine neue Sprache zur Auswertung dieser Daten entwickelt: U-SQL. Diese Sprache ist eine Kombination aus T-SQL und C# und bietet vor allem Microsoft Entwicklern ein komfortables Werkzeug im Bereich von Big-Data-Analysen.

Azure Data Lake und diverse Möglichkeiten für Analytics

Erstaunlicherweise war die erste Frage von Michael Rys: In welcher Sprache sollen  die Vorträge gehalten werden (in Hochdeutsch, Schweizer-Deutsch oder Englisch)? … Michael Rys stammt nämlich aus der Schweiz und lebt schon seit über 20 Jahren in den USA und arbeitet bei Microsoft.

Michael Rys hat erklärt, dass man sich den Azure Data Lake (ADL) jedoch nicht als See vorstellen sollte, wo die Daten wahllos hineingekippt werden, sondern eher ähnlich einer Verzeichnisstruktur, wo es Unterordner und verschiedene Bereiche gibt. Dort werden die Daten möglichst im Original-Format und ohne zusätzliche Schema-Informationen gespeichert. D.h. auch wenn man seine Daten in einem Data Lake kopiert und aufbewahrt, müssen diese verwaltet und organisiert werden. Das wird einem durch einen Data Lake nicht abgenommen. Hierzu könnte z.B. das Tool Azure Data Catalog verwendet werden.

Various Big Data Solutions

Mit U-SQL lassen sich die Daten gemäss „Query where the data lives“ auswerten und zwar mit dem Ziel dass möglichst wenig Daten kopiert werden müssen und das Ganze möglichst performant ist.

Daten mit U-SQL und Azure Data Lake Analytics (ADLA) abfragen

 

Bei Azure Data Lake Analytics sind bereits 6 sogenannte kognitive Funktionen eingebaut:

  • Face API
  • Image Tagging
  • Emotion Analysis
  • OCR
  • Text Key Phrase Extraction
  • Text Sentiment Analysis

Aber auch Funktionalitäten wie z.B. das Durchsuchen von PDF-Dateien lassen sich relativ einfach realisieren, indem Open-Source .Net Code einfach eingebunden (z.B. von GitHub) und verwendet werden kann, wie Marco Amhof eindrücklich mit einem seiner vielen Code-Beispiele und Live Demos demonstriert hat:

  • ImageTagging (ein Feature aus den Cognitive Services) mit Visualisierung in PowerBI

    Demo: Image Tagging

     

  • Verarbeitung von 2 CSV Files und einer Abfrage (Federated Query) aus Azure SQL DWH mit dem Ergebnis, mit diesen Daten einen Data Mart nach Azure Data Lake zu schreiben, und diesen wiederum mit PowerBI zu visualisieren.(Der Data Mart lässt sich ebenfalls mit dem Polybase Feature in Azure SQL DWH abfragen. Alternativ kann dieser Data Mart von PowerBI extrahiert und nach Azure Analysis Services deployed werden.)
  • PDFParsing: Mit einem Open Source PDF Parser lassen sich beliebige PDF Files parsen. Diese wurden dann mit dem Keyword Extractor (Cognitive Services Framework) verarbeitet und die in PowerBI mit dem WordCloud Custom Visual visualisert


Patrik Borosch thematisierte unter anderem die Frage: Wird das traditionelle Data Warehouse überhaupt noch benötigt? Oder kann man alle Daten in einen Data Lake hochladen und dann direkt mit Hadoop, Spark, R oder Azure Data Lake Analytics auswerten? Die Antwort die er gegeben hat, ist ein klares JA: Das Data Warehouse wird noch benötigt, aber der grösste Nutzen für das Unternehmen entsteht dann, wenn das relationale Data Warehouse als Teil einer Big Data Lösung betrieben wird.

Denn immer noch müssen die Daten von OLAP-System, CRM, MDM (Master Data Management) etc. integriert, bereinigt, aggregiert und ausgewertet werden. Und genau diese Dinge kann ein Data Warehouse sehr gut. Wenn nun das Data Warehouse in die Cloud migriert wird (z.B. als Azure Data Warehouse oder auch als vollwertiger SQL-Server auf einer Azure-VM) hat man quasi das Beste aus zwei Welten und kann strukturierte und nicht strukturierte Daten miteinander verbinden und daraus neue Erkenntnisse erzielen. Patrik Borisch gab auch den Hinweis, dass sich derzeit eine neue Lösung im der Public Preview-Phase befindet: Azure SQL Database Managed Instance.

Azure Data Lake, Analytics, and Data Warehouse

Mein Fazit: Das war eine gelungene, halbtägige Veranstaltung mit hochkarätigen Speakern, die es verstanden haben, einerseits einen Überblick über Azure Data Lake zu geben, und andererseits mit praktischen Code-Beispielen die gezeigten Themen direkt demonstrieren konnten und auch teilweise in die Tiefe zu gehen. Während der Veranstaltung gab es immer wieder Fragen seitens der Zuhörer, die aus sehr verschiedenen Branchen kamen.

Alle Fragen konnten von den Speakern detailliert und zufriedenstellend erklärt werden. Und auch die Organisatoren Willfried Färber und Rosmarie Stutz haben einen tollen Job gemacht: Sie haben tolle Speaker zu einem sehr spannenden Thema hier in die Schweiz geholt. Cool!

Advertisements

Themen Lunch: Microsoft SQL Server 2014 Neuigkeiten

Die Fa. Trivadis bietet einen kostenlosen Themen Lunch zur brandneuen Version des Microsoft SQL Server 2014 an. Die Veranstaltung geht über den Mittag und dauert ca. 2 Stunden. Meinrad Weiss referiert über die wichtigsten Neuerungen des SQL Server 2014, wie z.B. Mission Critical Performance, In-Memory OLTP, In-Memory Data Warehouse, Azure Cloud Services für DB Applikationen, Ausblick zu Big Data, etc. Nach dem Event werden Snacks offeriert und man hat Gelegenheit, sich mit den anderen Teilnehmern und dem Referenten auszutauschen.

Für den Event gibt es 2 Termine:

  • 20. Februar 2014 in Basel, Beginn 11:00 Uhr
  • 5. März 2014 in Glattbrugg, Beginn 11:00 Uhr

Hier geht’s zu den Detailinformationen und zur Anmeldung.

Microsoft Parallel Data Warehouse

27. Dezember 2012 2 Kommentare

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

Videos der TechEd North America 2012

Anmeldung zu Microsoft TechTalk in Wallisellen: Datenbankkonsolidierung mit SQL Server Private Cloud und Professional Data Warehousing

Am 9. Mai 2012 (9:00 bis 12:00 Uhr)  findet bei Microsoft Schweiz, Wallisellen, ein halbtägiger TechTalk zum Thema „Datenbankkonsolidierung mit SQL Server Private Cloud und Professional Data Warehousing“ statt. Es geht also um Microsoft FastTrack, DBC (Database Consolidation) und PDW (Parallel Data Warehouse). Der von Trivadis  und HP durchgeführte TechTalk besteht aus einem Mix zwischen Theorie und konkreten Zahlen aus realisierten Projekten wie auch Live Demos. Nach dem TechTalk sind Sie in der Lage die verschiedenen Angebote richtig einzuschätzen und Vorteile für Ihre Umgebung zu erkennen. Interessant ist der Techtalk vor allem für System Architekten, Entwickler und Entscheidungsträger im Bereich Datenbank und Data Warehouse Infrastruktur.

Referenten: Meinrad Weiss, Trivadis AG Marc Wunderli, HP Schweiz

Weitere Details und Anmeldung

Agenda/Themen

Produkte: SQL Server
Lösungen: DWH, Private Cloud, Datenbankkonsolidierung

Einführung in Engineered Systems, Appliances und Private Cloud
– Überblick, was sind die Ziele, was machen andere Hersteller

Hochperformante und Kostengünstige Data Warehouse Systeme
– Grundlagen zu Fast Track
– System Architektur und deren Auswirkung auf Data Warehouse Applikationen
– System Sizer und System Limiten
– Vorstellung konkreter Case Study: Vorteile der Umstellung auf Fast Track
– Konkrete Fast Track Angebote von HP

Effizienter Datenbank Betrieb mit „Database Consolidation Appliance“ (DBCA)
– Grundlagen zu DBC
– System Architektur
– Vorgehen und Tools für den effizienten Aufbau und Betrieb
– Demo, DBC in Action
– Konkrete HP Angebote im Bereich DBC von HP

Beste Skalierbarkeit dank massiv paralleler Verarbeitung mit „Parallel Data Warehouse“ (PDW)
– Grundlagen zu PDW
– System Architektur und deren Auswirkung auf Data Warehouse Applikationen
– Abgrenzung zu Fast Track Systemen
– Demo PDW in Action
– Konkrete Angebote im Bereich PDW von HP

TechTalk: Datenbankkonsolidierung mit SQL Server Private Cloud und Professional Data Warehousing

Am 9. Mai 2012 findet bei Microsoft Schweiz, Wallisellen, ein halbtägiger TechTalk zum Thema „Datenbankkonsolidierung mit SQL Server Private Cloud und Professional Data Warehousing“ statt. Es geht also um Microsoft FastTrack, DBC (Database Consolidation) und PDW (Parallel Data Warehouse). Der von Trivadis durchgeführte TechTalk besteht aus einem Mix zwischen Theorie und konkreten Zahlen aus realisierten Projekten wie auch Live Demos. Nach dem TechTalk sind Sie in der Lage die verschiedenen Angebote richtig einzuschätzen und Vorteile für Ihre Umgebung zu erkennen. Interessant ist der Techtalk vor allem für System Architekten, Entwickler und Entscheidungsträger im Bereich Datenbank und Data Warehouse Infrastruktur.

Weitere Details und Informationen zur Anmeldung werden in Kürze bekanntgegeben.