Hadoop-Kurzschluss-Lesevorgänge und Datenbankleistung

Wenn Sie mit Hadoop gearbeitet haben, sind Sie wahrscheinlich schon auf das Konzept der Short Circuit Reads (SCRs) gestoßen und wissen, wie sie die Leistung verbessern können. Heutzutage sind sie meist standardmäßig aktiviert (wenn auch nicht in "Vanilla" Apache oder ähnlichen Derivaten wie Amazon EMR).

Actian VectorH bringt Hochleistungs-SQL, ACID-Konformität und Unternehmenssicherheit in Hadoop, und ich wollte testen, wie wichtig SCRs für die beobachtete Leistung sind oder nicht.

Die erste Herausforderung, die sich mir stellte, war herauszufinden, was genau vorhanden ist und was veraltet ist. Dies ist bei der Arbeit mit Hadoop keine Seltenheit - manchmal liefert die normalerweise sehr hilfreiche "Google-Suche" eine Menge widersprüchlicher Informationen, die nicht alle mit einem praktischen Datum versehen sind, um die Relevanz des Materials zu beurteilen. Im Fall der SCRs ist die anfängliche Verwirrung hauptsächlich darauf zurückzuführen, dass es zwei Implementierungsmethoden gibt: die ältere Methode, die direkten Zugriff auf die HDFS-Blöcke gewährt - was zwar zu Leistungssteigerungen führt, aber eine Sicherheitslücke öffnet - und die neuere Methode, die einen Memory-Socket verwendet und damit die Kontrolle über den DataNode behält.

Beachten Sie, dass ich für diesen Eintrag MapR von der Diskussion ausschließe. Soweit ich weiß, implementiert MapR sein Äquivalent von SCRs automatisch und erfordert keine Konfiguration (bitte lassen Sie mich wissen, wenn das nicht der Fall ist).

Bei der neueren Methode ist das Einzige, was benötigt wird, damit SCRs funktionieren, eine gültige native Bibliothek, die Eigenschaft dfs.client.read.shortcircuit, die auf true gesetzt ist, und die Eigenschaft dfs.domain.socket.path, die auf etwas gesetzt ist, auf das sowohl der Client als auch der DataNode zugreifen können. *Es gibt noch weitere Einstellungen, die sich auf die Leistung von SCRs auswirken, aber dieser Eintrag untersucht diese nicht.

Auf meinem Cluster erhalte ich standardmäßig Folgendes:

# hadoop checknative -a
16/03/09 12:21:41 INFO bzip2.Bzip2Factory: Erfolgreich geladen & initialisiert ...
16/03/09 12:21:41 INFO zlib.ZlibFactory: Erfolgreich geladen und initialisiert ...
hadoop: true /usr/hdp/2.3.2.0-2950/hadoop/lib/native/libhadoop.so.1.0.0
zlib: wahr /lib64/libz.so.1
snappy: wahr /usr/hdp/2.3.2.0-2950/hadoop/lib/native/libsnappy.so.1
lz4: wahr Revision:99
bzip2: wahr /lib64/libbz2.so.1
openssl: false libcrypto.so kann nicht geladen werden (libcrypto.so: kann freigegebene ...

# hdfs getconf -confkey dfs.client.read.shortcircuit
true
# hdfs getconf -confkey dfs.domain.socket.path
var

Für die Tests selbst habe ich einen unserer demo verwendet. Dieser hat 5 Knoten (1 NameNode und 4 DataNodes), auf denen in diesem Fall HDP 2.2 auf RHEL 6.5 läuft. Bei den DataNodes handelt es sich um HP DL380 G7s mit 2 x 6 Kernen @2.8Ghz, 288GB RAM, 1x 10GbE Netzwerkkarte und 16x300GB SFF SAS Laufwerke (also eine vernünftige Spezifikation von 2012, aber weit entfernt vom heutigen "Stand der Technik").

Bei den Daten für den Test handelt es sich um ein Star-Schema mit etwa 25 Dimensionstabellen mit einer Größe von 100 bis 50 Millionen Zeilen und einer einzigen Faktentabelle mit 8 Milliarden Zeilen.

Die Abfragen in der demo verbinden zwei oder mehr der Dimensionstabellen mit der Faktentabelle und filtern nach einem Datumsbereich zusammen mit anderen Prädikaten.

Hier stoße ich auf meine zweite Herausforderung - die meisten der in der demo verwendeten Abfragen laufen in Sekundenbruchteilen ab, so dass es kaum Möglichkeiten gibt, die Wirkung von SCRs zu messen. Zum Beispiel läuft die folgende Anfrage in 0,3 Sekunden gegen 8 Milliarden Zeilen (jedes Datum zielt auf etwa 80 Millionen Zeilen):
[sql]
select
d1.DateLabel, d2.MeasureLabel, sum(f.MeasureValue)
von
Fakt f
,Datum_Dim d1
,Measure_Dim d2
wo
f.DateId = d1.DateId
und d2.MeasureId = f.MeasureId
und d1.DateLabel in ('05-Feb-2015′)
gruppieren nach
d1.DateLabel
,d2.MeasureLabel
[/sql]
Um die Vorteile von SCRs zu beobachten, habe ich eine Anfrage erstellt, die alle 8 Milliarden Zeilen gegen alle Zeilen beider Dimensionstabellen aggregiert (d. h. das Prädikat "und d1.DateLabel in (...)" entfernt). Dies erzeugt eine Ergebnismenge von Zehntausenden von Zeilen, aber das verzerrt die Ergebniszeit nicht genug, um den Test ungültig zu machen.

Um sicherzustellen, dass alle Daten vom DataNode gelesen werden, wurde Actian VectorH neu gestartet, bevor die Anfrage ausgeführt wurde. Der Cache des Linux-Dateisystems wurde unverändert belassen, um nicht zu stören, was der DataNode intern mit Datei-Handles usw. tun könnte.

Bewaffnet mit dieser neuen Anfrage führte ich meine ersten Tests durch, bei denen ich den Unterschied mit und ohne SCRs verglich und keinen Unterschied feststellte - Huh! Bei näherer Betrachtung stellte ich fest, dass VectorH das Netzwerk sehr effizient nutzte, so dass das Fehlen der SCRs keinen Einfluss auf die Lesezeiten hatte. Also simulierte ich eine gewisse Netzwerklast mit scp und sendete Daten zwischen den verschiedenen Knoten, während die Abfragen liefen. Unter diesen Bedingungen hatten die SCRs einen positiven Einfluss von etwa 10 %.

Zusammenfassend lässt sich sagen, dass SCRs bei einer guten Netzwerkeinrichtung und einer Software, die diese gut nutzt, keinen Nutzen bringen. Wenn das Netz jedoch einigermaßen ausgelastet ist, dann werden SCRs wahrscheinlich helfen. Der hier gemessene Unterschied betrug etwa 10 %.

Über Actian Corporation

Actian macht Daten einfach. Unsere Datenplattform vereinfacht die Verbindung, Verwaltung und Analyse von Daten in Cloud-, Hybrid- und lokalen Umgebungen. Mit jahrzehntelanger Erfahrung in den Bereichen Datenmanagement und -analyse liefert Actian leistungsstarke Lösungen, die es Unternehmen ermöglichen, datengesteuerte Entscheidungen zu treffen. Actian wird von führenden Analysten anerkannt und wurde für seine Leistung und Innovation mit Branchenpreisen ausgezeichnet. Unsere Teams präsentieren bewährte Anwendungsfälle auf Konferenzen (z. B. Strata Data) und tragen zu Open-Source-Projekten bei. Im ActianBlog behandeln wir Themen wie Echtzeit-Dateneingabe, Datenanalyse, Data Governance, Datenmanagement, Datenqualität, Datenintelligenz und KI-gesteuerte Analysen.