Big Data Analytics : Open-Source & Cost optimisation

0:19 Alors bonsoir à tous. Ce soir on n'est pas extrêmement nombreux mais c'est pas grave, profitons-en pour créer un échange interactif. Je vous propose, et Alexandre pourra vous en parler un peu plus, mais de poser vos questions au fil du meet-up. On peut créer vraiment un moment sympa. Et les speakers reprendront vos questions dans leur boîte, sinon je ne vous entendrai pas sur le replay, tout simplement. Donc moi je suis Noémie, je suis directrice de Tech.Rocks et je suis ravie d'être avec vous ce soir. Rapide rappel pour ceux qui ne nous connaissent pas très bien encore. Donc nous on est une communauté, une communauté de CTO. On a 2800 personnes aujourd'hui avec nous. Donc pas ce soir avec nous hélas, mais sur un Slack où on interagit. Vous pouvez trouver toutes nos informations sur notre site. On a mis justement les événements, les contenus qu'on fait, podcasts, études, livres blancs, etc. Donc on organise des événements, on a des événements hebdomadaires en présentiel et en virtuel. Et on a notre gros événement, notre grand messe, qui est le Tech Rock Summit, qui aura lieu les 7 et 8 décembre prochains. Je vous parlais du contenu, donc des articles également, avec le podcast. On a également des initiatives qui sont portées par des membres de la communauté.

1:21 Une newsletter du mensuel, avec de la curation de contenu. On a un book club où on vient parler, comme son nom l'indique, de livres. On échange sur un chapitre par semaine. Un vidéoclub qu'on tarde un petit peu à lancer, mais qui sera effectif dès la rentrée prochaine, dès septembre prochain. Et évidemment, des initiatives, notamment Women in Tech Rocks, qui est une initiative qui nous tient à cœur. On propose du mentorat, de la formation. Il y a beaucoup de choses, donc je passe assez vite. Et puis n'hésitez pas à venir me voir à la fin si vous souhaitez plus d'informations. Et comme je vous le disais, le Tech.Rocks Summit, qui est notre grand moment de l'année, 7 et 8 décembre 2023. Vous pouvez noter dans vos agendas et vos portables justement la date. Et l'idée, c'est que la billetterie est ouverte. On l'a ouverte avec des tarifs préférentiels jusqu'à... Voilà nos speakers du Semitode. Donc on les diffuse au fur et à mesure. Et donc on a commencé avec les premières personnes qu'on aura à nos côtés. Donc on est ravis et le programme justement s'étoffe au fur et à mesure des mois. Voilà, je vais vous en parler rapidement.

2:24 On a lancé une formation en collaboration avec Pierre Fournier. Je ne sais pas si vous le connaissez un peu, c'est l'ex-CPO de Manomanon, qui a lui monté son académie, qui proposait une formation, et donc on a décidé de collaborer tout simplement sur une formation pour devenir manager coach. On fait des sessions de test gratuites, sans engagement. Si ça vous intéresse, n'hésitez pas, il y a un formulaire sur le site directement. Voilà, je passe très vite, on a un prochain événement le 6 juillet autour du Pinops. Et ce soir, sans plus attendre, on aura donc Natalia, Pierre et Alexandre qui viendront nous parler. de Big Data Analytics. Voilà, je laisse l'animation de ce meet-up à Alexandre et n'hésitez pas à poser vos questions. Merci beaucoup! Bon déjà d'une, merci beaucoup de m'avoir invité à participer au meet-up et à l'animer. Je serai dans le dossier de la responsabilité. Merci aussi à Nathalie et à Pierre d'avoir accepté de jouer le jeu et qu'on puisse rentrer dans ces témoignages. Donc on l'a dit, on va parler de... Principalement de data, on l'aura compris, de big data sur des cas d'usage analytique, et on va essayer de coupler la notion de réduction de coût en cumulant de l'open source et du cloud computing.

3:35 Avant de commencer tout ça, on va faire un petit tour pour se présenter. Je te laisse démarrer pour te présenter. Oui, ça marche. Dans le carré. Dans le carré, oui. Ah oui, c'est le carré. Bonjour à tous. Donc, je suis Natalia. Je suis CEO de DoubleCloud. DoubleCloud, c'est une startup qui a été lancée il y a un an. C'est une plateforme sur laquelle vous pouvez construire des data analytics avec les technologies open source managées. Non, ça ne marche pas. On a l'impression que ça ne marche pas du tout. Est-ce que maintenant c'est mieux? Oui, c'est parfait. Alors, ce qui m'intéresse toujours, je communique énormément avec les CTO différents, ce qui m'intéresse toujours, c'est voir comment le monde change. On vient de discuter avec toi, Alexandre, qu'il n'y a que 10 ans, en 2011, 2012, 2013, J'ai participé beaucoup dans les événements quand on a parlé, est-ce que l'événement de Big Data va devenir notre réalité ?

4:37 Et là maintenant on discute tous en disant, bon, ces outils ça ne marche pas, il faut changer, Radoup, on oublie déjà, qu'est-ce qu'il y a qui utilise Radoup toujours, etc. Donc le monde est changé, c'est très intéressant, donc je suis très ravie de participer dans ça. Et à part de cela, mon métier principal, ce n'est pas le métier tech, mais c'est gérer les business. Et c'est vrai que... chose marche donc je vais donner ma vision aujourd'hui de ça. Je pense que ça tombe. Je peux en finir si tu veux, et après, vas-y, vas-y, et prétends que tu es un petit matelot. Moi, comme je l'ai dit, c'est Alexandre. Moi, je suis rentré dans le monde de la data depuis le début. C'est le début que j'ai commencé à travailler à l'origine. Je travaillais chez des grands groupes qui étaient liés à l'énergie. Là, je suis dans une entreprise qui s'appelle QuickSign, qui est une grosse entreprise qui est dans de la fintech et de l'insurtech, et qui a pour but de faciliter l'onboarding digital dans l'ouverture de comptes en ligne, ou de crédit à la consommation.

5:42 Donc en gros, vous vous connectez chez 1%MA, chez Fortuneo, etc. Vous avez tout un parcours qui va vérifier votre identité, vous allez devoir saisir des documents, tout ça c'est analysé automatiquement, il y a des contrôles qui vont être opérés. Et vous avez des systèmes pour piloter tout ça, c'est-à-dire qui est bloqué à quel endroit, comment on peut optimiser telle et telle chose. Donc là actuellement, ça fait pas longtemps que j'y suis, j'y suis depuis janvier, quelque chose comme ça. Je m'occupe de l'équipe Data qui a pour but à la fois de créer des services avec de l'intelligence artificielle pour scanner les documents, pour les décomposer. Il y a aussi une équipe qui est plus portée sur l'analytics, qui fait du reporting financier. On a un mode de facturation qui est à la consommation avec plein plein de règles. Ce qui fait qu'il y a besoin d'avoir une vraie stack là-dessus et toute une stack BI. Pour faire de la mesure de performance. de performance de la plateforme, à quel point est-ce que si on inverse, je pose un document versus je le scanne avec mon téléphone, qu'est-ce que ça change ? Vraiment des problématiques de funnel, de ce côté on passe d'une étape à une autre. Et juste avant ça, j'étais chez Neymar, une startup qui est dans de la green tech, donc encore un autre sujet, qui fait un SaaS et des données mais avec une très très forte composante de données.

6:51 Voilà dans les premiers. Pierre, je te laisse la parole. Donne-moi le carré alors. Bon, et bien bonsoir. Allez, je vais vous donner 30 secondes sur Botify, 30 secondes sur moi. Ça va aller assez vite. Botify a un métier, c'est rendre les sites web découvrables par les moteurs d'indexation. Ça a l'air un peu bête, mais aujourd'hui, un gros site, ça a une trentaine de millions de pages, et Google lâche l'affaire au bout d'une dizaine. Donc comment on fait pour l'aider? C'est un vrai problème pour les gens qui gagnent de l'argent avec ce site-là. Voilà, donc il y a pas mal de big data, on verra des chiffres tout à l'heure quand on parlera, on est 80 pour faire marcher tout ça entre le produit et l'ingénierie. La boîte est plus grosse, mais notre cœur d'activité c'est ça. Et on a plein d'expériences liées à l'échelle. Donc je vais vous raconter des choses qu'on a vécues, je vais vous raconter des technologies qu'on a enterrées, parce qu'elles ne marchaient plus à partir d'un certain seuil de complexité. Et moi, je suis CTO.

7:52 Avant ça, j'ai fait un peu de Microsoft en vendant du cloud. Et puis après, j'ai fait un peu de publicité. chez Criteo, puis après j'ai fait un peu de crypto chez Ledger, puis maintenant je suis là depuis début 2020. Et voilà, voilà pour ma minute, je te rends la parole. Merci Pierre. Alors pour commencer, ce que je vous propose c'est qu'on va parler d'un sujet, donc une comparaison de technologie, on va parler de BigQuery et de ClickHouse. L'idée c'est de mettre en rapprochement ces deux technos, de voir qu'est-ce que c'est déjà ces technos, quelles sont les différences qui existent et quel est le retour d'expérience qu'on peut avoir à partir de ces technos. Tout à l'heure, c'était des choses que tu as pas mal utilisées. Est-ce que tu pourrais nous en dire un peu plus sur ce que c'est et toutes ces distinctions? Oui. Déjà, je sais qu'il y a des gens qui vont le regarder en replay, qui est complètement familier avec, en gros, le fait d'avoir une database en anticolonne. Ça va aller assez vite. Je vois Thomas, notre ex-CTO et maintenant patron de l'innovation, qui s'évagmente de quoi il s'agit.

8:57 Je lui ai piqué des slides, comme après. On y va. Le problème classique d'une base de données, c'est que ça passe son temps à lire des lignes. Et du coup, quand on veut aller chercher quelque chose dans un grand paquet de lignes, il faut se taper un grand paquet de lectures. Et le coût par lecture, c'est le coût de la ligne. Et donc ça bloque tout de suite la mise à l'échelle. ClickHouse et BigQuery ont une approche légèrement différente et en fait ils ne lisent pas des lignes, ils lisent des colonnes. Et du coup ils n'ont pas à se fader l'intégralité des lignes pour aller découvrir ce qui vous intéresse. Ils ne travaillent que sur les colonnes. que vous recherchez, et ils font des choses intelligentes par colonne et pas par ligne. On va commencer par Bikuri. Bikuri, ça a été fait... Sous verre, sous cloche, c'est conçu pour fonctionner dans le data center de Google et donc on se permet des choses que personne ne peut se permettre. Un exemple très intéressant de BigQuery, c'est que le compute c'est gratuit du point de vue de Google, rajouter une machine ou mille machines c'est pareil, le data center est assez gros pour se le permettre.

10:00 Et la donnée, elle est toujours très très proche, parce que là aussi, il y a des capacités de stockage colossales. Donc ce que fait Google d'astucieux, c'est de dire, tu as ton stockage d'un côté, tu as ton requêtage de l'autre, je te bile séparément pour les deux, et je mets entre les deux un système ultra efficace pour pouvoir scanner en parallèle autant qu'on veut de zones de stockage de données, avec autant d'unités d'exécution que je veux, et un réseau prodigieusement rapide entre les deux. En fait, les gens qui disent serverless aujourd'hui, donc cette capacité d'usage illimité, c'est BigQuery, c'est ça, c'est une database serverless, c'est exactement comme ça que ça fonctionne. Et ça donne une qualité extraordinaire qui est, quel que soit le volume de données qu'on veut requêter, ça répond en temps pas constant mais pas loin, c'est extrêmement rapide. Plus la requête est grosse, plus ça lance de bécane sur les datas et le temps est compressé. Même s'il y a 2 millions de secondes d'exécution, en fait on n'en voit que 2000 parce qu'il y a 1000 bécanes qui font d'autres.

11:03 Il n'a pas été conçu spécifiquement pour la performance, il a été conçu pour la scalabilité. Il est capable d'encaisser et il sera lent sur les petites requêtes, mais ce n'est pas grave. Maintenant, on va traverser, on va aller voir le chaos. Donc, en tout cas, c'est un moteur qui a été conçu pour des besoins de performance au début, par une petite équipe cachée chez Yandex, qui a sorti progressivement. Et au départ, c'était un système qui avait un point commun et une grande différence avec Vécu. Le point commun, c'est la même façon de conceptualiser le stockage de la donnée et de le requêter. Mais la grosse différence, c'était qu'on collait ensemble le stockage, le compute, et on optimisait autant qu'on pouvait. Typiquement, la nature du disque qu'on a, ça compte énormément aujourd'hui dans la performance qu'on va retrouver, c'est ClickHouse. Ça s'est progressivement élargi, mais donc on avait au départ deux modèles très différents. Un qui est open source, qu'on peut embarquer là où on veut, on peut le hoster chez soi, ça tombe en marche de tous les côtés, mais la scalabilité dépend du nombre de bécanes qu'on veut bien y mettre, et puis du coup tu fais un tout entre la somme des storages, la somme des CPU, et il faut trouver le bon mix de tout ça.

12:07 Et de l'autre côté, un système qui était nettement moins réactif, mais qui n'avait pas de limite de scalabilité concrète du point de vue de l'utilisateur. Donc voilà un peu la façon d'opposer les deux. La même idée derrière, mais deux réalisations complètement différentes. Une qu'on met n'importe où et qui est très rapide, mais la scalabilité c'est pour toi. Donc il faut vraiment choisir comment tu provisionnes ton système. Et l'autre qui est, c'est jamais chez toi, mais t'as pas de problème. pas de problème de scalabilité. Ça te va? Oui, c'est super clair. Et comment tu as géré cette transition entre les deux? C'est de l'un à l'autre. Plan slide. C'est promis. Justement, il y a plusieurs façons de faire ça. Donc en teaser, Comets ne se comporte pas de la même façon, on ne peut pas leur faire faire les mêmes choses exactement. Et du coup, on a deux chemins distincts de transition dont on parlera tout à l'heure. Toi de ton côté, Natalia, sur la distinction entre les deux, et notamment particulièrement sur Kika aussi.

13:13 Je pense que Pierre a dit de la meilleure façon possible la distinction entre les deux. Moi, personnellement, j'ai réjoui en DoubleCloud parce qu'il y avait la promesse de ClickHouse. Donc, on a plusieurs technologies open source, dont ClickHouse, on a Kafka, qui est moins cher de marché d'ailleurs. Donc, on a Airflow, on va ajouter bientôt Trino, etc. Donc, il y a plusieurs technologies qui permettent de construire le data analytics. Mais ClickHouse, pour moi, c'était la grande promesse. Pourquoi? Donc, pareil, j'étais chez Microsoft, après j'ai passé chez Databricks, après j'étais chez Splunk, mais pas côté sécurité, mais côté observabilité, monitoring, ce côté de data stack opérationnel. Et en fait, j'ai vu partout la même problématique. Et la problématique, c'est... Ok, on utilise quelque chose qui est très bien, mais ça coûte soit trop cher, soit le prix ça va, mais c'est lent, et en fait les besoins changent dans les sociétés. Et quand j'ai rencontré la base de données de ClickHouse, quand j'ai entendu des bonnes news qu'ils ont parlé, un micro-pé aussi, genre Uber qui est élastique et qui déménage vers ClickHouse, ou

14:26 Cloudflare qui l'utilise aussi pour leur histoire de CDN, etc. Je me suis dit, ok, il y a une promesse, mais pourquoi cette promesse? Parce que le monde change et en fait, on a besoin aujourd'hui de plus d'analytics en temps réel. Donc, la structure de base de données peut-être doit changer et les approches aussi peut-être doivent changer. Et donc, comme Pierre a dit, le BQA était pour les besoins un peu avant. Le monde change, les besoins sont différents, donc les chaos proposent plus les solutions pour un autre use case, mais aussi... peut-être les besoins qui sont actuels aujourd'hui ou dans les prochaines 3-4 ans. Merci à toi. Moi, de mon côté, alors ClickHouse, je ne vais pas trop en parler, parce que finalement, je le connais, mais je ne l'ai jamais vraiment utilisé. BigQuery, je l'ai un peu plus utilisé dans mon expérience précédente, pour des questions de perf de calcul, mais qui fonctionnaient plutôt sur des gros batchs, que sur du temps réel, comme tu viens de le décrire. En gros, par le passé, je manipulais pas mal de données géolocalisées, en faisant des traitements assez lourds.

15:30 La techno qui est top là-dessus, c'est du post-grès, parce qu'il y a une extension qui est post-gris et qui fonctionne super bien là-dessus. Par contre, elle n'est pas du tout extensible, je pense que tu reviendras dessus, mais elle n'est pas du tout extensible à l'infini quand on a des grosses problématiques d'analytics. Mais bon, tout ce qui est fonctionnalité géospatiale, tout ce qui est utilisation de fonctions, ça fonctionne super bien, il y a énormément de choses qui existent. Pour contrer ces limites, on était passé à BigQuery qui a un peu de fonctionnalité spatiale, mais finalement pas beaucoup. Par contre, en termes de perte de calcul, ça n'avait absolument rien à voir. Et on pouvait vraiment s'amuser à aller... Au fond, de fonction spatiale, ce n'est pas juste une distance, c'est des formations de géométrie, c'est... C'était sur des problématiques de reconstruction de la structure d'un toit. Donc en fait, il fallait vraiment manipuler toutes ces structures-là, et BigQuery a pas mal aidé là-dessus. Ça c'est le feedback que j'ai eu, mais je garderai en tête cette notion de... En fait, c'est vraiment une question de taille de la base de données. J'ai fait beaucoup d'analytics avec Postgres, ça marche très bien. Big Quarry aussi, mais son coup, tu l'as dit, est particulièrement fort.

16:36 Et ClickUp, ça me semble pas mal, je crois. On va en parler encore plus. Comme on disait, on va parler de tout ce qui est en social. Comment ça marche? Oui, je crois que tu as quelques slides à nous partager. On va parler stratégie data, de comment est-ce que c'est mis en place, de cette techno, d'organisation et compagnie. Alors j'ai fait les slides cet après-midi entre deux meetings, je ne sais plus, on va voir. Bon, on va découvrir ça. On y va. On s'était mis d'accord sur un petit fil conducteur et ensuite je suis parti sur différentes choses. Je passe, on s'est déjà présenté. Cette slide a été volée à une présentation faite par Thomas, qui est donc un des co-founders et qui en 2012 a commencé à regarder BigQuery et qui à cette époque-là apparemment a fait« on va aussi prendre autre chose» et donc on est parti sur Elasticsearch à cette époque-là. Pour moi c'est la préhistoire, je suis arrivé fin 2019. Et du coup, on a déjà un truc intéressant qui est, on a des patterns qui se prêtent pas bien à l'utilisation d'un datastore et du coup on va en regarder un autre.

17:44 Et c'est exactement la démarche dans laquelle on est maintenant. Donc on va retrouver un écho de la slide qui est là. Donc, Elacid Surf, ça a grossi, c'était hosté chez OVH, si je ne dis pas de bêtises. Et ça... Ça a grossi, et puis ça a grossi, et puis ça a grossi. Et puis, on va voir un petit peu. Ça ne marche pas dans l'autre sens? Ah, c'est pas mal. Et donc, ça a grossi jusqu'à mourir de sa belle mort. Donc, Elasticsearch, on s'est rendu compte, vers 2019, qu'on arrivait au bout. En fait, ça fait partie des systèmes qui ne supportent pas d'être trop chardés quand on est un peu bavard quand on les utilise. Et quand on est chez OVH et qu'une machine passe un peu flappy, il faut aller en remonter une, rééquilibrer, etc. L'équipe d'infrastructure aujourd'hui c'est trois personnes pour une boîte de 300 et c'est difficile d'avoir une personne qui passe sa nuit sur un char qui ne marche pas bien. Donc ça a été tué en deux ans, c'était long et douloureux.

18:49 On a fait une cérémonie, on a dégommé à tour de rôle la machine, donc on avait toutes les vécanes du cluster, en picolant du champagne après chaque machine pour célébrer ça. Ça a fait très plaisir, même si ça marche super bien, simplement il y a des patterns qui trouvent leurs limites en termes de taille. On a rajouté plein de petits data stores, on les verra tout à l'heure, quand je raconterai un peu comment ça fonctionne. On a rajouté des façons d'alimenter en data, donc ML Pipelines, destinées aux équipes de Yannal, qui est planqué derrière aussi, et qui fait toute la partie data platform, platform, machine learning, data analytics, data science, tout est là-dedans. Et donc c'était le petit H pour lui. Et il y en a un qui a survécu, au moins jusqu'à l'avant-hier. qui est post-grès. Donc, Guillaume s'est mangé un petit outage sur post-grès avant-hier. On a réussi à le flinguer, finalement. Ça va, il va bien. On l'a redémarré. Mais pour l'instant, c'est la techno qui a le mieux vécu là-dessus parce qu'on l'a cantonné à des points très simples. Voilà, et BigQuery a pris le pas sur tout le reste.

19:52 BigQuery a pris le pas pour des raisons toutes bêtes. C'est, on peut lui donner n'importe quoi à manger, il ne se plaint pas. On a fait quelque chose de malin, on a logiquement partitionné par client. Ce n'est pas vrai, on met tout au même endroit. Mais ça veut dire que si on fait quelque chose de spécifique pour un client, ça n'impacte pas les autres. La façon dont on partitionne nous garantit ça. Et ça nous a donné à la fois plein de liberté et puis un endroit parfaitement unifié pour le requêtage. Et bien quand on fait ça, cette liberté, on y prend vite goût. Et du coup, le système a grandi autour de BigQuery en permanence. Aujourd'hui, on y met des logs, on y met des résultats d'analyse, on y met énormément de choses. Les seules choses qu'on ne met pas, c'est quand elles deviennent tellement grosses que ça coûterait vraiment, vraiment trop cher. Qu'est-ce que ça veut dire tellement grosse? Ça c'est quelques-unes de nos petites données stockées dans BQ. Donc on arrive, la plus grosse dépasse pas un péta et quelques.

20:56 Le gros de données n'est pas là-dedans, il est dans S3. Et donc on est obligé de faire attention. Alors ça a l'air un peu ridicule quand on voit les volumétries qui sont là, mais encore une fois notre métier est très très consommateur en data. Et du coup... Excuse-moi Pierre, je t'interromps un petit peu. Je crois qu'on ne nous entend pas super bien sur la place. Alors, est-ce que tu veux que je parle plus fort? Il faut tous parler plus fort, s'il vous plaît. Alors, je vais essayer de ne pas crier, mais de parler un petit peu plus fort, ça va? Le micro qui marche. Hein? Le micro qui marche, lui aussi. T'as qui de moi? Donc ça, ça illustre très bien. Le côté magique de Bicoin. On n'était pas à ces volumétries-là quand on a commencé à l'utiliser. Et le système nous a accompagnés jusqu'à ces volumétries sans flancher. Ça continue de répondre, ça continue de marcher. Il y a plein d'astuces cachées derrière. Pour l'info, on a baissé tout récemment. Ça, c'est les volumes après réduction. On a commencé à dégager de la donnée qui n'était pas utile. C'est la donnée logique. Sur la donnée physique, c'est beaucoup plus petit. On utilise des systèmes de compression pour nous dans S3.

21:58 Et on sait qu'il y en a aussi chez BQ. Et donc, on a discuté avec Google. Quand on est à cette échelle-là, on peut échanger un peu avec eux sur le meilleur modèle de pricing pour le stockage. Voilà pour notre histoire là-dedans. Tout ça, fondamentalement, c'est un moteur d'analytics très orienté métier. Donc on a deux grosses sources de données qui sont des logs, qui disent quels sont les robots qui sont venus nous voir. Et puis nous, on simule un crawler sur le site web pour comprendre comment il aurait dû se comporter. On a dans ce mix d'autres petits datasets, petits en taille, mais fondamentaux en sémantique. Et puis le mélange de tout ça, ça donne un système d'exploration pour les utilisateurs où on les guide sur tous les côtés du SI. Cette machine compliquée, elle a quelques petits soucis. Tu me dis quand je déborde mon temps parce que je me laisse tranquillement aller. Merci. Le premier souci qu'on a, c'est que le nombre de nos produits augmente, le nombre d'analyses différentes qu'on peut proposer augmente, et le temps...

23:00 L'angle de latence d'une requête, il n'augmente pas, mais il n'était pas très beau au départ. Et donc, pour une app qui se veut très interactive et exploratoire, en fait, on a une app qui est interactive, mais pas super exploratoire, parce qu'au moment où on lance la requête pour de bon, ce n'est pas grand-chose, c'est quelques secondes, mais c'est vraiment quelques secondes. Et du coup, il y a des parties. Donc, on magouille, on fait plein de choses. On est en train de sampler, par exemple, de façon à permettre de la preview instantanée sur les choses qu'on fait. Mais en règle générale, on s'est rendu compte, par exemple, lorsqu'on a des API, c'est un peu pénible d'avoir des API qui sont lentes à répondre parce que la connexion qu'on doit garder ouverte, maintenant, on la garde ouverte aussi longtemps qu'on n'a pas répondu. Et quand on a beaucoup de clients qui viennent appeler, on commence à avoir un pool de connexion qui pète pour pas grand-chose. Il y a plein d'endroits où c'est pénible d'avoir un système qui ne répond pas vite. Et donc un de nos soucis, c'est cette difficulté d'être... Le deuxième souci qui est intéressant, c'est que Bacchus était très facile au début, on payait au nombre d'octets scannés. Donc tu fais ta requête et puis en fonction du volume qui a été balayé pour répondre à ta requête, tu reçois une facture pour temps.

24:07 Et puis il y a des systèmes de réservation, d'optimisation, il y a plein de choses qu'on peut faire dessus. Aujourd'hui le pricing BigQuery est devenu quelque chose sur lequel on peut optimiser, mais c'est beaucoup de temps et ça introduit quelques petites contraintes selon le mode de facturation qu'on choisit. Donc ça c'est un premier élément. Le dernier, c'est BigQuery avait besoin d'avoir son stockage près de lui. Tout à l'heure, j'ai montré les volumes de données. Et en fait, ce n'était pas du tarif S3 ou GCS, c'était du tarif BigQuery. Et le stockage BigQuery coûte plus cher que le stockage traditionnel. Mais nous, on n'avait pas envie de payer deux fois pour nos coûts. Stocker deux fois la donnée, ça coûte très cher. Et on avait envie de pouvoir minimiser le nombre de répliques de données qu'on gardait. On les garde pour des raisons de reliability, mais pas pour simplement... de l'utilisation distincte. Et enfin, ça a l'air tout bête, mais comme il a été conçu autour d'un cloud, il ne tourne que dans ce cloud. Et aujourd'hui, on a des clients qui sont pro-Amazon, anti-Amazon, pro-Google, anti-Google, on a tous ces trucs-là.

25:16 Nous, on a nos problématiques d'optimisation de coûts, où on va regarder par exemple comment sortir d'un cloud pour une fonction commoditisée, où on n'a pas de problème d'évolution de charge. Et quand on cherche à faire tout ça, On paye la bande passante dès qu'on va voir sur un cloud. Et si on n'est pas capable de déplacer son data store à l'endroit où on consomme la data, on paye tous les échanges avec cette data. Voilà ces petits pain points qu'on a expérimentés. Et donc on a décidé d'essayer d'élargir un petit peu. Comment on a fait ça? On a regardé plein d'alternatives. Alors certaines, on a fait des vraies expériences complètes. D'autres, on a juste lu la doc et déduit ça marchait, ça ne marchait pas. D'autres, on les a éliminés pour des qualités qu'ils n'avaient pas. Par exemple, ils étaient aussi collés à un cloud. Et en fait, on a fini par converger sur... Il nous faut un modèle columnar pour être capable de supporter nos volumes de requêtes, parce que même sur des petits volumes, vous avez vu la taille des éléments qu'on manipule, il nous faut un système open source qui soit du coup stable assez facilement à droite à gauche, sans qu'on ait de problème de négociation ou de licence qui en a besoin de grossir ou de déplacer.

26:24 Et il nous faut un système qui soit autant possible compatible avec les grands clouds qu'on trouve autour de nous. Alors c'est quoi une petite... Ça c'est nos... On fait tous nos diagrammes comme ça, on les met sur un mur, et puis après si on a le temps, on fait un beau diagramme qui finit sur papier, mais là celui-là, il est tiré de la page Confluence. Qu'est-ce qu'il faut retenir là-dedans? C'est l'approche qu'on a choisie pour utiliser d'autres data stores. Vous avez là au premier tiers S3, qui est une grande barre sur laquelle tout arrive. En fait, tous nos systèmes de traitement dans Amazon publient leurs résultats dans S3. Et ensuite, on va charger une partie de tout ça dans BQ, qu'on voit là à droite, enfin au milieu, en haut plutôt au milieu, et BigQuery devient l'endroit sur lequel on va tout requêter. Donc il y a encore une fois des choses qui ne vont pas dans BigQuery, mais tout ce qui a une tête requétable se retrouve dans BQ. Notre idée, c'est de dire, on a un référentiel de données assez central, qui est, on peut choisir son point de vue, soit on peut dire c'est des fichiers, c'est du S3, ça pourrait être du parquet par exemple, et puis c'est chargé dans un endroit par exemple qui serait vécu.

27:34 Aujourd'hui, la réalité chez nous, c'est plutôt... Le pivot, c'est Bitcoin. Il se trouve que c'est le reflet de ce qu'on a dans du stockage. Et à terme, je suis sûr qu'on aura un système dans lequel la source de vérité, ce sera le stockage. Et le choix de charger dans BQ, ce sera un choix parmi deux. Sauf qu'aujourd'hui, c'est le pivot. Et ensuite, ce qu'on fait, c'est qu'on projette des datasets pour des usages spécialisés dans d'autres datasets. parce qu'ils sont trop chers pour être embécus, parce qu'il faut qu'on ait du requêtage plus rapide, parce qu'on peut pré-agrégé, etc. Et ce que vous voyez en dessous là qui s'appelle ClickHouse, c'était un de ces premiers systèmes. Et vous voyez l'idée, ça part directement depuis la partie stockage pour filer là-dedans, exactement comme ça aurait filé dans... Dans BigQuery et après la partie en rouge elle est incompréhensible pour les gens qui sont pas chez Botify donc j'expliquerai un peu plus tard. En gros c'est la consommation de tout ça. On a des scénarios spécifiques pour la partie ClickHouse en l'occurrence. Voilà l'idée générale. Si ça vous intéresse, après le tour on parlera plus de ce schéma qui couvre énormément de choses dans ce qu'on fait.

28:42 Maintenant, J'ai parlé de pétaloctère, on va être beaucoup plus concret et on va prendre des petites expérimentations. Donc voilà trois pélotes traditionnels chez nous. Le premier, je vais virer le nom du client, j'ai peut-être oublié sur le dernier, ça arrive. C'est un petit site d'e-commerce. Donc un petit site d'e-commerce, c'est 250 000 URL. Très bien, ça fait quelques gigas. Un site un peu plus important, 30 millions d'URL, on a viré toutes les informations dont on n'avait pas besoin, on garde que le minimum pour pouvoir traiter. Et donc on arrive à quelques centaines de gigas. Un dernier, et bien là on a atteint le teraoctet sur ce qu'on est censé manipuler et requêter. Je parle des tailles de requêtage analytics, pas du tout des tailles d'onologues ou de quoi que ce soit. C'est vraiment la donnée finalisée, réduite, qu'on va vouloir manipuler. C'est rassurant parce que ce n'est pas gros, en fait, comparé au PETA dont je parlais tout à l'heure.

29:50 C'est des gros volumes, mais c'est des volumes qui sont absorbables par des systèmes qui sont server-based. Ça se trouve très bien aujourd'hui. Une bête disque, ça fait 20 teras. On n'est pas paumé quand on est en face de ça. Et donc l'exploration de Data Store non cloudifiée by design, c'était tout à fait envisageable. On peut même en trouver caché là, dans la slide d'avant. Un petit marrant là ici, DocDB qui est capable de vivre une process, mais en fait quand on a des petits entre guillemets datasets, et là on en a qui tiennent en RAM. Une petite machine aujourd'hui, elle a des dizaines de gigs de RAM, donc un système qui s'exprime en gigas, il peut être chargé. Voilà pour... On se laisse à votre minute pour... Oui, deux minutes! Voilà, je vais la slayer sur 25. Allez, j'avance. Du coup, qu'est-ce qu'on a fait? On a pris des requêtes. On a essayé de les traduire comme on pouvait en requêtes sur l'autre data store et on a comparé principalement le temps de réponse de tout ça, la latence.

30:58 La bonne nouvelle, donc en l'occurrence c'est sur ClickHouse, c'est qu'effectivement on arrive à un système beaucoup plus réactif. 300 millisecondes, c'est pas mal. Ça devient intéressant. Ici, alors ce n'était pas des très très gros volumes, ici c'est des petites expérimentations, et donc on a vu ce gain-là. Et donc on sait que pour plein de scénarios de consommation, le rapport 8 qui est là, il nous intéresse, on est très preneur de ce rapport-là. Et on a commencé à faire des choses dans cette direction-là. On a également fait... chose et donc je vais prendre les deux minutes on a en gros un système chez nous qui a une couche d'abstraction sur les requêtes qu'on va faire parce que notre domaine est en métier notre data model il est gros il y a 1500 features qui se battent un peu dans tous les sens c'est éparpillé dans plein de collections il y a des relations qui ont l'air logique mais qui marche pas d'une collection à une autre ou qui marche etc donc on a un petit DSL qui représente un langage de requête orienté métier qui s'appelle BQL chez nous

32:00 qui est le Botify pour les langages parce que on était Botify quoi et ensuite on a du code qui prend en gros les schémas connus la requête exprimée c'est un petit JSON qui fait un AST à partir de ça qui le retraduit et à partir de cette retraduction qui choisit ensuite le datastore et qui fait une dernière phase d'adaptation du dialecte SQL Et donc on en a trois aujourd'hui. Redis vous connaissez, BigQuery vous connaissez, PGO vous ne connaissez pas. C'est un système qui stocke directement sur S3 avec un format super compressé qu'on utilise pour des besoins très spécifiques chez nous. Et on s'est dit est-ce qu'on peut rajouter Kikaus? Et donc on a fait la même idée de traduction de requête de façon simple, on l'a intégré comme les autres là-dedans. La bonne nouvelle, c'est que ça marche. Donc en fait, voilà ici un truc d'analyse sur trois ans d'un site web. Et en fait, on a réussi à reproduire notre système, ça fonctionne. Par contre, on n'est pas arrivé au bout. Vous avez en fait ici... Les colonnes vertes qui bégayent et les colonnes time qui bégayent, c'est juste parce qu'il y a la version BigQuery et la version ClickHouse.

33:07 Grosse surprise, en fait pour l'instant la version cliquable c'est pas plus rapide, elle est plus lente dans certains cas. Qu'est-ce qui se passe? On n'a pas encore les 11 ans d'optimisation, de connaissances, de comment faire les requêtes qu'on a aujourd'hui sur des Q, on n'a pas encore les petits caches intermédiaires qu'on a planqués à droite à gauche, etc. Le truc très prometteur c'est qu'on est dans les mêmes ordres de grandeur, j'étais taquin, je suis désolé pour Natalia, j'ai choisi un exemple sur lequel cliquable c'était plus lent, en général ils sont comparables, les cliquables gagnent souvent mais pas beaucoup. Donc je trouvais plus évident de dire, il y a du boulot après, tous les Pélotes ne sont pas adaptés à un changement de base de données, même si sur le papier elles se ressemblent beaucoup. Voilà ce que j'avais à vous raconter sur nos petites migrations. Je n'ai pas trollé beaucoup sur les autres bases de données qu'on avait. On fera ça après, si vous voulez. Merci. Merci beaucoup pour ta présentation. Comme on disait au début, on va essayer de le rendre un peu plus interactif.

34:07 Donc si vous avez une ou deux questions, on peut éventuellement les prendre dès maintenant plutôt qu'à la fin. Est-ce que vous avez des questions? Oui. Je vais te laisser le faire directement. Au micro, tu peux parler de l'antimagique. En fait, déjà, merci pour la présentation. J'ai une question par rapport... Vous avez parlé de pas mal de bases de données que vous avez essayées. Est-ce que vous avez... fermenté avec des table formats sur S3, comme Iceberg ou bien Woody. Je me tourne vers Thomas. Il va attraper le micro pour répondre. Viens, viens, tu vas dans le carré. Thomas Grange, notre co-founder, ex-CTO, patron de l'innovation. On a fait des essais sur Presto. Je ne sais pas quelle est l'ange à l'UVS. Je ne sais plus. Athéna. Athéna. Athéna. Donc on a mis des fichiers parqués sur S3, sur des petites bases, donc on va dire des fichiers qui vont faire quelques centaines de mégas, ça fonctionne bien.

35:14 Par contre, on a fait pas mal d'essais sur les latences. Là où BigQuery ou ClickHouse vont toujours répondre à 10% près en average. On va se retrouver à avoir des latences où parfois on aura des résultats qui vont arriver en une seconde, parfois en 10 secondes. Il y a une prédictabilité finalement du temps de réponse qui était très faible. Et puis plein d'erreurs de rate limit ou de size limit, parfois des erreurs aléatoires. Donc en fait, on sentait que le produit chez DoubleCloud, ce n'était pas très stable. Donc on a assez vite abandonné. Mais par contre, sur des équipes de data science qui ont besoin de faire de l'analytique très rapidement, c'est une technologie qui est assez intéressante parce que derrière, il y a juste besoin d'un S3. Est-ce que vous avez essayé avec un... Parce que par défaut, sur Athena, on a le catalogue Glue, qui est concrètement le Hive Metastore, mais on peut optimiser sur cette partie avec Iceberg ou bien Woody, ou des technologies qui en fait optimisent la construction de la table derrière.

36:24 Ouais, je t'avoue qu'on n'est pas allé plus loin que ça. Désolé. Merci. De rien. Merci beaucoup, Thomas. D'autres questions? On a le temps pour une petite question, et sinon après on aura tout le loisir d'en parler beaucoup plus. Très bien, deuxième. Allez, reprends le micro pour que les gens les entendent. Voilà, super. Sinon on n'entendra pas sur le replay, c'est dommage. En fait, c'est une deuxième question un peu liée au même sujet, mais vous avez parlé de datasets pré-agrégés déjà. Oui. Est-ce que ça, en fait, comment vous décidez de pré-agrégé un dataset? Et deuxième partie, est-ce que vous avez essayé d'utiliser des databases qui, en fait, ont cette fonctionnalité-là de base, comme Druid, par exemple, qui travaille sur la pré-agrégation de la data pour optimiser les retweets? Alors, on a pré-agrégé en mode réactif, en regardant comment les choses fonctionnaient et en disant c'est stupide, ça ne peut pas fonctionner comme ça. Et donc c'est des pré-agrégations qui sont au départ destinées à éliminer les jointures et les look-up qui coûtent un bras.

37:31 Je vais donner un exemple tout bête. Aujourd'hui, chez nous, l'URL, c'est un petit peu le sang de tout ce qu'on fait, puisque c'est comme ça qu'on raisonne. Une URL, c'est long comme tout. On a aliacé, ramené ça sur des trucs plus courts, et maintenant, c'est des H qu'on utilise et qui sont partout, et qui sont répliqués absolument partout, de façon à éviter les problèmes de ce côté-là. Un autre endroit sur lequel on préagrège, c'est, on a parfois des notions qui sont presque identiques, mais le fait qu'une page ait été visitée de pas tout à fait... fait dire la même chose lorsqu'on parle d'un crawler ou bien des logs qu'on récupère. Et donc là aussi, on remet les mêmes notions aux différents endroits. Et ensuite, je vais peut-être passer la parole, si vous en voulez beaucoup plus, au bricol qu'on a fait en optimisation de vitesse de requêtage BQ, où on a beaucoup travaillé là-dessus. En inlining, en agrégeant, avec de la vue matérialisée, il y a beaucoup d'endroits où on a préparé énormément les requêtes. Et puis après, on n'aura pas le temps. Après, on a tout ce qu'on a fait sur la grosse problématique de compter dans un très grand volume.

38:36 Là aussi, on ne peut pas compter, c'est trop lent, donc c'est l'hyperloglog partout. Il y a beaucoup de choses qui sont cachées derrière ça. Merci beaucoup. Merci encore, Pierre. Donc, on a parlé de ClickHouse, on va continuer à parler de ClickHouse, mais cette fois-ci, chez DoubleCloud. Nathalia, tu peux nous parler de la stratégie de DoubleCloud en général, et aussi, si on peut parler de l'open source, de l'avenir de l'open source, comment est-ce que ça s'inscrit dans cette stratégie de DoubleCloud? Ça marche, oui. Quand j'étais chez Databricks, Databricks, c'était le domaine de l'EI. Donc, c'était Spark. Ils ont passé pas mal d'années en faisant pas mal de meetups pour populariser les technologies. Et c'était la grosse vague. la première vague de l'intelligence artificielle, absolument chaque CTO a voulu tester et trouver quelque chose. Donc depuis, DataRix, comme la société, continue à ajouter des éléments.

39:41 Qu'est-ce qu'ils font aujourd'hui? Aujourd'hui, ils ont créé une plateforme où tu peux construire ton data stack en commençant par intégrer les données, transformer les données, faire quelque chose avec les données, faire les ML là-dessus, visualiser les données. Donc ça devient la plateforme end-to-end analytics, donc Databricks est arrivé ici aujourd'hui. Sauf que ça, c'est la plateforme, ce qu'en anglais on appelle proprietary. Donc une fois que tu es dedans, tu ne vas jamais sortir. Et donc, chez DoubleCloud, moi personnellement, on trouve que le monde change. Justement, ce que Pierre a dit, il y a des clients anti-Amazon. Pour Amazon Pro, Amazon, il y a les clients anti-Google, Pro-Google, etc. En plus, le monde de cloud devient un peu trop cher pour plein de sociétés. Donc du coup, plein de monde regarde, est-ce qu'il ne faut pas installer déjà les choses entre elles? Comment tu fais si tu as acheté déjà la technologie, si tu as déjà dépensé des millions de dollars?

40:46 Tu ne fais pas. Donc la réponse pour moi, c'est open source. La vraie open source, c'est l'open source qui est managé. Donc ça veut dire quoi? Ça veut dire que l'histoire de sécurité, des backups, des choses que tu ne veux pas faire et que tu préfères coder, donc ça c'est managé et open source reste open source. Un jour tu en as marre, tu prends ton open source et tu le ménages vers ton propre serveur, ou tu as les deux choses en même temps. Et c'est ça les philosophies de Double Cloud. Donc ce qu'on veut proposer, c'est on donne la plateforme, ou les technologies open source qui vous permettent, les technologies vous permettent. Travailler avec les données de la façon que vous voulez, adresser les... problème business que vous avez, sauf que ça reste open source et un jour quand vous voulez partir, vous partez. Une technologie clé de DoubleCloud, c'est ClickHouse Open Source. C'est historique parce que l'équipe de dev, ils ont aussi des racines de Yandex qui a inventé ClickHouse.

41:49 Qui paraît progressivement sorti de la société, mais aujourd'hui, ils ont quand même beaucoup d'expérience de créer les bases de données managées et surtout adresser les vraies problématiques des clients. Et donc du coup, c'est pour ça que les cas, c'est une des choses principales. Après, j'ai parlé des autres, de Kafka, d'Herpou, etc. Mais en gros, l'idée de Double Cloud, c'est ça. Et moi, je voulais parler surtout, je ne veux pas parler de ce qu'on fait, c'est moins intéressant. Je voulais parler un peu de la cuisine, de la base de données managée. Quelles sont les différences entre, ok, tu installes ton clicker sur ton propre serveur, ou tu utilises quelque chose managé, c'est quoi les problématiques et comment on les a adressées ces problématiques dans le passé et aujourd'hui. Alors, ClickHouse, vous avez déjà parlé, Pierre vous a déjà expliqué, donc c'était déjà créé il y a des années, en 2016, c'était Open Source, et il y a énormément d'adoptions pour ça.

42:52 Pourquoi? Parce que c'est extrêmement rapide, c'est une vraie base de données orientée colonne, Et comme Pierre a expliqué, comme résultat, c'est fait pour analytics rapide, quasi en temps réel. Mais c'est l'autre logique que par exemple le Kafka qui va permettre de faire aussi le temps réel, mais c'est l'autre définition du temps réel. Il y a beaucoup de forks, il y a plus de 22 000 contributeurs sur GitHub et sur ClickHouse, donc c'est quelque chose qui devient assez populaire. Et donc il y a les gros logos, ce n'est pas les nôtres, mais il y a les grosses sociétés qui ont déjà déménagé, c'est les cas publics. Donc il y a un parc publiquement qui, voilà, on utilise ClickHouse pour les raisons x, y. Vous avez déjà compris, c'est la question de performance qui devient importante dans le monde moderne. Ça, c'est les benchmarks sur bare metals de mémoire, donc les sites que vous trouvez vous-même.

43:55 Mais vous voyez que le click house, par exemple, par rapport à Postgres, c'est foissant la performance. Donc il y a les cas quand ce n'est pas important et il y a les cas quand ça va être très important et cette différence est cruciale pour, par exemple, certaines justices, certaines datasets que vos clients utilisent régulièrement. Après, en plus, comme ClickHouse travaille avec le Time Series, c'est parfait pour cette analytics d'un réel. Ça s'intègre hyper bien dans le stack actuel. Donc, ce n'est pas une question de migration totale. Vous pouvez, comme encore une fois, vous avez vu l'exemple de Botify, vous pouvez utiliser ClickHouse dans votre stack actuel, par exemple comme data store ou comme satellite à côté de votre stack. Et faire, par exemple, on a des clients qui ont déjà Spark, qui ont déjà Kafka, ils font les calculs directement de ClickHouse, donc les données sont envoyées vers ClickHouse et voilà comment ça se passe.

45:00 La beauté de ClickHouse, c'est que c'est une base de données extrêmement extensible. Donc un cluster est possible à étendre avec des serveurs. La plus grande installation dans le monde de ClickHouse aujourd'hui, c'est 2000 serveurs. D'ailleurs, c'est un grand concurrent de Botify de mémoire. Et donc, ils ont 2000 serveurs, c'est beaucoup, mais il n'y a pas de dégradation de performance. C'est ce qui est génial. Après, il y a les scénarios spécifiques. Donc, un des scénarios les plus populaires est des logs. Donc, encore une fois, laissez le use case de Uber, c'est public sur leur blog de dev, qu'ils ont expliqué pourquoi ils ont déménagé, comment le déménagement s'est passé, pourquoi ils utilisent Kikar, etc. Il y a l'autre use case qui est très populaire, c'est quand on a besoin d'analyser, par exemple, le comportement des utilisateurs, quand on reçoit beaucoup de données de devices IoT, etc.

46:05 Et aussi, par exemple, Cloudflare utilise pour sécurité. C'est le ski, c'est assez typique, donc assez populaire. Aujourd'hui, il y a plusieurs façons, comme c'est une base de données open source, il y a plusieurs façons de travailler avec cette base de données. Il y a, vous l'installez sur votre ordinateur, sur ici tout le monde, vous le mettez sur votre ordinateur. manager vous-même. Ça marche hyper bien quand vous avez peu de données et c'est parfait. Il y a la possibilité de l'utiliser de façon manager open source, c'est notre casque qu'on propose. Mais il y a aussi autre façon de faire, il y a plein d'autres forts comme je dis, par exemple, le tag DB, Il y a ClickHouse Local pour... Vous pouvez lire pour Parsing Arcade Files, je ne sais pas comment dire ça en français. Bon bref, il y a plein de façons de le faire. Maintenant, la problématique de gestion de ClickHouse par vous-même, en fait, il y a plein de problèmes pour n'importe quelle base de données.

47:08 Mais la grosse différence de ClickHouse, c'est que c'était fait pour beaucoup de données. Beaucoup de données, c'est terabytes de données. Donc n'importe quelle base de données avec terabytes de données, c'est comment se comporter un peu mal. C'est lent, ça tourne mal. Donc quand vous travaillez avec autant de volume de données sur ClickHouse, vous managez vous-même, Il y a beaucoup de problèmes qui apparaissent. Par exemple, je ne sais pas, les backups. Comment vous faites un backup régulier pour un terabyte de données? Donc, ce n'est pas évident. Pour manager ClickHouse vous-même, il faut Zookeeper. Et pour anecdote, Zookeeper, c'était tellement compliqué pour ClickHouse que l'équipe de dev de ClickHouse.com aujourd'hui, Ils ont été fatigués de Zouképer, ils ont créé Klikaus Kipek. Donc, c'est l'histoire comme ça sur les quantités. Après, l'histoire de sharding. Donc, quand vous êtes...

48:10 Aide capacité pour vos clusters et vous avez besoin de faire un resharding, c'est une tâche quasi impossible si vous faites ça vous-même. Donc nous, on a un grand nombre de fois, notre approche toujours, c'est soit parce que c'est compliqué pour nous-mêmes et donc on change de produit, soit c'est parce que les clients demandent et donc on fait quelque chose. Donc il y avait les petits problèmes pour les gestions de clics house que les clients nous ont demandé, il y avait les grands problèmes. Parmi les petits problèmes adressés, la première c'est comment tu fais une mise à jour. Donc si tu as installé ton instance de ClickHouse, chaque deux semaines ou chaque mois, il y a la mise à jour de ClickHouse. Donc comment mettre à jour ce que tu as? Ici, le problème, c'est que pour mettre à jour, tu dois stopper le cluster. Évidemment, il y a les business quand ce n'est pas possible, et donc comment faire?

49:13 Nos développeurs ont approché ça de façon suivante. Donc déjà, il y a le maintenance window quand tu décides toi-même, ok, le maintenance pour mes clusters, c'est possible la nuit du dimanche, lundi ou la nuit de fête de la musique en France. Parce qu'en tous les cas, personne ne va être sur, par exemple, nos sites. Et après, on ne fait pas la mise à jour de cluster, c'est toujours, je ne sais pas si c'est le mot équivalent, node, donc node par node. Ça veut dire quoi? Ça veut dire qu'il y a, par exemple, aujourd'hui, c'est une nouvelle version de ClickHouse qui arrive. On le teste, on regarde s'il n'y a pas de régression, s'il ne faut pas modifier quelque chose dans le code pour être sûr que c'est compatible. Après, il y a un script spécial qui vérifie quels sont les clusters et les nodes qui sont éligibles pour cette mise à jour.

50:21 Et après, pendant la période que la maintenance doit se passer, le script lance la mise à jour. Et c'est comme ça, les clusters éligibles sont mis à jour. Tout se passe automatiquement, il n'y a pas besoin de stopper les clusters et créer les problèmes qu'on n'a pas. L'autre problème du clickhouse original, c'était que le clickhouse était fait avec beaucoup de métriques, genre une centaine de métriques. Les métriques sur la performance, sur la quantité de requêtes, tout ce que vous pouvez imaginer pour la base de données. Sauf qu'il n'y avait pas de visualisation avec. Donc oui, certes, on peut toujours connecter un des outils qu'on a avec la base de données de clickhouse, mais de temps en temps, on n'a pas envie. Et on a dressé ça de façon très simple. Donc il y a plusieurs façons de faire. Les métriques peuvent être collectées par Grafana. Les métriques sont toujours par défaut dans nos dashboards qu'on a dessinés pour le monitoring.

51:27 Ou ça peut être connecté avec quelque chose d'autre. Mais surtout, on prend tout ce métrique que ClickHouse nous donne dans la base de données centralisée et après on propose les subsets de données pour voir comment la base de données se comporte, qu'est-ce qui est important de notre expérience pour le client à savoir à n'importe quel moment. Les deux grands problèmes qui sont intéressants et que l'équipe de dev a passé beaucoup de temps pour résoudre et adresser, c'est le problème de backup et le problème de déploiement de ClickHouse dans votre propre compte, par exemple Amazon. Le backup. Donc jusqu'à peu, il n'y avait pas de possibilité de faire... En fait, il n'y avait pas de backup par défaut dans ClickHouse. Et on parle beaucoup avec les sociétés qui utilisent ClickHouse déjà, et ça marche hyper bien pour eux, sur leur propre serveur, sur ici tout, mais ils se plaignent tous sur backup en disant qu'est-ce que c'est, c'est compliqué. Et donc c'est pour ça qu'on a pris beaucoup de temps pour proposer les bonnes solutions.

52:31 La bonne solution pour le backup, c'est quoi? Bon déjà, tu veux que tes backups soient au moins chaque jour. Plus souvent, c'est compliqué parce que, comme j'ai dit, ça peut être une base de données hyper large, donc ça peut être compliqué. La deuxième chose très importante pour le backup, c'est que... En fait, ok, imaginons qu'il y a un backup, mais il y a la question de sécurité. Comment tu approches les sécurités que personne... Voilà, qu'il n'y a rien de grave. Et après, si c'est quelqu'un qui fait gestion de ClickHouse, et si les personnes s'occupent trop de backup, donc en fait, il fait beaucoup moins de temps pour, par exemple, créer les lignes de code. Donc, c'est quelque chose où on peut passer beaucoup moins de temps si c'est possible. Donc chez DoubleCloud, les backups, on a créé nos propres outils pour faire la chose suivante. Déjà, on a travaillé beaucoup avec l'équipe de dev de ClickHouse pour être sûr qu'on peut faire les snapshots.

53:34 Parce que quand la base de données change tout le temps, on ne peut pas faire le backup parce que ça change. Donc maintenant c'est possible. Après, on fait le snapshot. Le backup se passe sur S3, un baquet dédié pour le backup. Chaque fois, par cluster, c'est un clé encryption by cluster. Et donc, comme résultat, ça se passe chaque jour. Il n'y a pas de pensée, il ne faut pas penser de backup pour les utilisateurs. Restauration, ça se passe aussi assez facilement. Quelque chose passe, vous voulez restaurer, vous cliquez restaurer. La base de données, ça arrive dans un nouveau cluster. Et donc, voilà. Encore une fois, chaque cluster a les clés d'inscription, donc un cluster ne peut pas avoir accès à l'autre.

54:37 L'outil pour restaurer le clickhouse, on va aller au bon sort, c'est bientôt parce qu'on l'a créé, on va partager avec le monde. C'est même une minute pour la dernière problématique de laquelle je voulais parler. Alors, j'ai mis les mots-clés parce que c'est notre propre terme, bring your own. Mais bring your own account, ça veut dire quoi ? C'est déployer ClickHouse dans votre propre compte AWS ou GCP ou n'importe quel cloud. Donc pourquoi un gros n'importe quelle société, pourquoi c'est intéressant de déployer quelque chose dans votre propre compte? Évidemment pour l'argent. Si vous ne savez pas, chez AWS, le plus vous utilisez de ressources, le plus de remises vous pouvez avoir, donc c'est intéressant. Après, la deuxième raison évidente, c'est le périmètre de sécurité ou de compliance. Ça veut dire que si data reste dans votre propre compte, vous n'avez pas besoin de, par exemple, faire audit de vendeur où vous prenez la prestation.

55:52 Chez nous, le cloud, en fait, il a deux parties. Il a la partie control plane et la partie data plane. Donc, control plane, c'est les applications. Par exemple, le même script dont je parlais qui va lancer la mise à jour du cluster. Et il y a data plane. Et donc, data plane, c'est les clusters, vos clusters, vos données, S3 pour les backups, S3 pour le storage, si vous utilisez ce qu'on appelle le hyper storage. Donc, c'est entre SSD et S3, etc. Et donc... Et donc, tout... ces données et tous ces clusters vont entrer dans votre propre compte. Et je me suis permis de mettre ce qu'il y a de l'équipe de Pierre qui nous a dit ça, et c'était vraiment très important pour nous, c'est comme la reconnaissance de quelque chose qui a fait bien. Mais effectivement, on est fiers de ce qu'on a réalisé. Cette réalisation vient de façon comment on a créé cette gestion de base de données.

56:56 En fait, chaque instance de ClickHouse chez nous, c'est une machine virtuelle. Et pour chaque client, c'est une network, c'est une network virtuelle. Donc un gros déploiement dans votre compte, c'est un déploiement de la même network, sauf que chez vous. Et pour nous, le même problème n'était pas comment faire ça, parce que souvent le problème est là. Mais en fait, pour nous, le problème était comment trouver le rôle, par exemple, comment trouver le login mot de passe, cette instance qu'on appelle les rôles. Ça peut déployer à votre nom dans votre compte. Et c'est compliqué. Pourquoi? Parce que ça doit être très limité, mais en même temps assez large. Et donc on a cherché, on a travaillé pas mal là-dessus. Vous savez, par exemple, avec AWS, et au final, chez AWS, c'est la cloud formation qui permet de faire ça. Donc du coup, on demande à nos clients d'utiliser et déployer la cloud formation. On prend le résultat JSON.

58:03 On prend les résultats comme JSON, BPCID, etc. Et avec ça, le déploiement se passe. Et voilà, c'est hyper simple. Et comme résultat, les clients en profitent tout en gardant l'état dans leur périmètre. Je pense que c'est tout. Merci beaucoup. On attend de prendre une question, si vous en avez. Alors moi, je vais poser la question, puis y répondre. À quoi ça sert d'un Euro on Account? Pour nous, ça a un intérêt qui n'a pas cité Natalia, mais ça veut dire que la data est très, très, très de son utilisation. Et ça veut dire qu'on n'a pas de coût de transfert lorsqu'on passe d'un environnement à l'autre dans Amazon, alors qu'en général, même à l'intérieur d'Amazon, on paye au passage. Et là, on n'a pas ce guichet à traverser. Oui, ça reste.

59:06 Il y avait une discussion assez longue à me coller dessus. Merci beaucoup, Nathalie. Merci. De mon côté, je suis un mot de délai, je ne vous ai pas fait de slide, mais c'est pas grave. Je vais vous partager un peu sur les retours d'expérience que j'ai eus sur les problématiques data. Alors, si je parle sur l'actuel, chez Putsang, je disais tout à l'heure, un des enjeux qui est cette composante analytics de mesure de performance. On a vraiment une équipe qui est dédiée à ça. C'est vraiment de mesurer à quel point est-ce que l'appli fonctionne bien, comment est-ce que ça se passe pour les différents clients, de pouvoir leur fournir des dashboards, de leur fournir aussi du service de recommandation qui est derrière. En fait, pour ça, il a fallu construire toute la plateforme. Alors comme beaucoup de boîtes qui se construisent, on a eu plusieurs versions. de la plateforme avec des versions legacy. Ce qu'on a aujourd'hui, on a deux, trois plateformes qui coexistent, donc on avait beaucoup appris avec nos premières plateformes sur la stack BI.

1:00:11 De mémoire, ça avait commencé par un Elasticsearch qui récupérait tout, ce qui venait d'un name qui était aussi historisé dans un Oracle, qui ensuite allait se déverser dans un MongoDB, et à partir de là, il y avait des extracts qui étaient faits du MongoDB pour aller se mettre dans du tableau. Bref, ça fonctionne en vrai, mais c'était assez lourd et là l'idée c'était de prendre les enseignements de tout ça pour reconstruire toute la plateforme d'Atta. Notre plateforme, elle fonctionne sous la forme d'événements, classiquement, ce sont des microservices qui communiquent entre eux. On a un service, ce qu'on appelle du KW ici, donc du Know Your Customer, qui va dire, j'ai telle pièce qui a été uploadée, je vais l'envoyer à un système de classification qui va me dire, il s'agit d'un permis de conduire français de 2012, et donc qui vont communiquer uniquement sur du messaging. Et donc nous, on a notre data lake qui est en fait un Minayo. On est complètement sur de l'open source, sur pratiquement l'ensemble de toutes les technologies, avec un Kafka Connect qui va venir écouter tout ce qui se passe, le mettre dans notre milieu et exécuter différentes pipelines pour de l'anonymisation.

1:01:20 Donc quand même sur de la donnée qui est extrêmement sensible. D'ailleurs, on a beaucoup parlé de cloud aujourd'hui, ce soir. Moi, je suis... Alors j'ai fait du cloud dans ma précédente expérience, dans le montage du projet, la création de la boîte, c'était top, ça fonctionne très bien, c'est facile. Et là où je suis maintenant, je l'expérimente différemment, c'est que je suis dans un milieu qui est beaucoup plus contraint en termes de réglementation, et donc le cloud ça ne passe pas du tout. C'est-à-dire la donnée financière, c'est extrêmement fort en termes de certifications qui sont nécessaires. On a le SACNIM Cloud qui est une certification qui est donnée par l'ANSI pour notamment les services financiers qui poussent à ne pas utiliser les grands cloud providers qui ne sont pas certifiés, même si c'est en train de changer. Il y a des consortiums qui se sont créés sur les trois gros et qui justement cherchent à obtenir ce type de certification. Je crois qu'il y a Thales et Google qui se sont maqués et qui devraient notamment avancer dessus à partir de 2024.

1:02:24 Mais donc on a cette contrainte qui est très forte et qu'on ne peut pas. Tu as cité un chiffre qui était intéressant tout à l'heure, tu as dit que vous étiez 300 pour 3 DevOps. Donc nous on est 110 sur une équipe de production qui doit avoir une vingtaine de personnes, entre 15 et 20 personnes, avec des DevOps, des gens qui gèrent la prod, etc. Donc on voit tout de suite le ratio qui n'est pas du tout le même, il faut gérer toute notre infra. En plus on est sur différents providers, on a du OVH, on a un tout petit peu de Google sur une application qui était à l'heure. Un test qui a été fait pour certains clients qui ont plus lié à de l'assurance que à de la banque et donc qui acceptent qu'on aille sur ce type de techno. Et on a du IBM, bref, on a pas mal de différents providers qu'on concilie. Donc c'est pour ça qu'on a besoin d'avoir une équipe assez forte pour administrer ce que j'ai commencé à décrire. Notre Kafka, notre Minayo, qui ensuite lui est orchestré par un Airflow qui va faire toute la pipeline d'anonymisation, de traitement, jusqu'à son ingestion dans une masse post-greffe.

1:03:33 D'ailleurs, j'y pensais tout à l'heure quand on parlait, et à un moment on avait des problèmes de perte dans mon ancienne expérience, et on avait expérimenté Citus. Je ne sais pas si tu connais, mais qui est une couche par-dessus de Postgres et qui permet justement de faciliter toute la gestion du sharding. Alors, ça marche? Ça marche assez bien, mais par contre, ce n'est pas si simple que ça à utiliser. Oui, c'est ça. C'est développé par ceux qui sont partis justement de chez Postgres et qui se sont mis à mettre ça d'affaires. Mais l'approche était intéressante. Donc bref, ça arrive dans un post-grès, ça met à disposition notre data warehouse en quelque sorte auprès des analytics engineers. Et en fait c'est ça l'élément qui était assez essentiel par rapport à la stack qui existait avant, le Mongo qui était orchestré par un préfet avec des jobs qui tombent. La différence, le pain point qu'on a rencontré, il était là. C'était comment est-ce qu'on arrive à leur donner plus en plus d'autonomie, puisque ça a... n'existait pas à l'époque pour construire leur dashboard. Bon, il y a une techno, je suis sûr que vous connaissez tous, qui est DBT, qui fonctionne très très bien, particulièrement avec les bases SQL et les postes Grey,

1:04:41 qui leur a vraiment permis de gagner, déjà en compétences, parce qu'on parle beaucoup en ce moment du métier d'Analytics Engineer, mais en vrai c'était des data analysts à ce moment-là, Donc il a fallu organiser toute la montée en compétences pour les faire monter sur SQL, sur toute la stack de comment est-ce qu'on construit sa requête, etc. Donc ça, ça a été un très beau lot qui a super bien fonctionné. Maintenant, ils sont totalement opérationnels, totalement autonomes dans ce qu'ils construisent. Là, on en est à la phase de plus de dashboarding. On utilisait historiquement plus du tableau pour exposer. On pousse vraiment beaucoup l'open source sur la plupart de nos solutions. Donc là, on est en train de décommissionner. Et là, on est parti sur une autre solution qui est sur du métabase. On a fait une longue étude architecturale sur le sujet et qui semble pas mal correspondre aux attentes. On l'a testé avec différents métiers, avec les CSM, avec des PO, avec des chefs de projet, et ça a super bien fonctionné. Ils ont réussi à totalement répondre à leurs questions.

1:05:42 Et là, on a un enjeu qui est plus sur la notion de catalogue. Comment est-ce qu'on arrive à vraiment entretenir notre catalogue de données pour leur permettre de garder encore plus d'autonomie, mais aux différents métiers, cette fois-ci, et plus aux data analysts, aux analytics engineers. Et un élément sur lequel je voulais insister, donc dans toute cette stack, toute l'administration de cette stack, le fait d'avoir une équipe infra, une équipe infra top pour administrer tout ça, par contre ça leur bouffe bien sûr pas mal de temps, avec énormément de chantiers sur le côté. Je pense que s'il n'y avait pas eu la contrainte de la certification qui est derrière, on serait largement parti sur une solution cloud. Et d'ailleurs, on s'autorise à potentiellement le remettre en question. Et justement, En ce moment, on a tout sujet de comment est-ce qu'on arrive à créer de l'autonomie pour les équipes qui proviennent de l'infra pour justement embarquer toutes nos demandes, nos différentes versions, nos différents updates, etc. Donc ça, ça vous donne à peu près les grandes lignes de la plateforme data qui s'est créée.

1:06:50 Donc totalement open source, on en est vraiment très content. La communauté bien sûr, celle des outils qu'on a pris, est quand même assez large et assez développée. On en est encore au début de cette plateforme, donc je suis sûr qu'on va rencontrer encore pas mal de choses. Je pense qu'il va falloir faire un test de ClickHouse de notre côté, parce que moi j'en suis convaincu maintenant. Voilà. Et c'est à peu près dans les grandes lignes ce que je voulais vous raconter sur le retour d'expérience. J'ai une question pour toi. Je t'en prie. Metabase, c'est intéressant. On est aussi en train de le regarder. Il y a une question qu'on est en train de se poser qui est la suivante. Tu ne peux pas juste donner toutes tes datas à Metabase et espérer que ça va être utilisable ou compréhensible. C'est impossible. Donc un pré-travail avant que la donnée soit consommable par des gens sur Metabase qui est un peu magique, Clicodrome, Safe Service, etc. Qui fait la demande en disant j'ai un nouveau besoin et qui fait l'intégration des données vers Metabase? J'ai trois. Alors, Metabase, c'est juste un outil d'ajout de données.

1:07:53 Donc, il n'y a pas de données. Mais donc, tu peux préparer la donnée pour Metabase. Et la question, c'est qui prépare la donnée? À la demande de qui? Tout à l'heure, je parlais du métier d'Analytics Engineer. Finalement, c'est eux qui vont être chargés de ça. Donc en fait, le modèle de données, eux, ils sont vraiment au plus proche des métiers. Donc le modèle de données qui a été mis en place, ce n'est pas un modèle de données technique comme on pourrait le penser par des data engineers. Il a été vraiment vu comme étant des tables qui répondent à des problématiques métiers. En fait, déjà, il est conçu pour s'adapter assez facilement à ce public, qu'il le comprenne d'une manière très lisible. Et si on a des modifications qui sont à faire, là, ça rentre du côté des analytics engineers. Mais ce qu'on constate vraiment maintenant, c'est qu'il n'y a pas tant de demandes que ça. Alors, on en est au début, bien sûr, mais il n'y a pas tant de demandes que ça. C'est vraiment très simple à utiliser pour eux. Il faut se dire qu'avant, ils faisaient leur dashboard, qui était, donc là c'était le dashboard directement sur les événements, c'était sur du Kibana. Je parle de CSM sur Niki Banar.

1:08:57 Ok, c'est bon. Si tes CSM savent utiliser Kibana, il faut que tu ailles recruter du monde chez toi. Ce n'est pas le plus aisé. En vrai, Metabase, tu vois la différence avec Metabase. Si vous avez d'autres questions, n'hésitez surtout pas. Je suis un peu curieuse sur votre processus KYC, parce que là, vous parlez un peu de dashboarding. J'imagine que c'est pour des consommations internes, business stakeholders. Mais je me demandais un peu sur tout ce qui est analytique sur KYC que vous pourrez fournir peut-être à vos clients. Donc aujourd'hui, quel data product vous fournissez à vos clients, peut-être les marchands qui font des crédits, etc. Oui, en fait, cette approche de la mesure de la performance, en effet, elle a deux objectifs. De l'interne, c'est comprendre nos produits, comment ils fonctionnent, comment est-ce qu'on peut les améliorer.

1:09:59 C'est vraiment quelque chose qui s'est... inscrit très profondément dans l'entreprise, dans trois grands objectifs, et le data-driven est vraiment un de nos objectifs forts. Mais surtout, l'accompagnement qu'on pouvait avoir. Historiquement, on faisait beaucoup d'accompagnement avec notre expertise de notre plateforme. Typiquement, sur les problématiques de KWIC, c'était de se dire, tel document qui a été uploadé, telle typologie de document, on sait que ça fonctionne super bien ou beaucoup moins bien. On a des contrôles qui s'appliquent sur les documents. Est-ce que le nom que j'ai détecté dans la carte d'identité correspond au nom qui était dans le formulaire ou est-ce que la photo d'identité, ce n'est pas complètement n'importe quoi? J'ai un exemple là de... On avait vu, je crois que c'était il n'y a pas très très longtemps, on demandait un justificatif de refus et c'était une photo de billet qui était posée par terre. C'est un justificatif de refus. On peut essayer, sincèrement. Un jour, il y en a un qui voulait scanner un document, il l'a mis sur une porte qui était à genre...

1:11:03 5-6 mètres, et sur un cintre, et il l'a pris en photo à 5-6 mètres, et c'était le scan du document. On voit de tout, vraiment, sur le KWICI, sur l'analyse des documents qui nous sont posés. Mais bon, bref, ce qu'on est en train de mettre en place, justement, c'est cette offre d'ashboarding qui va intégrer ces mesures de performance qui sont très précises, parce que c'est vraiment sur le portefeuille des différents clients, mais aussi sur les produits qu'ils consomment. C'est-à-dire les produits KWICI, les différents contrôles, Et à partir de là, on peut leur faire des recommandations de comment est-ce qu'on va tuner les contrôles. Et de se dire, ok, j'ai mon funnel, j'ai cette idée de funnel, pour rappel, c'est que j'ai des inputs, et à la fin, j'ai mes outputs, et au fur et à mesure, je perds des gens derrière. Et c'est de se dire, ok, là, je suis très très dur sur les contrôles, Donc potentiellement je vais en alléger certains parce qu'ils sont moins importants, moins intéressants. Peut-être des contrôles sur de l'adresse, ce genre de choses. Et c'est ce type d'insight qu'on va leur fournir. Merci à vous. Voilà, dans les grandes lignes, je crois que je dépasse le temps et que je pique les femmes sur moi.

1:12:08 Mais on aura l'occasion, si vous avez d'autres questions, d'en parler juste après. Merci beaucoup à tous pour votre attention là-dessus. Et on va passer aux mots de conclusion. Ah, vous êtes trop bien. Qu'est-ce qu'on pourrait tirer de cette session sur le papier? On a parlé d'open source, de cloud, de clickhouse. Envers-tu? Je vais tricher parce que j'y ai réfléchi avant. Qu'est-ce que j'avais préparé pour vous sur les trucs qui sont importants lorsqu'on commence à attaquer ces problèmes de data analytics? C'est qu'on bouge de stack en stack. Deux trucs. On a intérêt à outiller les circuits d'alimentation de données le plus tôt possible. Parce que sinon, on se retrouve avec, j'en ai 8 versions, je ne sais plus laquelle c'est, j'ai un nouvel utilisateur, une nouvelle app, mais elle n'est pas branchée, etc. Donc, vous n'allez peut-être pas avoir une notion complète de l'INH dès le début, avec tous les circuits d'alimentation automatisés depuis des autres mètres que vous connaissez, mais pensez-y, c'est le premier truc. Et c'est ce qu'on a fait avec l'équipe Machine Learning quand on a commencé.

1:13:10 Il y avait deux personnes dans l'équipe quand on a mis en place des pipelines automatisés d'ingestion. Les gens me jetaient des pierres. Et puis en fait, c'est très, très pratique. Et le deuxième, mais ça, c'est valable partout, mettez de la métrologie super tôt aussi. Ça va vous permettre de comprendre à quel moment ça va exploser. Et ça va exploser. Voilà, c'est tout. Natalia, de votre côté, qu'est-ce que tu retiens de notre session? Je pense que moi, ce que je crois... T'as le micro? Hein? Ah! Mais je pense que ce que je retiens, c'est que vous deux, vous avez dit la même chose. En fait, open source, le data stack change, et c'est normal. Et le mot de... En fait, les relations avec Cloud, ça change aussi, et c'est normal. Voilà. Je crois qu'on peut terminer là-dessus. Merci beaucoup à tous les deux pour vos interventions. Et maintenant, on va passer à la suite. Un petit buffet, je crois, nous attend avec un peu de boisson que j'aperçois de loin.

1:14:14 Merci à tous d'être venus. Merci.