Wir leben in einer erstaunlichen Zeit, in der Sie schnell und einfach mehrere vorgefertigte Open-Source-Tools verbinden, sie gemäß den Ratschlägen von Stackoverflow bei ausgeschaltetem Bewusstsein einrichten können, ohne sich mit den „mehreren Buchstaben“ zu befassen, und sie starten können sie in den kommerziellen Betrieb zu überführen. Und wenn Sie aktualisieren/erweitern müssen oder jemand versehentlich ein paar Maschinen neu startet, stellen Sie fest, dass in der Realität eine Art obsessiver böser Traum begonnen hat, alles plötzlich bis zur Unkenntlichkeit komplizierter geworden ist, es kein Zurück mehr gibt, die Zukunft vage ist und sicherer, statt zu programmieren, Bienen züchten und Käse herstellen.
Nicht umsonst erwägen erfahrenere Kollegen, deren Kopf voller Bugs ist und die daher bereits grau sind, die unglaublich schnelle Bereitstellung von Paketen von „Containern“ in „Cubes“ auf Dutzenden von Servern in „modischen Sprachen“ mit integrierter Unterstützung für Asynchrone nicht blockierende E/A, lächeln Sie bescheiden. Und sie lesen stillschweigend weiterhin „man ps“, vertiefen sich in den „nginx“-Quellcode, bis ihnen die Augen bluten, und schreiben, schreiben, schreiben Unit-Tests. Kollegen wissen, dass das Interessanteste kommt, wenn „das alles“ eines Tages in der Nacht des Silvesterabends auf dem Spiel steht. Dabei hilft ihnen nur ein tiefes Verständnis der Natur von Unix, der gespeicherten TCP/IP-Statustabelle und grundlegender Sortier- und Suchalgorithmen. Um das System mit dem Glockenschlag wieder zum Leben zu erwecken.
Oh ja, ich war etwas abgelenkt, aber ich hoffe, es ist mir gelungen, den Zustand der Vorfreude zu vermitteln.
Heute möchte ich unsere Erfahrungen bei der Bereitstellung eines praktischen und kostengünstigen Stacks für DataLake teilen, der die meisten Analyseaufgaben im Unternehmen für völlig unterschiedliche Strukturbereiche löst.
Vor einiger Zeit kamen wir zu der Erkenntnis, dass Unternehmen zunehmend die Ergebnisse sowohl der Produkt- als auch der technischen Analyse benötigen (ganz zu schweigen vom i-Tüpfelchen in Form von maschinellem Lernen) und dass wir, um Trends und Risiken zu verstehen, diese sammeln und analysieren müssen immer mehr Metriken.
Grundlegende technische Analysen in Bitrix24
Vor einigen Jahren, gleichzeitig mit der Einführung des Bitrix24-Dienstes, haben wir aktiv Zeit und Ressourcen in die Schaffung einer einfachen und zuverlässigen Analyseplattform investiert, die dabei helfen würde, Probleme in der Infrastruktur schnell zu erkennen und den nächsten Schritt zu planen. Natürlich empfiehlt es sich, vorgefertigte Tools mitzunehmen, die möglichst einfach und verständlich sind. Daher wurde Nagios für die Überwachung und Munin für die Analyse und Visualisierung ausgewählt. Jetzt haben wir Tausende von Checks in Nagios, Hunderte von Charts in Munin und unsere Kollegen nutzen sie jeden Tag erfolgreich. Die Metriken sind klar, die Diagramme sind klar, das System funktioniert seit mehreren Jahren zuverlässig und es werden regelmäßig neue Tests und Diagramme hinzugefügt: Wenn wir einen neuen Dienst in Betrieb nehmen, fügen wir mehrere Tests und Diagramme hinzu. Viel Glück.
Finger on the Pulse – Fortgeschrittene technische Analysen
Der Wunsch, „so schnell wie möglich“ Informationen über Probleme zu erhalten, führte uns zu aktiven Experimenten mit einfachen und verständlichen Tools – pinba und xhprof.
Pinba schickte uns Statistiken in UDP-Paketen über die Betriebsgeschwindigkeit von Teilen von Webseiten in PHP, und wir konnten online im MySQL-Speicher (Pinba verfügt über eine eigene MySQL-Engine für schnelle Ereignisanalysen) eine kurze Liste von Problemen sehen und darauf reagieren ihnen. Und xhprof ermöglichte es uns automatisch, Diagramme der Ausführung der langsamsten PHP-Seiten von Kunden zu sammeln und zu analysieren, was dazu führen könnte – ruhig, Tee oder etwas Stärkeres einschenkend.
Vor einiger Zeit wurde das Toolkit um eine weitere recht einfache und verständliche Engine ergänzt, die auf dem Reverse-Indexing-Algorithmus basiert und perfekt in der legendären Lucene-Bibliothek implementiert ist – Elastic/Kibana. Die einfache Idee der Multithread-Aufzeichnung von Dokumenten in einem inversen Lucene-Index basierend auf Ereignissen in den Protokollen und einer schnellen Suche durch diese mithilfe der Facettenteilung erwies sich als wirklich nützlich.
Trotz des eher technischen Erscheinungsbilds von Visualisierungen in Kibana mit einfachen Konzepten wie „Eimer“, „nach oben fließen“ und der neu erfundenen Sprache der noch nicht völlig vergessenen relationalen Algebra, begann uns das Tool bei den folgenden Aufgaben gut zu helfen:
- Wie viele PHP-Fehler hatte der Bitrix24-Client in der letzten Stunde auf dem p1-Portal und welche? Verstehen, vergeben und schnell korrigieren.
- Wie viele Videoanrufe wurden in den letzten 24 Stunden auf Portalen in Deutschland in welcher Qualität getätigt und gab es Schwierigkeiten mit dem Kanal/Netzwerk?
- Wie gut funktioniert die Systemfunktionalität (unsere C-Erweiterung für PHP), die im neuesten Service-Update aus dem Quellcode kompiliert und für Kunden bereitgestellt wird? Gibt es Segfaults?
- Passen Kundendaten in den PHP-Speicher? Gibt es Fehler bezüglich der Überschreitung des den Prozessen zugewiesenen Speichers: „Nicht genügend Speicher“? Finden und neutralisieren.
Hier ist ein konkretes Beispiel. Trotz gründlicher und mehrstufiger Tests erhielt der Kunde mit einem sehr ungewöhnlichen Fall und beschädigten Eingabedaten einen ärgerlichen und unerwarteten Fehler, eine Sirene ertönte und der Prozess der schnellen Behebung begann:
Darüber hinaus können Sie mit kibana Benachrichtigungen für bestimmte Ereignisse organisieren, und schon nach kurzer Zeit wurde das Tool im Unternehmen von Dutzenden Mitarbeitern aus verschiedenen Abteilungen genutzt – vom technischen Support und der Entwicklung bis hin zur Qualitätssicherung.
Die Aktivitäten jeder Abteilung innerhalb des Unternehmens lassen sich jetzt bequem verfolgen und messen. Anstatt die Protokolle manuell auf Servern zu analysieren, müssen Sie die Protokollanalyse nur einmal einrichten und sie an den elastischen Cluster senden, um beispielsweise die Betrachtung im Kibana zu genießen Dashboard zeigt die Anzahl der verkauften zweiköpfigen Kätzchen, die im letzten Mondmonat auf einem 3D-Drucker gedruckt wurden.
Grundlegende Geschäftsanalysen
Jeder weiß, dass Business Analytics in Unternehmen oft mit der äußerst aktiven Nutzung von, ja, Excel beginnt. Aber die Hauptsache ist, dass es damit noch nicht zu Ende ist. Auch das cloudbasierte Google Analytics heizt das Feuer an – man gewöhnt sich schnell an die guten Dinge.
In unserem sich harmonisch entwickelnden Unternehmen tauchten hier und da „Propheten“ einer intensiveren Arbeit mit größeren Datenmengen auf. Der Bedarf an ausführlicheren und vielfältigeren Berichten begann sich regelmäßig zu zeigen, und durch die Bemühungen von Mitarbeitern aus verschiedenen Abteilungen wurde vor einiger Zeit eine einfache und praktische Lösung entwickelt – eine Kombination aus ClickHouse und PowerBI.
Diese flexible Lösung hat lange Zeit sehr geholfen, aber nach und nach kristallisierte sich heraus, dass ClickHouse kein Gummi ist und nicht auf diese Weise verspottet werden kann.
Hier ist es wichtig, gut zu verstehen, dass ClickHouse, wie Druid, wie Vertica, wie Amazon RedShift (das auf Postgres basiert), Analyse-Engines sind, die für ziemlich praktische Analysen optimiert sind (Summen, Aggregationen, Minimum-Maximum nach Spalte und einige mögliche Verknüpfungen). ), Weil im Gegensatz zu MySQL und anderen uns bekannten (zeilenorientierten) Datenbanken für die effiziente Speicherung von Spalten relationaler Tabellen organisiert.
Im Wesentlichen ist ClickHouse nur eine umfangreichere „Datenbank“ mit nicht sehr praktischer Punkt-für-Punkt-Einfügung (so ist es gedacht, alles ist in Ordnung), aber angenehmer Analyse und einer Reihe interessanter leistungsstarker Funktionen für die Arbeit mit Daten. Ja, Sie können sogar einen Cluster erstellen – aber Sie verstehen, dass das Einschlagen von Nägeln mit einem Mikroskop nicht ganz richtig ist und wir begannen, nach anderen Lösungen zu suchen.
Nachfrage nach Python und Analysten
Unser Unternehmen hat viele Entwickler, die seit 10–20 Jahren fast täglich Code in PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash schreiben. Es gibt auch viele erfahrene Systemadministratoren, die mehr als eine absolut unglaubliche Katastrophe erlebt haben, die nicht in die Gesetze der Statistik passt (z. B. wenn die Mehrheit der Festplatten in einem Raid-10 durch einen starken Blitzeinschlag zerstört wird). Unter solchen Umständen war lange Zeit nicht klar, was ein „Python-Analyst“ ist. Python ist wie PHP, nur ist der Name etwas länger und es gibt etwas weniger Spuren bewusstseinsverändernder Substanzen im Quellcode des Interpreters. Als jedoch immer mehr Analyseberichte erstellt wurden, begannen erfahrene Entwickler zunehmend zu verstehen, wie wichtig eine enge Spezialisierung auf Tools wie Numpy, Pandas, Matplotlib und Seaborn ist.
Die entscheidende Rolle spielte höchstwahrscheinlich die plötzliche Ohnmacht der Mitarbeiter aufgrund der Kombination der Wörter „logistische Regression“ und der Demonstration einer effektiven Berichterstattung über große Datenmengen mithilfe von, ja, ja, Pyspark.
Apache Spark, sein Funktionsparadigma, zu dem die relationale Algebra perfekt passt, und seine Fähigkeiten hinterließen bei Entwicklern, die an MySQL gewöhnt waren, einen solchen Eindruck, dass die Notwendigkeit, die Reihen mit erfahrenen Analysten zu verstärken, ganz klar wurde.
Weitere Startversuche von Apache Spark/Hadoop und was nicht ganz nach Drehbuch lief
Es wurde jedoch schnell klar, dass mit Spark systemisch etwas nicht stimmte oder man sich einfach besser die Hände waschen musste. Wenn der Hadoop/MapReduce/Lucene-Stack von ziemlich erfahrenen Programmierern erstellt wurde, was offensichtlich ist, wenn man sich den Quellcode in Java oder die Ideen von Doug Cutting in Lucene genau ansieht, dann ist Spark plötzlich in der exotischen Sprache Scala geschrieben aus praktischer Sicht sehr umstritten und befindet sich derzeit nicht in der Entwicklung. Und der regelmäßige Rückgang der Berechnungen im Spark-Cluster aufgrund der unlogischen und nicht sehr transparenten Arbeit mit der Speicherzuweisung für Reduzierungsoperationen (viele Schlüssel kommen gleichzeitig an) hat einen Heiligenschein um ihn herum geschaffen, der Raum für Wachstum bietet. Darüber hinaus wurde die Situation durch eine große Anzahl seltsamer offener Ports, temporäre Dateien, die an den unverständlichsten Stellen wuchsen, und eine Menge Jar-Abhängigkeiten verschärft – was bei Systemadministratoren ein seit ihrer Kindheit bekanntes Gefühl hervorrief: heftigen Hass (oder vielleicht sie mussten ihre Hände mit Seife waschen).
Infolgedessen haben wir mehrere interne Analyseprojekte „überlebt“, die Apache Spark (einschließlich Spark Streaming, Spark SQL) und das Hadoop-Ökosystem (usw.) aktiv nutzen. Trotz der Tatsache, dass wir im Laufe der Zeit gelernt haben, „es“ recht gut vorzubereiten und zu überwachen, und „es“ aufgrund von Änderungen in der Art der Daten und dem Ungleichgewicht des einheitlichen RDD-Hashing praktisch nicht mehr plötzlich abstürzte, besteht der Wunsch, etwas bereits Fertiges zu übernehmen , aktualisiert und verwaltet irgendwo in der Cloud, wurde immer stärker. Zu diesem Zeitpunkt versuchten wir, die vorgefertigte Cloud-Assembly von Amazon Web Services zu nutzen – und versuchte anschließend, Probleme damit zu lösen. EMR ist Apache Spark, das von Amazon mit zusätzlicher Software aus dem Ökosystem erstellt wurde, ähnlich wie Cloudera/Hortonworks-Builds.
Die Speicherung von Rubber-Dateien für Analysen ist dringend erforderlich
Die Erfahrung, Hadoop/Spark mit Verbrennungen an verschiedenen Körperteilen zu „kochen“, war nicht umsonst. Der Bedarf, einen einzigen, kostengünstigen und zuverlässigen Dateispeicher zu schaffen, der resistent gegen Hardwareausfälle ist und in dem es möglich wäre, Dateien in unterschiedlichen Formaten aus unterschiedlichen Systemen zu speichern und aus diesen Daten effiziente und zeiteffiziente Muster für Berichte zu erstellen, wurde immer größer klar.
Ich wollte auch, dass die Aktualisierung der Software dieser Plattform nicht zu einem Silvester-Albtraum wird, bei dem 20-seitige Java-Traces gelesen und kilometerlange detaillierte Protokolle des Clusters mithilfe des Spark History Servers und einer hintergrundbeleuchteten Lupe analysiert werden. Ich wollte ein einfaches und transparentes Tool haben, das kein regelmäßiges Eintauchen unter die Haube erfordert, wenn die Standard-MapReduce-Anfrage des Entwicklers nicht mehr ausgeführt wird, weil der Worker zur Datenreduzierung aufgrund eines nicht sehr gut gewählten Algorithmus zur Quelldatenpartitionierung nicht mehr genügend Speicher hat.
Ist Amazon S3 ein Kandidat für DataLake?
Die Erfahrung mit Hadoop/MapReduce hat uns gelehrt, dass wir ein skalierbares, zuverlässiges Dateisystem und darüber liegende skalierbare Worker benötigen, die näher an die Daten herankommen, um die Daten nicht über das Netzwerk zu treiben. Arbeitnehmer sollten in der Lage sein, Daten in verschiedenen Formaten zu lesen, möglichst jedoch keine unnötigen Informationen zu lesen und Daten vorab in für Arbeitnehmer geeigneten Formaten zu speichern.
Noch einmal die Grundidee. Es besteht kein Wunsch, große Datenmengen in eine einzelne Cluster-Analyse-Engine zu „gießen“, die früher oder später ersticken wird und Sie sie hässlich teilen müssen. Ich möchte Dateien, einfach nur Dateien, in einem verständlichen Format speichern und mithilfe verschiedener, aber verständlicher Tools effektive analytische Abfragen daran durchführen. Und es wird immer mehr Dateien in unterschiedlichen Formaten geben. Und es ist besser, nicht die Engine, sondern die Quelldaten zu teilen. Wir brauchen einen erweiterbaren und universellen DataLake, haben wir entschieden ...
Was wäre, wenn Sie Dateien im bekannten und bekannten skalierbaren Cloud-Speicher Amazon S3 speichern würden, ohne Ihre eigenen Daten aus Hadoop vorbereiten zu müssen?
Es ist klar, dass die personenbezogenen Daten „gering“ sind, aber was ist mit anderen Daten, wenn wir sie nach draußen bringen und „effektiv steuern“?
Cluster-BigData-Analyse-Ökosystem von Amazon Web Services – in ganz einfachen Worten
Nach unseren Erfahrungen mit AWS zu urteilen, wird Apache Hadoop/MapReduce dort seit langem unter verschiedenen Saucen aktiv eingesetzt, beispielsweise im DataPipeline-Dienst (ich beneide meine Kollegen, sie haben gelernt, wie man es richtig zubereitet). Hier richten wir Sicherungen verschiedener Dienste aus DynamoDB-Tabellen ein:
Und sie laufen seit mehreren Jahren regelmäßig wie ein Uhrwerk auf eingebetteten Hadoop/MapReduce-Clustern. „Einstellen und vergessen“:
Sie können sich auch effektiv am Daten-Satanismus beteiligen, indem Sie Jupiter-Laptops für Analysten in der Cloud einrichten und den AWS SageMaker-Service nutzen, um KI-Modelle zu trainieren und im Kampf einzusetzen. So sieht es bei uns aus:
Und ja, Sie können für sich selbst oder einen Analysten einen Laptop in der Cloud besorgen und ihn an einen Hadoop/Spark-Cluster anschließen, die Berechnungen durchführen und dann alles auf den Punkt bringen:
Wirklich praktisch für einzelne Analyseprojekte und für einige haben wir den EMR-Dienst erfolgreich für umfangreiche Berechnungen und Analysen genutzt. Wie wäre es mit einer Systemlösung für DataLake, wird das funktionieren? In diesem Moment waren wir am Rande von Hoffnung und Verzweiflung und setzten die Suche fort.
AWS Glue – ordentlich verpackter Apache Spark auf Steroiden
Es stellte sich heraus, dass AWS über eine eigene Version des „Hive/Pig/Spark“-Stacks verfügt. Die Rolle von Hive, d.h. Der Katalog der Dateien und ihrer Typen in DataLake wird vom Dienst „Datenkatalog“ durchgeführt, der seine Kompatibilität mit dem Apache Hive-Format nicht verbirgt. Sie müssen diesem Dienst Informationen darüber hinzufügen, wo sich Ihre Dateien befinden und in welchem Format sie vorliegen. Die Daten können nicht nur in s3, sondern auch in der Datenbank liegen, aber das ist nicht Gegenstand dieses Beitrags. So ist unser DataLake-Datenverzeichnis organisiert:
Die Dateien sind registriert, super. Wenn die Dateien aktualisiert wurden, starten wir Crawler entweder manuell oder nach einem Zeitplan, der die Informationen über sie aus dem Lake aktualisiert und speichert. Dann können die Daten aus dem See verarbeitet und die Ergebnisse irgendwo hochgeladen werden. Im einfachsten Fall laden wir auch auf s3 hoch. Die Datenverarbeitung kann überall erfolgen, es wird jedoch empfohlen, die Verarbeitung auf einem Apache Spark-Cluster mit erweiterten Funktionen über die AWS Glue-API zu konfigurieren. Tatsächlich können Sie den guten alten und bekannten Python-Code mithilfe der Pyspark-Bibliothek verwenden und seine Ausführung auf N Knoten eines Clusters mit einer gewissen Kapazität mit Überwachung konfigurieren, ohne in die Eingeweide von Hadoop einzutauchen, Docker-Moker-Container zu ziehen und Abhängigkeitskonflikte zu beseitigen .
Wieder einmal eine einfache Idee. Es besteht keine Notwendigkeit, Apache Spark zu konfigurieren. Sie müssen lediglich Python-Code für Pyspark schreiben, ihn lokal auf Ihrem Desktop testen und ihn dann auf einem großen Cluster in der Cloud ausführen und dabei angeben, wo sich die Quelldaten befinden und wo das Ergebnis abgelegt werden soll. Manchmal ist dies notwendig und nützlich, und so richten wir es ein:
Wenn Sie also etwas auf einem Spark-Cluster mithilfe von Daten in s3 berechnen müssen, schreiben wir Code in Python/Pyspark, testen ihn und wünschen der Cloud viel Glück.
Was ist mit der Orchestrierung? Was wäre, wenn die Aufgabe herunterfiele und verschwand? Ja, es wird vorgeschlagen, eine schöne Pipeline im Apache Pig-Stil zu erstellen, und wir haben sie sogar ausprobiert, aber vorerst haben wir uns entschieden, unsere stark angepasste Orchestrierung in PHP und JavaScript zu verwenden (ich verstehe, es gibt kognitive Dissonanzen, aber es funktioniert z. B Jahre und ohne Fehler).
Das Format der im Lake gespeicherten Dateien ist der Schlüssel zur Leistung
Es ist sehr, sehr wichtig, zwei weitere wichtige Punkte zu verstehen. Damit Abfragen zu Dateidaten im Lake so schnell wie möglich ausgeführt werden und die Leistung beim Hinzufügen neuer Informationen nicht beeinträchtigt wird, müssen Sie Folgendes tun:
- Speichern Sie Dateispalten separat (damit Sie nicht alle Zeilen lesen müssen, um zu verstehen, was in den Spalten steht). Hierfür haben wir das Parkettformat mit Komprimierung gewählt
- Es ist sehr wichtig, Dateien in folgende Ordner zu unterteilen: Sprache, Jahr, Monat, Tag, Woche. Engines, die diese Art von Sharding verstehen, schauen sich nur die notwendigen Ordner an, ohne alle Daten nacheinander zu sichten.
Im Wesentlichen legen Sie auf diese Weise die Quelldaten in der effizientesten Form für die darüber hängenden Analyse-Engines an, die selbst in Shard-Ordnern selektiv nur die erforderlichen Spalten aus Dateien eingeben und lesen können. Sie müssen die Daten nirgendwo „auffüllen“ (der Speicher platzt einfach) – legen Sie sie einfach sofort und mit Bedacht im richtigen Format im Dateisystem ab. Hier sollte natürlich klar sein, dass das Speichern einer riesigen CSV-Datei in DataLake, die erst Zeile für Zeile vom Cluster gelesen werden muss, um die Spalten zu extrahieren, nicht sehr ratsam ist. Denken Sie noch einmal über die beiden oben genannten Punkte nach, wenn noch nicht klar ist, warum das alles passiert.
AWS Athena – der Alleskönner
Und dann, als wir einen See anlegten, stießen wir zufällig auf Amazon Athena. Plötzlich stellte sich heraus, dass man durch die sorgfältige Anordnung unserer riesigen Protokolldateien in Ordner-Shards im richtigen (Parkett-)Spaltenformat sehr schnell äußerst informative Auswahlen daraus treffen und Berichte OHNE Apache Spark/Glue-Cluster erstellen kann.
Die auf Daten basierende Athena-Engine in S3 basiert auf dem legendären - ein Vertreter der MPP-Familie (Massive Parallel Processing) von Ansätzen zur Datenverarbeitung, die Daten dorthin bringen, wo sie sind, von s3 und Hadoop bis hin zu Cassandra und gewöhnlichen Textdateien. Sie müssen Athena nur bitten, eine SQL-Abfrage auszuführen, und dann funktioniert alles „schnell und automatisch“. Es ist wichtig zu beachten, dass Athena „intelligent“ ist, nur die erforderlichen Shard-Ordner durchsucht und nur die in der Anfrage benötigten Spalten liest.
Interessant ist auch die Preisgestaltung für Anfragen an Athena. Wir bezahlen . Diese. nicht für die Anzahl der Maschinen im Cluster pro Minute, sondern... für die Daten, die tatsächlich auf 100–500 Maschinen gescannt werden, also nur die Daten, die zum Abschließen der Anfrage erforderlich sind.
Und da wir nur die notwendigen Spalten aus korrekt geshardten Ordnern anforderten, stellte sich heraus, dass uns der Athena-Dienst mehrere Dutzend Dollar pro Monat kostete. Nun ja, großartig, fast kostenlos im Vergleich zur Analyse auf Clustern!
Übrigens, so teilen wir unsere Daten in s3 auf:
Infolgedessen begannen in kurzer Zeit völlig unterschiedliche Abteilungen des Unternehmens, von der Informationssicherheit bis zur Analyse, aktiv Anfragen an Athena zu richten und über relativ lange Zeiträume in Sekundenschnelle nützliche Antworten aus „großen“ Daten zu erhalten: Monate, ein halbes Jahr usw. P.
Aber wir gingen noch einen Schritt weiter und begannen, in der Cloud nach Antworten zu suchen : Ein Analyst schreibt eine SQL-Abfrage in einer vertrauten Konsole, die auf 100–500 Maschinen „für ein paar Cent“ Daten an s3 sendet und normalerweise innerhalb weniger Sekunden eine Antwort zurückgibt. Komfortabel. Und schnell. Ich kann es immer noch nicht glauben.
Nachdem wir uns entschieden hatten, Daten in s3 zu speichern, in einem effizienten Spaltenformat und mit angemessener Aufteilung der Daten in Ordner, erhielten wir DataLake und eine schnelle und kostengünstige Analyse-Engine – kostenlos. Und er wurde im Unternehmen sehr beliebt, weil... versteht SQL und arbeitet um Größenordnungen schneller als durch Starten/Stoppen/Einrichten von Clustern. „Und wenn das Ergebnis das gleiche ist, warum dann mehr bezahlen?“
Eine Anfrage an Athena sieht in etwa so aus. Auf Wunsch können Sie natürlich auch ausreichend formen , aber wir beschränken uns auf eine einfache Gruppierung. Sehen wir uns an, welche Antwortcodes der Client vor einigen Wochen in den Webserverprotokollen hatte, und stellen wir sicher, dass keine Fehler vorliegen:
Befund
Nachdem wir einen zwar langen, aber schmerzhaften Weg zurückgelegt und die Risiken, den Grad der Komplexität und die Kosten des Supports ständig angemessen bewertet hatten, haben wir eine Lösung für DataLake und Analytics gefunden, die uns sowohl hinsichtlich der Geschwindigkeit als auch der Betriebskosten immer wieder begeistert.
Es stellte sich heraus, dass der Aufbau eines effektiven, schnell und kostengünstig zu betreibenden DataLake für die Bedürfnisse völlig unterschiedlicher Abteilungen des Unternehmens völlig in den Fähigkeiten selbst erfahrener Entwickler liegt, die noch nie als Architekten gearbeitet haben und nicht wissen, wie man damit Quadrate auf Quadraten zeichnet Pfeile und kennen 50 Begriffe aus dem Hadoop-Ökosystem.
Zu Beginn der Reise spaltete sich mein Kopf von den vielen wilden Zoos offener und geschlossener Software und dem Verständnis für die Last der Verantwortung gegenüber den Nachkommen. Beginnen Sie einfach mit dem Aufbau Ihres DataLake mit einfachen Tools: Nagios/Munin -> Elastic/Kibana -> Hadoop/Spark/S3..., sammeln Sie Feedback und verstehen Sie die Physik der ablaufenden Prozesse tiefgreifend. Alles, was komplex und undurchsichtig ist – geben Sie es Ihren Feinden und Konkurrenten.
Wenn Sie nicht in die Cloud gehen möchten und Open-Source-Projekte unterstützen, aktualisieren und patchen möchten, können Sie lokal auf kostengünstigen Büromaschinen mit Hadoop und Presto ein ähnliches Schema wie unseres erstellen. Die Hauptsache ist, nicht innezuhalten und voranzukommen, sondern zu zählen, nach einfachen und klaren Lösungen zu suchen, und alles wird auf jeden Fall klappen! Viel Glück an alle und wir sehen uns wieder!
Source: habr.com