In den letzten Jahren hatte ich viele Gespräche mit Freunden und Kollegen, die frustriert waren, wie unergründlich komplex das Ökosystem der Dateninfrastruktur ist. Obwohl nicht ganz so schlimm wie die Front-End-Welt, ändern sich die Dinge schnell genug, um eine Buzzword-Suppe zu kreieren.

Als Anfänger ist es eine große Herausforderung zu entscheiden, welche Tools für Sie geeignet sind. Die Apache Foundation listet 38 Projekte im Abschnitt „Big Data“ auf, und diese Tools haben jede Menge Überschneidungen bei den Problemen, die sie angeblich lösen. Zum Beispiel sind Flink, Samza, Storm und Spark Streaming „Distributed Stream Processing Engines“, Apex und Beam „unify Stream and Batch Processing“.

In diesem Beitrag hoffe ich, Ihnen beim Aufbau der Dateninfrastruktur beim Navigieren durch die Optionen behilflich zu sein. Dies sind ungefähr die Schritte, denen ich heute folgen würde, basierend auf meinen Erfahrungen im letzten Jahrzehnt und Gesprächen mit Kollegen, die in diesem Bereich arbeiten.

Zu Beginn Ihres Projekts haben Sie wahrscheinlich nur das Ziel, „Erkenntnisse aus meinen Daten zu gewinnen“. Die Zuordnung zu bestimmten Technologien ist äußerst entmutigend. Sie haben wahrscheinlich kein gutes Gespür dafür, welche Tools beliebt sind, was „Stream“ oder „Batch“ bedeutet oder ob Sie überhaupt eine Dateninfrastruktur benötigen.

In diesem Beitrag hoffe ich, Ihnen eine Anleitung zu geben, mit der Sie schnell loslegen und den Wert Ihrer Daten extrahieren können. Ich glaube fest daran, die Dinge so lange wie möglich einfach zu halten und Komplexität nur dann einzuführen, wenn sie für die Skalierbarkeit erforderlich ist. Dieser Beitrag folgt diesem Bogen über drei Stufen. In vielerlei Hinsicht zeichnet es die Schritte des Aufbaus der Dateninfrastruktur nach, die ich in den letzten Jahren verfolgt habe.

Beachten Sie, dass es keinen richtigen Weg gibt, eine Dateninfrastruktur zu erstellen. Für die Experten, die dies lesen, haben Sie möglicherweise Alternativen zu den hier vorgeschlagenen Lösungen bevorzugt. Das ist fantastisch und unterstreicht die Vielfalt der erstaunlichen Tools, die wir heutzutage haben. Wir haben einen sehr langen Weg zurückgelegt, als Hadoop MapReduce alles war, was wir hatten.

Also hier ist die Sache: Sie haben wahrscheinlich noch keine „Big Data“. Fast 4 Jahre später ist Chris Stucchios Artikel 2013 Verwenden Sie Hadoop nicht immer noch auf dem Punkt. Wenn Sie weniger als 5 TB Daten haben, fangen Sie klein an. Dies erspart Ihnen betriebliche Kopfschmerzen bei der Wartung von Systemen, die Sie noch nicht benötigen. Aber hey, wenn Sie 3am Fire Drills von Job failures lieben, können Sie diesen Abschnitt überspringen …

Andernfalls halten Sie sich von allen Buzzword-Technologien am Anfang fern und konzentrieren Sie sich auf zwei Dinge: (1) Machen Sie Ihre Daten in SQL abfragbar und (2) Wählen Sie ein BI-Tool. Diese werden das „Hallo, Welt“ -Backbone für Ihre gesamte zukünftige Dateninfrastruktur sein.

Alles in SQL

Dies ist wirklich wichtig, da es Daten für die gesamte Organisation freischaltet. Mit seltenen Ausnahmen für die unerschrockensten Marketingleute werden Sie Ihre nicht-technischen Kollegen niemals davon überzeugen, Kibana zu lernen, einige Protokolle zu greppen oder die obskure Syntax Ihres NoSQL-Datenspeichers zu verwenden.

Die Bereitstellung von SQL-Zugriff ermöglicht es dem gesamten Unternehmen, Self-Service-Analysten zu werden und Ihr bereits gestrecktes Engineering-Team aus dem kritischen Pfad herauszuholen. Außerdem wird jeder zu einem kostenlosen QS-Team für Ihre Daten. Das „Hey, diese Zahlen sehen irgendwie komisch aus …“ ist von unschätzbarem Wert, um Fehler in Ihren Daten und sogar in Ihrem Produkt zu finden.

Wenn Ihr primärer Datenspeicher eine relationale Datenbank wie PostgreSQL oder MySQL ist, ist dies sehr einfach. Sie können einfach ein Lesereplikat einrichten, den Zugriff bereitstellen und fertig.

Mit einer NoSQL-Datenbank wie ElasticSearch, MongoDB oder DynamoDB müssen Sie mehr Arbeit leisten, um Ihre Daten zu konvertieren und in eine SQL-Datenbank einzufügen. Wenn Sie neu in der Datenwelt sind, nennen wir dies eine ETL-Pipeline. Vermeiden Sie es, dies nach Möglichkeit selbst zu erstellen, da die Verkabelung einer Standardlösung bei kleinen Datenmengen viel kostengünstiger ist. Abhängig von Ihrer vorhandenen Infrastruktur gibt es möglicherweise einen Cloud-ETL-Anbieter wie Segment, den Sie nutzen können.

Wenn Sie feststellen, dass Sie Ihre eigenen Datenpipelines erstellen müssen, halten Sie diese zunächst äußerst einfach. Schreiben Sie ein Skript, um Aktualisierungen regelmäßig aus Ihrer Datenbank zu sichern, und schreiben Sie sie an einen Ort, der mit SQL abgefragt werden kann.

Die Geschichte für die Bündelung von Daten aus 3rd-Party-Quellen ist ähnlich wie bei NoSQL-Datenbanken. Verwenden Sie einen ETL-as-a-Service-Anbieter oder schreiben Sie ein einfaches Skript und hinterlegen Sie Ihre Daten einfach in einer SQL-abfragbaren Datenbank.

Richten Sie eine Maschine ein, um Ihre ETL-Skripte als täglichen Cron auszuführen, und Sie können loslegen.

BI-Tool

Ein gutes BI-Tool ist ein wichtiger Teil des Verständnisses Ihrer Daten. Einige großartige Tools, die Sie in Betracht ziehen sollten, sind Chartio, Mode Analytics und Periscope Data — jedes dieser Tools sollte hervorragend funktionieren, um Ihre Analysen auf den Weg zu bringen. In den meisten Fällen können Sie diese Tools mit einer schnellen Konfiguration direkt auf Ihre SQL-Datenbank verweisen und direkt in die Erstellung von Dashboards eintauchen.

Hier ist das „Hallo, Welt“ der Dateninfrastruktur:

Stufe 1: Die kleine Datenpipeline „Hallo, Welt“

Stufe 2: Nennen wir es „mittlere“ Daten

Zu diesem Zeitpunkt schweben mehr als ein paar Terabyte herum, und Ihre cron + Skript-ETL hält nicht ganz mit. Möglicherweise haben Sie Datenspeicher vermehrt und verfügen über eine heterogene Mischung aus SQL- und NoSQL-Backends. Möglicherweise haben Sie jetzt auch eine Handvoll Dritter, von denen Sie Daten sammeln. Schließlich haben Sie möglicherweise mehrere Stufen in Ihren ETL-Pipelines mit einigen Abhängigkeiten zwischen den Schritten.

Workflow-Management & Automatisierung

Der erste Schritt in dieser Phase sollte die Einrichtung von Airflow zur Verwaltung Ihrer ETL-Pipelines sein. Mit Airflow können Sie Jobs in regelmäßigen Abständen planen und sowohl zeitliche als auch logische Abhängigkeiten zwischen Jobs ausdrücken. Es ist auch ein großartiger Ort in Ihrer Infrastruktur, um Job-Wiederholungsversuche hinzuzufügen und & Warnungen für Aufgabenfehler zu überwachen. Es ist ein laufender Witz, dass jedes Startup ab einer bestimmten Größe seinen eigenen Workflow Manager / Job Scheduler schreibt. Unter anderem schrieb Spotify Luigi und Pinterest Pinball. Diese haben jedoch weniger Dynamik in der Community und es fehlen einige Funktionen in Bezug auf den Luftstrom.

Erstellen von ETL-Pipelines

Wenn Ihr Unternehmen wächst, werden sich Ihre ETL-Pipeline-Anforderungen erheblich ändern. Sie müssen mit dem Aufbau einer skalierbareren Infrastruktur beginnen, da ein einzelnes Skript diese nicht mehr schneidet. Ihre Ziele werden sich wahrscheinlich auch von der einfachen Aktivierung des SQL-Zugriffs auf die Unterstützung anderer nachgelagerter Jobs erstrecken, die dieselben Daten verarbeiten.

schließlich werden einfache Pipelines nicht skaliert

Um diesen sich ändernden Anforderungen gerecht zu werden, sollten Sie Ihre ETL-Skripte so konvertieren, dass sie als verteilter Job in einem Cluster ausgeführt werden. Die Anzahl der möglichen Lösungen ist hier absolut überwältigend. Ich würde dringend empfehlen, mit Apache Spark zu beginnen. Spark hat eine riesige, sehr aktive Community, skaliert gut und ist ziemlich einfach schnell zum Laufen zu bringen. Auf AWS können Sie Spark mit EMR ausführen; für GCP mit Cloud Dataproc. Wenn Sie Daten aus einer relationalen Datenbank aufnehmen, ist Apache Sqoop so ziemlich der Standard.

An diesem Punkt wird Ihre ETL-Infrastruktur wie Pipeline-Phasen von Jobs aussehen, die die drei ETL-Verben implementieren: Extrahieren Sie Daten aus Quellen, transformieren Sie diese Daten in standardisierte Formate im persistenten Speicher und laden Sie sie in einen SQL-abfragbaren Datenspeicher.

Data Warehouse

Zu diesem Zeitpunkt bleibt das Abrufen aller Ihrer Daten in SQL eine Priorität, aber dies ist die Zeit, in der Sie mit dem Aufbau eines „echten“ Data Warehouse beginnen möchten.

Für diejenigen, die gerade erst anfangen, würde ich die Verwendung von BigQuery empfehlen. BigQuery ist einfach einzurichten (Sie können Datensätze einfach als JSON laden), unterstützt verschachtelte / komplexe Datentypen und ist vollständig verwaltet / serverlos, sodass Sie nicht mehr Infrastruktur warten müssen. Wie bei vielen der Empfehlungen hier stehen Alternativen zu BigQuery zur Verfügung: auf AWS, Redshift und vor Ort, Presto. Ich bevorzuge BigQuery gegenüber Redshift aufgrund seines serverlosen Designs, der einfachen Konfiguration der richtigen Sicherheit / Überwachung und der Unterstützung komplexer Typen. Presto ist eine Überlegung wert, wenn Sie eine harte Anforderung an On-Prem haben.

Wenn Sie über die Einrichtung Ihres Data Warehouses nachdenken, ist es ein praktisches Muster, ein 2-stufiges Modell zu verwenden, bei dem unverarbeitete Daten direkt in einer Reihe von Tabellen landen und ein zweiter Job diese Daten in „sauberere“ Tabellen nachverarbeitet.

Nutzen Sie diese Übersichtstabellen als Gelegenheit, einen kuratierten Einblick in Ihr Unternehmen zu erhalten. Für jede der wichtigsten Entitäten in Ihrem Unternehmen sollten Sie eine Tabelle mit allen Metriken/KPIs und Dimensionen erstellen und verwalten, die Sie häufig zur Analyse dieser Entität verwenden. Beispielsweise kann eine Tabelle „Benutzer“ Metriken wie Anmeldezeit, Anzahl der Käufe und Dimensionen wie geografischer Standort oder Akquisitionskanal enthalten.

Am Ende sollte Ihre Infrastruktur ungefähr so aussehen:

Stufe 2: die „mittlere“ Datenpipeline

🚀 Stufe 3: Going big

Mit den richtigen Fundamenten muss weiteres Wachstum nicht schmerzhaft sein. Sie können oft einfach damit auskommen, Hardware auf das Problem des Umgangs mit erhöhten Datenmengen zu werfen.

Die herausforderndsten Probleme in dieser Zeit sind oft nicht nur der rohe Maßstab, sondern die wachsenden Anforderungen. Beispielsweise müssen Sie A/B-Tests unterstützen, Modelle für maschinelles Lernen trainieren oder transformierte Daten in einen ElasticSearch-Cluster leiten.

Einige Dinge, die Sie in dieser Phase beachten sollten:

  • Nahezu in Echtzeit: Sie werden wahrscheinlich erst viel später eine verteilte Warteschlange oder eine nahezu echtzeitfähige Infrastruktur benötigen, als Sie vielleicht denken. Es bringt eine Menge zusätzlicher Komplexität mit sich, um alle möglichen Fehlermodi zu handhaben, was sich nicht frühzeitig lohnt. Sobald das ROI-Kalkül Sinn macht, versuchen Sie es mit Kafka oder Cloud Pub / Sub.
  • Skalierbarkeit: Bei einem einzelnen monolithischen Spark-Cluster treten mit ziemlicher Sicherheit Probleme mit Ressourcenkonflikten auf. Wenn Sie dies tun, lohnt es sich, vollständig elastische Spark-Cluster mit Jobbereich zu erkunden.
  • Sicherheit & Auditing: Irgendwann möchten Sie möglicherweise detailliertere Zugriffskontrollen für Ihre Data Warehouse-Daten erzwingen. Wenn Sie BigQuery verwenden, können Sie den Datensatzzugriff für Google Groups bereitstellen und diesen Zugriff mithilfe von Deployment Manager programmgesteuert verwalten. BigQuery bietet auch Überwachungsprotokolle, um Benutzerabfragen zu verstehen. Andere Tools wie Apache Knox und Apache Sentry sind für On-Prem-Sicherheitslösungen verfügbar.
  • A / B-Tests: Für den Aufbau interner A / B-Tests und die Unterstützung von Experimenten gibt es leider nicht viele Standardlösungen. Das Erstellen einer Pipeline von Spark-Jobs, die Tabellen in Ihrem Data Warehouse füllen, ist wahrscheinlich die beste Wahl.
  • Maschinelles Lernen: Für die Feature-Extraktion können Sie zusätzliche Datenpipelines in Spark erstellen. Für die Modelle selbst sollten Sie wieder klein anfangen. Ihre verarbeiteten Features sind wahrscheinlich klein genug, um auf eine Maschine zu passen, sodass Sie Modelle mit scikit-learn oder TensorFlow trainieren können. Wenn eine Maschine nicht mehr ausreicht, können Sie Spark MLlib oder Distributed TensorFlow verwenden.

Die Zukunft

Es ist spannend zu sehen, wie sehr sich das Ökosystem der Dateninfrastruktur in den letzten zehn Jahren verbessert hat. Wir haben einen langen Weg vom Babysitten von Hadoop-Clustern und Gymnastik zurückgelegt, um unsere Datenverarbeitungslogik in Karten und Diagramme in umständlichem Java zu zwingen. Damals fühlte sich der Aufbau einer Dateninfrastruktur an, als würde man versuchen, mit einem Spielzeughammer einen Wolkenkratzer zu bauen.

Heute haben wir eine erstaunliche Vielfalt an Werkzeugen. Spark hat eindeutig als Alleskönner Ersatz für Hadoop MapReduce dominiert; das Gleiche passiert mit TensorFlow als Plattform für maschinelles Lernen. Mit sehr wenigen Ausnahmen müssen Sie heutzutage keine Infrastruktur oder Tools von Grund auf neu erstellen, und Sie müssen wahrscheinlich keine physischen Server verwalten. Der Wolkenkratzer ist schon da, Sie müssen nur Ihre Lackfarben auswählen.

die serverlose Zukunft – es wird total so sein

Mit Blick auf die Zukunft erwarte ich, dass sich die Dateninfrastruktur und die Tools weiter in Richtung vollständig serverloser Plattformen bewegen werden — DataBricks hat gerade ein solches Angebot für Spark angekündigt. Die serverlose Infrastruktur ermöglicht eine elegante Trennung der Bedenken: Die Cloud-Anbieter können sich um Hardware, Devops und Tools kümmern, sodass sich die Ingenieure auf die Probleme konzentrieren können, die für ihr Unternehmen einzigartig sind (und auf sie abgestimmt sind). Die Zukunft ist eine ohne Hardwarefehler, ZooKeeper-Freakouts oder Probleme mit YARN-Ressourcenkonflikten, und das ist wirklich cool.

Bearbeiten: Hinzufügen von Links zu einigen früheren Beiträgen, die ich über die Dateninfrastruktur von Thumbtack geschrieben habe:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

lg