Concevez des architectures Big Data

Le deuxième composant de notre architecture Big Data est nommé serving layer : c'est le composant qui va être en charge de stocker et d'exposer aux utilisateurs les résultats des analyses par lot réalisées dans la batch layer. En fait, il s'agit d'un composant assez simple : la serving layer agit comme une base de données dans laquelle on va stocker des informations, et ces informations vont pouvoir être lues par les utilisateurs lorsqu'ils vont réaliser des requêtes.

Les contraintes de la serving layer

Reprenons notre exemple habituel qui consiste à compter le nombre de visites de notre site, et complexifions-le un peu : nous désirons maintenant obtenir le nombre de visite par page et par heure. (Cette difficulté supplémentaire est faite pour bien comprendre les enjeux de passage à l'échelle, mais ne change pas fondamentalement notre problème)

La batch layer va calculer des statistiques horaires pour chaque page et les insérer dans notre serving layer. Les données de notre serving layer auront donc la forme :

20171201-00:00:00   http://www.plonk.com/index.html       323
20171201-00:01:00   http://www.plonk.com/index.html       244
20171201-00:02:00   http://www.plonk.com/index.html       458
20171201-00:03:00   http://www.plonk.com/index.html       242
20171201-00:00:00   http://www.plonk.com/about.html       12
20171201-00:01:00   http://www.plonk.com/about.html       63
20171201-00:02:00   http://www.plonk.com/about.html       52
20171201-00:03:00   http://www.plonk.com/about.html       98
20171201-00:00:00   http://blog.plonk.com/article.html    546
20171201-00:01:00   http://blog.plonk.com/article.html    846
20171201-00:02:00   http://blog.plonk.com/article.html    961
20171201-00:03:00   http://blog.plonk.com/article.html    1024

On peut logiquement s'attendre à ce que les utilisateurs cherchent alors à récupérer le nombre de visites pour chaque url sur une plage de temps donnée. Par ailleurs, les utilisateurs voudront également récupérer les 100 pages les plus fréquentes à n'importe quelle heure.

À partir de cet exemple, énumérons les contraintes que devra respecter la serving layer :

• Écriture par lot : la serving layer va recevoir des nouvelles données à chaque fois qu'une analyse par lot aura été faite dans la batch layer. Ces écritures vont donc se faire également par lot.

• Lecture aléatoire : les clients qui vont réaliser des requêtes vont récupérer des données concernant n'importe quelle url, dans n'importe quelle période de temps. Il faut donc que la serving layer supporte des lectures en accès aléatoire. Ceci implique de créer des index sur les données pour avoir des temps de réponse faibles.

On note que la serving layer n'aura pas à supporter les écritures aléatoires : c'est une excellente nouvelle, parce qu'une grande partie de la complexité des bases de données que nous connaissons, relationnelles ou non, provient de la nécessité de réaliser des écritures aléatoires. Dans son livre qui introduit la notion d'architecture Lambda, Nathan Marz propose d'utiliser ElephantDB, une base de données très simple (et donc, on l'espère, performante) qu'il a créée lui-même. Cependant, ElephantDB n'a jamais vraiment été une solution très populaire, et sa documentation est franchement lacunaire. Alors quelle solution technique choisir pour implémenter la serving layer ?

Solution technique

Je vous recommande d'utiliser n'importe quelle solution NoSQL à laquelle vous êtes habitués et qui répond aux contraintes énoncées ci-dessus. Il y a fort à parier que vous n'aurez pas besoin de la plupart des fonctionnalités offertes par cette solution, mais au moins vous utiliserez un outil pour lequel vous n'aurez pas à vous former. Et si vous ne connaissez pas déjà une solution NoSQL qui pourrait faire l'affaire, vous pouvez vous former à une solution suffisamment générique que vous pourrez réutiliser par la suite. Par exemple, Cassandra, MongoDb et ElasticSearch sont de bons candidats. En plus, ces deux derniers sont couverts en détails dans le cours Maîtrisez les bases de données NoSQL ;-)

Conclusion

Avec la combinaison de la batch layer et de la serving layer, on est tentés de penser qu'on dispose déjà d'une architecture big data complète. Effectivement, dans les situations où on n'a pas besoin d'analyser les données les plus récentes, ces deux composants se suffisent à eux-même. Mais dans le cas général, cette architecture à deux composants a une faille : elle ne permet pas d'analyser les données récoltées pendant l'analyse par lot dans la batch layer. Pour répondre à cette contrainte, il faut s'intéresser à la speed layer...

Vous souhaitez professionnaliser vos compétences ? Jetez un oeil sur les formations big datas proposées par OpenClassrooms : architecture big data