Wir leben in einer erstaunlichen Zeit, in der man schnell und einfach mehrere bereitgestellte Open-Source-Tools kombinieren kann, sie mit 'ausgeschaltetem Bewusstsein' gemÀà den RatschlĂ€gen von StackOverflow einrichten kann, ohne sich um 'viele Buchstaben' kĂŒmmern zu mĂŒssen, und sie in den kommerziellen Betrieb ĂŒbernehmen kann. Und wenn es nötig wird, sich zu aktualisieren/erweitern oder jemand aus Versehen ein paar Maschinen neu startet â wird man erkennen, dass man in einen aufdringlichen, schlechten Traum aufgewacht ist, alles hat sich plötzlich unkenntlich kompliziert und ein ZurĂŒck gibt es nicht, die Zukunft ist ungewiss und sicherer, anstatt zu programmieren, Bienen zu zĂŒchten und KĂ€se herzustellen.
Nicht ohne Grund lĂ€cheln die erfahreneren Kollegen mit grauen Haaren, die schon viele Bugs gesehen haben, wĂ€hrend sie das unglaublich schnelle Deployment von Container-Paketen in âCubesâ auf Dutzenden von Servern in modernen Programmiersprachen mit integrierter UnterstĂŒtzung fĂŒr asynchrones, nicht blockierendes I/O betrachten. Sie lesen still das âman psâ nach, vertiefen sich bis zum Augenbluten in den Quellcode von ânginxâ und schreiben, schreiben, schreiben Unit-Tests. Die Kollegen wissen, dass das Interessanteste noch bevorsteht, wenn âall dasâ eines Nachts zu Silvester zum Stillstand kommt. Nur ein tiefes VerstĂ€ndnis der Unix-Natur, die auswendig gelernten TCP/IP-Zustandsdiagramme und grundlegenden Sortier- und Suchalgorithmen können helfen, das System beim GlockenlĂ€uten wieder zum Leben zu erwecken.
Ach ja, ich bin ein wenig abgekommen, aber ich hoffe, ich konnte den Zustand der Vorfreude vermitteln.
Heute möchte ich unsere Erfahrungen mit dem Deployment eines benutzerfreundlichen und kostengĂŒnstigen Stacks fĂŒr DataLake teilen, der die meisten analytischen Aufgaben im Unternehmen fĂŒr ganz unterschiedliche Abteilungen löst.
Vor einiger Zeit erkannten wir, dass Unternehmen zunehmend auf die Ergebnisse sowohl der Produkt- als auch der technischen Analytik angewiesen sind â ganz zu schweigen von den âSahnehĂ€ubchenâ in Form von Machine Learning. Um Trends und Risiken besser zu verstehen, mĂŒssen immer mehr Kennzahlen gesammelt und analysiert werden.
Grundlegende technische Analytik in âBitrix24â
Vor einigen Jahren, gemeinsam mit dem Start des Dienstes âBitrix24â, investierten wir aktiv Zeit und Ressourcen in die Entwicklung einer einfachen und zuverlĂ€ssigen Analyseplattform, die es ermöglicht, Probleme in der Infrastruktur schnell zu erkennen und die nĂ€chsten Schritte zu planen. NatĂŒrlich wollten wir möglichst einfache und verstĂ€ndliche, fertige Tools verwenden. SchlieĂlich fiel die Wahl auf Nagios fĂŒr das Monitoring und Munin fĂŒr die Analyse und Visualisierung. Jetzt haben wir tausende von Checks in Nagios, Hunderte von Grafiken in Munin und unsere Kollegen verwenden diese tĂ€glich und erfolgreich. Die Kennzahlen sind klar, die Grafiken sind verstĂ€ndlich, und das System arbeitet zuverlĂ€ssig seit mehreren Jahren und wird regelmĂ€Ăig um neue Tests und Grafiken erweitert: Bei der Inbetriebnahme eines neuen Dienstes â fĂŒgen wir einige Tests und Grafiken hinzu. Gute Reise.
Immer 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 verstĂ€ndlichen Werkzeugen gefĂŒhrt â Pinba und XHProf.
Pinba sendete uns in UDP-Paketen Statistiken ĂŒber die Geschwindigkeit der PHP-Webseitenteile, und man konnte in Echtzeit im MySQL-Speicher (Pinba ist mit einer eigenen MySQL-Engine fĂŒr schnelle Ereignisanalysen ausgestattet) eine kurze Liste von Problemen sehen und darauf reagieren. XHProf ermöglichte es uns zudem automatisch, die AusfĂŒhrungsgraphen der langsamsten PHP-Seiten der Kunden zu sammeln und zu analysieren, was dazu gefĂŒhrt haben könnte â gemĂŒtlich bei einer Tasse Tee oder etwas StĂ€rkerem.
Vor einiger Zeit wurde das Toolset um eine weitere recht einfache und verstĂ€ndliche Engine auf Basis des Algorithmus zur inversen Indizierung erweitert, die hervorragend in der legendĂ€ren Bibliothek Lucene umgesetzt wurde â Elastic/Kibana. Die einfache Idee, mehrschichtige Dokumente in den inversen Lucene-Index auf Basis von Log-Ereignissen aufzunehmen und schnell nach diesen zu suchen, stellte sich als wirklich nĂŒtzlich heraus.
Trotz der eher technischen Darstellung in Kibana mit den "nach oben durchdringenden" niedrigstufigen Konzepten wie "Bucket" und einer neu erfundenen Sprache der lÀngst vergessenen relationalen Algebra hilft uns das Tool gut bei den folgenden Aufgaben:
- Wie viele PHP-Fehler hatte der Bitrix24-Kunde im Portal p1 in der letzten Stunde und welche? Verstehen, verzeihen und schnell beheben.
- Wie viele Videoanrufe wurden in den letzten 24 Stunden in den Portalen in Deutschland getÀtigt, mit welcher QualitÀt und gab es Probleme mit dem Kanal/netzwerk?
- Wie gut funktioniert die systemeigene FunktionalitĂ€t (unser C-Erweiterung fĂŒr PHP), die aus den Quellcodes in der letzten Aktualisierung des Dienstes kompiliert und an die Kunden verteilt wurde? Gibt es segfaults?
- Werden die Kundendaten im PHP-Speicher untergebracht? Gibt es keine Fehler aufgrund von SpeicherĂŒberlastung: "out of memory"? Finden und entschĂ€rfen.
Hier ein konkretes Beispiel. Trotz sorgfÀltiger und mehrstufiger Tests trat bei einem Kunden, bei einem sehr untypischen Anwendungsfall und beschÀdigten Eingangsdaten, ein Àrgerlicher und unerwarteter Fehler auf, die Sirene ertönte und der Prozess zur schnellen Behebung begann:
ZusĂ€tzlich ermöglicht Kibana die Einrichtung von Benachrichtigungen fĂŒr bestimmte Ereignisse, und in kurzer Zeit nutzen Dutzende von Mitarbeitern aus verschiedenen Abteilungen â von der technischen UnterstĂŒtzung ĂŒber die Entwicklung bis hin zu QA â das Tool im Unternehmen.
Die AktivitĂ€t jeder Abteilung innerhalb des Unternehmens lĂ€sst sich bequem verfolgen und messen â anstelle einer manuell vorgenommenen Analyse der Protokolle auf den Servern genĂŒgt es, einmal das Parsing der Protokolle einzurichten und sie an den Elastic-Cluster zu senden, um beispielsweise die Anzahl der verkauften 3D-gedruckten zweiköpfigen KĂ€tzchen im Dashboard von Kibana fĂŒr den letzten Mondmonat zu betrachten.
BasisgeschÀftsanalyse
Alle wissen, dass die GeschĂ€ftsanalyse in Unternehmen oft mit einer extrem aktiven Nutzung von, ja, Excel beginnt. Aber das Wichtigste ist, dass sie nicht damit endet. Die Cloud-basierte Google Analytics trĂ€gt zusĂ€tzlich zur SchĂ€rfe bei â an das Gute gewöhnt man sich schnell.
In unserem harmonisch wachsenden Unternehmen begannen ĂŒberall âProphetenâ fĂŒr intensivere Arbeiten mit gröĂeren Datenmengen aufzutauchen. RegelmĂ€Ăig traten BedĂŒrfnisse nach tiefergehenden und vielseitigeren Berichten auf, und durch die BemĂŒhungen der Kollegen aus verschiedenen Abteilungen wurde vor einiger Zeit eine einfache und praktische Lösung organisiert â die Kombination von ClickHouse und PowerBI.
Eine ziemlich lange Zeit hat diese flexible Lösung hervorragend geholfen, aber allmÀhlich wurde klar, dass ClickHouse nicht elastisch ist und man damit nicht so umgehen kann.
Es ist wichtig zu verstehen, dass ClickHouse, wie auch Druid, Vertica und Amazon RedShift (das auf Postgres basiert), analytische Engines sind, die fĂŒr eine recht komfortable Analyse optimiert sind (Summen, Aggregationen, Minimum-Maximum nach Spalte und ein wenig Joins), da sie fĂŒr die effiziente Speicherung von Spalten relationaler Tabellen organisiert sind, im Gegensatz zu den uns bekannten MySQL und anderen (row-oriented) Datenbanken.
Im Grunde genommen ist ClickHouse lediglich eine umfangreichere Datenbank mit einer nicht ganz benutzerfreundlichen punktuellen EinfĂŒgung (so ist es nun mal gedacht, alles in Ordnung), aber mit angenehmer Analyse und einer Reihe interessanter, leistungsstarker Funktionen zur Datenbearbeitung. Ja, man kann sogar einen Cluster erstellen â aber Sie verstehen, dass man NĂ€gel nicht mit einem Mikroskop einschlagen sollte, und wir haben begonnen, nach anderen Lösungen zu suchen.
Die Nachfrage nach Python und Analysten
In unserem Unternehmen gibt es viele Entwickler, die fast tĂ€glich seit 10-20 Jahren Code in PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python und Bash schreiben. Es gibt auch viele erfahrene Systemadministratoren, die schon einige unglaublich unglĂŒckliche Katastrophen ĂŒberstanden haben, die statistischen Gesetzen nicht gehorchen (zum Beispiel wenn die meisten Festplatten in einem RAID-10 durch einen starken Blitzeinschlag zerstört werden). Unter solchen Bedingungen war lange Zeit unklar, was ein âAnalyst in Pythonâ eigentlich ist. Python ist wie PHP, nur mit einem etwas lĂ€ngeren Namen und weniger Spuren von bewusstseinserweiternden Substanzen im Quellcode des Interpreters. Doch mit der Erstellung immer neuer analytischer Berichte begannen erfahrene Entwickler, die Bedeutung einer engen Spezialisierung auf Tools wie numpy, pandas, matplotlib und seaborn immer mehr zu erkennen.
Die entscheidende Rolle spielten wahrscheinlich die plötzlichen OhnmachtsanfĂ€lle der Mitarbeiter bei der Kombination der Worte âlogistische Regressionâ und der Demonstration des effizienten Aufbaus von Berichten ĂŒber groĂe Datenmengen mit ja, ja, pyspark.
Apache Spark, dessen funktionale Paradigmen perfekt zur relationalen Algebra und den Möglichkeiten passen, haben einen solchen Eindruck bei Entwicklern hinterlassen, die mit MySQL vertraut sind, dass die Notwendigkeit, die Reihen der erfahrenen Analysten zu stÀrken, so klar wie der Tag wurde.
Weitere Versuche, dass Apache Spark/Hadoop durchstarten und was nicht ganz nach Plan lief.
Bald wurde jedoch klar, dass mit Spark offenbar etwas systematisch nicht stimmte oder man einfach besser die HĂ€nde waschen sollte. Wenn der Hadoop/MapReduce/Lucene-Stack von erfahrenen Programmierern entwickelt wurde, was offensichtlich ist, wenn man sich die Quellcodes auf Java oder die Ideen von Doug Cutting in Lucene ansieht, ist Spark ĂŒberraschend in einer sehr umstrittenen, aus praktischer Sicht nicht weiterentwickelten exotischen Sprache, Scala, geschrieben. Das regelmĂ€Ăige Versagen von Berechnungen im Spark-Cluster aufgrund der unlogischen und nicht sehr transparenten Handhabung der Speicherzuteilung fĂŒr Reduce-Operationen (es kommen gleich viele SchlĂŒssel auf einmal) hat um ihn herum eine Aura geschaffen, die darauf hinweist, dass es viel Spielraum fĂŒr Verbesserungen gibt. Zudem verschĂ€rfte eine groĂe Anzahl seltsamer offener Ports, temporĂ€rer Dateien, die an den unerwartetsten Orten wuchsen, und zahlreiche jar-AbhĂ€ngigkeiten die Situation â was bei den Systemadministratoren ein bekanntes GefĂŒhl hervorrief: reine Wut (vielleicht hĂ€tte man die HĂ€nde mit Seife waschen sollen).
Im Laufe der Zeit haben wir mehrere interne Analyseprojekte âĂŒberlebtâ, die intensiv Apache Spark (einschlieĂlich Spark Streaming, Spark SQL) und das Hadoop-Ăkosystem nutzen. Obwohl wir gelernt haben, es gut vorzubereiten und zu ĂŒberwachen, und es fast nicht mehr wegen der sich Ă€ndernden Datenmuster und der Ungleichgewichtsproblematik bei der gleichmĂ€Ăigen Hashing von RDDs ausfĂ€llt, wurde das Verlangen nach einer bereits vorgefertigten, aktualisierbaren und verwaltbaren Lösung in der Cloud immer stĂ€rker. In dieser Zeit haben wir versucht, die fertige Cloud-Lösung von Amazon Web Services zu nutzen â und haben anschlieĂend versucht, unsere Aufgaben dort zu lösen. EMR ist Amazons vorkonfigurierte Version von Apache Spark mit zusĂ€tzlicher Software aus dem Ăkosystem, Ă€hnlich wie die Cloudera/Hortonworks-Distributionen.
Ein âflexiblesâ Dateispeicher fĂŒr Analysen â ein dringender Bedarf
Die Erfahrung mit der "Zubereitung" von Hadoop/Spark, einschlieĂlich der dabei erlittenen Verletzungen, war nicht umsonst. Es wurde zunehmend klarer, dass die Schaffung eines kostengĂŒnstigen und zuverlĂ€ssigen Dateispeichers notwendig ist, der gegen HardwareausfĂ€lle resistent ist und in dem Dateien aus verschiedenen Systemen in unterschiedlichen Formaten gespeichert werden können, um auf diesen Daten effektive Abfragen fĂŒr Berichte in angemessener Zeit durchfĂŒhren zu können.
AuĂerdem wĂ€re es wĂŒnschenswert, dass die Softwareaktualisierung dieser Plattform nicht in einen nĂ€chtlichen Albtraum an Neujahr mĂŒndet, mit dem Lesen von 20-seitigen Java-Tracebacks und der Analyse von kilometerlangen detaillierten Protokollen der Clusterarbeit mithilfe des Spark History Servers und einer Lupe mit Beleuchtung. Ich wĂŒrde mir ein einfaches und transparentes Werkzeug wĂŒnschen, das keine regelmĂ€Ăigen technischen Eingriffe erfordert, wenn der Entwickler bei der AusfĂŒhrung einer Standard-MapReduce-Anfrage auf Probleme stöĂt, weil beim Speichern der Reduce-Daten im Arbeitsspeicher des Workers ein nicht optimal gewĂ€hlter Partitionierungsalgorithmus fĂŒr die Quelldaten verwendet wurde.
Ist Amazon S3 ein Kandidat fĂŒr DataLake?
Die Erfahrung mit Hadoop/MapReduce hat mich gelehrt, dass ein zuverlĂ€ssiges und skalierbares Dateisystem sowie skalierbare Worker notwendig sind, die nĂ€her an den Daten »kommen«, um Daten nicht ĂŒber das Netzwerk zu ĂŒbertragen. Die Worker sollten in der Lage sein, Daten in verschiedenen Formaten zu lesen, aber idealerweise nicht unnötige Informationen einzulesen, und es sollte möglich sein, die Daten im Vorfeld in fĂŒr die Worker geeigneten Formaten zu speichern.
Nochmal â die Grundidee. Es besteht kein Wunsch, groĂe Daten in eine einzige Cluster-Analyse-Engine zu »laden«, die ohnehin frĂŒher oder spĂ€ter ĂŒberlastet sein wird und die man dann unschön sharden muss. Ich möchte Dateien, einfach Dateien, in einem verstĂ€ndlichen Format speichern und effiziente analytische Abfragen mit verschiedenen, aber verstĂ€ndlichen Tools durchfĂŒhren. Und die Anzahl der Dateien in unterschiedlichen Formaten wird immer gröĂer. Es ist besser, nicht die Engine zu sharden, sondern die Rohdaten. Wir brauchen einen skalierbaren und universellen DataLake, haben wir beschlossen...
Was wĂ€re, wenn wir Dateien in einem vertrauten und vielen bekannten skalierbaren Cloud-Speicher wie Amazon S3 speichern, ohne eigene »Schweinemedaillons« aus Hadoop zubereiten zu mĂŒssen?
Klar, personenbezogene Daten sind »verboten«, aber was ist mit anderen Daten, wenn wir diese dort speichern und »effizient verarbeiten«?
Die clusterbasierte Big-Data-Analyse-Umgebung von Amazon Web Services â ganz einfach erklĂ€rt.
Nach unseren Erfahrungen mit AWS wird dort seit langem und intensiv unter verschiedenen Aspekten Apache Hadoop/MapReduce eingesetzt, zum Beispiel im DataPipeline-Service (ich beneide die Kollegen, sie haben es wirklich geschafft, es richtig zu handhaben). Hier haben wir Backups von verschiedenen Diensten aus DynamoDB-Tabellen eingerichtet:
Und diese laufen regelmĂ€Ăig auf integrierten Hadoop/MapReduce-Clustern seit mehreren Jahren wie am SchnĂŒrchen. âEinmal eingestellt und vergessenâ:
AuĂerdem kann man effektiv Datenmanagement betreiben, indem man Jupiter-Notebooks fĂŒr Analysten in der Cloud hochzieht und AWS SageMaker fĂŒr das Training und den Einsatz von KI-Modellen nutzt. So sieht das bei uns aus:
Und ja, man kann sich oder den Analysten ein Notebook in der Cloud einrichten und an ein Hadoop/Spark-Cluster anschlieĂen, rechnen und alles dann âbeendenâ:
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. Aber was ist mit einer systematischen Lösung fĂŒr DataLake, wird das funktionieren? In diesem Moment waren wir am Rande der Hoffnung und Verzweiflung und setzten unsere Suche fort.
AWS Glue â sauber verpacktes Apache Spark "auf Steroiden".
Es stellt sich heraus, dass AWS eine âeigeneâ Version des Stacks âHive/Pig/Sparkâ hat. Die Rolle von Hive, also das Verzeichnis von Dateien und ihren Typen im DataLake, wird durch den Dienst âData catalogâ erfĂŒllt, der auch offen ĂŒber seine KompatibilitĂ€t mit dem Apache Hive-Format kommuniziert. In diesen Dienst mĂŒssen Informationen darĂŒber eingetragen werden, wo sich Ihre Dateien befinden und in welchem Format sie vorliegen. Die Daten können sich nicht nur in S3, sondern auch in einer Datenbank befinden, aber das ist nicht Thema dieses Beitrags. So ist der Datenkatalog im DataLake bei uns organisiert:
Die Dateien sind registriert, ausgezeichnet. Wenn die Dateien aktualisiert werden, starten wir entweder manuell oder nach Plan die Crawler, die Informationen aus dem See aktualisieren und speichern. AnschlieĂend können die Daten aus dem See bearbeitet und die Ergebnisse irgendwohin exportiert werden. Im einfachsten Fall exportieren wir auch in S3. Die Datenverarbeitung kann ĂŒberall erfolgen, aber es wird empfohlen, den Verarbeitungsprozess auf einem Apache Spark-Cluster mit erweiterten Funktionen ĂŒber die AWS Glue-API einzurichten. Im Grunde genommen kann man den alten, vertrauten Code in Python mit der Bibliothek PySpark verwenden und dessen AusfĂŒhrung auf N Knoten eines Clusters mit einer bestimmten Leistung einstellen, inklusive Monitoring, ohne sich mit Hadoop intern zu beschĂ€ftigen oder Docker-Container zu schleppen und AbhĂ€ngigkeitskonflikte zu lösen.
Noch einmal â eine einfache Idee. Es ist nicht notwendig, Apache Spark einzurichten; man muss lediglich Code in Python fĂŒr PySpark schreiben, diesen lokal auf dem Desktop testen und dann auf einem groĂen Cluster in der Cloud ausfĂŒhren, wobei man angibt, wo die Quelldaten liegen und wo das Ergebnis abgelegt werden soll. Manchmal ist das notwendig und nĂŒtzlich, und so ist es bei uns eingerichtet:
Wenn etwas auf einem Spark-Cluster mit Daten in S3 berechnet werden muss, schreiben wir den Code in Python/PySpark, testen ihn und auf gehtâs in die Cloud.
Was ist mit der Orchestrierung? Und wenn eine Aufgabe fehlschlÀgt und verloren geht? Ja, es wird vorgeschlagen, eine schöne Pipeline im Stil von Apache Pig zu erstellen, und wir haben es sogar ausprobiert, aber wir haben uns entschieden, vorerst unsere tiefgehend angepasste Orchestrierung mit PHP und JavaScript zu verwenden (ich verstehe, dass es kognitiven Dissonanz erzeugt, aber es funktioniert seit Jahren und fehlerfrei).
Das Format der im See gespeicherten Dateien ist der SchlĂŒssel zur Leistung.
Es ist sehr, sehr wichtig, noch zwei weitere SchlĂŒsselpunkte zu verstehen. Damit die Anfragen an die Datei-Daten im See so schnell wie möglich ausgefĂŒhrt werden und die Leistung nicht beim HinzufĂŒgen neuer Informationen abnimmt, mĂŒssen folgende Punkte beachtet werden:
- Die Spalten der Dateien mĂŒssen separat gespeichert werden (um nicht alle Zeilen lesen zu mĂŒssen, um zu verstehen, was in den Spalten ist). Dazu haben wir das Parquet-Format mit Kompression gewĂ€hlt.
- Es ist sehr wichtig, die Dateien nach Kategorien wie: Sprache, Jahr, Monat, Tag, Woche zu sharden. Engines, die diesen Sharding-Typ verstehen, werden nur in die benötigten Ordner schauen, ohne die gesamten Daten durchzusehen.
Im Wesentlichen stellen Sie auf diese Weise die Ausgangsdaten fĂŒr oben aufgesetzte Analyse-Engines am effizientesten zur VerfĂŒgung, die auch selektiv auf geschlossene Ordner zugreifen und nur die benötigten Spalten aus den Dateien lesen können. Es ist nicht nötig, Daten irgendwohin âhochzuladenâ (der Speicherplatz wĂŒrde einfach platzen) â legen Sie sie einfach direkt in der richtigen Form in das Dateisystem ab. NatĂŒrlich sollte klar sein, dass es nicht sehr sinnvoll ist, eine riesige CSV-Datei im DataLake zu speichern, die zuerst zeilenweise vom Cluster gelesen werden muss, um die Spalten herauszuziehen. Ăberdenken Sie die beiden oben genannten Punkte noch einmal, falls Ihnen bisher unklar ist, warum das alles notwendig ist.
AWS Athena â der âTeufelâ aus der Kiste
Und hier, beim Erstellen eines Sees, stieĂen wir irgendwie zufĂ€llig auf Amazon Athena. Plötzlich stellte sich heraus, dass wir, indem wir unsere umfangreichen Protokolldateien sorgfĂ€ltig im richtigen (Parquet) spaltenbasierten Format in Scharden-Ordner ablegten, sehr schnell Ă€uĂerst informative Abfragen durchfĂŒhren und Berichte erstellen konnten, OHNE einen Apache Spark/Glue-Cluster zu nutzen.
Die Athena-Engine, die auf Daten in S3 basiert, basiert auf dem legendĂ€ren â Vertreter des MPP (Massive Parallel Processing)-Ansatzes zur Datenverarbeitung, der Daten dort abruft, wo sie liegen, von S3 und Hadoop bis hin zu Cassandra und einfachen Textdateien. Man muss nur Athena bitten, eine SQL-Abfrage auszufĂŒhren, und dann lĂ€uft alles âschnell und selbststĂ€ndigâ. Es ist wichtig zu erwĂ€hnen, dass Athena âintelligentâ ist, nur in die benötigten shardierten Ordner geht und nur die benötigten Spalten aus der Anfrage liest.
Die Abfragen an Athena sind ebenfalls interessant tarifiert. Wir zahlen fĂŒr . Das heiĂt, nicht fĂŒr die Anzahl der Maschinen im Cluster pro Minute, sondern⊠fĂŒr die tatsĂ€chlich gescannten Daten, die auf 100-500 Maschinen benötigt werden, um die Abfrage auszufĂŒhren.
Und wenn man nur die benötigten Spalten aus richtig shardierten Ordnern abfragt, stellt sich heraus, dass der Dienst Athena uns nur einige Dutzend Dollar im Monat kostet. Nun, das ist doch fast kostenlos im Vergleich zur Analyse in Clustern!
Hier ist ĂŒbrigens, wie wir unsere Daten in S3 shardieren:
In kurzer Zeit begannen in der Firma völlig unterschiedliche Abteilungen, von der Informationssicherheit bis zur Analyse, aktiv Anfragen an Athena zu stellen und schnell, innerhalb von Sekunden, nĂŒtzliche Antworten aus den âgroĂenâ Daten ĂŒber lĂ€ngere ZeitrĂ€ume hinweg zu erhalten: Monate, Halbjahre usw.
Aber wir sind weitergegangen und haben Antworten in die Cloud geholt. : Ein Analyst schreibt in der gewohnten Konsole eine SQL-Anfrage, die auf 100-500 Maschinen âzu geringen Kostenâ die Daten in S3 durchsucht und die Antwort normalerweise innerhalb von Sekunden zurĂŒckgibt. Praktisch. Und schnell. Es ist schwer zu glauben.
Nachdem wir beschlossen haben, die Daten in S3 zu speichern, in einem effizienten, spaltenbasierten Format und mit sinnvoller Datenpartitionierung... haben wir einen DataLake und eine schnelle, kostengĂŒnstige Analytik-Engine erhalten â kostenlos. Und sie ist im Unternehmen sehr populĂ€r geworden, da sie SQL versteht und um ein Vielfaches schneller arbeitet als bei Start/Stopp/Einstellungen von Clustern. "Wenn das Ergebnis dasselbe ist, warum mehr bezahlen?"
Eine Abfrage an Athena sieht ungefĂ€hr so aus. Wenn gewĂŒnscht, kann man natĂŒrlich auch eine ausreichend , aber wir beschrĂ€nken uns auf eine einfache Gruppierung. Lassen Sie uns sehen, welche Antwortcodes der Kunde vor einigen Wochen in den Protokollen des Webservers hatte und sicherstellen, dass es keine Fehler gibt:
Fazit
Nachdem wir einen nicht gerade langen, aber schmerzhaften Weg zurĂŒckgelegt haben, in dem wir stĂ€ndig die Risiken, die KomplexitĂ€t und die Kosten der UnterstĂŒtzung angemessen bewertet haben, haben wir eine Lösung fĂŒr DataLake und Analytik gefunden, die uns sowohl in Bezug auf Geschwindigkeit als auch in Bezug auf die Kosten des Eigentums begeistert.
Es stellte sich heraus, dass es fĂŒr erfahrene Entwickler, die nie als Architekten gearbeitet haben und nicht wissen, wie man Quadrate auf Quadrate mit Pfeilen zeichnet und 50 Begriffe aus dem Hadoop-Ăkosystem kennt, durchaus möglich ist, ein effektives, schnelles und kostengĂŒnstiges DataLake fĂŒr die BedĂŒrfnisse völlig unterschiedlicher Abteilungen des Unternehmens zu erstellen.
Zu Beginn war es ĂŒberwĂ€ltigend, sich mit der Vielzahl an offenen und geschlossenen Softwarelösungen sowie der Verantwortung gegenĂŒber kĂŒnftigen Generationen auseinanderzusetzen. Starten Sie einfach mit dem Aufbau Ihres Data Lakes mit einfachen Werkzeugen: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3 âŠ, sammeln Sie Feedback und verstehen Sie tiefgehend die physikalischen Prozesse, die ablaufen. Alles Komplizierte und Unklare sollten Sie Ihren Rivalen ĂŒberlassen.
Wenn Sie nicht in die Cloud möchten und gerne offene Projekte unterstĂŒtzen, aktualisieren und patchen, können Sie ein Ă€hnliches System lokal auf gĂŒnstigen BĂŒrocomputern mit Hadoop und Presto aufbauen. Das Wichtigste ist, nicht stehenzubleiben, voranzukommen, nach einfachen und klaren Lösungen zu suchen, und alles wird bestimmt klappen! Viel Erfolg an alle und bis zum nĂ€chsten Mal!
Quelle: habr.com
