Ein Leitfaden für Dateningenieure zu nicht-traditionellen Datenspeichern

Datentechnik

Mit dem Aufkommen von Big Data und Data Science werden viele Engineering-Rollen herausgefordert und erweitert. Eine New-Age-Rolle ist Data Engineering .

Ursprünglich war der Zweck des Data Engineering das Laden externer Datenquellen und das Entwerfen von Datenbanken (Entwerfen und Entwickeln von Pipelines zum Sammeln, Manipulieren, Speichern und Analysieren von Daten).

Seitdem ist es gewachsen, um das Volumen und die Komplexität von Big Data zu unterstützen. Data Engineering umfasst also heute eine breite Palette von Fähigkeiten, von Web-Crawling, Datenbereinigung, verteiltem Rechnen und Datenspeicherung und -abruf.

Für Data Engineering und Data Engineers ist das Speichern und Abrufen von Daten zusammen mit der Art und Weise, wie die Daten verwendet und analysiert werden können, die entscheidende Komponente der Pipeline.

In jüngster Zeit sind viele neue und unterschiedliche Datenspeichertechnologien entstanden. Welches ist jedoch am besten geeignet und hat die geeignetsten Funktionen für das Data Engineering?

Die meisten Ingenieure sind mit SQL-Datenbanken wie PostgreSQL, MSSQL und MySQL vertraut, die in relationalen Datentabellen mit zeilenorientierter Speicherung strukturiert sind.

Da diese Datenbanken allgegenwärtig sind, werden wir sie heute nicht diskutieren. Stattdessen untersuchen wir drei Arten von alternativen Datenspeichern, die immer beliebter werden und unterschiedliche Ansätze für den Umgang mit Daten eingeführt haben.

Im Zusammenhang mit Data Engineering sind diese Technologien Suchmaschinen, Dokumentenspeicher und Spaltenspeicher.

• Suchmaschinen zeichnen sich durch Textabfragen aus. Im Vergleich zu Textübereinstimmungen in SQL-Datenbanken wie LIKE bieten Suchmaschinen von Haus aus höhere Abfragemöglichkeiten und eine bessere Leistung.
• Dokumentspeicher bieten eine bessere Datenschema-Anpassbarkeit als herkömmliche Datenbanken. Indem die Daten als einzelne Dokumentobjekte gespeichert werden, die häufig als JSONs dargestellt werden, benötigen sie keine Schemavordefinition.
• Columnar Stores sind auf Einzelspaltenabfragen und Wertaggregationen spezialisiert. SQL-Operationen wie SUM und AVG sind in Spaltenspeichern erheblich schneller, da Daten derselben Spalte näher beieinander auf der Festplatte gespeichert werden.

In diesem Artikel untersuchen wir alle drei Technologien: Elasticsearch als Suchmaschine, MongoDB als Dokumentenspeicher und Amazon Redshift als Spaltenspeicher.

Durch das Verständnis alternativer Datenspeicher können wir für jede Situation die am besten geeignete auswählen.

Um diese Technologien zu vergleichen, untersuchen wir, wie sie Daten indizieren, fragmentieren und aggregieren.

Jede Datenindizierungsstrategie verbessert bestimmte Abfragen, während andere behindert werden.

Zu wissen, welche Abfragen am häufigsten verwendet werden, kann Einfluss darauf haben, welcher Datenspeicher verwendet werden sollte.

Sharding, eine Methode, mit der Datenbanken ihre Daten in Blöcke aufteilen, bestimmt, wie die Infrastruktur wächst, wenn mehr Daten aufgenommen werden.

Es ist entscheidend, eines zu wählen, das zu unserem Wachstumsplan und Budget passt, und dies gilt für jedes Data-Science-Unternehmen, unabhängig von seiner Größe.

Schließlich aggregieren diese Technologien ihre Daten jeweils sehr unterschiedlich.

Wenn wir es mit Gigabytes und Terabytes an Daten zu tun haben, kann die falsche Aggregationsstrategie die Art und Leistung der Berichte einschränken, die wir generieren können.

Als Dateningenieure müssen wir alle drei Aspekte bei der Bewertung verschiedener Datenspeicher berücksichtigen.

Anwärter

Suchmaschine: Elasticsearch

Elasticsearch gewann aufgrund seiner Skalierbarkeit und einfachen Integration schnell an Popularität unter seinen Mitbewerbern. Es baut auf Apache Lucene auf und bietet eine leistungsstarke, sofort einsatzbereite Textsuch- und Indizierungsfunktion. Neben den traditionellen Suchmaschinenaufgaben, der Textsuche und Abfragen nach exakten Werten bietet Elasticsearch auch mehrschichtige Aggregationsfunktionen.

Dokumentenspeicher: MongoDB

An diesem Punkt kann MongoDB als die Go-to-NoSQL-Datenbank betrachtet werden. Seine Benutzerfreundlichkeit und Flexibilität erlangten schnell seine Popularität. MongoDB unterstützt umfangreiche und anpassbare Abfragen zum Durchsuchen komplexer Dokumente. Häufig abgefragte Felder können durch Indizierung beschleunigt werden, und beim Aggregieren großer Datenmengen bietet MongoDB eine mehrstufige Pipeline.

Säulenspeicher: Amazon Redshift

Neben der zunehmenden Popularität von NoSQL haben auch spaltenorientierte Datenbanken Aufmerksamkeit erregt, insbesondere für die Datenanalyse. Durch das Speichern von Daten in Spalten anstelle der üblichen Zeilen können Aggregationsvorgänge direkt von der Festplatte ausgeführt werden, wodurch die Leistung erheblich gesteigert wird. Vor einigen Jahren führte Amazon seinen gehosteten Service für einen Säulenladen namens Redshift ein.

Indizierung

Die Indizierungsfunktion von Elasticsearch

Suchmaschinen sind in vielerlei Hinsicht Datenspeicher, die sich auf die Indexierung von Texten spezialisiert haben.

Während andere Datenspeicher Indizes basierend auf den genauen Werten des Felds erstellen, ermöglichen Suchmaschinen den Abruf nur mit einem Fragment des (normalerweise Text-) Felds.

Standardmäßig erfolgt dieser Abruf automatisch für jedes Feld durch Analysatoren.

Ein Analysator ist ein Modul, das mehrere Indexschlüssel erstellt, indem es die Feldwerte auswertet und sie in kleinere Werte zerlegt.

Zum Beispiel könnte ein einfacher Analysator „der schnelle braune Fuchs sprang über den faulen Hund“ in Wörter wie „der“, „schnell“, „braun“, „Fuchs“ und so weiter untersuchen.

Mit dieser Methode können Benutzer die Daten finden, indem sie in den Ergebnissen nach Fragmenten suchen, die danach geordnet sind, wie viele Fragmente mit denselben Dokumentdaten übereinstimmen.

Ein ausgefeilterer Analysator könnte Entfernungen und N-Gramm bearbeiten und nach Stoppwörtern filtern, um einen umfassenden Abrufindex zu erstellen.

Die Indizierungsfunktion von MongoDB

Als generischer Datenspeicher bietet MongoDB viel Flexibilität für die Indizierung von Daten.

Im Gegensatz zu Elasticsearch indiziert es standardmäßig nur das _id -Feld, und wir müssen Indizes für die häufig abgefragten Felder manuell erstellen.

Im Vergleich zu Elasticsearch ist der Textanalysator von MongoDB nicht so leistungsfähig. Aber es bietet eine Menge Flexibilität bei Indizierungsmethoden, von Compound und Geospatial für optimale Abfragen bis hin zu TTL und Sparse für Speicherreduzierung.

Indizierungsfunktion von Redshift

Im Gegensatz zu Elasticsearch, MongoDB oder sogar herkömmlichen Datenbanken, einschließlich PostgreSQL, unterstützt Amazon Redshift keine Indizierungsmethode.

Stattdessen reduziert es seine Abfragezeit, indem es eine konsistente Sortierung auf der Festplatte beibehält.

Als Benutzer können wir einen geordneten Satz von Spaltenwerten als Tabellensortierungsschlüssel konfigurieren. Wenn die Daten auf der Festplatte sortiert sind, kann Redshift beim Abrufen einen ganzen Block überspringen, wenn sein Wert außerhalb des abgefragten Bereichs liegt, was die Leistung stark steigert.

Scherben

Sharding-Fähigkeit von Elasticsearch

Elasticsearch wurde auf Lucene aufgebaut, um horizontal zu skalieren und produktionsbereit zu sein.

Die Skalierung erfolgt durch das Erstellen mehrerer Lucene-Instanzen (Shards) und deren Verteilung auf mehrere Knoten (Server) innerhalb eines Clusters.

Standardmäßig wird jedes Dokument über sein _id -Feld zu seinem jeweiligen Shard geleitet.

Während des Abrufs sendet der Master-Knoten jedem Shard eine Kopie der Abfrage, bevor er sie schließlich aggregiert und für die Ausgabe einordnet.

Sharding-Fähigkeit von MongoDB

Innerhalb eines MongoDB-Clusters gibt es drei Arten von Servern: Router, Konfiguration und Shard.

Durch die Skalierung des Routers können Server mehr Anfragen akzeptieren, aber die Schwerstarbeit findet auf den Shard-Servern statt.

Wie bei Elasticsearch werden MongoDB-Dokumente (standardmäßig) über _id zu ihren jeweiligen Shards geleitet. Zum Zeitpunkt der Abfrage benachrichtigt der Konfigurationsserver den Router, der die Abfrage fragmentiert, und der Router-Server verteilt dann die Abfrage und aggregiert die Ergebnisse.

Die Sharding-Fähigkeit von Redshift

Ein Amazon Redshift-Cluster besteht aus einem Leader-Knoten und mehreren Rechenknoten.

Der Leader-Knoten übernimmt die Zusammenstellung und Verteilung von Abfragen sowie die Aggregation von Zwischenergebnissen.

Im Gegensatz zu den Router-Servern von MongoDB ist der Leader-Knoten konsistent und kann nicht horizontal skaliert werden.

Dies schafft zwar einen Engpass, ermöglicht aber auch ein effizientes Caching kompilierter Ausführungspläne für beliebte Abfragen.

Aggregieren

Die Aggregationsfähigkeit von Elasticsearch

Dokumente innerhalb von Elasticsearch können nach exakten, Bereichs- oder sogar Zeit- und Geolokalisierungswerten gebuckelt werden.

Diese Buckets können durch verschachtelte Aggregation weiter in eine feinere Granularität gruppiert werden.

Metriken, einschließlich Mittelwerte und Standardabweichungen, können für jede Schicht berechnet werden, was die Möglichkeit bietet, eine Hierarchie von Analysen innerhalb einer einzigen Abfrage zu berechnen.

Da es sich um eine dokumentbasierte Speicherung handelt, leidet es unter der Einschränkung von Feldvergleichen innerhalb von Dokumenten.

Während es zum Beispiel gut filtern kann, wenn ein Feld follower größer als 10 ist, können wir nicht prüfen, ob followers größer als ein anderes Feld following ist.

Als Alternative können wir Skripte als benutzerdefinierte Prädikate einfügen. Diese Funktion eignet sich hervorragend für einmalige Analysen, aber die Leistung leidet in der Produktion.

Die Aggregationsfähigkeit von MongoDB

Die Aggregation Pipeline ist leistungsstark und schnell.

Wie der Name schon sagt, verarbeitet es die zurückgegebenen Daten schrittweise.

Jeder Schritt kann die Dokumente filtern, aggregieren und transformieren, neue Metriken einführen oder zuvor aggregierte Gruppen auflösen.

Da diese Operationen stufenweise durchgeführt werden und indem sichergestellt wird, dass Dokumente und Felder nur noch gefiltert werden, können die Speicherkosten minimiert werden. Im Vergleich zu Elasticsearch und sogar Redshift ist Aggregation Pipeline eine äußerst flexible Möglichkeit, die Daten anzuzeigen.

Trotz seiner Anpassungsfähigkeit leidet MongoDB unter dem gleichen Mangel an Feldvergleichen innerhalb von Dokumenten wie Elasticsearch.

Darüber hinaus erfordern einige Operationen, einschließlich $group , dass die Ergebnisse an den Master-Knoten übergeben werden.

Daher nutzen sie das verteilte Rechnen nicht.

Diejenigen, die mit der stufenweisen Pipeline-Berechnung nicht vertraut sind, werden bestimmte Aufgaben als unintuitiv empfinden. Beispielsweise würde das Summieren der Anzahl der Elemente in einem Array-Feld zwei Schritte erfordern: zuerst die $unwind und dann die $group -Operation.

Die Aggregierungsfähigkeit von Redshift

Die Vorteile von Amazon Redshift sind nicht zu unterschätzen.

Frustrierend langsame Aggregationen auf MongoDB bei der Analyse des mobilen Datenverkehrs werden von Amazon Redshift schnell gelöst.

Durch die Unterstützung von SQL können herkömmliche Datenbankingenieure ihre Abfragen problemlos zu Redshift migrieren.

Abgesehen von der Einarbeitungszeit ist SQL eine bewährte, skalierbare und leistungsstarke Abfragesprache, die Vergleiche zwischen Dokumenten und Zeilenfeldern problemlos unterstützt. Amazon Redshift verbessert seine Leistung weiter, indem es beliebte Abfragen, die auf den Rechenknoten ausgeführt werden, kompiliert und zwischenspeichert.

Als relationale Datenbank verfügt Amazon Redshift nicht über die Schemaflexibilität von MongoDB und Elasticsearch. Es ist für Lesevorgänge optimiert und leidet unter Leistungseinbußen während Aktualisierungen und Löschvorgängen.

Um die beste Lesezeit beizubehalten, müssen die Zeilen sortiert werden, was zusätzlichen Betriebsaufwand bedeutet.

Es ist auf diejenigen zugeschnitten, die Probleme im Petabyte-Bereich haben, es ist nicht billig und wahrscheinlich die Investition nicht wert, es sei denn, es gibt Skalierungsprobleme mit anderen Datenbanken.

Auswahl des Gewinners

In diesem Artikel haben wir drei verschiedene Technologien – Elasticsearch, MongoDB und Amazon Redshift – im Kontext des Data Engineering untersucht. Es gibt jedoch keinen klaren Gewinner, da jede dieser Technologien in ihrer Kategorie der Speichertypen führend ist.

Für das Data Engineering sind je nach Anwendungsfall einige Optionen besser als andere.

• MongoDB ist eine fantastische Starterdatenbank. Es bietet die gewünschte Flexibilität, wenn das Datenschema noch bestimmt werden muss. Allerdings übertrifft MongoDB bestimmte Anwendungsfälle, auf die sich andere Datenbanken spezialisiert haben, nicht.
• Während Elasticsearch ein ähnliches flüssiges Schema wie MongoDB bietet, ist es für mehrere Indizes und Textabfragen auf Kosten der Schreibleistung und Speichergröße optimiert. Daher sollten wir eine Migration zu Elasticsearch in Betracht ziehen, wenn wir feststellen, dass wir zahlreiche Indizes in MongoDB pflegen.
• Redshift erfordert ein vordefiniertes Datenschema und ihm fehlt die Anpassungsfähigkeit, die MongoDB bietet. Im Gegenzug übertrifft sie andere Datenbanken bei Abfragen, die nur einzelne (oder wenige) Spalten betreffen. Wenn es das Budget zulässt, ist Amazon Redshift eine tolle Geheimwaffe, wenn andere die Datenmenge nicht bewältigen können.