Wie haben wir unser Impala schneller gemacht?
Sie haben also Ihr Hadoop, Terabytes von Daten werden pro Tag hineingeschoben, ETLs werden 24/7 mit Spark, Hive oder – Gott bewahre – Pig durchgeführt. Und dann, nachdem die Daten genau die gewünschte Form haben (oder sogar schon vorher) und alles perfekt ist, wollen die Analysten sie abfragen. Wenn Sie Impala für diese Aufgabe gewählt haben, ist dieser Artikel für Sie.
Wir verwenden Impala für einige Zwecke:
- Lassen Sie Analysten neue Datentypen abfragen, für die die Dateningenieure noch keine ETLs erstellt haben.
- Analysten können Daten abfragen, deren endgültiges Ziel (nach dem ETL-Prozess) HDFS ist.
- Berichterstellung (mit unseren eigenen Tools).
- Überwachung &von Alarmsystemen (für neue Daten, die stündlich eingehen).
Wir haben zehntausende von Abfragen pro Tag, jede Abfrage scannt im Durchschnitt einige Gigabyte Daten und dauert 10 Sekunden. Unser Cluster ist nicht riesig, was die Hardware und die Anzahl der Knoten angeht, die wir haben. Ganz zu schweigen davon, dass wir täglich Hunderte von anderen Workflows (Spark, Pig, Hive) auf demselben Cluster laufen lassen.
In diesem Artikel werde ich die Erkenntnisse und Schlussfolgerungen teilen, die wir aus unserem Impala-Optimierungsprojekt gewonnen haben.
Was ist Impala?
Wenn Sie nicht wissen, was es ist – lesen Sie darüber im Cloudera Impala Guide, und kommen Sie dann hierher zurück, um die interessanten Dinge zu erfahren.
Impala im Vergleich zu anderen SQL-on-Hadoop-Lösungen
Hier gibt es nichts zu vergleichen. Heutzutage ist Hive nur noch für ETLs und Batch-Processing gedacht. Ihre Analysten erhalten ihre Antworten mit Impala viel schneller, obwohl Impala im Gegensatz zu Hive nicht fehlertolerant ist. Aber für eine MPP-Engine (Massive Parallel Processing) ist das in Ordnung.
Impala ist schneller als Hive, weil es eine ganz andere Engine ist und Hive über MapReduce steht (das aufgrund seiner zu vielen Platten-E/A-Operationen sehr langsam ist).
Impala Vs. SparkSQL
Ja, SparkSQL ist viel schneller als Hive, vor allem wenn es nur In-Memory-Berechnungen durchführt, aber Impala ist immer noch schneller als SparkSQL.
Es ist schneller, weil Impala eine Engine ist, die speziell für die Aufgabe von interaktivem SQL über HDFS entwickelt wurde, und es hat Architekturkonzepte, die es dabei unterstützen. Zum Beispiel sind die Impala „always-on“ Daemons rund um die Uhr in Betrieb und warten auf Abfragen – etwas, das bei SparkSQL nicht der Fall ist. Und einige weitere Gründe wie Impalas Codegen-Mechanismus, die Optimierung des Parquet-Formats, Statistiken, Metadaten-Cache, usw.
Der JDBC/ODBC Thrift Server von SparkSQL könnte ein vergleichbarer Konkurrent zu Impala sein, aber da ich nicht viel darüber im Web finden konnte – werde ich es hier nur erwähnen und wenn Sie etwas Wissen und Erfahrung zu diesem Thema haben, schreiben Sie bitte einen Medium-Post darüber. Vielleicht schreibe ich einen in naher Zukunft.
Impala vs. Presto
Presto ist eine sehr ähnliche Technologie mit ähnlicher Architektur. Nach fast allen Benchmarks im Internet ist Impala schneller als Presto, aber Presto ist viel anpassungsfähiger als Impala. Impala ist vermutlich schneller, wenn Sie SQL über Hadoop benötigen, aber wenn Sie mehrere Datenquellen mit der gleichen Abfrage-Engine abfragen müssen, ist Presto besser als Impala. Sehen Sie sich einfach diese Liste von Presto Connectors an. Impala kann auch Amazon S3, Kudu und HBase abfragen und das war’s dann auch schon.
Für weitere Informationen über Presto – hier ist ein vollständiger Bericht über PrestoDB.
Impala Best Practices
Impala funktioniert am besten, wenn es Dateien abfragt, die im Parquet-Format gespeichert sind. Die gesamte Technologie, auf der Cloudera Impala basiert, stammt aus dem Google Dremel Whitepaper und in diesem Paper findet man das Konzept, auf dem Parquet basiert. Denken Sie also daran, keine json, csv oder Sequenzdateien abzufragen – parquetieren Sie Ihre Dateien, bevor Sie sie von Analysten abfragen lassen.
Arbeiten Sie mit Partitionen
Partitionieren Sie Ihre Daten entsprechend den Abfragen Ihrer Analysten. Impala hat keine Indizes, also ist das die einzige Möglichkeit, die Datenmenge zu reduzieren, die Sie bei jeder Abfrage verarbeiten. Wir verwenden DT (Datumszeit) als Hauptpartitionierungsmethode für die meisten unserer Tabellen. Eine zu starke Partitionierung kann gefährlich sein (lesen Sie weiter, um mehr darüber zu erfahren).
Die REFRESH-Anweisung
Die REFRESH-Anweisung kann eine teure Operation sein, besonders wenn Sie Tausende von Tabellen haben, zu denen stündlich Daten hinzukommen. Wir führen mehr als 10.000 Aktualisierungen pro Tag durch. Dies sind meine besten Praktiken für Aktualisierungen:
- Seit Impala 2.7 können Sie eine Aktualisierung auf einer bestimmten Partition durchführen, was die REFRESH-Anweisung viel leichter macht.
- Heiße & archivierte Tabellenarchitektur – jede Tabelle hat eine heiße Version und eine archivierte Version. Die heiße Version enthält die letzten 24 Stunden, und eine Aktualisierung dieser Tabelle erfolgt stündlich und ist sehr viel leichter. Jeden Tag wird die heiße Tabelle mit der archivierten Tabelle zusammengeführt, und es erfolgt eine umfangreichere Aktualisierung dieser Tabelle. Und natürlich eine VIEW über diesen beiden, die sie vereint, so dass die Benutzer dies nicht einmal bemerken.
- Sie sollten nicht zu viele Metadaten (Dateien und Partitionen) pro Tabelle haben (siehe den Abschnitt „Optimale Dateigröße“).
Statistiken berechnen
Statistiken machen Ihre Abfragen viel effizienter, insbesondere diejenigen, die mehr als eine Tabelle (Joins) umfassen. Daher sollten Sie Statistiken für alle Ihre Tabellen berechnen und einen Workflow einrichten, der sie mit inkrementellen Statistiken auf dem neuesten Stand hält. Für weitere technische Details lesen Sie bitte Cloudera Impala Tabellen- und Spaltenstatistiken.
Optimale Dateigröße – 256MB/Datei
TL;DR: Stellen Sie sicher, dass Sie nicht zu viele kleine Dateien haben – das schadet Ihrem Katalogserver, den Aktualisierungen und der Abfrageleistung sehr.
Wir haben bemerkt, dass unser Impala-Katalogserver 4 Mal pro Woche abstürzt und dass unsere Abfragen zu viel Zeit benötigen. Dann haben wir festgestellt, dass wir viel zu viele Dateien und Partitionen haben. Wir haben stündlich mit DT-Partitionen gearbeitet, unabhängig von der Größe der Partitionen.
Auf diese Weise hatten wir nach 2 Jahren Tabellen mit 17 GB Daten und 17.000 Partitionen – was bedeutet, dass jede Partition etwa 1 MB groß ist. Wir hatten Tabellen mit Partitionen in der Größe von 50KB. Und als ob das noch nicht genug wäre, enthielten einige dieser kleinen Partitionen mehrere Dateien.
Anfänglich dachten wir, dass diese unvernünftige Menge an Dateien nur dazu führt, dass unsere Metadaten zu groß sind und dass deshalb die Aktualisierungen so schwer sind und der Katalogserver abstürzt. Aber dann wurde uns klar, dass die Menge der Dateien auch unsere Abfrageleistung sehr stark beeinträchtigt (weil die Anzahl der Scanner-Threads zum Lesen so vieler Parkettdateien erforderlich ist).
Wie stark? Wir haben einen Test mit einer aktuellen 500MB-Tabelle durchgeführt, die wir haben, mit 17.280(!) Partitionen und Dateien. Wir haben eine neue zusammengeführte Version dieser Tabelle mit nur 2 Dateien erstellt, 1 pro Jahr. Der SCAN HDFS-Teil in der Zusammenfassung der Abfrageausführung war 2.000 Mal schneller. Das war der Teil, in dem wir verstanden, wie sehr uns unsere kleinen Dateien schaden.
So begannen wir, unsere Partitionen zu verwalten und sie auf die optimale Dateigröße zusammenzuführen, die etwa 256 MB beträgt.
Tabellen mit einer stündlichen Partitionierung wurden zu täglichen, monatlichen oder jährlichen Partitionen. Jede Partition hat nur noch eine Datei (es sei denn, sie ist > 256mb groß)
Koordinatoren &Ausführer pro Daemon konfigurieren
Seit Impala 2.9 kann man bestimmen, welche Impala-Daemons Koordinatoren und welche Ausführer sind. Das ist eine enorme Veränderung, denn vorher waren alle Daemons Koordinatoren und Executors, und der Overhead eines Koordinators ist für große Cluster sehr ressourcenintensiv.
Das bedeutet zum Beispiel, dass jeder Knoten den gesamten Metadaten-Cache in seinem RAM hält. Und wenn Sie z.B. 20 GB Metadaten und 50 Knoten haben, bedeutet das eine Verschwendung von 1 TB RAM, nur weil alle Knoten auch Koordinatoren sind!
Testen Sie, was für Sie das beste Verhältnis von Koordinatoren und Ausführenden ist und verwenden Sie es. Tipp: Beginnen Sie mit 2 Koordinatoren pro Cluster.
Spalten-Datentypen
Zunächst verwendeten wir STRING für alle unsere Spalten in allen Tabellen. Das ist eine wirklich schlechte Praxis, die der Leistung sehr schadet. Man sollte versuchen, aus allen von Impala unterstützten Datentypen den am besten geeigneten Typ für die Spalte zu wählen.
Impala Query Limits
Man sollte die Impala Admission Control verwenden, um verschiedene Pools für verschiedene Benutzergruppen festzulegen, um die Nutzung einiger Benutzer auf X gleichzeitige Abfragen oder Y Speicher zu beschränken. Aber noch mehr als das – wir haben unser eigenes System entwickelt, um mit problematischen Benutzern und Abfragen umzugehen.
Unser System prüft die aktuell laufenden Abfragen alle 10 Sekunden und wenn eine Abfrage länger als 30 Minuten läuft – wird sie beendet. Wenn dieselbe Abfragevorlage im letzten Monat 90 % der Male gekillt wurde, weil sie mehr als 30 Minuten dauerte, wird sie von unserem System sofort gekillt, wenn es die Vorlage erkennt, um unsere Infrastruktur zu schützen.
Das Töten von Abfragen ist kein neues Konzept – Amazon Athena hat das schon vor uns getan, aber Abfragen nur nach problematischen Mustern zu töten – das ist etwas, was sonst niemand tut, und das ist die einzige Möglichkeit, mit Tausenden von hungrigen Analysten umzugehen.
Zusammenfassung
Wenn Sie Ihre Analysten Ad-hoc-, interaktive SQL-Abfragen über Ihr Hadoop durchführen lassen wollen – Impala ist eine großartige Lösung. Sie sollten den Cloudera Impala Guide lesen, um ein wirklich guter Impala-Administrator zu werden, und daran denken, nach den Best Practices zu arbeiten, die ich hier erklärt habe.