Big Data Processing Engines – Welche verwende ich?:Teil 1

Dieser Blogbeitrag wurde vor der Fusion mit Cloudera auf Hortonworks.com veröffentlicht. Einige Links, Ressourcen oder Referenzen sind möglicherweise nicht mehr korrekt.

Besonderer Dank geht an Bill Preachuk und Brandon Wilson für die Überprüfung und Bereitstellung ihres Fachwissens

Einführung

Columnar Storage ist heute ein oft diskutiertes Thema in der Welt der Big-Data-Verarbeitung und -Speicherung – es gibt Hunderte von Formaten, Strukturen und Optimierungen, in denen Sie Ihre Daten speichern können, und noch mehr Möglichkeiten, sie abzurufen, je nachdem, was Sie vorhaben damit. Diese Fülle von Optionen entstand aufgrund der Notwendigkeit, Daten nicht nur schnell mit Tools für die Online-Transaktionsverarbeitung (OLTP) aufzunehmen, sondern auch aufgrund der Notwendigkeit, Daten mit größerer Effizienz mithilfe von On-Line Analytical Processing (OLAP) zu konsumieren und zu analysieren. Werkzeug. Tausende von verschiedenen Anwendungsfällen haben jeweils ihre eigenen spezifischen Anforderungen und daher sind viele Optionen aufgetaucht. Beispielsweise erfordert das Lesen von Börsentickerdaten eine völlig andere Denkweise als die Analyse von Qualitätskennzahlen in einer Fertigungslinie. Bei all diesen Möglichkeiten kann man sich leicht verirren, wenn man zu seinem Endziel navigiert:der Auswahl eines Tools, das für einen funktioniert.

HDP umfasst eine Reihe von Speicherlösungen, von denen jede für bestimmte Anwendungsfälle maßgeschneidert ist. Wir möchten diese Blog-Serie beginnen, indem wir über die folgenden drei Tools/Engines und ihre zugehörigen Speicherformate sprechen:

• Apache Hive verwendet Apache ORC als effizientes spaltenorientiertes Speicherformat, das Leistung sowohl für die OLAP- als auch für die Deep-SQL-Abfrageverarbeitung ermöglicht
• Apache Phoenix/Apache HBase bilden zusammen eine OLTP-Datenbank, die Echtzeitabfragen über Milliarden von Datensätzen ermöglicht und schnelle zufällige schlüsselbasierte Suchen sowie Aktualisierungen bietet
• Apache Druid ist ein Hochleistungs-Datenspeicher, der Echtzeit-Zeitreihenanalysen von Ereignisströmen und OLAP-Analysen historischer Daten mit extrem geringer Latenzzeit ermöglicht

In diesem Artikel möchten wir darlegen, welches Tool für einen bestimmten Anwendungsfall geeignet ist, die verschiedenen Tools vergleichen und gegenüberstellen und eine grundlegende Richtlinie für die Auswahl des geeigneten Tools oder einer Reihe von Tools für Ihren Anwendungsfall bereitstellen.

Das ist ähnlich wie Tetris zu spielen – jedes Stück hat eine andere Nische, aber jedes fügt der größeren Struktur einen einzigartigen Wert hinzu

Big Data-Verarbeitung und ihre Ähnlichkeiten

Daten werden im Speicher nach Spalten gruppiert, da wir häufig versuchen, Summen, Durchschnittswerte oder andere Berechnungen auf eine bestimmte Spalte einzugrenzen. Stellen Sie sich vor, Sie sind eine Fluggesellschaft, die versucht zu verstehen, wie viel Treibstoff einem Flugzeug gegeben werden muss, wenn es angedockt ist – Sie möchten vielleicht die durchschnittlich geflogenen Meilen jedes Fluges aus einer Tabelle mit Flugreisedaten berechnen. Dies würde erfordern, dass die Durchschnittsfunktion für eine einzelne Spalte ausgeführt wird. Wir würden diese Daten im Spaltenformat speichern, da sequentielle Lesevorgänge auf der Festplatte schnell sind, und was wir in diesem Fall tun möchten, ist eine vollständige Spalte aus der Tabelle sequentiell zu lesen (und dann eine Durchschnittsberechnung durchzuführen).

Es gibt viele Unterschiede zwischen diesen Engines, aber unabhängig davon, für welche Datenverarbeitungs-Engine Sie sich entscheiden, werden Sie von einigen Gemeinsamkeiten profitieren. Eine davon ist die gemeinsame Funktion des Cachings. Jede dieser drei Engines arbeitet Hand in Hand mit In-Memory-Caching, um die Verarbeitungsleistung zu steigern, ohne das Backend-Speicherformat zu ändern, und Reaktionszeiten von unter einer Sekunde zu erreichen. HBase hat den BlockCache, Hive hat die LLAP-IO-Schicht und Druid hat mehrere In-Memory-Caching-Optionen. Der kostspielige Teil der Bearbeitung einer Abfrage besteht häufig darin, die Anforderung zu parsen und in den dauerhaften Speicher zu wechseln, um die Teilmenge der Daten abzurufen, an denen der Benutzer interessiert ist. Dieser gesamte Schritt kann jedoch vermieden werden, wenn ein In-Memory-Caching-Mechanismus mit vielen spaltenorientierten Speicherformaten verwendet wird verwenden, wodurch der Prozess in Sekundenbruchteilen in den Speicher für zuvor abgefragte Daten gelangen kann. Kommen wir zurück zu unserem Treibstoffberechnungsbeispiel:Angenommen, ich habe gerade nach den durchschnittlich geflogenen Meilen für alle Flüge in meinem Unternehmen gefragt, aber mir ist klar, dass Inlandsflüge ganz andere Treibstoffanforderungen haben als internationale Flüge. Ich möchte dann meine vorherige Abfrage mit einer Klausel WHERE country='US' (oder einem entsprechenden Ländercode) filtern. Dieses Abfragemuster ist für die Datenexploration sehr verbreitet. Da wir die Daten der vorherigen Abfrage bereits im Speicher haben, können die Ergebnisse dieser Abfrage zurückgegeben werden, ohne dass ein teurer Datenträgerlesevorgang durchgeführt werden muss.

Die Struktur der LLAP-Schicht von Hive – ein Teil ihres Speicherplatzes wird für das Caching verwendet, während die Langzeitspeicherung auf HDFS erfolgt. HBase und Druid haben auch ein ähnliches Cache- und Speicherkonzept.

Eine weitere Ähnlichkeit besteht in den Abkürzungen, die jede dieser Engines verwendet, um sich auf die spezifischen Daten zu konzentrieren, die abgefragt werden. HBase verfügt über HashMap-basierten O(1)-Direktzugriff, Druid verwendet invertierte Bitmap-Indizes, um herauszufinden, welche Spaltenwerte sich in welchen Zeilen befinden, und Hive-Tabellen verfügen über Statistiken, Indizes und Partitionierungen, um den Datenzugriff zu verkürzen. Diese Funktionen ermöglichen es den Engines, die Art und Weise, wie Daten gespeichert werden, mit der Art und Weise, wie auf sie zugegriffen wird, zu kombinieren, wodurch schnelle Analysen ermöglicht werden, während gleichzeitig die Effizienz der Hardware optimiert und die verfügbare CPU und der verfügbare RAM optimal genutzt werden.

Die letzte Gemeinsamkeit ist die Unternehmenstauglichkeit jeder dieser Engines. Auf der Seite der Datenredundanz verwenden alle drei Engines HDFS als Deep-Storage-Mechanismus; Der HDFS-Replikationsfaktor von 3x stellt sicher, dass Kopien der Daten an anderer Stelle vorhanden sind, selbst wenn zwei Knoten gleichzeitig ausfallen. Die Daten können sofort erneut auf fehlerfreie Knoten repliziert werden, um die Redundanz aufrechtzuerhalten. Beim Thema Fehlertoleranz innerhalb eines Clusters füllt jedes Tool in irgendeiner Weise die Lücke. HBase bietet Regionsreplikation, Druid hat die Duplizierung von Master- und Worker-Komponenten sowie einen erhöhten Replikationsfaktor auf HDFS, und Hive hat HDFS neben der fehlertoleranten Logik des YARN-Frameworks. Enterprise Readiness stellt sicher, dass diese Engines ausfallsicher und vom ersten Tag an in der Produktion einsatzbereit sind.

Die Unterschiede zwischen unseren Big-Data-Verarbeitungsmaschinen

Wie nimmt man Daten am besten auf? Wie können Sie nach der Aufnahme Ihrer Daten schnell Erkenntnisse daraus ziehen? Sehen wir uns an, wie diese drei großen Datenverarbeitungs-Engines diese Reihe von Datenverarbeitungsaufgaben unterstützen

Diese Engines werden aufgrund ihrer Fähigkeit, Big Data sowohl zu speichern als auch zu verarbeiten, manchmal gedanklich gebündelt und ähnlich betrachtet, aber wie wir herausfinden werden, werden sie für Anwendungsfälle und Zwecke ausgewählt, die speziell zu ihren Stärken passen. Sie werden sehen, dass die Sammlung von Tools, die die Hortonworks Data Platform enthält, gut für jede Big-Data-Workload geeignet ist, die Sie darauf werfen können, insbesondere mit HDP 3.0 und den von uns eingeführten Echtzeit-Datenbankfunktionen.

Hive ist die OLAP-Engine, die für die breiteste Palette von Anwendungsfällen repräsentativ ist, wobei am häufigsten das Hadoop Distributed File System (HDFS) als Speicherschicht verwendet wird, um die Speicherung nahezu aller Arten von Daten zu ermöglichen. Es kann unstrukturierte Textdaten, CSV-Dateien, XML, halbstrukturiertes JSON, spaltenförmiges Parquet und eine Vielzahl anderer Formate abfragen, verarbeiten und analysieren. Hive unterstützt auch alternative Speichermedien wie Cloud-Speicher, Isilon und andere. Der De-facto-Speicherstandard für Hive ist ORC, der am effizientesten optimiert und die Vorteile der Spaltenspeicherung nutzt. Nach der Konvertierung in ORC werden Ihre Daten komprimiert und die Spalten in Ihrer Tabelle werden sequenziell auf der Festplatte gespeichert, sodass die In-Memory-Caching-Schicht LLAP von Hive die Daten einmal von der Festplatte abrufen und mehrmals aus dem Speicher bereitstellen kann. Die Kombination aus Hive+LLAP wird für Ad-hoc-Analysen, die Berechnung großer Aggregate und Berichte mit geringer Latenz verwendet. Ein großartiger Anwendungsfall für Hive ist die tägliche Ausführung einer Reihe von Dashboard-Berichten für Benutzer. Die sich wiederholenden Abfragen nutzen nicht nur den LLAP-Cache, sondern auch die Funktion "Cache für Abfrageergebnisse", die nahezu sofortige Ergebnisse zurückgibt, wenn sich die Daten nicht geändert haben (Nebenbei:Der Cache für Abfrageergebnisse ist eine Funktion, die in Hive 3.0 verfügbar ist - veröffentlicht in HDP 3.0). Daneben ist ein Hive Data Warehouse eine großartige Nutzung der Ad-hoc-Analysen, zu denen Hive in der Lage ist; Benutzer können Daten zusammenführen, gleichzeitige Abfragen ausführen und ACID-Transaktionen ausführen. Betrachten Sie Hive in dieser Hinsicht als SQL-Alleskönner, während die anderen beiden Engines eine extrem schnelle Leistung für bestimmte Nischenanwendungsfälle bieten.

Unsere zweite Engine, HBase, ist ein verteilter Schlüsselwertspeicher mit zufälligen Lese-, Schreib-, Aktualisierungs- und Löschfunktionen. HBase (eine NoSQL-Variante) ist als OLTP-Engine konzipiert, die eine Architektur für hochvolumige Transaktionsvorgänge ermöglicht – denken Sie an Messaging-Plattformen mit ständigen Nachrichten, die zwischen Benutzern ausgetauscht werden, oder Transaktionen, die in einem Finanzsystem generiert werden. HBase ist extrem effizient darin, Daten schnell einzugeben, zu speichern und wieder auszugeben – zufällige Einfügungen/Aktualisierungen/Löschungen mit ultraniedriger Latenz. Wofür es nicht ausgelegt ist, ist das Aggregieren und Zusammenführen von Daten – diese Funktionalität wird durch Phoenix, eine SQL-Schicht und -Engine auf HBase, erreicht, wird jedoch nicht für größere Datenmengen empfohlen, da die Daten nicht so strukturiert sind, dass sie optimal sind Leistung (verwenden Sie stattdessen Hive). Zusammenfassend lässt sich sagen, dass HBase großartig darin ist, große Mengen von Create-Update-Delete-Vorgängen zu verarbeiten, aber nicht in der Lage ist, diese Daten in einem konsumierbaren Format für Benutzer bereitzustellen.

Schließlich ist Druid die dritte Engine und eine, die sich für OLAP-Zeitreihen-Workloads mit geringer Latenz sowie für die Echtzeit-Indizierung von Streaming-Daten eignet. Druid bietet OLAP-Abfragen in Würfelgeschwindigkeit für Ihren Cluster. Die Zeitreihennatur von Druid ist ein Eckpfeiler der Engine; Es ist so konzipiert, weil die Zeit ein primärer Filter ist, wenn zeitbasierte Daten analysiert werden. Denken Sie daran, wenn Sie die Flugzeiten analysieren, um eine Reise zu buchen – ich möchte den günstigsten Flug nach Italien innerhalb dieses bestimmten 2-Wochen-Zeitraums wissen. Druid passt in die Nische, Daten sehr schnell aufzunehmen und sie auf Anfrage zu lokalisieren. Andererseits ermöglicht es auch Geschäftsanwendern und Analysten, die Daten abzufragen und sie durch Superset, eine Visualisierungsebene, die eng mit Druid verbunden ist, zu verstehen. Druid ist hervorragend darin, eine Handvoll Datenzeilen unter Hunderten von Millionen oder Milliarden in weniger als einer Sekunde zu lokalisieren, und es zeichnet sich auch durch die extrem schnelle Berechnung von Gesamtwerten über dieselbe Datenmenge aus. Es führt jedoch keine Verknüpfungen durch und kann daher nicht zum Kombinieren von Datensätzen zu Analysezwecken verwendet werden. Wenn Sie eine Kombination von Datensätzen in Druid analysieren möchten, sollten Sie die Daten vor dem Einfügen in Druid zusammenführen oder Hive (und von Druid unterstützte Hive-Tabellen) verwenden, um Verknüpfungen durchzuführen. Mit anderen Worten, Druid passt gut in die Rolle, die letzte Station für Ihre Daten zu sein, nachdem sie verarbeitet und in den Zugriff Ihrer Geschäftsbenutzer umgewandelt wurden. Druid eignet sich hervorragend für Business-Analysten, da sie sich bei Superset anmelden und Metriken in Dashboard-Form visualisieren können, ohne Abfragen schreiben zu müssen; Sie verwenden einfach eine GUI, um die Abfragedatenquelle und die Filter auszuwählen. Aufgrund seiner schnellen Abfragezeiten eignet es sich auch hervorragend als unterstützende Datenquelle für System-Dashboards, ob operativ oder analytisch.

Hier ist eine Möglichkeit, wie Sie die Entscheidungsfindung aufschlüsseln können, welches Tool Sie für Ihre Arbeitslast verwenden sollten:

Einheitliches SQL

Wir haben bis zu diesem Punkt mehrere Systeme besprochen, und jedes hat seine eigenen Möglichkeiten, auf seine Daten zuzugreifen. Das ist großartig, wenn Ihre Benutzer wissen, wie all diese Tools funktionieren, aber sie werden möglicherweise eine Lernkurve durchlaufen, bevor sie ihre volle Produktivität erreichen können, wenn sie aus einer Welt von SQL, SQL und noch mehr SQL kommen, wie es die meisten Analysten tun. Aus diesem Grund haben wir versucht, diese Interaktion so einfach wie möglich zu gestalten; Mit Hive 3.0 in HDP 3.0 können Sie die SQL-ähnliche HQL-Syntax von Hive verwenden, um mit so vielen verschiedenen Datenspeichern in diesem Bereich zu interagieren. Hive kann als Portal verwendet werden, um auf Druid, HBase und alles, was eine JDBC-Schnittstelle und einen Treiber bereitstellt, zuzugreifen und diese zu ändern. Hive kann verwendet werden, um eine Aufnahmeaufgabe für Druiden zu verwalten, die auf Kafka hört und einen einfachen Weg zur Aufnahme in Echtzeit bietet. Und schließlich kann Hive verwendet werden, um alles zusammenzubringen – speichern Sie Ihre Daten dort, wo es am sinnvollsten ist, und greifen Sie von einem Ort aus darauf zu. Fügen Sie es zusammen, speichern Sie das neue Ergebnis vielleicht sogar an einem anderen Ort. Die Möglichkeiten sind vielfältig, aber die Benutzeroberfläche wurde stark vereinfacht, sodass Ihre Nutzer weniger Zeit damit verbringen, ein anderes Tool zu lernen, und mehr Zeit damit verbringen, einen Mehrwert für das Unternehmen zu schaffen.

Schlussfolgerung

Hive, Druid und HBase haben alle unterschiedliche Stellen in einer Datenarchitektur, wie wir aus der vorherigen Analyse gesehen haben. Sie sind jedoch komplementäre Werkzeuge; Sie könnten Transaktionsdaten mit HBase mit seinen schnellen Lookups aufnehmen, diese Daten für schnelles Drilldown/Aggregation in Druid verschieben und Hive die beiden zusammen mit seinen eigenen von Hive verwalteten Daten integrieren lassen, damit Benutzer Daten kombinieren können, wo immer sie sich befinden eine einzige Ansicht und eine Fülle von Einblicken. Bei diesem Ansatz speichert Druid Daten, auf die eigenständig zugegriffen werden kann, aber diese Funktionalität wird durch Hive erweitert, das Druid-Daten abrufen und mit zusätzlichen Daten verbinden kann. Fügen Sie dazu die wichtigsten Verbesserungen hinzu, die mit Hive 3.0 ins Spiel gekommen sind, darunter nicht zuletzt materialisierte Ansichten, verbesserte Integrationen mit Druid sowie vielen anderen Engines und erweiterten Data-Warehouse-ähnlichen Funktionen, und Sie haben eine Gruppe von Tools, die nahezu jeden Anwendungsfall lösen können.

Architekturen wie die oben genannte bringen das Beste aus jedem Tool, um Ihren Workflow zu optimieren, und abstrahieren gleichzeitig die Details für diejenigen Benutzer, die nur mit den Daten befasst sind. Die Architekten richteten die Pipelines ein und platzierten die Daten je nach Anwendungsfall dort, wo sie hingehören. Das führt dann zu den Datenanalysten, die Hive als einzige Schnittstelle verwenden, um Wissen und Erkenntnisse zu gewinnen. Sie sind in der Lage, interessante Muster in den Daten zu finden, anstatt sich Gedanken darüber zu machen, wo die Daten gespeichert sind, oder eine neue Syntax zu lernen, um darauf zuzugreifen – Sie werden überrascht sein, wie oft wir dies auf der Welt sehen.

An dieser Stelle haben wir die Stärken, Schwächen und Best Practices jedes Tools aufgezeigt; Wir hoffen, dass Sie mit einem besseren Verständnis davon, was wo passt, sowie mit einem Gesamtbild davon, wie alle drei kombiniert werden können, um die besten Ergebnisse zu erzielen, nach Hause gehen.