Heise Consulting Services GmbH
images/Logo3-trans.png

Technology Blog

Der Einsatz von MapReduce im Business Intelligence und vermeintliche Alternativen klassischer massiv paralleler Datenbank (MPP) Lösungen.

  • Reifegrad von MapReduce mit einer verteilten Datenspeicherung
  • Apache Access Logs in MySQL
  • MapReduce Framework
  • Google Analytics
  • MapReduce auf verteiltem Filesystem (Beispiel Hadoop)
  • MapReduce in (MPP) Datenbanken
  • Datenmanagement

Reifegrad von MapReduce mit einer verteilten Datenspeicherung?

Das Datenvolumen und die Analysetiefe der Datenbestände nimmt in allen Branchen zu. Zählten vor 15 Jahren >2GB DataWarehouses zu großen Installationen, sind heute 1 TB große DataWarehouses üblich und erste Systeme mit einem Datenvolumen von PB sind im produktiven Einsatz. Heute sind Größen zwischen 100 bis 300GB von DataWarehhouse Lösungen eher klein. Der Wachstum des Datenaufkommens ist in den einzelnen Branchen durchaus unterschiedlich;  zu Branchen mit großen Wachstumsraten zählen Internet Service Provider oder Telekommunikationsunternehmen, auch wenn eine Datenvorratsspeicherung nach dem Urteil des Bundesverfassungsgerichtes vom 2.3.2010 verfassungswidrig ist und sämtliche Daten zur Vorratsspeicherung zu löschen sind. Zudem liefern Daten der Vorratsdatenspeicherung keine wichtige Basis analytischer Funktionen. Ein Grund für die Zunahme des Datenvolumens sind zunehmende analytische Aktivitäten.  Ferner besteht ein Trend, Daten immer zeitnaher nach Ihrer Entstehung auszuwerten, um Reaktionszeiten auf Ereignisse oder Veränderungen zu reduzieren.
Die technische Reaktion auf diese Anforderungen ist zunehmend der Einsatz verteilter Rechenkapazität und Datenspeicherkapazitäten. Die Leistungssteuerung von Rechnern (z.B. immer noch gültige Mooresches Gesetz) und Speichermedien reichen nicht in allen Bereichen aus, die gestiegenen Kapazitätsanforderungen zu kompensieren. Seit dem von Google in 2004  vorgestellten MapReduce Ansatz zur Parallelisierung von Analysen und Ergebnisspeicherung auf Serverclustern haben Google und andere Internetdienste vergleichbare Lösungen mit diesem Ansatz im produktiven Einsatz. Hierbei werden mitunter hunderte von Servern zur Analyse und Datenspeicherung verbunden. In anderen Bereichen werden Massiv Parallel Prozessing (MPP) Datenbanken (shared-nothing-architecture) eingesetzt, um ähnliche Auswertung auf Massendaten vornehmen zu können, die derzeit mehr funktionale Rechenleistung gegenüber dem von Google vorgestellten Ansatz aufweisen. Welchen Reifegrad haben MapReduce Ansätze gegenüber MPP Datenbanken; welche Alternativen bestehen, wenn mit „commodity Hadware“ und vergleichsweise einfachen Datenbanken – wie beispielsweise MySQL als Massenmarkt DataWarehouse Lösung – das Wachstum auch solcher kleiner DataWarehouse Lösungen möglich sein soll?

Apache Access Logs in MySQL

MySQL Installationen spielen – als Open Source Produkt - bei Unternehmen der Internet Gemeinde eine wichtige Rolle. Ein Serviceangebot von Internet Dienstleistern ist es, ihren Kunden Auswertungen über das Nutzerverhalten der von Ihnen gehosteten Webseites etc. zu liefern. Auch die Soziale-Netzwerke, Web-Shops/Auftritte oder Portale etc. nutzen Log-Dateien ihrer WebServer zu Analysezwecken. Die Ansätze der Auswertung und Datenerhebung können jedoch voneinander abweichen. Es sind hierzu Daten mit mehreren Millionen Datenzeilen zu analysieren und zumindest kurzfristig zu speichern.
Mit MySQL DBMS ist es eine Herausforderung, detail log records von Millionen Zeilen Access-Log Dateien auszuwerten. Service Anbieter hosten nicht selten tausende Web-Sites ihrer Kunden Domains mit entsprechenden analytischen Serviceangeboten. In der Literatur werden gegenwärtige Limitierungen von MySQL 5.1 Installationen für 50-100 Millionen Zeilen pro Tabelle und für mehr als 50 Abfragen/Sec. angegeben, wobei die jeweils zugrunde liegenden MySQL Storage Engine und Abfragekomplexität nicht immer benannt wird. Eigene Erfahrungen sind eher konservativ insbesondere dann, wenn wie im DataWarehouse Umfeld komplexe und variierende SQL Statements auf der MySQL mit gemischten Workload ausgeführt werden. Der Betrieb von DBMS und die Ausführung von SQL Statements kommt nicht ohne geeignete Tuning Maßnahmen aus.

Analytische Auswertungen von vielen Millionen Datenzeilen übersteigen MySQL Limits üblicher Konfiguration. Eine Skalierung (Datenmenge + Workload) durch den Einsatz einer Vielzahl von MySQL RDBMS zur jeweiligen Speicherung weniger Domain Log-Dateien (Shading) in Verbindung mit Replikationsmechanismen ist ein Lösungsansatz. Das Shading oder Partitionierung der Daten auf unterschiedliche MySQL Installation ist ein übliches Vorgehen bei den vorliegenden Mengengerüsten. Der Einsatz zusätzlicher Replikationsmechanismen dient der Verteilung von Schreib- und Lesezugriffen auf unterschiedliche MySQL Installationen. Der Master Knoten dient im wesentlichen für Schreibvorgänge und der Slave Knoten dient für Lesevorgänge/Abfragen. Dieses Shading (Partionierung) der Daten ist prinzipiell nur dann möglich, wenn keine Joins mit Datenbanken anderer verteilter MySQL Server für die jeweilige Auswertung benötigt werden. Die fachlichen Voraussetzungen müssen hier geprüft werden, ob relative unabhängige Daten auf den jeweiligen MySQL Installationen ausgewertet werden können. Eine solche Konfiguration ist eine Herausforderung für die gesamte Architektur und erhöht den Aufwand für DBAs, Datenmanagement, Anwendungslogik und Betriebsteam.

Jeder dieser MySQL Server bedarf einer eigenen wenn auch logisch einheitlichen Verwaltung und Datenbewirtschaftung, da der Einsatz eines MySQL Clusters mit der MySQL Storage Engine 7 für diesen

Anwendungsfall nicht möglich ist:

  1. MySQL benötigt für ein Cluster die NDB clustered engine
  2. Die NDB ist für lesende Zugriffe optimiert. Für konkurrierende schreibende Zugriffe ist diese Databasengine nicht optimiert. InnoDB ist für konkurrierende schreibende und lesende Zugriffe optimiert, unterstützt jedoch gegenwärtig keine Cluster
  3. Die gesamte NDB Datenbank muss im Arbeitsspeicher gehalten werden können. 

Dies bedeutet, eine Cluster-Option ist in Millionen Zeilen Umgebungen nicht anwendbar. Die Bewirtschaftung einer MySQL Installation ist Aufgabe der Anwendungslogik und der Jobsteuerung. Das Workload Management ist eine stetige Aufgabe sowie die Durchführung notwendiger Changes und wird durch die Datenbank nur in geringem Umfang unterstützt.
Apache bietet die Möglichkeit Access-Logs direkt in MySQL Datenbanken zu scheiben (mod_log_sql), ohne den Umweg Log-Dateien über einen Datenmanagement Prozess in eine MySQL zu laden. Hierdurch können Batch Ladevorgänge von Log-Dateien reduziert werden, Kapazitätsanforderungen zur Anreicherung und Analyse dieser Daten sind damit nicht gelöst. Ebenso sind Sicherheitsaspekte zu beachten, da Web-Server idR. außerhalb einer Firewall stehen und die Analytischen DBMS idR. sich innerhalb von Firewalls und anderer Netzwerksegmente befinden.
Soll eine Farm von MySQL Installationen zu einer logischen Instanz zusammengeführt werden, so bedarf (es einer) weiteren Software, da MySQL diese Funktionalität nicht enthält. So können beispielsweise mit anderen DBMS oder Middleware Verlinkungen verteilter MySQL Datenbanken eingerichtet werden, um Daten logisch zusammen zu führen. Einfache Abfragen mit geringen Datenrückgabemengen können auf diese Weise ausgeführt werden. Eine weitere Alternative Shading Daten zusammenzufügen ist der Einsatz von Sphinx (Open-Source) als eine Full-Text Index Engine mit MySQL Schnittstellen. Auch hier gilt, die Operationen auf diese „verknüpften“ Daten dürfen nicht zu „komplex“ sein. Der Einsatz dieser „federated databases“ ist mindestens aus Performancegesichtspunkten im DataWarehouse Umfeld eine unbefriedigende Maßnahme. Auch caching Maßnahmen sind nur begrenzet einsetzbar, wenn variierende Abfragen möglicherweise mit abweichenden Datenzugriffsbeschränkungen ausgeführt werden sollen.
Anmerkung: Der Einsatz heutiger MySQL Umgebungen ist für den Einsatz granularer Log-Access Daten für DataWarehouses mittlerer bis großer Historie nur mit einem deutlich erhöhtem Aufwand (Architektur, Design und Ressourcen) realisierbar. Goolge, YouToube, Facebook, Flickr, Metacafe oder Netlog nutzen MySQL Installation in Millionen Zeilen Konfiguration. MySQL installationen bieten sich eher für eine Hybrid-Strategie an, indem Analysen und Datenspeicher für granulare Daten außerhalb einer MySQL vorgenommen werden: MySQL Installationen enthalten Aggregate externer granularer Daten mittlerer Historie. Zahlreiche Anbieter von DataWarehouse Frontends stellen Schnittstellen zu MySQL bereit, so dass mitunter die Speicherung  dieser externen granularen Daten mit proprietären Lösungen erfolgen kann. Steigen Kapazitätsanforderungen und soll MySQL nicht durch ein anders DBMS ausgetauscht werden, da Anpassungen an Schnittstellen, der Einsatz neuer DBA Werkzeuge oder eine Datenmigration vermieden werden soll, so kann der Einsatz einer für MySQL optimierten Hardware (Kickfire) oder der Einsatz von Datenbanken eine Option sein, die MySQL zu spaltenorientierten (Infobright, Calpont) bis hin zu MPP Datenbanken erweitern (Calpont). MySQL Treiber oder Schnittstellen können weiterhin verwendet werden, sie besitzen jedoch einen geänderten Optimizer und Indexstrategie. Diese kapazitiven Beschränkungen von MySQL können auch auf DBMS anderer Single-Server Installationen übertragen werden.

MapReduce Framework

MapReduce ist ein funktionaler Programmieransatz und wird in Verbindung gebracht mit der Verarbeitung großer Datenmengen. Anwender definieren eine Map Funktion die Key/Value Paare einer Eingabeliste verarbeiten und wiederum Key/Value Paare erzeugen. Eine Reduce Funktion integriert diese Zwischenergebnisse mit gleichen Key/Value Paaren. Map-/Reduce Funktionen können in Sequenzen angewendet werden, so dass Zwischenergebnisse für weitere Berechnungen gespeichert werden können. Programme, die mit diesem Ansatz erstellt wurden sind parallelisierbar aufgrund der Key/Value Paare die in Clustern von Servern ausgeführt werden können. MapReduce umfasst zwei Technologiebereiche:

  1. Parallele Programmierung
  2. Verteiltes Datenmanagement

Reduce Funktionen können Zähler, Summen oder andere Aggregationen implementieren. MapReduce muss nicht immer für eine Reduktion der Datensätze sorgen, sondern es kann auch eine Anreicherung dieser sein. Beispielsweise wird die Anwendung von MapReduce auf Apache Access-Log Files formatierte Key/Value Listen möglicherweise mit anhängendem SessionID und Timestemp und einem neuem Key liefern. In Verbindung mit der Funktionalität der Map-Funktionen lassen sich mindestens drei Classen von Anwendungen formulieren:

  1. Textzerlegungen, Indizierung, Suchfunktionen
  2. Erstellung von Datenstrukturen (z.B. Graphen)
  3. Data Mining und maschinelles Lernen

MapReduce erzeugt Listen, diese Key/Value Paare können in Tabellen dargestellt werden. Invertierte Text-Listen sind jedoch nicht unbedingt wieder sinnvoll in Tabellen darstellbar z.B. ein invertierter „Klickstream“ Graph (welche Seiten zeigen -mit ein oder mehreren Links- auf eine bestimmte Seite). Graphen von „Klickstreams“ sind in relationalen Strukturen problematisch abzubilden (sparse tables); um zu einer URL zu gelangen können idR. nur wenige URLs aller verfügbaren URLs in einer Kette von Klicks durch die Webanwender genutzt werden. Die Repräsentation von „Klickstreams“ in Listen kann daher einer „relationalen“ Speicherung überlegen sein. Die Problematik der statistischen Auswertung hochdimensionaler Informationen mit hoher sparsity bleibt jedoch erhalten.  Analytische Funktionalitäten oder Berichte können auch ohne den Einsatz von SQL aus diesen Listen bereit gestellt werden. Beispielsweise können Berichte als Ergebnis Ausgabe-Listen der Reduce Funktion enthalten. Visualisierungswerkzeuge aus dem klassischen DataWarehouse Umfeld, die Ergebnisse von Abfragen multidimensionaler Datenstrukturen oder relationale Datenbanken darstellen, sind für die Darstellung dieser Listen nicht geeignet, es sei denn, diese Listen werden zuvor in geeignete Datenstrukturen exportiert.

Es gibt zahlreiche unterschiedliche Implementierungen von MapReduce (http://en.wikipedia.org/wiki/MapReduce Exemplarisch sind dies: http://hadoop.apache.org; http://qizmt.myspace.com; http://discoproject.org; http://www.greenplum.com; http://www.asterdata.com; http://mapreduce.stanford.edu;).

  1. Die Implementierung des Datenmanagements kann auf Anforderungen verteilter Filesysteme (Cluster) (Google, Hadoop) 
  2. gemeinsamer Speicher (Stanford Phoenix) oder
  3. paralleler Datenbanken (Greenplum) zugeschnitten sein. 

Google Analytics

Viele Projekte von Google speichern Daten in großen Tabellen. Google gibt an, hierfür eine eigene Infrastruktur geschaffen zu haben:

  1. Google File System (GFS) 10/2003
  2. MapReduce: Simplified Data Processing on Large Clusters 12/2004 (http://labs.google.com/papers/mapreduce.html)
  3. BigTabe: A Distributed Storage System for Structured Data 11/2006 (http://labs.google.com/papers/bigtable.html)

Zu dieser zählt auch das Google File System (GFS) zum speichern von Log-Files und Daten-Files. Goolges Engineers entwickelten eine BigTable als eigenständigen indizierten Datenspeicher basierend auf dem GFS, um große und verteilte Datenmengen, die wie Apache-Log Files auf über hunderte Maschinen verteilt sind in einer vertretbaren Zeit und mit einem wirtschaftlichen Ressourceneinsatz zu analysieren. Das Framework soll gleichzeitig die gesonderte Anforderungen paralleler Programmierung, Fehlertoleranz, Skalierbarkeit, Lastverteilung, Wiederherstellung oder Datenverteilung kapseln, so dass Anwender (Engineers) im wesentlichen Algorithmen für die Transformationen von Key/Value Paaren in Map- und Reduce Funktionen erstellen. Google nutzt den verteilten Datenspeicher BigTable für zahlreiche datenintensiven Produkte wie Google Search, Gmail, Google Maps, Google Earth oder Google Finance. Für diese Anwendungsfälle ist die BigTable eine Alternative zu RDBMS.
Mit seiner Datastore API ermöglicht Google den Zugriff auf den BigTable Datenspeicher. App Engine Anwender können Abfragen auf “Entitäten” im Datenspeicher ausführen. Eine „Entität“ besitzt “typed properties”,  wie StringProperty oder BooleanProperty. Es gibt zwei Schnittstellen um Abfragen auszuführen: Query Class (Prozedurale Abfrage) und GqlQuery Class (SQL ähnliche deklarative Abfrage Sprache).
Anmerkung: Google hat gezeigt, mit der BigTable und MapReduce für analytische Anwendungsfälle im Petabyte (PB) Umfeld eine Alternative zu (MPP) Datenbanken zu besitzen. Weiterhin dient Google der MapReduce Ansatz dem Datenmanagement semi-strukturierte Logfiles in strukturierte Daten zu transformieren, die in einer BigTable gespeichert werden. Die Datastore API und der MapReduce Ansatz bieten Engineers die bislang weniger im RDBMS Umfeld gearbeitet haben die Möglichkeit, in für sie bislang nicht bekanntem Umfang und Performance große Datenmengen zu analysieren.

MapReduce auf verteiltem Filesystem (Beispiel Hadoop)

Hadoop ist ein bedeutender Vertreter des Implementierungsansatzes von MapReduce in verteilten Filesystemen. Hadoop wurde in Anlehnung an die Google MapReduce Implementierung entworfen. Hadoop enthält zwei Hauptkomponenten:
Hadop distributed file system (HDFS):

  • Master/Slave Architekture: Der Master NameNode enthält Informationen über den Ort von Datenblöcken (Typischerweise 64MB). Jeder Datenblock kann auf einem unterschiedlichen Knoten (Server) liegen. Jeder Slave DataNode verwaltet seine Datenblöcke auf dem lokalen Filesystem, ohne Kenntnis der HDFS Dateien.
  • Speicherung von Dateien im HDFS: Jeder Client (zuvor im Temp-files auf dem Client gepuffert) sendet zu schreibende Dateien in kleinen Datenpaketen (4K) an die Slave DataNode(s). Der Master

NamedNode koordiniert die Verteilung der Datenblöcke auf die Slave DataNodes. Die Slave DataNodes empfangen und schreiben die Datenpakte sukzessive in das lokale Filesystem und senden die Datenblöcke weiter an den nächsten Replikationsslave der durch den Master NamedNode benannt wurde. Die Verwendung von Schecksummen zur Prüfung der Datenintegrität ist für diese kleinen Datenpakete nicht bekannt, so dass am Ende einer Übertragung von Dateien in das HDFS festgestellt wird, ob Integritätsbedingungen erfüllt sind (Schecksummen Prüfung erfolgen nach der Übertragung von Dateien – das Schreiben von großen Tabellen ist kein Prozess von wenigen Minuten).

  • Die Replikation und Re-Replikation von Datenblöcken erfolgt über unterschiedliche Cluster.
  • Der Master NameNode kann mehrere Kopien seiner Medatadaten verwalten und synchronisieren (FsImage, EditLog). Beim Start des Master NameNode wird jeweils das neueste FsImage verwendet.
  • Ein Absturz des Master NameNode führt zum Verlust aller zu diesem Zeitpunkt beschriebener HDFS Files (open Files).
  • Die Verteilung der Daten auf einzelne Cluster erfolgt nicht automatisch, um die Auslastung der Cluster zu balancieren.
  • Snapshots des HDFS zum Rollback im Fehlerfall sind nicht möglich.
  • Master/Slave Architektur ist nicht für Realtime Abfragen ausgelegt; sondern für eine Batch Verarbeitung bei der der Master Node die Jobsteuerung übernimmt.
  • Master/Slave Architektur ermöglicht gewöhnlich kein Random Accesss auf das HDFS.

Hadoop MapReduce

  • Built-in binding für Java und C
  • Map Funktionen sollten auf den verfügbaren Datenblöcken des Slave DataNode laufen. Die Ausgabe dieser Map Funktionen sollte mit Reducer Funktionen bearbeitet werden, die auf dem gleichen Slave DataNode ablaufen, um Netzwerk-Bandbreiten zu schonen.
  • HDFS ist in der Lage, Datenblöcke von einer Replikation zu lesen, so dass auch Replikationen auf dem SlaveNode durch die Map/Reducer-Funktionen genutzt werden können. 

Es gibt bereits zahlreiche Implementierungen von HDFS (Yahoo, Last.fm, Google, Facebook, enthalten in Amazon’s Elastic Compute Cloud (EC2) cloud computing infrastructure). Yahoo ist der Hauptsponsor von Hadoop.  Es gibt viele Foren- und Blog- Beitrage zu Hadoop. Ein paar weiterführende Artikel zur Architektur, Performance und Stabilität sind zu finden unter http://www.usenix.org/event/hotcloud09/tech/full_papers/tan.pdf; http://hadoop.apache.org/common/docs/r0.18.0/hdfs_design.pdf; http://www.pdl.cmu.edu/PDL-FTP/stray/CMU-PDL-09-107.pdf

HBase ist eine Java-basierte Erweiterung für Hadoop und wurde in Anlehnung an Googles BigTable entwickelt:

  • HBase ist keine Query Engine
  • HBase bietet Googles BigTable ähnliche Funktionalitäten auf Hadoop (HDFS).
  • HBase ist ein spaltenbasiert Datenspeicher aber kein Ersatz für RDBMS
  • Tabellen bestehen aus Regionen wobei jede Region auf unterschiedlichen Servern liegen kann. Tabellen werden im HDFS Filesystem gespeichert.
  • HBase besteht aus zwei Typen von Knoten: Master und Regionserver. Der Masterserver koordiniert die Regionserver.
  • Spezialtabellen –ROOT- und .META. speichern Schemainformationen und den Ort der Regionserver
  • TableInput/Table Output Format für Hadoop MapReduce
  • Native Java Client/API (get(byte[] row, byte[] column, long ts, int versions)
  • Beispiele für HBase Externsions: Hive, Pig, Cascading, Pigi, Hbase-Writer
  • Es besteht die Gefahr eines Datenverlustes, im Fehlerfall des Master Server des HDFS.
  • Scalierung: Radom access (Ab Release 0.20). Skalierung durch Verwendung von mehr Regionservern. Schreibvorgänge werden „ohne Indizes“ über das HDFS verteilt.
  • Reliability: Verwendung der HDFS Replikation; Backups sind möglich. Mit der HDFS Version ab 0.19.0, ist es möglich HDFS Files erneut zu öffnen und am Endes des Files Content zu schreiben. Hierdurch wird der Redo Logfile von HBase reliable.
  • Einfaches Datenbank Schema: Datenkonsistenz zwischen Tabellen erfolgt auf Anwendungsebene; Datenstrukturen können dafür durch den Entwickler einfach verändert werden
  • Gegenwärtig ist das von den Entwicklern von HBase gesteckte Ziel noch nicht erreicht: Der performante, reliable und fehlertolerante Lese/Schreibzugriff auf Tabellen mit >>Millionen von Zeilen und >>tausenden von Spalten mit „commodity“ Servern.  Gegenüber der BigTable von Google wird über konzeptionelle Performancenachteile (u.a. wegen Java Code-Basis) berichtet. Gegenwärtig werden Gesichtspunkte von Robustheit, Skalierung und Korrektheit in der Entwicklung von HBase Algorithmen fokussiert.

Anmerkung: Hadoop und HBase sind weiterhin im Status der Entwicklung aber werden bereits in Unternehmen wie Yahoo, Facebook oder Amazon produktiv genutzt. Die berichtete Fehlerrate von Jobs im HDFS Dateisystem wurde mit der Version 0.20 gegenüber Vorgängerversionen deutlich reduziert. Das HBase Projekt ist für die Unternehmungen interessant, die hohe Lizenzkosten für kommerzielle (MPP) RDBMS Produkte scheuen, affin für Open-Source Produkte sind und Aufgrund von Millionen von Zeilen in Tabellen die bestehenden MySQL Installationen oder Single-Server DMS Installationen Probleme bereiten. Konfigurationen auf der Basis Hadoop/HBase umfassen weitaus mehr Server als beispielsweise MPP Installationen mit vergleichbarem Datenvolumen und Analysebedarf. Gegenwärtig wird von Aktivitäten berichtet, PostgresSQL-Datenbanken über das HDFS Cluster zu verteilen. Mit PostgresSQL steht dann ein RDBMS auf einem HDFS Cluster zur Verfügung. Greenplum hat ebenfalls PostgresSQL für seine MPP Datenbank erweitert und gute Erfolge erzielt.

MapReduce in (MPP) Datenbanken

Zur Bewältigung hoher Kapazitätsanforderungen zeichnet sich ein Trend ab, die Software des DBMS und Hardware aufeinander abzustimmen und die Daten über mehrerer Rechnerknoten zu verteilen. Für Installationen hoher Kapazitäten setzt sich diese shared-nothing-architecture durch. Auch Anbieter, die in der Vergangenheit in ihren transaktionsorientierten Datenbanken auf SMP Architekturen gesetzt hatten und für den Einsatz komplexer Abfragen Optimierungen vorgenommen hatten, vollziehen einen Schwenk zu „DataWarehouse Applicances“ mit MPP Eigenschaften in ihren Top-Produkten. Gegenwärtig ist eine Vielzahl MPP DBMS verfügbar (Teradata, Sybase, HP Neoview, Oracle Exadata, IBM InfosphereBalancedWarehouse, Netezza, MicroSoft/DataAllegro, ParAcell, Greenplum, Vertica, Dataupia, Aster Data oder Calpont...) Analytische Funktionalitäten werden von einer Vielzahl kommerzieller DBMS Anbieter in ihre RDBMS integriert und bieten die Möglichkeit, externe analytische Funktionen innerhalb des DBMS auszuführen und schaffen die technischen Voraussetzungen für zukünftige datengetriebener Anwendungen. Diese Lösungen sind individuell und können nicht von einem Anbieter auf den anderen übertragen werden.
Greenplum und Aster Data Systems waren die ersten Datenbank Anbieter, die MapReduce Funktionalitäten in ihre Produkte integriert haben. Die Anbieter bietet die Möglichkeit, Flatfiles mit MapReduce Funktionen zur verarbeiten und (Zwischen-) Ergebnisse mit Daten aus dem RDBMS zu verknüpfen. Netezza und Teradata haben beispielsweise eigene Implementierungen des MapReduce Ansatzes. So löst Teradata MapReduce Funktionen auch mit SQL Statements (Bsp. Teradata Sessionalization von Access-Logs, die in dem RDBMS strukturiert gespeichert sind ggf. unter Anwendung von externen user defined funtions (UDF) http://developer.teradata.com/extensibility/articles/sessionization-map-reduce-support-in-teradata)
Anmerkung: MPP Datenbank Anbieter wie Teradata oder Greenplum nutzen ihre MPP Architektur um Prozesse z.B. SQL Statements zu parallelisieren und Daten perfomant, fehlertolerant und reliabel zu speichern. Die Gefahr von Datenverlusten wie bei Hadoop/HBase besteht nicht. Insbesondere Teradata besitzt durch seine über Jahre gereifte Architektur, Query-Engine und Administrationswerkzeugen technologische Eigenschaften die Hadoop/HBase oder auch Googles BigTable nicht aufweisen. Die großen MPP Datenbankanbieter werden in Bezug auf Skalierbarkeit oder Wirtschaftlichkeit durch Googles BigTable herausgefordert. Marktführer für „DataWarehouse Applicances“  (vergl. Gartner) wie Teradata, Oracle, IBM, Netezza oder MicroSoft/DataAllegro sind „stand-alone“ MPP DBMS für DataWarehousing. Sie haben ihre Skalierbarkeit in produktiven Umgebungen mit hunderten von Terabytes und intern mit Petabyte Datenvolumina demonstriert. Sie sind gleichsam in gemischten Workload Umgebungen bewährt. Visualisierungswerkzeuge aus dem klassischen DWH Umfeld zur Darstellung von Abfragen und Reporting, haben stabile Schnittstellen zu diesen MPP Datenbanken.
MapReplace in Verbindung mit Googles BigTable ist aus Datenbanksicht kein Ersatz für ein DataWarehouse. Es handelt sich um eine Ergänzung im Bereich Datenmanagement bzw. ETL und der Analysefunktionalität von DBMS. Funktionalitäten von MapReduce werden zum Portfolio von zukünftigen DBMS gehören. DBAs, DataWarehouse Anhänger und ihre Engieering Kollegen werden die für ihr Fachgebiet nutzbringenden Einsatzgebiete auswählen.

Datenmanagement

Mit der Einführung von MapReduce durch Google im Whitepaper von 2004,  wurde offensichtlich, dass MapReduce auch große Teile eines Datenmanagement Prozesses abdecken kann: von der Extraktion, der Transformation, dem Laden, der Datenbereinigung bis hin zur Datenanalyse. Die Möglichkeit des Einsatzes von externen Programmen in Map- und Reduce Funktionen verleiht MapReduce eine hohe Flexibilität und bietet die Möglichkeit, komplexe Transformationen/Mappings sogar in externe Libraries auszulagern. MapReduce Funktionalitäten gehen weit über Filter/Grep/RegExpression Techniken hinaus, wie sie beispielsweise in einfachen Hadoop Beispielen auf Web-Sites dargestellt werden. Die Einfachheit der Parallelisierung durch Key/Value Paare ist überzeugend aber Datenbewirtschaftungsprozesse  enthalten sehr häufig Datenabhängigkeiten, die berücksichtigt werden müssen.
Anmerkung: Wird anstelle von MySQL oder BigTable/HBase Datenspeicher eine MPP Datenbank eingesetzt, so sollte das Datenmanagement vermehrt in die Datenbank verlegt werden, die aufgrund ihrer MPP Architektur zur Parallelisierung von Bewirtschaftungsprozessen beiträgt. Wird eine Hadoop/HBase Umgebung gewählt, bestünde die Architektur aus einer Farm von „File-Servern“ die das HDFS Cluster aufspannen und den Datenspeicher in Form von HBase Tabellen bereitstellen und ebenso die Rechenkapazität für MapReduce Prozesse.  Mischformen mit Hadoop/HBase Umgebungen für die Speicherung großer Tabellen und dem Datenmanagement und MySQL Installationen zum speichern von Aggregationen sind eine Option für Unternehmungen, die beispielsweise Softwarelizenzen scheuen und lieber auf Open-Source Lösungen setzen. Neben den Ansätzen, das Datenmanagement mit MapReduce Ansätzen zu lösen stehen Tools zur Datenintegration bereit, die bei einigen Anbietern von DBMS in ihrem Produktportfolio enthalten sind oder von spezialisierten Softwarefirmen angeboten werden oder auch als Open-Source verfügbar sind. Die Eignung dieser Produkte zur Parallelisierung weist unterschiedliche Reifegrade auf. So ist eine parallele Ausführung von Datenmanagement Prozessen bei dem Open Source Produkt PDI (ehemals Kettle) erst ab Version 3.1 möglich und weist Limitierungen im Prozessdesign auf. Hingegen kann AbInitio hinsichtlich der Parallelisierung von Datenbewirtschaftungen als sehr ausgereift bezeichnet werden.