Es ist drei Jahre her, seit ich in das Unternehmen eingetreten bin, also eine Zusammenfassung meiner bisherigen Aktivitäten, einschließlich meines eigenen Memos.
Aufgrund des Entwicklungszeitraums konnte ich nicht jedes System im Detail verstehen und optimieren. Weil es von einer Person mit Informationen erstellt wurde, die innerhalb des Zeitraums geprüft wurden Etwas wie "Nein, nein, wenn Sie es richtig einstellen, erhalten Sie dieses Ergebnis nicht." Bitte beachten Sie, dass es viele geben kann. Außerdem hatte ich vor drei Jahren noch nie Linux oder SQL berührt Ich denke, dass der, für den ich am Anfang verantwortlich war, nicht so einfach zu machen war.
Eine Analyseplattform für die Querschnittsanzeige der KPIs unserer Spieleserie. Verwenden Sie fluentd, um RedShift zu füllen und in täglichen Chargen zu aggregieren. Das Aggregationsergebnis wurde in einer anderen Tabelle von RedShift gespeichert. Ruby wird für den Stapel verwendet, und CakePHP wird für das Framework verwendet. Da fluentd von Ruby erstellt wird, kann Ruby durch Erstellen von Plug-Ins erstellt werden. CakePHP ist eine Unternehmenskultur.
Ungefähr 6 Monate von Oktober 2013 bis März 2014 (parallel zu anderen Operationen, einschließlich Überprüfungszeitraum)
Nur das Bild, das ich unbedingt lernen wollte, weil ich es nur zum ersten Mal berührt habe ...
Die Wartungskosten von Red Shift waren für die geringe Datenmenge hoch. (Zu diesem Zeitpunkt war die Kostenleistung schlecht, da nur ein Knoten mit dichtem Speicher vorhanden war.) Außerdem ist die Aggregationszeit länger als erwartet und ich habe sie mit dem Slogan "Hadoop ist heutzutage beliebt, lasst es uns überprüfen" überprüft. Eingeführt, weil bestätigt wurde, dass die Aggregation zu geringen Kosten durchgeführt werden kann.
Eine Analyseplattform, mit der Sie KPIs für andere Spiele als die Serie anzeigen können. "Python ist reich an statistischen Bibliotheken. Wenn Sie also ein Analyseingenieur sind, warum nicht Python?" Es gab eine Empfehlung eines Senioren. Also habe ich Python für den Batch und Django für Python als Framework verwendet.
Ungefähr 14 Monate von April 2014 bis Juni 2015 (parallel zu anderen Arbeiten, einschließlich Überprüfungszeitraum. Die Visualisierung wird von einer anderen Person durchgeführt).
Ich glaube nicht, dass sich die Zählzeit dramatisch geändert hat (keine detaillierten Notizen mehr ...) Mit EMR könnten die Gesamtkosten jedoch auf etwa die Hälfte reduziert werden, da der Server nur für die Gesamtzeit gestartet werden muss. Ich denke, dass das Starten von Python hier die richtige Antwort war, um später Spark und maschinelles Lernen durchzuführen. Einfach zu schreiben!
Ich wollte die neue Technologie berühren, und Spark wurde zu einem heißen Thema, deshalb habe ich beschlossen, es zuerst zu versuchen. Wenn der Cache effektiv ist, wird die Aggregationszeit verkürzt, wenn die Aggregationszeit kurz ist, können die Aggregationskosten voraussichtlich reduziert werden, und da die Spark-Verarbeitung mit Python durchgeführt wird, ist die Migration einfach.
Der Wechsel von Hive zu Spark entspricht fast dem der zweiten Generation. Ich habe eine RDD-basierte mit Spark1.2 und eine DataFrame-basierte mit Spark1.4 erstellt.
Ungefähr 6 Monate von Juni 2015 bis Dezember 2015 (parallel zu anderen Vorgängen, einschließlich Überprüfungszeitraum)
Aufgrund der fehlenden Dokumentation war es schwierig, durch Ausprobieren aufzubauen. Selbst wenn ich zu einem Seminar gehe, gibt es viele Unternehmen, die sich in der Phase der Einführung befinden, so dass ich nicht viel ... Ich glaube, ich habe die Fähigkeiten erworben, die Ergebnisse von Google-Übersetzungen zu übersetzen, um unbekannte englische Artikel zu lesen. Wenn Spark die Cache-Funktion verwendet, ist die iterative Verarbeitung schnell (beim Aufteilen der DAU in verschiedene Segmente wird das Anmeldeprotokoll zwischengespeichert usw.). Der Nachteil besteht jedoch darin, dass dies einige Zeit in Anspruch nimmt, da der Cache beim ersten Mal nicht funktioniert. Es war.
Während ich verschiedene Dinge machte, dachte ich: "Oh, ich brauche Hive oder Spark überhaupt nicht mit dieser Datenmenge." Dies wurde bestätigt, indem der Aggregationsalgorithmus überprüft und überprüft wurde, dass bei korrekter Berücksichtigung des DB-Tabellendesigns kein Problem mit der aktuellen Datenmenge vorliegt. Aufgrund der Tatsache, dass der Cache beim ersten Mal von Spark nicht funktioniert, scheint es, dass die Verarbeitung auf der Datenbank oder dem Server die Aggregationszeit verkürzen kann.
Der Verarbeitungsinhalt ist der gleiche wie bei der vorherigen Generation. In Python in mehreren Prozessen verarbeitet. Anstatt alle Protokolle in die Datenbank zu stellen Ich habe nur die für die Aggregation erforderlichen Protokolle abgelegt und sie gelöscht, wenn sie nicht mehr verwendet wurden. (Protokolldatei bleibt in S3)
Ungefähr 3 Monate von Dezember 2015 bis Februar 2016 (parallel zu anderen Vorgängen, einschließlich Überprüfungszeitraum)
Im Vergleich zu Spark beträgt die Aggregationszeit weniger als die Hälfte. Keine zusätzlichen Kosten, da wir einen Server und eine Datenbank verwendet haben, die immer für andere Zwecke ausgeführt werden. Es fühlt sich so an, als würde dies für ein paar GB pro Tag etwas bewirken.
Selbst wenn die Datenmenge in Zukunft zunimmt, kann sie bis zu einem gewissen Grad verarbeitet werden. Es besteht jedoch die Sorge, dass sie nicht verwendet werden kann, wenn der Analysebereich erweitert und die Datenmenge gleichzeitig erhöht wird und wenn die Datenmenge bei der Ad-hoc-Analyse groß ist, wird ein Spark-Cluster gestartet. Ich habe getan ... Ich habe überprüft, dass es einfacher wäre, mit BigQuery tägliche Batch- und Ad-hoc-Analysen durchzuführen.
Der Verarbeitungsinhalt ist der gleiche wie bei der vorherigen Generation. Ich habe Luigi, ein Framework zum Erstellen von Datenpipelines von Python, für Stapel verwendet.
Von Februar 2016 bis heute
Es braucht viel Zeit, um einen Tisch zu machen. Selbst wenn Sie Google fragen, wird es einige Zeit dauern. Erwarten Sie es also in Zukunft. Das derzeitige Limit von 1000 Tabellen pro Abfrage ist ebenfalls schwierig zu verwenden. Bei Titeln, die 1000 Tage nach der Veröffentlichung überschreiten, ist es nicht möglich, einfach den kumulierten Rechnungsbetrag für jeden Benutzer ab dem X. und Y. Tag anzufordern. Das Limit von 1000 Tabellen muss vermieden werden, z. B. das Erstellen einer Tabelle für jeden Tag mit "kumulierter Abrechnungsbetrag bis zum vorherigen Tag + Abrechnungsbetrag für den aktuellen Tag".
Die für die Aggregation erforderliche Zeit ist jedoch kurz, und selbst wenn alle Daten enthalten sind, fallen fast keine Verwaltungskosten an. Daher ist es ein großer Vorteil, dass die Ad-hoc-Analyse einfach ist. Die Aggregationskosten für die ersten 1 TB eines jeden Monats sind kostenlos. Wenn also die Datenmenge gering ist, sind die Aggregationskosten nahezu Null.
Wenn das zu aggregierende Protokoll ungefähr mehrere GB umfasst
| Artikel | Installationskosten | Betriebskosten | Einfache Ad-hoc-Analyse |
|---|---|---|---|
| RedShift | ◯ | ✕(Wenn Sie SSD verwenden, geht es um △) | ◯ |
| Hive | ◯ | △ | △ |
| Spark | △ | ◯ | △ |
| SQL und verteilte Verarbeitung | △ | ◎ | △ |
| BigQuery | △(Die Tabellenerstellung ist langsam) | ？(Die endgültigen Kosten sind noch unbekannt. Wahrscheinlich ◯) | ◯ |
[Einführungskosten] ◯: Wenn Sie SQL schreiben, fallen fast keine Kosten an △: Neben dem Schreiben von SQL sind noch weitere Punkte zu beachten
[Betriebskosten] ◎: Keine zusätzlichen Kosten, da der Server und die Datenbank, die immer für andere Zwecke ausgeführt werden, verwendet werden. ◯: 50.000 oder weniger △: Etwas weniger als 100.000 ✕: Über 100.000
[Einfache Ad-hoc-Analyse] ◯: Kein Problem, wenn SQL angewendet wird △: Es gibt einige Schwierigkeiten. Langsame Antwort oder Notwendigkeit, den Cache zu berücksichtigen
Ich denke, dass es je nach Datenmenge und Zweck der Analyse möglicherweise nicht passt. Ich denke, es gibt einige Orte, an denen On-Pres besser ist als die Cloud. Immerhin fühlt es sich wie die richtige Person am richtigen Ort an. Persönlich mag ich Spark oder BigQuery. Spark verfügt über eine Bibliothek für maschinelles Lernen und ist flexibel, da sie zusätzlich zu SQL von Scala und Python verarbeitet werden kann. Danach, wenn die Verarbeitungsgeschwindigkeit verbessert wird. BigQuery erfordert keine Feinabstimmung und ist kostengünstig. Daher ist es gut, dass es einfach zu bedienen ist. Ich hoffe, dass die aktuellen Probleme bald gelöst werden. Rückblickend wurden alle sechs Monate umfangreiche Renovierungsarbeiten durchgeführt. Ich konnte nicht eins nach dem anderen tiefer graben, aber ich bin dankbar für die Umgebung, in der ich in drei Jahren so viele Dinge erlebt habe.
Recommended Posts