Dremio: Einfachere und schnellere Datenanalyse

Jacques Nadeau ist CTO und Mitbegründer von Dremio.

Jetzt ist eine gute Zeit, um Entwickler zu werden. In den letzten zehn Jahren haben sich Entscheidungen über Technologie vom Sitzungssaal zu innovativen Entwicklern verlagert, die mit Open Source bauen und Entscheidungen auf der Grundlage der Vorzüge des zugrunde liegenden Projekts und nicht der Geschäftsbeziehungen eines Anbieters treffen. Es sind neue Projekte entstanden, die darauf abzielen, Entwickler produktiver zu machen und die einfacher zu verwalten und zu skalieren sind. Dies gilt für praktisch jede Schicht des Technologie-Stacks. Das Ergebnis ist, dass Entwickler heute nahezu unbegrenzte Möglichkeiten haben, neue Technologien, neue Architekturen und neue Bereitstellungsmodelle zu erkunden.

Insbesondere im Hinblick auf die Datenschicht haben NoSQL-Systeme wie MongoDB, Elasticsearch und Cassandra die Grenzen hinsichtlich Agilität, Skalierbarkeit und Leistung für betriebliche Anwendungen mit jeweils unterschiedlichen Datenmodellen und Schemata für das Schema erweitert. Auf dem Weg dorthin wechselten viele Entwicklungsteams zu einem Microservices-Modell und verteilten Anwendungsdaten auf viele verschiedene zugrunde liegende Systeme.

In Bezug auf die Analyse haben alte und neue Datenquellen ihren Weg in eine Mischung aus traditionellen Data Warehouses und Data Lakes gefunden, einige auf Hadoop, andere auf Amazon S3. Und der Aufstieg der Kafka-Daten-Streaming-Plattform schafft eine völlig andere Denkweise in Bezug auf Datenbewegung und Analyse von Daten in Bewegung.

Bei Daten in so vielen verschiedenen Technologien und zugrunde liegenden Formaten ist die Analyse moderner Daten schwierig. BI- und Analysetools wie Tableau, Power BI, R, Python und Modelle für maschinelles Lernen wurden für eine Welt entwickelt, in der Daten in einer einzigen relationalen Hochleistungsdatenbank gespeichert sind. Darüber hinaus möchten Benutzer dieser Tools - Geschäftsanalysten, Datenwissenschaftler und Modelle für maschinelles Lernen - die Möglichkeit haben, selbstständig auf Daten zuzugreifen, diese zu untersuchen und zu analysieren, ohne von der IT abhängig zu sein.

Einführung in die Dremio-Datenstruktur

BI-Tools, Data Science-Systeme und Modelle für maschinelles Lernen funktionieren am besten, wenn Daten in einer einzigen relationalen Hochleistungsdatenbank gespeichert sind. Leider leben dort heute keine Daten mehr. Infolgedessen hat die IT keine andere Wahl, als diese Lücke durch eine Kombination aus kundenspezifischer ETL-Entwicklung und proprietären Produkten zu schließen. In vielen Unternehmen umfasst der Analytics-Stack die folgenden Ebenen:

  • Datenbereitstellung . Die Daten werden aus verschiedenen Betriebsdatenbanken in einen einzelnen Staging-Bereich wie einen Hadoop-Cluster oder einen Cloud-Speicherdienst (z. B. Amazon S3) verschoben.
  • Data Warehouse . Während es möglich ist, SQL-Abfragen direkt auf Hadoop und im Cloud-Speicher auszuführen, sind diese Systeme einfach nicht dafür ausgelegt, interaktive Leistung zu liefern. Daher wird normalerweise eine Teilmenge der Daten in ein relationales Data Warehouse oder eine MPP-Datenbank geladen.
  • Cubes, Aggregationstabellen und BI-Extrakte . Um eine interaktive Leistung für große Datenmengen bereitzustellen, müssen die Daten voraggregiert und / oder indiziert werden, indem Cubes in einem OLAP-System oder materialisierte Aggregationstabellen im Data Warehouse erstellt werden.

Diese mehrschichtige Architektur bringt viele Herausforderungen mit sich. Es ist komplex, fragil und langsam und schafft eine Umgebung, in der Datenkonsumenten vollständig von der IT abhängig sind.

Dremio führt eine neue Stufe in der Datenanalyse ein, die wir als Self-Service-Datenstruktur bezeichnen. Dremio ist ein Open-Source-Projekt, mit dem Business Analysten und Datenwissenschaftler Daten jederzeit unabhängig von Standort, Größe oder Struktur untersuchen und analysieren können. Dremio kombiniert eine Scale-Out-Architektur mit säulenförmiger Ausführung und Beschleunigung, um eine interaktive Leistung für jedes Datenvolumen zu erzielen, und ermöglicht es IT, Datenwissenschaftlern und Geschäftsanalysten, die Daten nahtlos an die Anforderungen des Unternehmens anzupassen.

Erbaut auf Apache Arrow, Apache Parkett und Apache Calcite

Dremio verwendet leistungsstarke Spaltenspeicherung und -ausführung, die von Apache Arrow (Spalte im Speicher) und Apache Parquet (Spalte auf der Festplatte) unterstützt wird. Dremio verwendet Apache Calcite auch für die SQL-Analyse und Abfrageoptimierung und baut auf denselben Bibliotheken auf wie viele andere SQL-basierte Engines wie Apache Hive.

Apache Arrow ist ein Open Source-Projekt, das die Verarbeitung und den Austausch von speicherinternen Spalten im Speicher ermöglicht. Arrow wurde von Dremio erstellt und umfasst Committer verschiedener Unternehmen, darunter Cloudera, Databricks, Hortonworks, Intel, MapR und Two Sigma.

Dremio ist die erste Ausführungs-Engine, die von Grund auf auf Apache Arrow basiert. Intern werden die Daten im Speicher außerhalb des Heapspeichers im Pfeilformat verwaltet, und es wird bald eine API geben, die Abfrageergebnisse als Pfeilspeicherpuffer zurückgibt.

Eine Vielzahl anderer Projekte hat sich ebenfalls mit Arrow befasst. Python (Pandas) und R gehören zu diesen Projekten, mit denen Datenwissenschaftler effizienter mit Daten arbeiten können. Zum Beispiel hat Wes McKinney, der Schöpfer der beliebten Pandas-Bibliothek, kürzlich demonstriert, wie Arrow es Python-Benutzern ermöglicht, Daten mit über 10 GB / s in Pandas einzulesen.

Wie Dremio Self-Service-Daten aktiviert

Neben der Fähigkeit, interaktiv mit ihren Datensätzen zu arbeiten, benötigen Dateningenieure, Geschäftsanalysten und Datenwissenschaftler auch eine Möglichkeit, die Daten so zu kuratieren, dass sie für die Anforderungen eines bestimmten Projekts geeignet sind. Dies ist eine grundlegende Abkehr vom IT-zentrierten Modell, bei dem Datenkonsumenten eine Anforderung für einen Datensatz initiieren und Wochen oder Monate später darauf warten, dass die IT ihre Anforderung erfüllt. Dremio ermöglicht ein Self-Service-Modell, bei dem Datenkonsumenten die Datenkurationsfunktionen von Dremio verwenden, um Daten gemeinsam zu entdecken, zu kuratieren, zu beschleunigen und gemeinsam zu nutzen, ohne sich auf die IT verlassen zu müssen.

Alle diese Funktionen sind über eine moderne, intuitive, webbasierte Benutzeroberfläche zugänglich:

  • Entdecken Sie . Dremio enthält einen einheitlichen Datenkatalog, in dem Benutzer physische und virtuelle Datensätze erkennen und untersuchen können. Der Datenkatalog wird automatisch aktualisiert, wenn neue Datenquellen hinzugefügt werden und wenn sich Datenquellen und virtuelle Datensätze weiterentwickeln. Alle Metadaten werden in einem leistungsstarken, durchsuchbaren Index indiziert und Benutzern über die gesamte Dremio-Oberfläche zugänglich gemacht.
  • Kuratieren . Mit Dremio können Benutzer Daten kuratieren, indem sie virtuelle Datensätze erstellen. Eine Vielzahl von Point-and-Click-Transformationen wird unterstützt, und fortgeschrittene Benutzer können mithilfe der SQL-Syntax komplexere Transformationen definieren. Während Abfragen im System ausgeführt werden, lernt Dremio die Daten kennen und kann verschiedene Transformationen wie Verknüpfungen und Datentypkonvertierungen empfehlen.
  • Dremio ist in der Lage, Datensätze gegenüber der Leistung des Quellsystems um das 1000-fache zu beschleunigen. Benutzer können für Datensätze stimmen, die ihrer Meinung nach schneller sein sollten, und die Heuristiken von Dremio berücksichtigen diese Stimmen bei der Bestimmung, welche Datensätze beschleunigt werden sollen. Optional können Systemadministratoren manuell bestimmen, welche Datasets beschleunigt werden sollen.
  • Mit Dremio können Benutzer Daten sicher mit anderen Benutzern und Gruppen teilen. In diesem Modell kann eine Gruppe von Benutzern an einem virtuellen Datensatz zusammenarbeiten, der für einen bestimmten Analyseauftrag verwendet wird. Alternativ können Benutzer ihre eigenen Daten, z. B. Excel-Tabellen, hochladen, um sie mit anderen Datasets aus dem Unternehmenskatalog zu verbinden. Ersteller virtueller Datasets können bestimmen, welche Benutzer ihre virtuellen Datasets abfragen oder bearbeiten können. Es ist wie Google Text & Tabellen für Ihre Daten.

So funktioniert die Dremio-Datenbeschleunigung

Dremio verwendet hochoptimierte physikalische Darstellungen von Quelldaten, die als Datenreflexionen bezeichnet werden. Der Reflection Store kann auf HDFS, MapR-FS, Cloud-Speicher wie S3 oder DAS (Direct-Attached Storage) basieren. Die Größe des Reflection Store kann die des physischen Speichers überschreiten. Diese Architektur ermöglicht es Dremio, mehr Daten zu geringeren Kosten zu beschleunigen, was zu einer viel höheren Cache-Trefferquote im Vergleich zu herkömmlichen Nur-Speicher-Architekturen führt. Datenreflexionen werden vom kostenbasierten Optimierer zur Abfragezeit automatisch verwendet.

Datenreflexionen sind für Endbenutzer nicht sichtbar. Im Gegensatz zu OLAP-Cubes, Aggregationstabellen und BI-Extrakten stellt der Benutzer keine explizite Verbindung zu einer Datenreflexion her. Stattdessen geben Benutzer Abfragen für das logische Modell aus, und der Optimierer von Dremio beschleunigt die Abfrage automatisch, indem er die Datenreflexionen nutzt, die für die Abfrage auf der Grundlage der Kostenanalyse des Optimierers geeignet sind.

Wenn das Optimierungsprogramm die Abfrage nicht beschleunigen kann, nutzt Dremio seine leistungsstarke verteilte Ausführungs-Engine, die die säulenförmige In-Memory-Verarbeitung (über Apache Arrow) und erweiterte Push-Downs in die zugrunde liegenden Datenquellen (beim Umgang mit RDBMS- oder NoSQL-Quellen) nutzt.

Wie Dremio mit SQL-Abfragen umgeht

Clientanwendungen senden SQL-Abfragen an Dremio über ODBC, JDBC oder REST. Eine Abfrage kann ein oder mehrere Datasets umfassen, die sich möglicherweise in verschiedenen Datenquellen befinden. Eine Abfrage kann beispielsweise eine Verknüpfung zwischen einer Hive-Tabelle, Elasticsearch und mehreren Oracle-Tabellen sein.

Dremio verwendet zwei Haupttechniken, um den für eine Abfrage erforderlichen Verarbeitungsaufwand zu reduzieren:

  • Pushdowns in die zugrunde liegende Datenquelle . Der Optimierer berücksichtigt die Funktionen der zugrunde liegenden Datenquelle und die relativen Kosten. Anschließend wird ein Plan generiert, der Phasen der Abfrage entweder in der Quelle oder in der verteilten Ausführungsumgebung von Dremio ausführt, um den effizientesten Gesamtplan zu erzielen.
  • Beschleunigung über Datenreflexionen . Das Optimierungsprogramm verwendet Datenreflexionen für Teile der Abfrage, wenn dies den effizientesten Gesamtplan ergibt. In vielen Fällen kann die gesamte Abfrage über Datenreflexionen bearbeitet werden, da sie um Größenordnungen effizienter sind als die Verarbeitung von Abfragen in der zugrunde liegenden Datenquelle.

Push-Downs abfragen

Dremio ist in der Lage, die Verarbeitung in relationale und nicht relationale Datenquellen zu verschieben. Nicht relationale Datenquellen unterstützen normalerweise kein SQL und verfügen nur über eingeschränkte Ausführungsfunktionen. Ein Dateisystem kann beispielsweise keine Prädikate oder Aggregationen anwenden. MongoDB hingegen kann Prädikate und Aggregationen anwenden, unterstützt jedoch nicht alle Joins. Der Dremio-Optimierer kennt die Funktionen jeder Datenquelle. Wenn es am effizientesten ist, sendet Dremio so viele Abfragen wie möglich an die zugrunde liegende Quelle und führt den Rest in seiner eigenen verteilten Ausführungs-Engine aus.

Betriebsdatenbanken entladen

Die meisten Betriebsdatenbanken sind für schreiboptimierte Workloads ausgelegt. Darüber hinaus müssen diese Bereitstellungen strenge SLAs berücksichtigen, da Ausfallzeiten oder Leistungseinbußen das Geschäft erheblich beeinträchtigen können. Infolgedessen sind Betriebssysteme häufig von der Verarbeitung analytischer Abfragen isoliert. In diesen Fällen kann Dremio mithilfe von Datenreflexionen analytische Abfragen ausführen, die eine möglichst effiziente Abfrageverarbeitung ermöglichen und gleichzeitig die Auswirkungen auf das Betriebssystem minimieren. Datenreflexionen werden regelmäßig basierend auf Richtlinien aktualisiert, die tabellenweise konfiguriert werden können.

Ausführungsphasen abfragen

Die Lebensdauer einer Abfrage umfasst die folgenden Phasen:

  1. Der Client sendet eine Anfrage an den Koordinator über ODBC / JDBC / REST
  2. Planung
    1. Der Koordinator analysiert die Abfrage des universellen relationalen Modells von Dremio
    2. Der Koordinator berücksichtigt die verfügbaren Statistiken zu Datenquellen, um einen Abfrageplan zu entwickeln, sowie die funktionalen Fähigkeiten der Quelle
  3. Der Koordinator schreibt den zu verwendenden Abfrageplan neu
    1. die verfügbaren Datenreflexionen unter Berücksichtigung der Reihenfolge, Partitionierung und Verteilung der Datenreflexionen und
    2. die verfügbaren Funktionen der Datenquelle
  4. Ausführung
  1. Ausführende lesen Daten parallel aus Quellen in Pfeilpuffer
    1. Ausführende führen den umgeschriebenen Abfrageplan aus.
    2. Ein Executor führt die Ergebnisse von einem oder mehreren Executoren zusammen und überträgt die Endergebnisse an den Koordinator
  1. Der Kunde erhält die Ergebnisse vom Koordinator

Beachten Sie, dass die Daten möglicherweise aus Datenreflexionen oder den zugrunde liegenden Datenquellen stammen. Beim Lesen aus einer Datenquelle sendet der Executor die nativen Abfragen (z. B. MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL), die vom Optimierer in der Planungsphase festgelegt wurden.

Alle Datenoperationen werden auf dem Executor-Knoten ausgeführt, sodass das System mit nur wenigen Koordinatorknoten auf viele gleichzeitige Clients skalieren kann.

Beispiel-Pushdown für Abfragen

Um zu veranschaulichen, wie Data Fabric in Ihre Datenarchitektur passt, schauen wir uns die Ausführung einer SQL-Abfrage für eine Quelle genauer an, die SQL nicht unterstützt.

Eine der beliebtesten modernen Datenquellen ist Elasticsearch. An Elasticsearch gibt es viel zu mögen, aber in Bezug auf die Analyse wird SQL nicht unterstützt (einschließlich SQL-Joins). Das bedeutet, dass Tools wie Tableau und Excel nicht zum Analysieren von Daten aus Anwendungen verwendet werden können, die auf diesem Datenspeicher basieren. Es gibt ein Visualisierungsprojekt namens Kibana, das für Elasticsearch beliebt ist, aber Kibana wurde für Entwickler entwickelt. Es ist nicht wirklich für Geschäftsanwender.

Mit Dremio können Sie Daten in Elasticsearch mit jedem SQL-basierten Tool, einschließlich Tableau, einfach analysieren. Nehmen wir zum Beispiel die folgende SQL-Abfrage für Yelp-Geschäftsdaten, die in JSON gespeichert ist:

SELECT Bundesland, Stadt, Name, review_count

FROM elastic.yelp.business

WO

  Zustand NICHT IN ('TX', 'UT', 'NM', 'NJ') UND

  review_count> 100

ORDER BY review_count DESC, Bundesland, Stadt

GRENZWERT 10

Dremio kompiliert die Abfrage zu einem Ausdruck, den Elasticsearch verarbeiten kann: