Post on 30-Jul-2015
Analytics Spideo Cassandra Day
1
Mouna Damak damak@spideo.tv Paul de Monchy monchy@spideo.tv Randa Zarkik zarkik@spideo.tv / @AFCRanda
Mardi 16 juin 2015
Plan 1. Spideo 2. Analytics 3. Pourquoi Cassandra ? 4. Etude de cas
I. Compteur avec filtres II. Top 10 III. Utilisateurs actifs
5. Conclusion
Plan 1. Spideo 2. Analytics 3. Pourquoi Cassandra ? 4. Etude de cas
I. Compteur avec filtres II. Top 10 III. Utilisateurs actifs
5. Conclusion
4
Qu’allez vous regarder ce soir ?
75% d’indécis devant leur TV
Rendez-moi mon vendeur du vidéoclub !
Service de recommandation “content centric” Toujours expliquer la recommandation pour créer un lien de confiance avec les utilisateurs
Les Avantages des algorithmes de Spideo : - Temps réels - Scalables - Explicables - A fait ses preuves
Algorithmes de recommandation innovants
Mood-Based Discovery
Related Content Profile-Based Suggestions
Semantic Search
Quelques clients actuels de nos solutions
Plan 1. Spideo 2. Analytics 3. Pourquoi Cassandra ? 4. Etude de cas
I. Compteur avec filtres II. Top 10 III. Utilisateurs actifs
5. Conclusion
Content and User Metrics
Business Rules User Segmentation
Des analytics... ...pour aider nos clients à bien analyser et mieux monétiser leurs services
Plan 1. Spideo 2. Analytics 3. Pourquoi Cassandra ? 4. Etude de cas
I. Compteur avec filtres II. Top 10 III. Utilisateurs actifs
5. Conclusion
12
Il était une fois … analytics
13
Must have
- Scalabilité
- Tolérance aux pannes
- Haute disponibilité
- Critères de performance : . Écriture : 2000 logs/s . Lecture : < 60 ms/requête sur une période d’1 mois
14
Base de données distribuée
15
Oui mais laquelle ?
16
17
18
19
Mature
Intuitive
Flexible
Performante
Distribuée
“ Hype ”
20
Le POC
● Une requête complexe ● Temps de réponse à ISO config hardware ● Une semaine pour l’implémenter en Cassandra et PostreSQL
21
22
Cassandra 36 ms
PostreSQL ~ 3 s Après tuning ~ 1 s
Temps de réponse sur toute l’année et tous les segments
=> 28x plus rapide
Le CAP
23 sources: Cassandra: the Definitive Guide.
Les cerises sur le gâteau
24
Timeseries
25
Counter
26
Le vote
27
And the winner is ...
28
29
30
Concrètement, comment ça marche?
31
Plan 1. Spideo 2. Analytics 3. Pourquoi Cassandra ? 4. Etude de cas
I. Compteur avec filtres II. Top 10 III. Utilisateurs actifs
5. Conclusion
Rappel dashboard
33
Compteurs avec filtres
34
[Mood]
[Theme]
[Format]
Envies (moods)
35
Thèmes
36
Quelques thèmes
Format
37
Définition du use case
38
Nombre de vues sur les films qui correspondent à l’envie rire, et au thème « en voyage »
La requête d’abord
39
Si on normalise :
=> Problème : toute la table sera remontée en RAM pour faire le count
40
Si on dénormalise:
41
CREATE TABLE watches( mood text, theme text, format text, day int, total counter, PRIMARY KEY ((mood,theme, format), day)
) CLUSTERING ORDER BY (day ASC)
# partition = Filtre
clustering column
Dans cette modélisation, on aura autant de partitions que de combinaison
possibles de
(mood, theme, format)
42
Cardinalité pour un contenu
43
(mood, theme, format)
1 + 3 1 + 8 1 + 1
= 4 x 9 x 2 = 72
Cardinalité totale
44
(mood, theme, format)
1 + 23 1 + 749 1 + 12
= 24 x 750 x 13 = 234 000
Un watch de film Rire et En voyage => On écrit 8 fois ( 2 * 2 * 2)
45
mood
Avantage : Temps de réponse instantané
Inconvénient :
Nombre d’écriture important
46
Plan 1. Spideo 2. Analytics 3. Pourquoi Cassandra ? 4. Etude de cas
I. Compteur avec filtres II. Top 10 III. Utilisateurs actifs
5. Conclusion
Classement Top 10
Exemple: Top 10 des contenus les plus regardés
48
Classement Top 10
49
Classement Top 10
50
CREATE TABLE watches_per_content(
day text, content_id text, nb_of_watch counter, total counter static, PRIMARY KEY ((day), content_id)
# partition clustering column
1- Table de compteur: compter le nombre de vues par contenu
Classement Top 10
Map<day, SortedMap<content_id,nb_of_watch>>
51
01-01-2015 52 175 id_Divergent id_The_Other_Women id_Noah
20 067 18 081 14 027
# partition total
1- Table de compteur:
Classement Top 10
Map<day, SortedMap<nbwatch,SortedMap<content,_>>
52
01-01-2015 20 067 18 081 14 027
Divergent The Other Women Noah
# partition
2- Table de tri:
Classement Top 10
53
CREATE TABLE content_ranking( day text, nb_of_watch bigint, content_id text, PRIMARY KEY ((day), nb_of_watch, content_id)
) CLUSTERING ORDER BY (nb_of_watch DESC, content_id ASC)
Ordre sur le nb de vues
2- Table de tri: trier les contenus par nombre de vues.
Classement Top 10
54
CREATE TABLE content_ranking( day text, nb_of_watch bigint, content_id text, PRIMARY KEY ((day), nb_of_watch, content_id)
) CLUSTERING ORDER BY (nb_of_watch DESC, content_id ASC)
CREATE TABLE watches_per_content( day text, content_id text, nb_of_watch counter, total counter static, PRIMARY KEY ((day), content_id)
Table où on écrit Table où on lit Batchs
Plan 1. Spideo 2. Analytics 3. Pourquoi Cassandra ? 4. Etude de cas
I. Compteur avec filtres II. Top 10 III. Utilisateurs actifs
5. Conclusion
Utilisateurs actifs
56
Utilisateurs actifs
Nombre d’utilisateurs uniques qui interagissent avec notre système
sur une période donnée (arbitraire)
57
Utilisateurs actifs
58
Exemple: Nombre de vues
Utilisateurs actifs
59
Utilisateurs actifs
+ Écrire : Simple update - Lire : SELECT count(*) WHERE day=”16-06-2015”
60
CREATE TABLE active_users( day text, user_id text, nb_of_watch counter, PRIMARY KEY ((day), user_id)
# partition clustering column
1ère Approche: Table de compteurs
Utilisateurs actifs
61
Utilisateurs actifs
+ Écrire : Simple update - Lire : SELECT count(*) WHERE month=”06-2015”
62
1ère Approche: Table de compteurs
CREATE TABLE active_users_by_week( day text, user_id text, nb_of_watch counter, PRIMARY KEY ((week), user_id)
CREATE TABLE active_users_by_month( day text, user_id text, nb_of_watch counter, PRIMARY KEY ((month), user_id)
Utilisateurs actifs
+ Lecture instantanée - Batchs (précalculs) - Pas de période aléatoire
63
2ème Approche: Mettre les count en cache
CREATE TABLE active_users_by_day_cache( day text, users bigint, PRIMARY KEY (day)
# partition
Utilisateurs actifs
+ Période quelconque - Lent
64
3ème Approche: Utiliser des Sets
CREATE TABLE active_users_with_set( day text, user_ids set<text>, PRIMARY KEY (day)
# partition
Utilisateurs actifs
65
3ème Approche: Utiliser des Sets
Utilisateurs actifs
66
Utilisateurs actifs
67
Utilisateurs actifs
http://fr.slideshare.net/doanduyhai/distributed-algorithms-for-big-data-geecon
Approche Espace requis Cardinalité Marge d’erreur
Set 10M 67 801 0%
HyperLogLog 512 octets 70 002 3%
68
4ème Approche: HyperLogLog : cardinalité estimée d’éléments uniques
Utilisateurs actifs
69
4ème Approche: HyperLogLog
Utilisateurs actifs
70
4ème Approche: HyperLogLog
CREATE TABLE active_users_with_hll( day text, hll blob, PRIMARY KEY (day)
hll-jour-1 ⋃ hll-jour-2 = hll sur deux jours
https://github.com/aggregateknowledge/java-hll
Utilisateurs actifs
71
4ème Approche: HyperLogLog
Approche Cardinalité Temps de réponse
Set 1 666 883 7 s
HyperLogLog 1 712 563 25 ms
× 28
Marge d’erreur : 2.7%
Utilisateurs actifs
72
Plan 1. Spideo 2. Analytics 3. Pourquoi Cassandra ? 4. Etude de cas
I. Compteur avec filtres II. Top 10 III. Utilisateurs actifs
5. Conclusion
Conclusion - Quelques chiffres
● ~ 1 350 000 écriture / 24 h / client ● ~ 20 log / s / client ● objectif 2000 log / s (demande d’un client) ● Au démarrage :
o 1 cluster : 3 machine à 160 go o temps de réponse maxi 2s pour un an
74
Conclusion
● Écrire les requêtes avant de concevoir le modèle. ● Se permettre de répliquer les données. ● Ne pas hésiter à chercher dans la littérature.
75
Conclusion
Questions ?
Remarques ?
Recommandations ?
76
damak@spideo.tv monchy@spideo.tv zarkik@spideo.tv / @AFCRanda