Spideo creates TV and movie recommendation engines to enable content discovery. It also provides data and analytics to optimize marketing strategy for our customers. Our engines handle millions of requests per day. We want to offer deeper insight on how users interact with content and personalized recommendation. We will present why and how we are using Cassandra for: * Real time analytics * Filtering data * Computation of cardinality

1. 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

2. Plan
1. Spideo
2. Analytics
3. Pourquoi Cassandra ?
4. Etude de cas
I. Compteur avec filtres
II. Top 10
III. Utilisateurs actifs
5. Conclusion

3. 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. 4
Qu’allez vous regarder ce soir ?
75%
d’indécis
devant
leur
TV

5. Rendez-moi mon vendeur du vidéoclub !

6. Service de recommandation “content centric”
Toujours expliquer la recommandation pour créer un lien
de confiance avec les utilisateurs

7. Les Avantages des algorithmes de Spideo :
- Temps réels
- Scalables
- Explicables
- A fait ses preuves
Algorithmes de recommandation innovants
Mood-Based
Discovery
Related ContentProfile-Based
Suggestions
Semantic Search

8. Quelques clients actuels de nos solutions

9. Plan
1. Spideo
2. Analytics
3. Pourquoi Cassandra ?
4. Etude de cas
I. Compteur avec filtres
II. Top 10
III. Utilisateurs actifs
5. Conclusion

10. Content and
User Metrics
Business Rules User
Segmentation
Des analytics...
...pour aider nos clients à bien analyser et mieux monétiser
leurs services

11. 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. 12
Il était une fois … analytics

13. 13

14. 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

15. Base de données distribuée
15

16. Oui mais laquelle ?
16

17. 17

18. 18

19. 19
Mature
Intuitive
Flexible
Performante
Distribuée
“ Hype ”

20. 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. 21

22. 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

23. Le CAP
23sources: Cassandra: the Definitive Guide.

24. Les cerises sur le gâteau
24

25. Timeseries
25

26. Counter
26

27. Le vote
27

28. And the winner is ...
28

29. 29

30. 30

31. Concrètement, comment ça marche?
31

32. Plan
1. Spideo
2. Analytics
3. Pourquoi Cassandra ?
4. Etude de cas
I. Compteur avec filtres
II. Top 10
III. Utilisateurs actifs
5. Conclusion

33. Rappel dashboard
33

34. Compteurs avec filtres
34
[Mood]
[Theme]
[Format]

35. Envies (moods)
35

36. Thèmes
36
Quelques thèmes

37. Format
37

38. Définition du use case
38
Nombre de vues sur les films
qui correspondent à l’envie rire,
et au thème « en voyage »

39. La requête d’abord
39

40. Si on normalise :
=> Problème : toute la table sera remontée en RAM pour faire le count
40

41. 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

42. Dans cette modélisation, on aura autant
de partitions que de combinaison
possibles de
(mood, theme, format)
42

43. Cardinalité pour un contenu
43
(mood, theme, format)
1 + 3 1 + 8 1 + 1
= 4 x 9 x 2 = 72

44. Cardinalité totale
44
(mood, theme, format)
1 + 23 1 + 749 1 + 12
= 24 x 750 x 13 = 234 000

45. Un watch de film Rire et En voyage
=> On écrit 8 fois ( 2 * 2 * 2)
45
mood

46. Avantage :
Temps de réponse instantané
Inconvénient :
Nombre d’écriture important
46

47. Plan
1. Spideo
2. Analytics
3. Pourquoi Cassandra ?
4. Etude de cas
I. Compteur avec filtres
II. Top 10
III. Utilisateurs actifs
5. Conclusion

48. Classement Top 10
Exemple: Top 10 des contenus les plus regardés
48

49. Classement Top 10
49

50. 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

51. 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:

52. 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:

53. 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.

54. 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

55. Plan
1. Spideo
2. Analytics
3. Pourquoi Cassandra ?
4. Etude de cas
I. Compteur avec filtres
II. Top 10
III. Utilisateurs actifs
5. Conclusion

56. Utilisateurs actifs
56

57. Utilisateurs actifs
Nombre d’utilisateurs uniques qui
interagissent avec notre système
sur une période donnée
(arbitraire)
57

58. Utilisateurs actifs
58
Exemple: Nombre de vues

59. Utilisateurs actifs
59

60. 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

61. Utilisateurs actifs
61

62. 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)

63. 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

64. 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

65. Utilisateurs actifs
65
3ème Approche: Utiliser des Sets

66. Utilisateurs actifs
66

67. Utilisateurs actifs
67

68. 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

69. Utilisateurs actifs
69
4ème Approche:
HyperLogLog

70. 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

71. 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%

72. Utilisateurs actifs
72

73. Plan
1. Spideo
2. Analytics
3. Pourquoi Cassandra ?
4. Etude de cas
I. Compteur avec filtres
II. Top 10
III. Utilisateurs actifs
5. Conclusion

74. 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

75. 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

76. Conclusion
Questions ?
Remarques ?
Recommandations ?
76
damak@spideo.tv
monchy@spideo.tv
zarkik@spideo.tv / @AFCRanda