Wir leben in einer erstaunlichen Zeit, in der man schnell und einfach mehrere fertige Open-Source-Tools zusammenschalten, sie mit einem "abgeschalteten Bewusstsein" nach den RatschlĂ€gen von Stackoverflow konfigurieren kann, ohne sich mit "vielen Buchstaben" auseinanderzusetzen und sie in den kommerziellen Betrieb nehmen kann. Doch wenn es Zeit wird, sich zu aktualisieren oder zu erweitern oder wenn jemand versehentlich ein paar Maschinen neu startet â wird einem bewusst, dass man in einen zwangshaften schlechten Traum aufgewacht ist, alles hat sich plötzlich unkenntlich kompliziert, der RĂŒckweg ist versperrt, die Zukunft ist ungewiss und es wĂ€re sicherer, anstatt Programmierung Bienen zu halten und KĂ€se zu machen.
Es ist kein Zufall, dass erfahrene Kollegen, die mit Bugs ĂŒberhĂ€uft und bereits grau geworden sind, das unglaublich schnelle Ausrollen von "Containern" in "Kubik" auf Dutzenden von Servern in "modernen Sprachen" mit integrierter UnterstĂŒtzung fĂŒr asynchronen, nicht blockierenden Input/Output betrachten â bescheiden lĂ€cheln. Und still wiederholen sie "man ps", verlieren sich bis zum Bluten in die Quellcodes von "nginx" und schreiben-schreiben-schreiben Unit-Tests. Die Kollegen wissen, dass das Interessanteste noch bevorsteht, wenn "das alles" irgendwann ĂŒber Nacht zu einem Paket zum Neuen Jahr wird. Und ihnen kann nur ein tiefes VerstĂ€ndnis der Unix-Natur, eine einstudierte TCP/IP-Zustandstabelle und grundlegende Sortier- und Suchalgorithmen helfen. Um zum Glockenschlag das System wieder zum Leben zu erwecken.
Ach ja, ich habe mich etwas abgelenkt, aber ich hoffe, ich konnte den Zustand der Vorfreude vermitteln.
Heute möchte ich unsere Erfahrungen mit der Bereitstellung eines benutzerfreundlichen und kostengĂŒnstigen Stacks fĂŒr DataLake teilen, der die meisten analytischen Aufgaben im Unternehmen fĂŒr ganz verschiedene Abteilungen löst.
Vor einiger Zeit kamen wir zu dem VerstĂ€ndnis, dass die Unternehmen zunehmend die FrĂŒchte sowohl der produktbezogenen als auch der technischen Analytik benötigen (geschweige denn die Kirschen auf der Torte in Form von Machine Learning), und um Trends und Risiken zu verstehen â mĂŒssen immer mehr Metriken gesammelt und analysiert werden.
Grundlegend technische Analytik in "Bitrix24"
Vor einigen Jahren, parallel zur EinfĂŒhrung des Dienstes âBitrix24â, haben wir aktiv Zeit und Ressourcen in die Erstellung einer einfachen und zuverlĂ€ssigen Analyseplattform investiert, die dazu dienen sollte, Probleme in der Infrastruktur schnell zu erkennen und den nĂ€chsten Schritt zu planen. NatĂŒrlich sollten die Werkzeuge möglichst einfach und klar sein. SchlieĂlich haben wir uns fĂŒr Nagios zur Ăberwachung und Munin zur Analyse und Visualisierung entschieden. Jetzt haben wir Tausende von ĂberprĂŒfungen in Nagios, Hunderte von Grafiken in Munin, und unsere Kollegen nutzen sie tĂ€glich und erfolgreich. Die Metriken sind klar, die Grafiken verstĂ€ndlich, das System funktioniert seit mehreren Jahren zuverlĂ€ssig und es werden regelmĂ€Ăig neue Tests und Grafiken hinzugefĂŒgt: Wir fĂŒhren einen neuen Dienst in Betrieb â fĂŒgen einige Tests und Grafiken hinzu. Gute Fahrt.
Finger am Puls â erweiterte technische Analyse
Der Wunsch, Informationen ĂŒber Probleme âso schnell wie möglichâ zu erhalten, hat uns zu aktiven Experimenten mit einfachen und klaren Werkzeugen â Pinba und XHProf â gefĂŒhrt.
Pinba sendete uns in UDP-Paketen Statistiken ĂŒber die Geschwindigkeit von PHP-Teilen auf Webseiten und man konnte in Echtzeit eine kurze Liste von Problemen in der MySQL-Datenbank sehen (Pinba kommt mit einer eigenen MySQL-Engine zur schnellen Ereignisanalyse) und darauf reagieren. XHProf ermöglichte es, automatisiert die AusfĂŒhrungsgraphen der langsamsten PHP-Seiten bei Kunden zu erfassen und zu analysieren, wodurch wir feststellen konnten, was dazu gefĂŒhrt haben könnte â entspannt, wĂ€hrend wir Tee oder etwas StĂ€rkeres genossen haben.
Vor einiger Zeit wurde das Werkzeug um eine weitere recht einfache und verstĂ€ndliche Engine auf Basis des Algorithmus der inversen Indizierung erweitert, die hervorragend in der legendĂ€ren Bibliothek Lucene implementiert ist â Elastic/Kibana. Die einfache Idee der mehrthreadigen Dokumentenspeicherung im inversen Lucene-Index basierend auf den Ereignissen in den Logs und der schnellen Suche danach mit Hilfe der Fassetten-Teilung hat sich tatsĂ€chlich als nĂŒtzlich erwiesen.
Trotz des recht technischen Aussehens der Visualisierungen in Kibana mit Konzepten wie âBucketsâ, die ânach oben flieĂenâ, und einer neu erfundenen Sprache, die noch nicht vergessene relationale Algebra ist â hat uns das Werkzeug gut bei den folgenden Aufgaben unterstĂŒtzt:
- Wie viele PHP-Fehler gab es bei dem Kunden Bitrix24 auf dem Portal p1 in der letzten Stunde und welche? Verstehen, verzeihen und schnell beheben.
- Wie viele Videoanrufe wurden in den letzten 24 Stunden auf den Plattformen in Deutschland getÀtigt, mit welcher QualitÀt und gab es Schwierigkeiten mit dem Kanal/Netzwerk?
- Wie gut funktioniert die SystemfunktionalitĂ€t (unsere C-Erweiterung fĂŒr PHP), die aus den Quellcodes im letzten Update des Services kompiliert und an die Kunden ausgerollt wurde? Gibt es Segfaults?
- Werden die Kundendaten im PHP-Speicher abgelegt? Gibt es keine Fehler bezĂŒglich des Ăberschreitens des zugewiesenen Speichers: âout of memoryâ? Finden und beheben.
Hier ist ein konkretes Beispiel. Trotz sorgfÀltiger und mehrstufiger Tests trat beim Kunden in einem sehr untypischen Fall mit beschÀdigten Eingabedaten ein Àrgerlicher und unerwarteter Fehler auf, die Sirene ertönte und der Prozess der schnellen Behebung begann:
ZusĂ€tzlich ermöglicht Kibana, Benachrichtigungen zu bestimmten Ereignissen zu organisieren, und in kurzer Zeit wurden Dutzende von Mitarbeitern aus verschiedenen Abteilungen â von Support und Entwicklung bis QA â Werkzeuge im Unternehmen.
Die AktivitĂ€t jeder Abteilung innerhalb des Unternehmens kann bequem ĂŒberwacht und gemessen werden â anstelle der manuellen Analyse von Logs auf Servern genĂŒgt es, einmal das Parsing der Logs und deren Versand an den Elastic-Cluster einzurichten, um beispielsweise die Betrachtung im Kibana-Dashboard der verkauften zweiköpfigen KĂ€tzchen, die im vergangenen Mondmonat auf 3D-Druckern hergestellt wurden, zu genieĂen.
BasisgeschÀftsanalyse
Jeder weiĂ, dass die GeschĂ€ftsanalyse in Unternehmen oft mit einer extrem aktiven Nutzung von, ja, ja, Excel beginnt. Aber das Wichtigste ist, dass sie dort nicht endet. Das Spiel wird noch zusĂ€tzlich angefacht durch Google Analytics â man gewöhnt sich schnell an das Gute.
In unserem harmonisch wachsenden Unternehmen tauchten hier und da âProphetenâ fĂŒr eine intensivere Arbeit mit gröĂeren Datenmengen auf. RegelmĂ€Ăig gab es Anforderungen an tiefere und facettenreichere Berichte, und die BemĂŒhungen von Mitarbeitern aus verschiedenen Abteilungen fĂŒhrten vor einiger Zeit zur Organisation einer einfachen und praktischen Lösung â der Anbindung von ClickHouse und PowerBI.
Lange Zeit half diese flexible Lösung ausgezeichnet, aber allmÀhlich wurde klar, dass ClickHouse nicht dehnbar ist und man nicht so mit ihm umgehen kann.
Hier ist es wichtig zu verstehen, dass ClickHouse, wie Druid, wie Vertica, wie Amazon RedShift (basierend auf Postgres), analytische Engines sind, die fĂŒr recht bequeme Analysen (Summen, Aggregationen, Minimum-Maximum pro Spalte und ein wenig Join) optimiert sind, da sie fĂŒr die effiziente Speicherung von Spalten relationaler Tabellen organisiert sind, im Gegensatz zu dem bekannten MySQL und anderen (row-oriented) Datenbanken.
Im Grunde genommen ist ClickHouse nur eine gröĂere "Datenbank", mit nicht sehr bequemer punktueller Einspeisung (so ist es gedacht, alles in Ordnung), aber mit angenehmer Analyse und einer Reihe von interessanten leistungsstarken Funktionen zur Datenverarbeitung. Ja, man kann sogar einen Cluster erstellen â aber, verstehen Sie, es ist nicht ganz richtig, NĂ€gel mit einem Mikroskop zu hĂ€mmern und wir begannen, nach anderen Lösungen zu suchen.
Nachfrage nach Python und Analysten
In unserem Unternehmen gibt es viele Entwickler, die fast jeden Tag seit 10-20 Jahren in PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash programmieren. AuĂerdem gibt es viele erfahrene Systemadministratoren, die nicht eine, sondern mehrere völlig unglaublich Katastrophen ĂŒberstanden haben, die nicht in die Gesetze der Statistik passen (zum Beispiel, wenn die meisten Festplatten in einem RAID-10 bei einem starken Blitzschlag zerstört werden). Unter solchen Bedingungen war lange Zeit unklar, was ein "Analyst mit Python" ist. Python ist wie PHP, nur mit einem etwas lĂ€ngeren Namen und weniger Substanzen, die das Bewusstsein im Quellcode des Interpreters verĂ€ndern. Doch wĂ€hrend immer neue analytische Berichte erstellt wurden, begannen die erfahrenen Entwickler mehr und mehr die Bedeutung der Spezialisierung auf Werkzeuge wie numpy, pandas, matplotlib, seaborn zu erkennen.
Eine entscheidende Rolle spielten wahrscheinlich die plötzlichen OhnmachtsanfĂ€lle der Mitarbeiter in Kombination mit den Worten "logistische Regression" und der Demonstration des effektiven Aufbaus von Berichten ĂŒber groĂe Datenmengen mit, ja, pyspark.
Apache Spark und seine funktionale Paradigmen, auf die die relationale Algebra hervorragend passt, haben so einen Eindruck bei den Entwicklern hinterlassen, die an MySQL gewöhnt sind, dass die Notwendigkeit, erfahrene Analysten in den Reihen zu haben, offensichtlich wurde.
Die weiteren Versuche von Apache Spark/Hadoop abzuheben, und was nicht ganz nach Plan verlief
Es stellte sich jedoch bald heraus, dass mit Spark offenbar etwas grundlegend nicht stimmte oder man einfach seine HĂ€nde besser waschen sollte. Wenn das Hadoop/MapReduce/Lucene-Stack von erfahrenen Programmierern erstellt wurde, was offensichtlich ist, wenn man sich die Quellcodes in Java oder Doug Cutting Ideen in Lucene ansieht, dann ist Spark plötzlich in einer sehr umstrittenen, praktischen Hinsicht und im Moment nicht mehr entwickelten exotischen Sprache Scala geschrieben. Das regelmĂ€Ăige Versagen von Berechnungen im Spark-Cluster aufgrund der unlogischen und wenig transparenten Speicherverwaltung fĂŒr Reduce-Operationen (da viele SchlĂŒssel auf einmal ankommen) hat um ihn einen Nimbus des Wachstums geschaffen. ZusĂ€tzlich wurde die Situation durch eine Vielzahl von seltsamen offenen Ports, temporĂ€ren Dateien, die an den unverstĂ€ndlichsten Orten wuchsen, und ein Netz von jar-AbhĂ€ngigkeiten verschĂ€rft â das rief bei den Systemadministratoren ein vertrautes GefĂŒhl hervor: loderne Hass (oder vielleicht hĂ€tte man die HĂ€nde mit Seife waschen sollen).
Wir haben als Ergebnis mehrere interne Analyseprojekte âĂŒberlebtâ, die intensiv Apache Spark (einschlieĂlich Spark Streaming, Spark SQL) und das Hadoop-Ăkosystem (und so weiter) nutzten. Obwohl wir im Laufe der Zeit gelernt haben, âdasâ ganz gut zu handhaben und zu ĂŒberwachen und âesâ praktisch nicht mehr plötzlich aufgrund der verĂ€nderten Datenmuster und der Unausgewogenheit des gleichmĂ€Ăigen Hashing von RDD fiel, wurde der Wunsch, etwas Fertiges, Aktualisiertes und Administriertes irgendwo in der Cloud zu nehmen, immer stĂ€rker. und haben anschlieĂend versucht, die Aufgaben bereits darauf zu lösen. EMR ist Amazons fertiger Apache Spark mit zusĂ€tzlicher Software aus dem Ăkosystem, Ă€hnlich wie die Cloudera/Hortonworks-Bundles.
Ein âgummibereitesâ Dateispeicher fĂŒr Analysen â ein dringender Bedarf
Die Erfahrung der âZubereitungâ von Hadoop/Spark mit Verbrennungen an verschiedenen Körperstellen blieb nicht ohne Ergebnis. Es zeichnete sich immer klarer die Notwendigkeit ab, einen einheitlichen, kostengĂŒnstigen und zuverlĂ€ssigen Dateispeicher zu schaffen, der gegen HardwareausfĂ€lle resistent wĂ€re und in dem Dateien in verschiedenen Formaten aus verschiedenen Systemen gespeichert werden könnten, um daraus effektive Datenabfragen fĂŒr Berichte in angemessener Zeit zu erstellen.
Es wĂ€re auch wĂŒnschenswert, dass die Software-Updates dieser Plattform nicht zu einem nervenaufreibenden Neujahrsnacht-Albtraum werden, bei dem man 20-seitige Java-Tracebacks lesen und kilometerlange detaillierte Protokolle des Clusterbetriebs mit Hilfe des Spark History Servers und einer Lupe mit Beleuchtung analysieren muss. Ich möchte ein einfaches und transparentes Werkzeug haben, das keine regelmĂ€Ăigen Tiefenuntersuchungen erfordert, wenn der Entwickler die Standard-MapReduce-Anfrage nicht mehr ausfĂŒhren kann, weil der Arbeitsspeicher des Reduce-Datenarbeiters bei ungĂŒnstigen Partitionsalgorithmen nicht mehr ausreicht.
Amazon S3 â ein Kandidat fĂŒr DataLake?
Die Erfahrungen mit Hadoop/MapReduce haben gezeigt, dass eine skalierbare, zuverlĂ€ssige Dateispeicherlösung sowie skalierbare Worker nötig sind, die nĂ€her an den Daten arbeiten, um nicht stĂ€ndig Daten ĂŒber das Netzwerk zu bewegen. Die Worker sollten in der Lage sein, Daten in verschiedenen Formaten zu lesen, aber idealerweise keine unnötigen Informationen lesen und die Daten im Voraus in Formate speichern, die fĂŒr die Worker praktisch sind.
Nochmal - das Hauptkonzept. Ich habe kein Interesse daran, groĂe Daten in eine einzige Cluster-Analysemotor zu laden, der irgendwann ohnehin ĂŒberfordert ist und dann unschön shardet werden muss. Ich möchte einfach Dateien in einem verstĂ€ndlichen Format speichern und mit verschiedenen, aber intuitiven Werkzeugen effiziente Analyseanfragen durchfĂŒhren. Es werden zunehmend mehr Dateien in verschiedenen Formaten generiert, und es wĂ€re besser, nicht den Motor zu sharden, sondern die Rohdaten. Wir benötigen einen skalierbaren und universellen DataLake, haben wir beschlossen...
Was wĂ€re, wenn wir die Dateien in einem vertrauten und von vielen bekannten skalierbaren Cloud-Speicher wie Amazon S3 speichern, ohne uns um die eigene Zubereitung von HĂ€hnchen zu kĂŒmmern?
Klar, personenbezogene Daten sind "no go", aber was ist mit anderen Daten, wenn wir sie dorthin bringen und "effektiv verarbeiten"?
Das clusterbasierte Big Data-Analyse-Ăkosystem von Amazon Web Services â sehr vereinfacht gesagt.
Nach unseren Erfahrungen mit AWS wird dort schon lange und aktiv Apache Hadoop/MapReduce unter verschiedenen Aspekten verwendet, beispielsweise im Dienst DataPipeline (ich beneide meine Kollegen, die haben gelernt, wie man es richtig zubereitet). Hier haben wir Backups aus verschiedenen Diensten von DynamoDB-Tabellen eingerichtet:
Und diese werden seit mehreren Jahren regelmĂ€Ăig auf den integrierten Clustern von Hadoop/MapReduce wie die Uhr ausgefĂŒhrt. "Einmal eingerichtet und vergessen":
AuĂerdem kann man effektiv Daten-Satanismus betreiben, indem man Jupiter-Notebooks in der Cloud fĂŒr Analysten hochzieht und AWS SageMaker fĂŒr das Training und Deployment von KI-Modellen verwendet. So sieht das bei uns aus:
Ja, man kann sich oder dem Analysten ein Notebook in der Cloud einrichten und es an ein Hadoop/Spark-Cluster anschlieĂen, die Daten berechnen und anschlieĂend alles âfesthaltenâ:
Es ist wirklich praktisch fĂŒr einzelne Analyseprojekte und fĂŒr einige von ihnen haben wir erfolgreich den EMR-Service fĂŒr groĂangelegte Berechnungen und Analysen genutzt. Und wie sieht es mit einer systematischen Lösung fĂŒr DataLake aus, wird das klappen? In diesem Moment waren wir am Rande von Hoffnung und Verzweiflung und setzten unsere Suche fort.
AWS Glue â ordentlich verpacktes Apache Spark âauf Steroidenâ
Es stellte sich heraus, dass AWS eine âeigeneâ Version des Stacks âHive/Pig/Sparkâ hat. Die Rolle von Hive, also das Katalogisieren von Dateien und ihren Typen im DataLake, ĂŒbernimmt der Service âDatenkatalogâ, der nicht einmal seine KompatibilitĂ€t mit dem Apache Hive-Format verheimlicht. In diesen Service mĂŒssen Sie Informationen darĂŒber einfĂŒgen, wo sich Ihre Dateien befinden und in welchem Format sie vorliegen. Die Daten können nicht nur in s3, sondern auch in einer Datenbank gespeichert sein, aber das ist nicht Thema dieses Beitrags. So ist unser Datenkatalog fĂŒr DataLake organisiert:
Die Dateien sind registriert, alles bestens. Wenn die Dateien aktualisiert wurden, starten wir entweder manuell oder nach einem Zeitplan Crawler, die die Informationen ĂŒber sie aus dem See aktualisieren und speichern. AnschlieĂend können die Daten aus dem See verarbeitet und die Ergebnisse irgendwohin exportiert werden. Im einfachsten Fall exportieren wir sie ebenfalls in s3. Die Datenverarbeitung kann ĂŒberall erfolgen, aber es wird empfohlen, den Verarbeitungsprozess auf einem Apache Spark-Cluster mit erweiterten Möglichkeiten ĂŒber die AWS Glue API einzurichten. Im Grunde kann man den guten alten und vertrauten Code in Python unter Verwendung der Bibliothek pyspark nehmen und seine AusfĂŒhrung auf N Knoten eines Clusters mit einer bestimmten Leistung einrichten, einschlieĂlich Monitoring, ohne sich mit den Tiefen von Hadoop zu beschĂ€ftigen und Docker-Mocker-Container hin und her zu ziehen und AbhĂ€ngigkeitskonflikte zu beseitigen.
Noch einmal â eine einfache Idee. Es ist nicht nötig, Apache Spark einzurichten, man muss nur Python-Code fĂŒr pyspark schreiben, lokal auf dem Desktop testen und dann auf einem groĂen Cluster in der Cloud ausfĂŒhren, indem man angibt, wo die Quelldaten liegen und wo das Ergebnis gespeichert werden soll. Manchmal ist das notwendig und nĂŒtzlich, und so ist es bei uns eingerichtet:
So, wenn man etwas auf einem Spark-Cluster mit Daten in s3 berechnen muss, schreibt man Python/pyspark-Code, testet ihn und ab ins Cloud.
Und was ist mit der Orchestrierung? Und wenn die Aufgabe gefallen und verschwunden ist? Ja, es wird vorgeschlagen, eine schöne Pipeline im Stil von Apache Pig zu erstellen, und wir haben sie sogar ausprobiert, aber beschlossen, vorerst unsere tiefgehend angepasste Orchestrierung in PHP und JavaScript zu verwenden (ich verstehe, dass ein kognitiver Dissonanz entsteht, aber es funktioniert, schon jahrelang und ohne Fehler).
Das Format der im See gespeicherten Dateien ist der SchlĂŒssel zur Leistung
Es ist sehr, sehr wichtig, zwei weitere entscheidende Punkte zu verstehen. Damit die Anfragen zu den Daten der Dateien im See so schnell wie möglich ausgefĂŒhrt werden und die Leistung beim HinzufĂŒgen neuer Informationen nicht sinkt, mĂŒssen Sie:
- Die Spalten der Dateien separat speichern (um nicht alle Zeilen lesen zu mĂŒssen, um zu verstehen, was in den Spalten steht). DafĂŒr haben wir das Parquet-Format mit Kompression gewĂ€hlt.
- Es ist sehr wichtig, die Dateien nach Ordnern zu shardieren: Sprache, Jahr, Monat, Tag, Woche. Engines, die diesen Sharding-Typ verstehen, werden nur in die benötigten Ordner schauen, ohne alle Daten durchzugehen.
Im Grunde genommen legen Sie auf diese Weise die Ausgangsdaten in der effektivsten Form fĂŒr die darĂŒber liegenden Analyse-Engines zur VerfĂŒgung, die ebenfalls selektiv in die shardierten Ordner gehen und nur die benötigten Spalten aus den Dateien lesen können. Es ist nicht nötig, die Daten irgendwo zu "laden" (das Speicher könnte sonst einfach platzen) â legen Sie sie einfach gleich sinnvoll im richtigen Format in das Dateisystem. SelbstverstĂ€ndlich sollte hier klar sein, dass es nicht sehr sinnvoll ist, eine riesige CSV-Datei im DataLake zu speichern, die man zuerst zeilenweise mit einem Cluster lesen muss, um die Spalten zu extrahieren â denken Sie noch einmal ĂŒber die beiden obigen Punkte nach, wenn Sie nicht verstehen, wozu das alles gut sein soll.
AWS Athena â der "Teufel" aus der Tabakdose
Und hier, wĂ€hrend wir den See erstellen, sind wir zufĂ€llig auf Amazon Athena gestoĂen. Plötzlich stellte sich heraus, dass wir, indem wir unsere riesigen Log-Dateien ordentlich nach Shards-Ordnern im richtigen (parquet) spaltenbasierten Format anordnen, sehr schnell Ă€uĂerst informative Abfragen durchfĂŒhren und Berichte OHNE, ohne Apache Spark/Glue-Cluster erstellen können.
Die Athena-Engine, die mit Daten in S3 arbeitet, basiert auf dem legendĂ€ren â Vertreter der MPP (massive parallel processing) AnsĂ€tze zur Datenverarbeitung, die Daten dort entnehmen, wo sie liegen, von s3 und Hadoop bis hin zu Cassandra und einfachen Textdateien. Man muss lediglich Athena auffordern, die SQL-Abfrage auszufĂŒhren, und der Rest âfunktioniert schnell und selbststĂ€ndigâ. Es ist wichtig zu erwĂ€hnen, dass Athena âintelligentâ ist, nur die benötigten shard-gerechten Ordner aufruft und nur die benötigten Spalten aus der Abfrage liest.
Die Anfragen an Athena werden ebenfalls interessant abgerechnet. Wir bezahlen fĂŒr . Das heiĂt, nicht fĂŒr die Anzahl der Maschinen im Cluster pro Minute, sondern⊠fĂŒr die tatsĂ€chlich gescannten, auf 100-500 Maschinen, nur die notwendigen Daten zur AusfĂŒhrung der Abfrage.
Und wenn man nur die benötigten Spalten aus den richtig shard-gerechten Ordnern abfragt, stellt sich heraus, dass uns der Service Athena nur einige Dutzend Dollar im Monat kostet. Na, das ist doch prima, fast kostenlos im Vergleich zu Analytics auf Clustern!
Ăbrigens, so shardieren wir unsere Daten in s3:
In der Folge haben innerhalb kurzer Zeit in der Firma vollkommen verschiedene Abteilungen, von der Informationssicherheit bis zur Analyse, begonnen, aktiv Anfragen an Athena zu stellen und schnell, in Sekunden, nĂŒtzliche Antworten aus den "groĂen" Daten ĂŒber ziemlich lange ZeitrĂ€ume zu erhalten: Monate, Halbjahre usw.
Aber wir sind weitergegangen und haben begonnen, die Antworten in die Cloud zu holen : Ein Analyst schreibt in der gewohnten Konsole eine SQL-Abfrage, die auf 100-500 Maschinen âfĂŒr einen kleinen Preisâ die Daten in s3 durchforstet und die Antwort normalerweise in wenigen Sekunden zurĂŒckgibt. Bequem. Und schnell. Es ist immer noch kaum zu glauben.
Insgesamt haben wir, nachdem wir entschieden haben, die Daten in s3 im effektiven Spaltenformat und mit einer sinnvollen Shardung der Daten nach Ordnern zu speichern⊠ein DataLake und eine schnelle und gĂŒnstige Analysesoftware - kostenlos. Und es wurde sehr beliebt im Unternehmen, da es SQL versteht und um ein Vielfaches schneller arbeitet als bei Start/Stop/Feinabstimmung von Clustern. "Und wenn das Ergebnis dasselbe ist, warum mehr bezahlen?"
Eine Anfrage an Athena sieht ungefĂ€hr so aus. Wenn gewĂŒnscht, kann man natĂŒrlich eine ausreichend , aber wir beschrĂ€nken uns auf eine einfache Gruppierung. Schauen wir, welche Antwortcodes der Kunde vor einigen Wochen in den Protokollen des Webservers hatte und stellen wir sicher, dass es keine Fehler gab:
Das DBMS Tarantool ist ein attraktives, zukunftstrÀchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Nach einem, wenn auch nicht langen, dafĂŒr aber schmerzhaften Weg, bei dem wir stĂ€ndig Risiken, den Schwierigkeitsgrad und die Kosten fĂŒr den Support angemessen bewertet haben, fanden wir eine Lösung fĂŒr DataLake und Analytics, die uns sowohl mit ihrer Geschwindigkeit als auch mit den Besitzkosten begeistert.
Es stellte sich heraus, dass es selbst fĂŒr erfahrene Entwickler, die niemals Architekten gewesen sind und es nicht gewohnt sind, Quadrate auf Quadraten mit Pfeilen zu zeichnen und 50 Begriffe aus dem Hadoop-Ăkosystem zu kennen, durchaus möglich ist, ein effizientes, schnelles und kostengĂŒnstiges DataLake fĂŒr die BedĂŒrfnisse ganz unterschiedlicher Unternehmensabteilungen zu erstellen.
Zu Beginn des Weges platzte einem der Kopf von einer Vielzahl extrem verrĂŒckter Zoos von Open- und Closed-Source-Software und dem GefĂŒhl der Verantwortung, die man gegenĂŒber den Nachkommen hat. Beginnen Sie einfach damit, Ihr DataLake mit einfachen Werkzeugen zu bauen: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3âŠ, sammeln Sie Feedback und verstehen Sie tief die physikalischen Prozesse, die ablaufen. Alles Komplexe und Unklare â geben Sie es Ihren Feinden und Konkurrenten.
Wenn Sie nicht in die Cloud möchten und es lieben, Open-Source-Projekte zu unterstĂŒtzen, zu aktualisieren und zu patchen, können Sie ein Ă€hnliches System wie das unsere lokal auf preiswerten BĂŒrorechnern mit Hadoop und Presto oben drauf aufbauen. Das Wichtigste ist, nicht stehen zu bleiben und voranzukommen, zu zĂ€hlen, einfache und klare Lösungen zu suchen, und alles wird auf jeden Fall gelingen! Viel GlĂŒck an alle und bis zum nĂ€chsten Mal!
Quelle: habr.com
