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

Transkript

1 White Paper saracus Big Data Stärken und Schwächen im praktischen Einsatz von Big Data Appliances

2 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 betreibbzw. 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 Münster Fon Fax saracus consulting AG Täfernstrasse 4 CH-5405 Baden-Dättwil Fon Fax saracus consulting d.o.o. ul. Bulevar Svetog Cara Konstantina, br SRB Nis Seite 2

3 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 semistrukturierten 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: Seite 3

4 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 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: 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. Seite 4

5 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. Seite 5

6 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. Seite 6

7 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: 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 Tuningmaß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 Unternehmensinfrastruktur 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. Seite 7

8 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: Seite 8

9 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 Database Machine X3-8 X3-2 Rackausbau 1 Rack 1 Rack ½ Rack ¼ Rack 1/8 Rack Database Servers CPU Cores DB-Operationen (GB) Max. Speicher Exadata Storage Server CPU Cores SQL- Operationen Smart Flash Cache (TB) Anzahl Disks Nutzbarer Diskspeicher bei Performance (TB) Nutzbarer Diskspeicher bei Kapazität (TB) Anzahl InfiniBand Switches Quelle: In Anlehnung an 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. Seite 9

10 Quelle: In Anlehnung an 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. Seite 10

11 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 Seite 11

12 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. Seite 12

13 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: 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: Seite 13

14 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: / 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. Seite 14

15 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 Kategorie Teradata Aster Big Analytics IBM PureData System for Analytics (Netezza) Oracle Exadata EMC Greenplum Hardware Teradata (x86- Architektur Dual Intel Six-Core Xeon Processors) IBM (x86-architektur) Sun Beliebige x86- Hardware möglich; mit HP-Hardware im vorkonfiguriertem Bundle Betriebssystem Novell Suse Linux Red Hat Linux Oracle Linux Sun Solaris Suse Linux, Red-Hat Linux, CentOS, Solaris, Oracle Unbreakable Linux Datenbank Aster Database Propietär (auf Postgres basierend) Oracle 11g R2, RAC Proprietär (auf Postgres basierend) DB-Technologie Hybrid (Zeilen- und Spaltenorientiert) Zeilenorientiert Zeilenorientiert Polymorph Data Storage (Wahl zwischen Zeilen- und Spaltenorientiert) DB-Kompression Dynamische Datenkompression (Kompressionsrate 3x 12x) Kompressions-Engine (Kompressionsrate 4x 8x) Hybrid Columnar Compression (HCC) (Kompressionsrate 10x-15x) In-database Kompression (Kompressionsrate 3x-10x) Advanced Analytics SQL-MapReduce, SQL-H, MapReduce Analytics Funktionen, Hadoop SAS-Funktionen in der DB, In-databaseanalytics, R, Matrix, Hadoop, Spatial Oracle Advanced Analytics (Oracle R and Data Minig) zusätzlich zu beschaffen SAS-Funktionen in der DB, Native Map Reduce Processing, Programmable Analytics Leistungsprinzip MPP Spezialisierte Datenbank für DWH/BI MPP Hardwareerweiterung (S- Blades) spezialisierte Datenbank für DWH/BI MPP Datenbank mit Storage Server MPP Software Datenbank Besonderheiten - patentierte SQL- MapReduce- Technologie - Out of the box Support für Big Data Analytics und Hadoop S-Blades mit FPGA Database Accelerator Smart Flash Cache, Smart Scan - Polymorphic Data Storage-MultiStorage / SSD Support - Out of the box Support für Big Data Analytics und Hadoop - MPP Scatter / Gather - Streaming Einsatz Analytisch Analytisch Analytisch / Operational Analytisch Konnektivität gut gut gut gut TCO mittel mittel hoch niedrig 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 Performanceaccelerator innerhalb eines bestehende Systems. Technologie Programmierung / Customizing Hadoopbasierter Systeme Integration BI-Tools und Customizing von ETL- Tools in Big Data Umgebungen Strategie- & Architekturberatung zu Big Data BI Anwendung v. Appliances Werkzeugevaluation Warum saracus consulting? Die folgenden Faktoren sprechen für die Wahl der saracus consulting als Beratungs- und Integrationspartner: Seit 1991 zu 100% fokussiert auf DWH, BI, CPM und acrm Spezifische Vorgehensmethodik Große Erfahrung mit wichtigen Technologien Kombination von Business- und IT-Know-how Umfangreiche Anzahl an ausgebildeten und erfahrenen Beratern, um auch große Projekte zeitgerecht fertig zu stellen Full Service von der Analyse, Konzeption über Systemintegration bis zum Betrieb Seite 16