Hadoop mit Apache Cassandra verwenden

Hadoop mit Apache Cassandra verwenden

  • Orchestrierung
6 Minuten Lesezeit Aktualisiert Apr 25, 2017

Auf einen Blick: Der Einsatz von Hadoop mit Apache Cassandra untersucht die Integration dieser Technologien für effiziente Big-Data-Verarbeitung und hebt Cassandras Architektur hervor, die Skalierbarkeit und schnelle Datenabrufe ohne traditionelle Normalisierung ermöglicht.

  • Cassandra ist eine NoSQL-Datenbank, die für hohe Verfügbarkeit und Geschwindigkeit entwickelt wurde.
  • Die Daten werden in einer abgeflachten Struktur gespeichert, wobei der Fokus auf Leistung statt auf Normalisierung liegt.

Überblick über Kassandra

Cassandra ist eine NoSQL-Open-Source-Datenbank. Sie wurde von Facebook entwickelt, um deren besonderen Anforderungen an die Verarbeitung enormer Datenmengen zu erfüllen.

Zu sagen, dass es sich um NoSQL handelt, bedeutet nicht, dass es unstrukturiert ist. Die Daten in Cassandra werden in den vertrauten Zeilen-und-Spalten-Datensätzen als reguläre SQL-Datenbank gespeichert. Aber es gibt keine Beziehungen zwischen den Tabellen. Und man kann in Cassandra Daten mit CQL (Cassandra Query Language) abfragen und schreiben, das dem regulären SQL sehr ähnlich ist.

Aber nur weil es SQL unterstützt, heißt das nicht, dass man alle SQL-Operationen darauf ausführen kann. Insbesondere gibt es keine JOIN- oder GROUP-Operationen oder irgendetwas, das eine Erweiterung der Festplattensuche und -berechnung erfordern würde. Stattdessen soll man die Daten in Cassandra genauso speichern, wie man sie präsentiert haben möchte. Dieser Wandel in der Denkweise ist eine komplette 180-Grad-Kehrtwende gegenüber dem, was viele über RDBMS (relationale Datenbankmanagementsysteme) gelernt haben.

play

 

Nicht-Normal

Um zu veranschaulichen, was wir meinen, müssen wir diskutieren, was es bedeutet, Daten zu normalisieren. Daten in Cassandra sollen nicht normal und abgeflacht sein. Lassen Sie uns das veranschaulichen. Angenommen, wir haben diese Studentendaten:

Schülernummer Name Stadt Zustand Postleitzahl

Jemand, der eine Oracle-Datenbank entwirft, würde daraus zwei Tabellen machen:

Schülernummer Name Postleitzahl
Postleitzahl Zustand Stadt

Das gemeinsame Element zwischen den beiden Tabellen ist die Postleitzahl. Denn wenn man die Postleitzahl kennt, in der jemand wohnt, kennt man die Stadt und den Bundesstaat. Warum sollte man diese Daten also in jeder einzelnen Zeile wiederholen? Das tut man nicht. Man macht die Daten normal. Aber nicht bei Cassandra. Cassandra ist nicht darauf bedacht, viel Speicherplatz zu verbrauchen, was einer der Gründe ist, warum man keine Normalisierung macht. (Dennoch reduziert sein Kompressionsalgorithmus den Speicher um 80 %.) Stattdessen geht es bei Cassandra ganz um Geschwindigkeit und Skalierbarkeit.

Architektur

Es gibt keinen zentralen Hub oder eine Master-Slave-Topologie bei Cassandra. Stattdessen ist es als Ring von Knoten konzipiert, wobei jeder Knoten die gleiche Rolle hat. Die Knoten kommunizieren miteinander in dem, was man Klatsch nennt. Knoten können bei Bedarf hinzugefügt und entfernt werden. Der Benutzer stellt das Replikationsniveau so ein, wie viele zusätzliche Datenkopien zur Redundanz gespeichert werden müssen. Was Cassandra von einem regulären RDBMS unterscheidet, ist, dass man beachten muss, wie es Daten physisch speichert und sortiert, um sie richtig zu nutzen und vollständig zu verstehen. Das bedeutet, CommitLog, Memtable, SSTable, Partitions und Nodes zu verstehen. Um eine Analogie zu verwenden: Denken Sie daran, wie Wellen am Strand an Land kommen. Eine große Welle kommt herein, gefolgt von mehreren kleineren. Dann kommt eine riesige Welle an Land und verschiebt alles. Man kann sich die Wellen als Cassandra-Speicher und den Strandsand als Cassandras permanenten Festplattenspeicher vorstellen. Cassandra ist, wie Hadoop, darauf ausgelegt, kostengünstige Commodity-Speicher zu nutzen, um eine verteilte Architektur zu liefern. Das bedeutet, die Festplatten zu verwenden, die an die virtuellen und physischen Maschinen im Rechenzentrum angeschlossen sind, anstelle eines Speicherarrays. Cassandra-Daten werden als SSTable im Speicher gespeichert. Schreibvorgänge werden zuerst in ein CommitLog geschrieben, damit es festhalten kann, welche Änderungen es vornehmen muss. Die Schreibvorgänge werden in Strukturen namens Memtable zwischengespeichert. Dieser Cache wächst, bis er wie eine Welle an Land stürzt, während Cassandra seine Änderungen auf der Festplatte festlegt. Die tatsächlichen Schreibvorgänge sind also relativ langsam, lesen aber extrem schnell. Mehrere dieser Memtables werden zu jedem Zeitpunkt hochgehalten. Die Struktur des zugrundeliegenden physischen SSTable unterscheidet sich also zu jedem Zeitpunkt von der Memtables. Das SSTable wird in Wellen geschrieben, genauso wie Linux Seiten Speicher auf Festplatte schreibt, wenn die Swap-Datei voll ist. Das unterscheidet sich von einem regulären RDBMS, das eine Tabelle jedes Mal aktualisiert, wenn ein INSERT oder eine andere Operation durchgeführt wird.

Partitionen und Knoten

Stellen Sie sich nun einen Primärschlüssel in einer Datenbanktabelle vor. Der Primärschlüssel ist ein eindeutiger Wert, der aus einem oder mehreren Feldern stammt. In Cassandra bezeichnet das erste dieser Felder den Partitionsschlüssel. Die anderen Felder im Primärschlüssel zeigen an, wie die Daten innerhalb dieser Partition sortiert sind. Partitionen zeigen an, wo Daten physisch gespeichert sind (also der Knoten). Zum Beispiel könnten Sie folgende Daten haben:

Primärschlüssel

Fahrzeug-ID Mach
1 Ford
2 Ford
3 Chevrolet
4 Chevrolet
5 Chevrolet

Die Fahrzeug-ID ist der Partitionsschlüssel. Make ist eine Cluster-Spalte. Das macht die Datenabfrage sehr effizient, wenn alle Ford-Fahrzeuge nebeneinander gespeichert werden, während sie so sortiert sind. In diesem Beispiel ist die Fahrzeug-ID eindeutig, daher ist nicht klar, wie dieser Speichermechanismus zur Effizienz beiträgt. Aber bedenken Sie, dass Sie einen zusammengesetzten Partitionsschlüssel haben können. Angenommen, die Fahrzeug-ID ist tatsächlich die Fabrik, in der das Fahrzeug hergestellt wurde, plus eine Nummer. Wir würden also alle diese Fahrzeuge im selben Werk herstellen und in derselben Farbe lackieren, dicht beieinander speichern, um die Abrufe zu beschleunigen:

Anlage Fahrzeug-ID Farbe
Mexiko 1 Rot
Mexiko 1 Rot
USA 1 Blau

Nun machen wir praktische Arbeit mit Cassandra, um diese Konzepte weiter zu veranschaulichen. Zuerst installieren wir die Software.

Installation

Hier ist die Installation auf CentOS. Ein Punkt ist, dass Cassandra auf der Cassandra-Website ihre Software als Download bereitstellt und sie an Ubuntu-Repositories verteilt, aber nicht für Yum. Datastax macht das also. Hinweis: Das private Unternehmen Datastax hat den Großteil der Dokumentation für Cassandra im Internet geschrieben. Früher haben sie ihre eigene Distribution von Cassandra erstellt, machen das aber nicht mehr. Jetzt muss jemand in die Leere treten und die Dokumentation fertigstellen, denn die offizielle Cassandra-Dokumentation enthält viele To-Do-Kommentare, in denen steht, welche Seiten sie erledigen müssen. Tatsächlich suchen sie sogar nach Personen, die bei der Fertigstellung der Dokumentation helfen möchten. Verwenden Sie also vorerst die Datastax-Dokumentation. Erstellen Sie zunächst eine Repo-Datei mit folgendem Inhalt:

    cat /etc/yum.repos.d/datastax.repo

name = DataStax Repo for Apache Cassandra
baseurl = http://rpm.datastax.com/community
enabled = 1
gpgcheck = 0

Dann installieren Sie diese beiden Elemente:

    yum install dsc30
yum install cassandra30-tools

Öffne jetzt die Cassandra-Schale:

    cqlsh
 
Connected to Test Cluster at 127.0.0.1:9042.

Use HELP for help.
cqlsh>

Jetzt erstellen wir eine Tabelle und legen einige Daten ein.

KeySpace

Das erste Objekt, das erstellt wird, ist ein KeySpace. Dies ist ein Container zur Replikation. Hier erstellen wir einen KeySpace namens Library, da wir eine Tabelle erstellen, um nachzuverfolgen, welche Bücher eine Person in unserem kleinen Beispiel aus der Bibliothek ausgeliehen hat. Die Klasse und replication_factor bestimmen , wie Daten repliziert werden. Dafür gibt es viele Möglichkeiten, ebenso wie für die Partitionsverteilung. Hier sagen wir, dass man von jedem Datensatz 3 Kopien machen soll.

    CREATE KEYSPACE Library
      WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };

Tabellen

Jetzt erstellen wir zwei Tabellen: Buch und Patron.

    CREATE TABLE Library.book (       
ISBN text, 
copy int, 
title text,  
PRIMARY KEY (ISBN, copy)
 );

CREATE TABLE  Library.patron (      
ssn int PRIMARY KEY,  
checkedOut set  
);

Hier sind einige Punkte zu beachten:

  • Wir verwenden die Feldtypen text und int. Cassandra hat die üblichen Spaltentypen und erlaubt benutzerdefinierte Spaltentypen.
  • Die erste Tabelle hat 2 Felder im Primärschlüssel. Die zweite Tabelle hat 1.
  • Die zweite Tabelle hat eine Mengmenge-Spalte. Eine Menge ist eine Sammlung eindeutiger Elemente, wie {1,2,3}. Cassandra unterstützt außerdem eine Liste, deren Elemente nicht eindeutig sein müssen, wie {1,2,2,3} und eine Abbildung, bei der der Schlüssel eindeutig sein muss, wie {key->value}.
  • Abgesehen davon sieht die Syntax genau wie normales Oracle SQL aus.

Daten hinzufügen

Fügen wir ein paar Daten hinzu. Die Befehle sehen genau wie reguläres SQL aus. Der Tabellenname wird vom Keyspace vorangestellt, genau wie in einer regulären SQL-Datenbank wird die Tabelle als database.table bezeichnet.

    INSERT INTO  Library.book (ISBN, copy, title) VALUES('1234',1, 'Bible');
INSERT INTO  Library.book (ISBN, copy, title) VALUES('1234',2, 'Bible');
INSERT INTO  Library.book (ISBN, copy, title) VALUES('1234',3, 'Bible');
INSERT INTO  Library.book (ISBN, copy, title) VALUES('5678',1, 'Koran');
INSERT INTO  Library.book (ISBN, copy, title) VALUES('5678',2, 'Koran');

Listen Sie nun die Werte auf:

    select * from Library.book;
 

 isbn | copy | title
------+------+-------
 5678 |    1 | Koran
 5678 |    2 | Koran
 1234 |    1 | Bible
 1234 |    2 | Bible
 1234 |    3 | Bible

Als Nächstes fügen wir Daten zur Benutzertabelle hinzu. Die Bücher, die der Bibliotheksnutzer ausgeliehen hat, sind eine Menge: {'1234','5678'}. In einer normalisierten Datenbank würden die Bücher und der Bibliotheksnutzer in getrennten Tabellen gespeichert. Hier flachen wir jedoch alles in eine Struktur ab, um SQL-JOIN und andere Operationen, die Zeit in Anspruch nehmen würden, zu vermeiden. Auch wenn wir Details zu den Büchern in die Buchtabelle einfügen, hätten wir auch Titel, Seitenanzahl usw. hinzufügen können, wie in der Patronentabelle, vielleicht in einem Tupel oder einer anderen Datenstruktur. Auch das ist das genaue Gegenteil von dem, was Programmierern traditionell beigebracht wird, wenn sie Datenbanktabellen entwerfen. Füge also einige Daten hinzu und drucke sie aus:

    INSERT INTO Library.patron (ssn, checkedOut) values (123,{'1234','5678'});
cqlsh> select * from Library.patron;
 

 ssn | checkedout
-----+------------------
 123 | {'1234', '5678'}

 INSERT INTO Library.patron (ssn, checkedOut) values (123,{‘1234’,’5678’});

Bei Cassandra geht es ganz um die Performance. Sie können also keine Felder in der Sammlungsspalte abfragen, ohne vorher einen Index zu erstellen:

    create index on Library.patron (checkedOut);

Jetzt können wir zeigen, welche Nutzer Buchnummer 1234 mit einer Abfrage ausleihen haben. Beachten Sie, dass wir den Operatoren contains verwenden.

    select ssn from Library.patron where checkedOut contains '1234';
 
 ssn
-----
 123

Dies ist ein Überblick über Cassandra, um dir den Einstieg zu erleichtern. Jetzt solltest du vielleicht einige der APIs untersuchen, da es Cassandra-APIs für viele Programmiersprachen gibt. Außerdem könntest du Anwendungsfälle lesen, denn da es jetzt so viele Big-Data-Datenbanken gibt, wäre es hilfreich zu sehen, welche Art Leute in welcher Situation verwendet haben.

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.

Mehr aus Orchestrierung

Abonnieren Sie The Brief

Mit der Registrierung für dieses Angebot bestätigen Sie, dass Sie die Datenschutzrichtlinie von BMC gelesen und zugestimmt haben.

Danke

Sie haben The Brief abonniert
Das Briefing umfasst die Mainframe- und Enterprise-Orchestrierung – BMC AMI und Control-M – sowie die Analystenforschung, Kundeneinsätze und Events in beiden Bereichen.