SlideShare ist ein Scribd-Unternehmen logo
White Paper saracus
Big Data

Stärken und Schwächen im praktischen
Einsatz von Big Data Appliances
Big Data Appliances




                            Appliances spielen im IT-Markt eine zentrale Rolle. Eine Appliance ist ein Komplettsystem, welches
                            aufeinander abgestimmte Komponenten für einen dezidierten Einsatzzweck vereint. Im Bereich der Big
                            Data Appliances umfassen die Kernkomponenten sämtliche Hard- und Software von den
                            Netzwerkadaptern über Rechenknoten bis zur Datenbank. Diese sind allerdings nicht beliebig
                            konfigurierbar, sondern nur in ausgewählten Konstellationen einsetzbar. Die wesentlichen Vorteile einer
                            Appliance werden in der schnellen Implementierung, dem effizientem Einsatz und den verringerten
                            Betriebs- und Wartungskosten gegenüber klassischen Systemen gesehen.

                            Komplettsysteme stellen damit eine von drei Möglichkeiten der strukturellen Architektur eines BI
                            Systems dar. Neben dem klassischen best of bread Architektur-Ansatz, der auf einem
                            unternehmensoptimierten Mix an Komponenten basiert, existiert noch der open-source Ansatz mit der
                            Zielrichtung kostengünstiger Hard- und Software. Appliances befinden sich daher in einer starken
                            Konkurrenzsituation und benötigen überzeugende Argumente zur Positionierung. Hierzu ist das Thema
                            Big Data hervorragend geeignet, da diese Art der Informationsverarbeitung neue Herausforderungen mit
                            sich bringt und einen Architekturwechsel unterstützen kann. Denn zu den Einführungs- und
                            Betriebsaufwänden einer Appliance ist in den meisten Fällen auch ein erheblicher Migrationsaufwand zur
                            Integration in bzw. von bestehenden Architekturen notwendig.

                            Dieser Artikel beschreibt anhand von drei Beispielen die Einsatzszenarien bzw. Stärken und Schwächen
                            von Big Data Appliances im praktischen Einsatz.



                            Big Data Appliance

                            Appliances waren schon vor Big Data ein Thema, aber mit Big Data erleben sie eine Art Renaissance. Alle Appliances
                            stellen deutlich ihre Möglichkeiten in diesem Bereich heraus. Die Angst vor überdimensionierten und nicht mehr betreib-
                            bzw. wartbaren Systemen im Zeitalter von Big Data erweckt wieder den Bedarf an „Systemen von der Stange“. Hier setzen
                            Appliances erfolgreich an. Die Kapselung von Hard- und Software zu einem vorkonfektionierten Funktionsbaustein
                            scheint genau diesem Wunsch nachzukommen. Vier führende Anbieter in diesem Segment werden hier beschrieben und
                            auf den Prüfstand gestellt, ob sie die Erwartungen erfüllen können. Neben der technischen Beschreibung sind dabei
                            insbesondere die Einsatzszenarien, Migrations- und Integrationsmöglichkeiten von Interesse. Und diese Themen werden
                            nicht nur von Big Data getrieben, sondern von der gesamten Infrastrukturlandschaft. Die folgende Tabelle zeigt führende
                            Anbieter inkl. zentraler Eckdaten der Lösung.




saracus consulting GmbH
Hafenweg 46
D-48155 Münster
Fon. +49 251 98721 0
Fax. +49 251 98721 26


saracus consulting AG
Täfernstrasse 4
CH-5405 Baden-Dättwil
Fon. +41 56 483 02 20
Fax. +41 56 483 02 21

saracus consulting d.o.o.
ul. Bulevar Svetog Cara
Konstantina, br. 82-86
SRB-18000 Nis


     www.saracus.com                                                                                                                    Seite 2
Big Data Appliances




                      Greenplum

                      Die Greenplum Data Computing Appliance (DCA) ist eine modular aufgebaute, hoch skalierbare Plattform, die eine
                      relationale Datenbank mit Massive-Parallel-Processing-Architektur (MPP) und Apache-Hadoop vereint und so die
                      Analyse, Auswertung und Verarbeitung von strukturierten (relationalen), semi-strukturierten und unstrukturierten
                      (Big Data) Daten in einer einheitlichen Umgebung ermöglicht. Die DCA kann aus den folgenden Komponenten
                      zusammengesetzt sein:

                      •     Greenplum Database Standard Module
                            Ist ein spezielles, hochskalierbares Data-Warehousing-Appliance-Modul, das mit seiner Architektur Datenbank-,
                            Computing-, Storage- und Netzwerk-Funktionalitäten vereint.

                      •     Greenplum Database High Capacity Module
                            Stellt eine Erweiterung des Greenplum Database Moduls dar. Es ermöglicht das Hosting von mehreren Petabyte
                            Daten ohne den Stromverbrauch, die Kosten oder den Platzbedarfs massiv in die Höhe zu treiben.

                      •     Greenplum HD
                            Dieses Modul basiert auf Hadoop-Basis und verbindet die Hadoop-Technologie mit der Greenplum-DB und
                            ermöglicht eine gemeinsame Verarbeitung von strukturierten und unstrukturierten Daten.

                      •     Greenplum Data Integration Accelerator
                            Das Data Integration Accelerator (DIA) Modul dient als Hostsystem für Business-Intelligence- oder ETL-
                            Applikationen, damit diese denselben hochleistungsfähigen Interconnect wie die anderen integrierten Module
                            nutzen können.

                      Greenplum Database und Greenplum HD sind sich gegenseitig ergänzende Technologien, um eine leistungsfähige
                      Lösung für die Analyse von strukturierten, semi-strukturierten und unstrukturierten Daten zur Verfügung zu stellen.
                      Wenn diese beiden Technologien wirksam zusammen eingesetzt werden, können komplexe, hoch performante,
                      interaktive Analysen durchgeführt werden, insbesondere durch die Verknüpfung von strukturierten und semi-
                      strukturierten Daten, die sowohl in der Greenplum Database als auch im Hadoop-Distributed-File-System (HDFS)
                      gespeichert sind.

                      Die DCA ist in verschiedenen Ausführungen erhältlich. Ausgehend von einem Single Primary Rack, das lediglich das
                      Greenplum Database Standard bzw. High Capacity Module enthält, kann die Appliance in Quarter-Rack-Schritten
                      um eine beliebige Anzahl von jedem der vier zur Verfügung stehenden Module erweitert werden.




                          Quelle: http://www.greenplum.com/technology/architecture

www.saracus.com                                                                                                                    Seite 3
Big Data Appliances




                      Greenplum-Database

                      Das Greenplum-Database Modul basiert auf der Open-Source Technologie PostgreSQL und nutzt Massiv Parallel
                      Processing (MPP), dass auch als Shared Nothing Architektur bezeichnet wird. Die Greenplum-DB nutzt diese
                      Technologie, um z. B. das Laden von sehr großen Datenmengen in ein DWH zu verteilen und hierfür alle zur
                      Verfügung stehenden Ressourcen parallel für die Ausführung eines Prozesses zu nutzen. Die Greenplum-DB besteht
                      im Prinzip aus mehreren PostgreSQL-Datenbank-Instanzen, die gemeinsam als ein geschlossenes DB-Management-
                      System fungieren. Sie wurde aus der Open-Source-Technologie PostgreSQL 8.2.15 entwickelt und ist für die End-
                      User besonders in Bezug auf SQL-Support, Features, Konfiguration und End-User-Funktionalität sehr ähnlich zu
                      PostgreSQL.

                      Unter der Oberfläche wurde PostgreSQL jedoch für den Einsatz in der parallelen Struktur der Greenplum-DB
                      angepasst und erweitert, um in der Lage zu sein, eine Query aufzuteilen und die entstandenen Teil-Queries auf die
                      verschiedenen PostgreSQL-Datenbank-Instanzen zu verteilen. Die Kommunikation zwischen den einzelnen DB-
                      Instanzen erfolgt über den Greenplum-Interconnect. Erst mit Hilfe dieses Networking Layers kann das System aus
                      verschiedenen einzelnen PostgreSQL-DB-Instanzen als eine logische Datenbank funktionieren. Zusätzlich enthält die
                      Greenplum-DB Funktionen, um PostgreSQL für Business-Intelligence Belastungen zu optimieren. Zum Beispiel
                      External Tables für das parallele Laden von Daten, Ressource Management, Query Optimization und Storage-
                      Management, Partitioning etc..


                      Der Master-Server fungiert als Entry-Point zu
                      einem Greenplum DB-System. Er verwaltet die
                      Client-Connections und koordiniert die Segment-
                      Server. Der Master-Server enthält keine User-
                      Daten, aber einen System-Katalog. Aus diesem
                      Grund hat ein Master-Server in der Regel eine
                      sehr    geringe    Festplatten-Auslastung.   In
                      produktiven Systemen wird           der freie
                      Speicherplatz daher oft für temporäre
                      Informationen wie „Load-“ oder „Backup-Files“
                      genutzt. Er benötigt eine schnelle CPU für
                      Loading-, Connection- und Query-Prozesse.

                                                                          Quelle: http://www.greenplum.com


                      Die Segment-Server werden in einem Greenplum-System zur Speicherung der Daten und zum Ausführen von (Teil)-
                      Abfragen verwendet. Sie können niemals direkt durch den User angesprochen werden, sondern die Kommunikation
                      erfolgt immer über den Master-Server.

                      Segment-Server bestehen aus einzelnen Segmenten, auf welchen alle User-definierten Tabellen mit ihrer gesamten
                      Index-Struktur verteilt werden. Jedes Segment enthält somit eine eindeutige Teilmenge der Gesamt-Datenmenge.

                      Die Anzahl von Segmenten auf einem Segment-Server ist durch die Anzahl CPU’s oder die Anzahl Cores festgelegt.
                      Wenn ein Segment-Server z. B. zwei Dual-Core-Prozessoren besitzt, können auf dem Server zwei oder vier Segmente
                      laufen. Bei drei Dual-Core-Prozessoren können drei, sechs oder zwölf Segmente laufen usw... Die optimale Anzahl
                      an Segmenten für ein bestimmtes Hardware-System muss mit Hilfe von Performance-Tests evaluiert werden.

                      Der Interconnect repräsentiert die Netzwerk-Schicht einer Greenplum-Datenbank. Wenn ein User eine Verbindung
                      zur DB herstellt und eine Query absetzt, werden – wie bereits im vorherigen Absatz beschrieben - auf Anweisung
                      des Master-Servers auf jedem Segment-Server in jedem Segment Prozesse erstellt, die die für das Resultat der
                      Query notwendige Arbeit ausführen. Der Interconnenct stellt bei diesem Prozess sowohl die Kommunikation
                      zwischen den einzelnen Segment-Servern bzw. Segmenten her als auch die Kommunikation mit dem Master-Server.
                      Er benutzt hierfür einen Standard Gigabit Ethernet Switch.




www.saracus.com                                                                                                                 Seite 4
Big Data Appliances




                      Greenplum HD

                      Das Greenplum HD Modul ist eine vollständig unterstützte und zertifizierte Version des Apache Hadoop Stacks.
                      Hadoop ist ein in Java geschriebenes Open Source Framework für skalierbare, verteilt arbeitende Software. Es
                      basiert auf dem MapReduce-Algorithmus und bietet mit Hilfe seiner automatischen Parallelisierung die Möglichkeit,
                      intensive Rechenprozesse mit großen Datenmengen auf Computerclustern durchzuführen.

                      Das Greenplum HD Modul beinhaltet die Komponenten Hadoop Distributed File System, MapReduce, Hive, Pig,
                      HBase, Zookeeper und Mahout.

                      Das Hadoop Distributed File System (HDFS) basiert auf Java und ist ein hochverfügbares, leistungsfähiges
                      Dateisystem zur Speicherung von großen Datenmengen. Es hat sich als solide Grundlage für die Verwendung von
                      Hadoop bewährt, denn es ist in der Lage die verwendeten Dateien in Datenblöcke mit fixer Länge zu zerlegen und
                      diese redundant auf die Dateisysteme aller als Knoten verwendeten Rechner in einem Netzwerk zu verteilen.

                      MapReduce wurde auf Grundlage der Funktionen map und reduce entwickelt und ist ein Hadoop-Framework für
                      parallele Berechnungen über große Datenmengen auf Computerclustern. Mit diesem Framework ist es möglich in
                      einfacher Art und Weise Applikationen zu entwickeln, die große Mengen an strukturierten und unstrukturierten
                      Daten abarbeiten können. Hive erweitert Hadoop um Data-Warehouse-Funktionalitäten und ermöglicht durch den
                      Einsatz der Anfragesprache HQL und Indizes das Zusammenfassen von Daten, Ad-Hoc-Queries und die Analyse von
                      großen Datenmengen, die in Hadoop-kompatiblen File-Systeme gespeichert sind. Es bietet als SQL-ähnliche
                      Schnittstelle eine zeilenbasierte Speichermöglichkeit, die in Kombination mit der Komprimierung ein besseres
                      Komprimierungsverhältnis beim Speichern von Daten gewährleistet. Pig ist eine verfahrensorientierte
                      Programmiersprache zur Verarbeitung großer, teilweise strukturierter Datenmengen auf Basis der Hadoop
                      MapReduce-Plattform. Als Alternative zu Java soll es das Entwickeln von MapReduce-Jobs erleichtern. HBase ist
                      eine verteilte, versionierte, spaltenorientierte Datenbank, die User-Applikationen zufälligen Real-Time Read/Write-
                      Access auf Big Data zur Verfügung stellt. Zookeeper ist ein hoch verfügbares System, um verteilte Prozesse zu
                      koordinieren. Mahout ist eine freie, in Java geschriebene Programmbibliothek für verteiltes, maschinelles Lernen
                      und Data Mining. Die Software setzt auf Hadoop auf.

                      Greenplum Data Integration Accelerator

                      Das Greenplum Data Integration Accelerator (DIA) Modul wurde entwickelt, um „Fast Data Loading“ in die
                      Greenplum Data Computing Appliance zu ermöglichen. Es dient dazu, das Greenplum-Tool „gpfdist“ mit den
                      anderen Komponenten in einer DCA zu vereinigen und setzt das interne 10GB/Sek High-Speed Netzwerk ein, um
                      Daten schnell in die DCA zu laden. Das DIA Modul, das in einer DCA als Server arbeitet, ist speziell angefertigt, um
                      Batch-Loading und Micro-Batch-Loading durchzuführen und unterstützt bereits einige Data-Integration-Tools wie
                      Informatica, Talend und Pentaho. Diese müssen dafür allerdings auf dem DIA-Server installiert werden. gpfdist ist
                      Greenplums Parallel-File-Server-Distribution-Utility. Es kann als ein Netzwerkprotokoll ähnlich dem HTTP-Protokoll
                      verstanden werden und wird in einer Greenplum DCA für das parallele Verarbeiten von External-Table-Files und
                      Writable-External-Tables verwendet

                      Fazit

                      Die Besonderheit der Greenplum-Architektur ist die modulare Zusammensetzung. Je nach Einsatzszenario können
                      die Module eingesetzt werden. Spielen beispielsweise unstrukturierten Daten keine Rolle, wird auf das Greenplum-
                      HD-Modul verzichtet. Weiterhin ist die Hardware-Unabhängigkeit hervorzuheben. Neben der konfektionierten DCA
                      ist es möglich, eigene Hardware zu nutzen, die Module dort zu installieren und als Appliance „Marke Eigenbau“ zu
                      verwenden.

                      Aus den bisherigen Erfahrungen ist eine Integration der Greenplum DCA in bestehende BI-Systeme sinnvoller als
                      eine Ablösung. Idealerweise benutzt man Greenplum für den Einsatz im analytischen Bereich. Hier können die
                      Stärken, die ja hauptsächlich in der MPP-Architektur liegen am besten eingesetzt werden. Die Performance der
                      Analytik wird in solchen Szenarien enorm verbessert und auch das Füllen der Faktentabellen wird enorm
                      beschleunigt. Im Bereich Core-DWH ist der Einsatz einer Greenplum nicht unbedingt immer gewinnbringend.
                      Solange der große Teil lediglich INSERTS in die DB vornimmt, können die Vorteile der parallelen Verarbeitung
                      genutzt werden. Da in diesem Bereich häufig mit UPDATE und teilweise auch mit DELETE gearbeitet wird, gibt es
                      nicht immer Performance-Verbesserungen.


www.saracus.com                                                                                                                    Seite 5
Big Data Appliances




                      Es gibt viele Gründe aus unterschiedlichen Bereichen, die für einen Einsatz von Greenplum sprechen. Performance
                      im Bereich Reporting und ETL (Data Mart), Investitions- und Betriebskosteneinsparungen, enorme Skalierbarkeit
                      und der modulare Aufbau sind dabei Kriterien, die sich in der Praxis bestätigt haben. Die konkrete Ausprägung ist
                      jeweils von den gegebenen Rahmenbedingungen abhängig. Bei einer Gegenüberstellung von Kosten und Nutzen
                      muss man zu dem Schluss kommen, dass es sich insbesondere für den analytischen Bereich
                      (Bewirtschaftung/Reporting) inklusive der Einbindung von Big Data Daten anbietet, Greenplum einzusetzen. Dies
                      betrifft sowohl neue Entwicklungen wie auch die Ablösung oder Migration von BI-Strukturen. Weniger geeignet ist
                      der Einsatz in operativen und transaktionsorientierten Systemen bzw. Systemen mit einer hohen Rate an Update-
                      /Delete-Jobs.

                      Für die Anbindung Greenplum‘s an weitere Werkzeugkomponenten im BI-Umfeld stehen viele Möglichkeiten zur
                      Verfügung. Im ETL- und Frontend-Bereich finden sich mit Informatica, Talend, Pentaho Data Integration (Kettle),
                      IBM DataStage, MicroStrategy, IBM Cognos, SAS, Information Builders, Oracle OBIEE, SAP Business Objects, Alpine
                      Miner, Attivio Active Intelligence, Qlikview, Recombinant i2b2, Revolution Analytics und Squid Solutions die
                      gängigen Werkzeuge wieder.

                      Zu beachten ist, dass besonders im Bereich ETL unter Umständen aufwändige Änderungen an den Mappings
                      vorgenommen werden müssen, da die DB ja auf Postgres basiert. Bei den BI-Tools sollte das ähnlich sein, solange
                      sie nicht wie z.B. MicroStrategy über einen eigen DB-spezifischen SQL-Generator verfügen. Weiterhin sollte geprüft
                      werden, wie die Connection hergestellt wird. Sind es proprietäre Treiber kann in der Regel die volle Geschwindigkeit
                      von Greenplum genutzt werden, bei „normalen“ ODBC-Treibern können ggf. Leistungseinbußen auftreten.

                      Die Umstellung einer klassischen Oracle-basierenden Analyse-DB mit MicroStrategy als Analysetool verursacht
                      bspw. keine großen Probleme bei einer Umstellung auf Greenplum, da nahezu alle Datentypen migriert werden
                      können und im Frontend-Bereich neben der DB-Typumstellung ggf. einige Performance-Einstellungen getestet
                      werden müssen. Hingegen kann die Umstellung im ETL-Bereich bspw. mit Informatica größeren Aufwand bedeuten,
                      da nicht nur Connections umgestellt werden müssen, sondern auch Source und Targets sowie SQL-Overrides etc..
                      Zusätzliche Problematik bringt die Tatsache, dass lediglich für das Schreiben in Greenplum ein PWX-Adapter von
                      Informatica zur Verfügung gestellt wird. Für das Lesen und somit auch das Aufbauen der Transformationen und der
                      Caches wird eine ODBC-Verbindung genutzt, die nur mäßige Performance aufweist. Auch die Update-Strategy von
                      Informatica wird in Greenplum nicht zufriedenstellend unterstützt, so dass Updates außerhalb von Informatica
                      durchgeführt werden mussten.

                      Die Kosten, die benötigte Zeit und der Aufwand einer Einführung bzw. Migration hängen sehr stark vom
                      Einsatzszenario ab. Neben einigen Kinderkrankheiten, wie z.B. mangelnde Unterstützung von
                      Modellierungswerkzeugen, die zukünftig nicht mehr zu erwarten sind, bestimmen im Wesentlichen Einsatzzweck
                      und Systemarchitektur die Hürden einer Einführung. Wenn Greenplum lediglich für die Bewirtschaftung von Data-
                      Marts und Ihre Analyse eingesetzt wird, kann das System in relative kurzer Zeit aufgebaut werden. Anders verhält es
                      sich, wenn ein komplettes DWH mit sehr vielen Mappings zur Bewirtschaftung abgelöst wird. Hier kann die
                      Einführung sehr langwierig und teuer werden. Trotzdem liegt eine Stärke von Greenplum im Bereich Data-Loading.
                      Wenn die Möglichkeiten des MPP richtig ausgeschöpft werden, gibt es derzeit keine andere Lösung am Markt,
                      welche die Daten schneller in die DB laden kann. Auf der anderen Seite besitzt die Greenplum enormes Potential bei
                      der Performance im Bereich der Analyse mit BI-Werkzeugen. Praxistests haben bewiesen, dass bei optimaler
                      Modellierung die Ergebnisse im Vergleich zu klassischen Datenbanken besonders bei großen Datenmengen bis zu
                      150mal schneller vorliegen.

                      Das größte Potential von Greenplum steckt sicherlich in der Kombination relationaler DB und Big Data innerhalb
                      einer BI-Umgebung. Durch diesen Ansatz sollte es in Zukunft auf einfache Art und Weise möglich sein,
                      unstrukturierte Daten in strukturierter Form zu analysieren und mit strukturierten Daten zu vergleichen.




www.saracus.com                                                                                                                    Seite 6
Big Data Appliances




                      IBM PureData System for Analytics

                      Diese Appliance ist die Datenbanktechnologie für IBM‘s analytische Appliance und kombiniert Netezza-Technologie
                      mit den bekannten S-Blades als Hardware und einem Red Hat Linux Advanced Server 5 als Betriebssystem. Als
                      Alleinstellungsmerkmal integriert sie sogenannte field programmable gate arrays (FPGAs), die zur Datenfilterung
                      unmittelbar am Diskspeicher eingesetzt werden. Damit wird ein wesentlicher Teil der Abfragelogik direkt an den
                      Daten ohne Netzwerkverkehr ermöglicht. Zusammen mit der asymetrischen massiv parallelen Verarbeitung (AMPP)
                      sind diese Appliances damit auf query-performance getrimmt.

                      Das PureData System ist, wie für Appliances üblich, in verschiedenen Ausbaustufen einsetzbar.




                  Quelle: http://public.dhe.ibm.com/common/ssi/ecm/en/imd14400usen/IMD14400USEN.PDF

                      PureData System for Analytics (und Greenplum‘s) Vorteil in der Datenbanktechnologie ist die Performance-
                      Optimierung out of the box. Trotz der Anwendung normaler Modellierungstechniken aus der transaktionalen oder
                      dimensionalen Welt werden keine Indizes, Partitionierungen, Tablespaces, Hints oder sonstigen
                      Optimierungstechniken in der Entwicklung benötigt. Dies erleichtert die Entwicklung und Wartbarkeit sowie den
                      Betrieb des „Datenbankservers“ in hohem Maße. Durch die sehr breite Portierungsfähigkeit von anderen
                      Datenbanksystemen ist darüber hinaus eine sehr einfache Anwendungsmigration möglich. Eine Migration von DB2,
                      Informix, Microsoft SQL Server, Oracle, Sybase oder Teradata erfolgt i.d.R. problemlos, abhängig von der
                      Verwendung von datenbank-spezifischen Funktionen. Eine Standardportierung von einem gängigen Oracle-
                      Datenbankserver auf ein PureData System mit annähernd gleichen Ressourcen bewirkt dabei ohne Tuning-
                      maßnahmen schnell die 20-fache Queryperformance. Für die weitere Toollandschaft gelten annähernd gleiche
                      Bedingungen. Alle gängigen BI- und ETL-Tools können an ein PureData System angebunden werden und auch die
                      Standardschnittstellen wie ODBC oder JDBC werden unterstützt. Der Philosophie der Appliance folgend ist die
                      Handhabung des Systems als black box für das gesamte System durchgängig. Ein PureData System kommt als „Box“,
                      vorkonfiguriert und einsatzbereit, und kann nach Anschluss einiger IP/Netzanschlüsse direkt in die Unternehmens-
                      infrastruktur integriert werden. Es entfallen Hard- und Softwareinstallationen sowie umfangreiche
                      Systemkonfigurationen. Diese Vorteile setzen sich im Betrieb fort. Durch die redundante Auslegung aller
                      Komponenten ist die Ausfallsicherheit gewährleistet. Die nahezu lineare Skalierungsmöglichkeit verhindert
                      zukünftige Ersatzinvestitionen, das black-box Prinzip reduziert den Ressourceneinsatz. Mittels
                      Gesamtwartungsvertrag für das System ist damit der TCO sehr gut abschätzbar.




www.saracus.com                                                                                                                Seite 7
Big Data Appliances




                      Mit PureData System for Analytics ist man für Big Data gerüstet. Netezza Analytics ermöglicht MapReduce-Routinen
                      und über Schnittstellen kann auf Hadoop zugegriffen werden. Big Data ist dabei nur ein Teil der analytischen
                      Fokussierung von PureData System for Analytics. Es finden sich diverse weitere analytische Bereiche wie SAS- oder
                      SPSS-Integration, Unterstützung diverser Programmiersprachen für build-in code oder bereits verfügbare
                      Analysemethoden wie z.B. Zeitreihenanalytik.

                      Die Herausforderung einer Migration auf ein PureData System besteht im wesentlichen aus der Anpassung
                      bestehender Spezialfunktionalitäten. Dies betrifft alle Anwendungsbereiche eines analytischen Systems, von der
                      Datenbank über das ETL-Werkzeug bis hin zum Frontend bzw. weiteren statistischen Systemen. Die grundsätzliche
                      Aussage hierbei ist, je näher die Werkzeuge am SQL-ANSI Standard eingesetzt werden, desto geringer ist die
                      Migrationskomplexität. Oftmals ist gerade die Abkehr vom Standard-SQL die einzige Möglichkeit in klassischen
                      Systemen akzeptable Performance zu erreichen und daher weit verbreitet. Diese Funktionalitäten sind aber kaum
                      bei einer Migration auf ein PureData System automatisierbar und müssen manuell angepasst werden. Der hierbei
                      entstehende Aufwand sollte wohl bedacht und durch entsprechende Systemexperten kalkuliert werden.

                      Dabei spielen interessanter Weise die eigentlichen Datenbanküberführungen die untergeordnete Rolle. Dies ist vor
                      allem dadurch begründet, dass viele Datenbankfunktionalitäten mit Netezza out of the box bereitgestellt werden,
                      wie bspw. Indizierung. Vielmehr sind es die Zugriffsmuster der ETL- und Frontend-Werkzeuge, bei denen es nicht
                      ausreicht den Connector umzustellen, wenn spezifische Zugriffsmethoden verwendet werden, sondern jeder Zugriff
                      dieser Art angepasst werden muss.




                      Quelle: http://public.dhe.ibm.com/common/ssi/ecm/en/imd14400usen/IMD14400USEN.PDF




www.saracus.com                                                                                                                 Seite 8
Big Data Appliances




                      Oracle Exadata

                      Oracles‘s Exadata Database Machine (OEDM) ist eine vollständige, vorkonfigurierte Datenbankumgebung, die
                      Oracle‘s Real Application Cluster (RAC) Datenbankserver mit Exadata Storage Servern über das interne Netzwerk
                      InfiniBand integriert. Sie ist in zwei Varianten verfügbar:

                      Exadata Database Machine X3-8
                      ist für Datenbankbereitstellungen konzipiert, die sehr große Datenmengen benötigen. Sie bietet höchste
                      Performance und Skalierbarkeit, insbesondere auch für operative Systeme mit hohen heterogen Arbeitslasten.

                      Exadata Database Machine X3-2
                      in unterschiedlichen Konfigurationen (Rack-Ausbau) verfügbar und damit für Anforderungen jeder Art einsetz- und
                      skalierbar.


                        Oracle Exadata
                                                               X3-8                                      X3-2
                        Database Machine

                        Rackausbau                            1 Rack           1 Rack             ½ Rack        ¼ Rack   1/8 Rack


                        Database Servers                        12                8                  4            2         2
                        CPU Cores DB-Operationen               160               128                64           32        16
                        (GB) Max. Speicher                    4096              2048              1024           512       512
                        Exadata Storage Server                  14                14                 7            3         3
                        CPU Cores SQL-
                                                               168               168                84           36        18
                        Operationen

                        Smart Flash Cache (TB)                 22.4             22.4               11.2          4.8       2.4
                        Anzahl Disks                           168               168                84           36        18
                        Nutzbarer Diskspeicher bei
                                                                45                45               22.5          9.5       4.5
                        „Performance“ (TB)

                        Nutzbarer Diskspeicher bei
                                                               224               224               112           48        23
                        „Kapazität“ (TB)

                        Anzahl InfiniBand Switches               3                3                  3            2         2
                       Quelle: In Anlehnung an http://www.oracle.com/technetwork/server-storage/engineered-
                       systems/exadata/dbmachine-x3-twp-1867467.pdf?ssSourceSiteId=ocomen

                      Oracles Exadata Database Machine ist im Gegensatz zu den Konkurrenten eine „shared disk“ Architektur, deren
                      Stärke in der Performance bei transaktionsorientierten Systemen liegt. Im Zuge der steigenden Operationalisierung
                      von Data Warehouse Systemen mit dem einhergehenden Mixed-Workload wirkt sich dies vorteilhaft aus. Bei rein
                      analytischen Systemen hingegen wirkt es nachteilig und muss durch Hardwareaufrüstung egalisiert werden. Für die
                      anstehenden Anforderungen im Bereich Big Data ist es noch nicht absehbar, ob sich die Architektur relevant
                      auswirkt.

                      Die Softwarearchitektur des Exadata Database Server sind von den herkömmlichen Oracle Systemen bekannt und
                      für die Nutzung der Exadata Database Machine erweitert und optimiert worden. Neue, für Exadata konzipierte
                      Komponenten, sind Oracle Database Quality of Service (QoS) Management und QoS Management Memory Guard.
                      Sie dienen zum Monitoring und zur Performance Optimierung von Anwendungen, die auf dem Datenbank-Server
                      implementiert sind. Zur Verwaltung der Datenbanken wird wie bisher der Enterprise Manager eingesetzt. Ebenso
                      findet sich das 11g Release, der Database Resource Manager (DBRM), das Oracle Database File System (DBFS) und
                      das Oracle Automatic Storage Management (ASM) zur automatischen Daten-Speicher-Partitionierung wieder.



www.saracus.com                                                                                                                  Seite 9
Big Data Appliances




                       Quelle: In Anlehnung an http://www.tektonsolutions.co.uk/2012/07/24/36/

                      Die Exadata Storage Server Software besteht aus den Komponenten:

                      Cell Services (CELLSRV)

                      Cell Services ist eine Multithread-Software, die auf den Exadata Cells läuft und mit der Datenbankinstanz auf dem
                      Datenbankserver kommuniziert. Sie stellt die erweiterten Funktionen zum Auslagern von SQL bereit, überträgt
                      Oracle-Blöcke, und implementiert die DBRM I/O Resource Management-Funktionen, um die I/O-Bandbreite an die
                      verschiedenen Datenbanken und Nutzungsgruppen, die I/O ausgeben, zu verteilen.

                      Management Server (MS)

                      Der Management Server stellt die Funktionen für die eigenständige Verwaltung und Konfiguration der Exadata-Cells
                      bereit. Er wird über das Exadata cell command line interface (CLI) oder das Exadata plug-in für den Enterprise
                      Manager angesprochen. Dadurch können alle bekannten Funktionen auch für die Verwaltung der Exadata-Server
                      genutzt werden. Dazu gehören i.w. die Überwachung des Oracle Exadata-Storage, die Sammlung von Informationen
                      zur Konfiguration und Leistung des Speichers, die Erzeugung von Alarmen und Warnungen auf Grundlage der
                      Schwellenwerte sowie die Bereitstellung von integrierten aussagekräftigen Metriken und Berichten auf Grundlage
                      von historischen Daten.

                      Restart Server (RS)

                      Der Restart Server sorgt dafür, dass die Exadata-Software und Storage-Services gestartet werden und laufen. Sie
                      wird auch zur Aktualisierung der Exadata-Software verwendet.

                      Eine entscheidene Rolle kommt dem Übertragungsprotokoll iDB zu. iDB baut auf dem Industrie-standard Reliable
                      Datagram Sockets-Protokoll (RDSv3) auf und läuft über InfiniBand. Das ZDP-Protokoll (Zero-Loss Zero-Copy
                      Datagram Protocol) ist eine Zero-Copy-Implementierung von RDS und wird verwendet, um das unnötige Kopieren
                      von Blöcken zu vermeiden. Mehrere Netzwerkschnittstellen können auf den Datenbankservern und Exadata-Zellen
                      verwendet werden. Dabei handelt es sich um ein extrem schnelles Protokoll mit niedriger Latenz, das die Anzahl der
                      erforderlichen Datenkopien minimiert, die für die I/O-Operationen erforderlich sind.




www.saracus.com                                                                                                                 Seite 10
Big Data Appliances




                      Wichtige Funktionen der Exadata Storage Server Software sind:

                      Exadata Smart Scan Processing

                      Bei traditionellem, nicht iDB-fähigem Speicher befindet sich die gesamte Datenbanklogik in der Datenbanksoftware
                      auf dem Server. Durch das Exadata Smart Scan Processing werden Datenbankfunktionalitäten in die
                      Speicherungsschicht, den Exadata Cells, integriert. Dort können Abfragen und andere Datenbankoperationen sehr
                      viel effizienter ausgeführt werden und nur die erforderliche Teilmenge der Daten wird an den Datenbankserver
                      zurückgegeben. Es werden lediglich relevante Zeilen und Spalten und keine Datenbank-Blöcke übertragen. Smart-
                      Scans sind für die Anwendung transparent, und es ist nicht erforderlich, Änderungen an der Anwendung oder dem
                      SQL-Code vorzunehmen. Sie sind in der Lage, die komplexen internen Mechanismen der Oracle-Datenbank richtig
                      zu verarbeiten. Wenn Exadata Smart Scan verwendet wird, zeigt der SQL EXPLAIN PLAN dies an. Bei Ausfall einer
                      Zelle während einer Smart-Scan-Operation können die noch nicht abgeschlossenen Teile des Smart Scan
                      transparent an eine andere Zelle weitergeleitet und dort abgeschlossen werden. Indem die SQL-Verarbeitung vom
                      Datenbankserver ausgelagert wird, werden Server-CPU-Zyklen freigegeben und ein großer Teil des
                      Bandbreitenverbrauchs wird eingespart. Datenbankfunktionalitäten, die auf die Exadata Cells verlagert werden
                      können sind unter anderem die Zeilen- und Spaltenfilterung, die Verarbeitung von Join-Anweisungen, die
                      Technologie zur Storage-Indizierung, Smart-Scan-Offload der neuen Hybrid Columnar Compressed Tables, Smart-
                      Scan-Offload von verschlüsselten Tablespaces und Spalten und Auslagerung der Data Mining-Modell-Bewertung.
                      Ebenso können inkrementelle Datenbank-Backups und die Erstellung von Tablespaces auf die Exadata Cells
                      verlagert werden, wodurch eine Verringerung des I/O Bandbreitenverbrauchs erreicht wird.

                      Exadata Hybrid Columnar Compression

                      Exadata verfügt über eine sehr effektive Funktionalität zur Kompression von Daten, die Hybrid Columnar
                      Compression (HCC). Sie ist eine neue Methode zur Organisation der Daten innerhalb eines Datenbank-Blocks.
                      Hierbei werden Zeilen- und Spaltenbasierte Methoden miteinander kombiniert.

                      Die durchschnittliche Speichereinsparung variiert zwischen dem Faktor 10 bis 15, je nach Einsatz von HCC (10% bei
                      der Datawarehouse Kompression, 15% bei der Archivierungskompression). In Verbindung mit Smart Scan, das keine
                      vorherige Dekompression der Daten verlangt, kann eine erhebliche Einsparung des I/O Bandbreitenverbrauchs
                      erreicht werden.

                      Exadata Smart Flash Cache Feature

                      Die Nutzung des Smart Flash Caches wird durch die Exadata Storage Server Software gesteuert. Als Hardware setzt
                      Oracle PCI Flash Cards(Sun Flash Accelerator F20 mit 96 GB) anstatt Flash Disks ein, sodass die gute Performance
                      des Flash Speichers nicht durch langsame Disk-Controller ausgebremst wird. Jeder Exadata Storage Server verfügt
                      über 4 PCI Flash Cards mit einer Gesamtkapazität von 1,6 TB.

                      Das Smart Flash Cache Feature ermöglicht automatisches Caching von Lese- und Schreibzugriffen in der Datenbank.
                      Hierdurch werden die Schreib- IOPS um das 20-fache und die Daten-Bandbreite um 33% erhöht. Beim Speichern
                      von Datenbank-Objekten entscheidet die Exadata Server Software, wann und wie der Exadata Smart Flash Cache
                      genutzt wird und wie dieser mit dem Flash-Cache der Datenbank kombiniert wird als Teil einer Data-Caching-
                      Strategie. Die Daten können simultan aus dem Flash-Speicher und von der Platte gelesen werden. Die Full Rack X3
                      Database Machine erreicht mit dieser Technologie bis zu 1,5 Millionen I/O operations per second (IOPS)und einen
                      Datendurchsatz von bis zu 75 GB/Sekunde.

                      Datenbank- und Storage-Server-Software bieten dem Anwender auch die Möglichkeit durch einfache Befehle für
                      Tabellen, Indizes und Segmenten sicherzustellen, dass bestimmte Daten permanent in den Flash-Speicher
                      geschrieben werden. Ebenso können ganze Tabellen in den Flash-Speicher geholt werden ohne sie in einen anderen
                      Tablespace zu verschieben. Der Smart Flash Cache wird auch genutzt, um das Schreiben von Logeinträgen zu
                      beschleunigen. Standardmäßig werden Logeinträge in den DRAM-Cache des Disk-Controllers geschrieben. Bei
                      einem hohen Aufkommen von I/O Operationen entstehen häufige Wartezeiten. Diese können durch Schreiben in




www.saracus.com                                                                                                                Seite 11
Big Data Appliances




                      den Smart Flash Cache wesentlich verringert werden, so dass die Performance verbessert wird. Allerdings gibt es
                      hier auch einige Ausnahmen. Exadata Smart Logging verfolgt daher den Ansatz, die Logeinträge sowohl in den
                      Smart Flash Cache als auch in den DRAM Cache des disk-Controllers zu schrieben. Sobald einer der beiden
                      Schreibvorgänge beendet ist, wird der andere abgebrochen. Somit werden die Vorteile beider Methoden genutzt.

                      I/O-Ressourcenmanagement mit Exadata

                      Beim traditionellen Speicher wird das Anlegen eines Shared-Storage-Grid dadurch beeinträchtigt, dass es unmöglich
                      ist, Prioritäten für die verschiedenen Jobs und Benutzer festzulegen, die I/OBandbreite aus dem Storage-Subsystem
                      verbrauchen. Dasselbe trifft zu, wenn mehrere Datenbanken sich ein Storage-Subsystem teilen. Die Funktionen von
                      DBRM und der I/O Ressourcenverwaltung können verhindern, dass eine Arbeitsklasse oder Datenbank die
                      Datenträgerressourcen und Bandbreite monopolisiert, und stellt sicher, dass benutzerdefinierte SLAs bei der
                      Verwendung von Exadata-Storage erfüllt werden. Der DBRM ermöglicht die Koordinierung und Priorisierung von
                      I/O-Bandbreite, die von den verschiedenen Datenbanken bzw. verschiedenen Benutzern oder Arbeitsklassen
                      verbraucht wird. Durch die enge Integration der Datenbank in die Storage-Umgebung erkennt Exadata die Arten von
                      Arbeiten und wie viel I/O-Bandbreite verbraucht wird. Folglich können Benutzer das Exadata-System einsetzen, um
                      die verschiedenen Arten von Arbeitslasten zu identifizieren, diesen Arbeitslasten Prioritäten zuzuweisen und
                      sicherzustellen, dass die wichtigsten Arbeitslasten vorrangig behandelt werden.

                      Fazit

                      Für eine Migration auf eine Exadata Machine können alle herkömmlichen Techniken zur Migration von Oracle
                      Datenbanken verwandt werden. Mittels Data Pump oder dem Verschieben von Tablespaces bzw. der Nutzung des
                      Oracle Recovery Manager (RMAN) sowie dem Oracle Data Guard ist eine schnelle Migration möglich. Das Gleiche
                      gilt für alle Anwendungen, die auf herkömmlichen Oracle-Systemen laufen. Sie können i.d.R. ohne Änderungen auf
                      ein Exadata-System übernommen werden. Das macht Exadata interessant für den Großteil von BI-Systemen. Aus
                      technischer Sicht ist das Exadata-System ein gekapseltes „all in one“ Datenbanksystem mit hoher Flexibilität, dass
                      für die meisten bestehenden Systeme relativ einfach zu migrieren ist. Die wesentlichen Vorteile von Exadata finden
                      sich demnach auch in dem Einsatzportfolio, das die gesamte Bandbreite von OLTP- bis OLAP-Anwendungen abdeckt
                      und über Schnittstellen zu allen gängigen Werkzeugen verfügt. Für individuelle Spezialisierungen hingegen, wie z.B.
                      eine extrem hohe Rate an konkurrierenden & komplexen Abfragen, ist jedoch die hardwareseitige Unterstützung
                      notwendig und/oder gezielte Systemeinstellungen. Mit jeder Spezialisierung aber erhöht sich die Komplexität des
                      Systems und Betriebs- und Wartbarkeit. Das kann neben den hochpreisigen Investitions- und Betriebskosten im
                      Vergleich zu den Konkurrenten schnell zu einem ungünstigen TCO führen.




www.saracus.com                                                                                                                  Seite 12
Big Data Appliances




                      Teradata Aster Big Analytics Appliance

                      Teradata bietet eine Reihe von Data Warehouse Plattformen an, um spezifische fachliche und technische
                      Anforderungen gerecht zu werden. Angefangen mit der Teradata Data Mart Appliance, für die Bedürfnisse eines
                      kleineren, kostengünstigeren (Fachbereichs-)Data Warehouses, bis hin zum hochperformanten und leicht
                      skalierbaren Teradata Active Enterprise Data Warehouse, optimiert für strategische und operative Workloads.




                      Quelle: http://www.teradata.com/brochures/Teradata-Purpose-Built-Platform-Family-eb5778/

                      Darüber hinaus hat Teradata mit der Terradata Aster Big Analytics Appliance eine weitere Plattform eingeführt, um
                      gezielt den Bedürfnissen der Big-Data-Analytics nachzukommen. Die Big Analytics Appliance ist eine vollständig
                      vorkonfigurierte, ready-to-run Platform. Durch eine Kombination von Big Data Technologie und ANSI-Standard SQL
                      Tools für BI und ETL, ist diese Appliance optimiert für das Speichern und Analysieren von Big Data.

                      Die Appliance basiert auf einer hybriden Architektur und beinhalten folgenden Komponenten:

                      Aster Database liefert eine massively parallel (MPP) analytische Plattform und integriert die SQL-MapReduce-
                      Technologie, Teradata Aster SQL-H und mit Aster MapReduce Analytics Portfolio eine Bibliothek mit über 50
                      analytischen Funktionen.

                      SQL-MapReduce ist ein patentiertes Framework, welches die analytische Power von MapReduce mit vertrauten SQL
                      kombiniert. Aster SQL-H ermöglicht Unternehmen, durch Nutzung von Standard- SQL- und BI-Werkzeuge, wertvolle
                      Datenschätze direkt aus Hadoop zu heben. Aster SQL-H nutzt dazu das Open-Source Projekt Apache HCatalog, das
                      Metadaten für einen vereinfachten Zugang bereitstellt.

                      Apache Hadoop bietet ein hochverfügbares, leistungsfähiges Dateisystem zur Speicherung von großen
                      Datenmengen.

                      Darüber hinaus verfügt die Appliance mit einen InfiniBand Switch mit 40 Gigabyte pro Sekunde, über eine
                      hochperformante Verbindung zwischen den Aster und Hadoop Knoten.




                                               Quelle: http://www.asterdata.com/resources/assets/sb-big-analytics-appliance.pdf

www.saracus.com                                                                                                                   Seite 13
Big Data Appliances




                      Die Teradata Aster Big Analytics Appliance wird als vollständig integriertes System aus Hard- und Software
                      bereitgestellt. Als „Plug and Play“-Lösung kann sie innerhalb weniger Stunden den Betrieb aufnehmen. Mit einem
                      maßgeschneiderten Mix aus Aster-Database- und Hadoop-Rechnerknoten lässt sie sich individuell an den
                      analytischen Workload-Bedarf eines Unternehmens anpassen.




                        Quelle: http://www.asterdata.com/resources/assets/sb-big-analytics-appliance.pdf /

                      Fazit

                      Terradata Aster Big Analytics bietet durch die Integration von relationalen Datenbanksystemen (basierend auf SQL)
                      und Apache Hadoop (basierend auf dem SQL-MapReduce Software Framework), eine vereinheitlichte
                      Datenarchitektur. Mit ihr verfügen Unternehmen über flexible Optionen zur Konfiguration, um die Aster Database
                      und das Open Source-Framework Hadoop nahtlos zu integrieren, und um alle Arten von Daten – strukturiert oder
                      unstrukturiert – zusammen mit einem Werkzeug zu analysieren. Über SQL-H können auch Business Analysten, die
                      nicht Java oder eine andere Programmiersprache beherrschen (für Hadoop/MapReduce nötig) analytische Queries
                      formulieren und so spielerisch mit den Daten jonglieren.

                      Die Teradata Aster Big Analytics Appliance wurde für extreme Anforderungen an Datenanalysen entwickelt, die
                      besonders hohe Rechnerleistung, viel Arbeitsspeicher und Möglichkeiten für Data Movement verlangen. Sie
                      ermöglicht einen bis zu 19-fach höheren Datendurchsatz und bis zu 35-mal schnellere Analysen als marktübliche
                      Analyselösungen.

                      Eine Vielzahl von Adaptern ermöglicht eine out-of-the-box Integration in die bestehende IT-Landschaft . So
                      ermöglichen z.B. zertifizierte ODBC und JDBC Schnittstellen die Anbindung aller gängigen BI und ETL Werzeuge. Die
                      Plattform nutzt die patentierte SQL-MapReduce-Technologie von Aster, um Datenverarbeitung und Anwendungen
                      zu parallelisieren. Somit ermöglichen einfach anwendbare SQL- und BI-Werkzeuge vielfältige analytische Einsichten
                      und existierende Investitionen in SQL basierende BI und ETL Tools können weiterhin genutzt werden.




www.saracus.com                                                                                                                 Seite 14
Big Data Appliances




                      Vergleichsübersicht

                      Die hier vorgestellten Appliances haben ihre Berechtigung in speziellen Einsatzszenarien, die bei der jeweiligen
                      Beschreibung herausgestellt wurde. Die folgende Übersicht fasst die Kernpunkte zusammen und soll als erstes
                      Raster für oder gegen den Einsatz einer Appliance dienen.

                  Anbieter               Teradata Aster Big      IBM PureData              Oracle Exadata           EMC Greenplum
                                         Analytics               System for Analytics
                  Kategorie                                      (Netezza)

                  Hardware               Teradata (x86-          IBM (x86-Architektur)     Sun                      Beliebige x86-
                                         Architektur Dual                                                           Hardware möglich;
                                         Intel Six-Core Xeon                                                        mit HP-Hardware im
                                         Processors)                                                                vorkonfiguriertem
                                                                                                                    Bundle

                  Betriebssystem         Novell Suse Linux       Red Hat Linux             Oracle Linux             Suse Linux, Red-Hat
                                                                                           Sun Solaris              Linux, CentOS,
                                                                                                                    Solaris, Oracle
                                                                                                                    Unbreakable Linux

                  Datenbank              Aster Database          Propietär (auf            Oracle 11g R2, RAC       Proprietär (auf
                                                                 Postgres basierend)                                Postgres basierend)

                  DB-Technologie         Hybrid (Zeilen- und     Zeilenorientiert          Zeilenorientiert         Polymorph Data
                                         Spaltenorientiert)                                                         Storage (Wahl
                                                                                                                    zwischen Zeilen- und
                                                                                                                    Spaltenorientiert)

                  DB-Kompression         Dynamische              Kompressions-Engine       Hybrid Columnar          In-database
                                         Datenkompression        (Kompressionsrate         Compression (HCC)        Kompression
                                         (Kompressionsrate       4x – 8x)                  (Kompressionsrate        (Kompressionsrate
                                         3x – 12x)                                         10x-15x)                 3x-10x)

                  Advanced               SQL-MapReduce,          SAS-Funktionen in der     Oracle Advanced          SAS-Funktionen in
                  Analytics              SQL-H, MapReduce        DB, In-database-          Analytics (Oracle R      der DB, Native Map
                                         Analytics               analytics, R, Matrix,     and Data Minig)          Reduce Processing,
                                         Funktionen, Hadoop      Hadoop, Spatial           zusätzlich zu            Programmable
                                                                                           beschaffen               Analytics

                  Leistungsprinzip       MPP                     MPP Hardware-             MPP Datenbank mit        MPP Software
                                         Spezialisierte          erweiterung (S-           Storage Server           Datenbank
                                         Datenbank für           Blades) spezialisierte
                                         DWH/BI                  Datenbank für
                                                                 DWH/BI

                  Besonderheiten         - patentierte SQL-      S-Blades mit FPGA         Smart Flash Cache,       - Polymorphic Data
                                         MapReduce-              Database Accelerator      Smart Scan               Storage-MultiStorage
                                         Technologie                                                                / SSD Support
                                         - Out of the box                                                           - Out of the box
                                         Support für Big Data                                                       Support für Big Data
                                         Analytics und                                                              Analytics und
                                         Hadoop                                                                     Hadoop
                                                                                                                    - MPP Scatter /
                                                                                                                    Gather
                                                                                                                    - Streaming

                  Einsatz                Analytisch              Analytisch                Analytisch /             Analytisch
                                                                                           Operational

                  Konnektivität          gut                     gut                       gut                      gut

                  TCO                    mittel                  mittel                    hoch                     niedrig




www.saracus.com                                                                                                                  Seite 15
Big Data und Business Intelligence




                              Fazit

                              Appliances bieten einen interessanten Ansatz für flexible und gut kalkulierbare Systeme. Gerade im analytischen BI-
                              Markt können diese massiv parallelen Systeme mit vielen Vorteilen gegenüber klassischen Datenbanksystemen
                              punkten. Dazu gehören u.a.
                              •   Kalkulierbare Installations-, Betriebs- und Wartungskosten (TCO)
                              •   Hohe Flexibilität und Skalierbarkeit (Investitionsschutz) sowie die Möglichkeit, mit den Herausforderungen zu
                                  wachsen (Planungssicherheit)
                              •   Abgestimmtes System, kein Customizing, Standardisierung unter dem Prädikat „Einfachheit“ (Wartbarkeit und
                                  Anwendungsfreundlichkeit)
                              •   Reduzierung des Aufwandes für Entwicklung und Wartung (Ressourcen-Minimierung)

                              Die Vorteile machen direkt das wahrscheinlichste Einsatzszenario einer Appliance im analytischen Umfeld deutlich:
                              der Einsatz als Datenbankserver. Die Appliances haben sich darauf fokussiert, wenngleich Oracle auch den
                              operativen Bereich mit abdeckt.

                              Big Data wirkt dabei als Katalysator auf dem Appliance-Markt. Es ist eine Funktionalität unter vielen, die den Einsatz
                              einer Appliance unterstützen kann. Der zentrale Kernpunkt ist aktuell jedoch die Analytik im klassischen Sinn. Die
                              Symbiose zwischen einer Appliance und Big Data bezieht sich daher wortwörtlich auf „Big“, d.h. die schiere
                              Datenmenge. Die Funktionalität, die unterschiedlichen und unstrukturierten Daten zu verarbeiten sowie die
                              Integration darauf spezialisierter Komponenten ist kein Alleinstellungsmerkmal von Appliances.

                              Die aktuelle Entwicklung könnte man mit den BI-Ansätzen der Vergangenheit vergleichen. Waren früher die „best of
                              bread-Ansätze“ (z.B. DB2,Informatica und MicroStrategy) und die „Suit-Ansätze“ (z.B. SAP, Oracle) im BI-Umfeld
                              stark diskutiert, so stellen sich aktuell unter dem Thema Big Data die Appliances gegen „open source - Systeme“.
                              Diese versuchen mit kostengünstiger Hardware und open source software die Leistungsfähigkeit der Appliances
                              unter Budgetminimierung zu erreichen. Dazu verwenden sie u.a. auch neue Verarbeitungsmethodiken, wie z.B.
                              NoSQl-Datenbanken. Das diese Entwicklungen beachtenswert sind, zeigt allein schon die Tatsache, dass die
                              Appliances entsprechende Schnittstellen anbieten oder Algorithmen übernehmen.

                              Die hier betrachteten Appliances können als „Hard- und Software-Appliance“ betrachtet werden. Daneben
                              existieren auch noch reine Software-Appliances, bei denen die Hardware variabel gewählt werden kann bzw.
                              Hardware-Bundle über Partner angeboten werden. Kandidaten hierzu sind u.a. die Microsoft Parallel Appliance,
                              Kognitio oder Exasol. Diese Software-Appliances sind jedoch eher als ergänzende Systemkomponente anzusehen.
                              So findet sich häufig der Einsatz einer In-memory-Datenbank (z.B. Kognitio) als zusätzlicher „Performance-
                              accelerator“ innerhalb eines bestehende Systems.




Technologie                   Warum saracus consulting?
• Programmierung /            Die folgenden Faktoren sprechen für die Wahl der saracus consulting als Beratungs- und
  Customizing Hadoop-         Integrationspartner:
  basierter Systeme           • Seit 1991 zu 100% fokussiert auf DWH, BI, CPM und aCRM
• Integration BI-Tools und
                              • Spezifische Vorgehensmethodik
• Customizing von ETL-
  Tools in Big Data           • Große Erfahrung mit wichtigen Technologien
  Umgebungen                  • Kombination von Business- und IT-Know-how
• Strategie- & Architektur-   • Umfangreiche Anzahl an ausgebildeten und erfahrenen Beratern,
  beratung zu Big Data BI       um auch große Projekte zeitgerecht fertig zu stellen
• Anwendung v. Appliances     • Full Service von der Analyse, Konzeption über Systemintegration bis zum Betrieb
• Werkzeugevaluation

    www.saracus.com                                                                                                                         Seite 16

Weitere ähnliche Inhalte

Ähnlich wie Big Data Appliances

Big Data Konnektivität
Big Data KonnektivitätBig Data Konnektivität
Big Data Konnektivität
Trivadis
 
OpenDMA - Daten Management Solution
OpenDMA  - Daten Management SolutionOpenDMA  - Daten Management Solution
OpenDMA - Daten Management Solution
Torsten Glunde
 
Geänderte Anforderungen an eine Data-Warehouse-Landschaft
Geänderte Anforderungen an eine Data-Warehouse-LandschaftGeänderte Anforderungen an eine Data-Warehouse-Landschaft
Geänderte Anforderungen an eine Data-Warehouse-Landschaft
ISR Information Products AG
 
Whitepaper sones GraphDB (ger)
Whitepaper sones GraphDB (ger)Whitepaper sones GraphDB (ger)
Whitepaper sones GraphDB (ger)sones GmbH
 
Cloud Computing für die Verarbeitung von Metadaten
Cloud Computing für die Verarbeitung von MetadatenCloud Computing für die Verarbeitung von Metadaten
Cloud Computing für die Verarbeitung von Metadaten
Magnus Pfeffer
 
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Überblick zu Oracle Database 12c Release 2
Überblick zu Oracle Database 12c Release 2Überblick zu Oracle Database 12c Release 2
Überblick zu Oracle Database 12c Release 2
Ulrike Schwinn
 
Oracle Database 12c Release 2
Oracle Database 12c Release 2 Oracle Database 12c Release 2
Oracle Database 12c Release 2
oraclebudb
 
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Überblick Oracle Datenbank 12c
Überblick Oracle Datenbank 12cÜberblick Oracle Datenbank 12c
Überblick Oracle Datenbank 12c
Ileana Somesan
 
sones auf windows azure whitepaper (german)
sones auf windows azure whitepaper (german)sones auf windows azure whitepaper (german)
sones auf windows azure whitepaper (german)sones GmbH
 
DXC Technology - THRIVE Blog: Pay-Per-Use
DXC Technology - THRIVE Blog: Pay-Per-UseDXC Technology - THRIVE Blog: Pay-Per-Use
DXC Technology - THRIVE Blog: Pay-Per-Use
Daniel Eiduzzis
 
RDBMS oder NoSQL – warum nicht beides?
RDBMS oder NoSQL – warum nicht beides?RDBMS oder NoSQL – warum nicht beides?
RDBMS oder NoSQL – warum nicht beides?
Capgemini
 
ExsoFlow Workflow & IntegrationServer technische Information
ExsoFlow Workflow & IntegrationServer technische InformationExsoFlow Workflow & IntegrationServer technische Information
ExsoFlow Workflow & IntegrationServer technische Information
EXSO. business solutions GmbH
 
Modernes Rechenzentrum
Modernes Rechenzentrum Modernes Rechenzentrum
Modernes Rechenzentrum
Microsoft Österreich
 
Datenbanksystem
DatenbanksystemDatenbanksystem
Datenbanksystem
Abdelhamid81
 
Datenbanksystem
DatenbanksystemDatenbanksystem
Datenbanksystem
Abdelhamid81
 
Rbu amanox big_data_intro_infrastruktur
Rbu amanox big_data_intro_infrastrukturRbu amanox big_data_intro_infrastruktur
Rbu amanox big_data_intro_infrastrukturRene Burgener
 
DWH-Modellierung mit Data Vault
DWH-Modellierung mit Data VaultDWH-Modellierung mit Data Vault
DWH-Modellierung mit Data Vault
Trivadis
 
DXC Technology - THRIVE Blog: Das nächste BI-Level
DXC Technology - THRIVE Blog: Das nächste BI-LevelDXC Technology - THRIVE Blog: Das nächste BI-Level
DXC Technology - THRIVE Blog: Das nächste BI-Level
Daniel Eiduzzis
 

Ähnlich wie Big Data Appliances (20)

Big Data Konnektivität
Big Data KonnektivitätBig Data Konnektivität
Big Data Konnektivität
 
OpenDMA - Daten Management Solution
OpenDMA  - Daten Management SolutionOpenDMA  - Daten Management Solution
OpenDMA - Daten Management Solution
 
Geänderte Anforderungen an eine Data-Warehouse-Landschaft
Geänderte Anforderungen an eine Data-Warehouse-LandschaftGeänderte Anforderungen an eine Data-Warehouse-Landschaft
Geänderte Anforderungen an eine Data-Warehouse-Landschaft
 
Whitepaper sones GraphDB (ger)
Whitepaper sones GraphDB (ger)Whitepaper sones GraphDB (ger)
Whitepaper sones GraphDB (ger)
 
Cloud Computing für die Verarbeitung von Metadaten
Cloud Computing für die Verarbeitung von MetadatenCloud Computing für die Verarbeitung von Metadaten
Cloud Computing für die Verarbeitung von Metadaten
 
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
Darf es ein bisschen mehr sein - Konzepte und Strategien zur Bewältigung groß...
 
Überblick zu Oracle Database 12c Release 2
Überblick zu Oracle Database 12c Release 2Überblick zu Oracle Database 12c Release 2
Überblick zu Oracle Database 12c Release 2
 
Oracle Database 12c Release 2
Oracle Database 12c Release 2 Oracle Database 12c Release 2
Oracle Database 12c Release 2
 
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
Darf es ein bisschen mehr sein - Konzepte Strategien zur Bewältigung großer u...
 
Überblick Oracle Datenbank 12c
Überblick Oracle Datenbank 12cÜberblick Oracle Datenbank 12c
Überblick Oracle Datenbank 12c
 
sones auf windows azure whitepaper (german)
sones auf windows azure whitepaper (german)sones auf windows azure whitepaper (german)
sones auf windows azure whitepaper (german)
 
DXC Technology - THRIVE Blog: Pay-Per-Use
DXC Technology - THRIVE Blog: Pay-Per-UseDXC Technology - THRIVE Blog: Pay-Per-Use
DXC Technology - THRIVE Blog: Pay-Per-Use
 
RDBMS oder NoSQL – warum nicht beides?
RDBMS oder NoSQL – warum nicht beides?RDBMS oder NoSQL – warum nicht beides?
RDBMS oder NoSQL – warum nicht beides?
 
ExsoFlow Workflow & IntegrationServer technische Information
ExsoFlow Workflow & IntegrationServer technische InformationExsoFlow Workflow & IntegrationServer technische Information
ExsoFlow Workflow & IntegrationServer technische Information
 
Modernes Rechenzentrum
Modernes Rechenzentrum Modernes Rechenzentrum
Modernes Rechenzentrum
 
Datenbanksystem
DatenbanksystemDatenbanksystem
Datenbanksystem
 
Datenbanksystem
DatenbanksystemDatenbanksystem
Datenbanksystem
 
Rbu amanox big_data_intro_infrastruktur
Rbu amanox big_data_intro_infrastrukturRbu amanox big_data_intro_infrastruktur
Rbu amanox big_data_intro_infrastruktur
 
DWH-Modellierung mit Data Vault
DWH-Modellierung mit Data VaultDWH-Modellierung mit Data Vault
DWH-Modellierung mit Data Vault
 
DXC Technology - THRIVE Blog: Das nächste BI-Level
DXC Technology - THRIVE Blog: Das nächste BI-LevelDXC Technology - THRIVE Blog: Das nächste BI-Level
DXC Technology - THRIVE Blog: Das nächste BI-Level
 

Big Data Appliances

  • 1. White Paper saracus Big Data Stärken und Schwächen im praktischen Einsatz von Big Data Appliances
  • 2. Big Data Appliances Appliances spielen im IT-Markt eine zentrale Rolle. Eine Appliance ist ein Komplettsystem, welches aufeinander abgestimmte Komponenten für einen dezidierten Einsatzzweck vereint. Im Bereich der Big Data Appliances umfassen die Kernkomponenten sämtliche Hard- und Software von den Netzwerkadaptern über Rechenknoten bis zur Datenbank. Diese sind allerdings nicht beliebig konfigurierbar, sondern nur in ausgewählten Konstellationen einsetzbar. Die wesentlichen Vorteile einer Appliance werden in der schnellen Implementierung, dem effizientem Einsatz und den verringerten Betriebs- und Wartungskosten gegenüber klassischen Systemen gesehen. Komplettsysteme stellen damit eine von drei Möglichkeiten der strukturellen Architektur eines BI Systems dar. Neben dem klassischen best of bread Architektur-Ansatz, der auf einem unternehmensoptimierten Mix an Komponenten basiert, existiert noch der open-source Ansatz mit der Zielrichtung kostengünstiger Hard- und Software. Appliances befinden sich daher in einer starken Konkurrenzsituation und benötigen überzeugende Argumente zur Positionierung. Hierzu ist das Thema Big Data hervorragend geeignet, da diese Art der Informationsverarbeitung neue Herausforderungen mit sich bringt und einen Architekturwechsel unterstützen kann. Denn zu den Einführungs- und Betriebsaufwänden einer Appliance ist in den meisten Fällen auch ein erheblicher Migrationsaufwand zur Integration in bzw. von bestehenden Architekturen notwendig. Dieser Artikel beschreibt anhand von drei Beispielen die Einsatzszenarien bzw. Stärken und Schwächen von Big Data Appliances im praktischen Einsatz. Big Data Appliance Appliances waren schon vor Big Data ein Thema, aber mit Big Data erleben sie eine Art Renaissance. Alle Appliances stellen deutlich ihre Möglichkeiten in diesem Bereich heraus. Die Angst vor überdimensionierten und nicht mehr betreib- bzw. wartbaren Systemen im Zeitalter von Big Data erweckt wieder den Bedarf an „Systemen von der Stange“. Hier setzen Appliances erfolgreich an. Die Kapselung von Hard- und Software zu einem vorkonfektionierten Funktionsbaustein scheint genau diesem Wunsch nachzukommen. Vier führende Anbieter in diesem Segment werden hier beschrieben und auf den Prüfstand gestellt, ob sie die Erwartungen erfüllen können. Neben der technischen Beschreibung sind dabei insbesondere die Einsatzszenarien, Migrations- und Integrationsmöglichkeiten von Interesse. Und diese Themen werden nicht nur von Big Data getrieben, sondern von der gesamten Infrastrukturlandschaft. Die folgende Tabelle zeigt führende Anbieter inkl. zentraler Eckdaten der Lösung. saracus consulting GmbH Hafenweg 46 D-48155 Münster Fon. +49 251 98721 0 Fax. +49 251 98721 26 saracus consulting AG Täfernstrasse 4 CH-5405 Baden-Dättwil Fon. +41 56 483 02 20 Fax. +41 56 483 02 21 saracus consulting d.o.o. ul. Bulevar Svetog Cara Konstantina, br. 82-86 SRB-18000 Nis www.saracus.com Seite 2
  • 3. Big Data Appliances Greenplum Die Greenplum Data Computing Appliance (DCA) ist eine modular aufgebaute, hoch skalierbare Plattform, die eine relationale Datenbank mit Massive-Parallel-Processing-Architektur (MPP) und Apache-Hadoop vereint und so die Analyse, Auswertung und Verarbeitung von strukturierten (relationalen), semi-strukturierten und unstrukturierten (Big Data) Daten in einer einheitlichen Umgebung ermöglicht. Die DCA kann aus den folgenden Komponenten zusammengesetzt sein: • Greenplum Database Standard Module Ist ein spezielles, hochskalierbares Data-Warehousing-Appliance-Modul, das mit seiner Architektur Datenbank-, Computing-, Storage- und Netzwerk-Funktionalitäten vereint. • Greenplum Database High Capacity Module Stellt eine Erweiterung des Greenplum Database Moduls dar. Es ermöglicht das Hosting von mehreren Petabyte Daten ohne den Stromverbrauch, die Kosten oder den Platzbedarfs massiv in die Höhe zu treiben. • Greenplum HD Dieses Modul basiert auf Hadoop-Basis und verbindet die Hadoop-Technologie mit der Greenplum-DB und ermöglicht eine gemeinsame Verarbeitung von strukturierten und unstrukturierten Daten. • Greenplum Data Integration Accelerator Das Data Integration Accelerator (DIA) Modul dient als Hostsystem für Business-Intelligence- oder ETL- Applikationen, damit diese denselben hochleistungsfähigen Interconnect wie die anderen integrierten Module nutzen können. Greenplum Database und Greenplum HD sind sich gegenseitig ergänzende Technologien, um eine leistungsfähige Lösung für die Analyse von strukturierten, semi-strukturierten und unstrukturierten Daten zur Verfügung zu stellen. Wenn diese beiden Technologien wirksam zusammen eingesetzt werden, können komplexe, hoch performante, interaktive Analysen durchgeführt werden, insbesondere durch die Verknüpfung von strukturierten und semi- strukturierten Daten, die sowohl in der Greenplum Database als auch im Hadoop-Distributed-File-System (HDFS) gespeichert sind. Die DCA ist in verschiedenen Ausführungen erhältlich. Ausgehend von einem Single Primary Rack, das lediglich das Greenplum Database Standard bzw. High Capacity Module enthält, kann die Appliance in Quarter-Rack-Schritten um eine beliebige Anzahl von jedem der vier zur Verfügung stehenden Module erweitert werden. Quelle: http://www.greenplum.com/technology/architecture www.saracus.com Seite 3
  • 4. Big Data Appliances Greenplum-Database Das Greenplum-Database Modul basiert auf der Open-Source Technologie PostgreSQL und nutzt Massiv Parallel Processing (MPP), dass auch als Shared Nothing Architektur bezeichnet wird. Die Greenplum-DB nutzt diese Technologie, um z. B. das Laden von sehr großen Datenmengen in ein DWH zu verteilen und hierfür alle zur Verfügung stehenden Ressourcen parallel für die Ausführung eines Prozesses zu nutzen. Die Greenplum-DB besteht im Prinzip aus mehreren PostgreSQL-Datenbank-Instanzen, die gemeinsam als ein geschlossenes DB-Management- System fungieren. Sie wurde aus der Open-Source-Technologie PostgreSQL 8.2.15 entwickelt und ist für die End- User besonders in Bezug auf SQL-Support, Features, Konfiguration und End-User-Funktionalität sehr ähnlich zu PostgreSQL. Unter der Oberfläche wurde PostgreSQL jedoch für den Einsatz in der parallelen Struktur der Greenplum-DB angepasst und erweitert, um in der Lage zu sein, eine Query aufzuteilen und die entstandenen Teil-Queries auf die verschiedenen PostgreSQL-Datenbank-Instanzen zu verteilen. Die Kommunikation zwischen den einzelnen DB- Instanzen erfolgt über den Greenplum-Interconnect. Erst mit Hilfe dieses Networking Layers kann das System aus verschiedenen einzelnen PostgreSQL-DB-Instanzen als eine logische Datenbank funktionieren. Zusätzlich enthält die Greenplum-DB Funktionen, um PostgreSQL für Business-Intelligence Belastungen zu optimieren. Zum Beispiel External Tables für das parallele Laden von Daten, Ressource Management, Query Optimization und Storage- Management, Partitioning etc.. Der Master-Server fungiert als Entry-Point zu einem Greenplum DB-System. Er verwaltet die Client-Connections und koordiniert die Segment- Server. Der Master-Server enthält keine User- Daten, aber einen System-Katalog. Aus diesem Grund hat ein Master-Server in der Regel eine sehr geringe Festplatten-Auslastung. In produktiven Systemen wird der freie Speicherplatz daher oft für temporäre Informationen wie „Load-“ oder „Backup-Files“ genutzt. Er benötigt eine schnelle CPU für Loading-, Connection- und Query-Prozesse. Quelle: http://www.greenplum.com Die Segment-Server werden in einem Greenplum-System zur Speicherung der Daten und zum Ausführen von (Teil)- Abfragen verwendet. Sie können niemals direkt durch den User angesprochen werden, sondern die Kommunikation erfolgt immer über den Master-Server. Segment-Server bestehen aus einzelnen Segmenten, auf welchen alle User-definierten Tabellen mit ihrer gesamten Index-Struktur verteilt werden. Jedes Segment enthält somit eine eindeutige Teilmenge der Gesamt-Datenmenge. Die Anzahl von Segmenten auf einem Segment-Server ist durch die Anzahl CPU’s oder die Anzahl Cores festgelegt. Wenn ein Segment-Server z. B. zwei Dual-Core-Prozessoren besitzt, können auf dem Server zwei oder vier Segmente laufen. Bei drei Dual-Core-Prozessoren können drei, sechs oder zwölf Segmente laufen usw... Die optimale Anzahl an Segmenten für ein bestimmtes Hardware-System muss mit Hilfe von Performance-Tests evaluiert werden. Der Interconnect repräsentiert die Netzwerk-Schicht einer Greenplum-Datenbank. Wenn ein User eine Verbindung zur DB herstellt und eine Query absetzt, werden – wie bereits im vorherigen Absatz beschrieben - auf Anweisung des Master-Servers auf jedem Segment-Server in jedem Segment Prozesse erstellt, die die für das Resultat der Query notwendige Arbeit ausführen. Der Interconnenct stellt bei diesem Prozess sowohl die Kommunikation zwischen den einzelnen Segment-Servern bzw. Segmenten her als auch die Kommunikation mit dem Master-Server. Er benutzt hierfür einen Standard Gigabit Ethernet Switch. www.saracus.com Seite 4
  • 5. Big Data Appliances Greenplum HD Das Greenplum HD Modul ist eine vollständig unterstützte und zertifizierte Version des Apache Hadoop Stacks. Hadoop ist ein in Java geschriebenes Open Source Framework für skalierbare, verteilt arbeitende Software. Es basiert auf dem MapReduce-Algorithmus und bietet mit Hilfe seiner automatischen Parallelisierung die Möglichkeit, intensive Rechenprozesse mit großen Datenmengen auf Computerclustern durchzuführen. Das Greenplum HD Modul beinhaltet die Komponenten Hadoop Distributed File System, MapReduce, Hive, Pig, HBase, Zookeeper und Mahout. Das Hadoop Distributed File System (HDFS) basiert auf Java und ist ein hochverfügbares, leistungsfähiges Dateisystem zur Speicherung von großen Datenmengen. Es hat sich als solide Grundlage für die Verwendung von Hadoop bewährt, denn es ist in der Lage die verwendeten Dateien in Datenblöcke mit fixer Länge zu zerlegen und diese redundant auf die Dateisysteme aller als Knoten verwendeten Rechner in einem Netzwerk zu verteilen. MapReduce wurde auf Grundlage der Funktionen map und reduce entwickelt und ist ein Hadoop-Framework für parallele Berechnungen über große Datenmengen auf Computerclustern. Mit diesem Framework ist es möglich in einfacher Art und Weise Applikationen zu entwickeln, die große Mengen an strukturierten und unstrukturierten Daten abarbeiten können. Hive erweitert Hadoop um Data-Warehouse-Funktionalitäten und ermöglicht durch den Einsatz der Anfragesprache HQL und Indizes das Zusammenfassen von Daten, Ad-Hoc-Queries und die Analyse von großen Datenmengen, die in Hadoop-kompatiblen File-Systeme gespeichert sind. Es bietet als SQL-ähnliche Schnittstelle eine zeilenbasierte Speichermöglichkeit, die in Kombination mit der Komprimierung ein besseres Komprimierungsverhältnis beim Speichern von Daten gewährleistet. Pig ist eine verfahrensorientierte Programmiersprache zur Verarbeitung großer, teilweise strukturierter Datenmengen auf Basis der Hadoop MapReduce-Plattform. Als Alternative zu Java soll es das Entwickeln von MapReduce-Jobs erleichtern. HBase ist eine verteilte, versionierte, spaltenorientierte Datenbank, die User-Applikationen zufälligen Real-Time Read/Write- Access auf Big Data zur Verfügung stellt. Zookeeper ist ein hoch verfügbares System, um verteilte Prozesse zu koordinieren. Mahout ist eine freie, in Java geschriebene Programmbibliothek für verteiltes, maschinelles Lernen und Data Mining. Die Software setzt auf Hadoop auf. Greenplum Data Integration Accelerator Das Greenplum Data Integration Accelerator (DIA) Modul wurde entwickelt, um „Fast Data Loading“ in die Greenplum Data Computing Appliance zu ermöglichen. Es dient dazu, das Greenplum-Tool „gpfdist“ mit den anderen Komponenten in einer DCA zu vereinigen und setzt das interne 10GB/Sek High-Speed Netzwerk ein, um Daten schnell in die DCA zu laden. Das DIA Modul, das in einer DCA als Server arbeitet, ist speziell angefertigt, um Batch-Loading und Micro-Batch-Loading durchzuführen und unterstützt bereits einige Data-Integration-Tools wie Informatica, Talend und Pentaho. Diese müssen dafür allerdings auf dem DIA-Server installiert werden. gpfdist ist Greenplums Parallel-File-Server-Distribution-Utility. Es kann als ein Netzwerkprotokoll ähnlich dem HTTP-Protokoll verstanden werden und wird in einer Greenplum DCA für das parallele Verarbeiten von External-Table-Files und Writable-External-Tables verwendet Fazit Die Besonderheit der Greenplum-Architektur ist die modulare Zusammensetzung. Je nach Einsatzszenario können die Module eingesetzt werden. Spielen beispielsweise unstrukturierten Daten keine Rolle, wird auf das Greenplum- HD-Modul verzichtet. Weiterhin ist die Hardware-Unabhängigkeit hervorzuheben. Neben der konfektionierten DCA ist es möglich, eigene Hardware zu nutzen, die Module dort zu installieren und als Appliance „Marke Eigenbau“ zu verwenden. Aus den bisherigen Erfahrungen ist eine Integration der Greenplum DCA in bestehende BI-Systeme sinnvoller als eine Ablösung. Idealerweise benutzt man Greenplum für den Einsatz im analytischen Bereich. Hier können die Stärken, die ja hauptsächlich in der MPP-Architektur liegen am besten eingesetzt werden. Die Performance der Analytik wird in solchen Szenarien enorm verbessert und auch das Füllen der Faktentabellen wird enorm beschleunigt. Im Bereich Core-DWH ist der Einsatz einer Greenplum nicht unbedingt immer gewinnbringend. Solange der große Teil lediglich INSERTS in die DB vornimmt, können die Vorteile der parallelen Verarbeitung genutzt werden. Da in diesem Bereich häufig mit UPDATE und teilweise auch mit DELETE gearbeitet wird, gibt es nicht immer Performance-Verbesserungen. www.saracus.com Seite 5
  • 6. Big Data Appliances Es gibt viele Gründe aus unterschiedlichen Bereichen, die für einen Einsatz von Greenplum sprechen. Performance im Bereich Reporting und ETL (Data Mart), Investitions- und Betriebskosteneinsparungen, enorme Skalierbarkeit und der modulare Aufbau sind dabei Kriterien, die sich in der Praxis bestätigt haben. Die konkrete Ausprägung ist jeweils von den gegebenen Rahmenbedingungen abhängig. Bei einer Gegenüberstellung von Kosten und Nutzen muss man zu dem Schluss kommen, dass es sich insbesondere für den analytischen Bereich (Bewirtschaftung/Reporting) inklusive der Einbindung von Big Data Daten anbietet, Greenplum einzusetzen. Dies betrifft sowohl neue Entwicklungen wie auch die Ablösung oder Migration von BI-Strukturen. Weniger geeignet ist der Einsatz in operativen und transaktionsorientierten Systemen bzw. Systemen mit einer hohen Rate an Update- /Delete-Jobs. Für die Anbindung Greenplum‘s an weitere Werkzeugkomponenten im BI-Umfeld stehen viele Möglichkeiten zur Verfügung. Im ETL- und Frontend-Bereich finden sich mit Informatica, Talend, Pentaho Data Integration (Kettle), IBM DataStage, MicroStrategy, IBM Cognos, SAS, Information Builders, Oracle OBIEE, SAP Business Objects, Alpine Miner, Attivio Active Intelligence, Qlikview, Recombinant i2b2, Revolution Analytics und Squid Solutions die gängigen Werkzeuge wieder. Zu beachten ist, dass besonders im Bereich ETL unter Umständen aufwändige Änderungen an den Mappings vorgenommen werden müssen, da die DB ja auf Postgres basiert. Bei den BI-Tools sollte das ähnlich sein, solange sie nicht wie z.B. MicroStrategy über einen eigen DB-spezifischen SQL-Generator verfügen. Weiterhin sollte geprüft werden, wie die Connection hergestellt wird. Sind es proprietäre Treiber kann in der Regel die volle Geschwindigkeit von Greenplum genutzt werden, bei „normalen“ ODBC-Treibern können ggf. Leistungseinbußen auftreten. Die Umstellung einer klassischen Oracle-basierenden Analyse-DB mit MicroStrategy als Analysetool verursacht bspw. keine großen Probleme bei einer Umstellung auf Greenplum, da nahezu alle Datentypen migriert werden können und im Frontend-Bereich neben der DB-Typumstellung ggf. einige Performance-Einstellungen getestet werden müssen. Hingegen kann die Umstellung im ETL-Bereich bspw. mit Informatica größeren Aufwand bedeuten, da nicht nur Connections umgestellt werden müssen, sondern auch Source und Targets sowie SQL-Overrides etc.. Zusätzliche Problematik bringt die Tatsache, dass lediglich für das Schreiben in Greenplum ein PWX-Adapter von Informatica zur Verfügung gestellt wird. Für das Lesen und somit auch das Aufbauen der Transformationen und der Caches wird eine ODBC-Verbindung genutzt, die nur mäßige Performance aufweist. Auch die Update-Strategy von Informatica wird in Greenplum nicht zufriedenstellend unterstützt, so dass Updates außerhalb von Informatica durchgeführt werden mussten. Die Kosten, die benötigte Zeit und der Aufwand einer Einführung bzw. Migration hängen sehr stark vom Einsatzszenario ab. Neben einigen Kinderkrankheiten, wie z.B. mangelnde Unterstützung von Modellierungswerkzeugen, die zukünftig nicht mehr zu erwarten sind, bestimmen im Wesentlichen Einsatzzweck und Systemarchitektur die Hürden einer Einführung. Wenn Greenplum lediglich für die Bewirtschaftung von Data- Marts und Ihre Analyse eingesetzt wird, kann das System in relative kurzer Zeit aufgebaut werden. Anders verhält es sich, wenn ein komplettes DWH mit sehr vielen Mappings zur Bewirtschaftung abgelöst wird. Hier kann die Einführung sehr langwierig und teuer werden. Trotzdem liegt eine Stärke von Greenplum im Bereich Data-Loading. Wenn die Möglichkeiten des MPP richtig ausgeschöpft werden, gibt es derzeit keine andere Lösung am Markt, welche die Daten schneller in die DB laden kann. Auf der anderen Seite besitzt die Greenplum enormes Potential bei der Performance im Bereich der Analyse mit BI-Werkzeugen. Praxistests haben bewiesen, dass bei optimaler Modellierung die Ergebnisse im Vergleich zu klassischen Datenbanken besonders bei großen Datenmengen bis zu 150mal schneller vorliegen. Das größte Potential von Greenplum steckt sicherlich in der Kombination relationaler DB und Big Data innerhalb einer BI-Umgebung. Durch diesen Ansatz sollte es in Zukunft auf einfache Art und Weise möglich sein, unstrukturierte Daten in strukturierter Form zu analysieren und mit strukturierten Daten zu vergleichen. www.saracus.com Seite 6
  • 7. Big Data Appliances IBM PureData System for Analytics Diese Appliance ist die Datenbanktechnologie für IBM‘s analytische Appliance und kombiniert Netezza-Technologie mit den bekannten S-Blades als Hardware und einem Red Hat Linux Advanced Server 5 als Betriebssystem. Als Alleinstellungsmerkmal integriert sie sogenannte field programmable gate arrays (FPGAs), die zur Datenfilterung unmittelbar am Diskspeicher eingesetzt werden. Damit wird ein wesentlicher Teil der Abfragelogik direkt an den Daten ohne Netzwerkverkehr ermöglicht. Zusammen mit der asymetrischen massiv parallelen Verarbeitung (AMPP) sind diese Appliances damit auf query-performance getrimmt. Das PureData System ist, wie für Appliances üblich, in verschiedenen Ausbaustufen einsetzbar. Quelle: http://public.dhe.ibm.com/common/ssi/ecm/en/imd14400usen/IMD14400USEN.PDF PureData System for Analytics (und Greenplum‘s) Vorteil in der Datenbanktechnologie ist die Performance- Optimierung out of the box. Trotz der Anwendung normaler Modellierungstechniken aus der transaktionalen oder dimensionalen Welt werden keine Indizes, Partitionierungen, Tablespaces, Hints oder sonstigen Optimierungstechniken in der Entwicklung benötigt. Dies erleichtert die Entwicklung und Wartbarkeit sowie den Betrieb des „Datenbankservers“ in hohem Maße. Durch die sehr breite Portierungsfähigkeit von anderen Datenbanksystemen ist darüber hinaus eine sehr einfache Anwendungsmigration möglich. Eine Migration von DB2, Informix, Microsoft SQL Server, Oracle, Sybase oder Teradata erfolgt i.d.R. problemlos, abhängig von der Verwendung von datenbank-spezifischen Funktionen. Eine Standardportierung von einem gängigen Oracle- Datenbankserver auf ein PureData System mit annähernd gleichen Ressourcen bewirkt dabei ohne Tuning- maßnahmen schnell die 20-fache Queryperformance. Für die weitere Toollandschaft gelten annähernd gleiche Bedingungen. Alle gängigen BI- und ETL-Tools können an ein PureData System angebunden werden und auch die Standardschnittstellen wie ODBC oder JDBC werden unterstützt. Der Philosophie der Appliance folgend ist die Handhabung des Systems als black box für das gesamte System durchgängig. Ein PureData System kommt als „Box“, vorkonfiguriert und einsatzbereit, und kann nach Anschluss einiger IP/Netzanschlüsse direkt in die Unternehmens- infrastruktur integriert werden. Es entfallen Hard- und Softwareinstallationen sowie umfangreiche Systemkonfigurationen. Diese Vorteile setzen sich im Betrieb fort. Durch die redundante Auslegung aller Komponenten ist die Ausfallsicherheit gewährleistet. Die nahezu lineare Skalierungsmöglichkeit verhindert zukünftige Ersatzinvestitionen, das black-box Prinzip reduziert den Ressourceneinsatz. Mittels Gesamtwartungsvertrag für das System ist damit der TCO sehr gut abschätzbar. www.saracus.com Seite 7
  • 8. Big Data Appliances Mit PureData System for Analytics ist man für Big Data gerüstet. Netezza Analytics ermöglicht MapReduce-Routinen und über Schnittstellen kann auf Hadoop zugegriffen werden. Big Data ist dabei nur ein Teil der analytischen Fokussierung von PureData System for Analytics. Es finden sich diverse weitere analytische Bereiche wie SAS- oder SPSS-Integration, Unterstützung diverser Programmiersprachen für build-in code oder bereits verfügbare Analysemethoden wie z.B. Zeitreihenanalytik. Die Herausforderung einer Migration auf ein PureData System besteht im wesentlichen aus der Anpassung bestehender Spezialfunktionalitäten. Dies betrifft alle Anwendungsbereiche eines analytischen Systems, von der Datenbank über das ETL-Werkzeug bis hin zum Frontend bzw. weiteren statistischen Systemen. Die grundsätzliche Aussage hierbei ist, je näher die Werkzeuge am SQL-ANSI Standard eingesetzt werden, desto geringer ist die Migrationskomplexität. Oftmals ist gerade die Abkehr vom Standard-SQL die einzige Möglichkeit in klassischen Systemen akzeptable Performance zu erreichen und daher weit verbreitet. Diese Funktionalitäten sind aber kaum bei einer Migration auf ein PureData System automatisierbar und müssen manuell angepasst werden. Der hierbei entstehende Aufwand sollte wohl bedacht und durch entsprechende Systemexperten kalkuliert werden. Dabei spielen interessanter Weise die eigentlichen Datenbanküberführungen die untergeordnete Rolle. Dies ist vor allem dadurch begründet, dass viele Datenbankfunktionalitäten mit Netezza out of the box bereitgestellt werden, wie bspw. Indizierung. Vielmehr sind es die Zugriffsmuster der ETL- und Frontend-Werkzeuge, bei denen es nicht ausreicht den Connector umzustellen, wenn spezifische Zugriffsmethoden verwendet werden, sondern jeder Zugriff dieser Art angepasst werden muss. Quelle: http://public.dhe.ibm.com/common/ssi/ecm/en/imd14400usen/IMD14400USEN.PDF www.saracus.com Seite 8
  • 9. Big Data Appliances Oracle Exadata Oracles‘s Exadata Database Machine (OEDM) ist eine vollständige, vorkonfigurierte Datenbankumgebung, die Oracle‘s Real Application Cluster (RAC) Datenbankserver mit Exadata Storage Servern über das interne Netzwerk InfiniBand integriert. Sie ist in zwei Varianten verfügbar: Exadata Database Machine X3-8 ist für Datenbankbereitstellungen konzipiert, die sehr große Datenmengen benötigen. Sie bietet höchste Performance und Skalierbarkeit, insbesondere auch für operative Systeme mit hohen heterogen Arbeitslasten. Exadata Database Machine X3-2 in unterschiedlichen Konfigurationen (Rack-Ausbau) verfügbar und damit für Anforderungen jeder Art einsetz- und skalierbar. Oracle Exadata X3-8 X3-2 Database Machine Rackausbau 1 Rack 1 Rack ½ Rack ¼ Rack 1/8 Rack Database Servers 12 8 4 2 2 CPU Cores DB-Operationen 160 128 64 32 16 (GB) Max. Speicher 4096 2048 1024 512 512 Exadata Storage Server 14 14 7 3 3 CPU Cores SQL- 168 168 84 36 18 Operationen Smart Flash Cache (TB) 22.4 22.4 11.2 4.8 2.4 Anzahl Disks 168 168 84 36 18 Nutzbarer Diskspeicher bei 45 45 22.5 9.5 4.5 „Performance“ (TB) Nutzbarer Diskspeicher bei 224 224 112 48 23 „Kapazität“ (TB) Anzahl InfiniBand Switches 3 3 3 2 2 Quelle: In Anlehnung an http://www.oracle.com/technetwork/server-storage/engineered- systems/exadata/dbmachine-x3-twp-1867467.pdf?ssSourceSiteId=ocomen Oracles Exadata Database Machine ist im Gegensatz zu den Konkurrenten eine „shared disk“ Architektur, deren Stärke in der Performance bei transaktionsorientierten Systemen liegt. Im Zuge der steigenden Operationalisierung von Data Warehouse Systemen mit dem einhergehenden Mixed-Workload wirkt sich dies vorteilhaft aus. Bei rein analytischen Systemen hingegen wirkt es nachteilig und muss durch Hardwareaufrüstung egalisiert werden. Für die anstehenden Anforderungen im Bereich Big Data ist es noch nicht absehbar, ob sich die Architektur relevant auswirkt. Die Softwarearchitektur des Exadata Database Server sind von den herkömmlichen Oracle Systemen bekannt und für die Nutzung der Exadata Database Machine erweitert und optimiert worden. Neue, für Exadata konzipierte Komponenten, sind Oracle Database Quality of Service (QoS) Management und QoS Management Memory Guard. Sie dienen zum Monitoring und zur Performance Optimierung von Anwendungen, die auf dem Datenbank-Server implementiert sind. Zur Verwaltung der Datenbanken wird wie bisher der Enterprise Manager eingesetzt. Ebenso findet sich das 11g Release, der Database Resource Manager (DBRM), das Oracle Database File System (DBFS) und das Oracle Automatic Storage Management (ASM) zur automatischen Daten-Speicher-Partitionierung wieder. www.saracus.com Seite 9
  • 10. Big Data Appliances Quelle: In Anlehnung an http://www.tektonsolutions.co.uk/2012/07/24/36/ Die Exadata Storage Server Software besteht aus den Komponenten: Cell Services (CELLSRV) Cell Services ist eine Multithread-Software, die auf den Exadata Cells läuft und mit der Datenbankinstanz auf dem Datenbankserver kommuniziert. Sie stellt die erweiterten Funktionen zum Auslagern von SQL bereit, überträgt Oracle-Blöcke, und implementiert die DBRM I/O Resource Management-Funktionen, um die I/O-Bandbreite an die verschiedenen Datenbanken und Nutzungsgruppen, die I/O ausgeben, zu verteilen. Management Server (MS) Der Management Server stellt die Funktionen für die eigenständige Verwaltung und Konfiguration der Exadata-Cells bereit. Er wird über das Exadata cell command line interface (CLI) oder das Exadata plug-in für den Enterprise Manager angesprochen. Dadurch können alle bekannten Funktionen auch für die Verwaltung der Exadata-Server genutzt werden. Dazu gehören i.w. die Überwachung des Oracle Exadata-Storage, die Sammlung von Informationen zur Konfiguration und Leistung des Speichers, die Erzeugung von Alarmen und Warnungen auf Grundlage der Schwellenwerte sowie die Bereitstellung von integrierten aussagekräftigen Metriken und Berichten auf Grundlage von historischen Daten. Restart Server (RS) Der Restart Server sorgt dafür, dass die Exadata-Software und Storage-Services gestartet werden und laufen. Sie wird auch zur Aktualisierung der Exadata-Software verwendet. Eine entscheidene Rolle kommt dem Übertragungsprotokoll iDB zu. iDB baut auf dem Industrie-standard Reliable Datagram Sockets-Protokoll (RDSv3) auf und läuft über InfiniBand. Das ZDP-Protokoll (Zero-Loss Zero-Copy Datagram Protocol) ist eine Zero-Copy-Implementierung von RDS und wird verwendet, um das unnötige Kopieren von Blöcken zu vermeiden. Mehrere Netzwerkschnittstellen können auf den Datenbankservern und Exadata-Zellen verwendet werden. Dabei handelt es sich um ein extrem schnelles Protokoll mit niedriger Latenz, das die Anzahl der erforderlichen Datenkopien minimiert, die für die I/O-Operationen erforderlich sind. www.saracus.com Seite 10
  • 11. Big Data Appliances Wichtige Funktionen der Exadata Storage Server Software sind: Exadata Smart Scan Processing Bei traditionellem, nicht iDB-fähigem Speicher befindet sich die gesamte Datenbanklogik in der Datenbanksoftware auf dem Server. Durch das Exadata Smart Scan Processing werden Datenbankfunktionalitäten in die Speicherungsschicht, den Exadata Cells, integriert. Dort können Abfragen und andere Datenbankoperationen sehr viel effizienter ausgeführt werden und nur die erforderliche Teilmenge der Daten wird an den Datenbankserver zurückgegeben. Es werden lediglich relevante Zeilen und Spalten und keine Datenbank-Blöcke übertragen. Smart- Scans sind für die Anwendung transparent, und es ist nicht erforderlich, Änderungen an der Anwendung oder dem SQL-Code vorzunehmen. Sie sind in der Lage, die komplexen internen Mechanismen der Oracle-Datenbank richtig zu verarbeiten. Wenn Exadata Smart Scan verwendet wird, zeigt der SQL EXPLAIN PLAN dies an. Bei Ausfall einer Zelle während einer Smart-Scan-Operation können die noch nicht abgeschlossenen Teile des Smart Scan transparent an eine andere Zelle weitergeleitet und dort abgeschlossen werden. Indem die SQL-Verarbeitung vom Datenbankserver ausgelagert wird, werden Server-CPU-Zyklen freigegeben und ein großer Teil des Bandbreitenverbrauchs wird eingespart. Datenbankfunktionalitäten, die auf die Exadata Cells verlagert werden können sind unter anderem die Zeilen- und Spaltenfilterung, die Verarbeitung von Join-Anweisungen, die Technologie zur Storage-Indizierung, Smart-Scan-Offload der neuen Hybrid Columnar Compressed Tables, Smart- Scan-Offload von verschlüsselten Tablespaces und Spalten und Auslagerung der Data Mining-Modell-Bewertung. Ebenso können inkrementelle Datenbank-Backups und die Erstellung von Tablespaces auf die Exadata Cells verlagert werden, wodurch eine Verringerung des I/O Bandbreitenverbrauchs erreicht wird. Exadata Hybrid Columnar Compression Exadata verfügt über eine sehr effektive Funktionalität zur Kompression von Daten, die Hybrid Columnar Compression (HCC). Sie ist eine neue Methode zur Organisation der Daten innerhalb eines Datenbank-Blocks. Hierbei werden Zeilen- und Spaltenbasierte Methoden miteinander kombiniert. Die durchschnittliche Speichereinsparung variiert zwischen dem Faktor 10 bis 15, je nach Einsatz von HCC (10% bei der Datawarehouse Kompression, 15% bei der Archivierungskompression). In Verbindung mit Smart Scan, das keine vorherige Dekompression der Daten verlangt, kann eine erhebliche Einsparung des I/O Bandbreitenverbrauchs erreicht werden. Exadata Smart Flash Cache Feature Die Nutzung des Smart Flash Caches wird durch die Exadata Storage Server Software gesteuert. Als Hardware setzt Oracle PCI Flash Cards(Sun Flash Accelerator F20 mit 96 GB) anstatt Flash Disks ein, sodass die gute Performance des Flash Speichers nicht durch langsame Disk-Controller ausgebremst wird. Jeder Exadata Storage Server verfügt über 4 PCI Flash Cards mit einer Gesamtkapazität von 1,6 TB. Das Smart Flash Cache Feature ermöglicht automatisches Caching von Lese- und Schreibzugriffen in der Datenbank. Hierdurch werden die Schreib- IOPS um das 20-fache und die Daten-Bandbreite um 33% erhöht. Beim Speichern von Datenbank-Objekten entscheidet die Exadata Server Software, wann und wie der Exadata Smart Flash Cache genutzt wird und wie dieser mit dem Flash-Cache der Datenbank kombiniert wird als Teil einer Data-Caching- Strategie. Die Daten können simultan aus dem Flash-Speicher und von der Platte gelesen werden. Die Full Rack X3 Database Machine erreicht mit dieser Technologie bis zu 1,5 Millionen I/O operations per second (IOPS)und einen Datendurchsatz von bis zu 75 GB/Sekunde. Datenbank- und Storage-Server-Software bieten dem Anwender auch die Möglichkeit durch einfache Befehle für Tabellen, Indizes und Segmenten sicherzustellen, dass bestimmte Daten permanent in den Flash-Speicher geschrieben werden. Ebenso können ganze Tabellen in den Flash-Speicher geholt werden ohne sie in einen anderen Tablespace zu verschieben. Der Smart Flash Cache wird auch genutzt, um das Schreiben von Logeinträgen zu beschleunigen. Standardmäßig werden Logeinträge in den DRAM-Cache des Disk-Controllers geschrieben. Bei einem hohen Aufkommen von I/O Operationen entstehen häufige Wartezeiten. Diese können durch Schreiben in www.saracus.com Seite 11
  • 12. Big Data Appliances den Smart Flash Cache wesentlich verringert werden, so dass die Performance verbessert wird. Allerdings gibt es hier auch einige Ausnahmen. Exadata Smart Logging verfolgt daher den Ansatz, die Logeinträge sowohl in den Smart Flash Cache als auch in den DRAM Cache des disk-Controllers zu schrieben. Sobald einer der beiden Schreibvorgänge beendet ist, wird der andere abgebrochen. Somit werden die Vorteile beider Methoden genutzt. I/O-Ressourcenmanagement mit Exadata Beim traditionellen Speicher wird das Anlegen eines Shared-Storage-Grid dadurch beeinträchtigt, dass es unmöglich ist, Prioritäten für die verschiedenen Jobs und Benutzer festzulegen, die I/OBandbreite aus dem Storage-Subsystem verbrauchen. Dasselbe trifft zu, wenn mehrere Datenbanken sich ein Storage-Subsystem teilen. Die Funktionen von DBRM und der I/O Ressourcenverwaltung können verhindern, dass eine Arbeitsklasse oder Datenbank die Datenträgerressourcen und Bandbreite monopolisiert, und stellt sicher, dass benutzerdefinierte SLAs bei der Verwendung von Exadata-Storage erfüllt werden. Der DBRM ermöglicht die Koordinierung und Priorisierung von I/O-Bandbreite, die von den verschiedenen Datenbanken bzw. verschiedenen Benutzern oder Arbeitsklassen verbraucht wird. Durch die enge Integration der Datenbank in die Storage-Umgebung erkennt Exadata die Arten von Arbeiten und wie viel I/O-Bandbreite verbraucht wird. Folglich können Benutzer das Exadata-System einsetzen, um die verschiedenen Arten von Arbeitslasten zu identifizieren, diesen Arbeitslasten Prioritäten zuzuweisen und sicherzustellen, dass die wichtigsten Arbeitslasten vorrangig behandelt werden. Fazit Für eine Migration auf eine Exadata Machine können alle herkömmlichen Techniken zur Migration von Oracle Datenbanken verwandt werden. Mittels Data Pump oder dem Verschieben von Tablespaces bzw. der Nutzung des Oracle Recovery Manager (RMAN) sowie dem Oracle Data Guard ist eine schnelle Migration möglich. Das Gleiche gilt für alle Anwendungen, die auf herkömmlichen Oracle-Systemen laufen. Sie können i.d.R. ohne Änderungen auf ein Exadata-System übernommen werden. Das macht Exadata interessant für den Großteil von BI-Systemen. Aus technischer Sicht ist das Exadata-System ein gekapseltes „all in one“ Datenbanksystem mit hoher Flexibilität, dass für die meisten bestehenden Systeme relativ einfach zu migrieren ist. Die wesentlichen Vorteile von Exadata finden sich demnach auch in dem Einsatzportfolio, das die gesamte Bandbreite von OLTP- bis OLAP-Anwendungen abdeckt und über Schnittstellen zu allen gängigen Werkzeugen verfügt. Für individuelle Spezialisierungen hingegen, wie z.B. eine extrem hohe Rate an konkurrierenden & komplexen Abfragen, ist jedoch die hardwareseitige Unterstützung notwendig und/oder gezielte Systemeinstellungen. Mit jeder Spezialisierung aber erhöht sich die Komplexität des Systems und Betriebs- und Wartbarkeit. Das kann neben den hochpreisigen Investitions- und Betriebskosten im Vergleich zu den Konkurrenten schnell zu einem ungünstigen TCO führen. www.saracus.com Seite 12
  • 13. Big Data Appliances Teradata Aster Big Analytics Appliance Teradata bietet eine Reihe von Data Warehouse Plattformen an, um spezifische fachliche und technische Anforderungen gerecht zu werden. Angefangen mit der Teradata Data Mart Appliance, für die Bedürfnisse eines kleineren, kostengünstigeren (Fachbereichs-)Data Warehouses, bis hin zum hochperformanten und leicht skalierbaren Teradata Active Enterprise Data Warehouse, optimiert für strategische und operative Workloads. Quelle: http://www.teradata.com/brochures/Teradata-Purpose-Built-Platform-Family-eb5778/ Darüber hinaus hat Teradata mit der Terradata Aster Big Analytics Appliance eine weitere Plattform eingeführt, um gezielt den Bedürfnissen der Big-Data-Analytics nachzukommen. Die Big Analytics Appliance ist eine vollständig vorkonfigurierte, ready-to-run Platform. Durch eine Kombination von Big Data Technologie und ANSI-Standard SQL Tools für BI und ETL, ist diese Appliance optimiert für das Speichern und Analysieren von Big Data. Die Appliance basiert auf einer hybriden Architektur und beinhalten folgenden Komponenten: Aster Database liefert eine massively parallel (MPP) analytische Plattform und integriert die SQL-MapReduce- Technologie, Teradata Aster SQL-H und mit Aster MapReduce Analytics Portfolio eine Bibliothek mit über 50 analytischen Funktionen. SQL-MapReduce ist ein patentiertes Framework, welches die analytische Power von MapReduce mit vertrauten SQL kombiniert. Aster SQL-H ermöglicht Unternehmen, durch Nutzung von Standard- SQL- und BI-Werkzeuge, wertvolle Datenschätze direkt aus Hadoop zu heben. Aster SQL-H nutzt dazu das Open-Source Projekt Apache HCatalog, das Metadaten für einen vereinfachten Zugang bereitstellt. Apache Hadoop bietet ein hochverfügbares, leistungsfähiges Dateisystem zur Speicherung von großen Datenmengen. Darüber hinaus verfügt die Appliance mit einen InfiniBand Switch mit 40 Gigabyte pro Sekunde, über eine hochperformante Verbindung zwischen den Aster und Hadoop Knoten. Quelle: http://www.asterdata.com/resources/assets/sb-big-analytics-appliance.pdf www.saracus.com Seite 13
  • 14. Big Data Appliances Die Teradata Aster Big Analytics Appliance wird als vollständig integriertes System aus Hard- und Software bereitgestellt. Als „Plug and Play“-Lösung kann sie innerhalb weniger Stunden den Betrieb aufnehmen. Mit einem maßgeschneiderten Mix aus Aster-Database- und Hadoop-Rechnerknoten lässt sie sich individuell an den analytischen Workload-Bedarf eines Unternehmens anpassen. Quelle: http://www.asterdata.com/resources/assets/sb-big-analytics-appliance.pdf / Fazit Terradata Aster Big Analytics bietet durch die Integration von relationalen Datenbanksystemen (basierend auf SQL) und Apache Hadoop (basierend auf dem SQL-MapReduce Software Framework), eine vereinheitlichte Datenarchitektur. Mit ihr verfügen Unternehmen über flexible Optionen zur Konfiguration, um die Aster Database und das Open Source-Framework Hadoop nahtlos zu integrieren, und um alle Arten von Daten – strukturiert oder unstrukturiert – zusammen mit einem Werkzeug zu analysieren. Über SQL-H können auch Business Analysten, die nicht Java oder eine andere Programmiersprache beherrschen (für Hadoop/MapReduce nötig) analytische Queries formulieren und so spielerisch mit den Daten jonglieren. Die Teradata Aster Big Analytics Appliance wurde für extreme Anforderungen an Datenanalysen entwickelt, die besonders hohe Rechnerleistung, viel Arbeitsspeicher und Möglichkeiten für Data Movement verlangen. Sie ermöglicht einen bis zu 19-fach höheren Datendurchsatz und bis zu 35-mal schnellere Analysen als marktübliche Analyselösungen. Eine Vielzahl von Adaptern ermöglicht eine out-of-the-box Integration in die bestehende IT-Landschaft . So ermöglichen z.B. zertifizierte ODBC und JDBC Schnittstellen die Anbindung aller gängigen BI und ETL Werzeuge. Die Plattform nutzt die patentierte SQL-MapReduce-Technologie von Aster, um Datenverarbeitung und Anwendungen zu parallelisieren. Somit ermöglichen einfach anwendbare SQL- und BI-Werkzeuge vielfältige analytische Einsichten und existierende Investitionen in SQL basierende BI und ETL Tools können weiterhin genutzt werden. www.saracus.com Seite 14
  • 15. Big Data Appliances Vergleichsübersicht Die hier vorgestellten Appliances haben ihre Berechtigung in speziellen Einsatzszenarien, die bei der jeweiligen Beschreibung herausgestellt wurde. Die folgende Übersicht fasst die Kernpunkte zusammen und soll als erstes Raster für oder gegen den Einsatz einer Appliance dienen. Anbieter Teradata Aster Big IBM PureData Oracle Exadata EMC Greenplum Analytics System for Analytics Kategorie (Netezza) Hardware Teradata (x86- IBM (x86-Architektur) Sun Beliebige x86- Architektur Dual Hardware möglich; Intel Six-Core Xeon mit HP-Hardware im Processors) vorkonfiguriertem Bundle Betriebssystem Novell Suse Linux Red Hat Linux Oracle Linux Suse Linux, Red-Hat Sun Solaris Linux, CentOS, Solaris, Oracle Unbreakable Linux Datenbank Aster Database Propietär (auf Oracle 11g R2, RAC Proprietär (auf Postgres basierend) Postgres basierend) DB-Technologie Hybrid (Zeilen- und Zeilenorientiert Zeilenorientiert Polymorph Data Spaltenorientiert) Storage (Wahl zwischen Zeilen- und Spaltenorientiert) DB-Kompression Dynamische Kompressions-Engine Hybrid Columnar In-database Datenkompression (Kompressionsrate Compression (HCC) Kompression (Kompressionsrate 4x – 8x) (Kompressionsrate (Kompressionsrate 3x – 12x) 10x-15x) 3x-10x) Advanced SQL-MapReduce, SAS-Funktionen in der Oracle Advanced SAS-Funktionen in Analytics SQL-H, MapReduce DB, In-database- Analytics (Oracle R der DB, Native Map Analytics analytics, R, Matrix, and Data Minig) Reduce Processing, Funktionen, Hadoop Hadoop, Spatial zusätzlich zu Programmable beschaffen Analytics Leistungsprinzip MPP MPP Hardware- MPP Datenbank mit MPP Software Spezialisierte erweiterung (S- Storage Server Datenbank Datenbank für Blades) spezialisierte DWH/BI Datenbank für DWH/BI Besonderheiten - patentierte SQL- S-Blades mit FPGA Smart Flash Cache, - Polymorphic Data MapReduce- Database Accelerator Smart Scan Storage-MultiStorage Technologie / SSD Support - Out of the box - Out of the box Support für Big Data Support für Big Data Analytics und Analytics und Hadoop Hadoop - MPP Scatter / Gather - Streaming Einsatz Analytisch Analytisch Analytisch / Analytisch Operational Konnektivität gut gut gut gut TCO mittel mittel hoch niedrig www.saracus.com Seite 15
  • 16. Big Data und Business Intelligence Fazit Appliances bieten einen interessanten Ansatz für flexible und gut kalkulierbare Systeme. Gerade im analytischen BI- Markt können diese massiv parallelen Systeme mit vielen Vorteilen gegenüber klassischen Datenbanksystemen punkten. Dazu gehören u.a. • Kalkulierbare Installations-, Betriebs- und Wartungskosten (TCO) • Hohe Flexibilität und Skalierbarkeit (Investitionsschutz) sowie die Möglichkeit, mit den Herausforderungen zu wachsen (Planungssicherheit) • Abgestimmtes System, kein Customizing, Standardisierung unter dem Prädikat „Einfachheit“ (Wartbarkeit und Anwendungsfreundlichkeit) • Reduzierung des Aufwandes für Entwicklung und Wartung (Ressourcen-Minimierung) Die Vorteile machen direkt das wahrscheinlichste Einsatzszenario einer Appliance im analytischen Umfeld deutlich: der Einsatz als Datenbankserver. Die Appliances haben sich darauf fokussiert, wenngleich Oracle auch den operativen Bereich mit abdeckt. Big Data wirkt dabei als Katalysator auf dem Appliance-Markt. Es ist eine Funktionalität unter vielen, die den Einsatz einer Appliance unterstützen kann. Der zentrale Kernpunkt ist aktuell jedoch die Analytik im klassischen Sinn. Die Symbiose zwischen einer Appliance und Big Data bezieht sich daher wortwörtlich auf „Big“, d.h. die schiere Datenmenge. Die Funktionalität, die unterschiedlichen und unstrukturierten Daten zu verarbeiten sowie die Integration darauf spezialisierter Komponenten ist kein Alleinstellungsmerkmal von Appliances. Die aktuelle Entwicklung könnte man mit den BI-Ansätzen der Vergangenheit vergleichen. Waren früher die „best of bread-Ansätze“ (z.B. DB2,Informatica und MicroStrategy) und die „Suit-Ansätze“ (z.B. SAP, Oracle) im BI-Umfeld stark diskutiert, so stellen sich aktuell unter dem Thema Big Data die Appliances gegen „open source - Systeme“. Diese versuchen mit kostengünstiger Hardware und open source software die Leistungsfähigkeit der Appliances unter Budgetminimierung zu erreichen. Dazu verwenden sie u.a. auch neue Verarbeitungsmethodiken, wie z.B. NoSQl-Datenbanken. Das diese Entwicklungen beachtenswert sind, zeigt allein schon die Tatsache, dass die Appliances entsprechende Schnittstellen anbieten oder Algorithmen übernehmen. Die hier betrachteten Appliances können als „Hard- und Software-Appliance“ betrachtet werden. Daneben existieren auch noch reine Software-Appliances, bei denen die Hardware variabel gewählt werden kann bzw. Hardware-Bundle über Partner angeboten werden. Kandidaten hierzu sind u.a. die Microsoft Parallel Appliance, Kognitio oder Exasol. Diese Software-Appliances sind jedoch eher als ergänzende Systemkomponente anzusehen. So findet sich häufig der Einsatz einer In-memory-Datenbank (z.B. Kognitio) als zusätzlicher „Performance- accelerator“ innerhalb eines bestehende Systems. Technologie Warum saracus consulting? • Programmierung / Die folgenden Faktoren sprechen für die Wahl der saracus consulting als Beratungs- und Customizing Hadoop- Integrationspartner: basierter Systeme • Seit 1991 zu 100% fokussiert auf DWH, BI, CPM und aCRM • Integration BI-Tools und • Spezifische Vorgehensmethodik • Customizing von ETL- Tools in Big Data • Große Erfahrung mit wichtigen Technologien Umgebungen • Kombination von Business- und IT-Know-how • Strategie- & Architektur- • Umfangreiche Anzahl an ausgebildeten und erfahrenen Beratern, beratung zu Big Data BI um auch große Projekte zeitgerecht fertig zu stellen • Anwendung v. Appliances • Full Service von der Analyse, Konzeption über Systemintegration bis zum Betrieb • Werkzeugevaluation www.saracus.com Seite 16