Serveranalysesysteme

Dies ist der zweite Teil einer Artikelserie über analytische Systeme (Link zu Teil 1).

Heute besteht kein Zweifel mehr daran, dass eine sorgfältige Datenverarbeitung und Interpretation der Ergebnisse nahezu jeder Art von Unternehmen helfen kann. Dabei werden analytische Systeme zunehmend mit Parametern belastet und die Anzahl der Trigger und Benutzerereignisse in Anwendungen nimmt zu.
Aus diesem Grund stellen Unternehmen ihren Analysten immer mehr „Rohinformationen“ zur Verfügung, die sie analysieren und in die richtigen Entscheidungen umwandeln können. Die Bedeutung eines Analysesystems für ein Unternehmen sollte nicht unterschätzt werden, und das System selbst sollte zuverlässig und nachhaltig sein.

Kundenanalysten

Bei der Kundenanalyse handelt es sich um einen Dienst, den ein Unternehmen über das offizielle SDK mit seiner Website oder Anwendung verbindet, in seine eigene Codebasis integriert und Ereignisauslöser auswählt. Dieser Ansatz hat einen offensichtlichen Nachteil: Aufgrund der Einschränkungen des von Ihnen gewählten Dienstes werden möglicherweise nicht alle erfassten Daten genau so verarbeitet, wie Sie es möchten. Auf einem System ist es beispielsweise nicht einfach, MapReduce-Aufgaben auszuführen, auf einem anderen können Sie Ihr Modell nicht ausführen. Ein weiterer Nachteil wird die regelmäßige (beeindruckende) Rechnung für Dienstleistungen sein.
Es gibt viele Client-Analytics-Lösungen auf dem Markt, doch früher oder später stehen Analysten vor der Tatsache, dass es keinen Universaldienst gibt, der für jede Aufgabe geeignet ist (während die Preise für alle diese Dienste ständig steigen). In einer solchen Situation entscheiden sich Unternehmen häufig dafür, ein eigenes Analysesystem mit allen erforderlichen benutzerdefinierten Einstellungen und Funktionen zu erstellen.

Serveranalysten

Bei der serverseitigen Analyse handelt es sich um einen Dienst, der intern auf unternehmenseigenen Servern und (normalerweise) intern bereitgestellt werden kann. In diesem Modell werden alle Benutzerereignisse auf internen Servern gespeichert, sodass Entwickler verschiedene Datenbanken zur Speicherung ausprobieren und die bequemste Architektur auswählen können. Und selbst wenn Sie für einige Aufgaben weiterhin clientseitige Analysen von Drittanbietern nutzen möchten, ist dies weiterhin möglich.
Serverseitige Analysen können auf zwei Arten bereitgestellt werden. Erstens: Wählen Sie einige Open-Source-Dienstprogramme aus, stellen Sie sie auf Ihren Computern bereit und entwickeln Sie Geschäftslogik.

Pros
Cons

Sie können alles anpassen, was Sie möchten
Dies ist oft sehr schwierig und erfordert separate Entwickler

Zweitens: Nutzen Sie SaaS-Dienste (Amazon, Google, Azure), anstatt sie selbst bereitzustellen. Im dritten Teil werden wir ausführlicher auf SaaS eingehen.

Pros
Cons

Bei mittleren Volumina ist es vielleicht günstiger, aber bei großem Wachstum wird es immer noch zu teuer
Es ist nicht möglich, alle Parameter zu steuern

Die Administration wird vollständig auf die Schultern des Dienstleisters übertragen
Es ist nicht immer bekannt, was sich im Dienst befindet (wird möglicherweise nicht benötigt)

So sammeln Sie Serveranalysen

Wenn wir von der Verwendung von Client-Analysen Abstand nehmen und unsere eigenen entwickeln wollen, müssen wir zunächst die Architektur des neuen Systems durchdenken. Im Folgenden erkläre ich Ihnen Schritt für Schritt, was Sie beachten müssen, warum jeder Schritt nötig ist und welche Tools Sie nutzen können.

1. Datenerfassung

Genau wie bei der Kundenanalyse wählen Unternehmensanalysten zunächst die Arten von Ereignissen aus, die sie in Zukunft untersuchen möchten, und sammeln sie in einer Liste. Typischerweise treten diese Ereignisse in einer bestimmten Reihenfolge auf, die als „Ereignismuster“ bezeichnet wird.
Stellen Sie sich als Nächstes vor, dass eine mobile Anwendung (Website) regelmäßige Benutzer (Geräte) und viele Server hat. Um Ereignisse sicher von Geräten an Server zu übertragen, ist eine Zwischenschicht erforderlich. Abhängig von der Architektur kann es mehrere unterschiedliche Ereigniswarteschlangen geben.
Apache Kafka - Das Pub/Sub-Warteschlange, die als Warteschlange zum Sammeln von Ereignissen verwendet wird.

Согласно Beitrag auf Quora 2014 beschloss der Erfinder von Apache Kafka, die Software nach Franz Kafka zu benennen, weil „es ein für das Schreiben optimiertes System ist“ und weil er Kafkas Werke liebte. — Wikipedia

In unserem Beispiel gibt es viele Datenproduzenten und Datenkonsumenten (Geräte und Server), und Kafka hilft dabei, sie miteinander zu verbinden. Die Verbraucher werden in den folgenden Schritten detaillierter beschrieben, wobei sie die Hauptthemen sein werden. Jetzt betrachten wir nur Datenproduzenten (Ereignisse).
Kafka fasst die Konzepte von Warteschlange und Partition zusammen; es ist besser, an anderer Stelle genauer darüber zu lesen (z. B. in Dokumentation). Ohne auf Details einzugehen, stellen wir uns vor, dass eine mobile Anwendung für zwei verschiedene Betriebssysteme gestartet wird. Dann erstellt jede Version ihren eigenen separaten Ereignisstrom. Produzenten senden Ereignisse an Kafka, sie werden in einer geeigneten Warteschlange aufgezeichnet.

(Bild daher)

Gleichzeitig können Sie mit Kafka Blöcke einlesen und einen Strom von Ereignissen in Mini-Batches verarbeiten. Kafka ist ein sehr praktisches Tool, das sich gut an wachsende Anforderungen anpassen lässt (z. B. durch Geolokalisierung von Ereignissen).
Normalerweise reicht ein Shard, aber bei der Skalierung wird es (wie immer) komplizierter mit der Kommunikation. Wahrscheinlich möchte niemand in der Produktion nur einen physischen Shard verwenden, da die Architektur fehlertolerant sein muss. Neben Kafka gibt es eine weitere bekannte Lösung – RabbitMQ. Wir haben es in der Produktion nicht als Warteschlange für die Ereignisanalyse verwendet (wenn Sie über solche Erfahrungen verfügen, teilen Sie uns dies in den Kommentaren mit!). Es wurde jedoch AWS Kinesis verwendet.

Bevor wir zum nächsten Schritt übergehen, muss noch eine weitere Ebene des Systems erwähnt werden – die Speicherung von Rohprotokollen. Dies ist keine obligatorische Ebene, aber sie ist nützlich für den Fall, dass etwas schief geht und die Ereigniswarteschlangen in Kafka auf Null zurückgesetzt werden. Das Speichern von Rohprotokollen erfordert keine komplexe und teure Lösung, Sie können sie einfach irgendwo in der richtigen Reihenfolge schreiben (sogar auf eine Festplatte).

2. Verarbeitung von Ereignisströmen

Nachdem wir alle Ereignisse vorbereitet und in die entsprechenden Warteschlangen gestellt haben, geht es mit dem Verarbeitungsschritt weiter. Hier verrate ich Ihnen die beiden gängigsten Verarbeitungsmöglichkeiten.
Die erste Möglichkeit besteht darin, Spark Streaming im Apache-System zu aktivieren. Alle Apache-Produkte basieren auf HDFS, einem sicheren Dateisystem mit Dateirepliken. Spark Streaming ist ein benutzerfreundliches Tool, das Streaming-Daten verarbeitet und gut skaliert. Es kann jedoch schwierig sein, es aufrechtzuerhalten.
Eine andere Möglichkeit besteht darin, einen eigenen Event-Handler zu erstellen. Dazu müssen Sie beispielsweise eine Python-Anwendung schreiben, diese in Docker erstellen und die Kafka-Warteschlange abonnieren. Wenn Trigger bei den Docker-Handlern eintreffen, beginnt die Verarbeitung. Bei dieser Methode müssen die Anwendungen jederzeit ausgeführt werden.
Nehmen wir an, wir haben uns für eine der oben beschriebenen Optionen entschieden und gehen zur Verarbeitung selbst über. Prozessoren sollten damit beginnen, die Gültigkeit der Daten zu überprüfen und Müll und „kaputte“ Ereignisse zu filtern. Zur Validierung verwenden wir normalerweise Zerberus. Anschließend können Sie eine Datenzuordnung durchführen: Daten aus verschiedenen Quellen werden normalisiert und standardisiert, um einer gemeinsamen Tabelle hinzugefügt zu werden.

3. Datenbank

Der dritte Schritt besteht darin, normalisierte Ereignisse beizubehalten. Wenn wir mit einem vorgefertigten Analysesystem arbeiten, müssen wir häufig darauf zugreifen. Daher ist es wichtig, eine geeignete Datenbank auszuwählen.
Wenn die Daten gut in ein festes Schema passen, können Sie wählen Clickhouse oder eine andere Spaltendatenbank. Aggregationen funktionieren also sehr schnell. Der Nachteil besteht darin, dass das Schema starr festgelegt ist und es daher nicht funktioniert, beliebige Objekte ohne Verfeinerung hinzuzufügen (z. B. wenn ein nicht standardmäßiges Ereignis auftritt). Aber es geht wirklich schnell.
Für unstrukturierte Daten können Sie beispielsweise NoSQL verwenden: Apache Kassandra. Es läuft auf HDFS, lässt sich gut replizieren, Sie können viele Instanzen erstellen und ist fehlertolerant.
Sie können auch etwas Einfacheres ansprechen, zum Beispiel: MongoDB. Es ist ziemlich langsam und für kleine Volumina geeignet. Das Plus ist aber, dass es sehr einfach ist und daher für den Einstieg geeignet ist.

4. Aggregationen

Nachdem wir alle Ereignisse sorgfältig gespeichert haben, möchten wir alle wichtigen Informationen aus der eingegangenen Charge sammeln und die Datenbank aktualisieren. Weltweit wollen wir relevante Dashboards und Metriken. Zum Beispiel von Ereignissen, um ein Benutzerprofil zu sammeln und irgendwie das Verhalten zu messen. Ereignisse werden aggregiert, gesammelt und wieder gespeichert (bereits in Benutzertabellen). Gleichzeitig ist es möglich, ein System so aufzubauen, dass auch ein Filter mit dem koordinierenden Aggregator verbunden ist: um Benutzer nur von einer bestimmten Art von Ereignissen zu sammeln.
Wenn danach jemand im Team nur High-Level-Analysen benötigt, können externe Analysesysteme angeschlossen werden. Sie können Mixpanel wieder nehmen. Da es jedoch recht teuer ist, werden nicht alle Benutzerereignisse dorthin gesendet, sondern nur das, was benötigt wird. Dazu müssen wir einen Koordinator erstellen, der einige Rohereignisse oder etwas, das wir zuvor selbst aggregiert haben, an externe Systeme, APIs oder Werbeplattformen überträgt.

5. Frontend

Sie müssen das Frontend mit dem erstellten System verbinden. Ein gutes Beispiel ist der Service Redashist eine Datenbank-GUI, die beim Erstellen von Dashboards hilft. So funktioniert die Interaktion:

1. Der Benutzer führt eine SQL-Abfrage durch.
2. Als Antwort erhält er ein Zeichen.
3. Erstellt eine „neue Visualisierung“ dafür und erhält eine schöne Grafik, die Sie bereits selbst speichern können.

Visualisierungen im Dienst werden automatisch aktualisiert, Sie können Ihre Überwachung konfigurieren und verfolgen. Redash ist kostenlos, wenn es selbst gehostet wird, aber als SaaS kostet es 50 US-Dollar pro Monat.

Abschluss

Nachdem Sie alle oben genannten Schritte ausgeführt haben, erstellen Sie Ihre Serveranalyse. Bitte beachten Sie, dass dies nicht so einfach ist wie die Anbindung von Kundenanalysen, da alles selbst konfiguriert werden muss. Bevor Sie Ihr eigenes System erstellen, lohnt es sich daher, den Bedarf an einem seriösen Analysesystem mit den Ressourcen zu vergleichen, die Sie bereit sind, dafür bereitzustellen.
Wenn Sie alle Berechnungen durchgeführt haben und festgestellt haben, dass die Kosten zu hoch sind, werde ich im nächsten Teil darüber sprechen, wie Sie eine günstigere Version der Back-End-Analyse erstellen können.

Danke fürs Lesen! Über Fragen in den Kommentaren freue ich mich.

Source: habr.com