Smart Talk Épisode 8 : Débloquer des Insights en Temps Réel sur les Data Lakehouses

Le data lakehouse est apparu comme un référentiel flexible et multi-usage. Dans cet épisode de Smart Talk, Dinesh Chandrasekhar, CEO de Stratola, et son invité Justin Borgman, CEO et Chairman de Starburst, discutent de comment étendre les capacités d'un data lakehouse pour inclure les données en temps réel et les requêtes haute performance qui peuvent fournir des insights quasi en temps réel — un cas d'usage de plus en plus courant. Deux technologies clés sont requises — les flux Kafka et un moteur de requête puissant.

Particulièrement intéressantes sont leurs perspectives sur l'importance du logiciel open-source et des formats ouverts, validée par l'annonce de Snowflake et Databricks du support d'Apache Iceberg. Justin partage ses conseils pour benchmarker les solutions — utilisez vos données d'entreprise, lancez vos vraies requêtes, simulez l'échelle, et enfin, calculez les coûts.

Sujets abordés :

• Kafka pour le streaming de données en temps réel dans les data lakehouses (4:22)
• Avantages des formats ouverts (5:56)
• Le rôle de support de SQL pour GenAI (8:53)
• Snowflake, Databricks et Iceberg (11:56)
• Stratégie de référentiel de données flexible (17:21)

Invité

Justin Borgman, CEO et Chairman, Starburst

Justin Borgman est un expert en big data & analytics. Avant de fonder Starburst, il était Vice President & GM chez Teradata (NYSE: TDC), responsable du portefeuille de produits Hadoop. Il a rejoint Teradata en 2014 via l'acquisition de sa société Hadapt où il était co-fondateur et CEO. Hadapt a créé le « SQL sur Hadoop » transformant Hadoop d'un système de fichiers en base de données analytique accessible par tout outil BI. Il a fondé Starburst en 2017, cherchant à donner aux analystes la liberté d'analyser divers ensembles de données où qu'ils se trouvent, sans compromettre la performance.

Animateur

Dinesh Chandrasekhar est un évangéliste technologique, un leader d'opinion et un analyste industriel IT chevronné. Avec près de 30 ans d'expérience, Dinesh a travaillé sur des logiciels B2B d'entreprise ainsi que des produits SaaS livrant et commercialisant des solutions sophistiquées pour des clients aux architectures complexes. Il a également défini et exécuté des stratégies GTM hautement réussies pour lancer plusieurs produits à forte croissance sur le marché chez diverses entreprises comme LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM, etc. Il est un conférencier prolifique, blogueur et codeur le week-end. Dinesh détient un MBA de Santa Clara University et un Master en Applications Informatiques de l'Université de Madras. Actuellement, Dinesh dirige sa propre entreprise, Stratola, une société de conseil en stratégie business client-centric et services marketing full-stack.

Ressources

Smart Talk Épisode 7 : Cardinalité, Contrôle et Coûts dans l'Observabilité

Smart Talk Épisode 6 : AIOps et l'Avenir du Monitoring IT

Smart Talk Épisode 5 : Désagrégation de la Stack Observabilité

Smart Talk Épisode 4 : Données en Temps Réel et Bases de Données Vectorielles

Smart Talk Épisode 3 : Pipelines de Données Modernes et LLM

Smart Talk Épisode 2 : L'Essor des Applications GenAI avec Data-in-Motion

Smart Talk Épisode 1 : Le Paysage de l'Écosystème Data-in-Motion

Voir la carte de l'écosystème data-in-motion ici

En savoir plus sur data-in-motion sur RTInsights ici

Transcription

Dinesh Chandrasekhar :

Bonjour et bienvenue à cet épisode de Smart Talk dans la série Data and Motion Leadership. Je suis votre hôte, Dinesh Chandrasekhar, analyste en chef et fondateur de Stratola. Notre invité aujourd'hui est Justin Borgman, CEO et chairman de Starburst. Justin a eu une carrière remarquable dans les entreprises de sécurité et d'analytics de données, et avant de fonder Starburst en 2017, il avait fondé une société appelée Hadapt, qui a été plus tard acquise par Teradata où il a servi comme VP et GM pendant un certain nombre d'années. Bienvenue Justin. Et commençons par Starburst, non ? Je pense que beaucoup de gens connaissent Starburst comme une marque, mais il y a aussi pas mal de gens qui sont impatients d'en apprendre un peu plus sur Starburst. Parlez-nous de Starburst, particulièrement de ses origines et votre motivation pour créer l'entreprise.

Justin Borgman :

Oui, avec plaisir. Donc comme vous l'avez mentionné dans l'introduction, je suis dans l'espace data analytics depuis environ 15 ans maintenant, remontant jusqu'à cette première startup, qui a été acquise par Teradata. Bien sûr, comme je suis sûr que votre audience le sait, Teradata pendant de nombreuses décennies, franchement, était le leader en data warehousing analytics. Et ce modèle nécessitait vraiment de déplacer toutes vos données dans une base de données propriétaire, qui était votre enterprise data warehouse. Et à partir de là, vous pouviez lancer des analytics rapides et comprendre votre business. Je pense que ce qu'on a vu était une opportunité de basically retourner ce modèle sur sa tête, particulièrement de deux façons. Numéro un, la capacité d'exploiter les formats de table ouverts dans un data lake, vous donnant une performance de data warehousing. Mais dans un data lake, parfois les gens appellent cela une architecture lakehouse aujourd'hui, ainsi que la capacité d'aller vers d'autres sources de données et de joindre des tables qui vivent dans une autre base de données avec des tables assises dans ce data lake.

Par exemple, vous pourriez avoir une base de données Oracle ou SQL Server, et vous voulez joindre une table dans l'un de ces systèmes avec une table dans un format de fichier Iceberg dans un data lake. Et c'est essentiellement ce que fait notre technologie. C'est la technologie sous-jacente appelée Trino. C'est un projet open source. Il est né à l'origine de Facebook, et c'est ainsi que de nombreuses des plus grandes entreprises Internet, LinkedIn, Airbnb, Netflix, Apple, etc. font leur propre data warehousing analytics. Encore, dans ce modèle où le data lake est le référentiel central où ils peuvent obtenir un coût de possession très bas, stockant les données dans ces data lakes, ainsi que la capacité de joindre d'autres tables également. Et donc vraiment Starburst n'est que la commercialisation de ce projet open source. Nous fournissons une version entreprise de Trino qui a des fonctionnalités de sécurité supplémentaires, des connecteurs supplémentaires, des avantages de performance supplémentaires, et toute une série d'autres fonctionnalités.

Dinesh Chandrasekhar :

Merci. Et je veux définitivement creuser un peu plus Trino et Iceberg et tout ça. Je pense que ce sont tous de grands sujets pour aujourd'hui, mais puis-je faire un pas en arrière et vous demander si vous regardiez l'évolution des architectures de données, nous avions les bases de données traditionnelles et puis les data warehouses sont arrivés, et avec l'explosion des données et le besoin de traiter plus de données en temps réel, les architectures lakehouse et autres sont arrivées. Donc dans votre monde, en regardant l'évolution des architectures de données, data lakehouse, et dans votre cas je pense que vous avez un concept appelé Icehouse aussi, comment cela a-t-il impacté la capacité des organisations à gérer efficacement les données en temps réel ?

Justin Borgman :

Oui, excellente question. Et juste pour clarifier pour vos auditeurs, le concept icehouse est vraiment juste un lakehouse basé sur Iceberg. Donc les données sont stockées dans un format de table iceberg et vous êtes capable de faire des analytics de style data warehousing par-dessus. Le résultat net fournit un coût total de possession vraiment bas ainsi que la capacité de gérer des données near real-time comme vous l'avez décrit. Et la façon dont on pense à cela est qu'on voit une augmentation tremendeuse de la quantité de technologies de streaming data sur le marché comme Kafka par exemple, où les clients utilisent de plus en plus cela pour streamer des données en near real time dans un data lake.

Et de notre côté, c'est là qu'on veut le récupérer. Nous avons construit quelque chose qu'on appelle streaming ingest où vous pouvez vous connecter à un flux Kafka et nous transformerons automatiquement cela en tables Iceberg et les rendrons disponibles pour requêtage presque instantanément. Donc cela permet maintenant à une entreprise d'avoir des insights beaucoup plus rapides et frais sur leurs données en résultat de cette architecture.

Dinesh Chandrasekhar :

Merci. Donc le Lakehouse promet définitivement d'être une approche d'architecture très unifiée pour l'analytique batch et temps réel. Pourrions-nous dire que, je veux dire, comment voyez-vous ce changement architectural transformer le BI et la prise de décision traditionnelle à travers les industries aujourd'hui ? Comment cela a-t-il changé ?

Justin Borgman :

Oui, je le vois changer les choses assez dramatiquement. Je pense que l'un des moteurs et l'un des bénéfices de cette architecture est aussi simple que l'économie. Au bout du compte, ces data warehouses traditionnels pouvaient devenir très chers. C'était en fait probablement la plainte numéro un pendant mon temps chez Teradata. Personne n'a jamais dit que Teradata était une mauvaise base de données. C'est en fait un excellent système de base de données. Il se trouve juste qu'il est extrêmement cher et une fois que vous y êtes, vous y êtes et vous êtes genre engagé.

Et donc ce data lake vous permet une plus grande flexibilité parce que vous utilisez des formats ouverts, ce qui permet au client de choisir quel est le bon moteur pour accéder à mes données. Cela vous donne beaucoup de flexibilité, réduit le lock-in, mais vous permet aussi de stocker vos données dans du stockage commodity vraiment peu coûteux, ce qui dans le contexte cloud est de plus en plus S3 ou Google GCS ou Azure Data Lake storage. Et même dans le monde on-prem, on voit du stockage objet compatible S3 de sociétés comme Dell ou IBM ou autre, où vous pouvez basically obtenir du S3. Donc cela devient la sorte de couche de fondation commune pour stocker les données très, très efficacement en termes de coûts, et c'est une partie de ce qui pilote cette transformation.

Dinesh Chandrasekhar :

OK, alors peut-être maintenant entrons dans, maintenant depuis que je pense que c'est genre comme le driver principal derrière votre offre, il a gagné en popularité au fil des ans comme un moteur de requête très puissant dans l'espace des données en temps réel. Comment voyez-vous son rôle évoluer dans l'écosystème de données moderne ? Surtout comme vous l'avez mentionné, il y a d'autres technologies open source comme Apache Iceberg, qui offrent aussi beaucoup d'interopérabilité entre différents systèmes de données et ainsi de suite. Donc comment cela combiné avec la combinaison de certaines de ces autres technologies open source change l'écosystème de données moderne ?

Justin Borgman :

Je pense que ça devient vraiment le genre de Postgres du data warehousing. Postgres bien sûr est une base de données open source largement déployée, extrêmement populaire. C'est un R-D-B-M-S traditional single node. Trino est genre comme l'équivalent MPP massively parallel processing data warehousing analytics. Et donc pour vos big data, pour vos activités de style data warehousing, c'est maintenant devenu le choix open source de facto.

Parfois les gens demandent, bien, quoi de Spark en comparaison ? Spark est un excellent moteur de traitement à usage général, mais pas vraiment optimisé pour l'analytics SQL. Et je pense à votre point précédent sur le business intelligence et la prise de décision, SQL est encore le langage de ces types de cas d'usage, que ce soit connecter un outil BI, lancer des rapports, ou même construire des applications data-driven, SQL continue d'être un langage vraiment important pour interfacer, et Trino est le moteur numéro un pour cela sur le marché aujourd'hui.

Quand vous le combinez avec quelque chose comme Iceberg, comme vous l'avez dit, vous avez maintenant un data warehouse essentiellement complet. Vous avez la partie moteur de requête, vous avez la partie stockage, et maintenant vous avez un data warehouse ouvert complet. Ils peuvent aussi tourner n'importe où, ça peut tourner on-prem, ça peut tourner dans le cloud. Donc vous avez beaucoup de flexibilité avec cette stack.

Dinesh Chandrasekhar :

Puis-je vous poser une petite question dérivée ? Puisque vous avez mentionné SQL comme genre de go-to pour beaucoup de ces data stores de nos jours, et je crois que dans les 30, 40 dernières années, rien n'a pu ébranler ça c'est sûr, mais avec l'avènement des technologies gen AI et du natural language processing partout, les gens sont maintenant capables de parler de data democratization où vous le distribuez maintenant même aux business analysts qui n'ont probablement pas une connaissance égale, mais peuvent utiliser le langage naturel pour dire, donnez-moi les trois derniers mois de ventes dans cette région particulière et ainsi de suite.

Et en interne évidemment ça traduit ça en SQL et puis requête le moteur ou quoi que ce soit, non ? Donc voyez-vous un changement là aussi ? SQL va-t-il prospérer et survivre, ou y aura-t-il un changement dans la façon dont on regarde le query data going forward ?

Justin Borgman :

C'est une question vraiment excellente et je pense que vous êtes sur quelque chose là. Je pense que graduellement au fil du temps, je pense que l'IA générative en tant qu'interface va devenir super populaire parce que à votre point, ça genre de simplifie pour n'importe qui franchement pour utiliser. Donc maintenant c'est plus une expérience Google sur toutes les données dans une entreprise, et c'est très excitant. En fait, on a incorporé une version précoce de ça dans notre propre produit et je pense que tout le monde le fera, ça deviendra table stakes.

Je pense cependant, en coulisses, ces technologies vont vraiment juste convertir ce langage naturel en syntaxe SQL pour que le moteur l'exécute réellement. Donc je pense que le langage restera important, mais il pourrait devenir plus un détail d'implémentation derrière une interface de style natural language générative AI. Je pense que vous avez raison. Ça me rappelle un peu quand les calculatrices ou même les calculatrices graphiques ont été inventées, soudain on n'avait plus besoin de connaître toutes les formules et exactement comment faire la division longue parce que notre calculatrice s'en occupait. Je pense que c'est genre ce que l'IA générative va faire pour nous ici.

Dinesh Chandrasekhar :

Accès plus facile aux données, définitivement c'est sûr. Je pense que c'est là qu'on se dirige. Donc définitivement un espace excitant. Donc on a parlé de Trino. Puis-je changer de sujet et vous demander à propos d'Iceberg encore ? Ça devient très, très populaire. Je vois les plus gros béhémoths de l'industrie commencer à adopter iceberg comme une façon très naturelle de dire nous sommes interopérables, nous le supportons, et ainsi de suite. Donc alors que les organisations adoptent de plus en plus l'analytique en temps réel, quel est le rôle d'iceberg pour permettre une gestion de données plus efficace et évolutive ? Quelle est votre opinion là-dessus ?

Justin Borgman :

Oui, je pense que c'est un gros deal. Je pense que c'est la plus grande histoire après l'IA de 2024. Et la raison pour laquelle je dis ça c'est que le format existe depuis quelques années, mais vraiment cette année le marché a genre réglé le débat sur quel format va gagner. Il y a eu une brève période où il y a genre trois formats populaires en compétition, et c'était une question qui va gagner ?

Notre pari était toujours Iceberg, je dirais qu'on a prédit que ça irait dans ce sens, mais je pense que le marché a genre acquiescé vraiment cet été quand Snowflake et Databricks ont annoncé leurs propres intentions de le supporter, et ça a genre juste tué le débat comme Iceberg est le standard de facto et ce que ça fait pour les clients, les clients sont les vrais gagnants là de loin. Et c'est parce qu'ils peuvent maintenant stocker les données dans un format qu'ils possèdent, qu'ils contrôlent qui est portable pour eux, qui n'est pas entre les mains d'un vendeur de base de données qui va les tenir en otage pendant des décennies à venir.

Ils possèdent ça et ça veut dire qu'ils peuvent jouer les moteurs les uns contre les autres. Ils peuvent dire, OK, Starburst va faire cette charge de travail qui va me donner le meilleur coût performance pour ça. Peut-être Snowflake est mieux pour cette charge de travail. Peut-être Databricks est mieux pour cette charge de travail et le client a le choix entre ces moteurs, ce qui est incroyable. Quand les moteurs compétitionnent, vous gagnez en tant que client et je pense que c'est vraiment ce qu'Iceberg rend disponible.

Dinesh Chandrasekhar :

Mais c'était un excellent résumé. Je pense que ça a clarifié l'importance d'iceberg looking forward alors que les entreprises standardisent sur un modèle où je pense que tout le monde est plus interopérable et je pense que ça bénéficie au client, comme vous l'avez dit, sans avoir à être attaché à un vendeur particulier, mais leur permet d'être un peu plus ouverts et flexibles. C'est un excellent point c'est sûr.

Justin Borgman :

Exactement.

Dinesh Chandrasekhar :

Justin, pourquoi ne pas parler d'un exemple client ici parce que Trino et Iceberg sont le centre de la conversation aujourd'hui, dites-nous un cas client où vous avez vu ça mis en pratique concrètement et quels sont les genres de bénéfices qu'ils ont vus en adoptant Trino et Iceberg ?

Justin Borgman :

Avec plaisir. Il y a un certain nombre d'exemples tant des grandes entreprises Internet comme DoorDash que des entreprises plus traditionnelles comme Comcast qui dans les deux cas bougent depuis ce que j'appellerais des plateformes de data warehouse traditionnelles, déplaçant des charges de travail depuis des plateformes de data warehouse traditionnelles.

Dans le cas de Comcast, data warehouse on-prem très traditionnel. Dans le cas de DoorDash, je l'appellerais un data warehouse cloud très traditionnel. Et dans les deux cas, ce qu'ils essaient de faire ultimement est d'obtenir un meilleur TCO sur leur analytics SQL et fournir la flexibilité de travailler avec les dernières technologies de pointe qui peuvent interfacer depuis ce format commun unique.

Encore, à notre point précédent, je pense que ce qu'ils essaient aussi de faire, et cela se rapporte au sujet IA, c'est qu'ils posent les fondations pour mettre leur architecture de données en place où ils peuvent maintenant avoir un accès facile aux données dont ils ont besoin pour entraîner leurs propres modèles ou effectuer des workflows RAG ultimement pour supporter leurs propres ambitions IA. Et je pense que beaucoup d'entreprises sont dans ces premiers jours de genre de comprendre quoi l'IA peut faire pour moi ? Comment cela peut-il me donner un avantage concurrentiel ?

Et pendant qu'ils comprennent ça, une chose je pense qu'ils sont tous très clairs dessus c'est que leurs propres données propriétaires vont être centrales pour leur donner un avantage concurrentiel. Et donc mettre en place une infrastructure de données qui vous donne accès à ce dont vous avez besoin d'une façon low cost high performant est une étape centrale dans ce processus.

Dinesh Chandrasekhar :

Donc comme un moyen de bénéfice dans un, puis-je double-cliquer là-dessus et dire ou vous demander avec les données en temps réel particulièrement, ça introduit souvent des défis comme l'évolution du schéma changements au schéma alors que les sources changent, la cible doit s'adapter et ainsi de suite, et le versioning des données aussi. Comment Apache Iceberg aide à adresser certains de ces défis dans les plateformes de données modernes comme celle-ci ?

Justin Borgman :

Donc il y a le concept de versioning et de faire du time travel et d'être capable de genre voir comment les données ont évolué dans notre plateforme. Nous avons aussi ajouté la lignée de données, des métriques de qualité de données que nous sommes capables de capturer et présenter à nos utilisateurs pour que vous puissiez vraiment comprendre d'où venaient ces données, comment elles ont évolué, comment elles ont itéré et fournir cette visibilité encore ultimement à l'utilisateur final.

Dinesh Chandrasekhar :

OK. Ensuite avec Trino, vous avez parlé de comment vous pouvez combiner des sources de données diverses et faire du joint querying et tout ça. L'architecture bouge-t-elle plus vers une source de données centralisée ou data store, ou est-ce qu'elle les garde où ils sont, mais fournit la capacité de les combiner et donne la visibilité pour les consommateurs ? Quelle est l'architecture in-state qu'on regarde ici ?

Justin Borgman :

Oui, excellente question. Il y a des éléments des deux, et je pense que c'est ce qui a toujours rendu ça difficile pour nous d'articuler même notre propre proposition de valeur parce que les gens sont habitués à un modèle et un état d'esprit, qui est centraliser tout dans un data warehouse traditionnel ou vous n'avez juste pas accès. Et je pense que la façon dont on voit le monde évoluer est qu'il y aura un référentiel central qui va être un data lake incontestablement, qui va stocker la majorité des données ou autant de données que possible parce que vous allez obtenir des bénéfices économiques, vous allez obtenir des bénéfices de performance de stocker autant que vous pouvez en formats iceberg dans votre lake. Donc on pense que c'est une excellente stratégie pour beaucoup de vos données, mais on pense aussi qu'il y aura toujours des cas d'usage où vous voudrez aller vers une autre source de données.

Peut-être que c'est de l'analytics exploratoire. J'ai juste une hypothèse que je veux aller tester que je pense pourrait être vraiment grande pour notre business, mais je ne veux pas développer tous les pipelines ETL et passer par tout ce processus juste pour une idée, juste pour une intuition que j'ai. Eh bien, c'est un excellent cas d'usage où être capable de joindre une table qui vit quelque part ailleurs avec ce que vous avez est un game changer. Ça pourrait en fait vous permettre d'aller tester cette hypothèse en quelques minutes plutôt que des semaines pour faire bouger les équipes pour déplacer les données d'une façon dont vous auriez besoin. Et donc je pense que les deux sont précieux, mais on pense à ça comme majorité dans le lake et puis aller au-delà de ce lake est la façon dont on y pense.

Dinesh Chandrasekhar :

Donc si je suis une entreprise tierce qui est, disons, à la recherche d'une plateforme de données moderne, quelles sont certaines des considérations de performance critiques que je voudrais avoir dans ma checklist quand je regarde Trino versus un tas d'autres alternatives ? Ensuite ma priorité est disons, gérer les requêtes de données en temps réel, s'assurer qu'il y a une faible latence et des choses comme ça. Donc ce sont mes exigences. Quelles sont certaines des considérations que je voudrais avoir dans ma checklist ?

Justin Borgman :

Ouais. Eh bien, les deux principaux conseils que je donnerais sont, numéro un, utilisez de vraies requêtes que vous utilisez réellement. Je pense que c'est très commun pour les gens d'utiliser des benchmarks industriels, et c'est bien comme peut-être une étape très cursory, mais ça ne va pas être reflétif de vos workloads. Ça ne l'est juste jamais. Chaque entreprise a ses propres trucs qu'ils essaient de faire. Donc c'est toujours mieux d'essayer de simuler votre end state du mieux que vous pouvez.

Et cela signifie lever vos propres requêtes et vos propres données pendant que vous mettez ensemble votre propre proof of concept et faites du benchmarking. Vous ne devriez jamais faire confiance aux benchmarks des autres vendeurs exclusivement. Même les nôtres. On en a, vous pouvez les regarder, mais vous devriez vraiment tester ça vous-même avec vos propres requêtes et vos propres données.

La deuxième chose que je dirais c'est aussi assurez-vous que vous simulez l'échelle et l'échelle est importante parce que c'est là où au moins on trouve certaines de nos propres opportunités avec les clients pour disons remplacer un vendeur qu'ils ont acheté, où dans le processus POC, ils pensaient que ce vendeur rencontrait leurs besoins, mais alors qu'ils arrivaient à l'échelle de production réelle, ça ne pouvait juste pas le gérer.

Et c'est là où je pense qu'il y a aussi un grand bénéfice à lever des technologies open source comme Trino, qui ont été prouvées à la plus grande échelle imaginable, comme Apple qui le fait tourner à une échelle insensée, évidemment Facebook échelle insensée. Donc ce truc peut marcher. Ça marche à cette échelle. Ça devrait vous donner une certaine tranquillité d'esprit. Mais même encore, je dirais simulez-le vous-même dans votre propre processus de benchmarking pour vraiment assurer que ces différentes technologies vont rencontrer les besoins que vous avez en production. Cool.

Et puis la troisième pièce peut-être que j'ajouterais c'est le coût. Le coût est aussi si important, non ? Coût et performance sont vraiment juste les deux faces de la même pièce. Et vous avez besoin de factoriser ça dans votre benchmarking aussi, non ? Vous n'allez pas juste choisir le plus rapide. Vous voulez choisir le meilleur coût performance. Et donc c'est une composante importante aussi.

Dinesh Chandrasekhar :

Je suis d'accord. Je pense que c'est un item de checklist majeur pour beaucoup de gens qui évaluent des solutions là-bas c'est sûr. Donc peut-être amenons ça à la fin d'une perspective tendances. Je veux juste vous demander, il y a beaucoup qui se passe dans l'espace data aujourd'hui, non ? Il y a des vendeurs de data warehouse, lakehouse vendors, data lake vendors, et plusieurs alternatives, real-time analytics databases et whatnot.

Les choix sont définitivement larges et confus pour l'acheteur. Donc d'une perspective tendances émergentes, voyez-vous une sorte de convergence arriver quand il s'agit de real-time data processing, les architectures data lakehouse qu'on vient de parler, et l'écosystème open source en général ? Y a-t-il une sorte de convergence que vous voyez arriver qui va le rendre plus clair pour l'acheteur dans le near future ?

Justin Borgman :

Je le pense. Je pense qu'on commence à voir des patterns très populaires émerger très souvent ces patterns originate dans l'Internet, hyperscalers et puis traduisent à l'entreprise au fil du temps. Et je pense qu'on est maintenant à ce point où ça fait son chemin dans l'entreprise. Et les patterns que je vois sont d'exploiter des technologies comme Kafka pour la portion streaming. Et bien sûr vous avez plusieurs choix là. Vous pouvez faire Confluent, vous pouvez faire la version d'Amazon. Vous avez le choix dans toutes ces plateformes open source, ce qui est génial. Je pense Iceberg for sure, pour le format pour stocker vos données, ça me semble comme le pari le plus safe que vous pourriez possible faire. Et puis côté moteur, encore, trouver le bon moteur pour le bon job. Je pense si c'est SQL Analytics, on dirait Trino et Starburst sont le meilleur pari, mais vous devriez le prouver à vous-même.

Si vous entraînez un modèle de machine learning, vous utiliseriez probablement Spark pour ça. Et ce sont les patterns qu'on voit. Je pense que toutes ces quatre technologies vont être incroyablement populaires dans les architectures de données dérivées open-source pour les années à venir. Et encore, l'open source vous donne cette flexibilité de pouvoir mélanger et matcher les composants au fil du temps, ce qui va faire que votre architecture résiste à l'épreuve du temps. Et je pense que c'est vraiment ce que vous voulez faire c'est pas créer de la dette technique que vous allez avoir un très dur temps à remplacer 10 ans plus tard. Et l'open source vous donne cette flexibilité.

Dinesh Chandrasekhar :

J'adore ce point. Merci. Je pense qu'on devrait wrap this up avec cette excellente note. Justin, merci beaucoup de nous avoir rejoints aujourd'hui. Je pense que c'était une excellente conversation pour comprendre plus sur Trino et Iceberg et comment Starbust offre cette plateforme fantastique qui combine le meilleur des deux mondes dans votre plateforme. Merci beaucoup et appréciez vous être joints à nous.

Justin Borgman :

Merci, Dinesh. C'était mon plaisir.