Cela fait trois ans que j'ai rejoint l'entreprise, donc un résumé de ce que j'ai fait jusqu'à présent, y compris mon propre mémo.
En raison de la période de développement, je ne pouvais pas comprendre et régler chaque système en détail. Parce qu'il a été construit par un individu dont les informations ont été examinées dans la période Quelque chose comme "Non, non, si vous le réglez correctement, vous n'obtiendrez pas ce résultat." Veuillez noter qu'il peut y en avoir plusieurs. De plus, il y a trois ans, je n'avais jamais touché à Linux ou à SQL, donc Je pense que celui dont j'étais en charge au début n'était pas aussi simple à réaliser.
Une plateforme d'analyse pour une visualisation transversale des KPI de notre série de jeux Utilisez fluentd pour remplir RedShift et agréger dans des lots quotidiens, Le résultat de l'agrégation a été stocké dans une autre table de RedShift. Ruby est utilisé pour le batch et CakePHP est utilisé pour le framework. Puisque fluentd est fait par Ruby, Ruby peut être créé en créant des plug-ins. CakePHP est une culture d'entreprise.
Environ 6 mois d'octobre 2013 à mars 2014 (parallèlement à d'autres opérations, y compris la période de vérification)
Seule l'image que j'avais désespérément envie d'apprendre car je ne l'ai touchée que pour la première fois ...
Le coût de maintenance de Red Shift était élevé pour la petite quantité de données. (À ce moment-là, les performances de coût étaient mauvaises car il n'y avait qu'un nœud de stockage dense) De plus, le temps d'agrégation est plus long que prévu, et je l'ai vérifié avec le slogan "Hadoop est populaire ces jours-ci, vérifions-le." Introduit parce qu'il a été confirmé que l'agrégation peut être effectuée à faible coût.
Une plateforme d'analyse qui vous permet de voir les KPI pour les jeux autres que la série. "Python est riche en bibliothèques statistiques, donc si vous êtes un ingénieur d'analyse, pourquoi pas Python?" Il y avait une recommandation d'une personne âgée. J'ai donc utilisé Python pour le batch et django pour Python comme framework.
Environ 14 mois d'avril 2014 à juin 2015 (parallèlement à d'autres travaux, y compris la période de vérification. La visualisation est gérée par une autre personne)
Je ne pense pas que le temps de décompte ait radicalement changé (il ne reste plus de notes détaillées ...) Cependant, avec EMR, le coût total pourrait être réduit à environ la moitié car le serveur n'a besoin d'être démarré que pour la durée totale. Je pense que démarrer Python ici était la bonne réponse pour faire Spark et l'apprentissage automatique plus tard. Facile à écrire!
Je voulais toucher à la nouvelle technologie, et Spark devenait un sujet brûlant, alors j'ai décidé de l'essayer en premier. Si le cache est efficace, le temps d'agrégation sera raccourci, si le temps d'agrégation est court, le coût d'agrégation peut être réduit, et comme le traitement Spark est effectué avec Python, il est facile de migrer.
Le simple changement de Hive à Spark est presque identique à celui de la 2ème génération. J'en ai créé un basé sur RDD avec Spark1.2 et un basé sur DataFrame avec Spark1.4.
Environ 6 mois de juin 2015 à décembre 2015 (parallèlement à d'autres opérations, y compris la période de vérification)
En raison du manque de documentation, il était difficile de construire par essais et erreurs. Même si je vais à un séminaire, il y a beaucoup d'entreprises en train d'envisager l'introduction, donc je ne peux pas beaucoup consulter ... Je pense avoir acquis les compétences nécessaires pour traduire les résultats des traductions Google afin de lire des articles anglais inconnus. Si Spark utilise la fonction de cache, le traitement itératif est rapide (lors de la division de la DAU en différents segments, le journal de connexion est mis en cache, etc.), mais l'inconvénient est que cela prend du temps car le cache ne fonctionne pas la première fois. C'était.
En faisant diverses choses, j'ai pensé: "Oh, je n'ai pas besoin de Hive ou Spark en premier lieu avec cette quantité de données." Cela a été confirmé en examinant l'algorithme d'agrégation et en vérifiant qu'il n'y a pas de problème avec la quantité actuelle de données lorsque l'on considère correctement la conception de la table DB. De plus, en raison du fait que le cache ne fonctionne pas la première fois de Spark, il semble que le traitement sur la base de données ou le serveur peut raccourcir le temps d'agrégation.
Le contenu du traitement est le même que celui de la génération précédente. Changé pour traiter dans plusieurs processus en Python. Au lieu de mettre tous les journaux dans la base de données Je n'ai mis que les journaux nécessaires à l'agrégation et les ai supprimés lorsqu'ils n'étaient plus utilisés. (Le fichier journal reste dans S3)
Environ 3 mois de décembre 2015 à février 2016 (parallèlement à d'autres opérations, y compris la période de vérification)
Par rapport à Spark, le temps d'agrégation est inférieur à la moitié. Aucun coût supplémentaire car nous avons utilisé un serveur et une base de données toujours en cours d'exécution à d'autres fins. Je pense que cela ne fonctionnera pas s'il s'agit d'environ Go par jour.
Même si la quantité de données augmente à l'avenir, elle peut être gérée dans une certaine mesure, mais on craint qu'elle ne soit pas utilisable lorsque la plage d'analyse s'élargit et que la quantité de données augmente à la fois, et lorsque la quantité de données est importante dans l'analyse ad hoc, un cluster Spark est lancé. Je faisais ... J'ai vérifié que ce serait plus facile si je pouvais effectuer des analyses quotidiennes par lots et ad hoc avec BigQuery.
Le contenu du traitement est le même que celui de la génération précédente. J'ai utilisé Luigi, un framework pour construire des pipelines de données fait par Python, pour les lots.
De février 2016 à nos jours
Il faut beaucoup de temps pour faire une table. Même si vous demandez à Google, cela prendra du temps, alors attendez-vous à le faire à l'avenir. La limite actuelle de 1 000 tables par requête est également difficile à utiliser. Pour les titres qui dépassent 1000 jours après la sortie, il n'est pas possible de demander simplement le montant de facturation cumulé pour chaque utilisateur aux Xe et Ye jours. Il est nécessaire d'éviter la limite de 1 000 tables, comme créer une table pour chaque jour avec «montant de facturation cumulé jusqu'au jour précédent + montant de facturation pour la journée en cours».
Cependant, le temps requis pour l'agrégation est court, et même si toutes les données sont incluses, il n'y a presque aucun coût de gestion, c'est donc un gros avantage que l'analyse ad hoc soit facile. Le coût d'agrégation pour le premier 1 To de chaque mois est gratuit, donc si la quantité de données est faible, le coût d'agrégation sera presque nul.
Lorsque le journal à agréger est d'environ plusieurs Go
| article | Les coûts d'installation | Le coût d'exploitation | Facilité d'analyse ad hoc |
|---|---|---|---|
| RedShift | ◯ | ✕(Si vous utilisez un SSD, il s'agit de △) | ◯ |
| Hive | ◯ | △ | △ |
| Spark | △ | ◯ | △ |
| SQL et traitement distribué | △ | ◎ | △ |
| BigQuery | △(La création de table est lente) | ？(Le coût final est encore inconnu. Probablement ◯) | ◯ |
[Coût d'introduction] ◯: Si vous écrivez SQL, il n'y a presque aucun coût △: Il y a d'autres points à considérer en plus d'écrire du SQL
[Le coût d'exploitation] ◎: Aucun coût supplémentaire car le serveur et la base de données qui sont toujours en cours d'exécution à d'autres fins sont utilisés. ◯: 50 000 ou moins △: un peu moins de 100 000 ✕: plus de 100 000
[Facilité d'analyse ad hoc] ◯: Pas de problème si SQL est appliqué △: Il y a quelques difficultés. Réponse lente ou besoin de prendre en compte le cache
Je pense que cela peut ne pas convenir en fonction de la quantité de données et du but de l'analyse. Je pense qu'il y a des endroits où on-pres est meilleur que le cloud. Après tout, on se sent comme la bonne personne au bon endroit. Personnellement, j'aime Spark ou BigQuery. Spark a une bibliothèque d'apprentissage automatique, et c'est bien parce qu'elle est flexible car elle peut être traitée par Scala et Python en plus de SQL. Après cela, si la vitesse de traitement est améliorée. BigQuery ne nécessite pas de réglage précis et est peu coûteux, il est donc bon qu'il soit facile à utiliser. J'espère que les problèmes actuels seront bientôt résolus. Avec le recul, il subissait des rénovations majeures à un rythme d'une fois tous les six mois. Je n'ai pas pu creuser plus profondément un par un, mais je suis reconnaissant pour l'environnement où j'ai vécu tant de choses en trois ans.
Recommended Posts