DataStax Enterprise – Cassandra des Big Data

Inhaltsverzeichnis

Die Gartner-Analysten bewerten DataStax in ihrem aktuellen Magic Quadrant für operative Datenbanksysteme als führend. Die wesentliche Technik der DSE zur Datenhaltung ist die NoSQL-Datenbank Apache Cassandra. Aus historischen Gründen wird sie auch mit C* bezeichnet, um auf "Eventual Consistency" hinzuweisen. Heute spricht DataStax der Klarheit halber von "Tunable Consistency", da sich strenge Konsistenz gegen Eintausch von Latenz und "ein wenig Hochverfügbarkeit" offenbar immer garantieren lässt.

Cassandra ist ein spaltenorientierter KeyValue-Store mit einer SQL-artigen Syntax namens CQL (Cassandra Query Language). Zudem gibt es APIs für den Zugriff auf Cassandra-Cluster (sog. Ringe) aus vielen Programmierplattformen heraus, etwa Java, Python, R, C#/.NET, Ruby, PHP und Node.js. Die vor gut einem halben Jahr in DSE hinzugekommene Graphendatenbank Titan nutzt mit Gremlin eine vergleichbare Abfragesprache für die Suche in Graphen.

Durst nach Wissen

Mit der DSE-Distribution samt ihren Hadoop-nahen Komponenten führt DataStax Big Data den ursprünglichen Business-Intelligence-Gedanken auf einer neuen Ebene fort. Altbewährte Zöpfe wie ETL-Strecken (Extract, Transform, Load), JOIN-Operationen und ACID-Transaktionen (Atomicity, Consistency, Isolation, Durability) werden zum Vorteil der Performance bewusst abgeschnitten.

Ursprünglich wurden jeweils Datenbanken für Management-Analysen (OLAP, Online Analytical Processing) wie geschäftliche Reports und Dashboards sowie für operative Systeme (OLTP, Online Transactional Processing) wie Eingabemasken, Stammdatenverwaltung, Bestellungen, Warenwirtschaft et cetera vorgehalten. Die Daten aus den OLTP-Datenbanken überführte man in der Regel durch nächtliche ETL-Jobs in die OLAP-Systeme. Letztere sind Data Cubes, Data Marts oder Ähnliches und jeweils einer Abteilung zugeordnet. Es besteht hier durchaus die Gefahr, dass Kennzahlen aus gleichen Daten in mehreren Abteilungen unterschiedlich verarbeitet beziehungsweise berechnet werden und dadurch eine unterschiedliche Sicht auf dasselbe Geschäft entsteht.

Plattformen für Data Science

Big-Data-Techniken wie die Hadoop-Distributionen und DSE setzen auf Datenlokalität: Einmal gespeichert bleiben große Datenmengen dort, wo sie sind, und die wesentlich kleineren Algorithmen "kommen zu ihnen". Dadurch entfallen ETL-Jobs samt deren Verzögerungen, und es bilden sich keine Datensilos zwischen den Abteilungen mehr. Es entsteht eine echte "einzige Quelle der Wahrheit" (SSOT, Single Source of Truth).

Daten werden in der DSE, wie im Machine Learning üblich, in denormalisierter Form bereitgestellt und können je Spalte auch gerne Mengen enthalten. NoSQL-Datenbanken wie Cassandra unterstützen keine ACID-Transaktionen, JOIN-Operationen, Referenzen und können damit auch keine referentielle Integrität modellieren. Cassandra unterstützt als System nach dem CAP- oder auch Brewer-Theorem (C: zeilenweise Konsistenz, A: Verfügbarkeit, P: Partitionssicherheit gegen "Split Brain" im Netzwerk) lediglich atomare und bleibende Schreiboperationen. Strenge Konsistenz lässt sich je lesendem beziehungsweise schreibendem Zugriff konfigurieren. Durch die fehlenden ACID-Transaktionen kann man keine Isolation gewährleisten; in Cassandra lediglich auf Zeilen- genauer auf Wide-Row-Basis. Cassandra und andere NoSQL-Datenbanken folgen deswegen dem BASE-System (Basically Available, Soft State, Eventual Consistency).

Schwächen und Stärken der DSE

Die drei großen Schwächen in Cassandra sind fehlende Unterstützung von JOINs, Transaktionen und Referenzen und damit keine referenzielle Integrität. Daraus leitet sich ab, welche Anwendungsfälle schwerfallen. Cassandra ist kein Ersatz für ein generisches RDBMS (relationales Datenbank-Managementsystem). Das gilt vor allem, wenn Denormalisierung nicht gewünscht ist und Transaktionen sich unter Garantie nicht gegenseitig beeinflussen dürfen. Transaktionen lassen sich im Zweifel durch sogenannte leichtgewichtige Transaktionen und Batches  herstellen. Eine Lösung für den durchgehenden Einsatz ist das jedoch nicht.

Eingehende Daten sind im Applikationsframework der DSE, in Spark, einfach möglich, über Applikationsschnittstellen ausgehende Daten – außer durch ODBC/JDBC – gelten generell als Anti-Pattern. Sie sollten gut getestet sein, und möglicherweise muss die Konfiguration daraufhin angepasst werden.

Stärken hat DSE vor allem in der Datenanalyse und bei Anwendungen, die ein hohes Datenvolumen performant annehmen oder ausgeben können müssen. Außerdem punktet sie bei Anwendungen, bei denen Hochverfügbarkeit wichtig ist, und falls eine Hadoop-Installation allein nicht geeignet erscheint sowie Hadoop und Cassandra zusammen betrieben werden sollen. Hadoop allein ist weniger gut geeignet, wenn Latenzwerte gering sein müssen oder die Anzahl der Komponenten klein sein soll. Selbst kleine Hadoop-Installationen haben durch ihre hohe Generalisierungsfähigkeit deutlich mehr Komponenten als die DSE. Besonders stark ist die Distribution in Webanwendungen, die ständig verfügbar, performant und quasi linear skalierbar sein sollen.

Die DSE enthält standardmäßig Cassandra zur Datenhaltung, Spark als Applikationsframework, Sqoop für die ETL-artige Datenverwaltung mit RDBMS sowie die DataStax-Entwicklungen OpsCenter für Administratoren und DevCenter für Entwickler.

Data Lake versus Data Hub

DataStax sieht die DSE vor allem im Einsatz bei Internet-of-Things-Anwendungen und Webapplikationen mit hohem Datenvolumen. Die Idee dahinter ähnelt stark einem Data Lake, in dem Big-Data-Techniken Systeme erweitern. In dem Szenario kommt jede Technik zum Einsatz, wofür sie am besten geeignet ist. Damit bleiben fachliche Prozesse und Datenflüsse bestehen.

Hadoop wird hingegen je nach Hersteller als Data Lake oder Data Hub positioniert. Der Distributor Hortonworks setzt auf den Data Lake; Konkurrent Cloudera auf den Data Hub. In Letzterem ist Hadoop das Drop-in Replacement für die abzulösenden Systeme. Damit übernimmt der Data Hub OLTP- und OLAP-Workloads gleichermaßen und es entsteht eine HTAP-Anwendung (Hybrid Transactional/Analytical Processing) nach Gartner respektive eine Lambda-Architektur nach Twitter. Diese Innovation bricht mit etablierten Techniken und wird daher disruptiv genannt. Fachliche Prozesse werden damit in jedem Fall geändert. Eine solche Lambda-Architektur muss in der Lage sein, Daten in Batch-Form zu verarbeiten sowie in naher Echtzeit dem Request/Response-Pattern folgen.

Ist der Wettbewerb von Hadoop-Herstellern und DataStax um Marktanteile ein Kampf wie David gegen Goliath? Es gleicht eher dem Kampf David gegen David gegen Goliath, wobei Letztere die Hersteller etablierter Datenbanken sind. Hadoop-Distributionen und DSE leiden damit unter einer "Folie à Deux": Ihre Entwicklung ist jeweils stark an denselben Markt gekoppelt. Also gehen sie durch diese moderierende Variable beide entweder auf- oder abwärts.

Wie mit der Innovation umgehen?

Alle Hadoop-Distributoren, aber auch DataStax sind amerikanische Unternehmen und jeweils vor allem durch dort einheimische Kapitalgeber gesichert. Ihre Produkte finden derzeit ihre jeweiligen Nischen oder versuchen sie erfolgreich zu besetzen. Eine bekannte Theorie aus dem Innovationsmanagement nach Clayton Christensens "The Innovator's Dilemma" besagt, dass der Vorstoß in höher-qualitative Marktsegmente ohne Beschränkung der Allgemeinheit möglich ist [1]. Nach dem sogenannten Einrastprinzip ist der Weg lediglich in breitere Marktsegmente schwierig, da sich die Gewinnambitionen großer Anbieter hier nicht mehr ausreichend decken lassen. Nach dieser Theorie werden Big-Data-Hersteller nach wie vor das Gros ihrer Gewinne bei großen Konzernen verdienen.

Sowohl Cloudera als auch DataStax sind mit circa 500 Mitarbeitern in einer schlagkräftigen und organisch gewachsenen Größe verglichen mit dem weltweiten Big-Data-Markt. Hortonworks ist mit circa 750 Mitarbeitern noch etwas größer, aber ebenfalls in gesundem Maße aufgestellt – im Gegensatz zur Beobachtung, dass die Anzahl an Experten eines der wesentlichen Flaschenhälse im Big-Data- und Data-Science-Markt ist.

Einfachheit ist für mögliche Nutzer ein wichtiges Akzeptanzkriterium. Die DSE ist mit gut integrierten Tools und Cassandra als performantem Speicher für gleichermaßen OLTP- und OLAP-Workloads ein exemplarisches Analysesystem. Hadoop zeigte hier vor allem auf älteren Versionen von Hive noch Schwächen bei interaktiven Queries. Das initiale Job-Setup der Anfrage nimmt gerne den Großteil der "Rechenzeit" in Anspruch. Auf DSE sind diese Latenzen durch die Verwendung von Spark gering, und der Datenzugriff ist dank Cassandra ebenso schnell.

Lediglich das Cassandra-Datenschema ist nicht besonders flexibel gegenüber Änderungen der Zugriffe auf Daten. Zudem sind in Hadoop Komponenten enthalten oder werden derzeit integriert, die Anwender der DSE teilweise vermissen werden – beispielsweise Datenflusssysteme wie NiFi oder Samza, Message Queues à la Kafka, Workflow Scheduler wie Oozie oder ein Applikations-Layer wie YARN (Yet Another Resource Negotiator).

Wer ein komplexes System mit vielen Freiheiten nicht scheut, wählt gerne Hadoop. Für YARN gibt es Frameworks wie Cascading, Tez und Twill, die die Komplexität der Entwicklung reduzieren. Applikationen wären ansonsten ein Großteil Boilerplate-Code, oder bereits ein "Hello World" wäre kaum überschaubar.

Die DSE erweitert und entlastet oft RDBMS-Systeme. Ein Beispiel hierfür ist die Computerspielreihe Call of Duty, die vor allem durch ihr Cassandra-Backend ein Nahechtzeiterlebnis liefern kann. Außerdem haben Macy's und Metro ihre Warenwirtschaftssysteme auf Cassandra gebaut. Banken wie Credit Suisse, ING-DiBa und UBS vertrauen DSE ihre Kundendaten an. eBay analysiert mit ihr zusammen mit einem Hadoop-Cluster Zugriffsmuster auf Betrug.

Aufstieg des Phönix

Die Etablierung von Big-Data-Techniken am Markt ist ein Henne-Ei-Problem, und neue Techniken bergen immer ein gewisses Risiko, selbst wenn DataStax die gewohnte Apache-Qualität um Enterprise-Support, Wartungsfenster von bis circa 18 Monaten und Bugfixes erweitert.

DataStax Enterprise besticht neben durchgehender Verfügbarkeit, Performance und quasi linearer Skalierbarkeit durch ein hohes Datensicherheitsniveau auch ohne die Verwendung von Kerberos und eines schlanken Datenanalyse-Stacks. Durchgehende Verfügbarkeit bezeichnet Hochverfügbarkeit mit beliebig vielen Neunen (in Prozent) – also wenige Minuten Ausfallzeit pro Jahr und weniger.

Auf der einen Seite könnte man die DSE ohne Cassandra als echte Untermenge einer generellen Hadoop-Distribution erachten; HBase würde in Hadoop an Cassandras Stelle treten. Damit wäre die DSE die Strategie der Wahl, wenn man mit größerer Komplexität leben wollte. Der Gewinn wäre mehr Flexibilität auf Kosten einer komplexen, stark gekoppelten Architektur. Hadoop wird als General-Purpose-Computing-Plattform in der Regel mehr Flexibilität mitbringen und generisch besser auf zukünftige, unbekannte Anforderungen passen. Auf der anderen Seite kann eben dieser schlanke Stack der DSE ein wesentlicher Vorteil auf dem Weg sein, ein datengetriebenes Unternehmen zu werden.

Fazit

Hadoop gilt heute als Paradebeispiel für Big Data, das die Medien bevorzugt thematisieren. Die DSE wird seltener erwähnt – trotz der besseren Positionierung unter anderem durch Gartner. Die DSE ist ein "Minimum Viable Product" für Data Science und sichert einfachen Betrieb auf hohemDatenschutzniveau. Sie zeichnet sich vor allem durch durchgehende Verfügbarkeit, gute Performance und Skalierbarkeit aus.

Daniel Schulz
ist Senior Solution Architect bei Capgemini. Er arbeitet seit fünf Jahren im Big-Data-Bereich mit besonderem Fokus auf der Automotive-Branche. Er interessiert sich seit seiner Schulzeit für Statistik, seit dem Studium auch für Machine Learning und dessen Einsatz in der Datenanalyse.

Literatur

1. Clayton Christensen, Stephan Friedrich von den Eichen, Kurt Matzler; The Innovator's Dilemma – Warum etablierte Unternehmen den Wettbewerb um bahnbrechende Innovationen verlieren; Vahlen 2015

(ane)