Cette semaine, Criteo organisait sa Not Another Big Data Conference. Si l’accent était mis sur les ateliers, une matinée était réservée aux sessions générales et les interventions se sont succédées à un rythme élevé la 2e journée.

Pour nous réveiller, Guillaume Bort a parlé « Making Criteo Functional ». Comme ça, on se demande : ah ouais c’est quoi ? Scala a été le thème principal. Au départ de Criteo, les technologies étaient .Net, SQL Server, mais après quelques années, Hadoop, Java se sont imposés. Rapidement, les langages fonctionnels ont été considérés et particulièrement Scala. Ce langage fonctionnel s’est imposé chez Twitter. La plateforme avait besoin d’une forte montée en charge et de disponibilité. À cela se rajoutent les problèmes liés aux Big Data, vu la quantité de données traitées. Scala c’est imposé. Mais Scala ne s’invente pas : il faut des outils, du monitoring. Aujourd’hui, il existe de nombreuses librairies pour Scala : Doobie, Cats, FS2. Elles permettent d’étendre Scala et surtout de faciliter son intégration son SI. Doobie permet l’accès aux données.  FS2 fait du streaming I/O. Pour la partie outil, les développeurs Criteo utilisent IntelliJ qui supporte parfaitement Java et Scala, mais ce support ne va pas sans problème parfois… Il a fallu un temps d’adapter. Pour la partie Big Data, Spark est compatible avec le langage. 

Mais comme Criteo a une forte culture Java, pourquoi ne pas fusionner Java et Scala ? L’opération a donné ScaVa, en s’appuyant sur la pile technologie Scala de Twitter avec les mêmes piles pour les données (Finagle, Scalding, Algebird).

Passer les développeurs d’un langage impératif à un langage fonctionnel n’est pas toujours évident. Au départ, il a fallu avoir un hybride entre les deux modèles puis de passer au modèle fonctionnel. Et l’éditeur a commencé à attirer les développeurs fonctionnels et notamment avec des profils très différents (OCaml, F#, Haskell). Ces compétences, que Criteo n’avait pas, ont permis d’étoffer les bonnes pratiques internes. 

Il faut oublier les mauvaises pratiques et les anciens patterns. Ce qui n’est pas forcément évident.  

Plusieurs outils ont été développés pour compléter l’outillage Scala tel que Cuttle, un scheduler pour Scala ou encore Slab pour créer des tableaux de bord de monitoring. 

On enchaîne avec Justin Coffey « From Just a Bunch of Engineers to Data Reliability. L’ingénierie de données est cruciale pour Criteo et il faut des experts. Un des problèmes est de savoir comment monter en charge et étendre les clusters. Le data engineering est une discipline à part entière, tout comme le data reliability engineering (DRE). Chez Criteo, le DRE est apparu avec les problèmes de BI lorsque Hadoop a commencé à s’imposer, mais il manquait parfois d’outils et de bonnes pratiques. Et il fallait gérer les actifs en production et assurer la transition vers Hadoop. Ce qui n’allait pas sans difficulté avec la croissance de la charge et que les premières casses infrastructures sont apparues. Il fallait fixer en attendre la casse suivante. Avec une infrastructure aussi énorme de Criteo, il fallait comprendre comment aller au-delà des limites des outils. Le fonctionnel a aidé à le faire avec les notions de l’idempotente, la gestion du changement des données, la capacité à rejouer les données et les scénarios liés. Il a fallu pour ça maîtriser MapReduce, Spark, le stockage par colonne, les architectures SGBD, les systèmes distribués. Cette ingénierie a permis de résoudre les charges de données. Avec toujours en ligne de mire : la scalabité, la garantie de la disponibilité, le tout en incluant de la data visualisation. Le rôle de SRE (Site Reliability Engineering) prend tout son sens avec l’expertise du code, l’automatisation des déploiements et l’opérationel des serveurs. 

La session promettait beaucoup avec son titre “Lies, Damn Lies and benchmarks”. Hakan Jakobsson évoque les problématiques de performances et comment les mesures concrètement. Il faut donc parler de benchmark, mais dans le monde de la donnée rien n’est simple comme il va nous le rappeler. Aujourd’hui, une référence dans le monde serveur et des données est le TPC et les multiples déclinaisons telles que les TPC-H et TPC DS. Car finalement, comment comparer et mesurer Hortonworks et Cloudera ou Hive et Impala ? Quel rôle du benchmarking ?

“Nous jurons que nous avons fait de mieux pour être juste avec notre concurrent” ou encore “notre solution a toujours l’avantage dans l’expertise des performances”. Vous l’aurez compris, le benchmark en données est un sujet sensible et durant 30 minutes, on prend conscience du problème depuis la fin des années 1970… 

Ainsi, on apprend, si vous ne le savez pas déjà, qu’il existe des clauses non divulgations de benchmarks sans autorisation de l’éditeur, ni de citer explicitement le nom des SGBD dans des travaux universitaires. C’est la clause DeWitt du contrat d’utilisation. Oracle va réagir un benchmarking qui n’est pas à l’avantage de leur base, c’est le début de cette fameuse clause. 

Le TPC va alors tenter d’établir des règles pour faire un benchmarking capable de comparer les SGBD. L’industrie y est très impliquée depuis son apparition fin des années 1980. Cette présence n’est pas sans influence sur les protocoles de tests et les critiques seront régulières sur les capacités réelles des tests à aller loin dans le stress des systèmes. 

Le conseil : créer son propre benchmarking quand c’est possible.

On termine les sessions plénières avec Matthieu Blumberg qui évoque “The concrete reality of the cloud”. Comme évoqué plus haut, au départ, Criteo utilisait des centaines de serveurs SQL Server, de la BI sur SQL Server, mais rapidement les limites des bases ont commencé à se faire sentir. Puis, Hadoop est arrivé. Un premier POC fut monté avant de généraliser. En 2011, Criteo avait environ 1000 serveurs, aujourd’hui, on dépasse les 25 000 ! Et il fallait supporter les fortes latences, une disponibilité délicate et le coût des infrastructures. 

En 2015, il y avait -3000 serveurs Hadoop, fin 2017, on est à 15 000 pour plus de +1 exaoctets de données à gérer, stocker, analyser. 

L’infrastructure est au cœur de Critéo. Aujourd’hui plusieurs datacenters dédiés sont déployés dans le monde et d’autres vont suivre. Le cluster doit fonctionner 24/7 avec la plus faible latence réseau possible. Le déploiement généralisé de Hadoop a obligé à redésigner une grande partie de l’infrastructure sur les nœuds, le réseau, l’énergie. Il faut penser le câblage des datacenters, utiliser au mieux les espaces.

Pour faciliter le travail, une véritable datacenter factory a été créée pour automatiser tout ce qui est possible avec les ingénieurs, les responsables de l’exploitation et les outils comme Ansible. 

Autre aspect parfois méconnu, le capacity planning, bref la planification. Prévoir les charges et les décharges est un élément important pour éviter tout stress inutile aux datacenters. Il faut pouvoir prévoir la saisonnalité, adopter les capacités disponibles, gérer les maintenances, etc. L’analyse du trafic est en temps réel avec x points d’accès, des datacenters partout dans le monde. L’improvisation n’a pas sa place. 

François Tonic