Smart Talk Épisode 8 : Obtenir des informations en temps réel sur les Data Lakehouses

Le Data Lakehouse est devenu un référentiel flexible et multi-usage. Dans cet épisode de Smart Talk, Dinesh Chandrasekhar, PDG de Stratola, et son invité, Justin Borgman, PDG et président de Starburst, discutent de la manière d'étendre les capacités d'un lac de données pour inclure des données en temps réel et des requêtes hautes performances qui peuvent fournir des informations presque en temps réel, un cas d'utilisation de plus en plus courant. Deux technologies clés sont requises :les flux Kafka et un moteur de requête puissant.

Leurs points de vue sur l’importance des logiciels open source et des formats ouverts sont particulièrement intéressants. Ils ont été validés par Snowflake et Databricks annonçant la prise en charge d’Apache Iceberg. Justin partage ses conseils pour les solutions d'analyse comparative :utilisez les données de votre entreprise, exécutez vos requêtes réelles, simulez l'échelle et, enfin, calculez les coûts.

Les sujets abordés incluent :

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

Invité

Justin Borgman, PDG et président de Starburst

Justin Borgman est un expert en la matière dans tout ce qui concerne le Big Data et l'analyse. Avant de fonder Starburst, il était vice-président et directeur général chez Teradata (NYSE :TDC), où il était responsable du portefeuille de produits Hadoop de l'entreprise. Justin a rejoint Teradata en 2014 via l'acquisition de sa société Hadapt dont il était co-fondateur et PDG. Hadapt a créé « SQL sur Hadoop », faisant passer Hadoop d'un système de fichiers à une base de données analytique accessible par n'importe quel outil de BI. Il a fondé Starburst en 2017, dans le but de donner aux analystes la liberté d'analyser divers ensembles de données, où qu'ils se trouvent, sans compromettre les performances. 

Hôte

Dinesh Chandrasekhar est un évangéliste technologique, un leader d'opinion et un analyste chevronné du secteur informatique. Avec près de 30 ans d'expérience, Dinesh a travaillé sur des logiciels d'entreprise B2B ainsi que sur des produits SaaS, fournissant et commercialisant des solutions sophistiquées pour des clients dotés d'architectures complexes. Il a également défini et exécuté des stratégies GTM très réussies pour lancer plusieurs produits à forte croissance sur le marché dans diverses sociétés telles que LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM, etc. Il est un conférencier prolifique, un blogueur et un codeur le week-end. Dinesh est titulaire d'un MBA de l'Université de Santa Clara et d'une maîtrise en applications informatiques de l'Université de Madras. Actuellement, Dinesh dirige sa propre entreprise, Stratola, une société de conseil en stratégie commerciale et de services de marketing complets axée sur le client.

Ressources

Smart Talk Épisode 7 :Cardinalité, contrôle et coûts en observabilité

Smart Talk Épisode 6 : AIOps et l'avenir de la surveillance informatique

Smart Talk Épisode 5 : Désagrégation de la pile d'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 et LLM modernes

Smart Talk Épisode 2 :L'essor des applications GenAI avec Data-in-Motion

Smart Talk Épisode 1 : Le paysage de l'écosystème des données en mouvement

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

Apprenez-en davantage sur les données en mouvement sur RTInsights ici

Transcription

Dinesh Chandrasekhar :

Bonjour et bienvenue dans cet épisode de la série Smart Talk at 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, PDG et président de Starburst. Justin a eu une brillante carrière dans des sociétés de sécurité et d'analyse de données et, avant de fonder Starburst en 2017, il avait fondé une société appelée Had Adapt, qui a ensuite été acquise par Teradata, où il a été vice-président et directeur général pendant plusieurs années. Bienvenue Justin. Et donc commençons par Starburst, n’est-ce pas ? Je pense que beaucoup de gens connaissent Starburst en tant que marque, mais beaucoup de gens sont également désireux d'en apprendre un peu plus sur Starburst. Parlez-nous de Starburst, en particulier de ses origines et de votre volonté de créer l'entreprise.

Justin Borgman :

Ouais, avec plaisir. Ainsi, comme vous l'avez mentionné dans l'introduction, je travaille dans le domaine de l'analyse de données depuis environ 15 ans maintenant, depuis cette première startup, qui a été acquise par Teradata. Bien sûr, comme votre public le sait sûrement, Teradata a été pendant de nombreuses décennies le leader de l'analyse de l'entreposage de données. Et ce modèle nécessitait vraiment de déplacer toutes vos données dans une base de données propriétaire, qui était l'entrepôt de données de votre entreprise. Et à partir de là, vous pouvez exécuter des analyses rapides et comprendre votre entreprise. Je pense que ce que nous avons vu était une occasion de renverser ce modèle, notamment de deux manières. Premièrement, la possibilité d'exploiter des formats de tables ouvertes dans un lac de données, vous offrant ainsi des performances d'entreposage de données. Mais dans un lac de données, les gens appellent parfois cela aujourd'hui une architecture Lakehouse, en plus de pouvoir accéder à d'autres sources de données et joindre des tables qui vivent dans une autre base de données avec des tables situées dans ce lac de données.

Ainsi, par exemple, vous pouvez disposer d'une base de données Oracle ou d'une base de données SQL Server et vous souhaitez joindre une table dans l'un de ces systèmes avec une table au format de fichier Iceberg dans un lac de données. 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 bon nombre des plus grandes sociétés Internet, LinkedIn, Airbnb, Netflix, Apple, etc., effectuent leurs propres analyses d'entreposage de données. Encore une fois, dans ce modèle où le lac de données est le référentiel central où ils peuvent obtenir un coût de possession très faible, stocker des données dans ces lacs de données, ainsi que pouvoir rejoindre d'autres tables également. Et donc, en réalité, Starburst n'est que la commercialisation de ce projet open source. Nous proposons une version entreprise de Trino dotée de fonctionnalités de sécurité supplémentaires, de connecteurs supplémentaires, d'avantages de performances supplémentaires et de toute une série d'autres caractéristiques et fonctionnalités.

Dinesh Chandrasekhar :

Merci. Et je veux vraiment plonger un peu plus profondément dans Trino et Iceberg et tout ça. Je pense que ce sont tous d'excellents sujets pour aujourd'hui, mais puis-je prendre un peu de recul et vous demander si vous regardiez l'évolution des architectures de données, nous avons eu les bases de données traditionnelles, puis les entrepôts de données, et avec l'explosion des données et la nécessité de traiter davantage de données en temps réel, des architectures Lakehouse et autres sont apparues. Donc, dans votre monde, lorsque vous regardez l'évolution des architectures de données, du data Lakehouse, et dans votre cas, je pense que vous avez également un concept appelé Icehouse, quel impact cela a-t-il eu sur la capacité des organisations à gérer efficacement les données en temps réel ?

Justin Borgman :

Ouais, excellente question. Et juste pour clarifier pour vos auditeurs, le concept de la glacière n’est en réalité qu’une cabane au bord d’un lac basée sur un iceberg. Ainsi, les données sont stockées dans un format de tableau iceberg et vous pouvez en plus effectuer des analyses de style entrepôt de données. Le résultat net offre un coût total de possession très faible ainsi que la possibilité de gérer des données en temps quasi réel, comme vous l'avez décrit. Nous constatons une augmentation considérable du nombre de technologies de streaming de données sur le marché, comme Kafka par exemple, où les clients les utilisent de plus en plus pour diffuser des données en temps quasi réel dans un lac de données.

Et de notre point de vue, c’est là que nous voulons le reprendre. Nous avons créé quelque chose que nous appelons l'ingestion de flux dans lequel vous pouvez vous connecter à un flux Kafka et nous le transformerons automatiquement en tables Iceberg et les rendrons disponibles pour des interrogations presque instantanément. Cela permet donc désormais à une entreprise d'avoir des informations beaucoup plus rapides et plus récentes sur ses données grâce à cette architecture.

Dinesh Chandrasekhar :

Merci. Lakehouse promet donc définitivement d'être une approche architecturale très unifiée pour l'analyse par lots et en temps réel. Pouvons-nous dire cela, je veux dire, comment voyez-vous ce changement architectural transformer la BI et la prise de décision traditionnelle dans tous les secteurs d'aujourd'hui ? Comment cela a-t-il changé ?

Justin Borgman :

Oui, je vois que cela change les choses de façon assez spectaculaire. Je pense que l’un des moteurs et l’un des avantages de cette architecture est aussi simple que l’économie. En fin de compte, ces entrepôts de données traditionnels pourraient coûter très cher. C'était probablement l'une des principales plaintes pendant mon séjour 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 que cela coûte extrêmement cher et une fois que vous y êtes, vous y êtes et vous êtes en quelque sorte engagé.

Ce lac de données vous offre donc une plus grande flexibilité car vous utilisez des formats ouverts, ce qui permet au client de choisir quel est le bon moteur pour accéder à mes données. Il vous offre beaucoup de flexibilité, réduit le verrouillage, mais vous permet également de stocker vos données dans un stockage de base très bon marché, qui dans le contexte du cloud est de plus en plus le stockage S3 ou Google GCS ou Azure Data Lake. Et même dans le monde sur site, nous voyons un stockage d'objets compatible S3 provenant de sociétés comme Dell ou IBM ou autre, où vous pouvez essentiellement obtenir S3. Cela devient donc une sorte de couche de base commune pour stocker les données de manière très, très rentable, et cela fait partie de ce qui motive cette transformation.

Dinesh Chandrasekhar :

D'accord, alors parlons peut-être maintenant, puisque je pense que c'est un peu le moteur de votre offre, il a gagné en popularité au fil des ans en tant que 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 ? Comme vous l'avez mentionné, il existe d'autres technologies open source comme Apache Iceberg, qui offrent également une grande interopérabilité entre différents systèmes de données, etc. Alors, comment cela s'est-il combiné avec la combinaison de certaines de ces autres technologies open source pour changer l'écosystème de données moderne ?

Justin Borgman :

Je pense que cela devient vraiment le genre de Postgres de l'entreposage de données. Postgres est bien sûr une base de données open source largement déployée et extrêmement populaire. Il s’agit d’un nœud unique R-D-B-M-S traditionnel. Trino est un peu comme l’équivalent analytique de l’entreposage de données à traitement massivement parallèle MPP. Et donc pour votre big data, pour vos activités de type entreposage de données, cela devient désormais le choix open source de facto.

Parfois, les gens se demandent :qu'en est-il de Spark en comparaison ? Spark est un excellent moteur de traitement à usage général, mais pas vraiment optimisé pour l'analyse SQL. Et je pense à votre point précédent sur la business intelligence et la prise de décision, SQL est toujours le langage de ce type de cas d'utilisation, qu'il s'agisse de connecter un outil de BI, d'exécuter des rapports ou même de créer des applications basées sur les données, SQL continue d'être un langage d'interface très important, et Trino est le moteur numéro un pour cela sur le marché aujourd'hui.

Lorsque vous le combinez avec quelque chose comme Iceberg, comme vous l'avez dit, vous disposez désormais d'un entrepôt de données complet. Vous avez la partie moteur de requête, vous avez la partie stockage, et maintenant vous disposez d'un entrepôt de données ouvert complet. Ils peuvent également fonctionner n’importe où, sur site ou dans le cloud. Vous disposez donc d'une grande flexibilité avec cette pile.

Dinesh Chandrasekhar :

Puis-je vous poser une petite question dérivée ? Depuis que vous avez mentionné SQL comme une sorte de référence pour beaucoup de ces magasins de données ces jours-ci, et je crois qu'au cours des 30 ou 40 dernières années, rien n'a pu ébranler cela, c'est sûr, mais avec l'avènement des technologies de génération d'IA et de traitement du langage naturel partout, les gens sont désormais en mesure de parler de démocratisation des données et vous les distribuez désormais même aux analystes commerciaux qui n'ont probablement pas les mêmes connaissances, mais peuvent utiliser le langage naturel pour dire, obtenez-moi les trois derniers mois de ventes dans cette région particulière. et ainsi de suite.

Et en interne, il traduit évidemment cela en SQL, puis interroge le moteur ou autre, n'est-ce pas ? Alors, voyez-vous également un changement dans ce domaine ? SQL va-t-il prospérer et survivre, ou va-t-il y avoir un changement dans la façon dont nous considérons les données de requête à l'avenir ?

Justin Borgman :

C’est une très bonne question et je pense que vous avez touché à quelque chose. Je pense que progressivement, au fil du temps, je pense que l'IA générative en tant qu'interface deviendra très populaire parce que, selon vous, elle est en quelque sorte stupide pour que quiconque puisse l'utiliser franchement. Il s’agit désormais davantage d’une expérience Google sur toutes les données d’une entreprise, et c’est très excitant. En fait, nous en avons incorporé une première version dans notre propre produit et je pense que tout le monde le fera, cela deviendra un enjeu de table.

Je pense cependant que, dans les coulisses, ces technologies se contenteront de convertir ce langage naturel en une syntaxe SQL que le moteur pourra réellement exécuter. Je pense donc que le langage sera toujours important, mais il pourrait devenir davantage un détail d’implémentation derrière une interface de style langage naturel d’IA générative. Je pense que tu as raison. Cela me rappelle un peu l’époque où les calculatrices ou même les calculatrices graphiques ont été inventées. Du coup, nous n’avions plus besoin de connaître toutes les formules ni exactement comment effectuer une division longue, car notre calculatrice s’en chargeait. Je pense que c'est un peu ce que l'IA générative va faire pour nous ici.

Dinesh Chandrasekhar :

Un accès plus facile aux données, bien sûr. Je pense que c’est là que nous nous dirigeons. C’est donc définitivement un espace passionnant. Nous avons donc parlé de Trino. Puis-je changer de vitesse et vous poser à nouveau des questions sur Iceberg ? Cela devient très, très populaire. Je vois les plus grands géants de l'industrie commencer à adopter l'iceberg comme une façon très naturelle de dire que nous sommes interopérables, que nous le soutenons, etc. Alors que les organisations adoptent de plus en plus l’analyse en temps réel, quel est le rôle de l’iceberg pour permettre une gestion des données plus efficace et évolutive ? Quelle est votre opinion à ce sujet ?

Justin Borgman :

Ouais, je pense que c'est un gros problème. Je pense que c’est la plus grande histoire autre que l’IA de 2024. Et la raison pour laquelle je dis cela est que le format existe depuis quelques années, mais en réalité cette année, le marché a en quelque sorte réglé le débat sur le format qui va gagner. Il y a eu une brève période où il y avait en quelque sorte trois formats concurrents populaires, et la question était de savoir qui allait gagner ?

Notre pari a toujours été Iceberg, je suppose que je dirais que nous avions prédit que cela irait dans cette direction, mais je pense que le marché s'est en quelque sorte mis d'accord cet été lorsque Snowflake et Databricks ont annoncé leurs propres intentions de le prendre en charge, et cela a en quelque sorte tué le débat comme Iceberg est la norme de facto et ce que cela fait pour les clients, les clients sont de loin les vrais gagnants. Et c’est parce qu’ils peuvent désormais stocker les données dans un format qui leur appartient, qu’ils contrôlent et qui est portable pour eux, et qui n’est pas entre les mains d’un fournisseur de bases de données qui va les tenir en otage pendant des décennies.

Cela leur appartient et cela signifie qu’ils peuvent faire fonctionner les moteurs les uns des autres. Ils peuvent dire, d'accord, Starburst va effectuer cette charge de travail qui va me donner le meilleur rapport coût/performance pour cela. Peut-être que Snowflake est meilleur pour cette charge de travail. Peut-être que Databricks est meilleur pour cette charge de travail et que le client a le choix entre ces moteurs, ce qui est incroyable. Lorsque les moteurs sont en compétition, vous gagnez en tant que client et je pense que c'est vraiment ce qu'Iceberg propose.

Dinesh Chandrasekhar :

Mais c'était un excellent résumé. Je pense que cela a clairement montré l'importance de l'iceberg pour l'avenir, alors que les entreprises standardisent sur un modèle dans lequel je pense que tout le monde est plus interopérable et je pense que cela profite au client, comme vous l'avez dit, sans avoir à être lié à un fournisseur particulier, mais leur permet d'être un peu plus ouvert et flexible. C'est certainement un excellent point.

Justin Borgman :

Exactement.

Dinesh Chandrasekhar :

Justin, pourquoi ne pas parler peut-être d'un exemple de client ici parce que Trino et Iceberg sont au centre de la conversation aujourd'hui, parlez-nous peut-être d'une étude de cas client où vous avez vu cela pratiquement utilisé et quels sont les types d'avantages qu'ils ont vu en adoptant Trino et Iceberg ?

Justin Borgman :

Heureux de le faire. Il existe un certain nombre d'exemples, allant de grandes sociétés Internet comme DoorDash à des entreprises plus traditionnelles comme Comcast qui existent depuis longtemps, qui dans les deux cas s'éloignent de ce que j'appellerais les plates-formes d'entrepôt de données traditionnelles, déplaçant les charges de travail pour démarrer des plates-formes d'entrepôt de données traditionnelles.

Dans le cas de Comcast, entrepôt de données sur site très traditionnel. Dans le cas de DoorDash, je l’appellerais un entrepôt de données cloud très traditionnel. Et dans les deux cas, ce qu’ils essaient de faire en fin de compte, c’est d’obtenir un meilleur TCO sur leurs analyses SQL et d’offrir la flexibilité nécessaire pour travailler avec les dernières technologies de pointe qui peuvent s’interfacer à partir de ce format commun unique.

Encore une fois, pour revenir à notre point précédent, je pense que ce qu'ils essaient également de faire, et cela est lié au sujet de l'IA, c'est de jeter les bases de la mise en place de leur architecture de données où ils peuvent désormais avoir un accès facile aux données dont ils ont besoin pour former leurs propres modèles ou exécuter des flux de travail RAG pour soutenir leurs propres ambitions en matière d'IA. Et je pense que beaucoup d’entreprises en sont à leurs débuts en train de comprendre ce que l’IA peut faire pour moi ? Comment cela peut-il me donner un avantage concurrentiel ?

Et pendant qu’ils s’en rendent compte, je pense qu’une chose sur laquelle ils sont tous très clairs est que leurs propres données exclusives seront essentielles pour leur donner un avantage concurrentiel. La mise en place d'une infrastructure de données qui vous donne accès à ce dont vous avez besoin de manière peu coûteuse et hautement performante est donc une étape essentielle de ce processus.

Dinesh Chandrasekhar :

Donc, pour bénéficier d'un avantage, puis-je double-cliquer dessus et vous dire ou vous demander des données en temps réel en particulier, cela introduit souvent des défis tels que des changements d'évolution du schéma à mesure que les sources changent, la cible doit s'adapter et ainsi de suite, ainsi que la gestion des versions des données. Comment Apache Iceberg aide-t-il à relever certains de ces défis dans les plateformes de données modernes comme celle-ci ?

Justin Borgman :

Il y a donc le concept de versioning et de voyage dans le temps et de pouvoir en quelque sorte voir comment les données ont évolué au sein de notre plate-forme. Nous avons également ajouté la traçabilité des données et des mesures de qualité des données que nous sommes en mesure de capturer et de présenter à nos utilisateurs afin que vous puissiez vraiment comprendre d'où proviennent ces données, comment ont-elles évolué, comment ont-elles été itérées et fournir à nouveau cette visibilité à l'utilisateur final.

Dinesh Chandrasekhar :

D'accord. Ensuite, avec Trino, vous avez expliqué comment combiner diverses sources de données et effectuer des requêtes conjointes, etc. L'architecture évolue-t-elle davantage vers une source de données ou un stockage de données centralisé, ou les conserve-t-elle là où elles se trouvent, tout en offrant la possibilité de les combiner et en donnant de la visibilité aux consommateurs ? Quelle est l’architecture interne que nous examinons ici ?

Justin Borgman :

Ouais, excellente question. Il y a des éléments des deux, et je pense que c’est ce qui a toujours rendu difficile pour nous d’articuler notre propre proposition de valeur, car les gens sont habitués à un seul modèle et à un seul état d’esprit, qui consiste à tout centraliser dans un entrepôt de données traditionnel ou à n’y avoir tout simplement pas accès. Et je pense que la façon dont nous voyons le monde évoluer est qu'il y aura un référentiel central qui sera incontestablement un lac de données, qui stockera la majorité des données ou autant de données que possible parce que vous obtiendrez des avantages économiques, vous obtiendrez des avantages en termes de performances en stockant autant que vous le pouvez au format iceberg dans votre lac. Nous pensons donc qu'il s'agit d'une excellente stratégie pour un grand nombre de vos données, mais nous pensons également qu'il y aura toujours des cas d'utilisation dans lesquels vous souhaiterez accéder à une autre source de données.

Il s’agit peut-être d’analyses exploratoires. J'ai juste une hypothèse que je veux tester et qui, je pense, pourrait être très importante pour notre entreprise, mais je ne veux pas développer tous les pipelines ETL et suivre tout ce processus juste pour une idée, juste pour une intuition que j'ai. Eh bien, c’est un excellent cas d’utilisation dans lequel le fait de pouvoir rejoindre une table qui vit ailleurs avec ce que vous avez change la donne. Cela pourrait en fait vous permettre d'aller attester cette hypothèse en quelques minutes plutôt qu'en quelques semaines pour amener les équipes à déplacer les données de la manière dont vous auriez besoin. Et donc je pense que les deux sont précieux, mais nous les considérons comme majoritaires dans le lac et ensuite, au-delà de ce lac, c'est notre façon de penser.

Dinesh Chandrasekhar :

Donc, si je suis une entreprise tierce qui recherche, disons, une plate-forme de données moderne, quelles sont certaines des considérations critiques en matière de performances que je voudrais avoir dans ma liste de contrôle lorsque j'examine Trino par rapport à un tas d'autres alternatives ? Ensuite, ma priorité est, disons, de gérer les requêtes de données en temps réel, de m'assurer qu'il y a une faible latence et des choses comme ça. Voilà donc mes exigences. Quelles sont certaines des considérations que je voudrais avoir dans ma liste de contrôle ?

Justin Borgman :

Ouais. Eh bien, les deux principaux conseils que je donnerais sont, premièrement, d'utiliser de vraies requêtes que vous utilisez réellement. Je pense qu’il est très courant que les gens utilisent des références de l’industrie, et c’est peut-être une étape très superficielle, mais cela ne reflétera pas votre charge de travail. Cela ne l’est jamais. Chaque entreprise essaie de faire ses propres choses. Il est donc toujours préférable d’essayer de simuler au mieux votre état final.

Et cela signifie exploiter vos propres requêtes et vos propres données pendant que vous élaborez votre propre preuve de concept et effectuez des analyses comparatives. Vous ne devriez tout simplement jamais faire confiance exclusivement aux références d’autres fournisseurs. Même le nôtre. Nous les avons, vous pouvez les consulter, mais vous devriez vraiment les tester vous-même avec vos propres requêtes et vos propres données.

La deuxième chose que je dirais est également de s'assurer que vous simulez l'échelle, et l'échelle est importante, car c'est là au moins que nous trouvons certaines de nos propres opportunités avec les clients, par exemple pour remplacer un fournisseur qu'ils ont acheté, alors que dans le processus POC, ils pensaient que ce fournisseur répondait à leurs besoins, mais lorsqu'ils sont arrivés à une échelle de production réelle, il n'a tout simplement pas pu le gérer.

Et c’est là que je pense qu’il y a aussi un grand avantage à exploiter des technologies open source comme Trino, qui ont fait leurs preuves à la plus grande échelle imaginable, comme Apple l’exécute à une échelle insensée, évidemment à une échelle insensée avec Facebook. Donc ce truc peut fonctionner. Cela fonctionne à cette échelle. Cela devrait vous apporter une certaine tranquillité d'esprit. Mais même quand même, je dirais de le simuler vous-même dans votre propre processus d’analyse comparative pour vraiment vous assurer que ces différentes technologies répondront aux besoins que vous avez en production. Cool.

Et puis le troisième élément que j’ajouterai peut-être est le coût. Le coût est également très important, n'est-ce pas ? Le coût et les performances ne sont en réalité que les deux faces d’une même médaille. Et vous devez également en tenir compte dans votre analyse comparative, n’est-ce pas ? Vous n’allez pas seulement choisir le plus rapide. Vous souhaitez choisir le meilleur rapport coût/performance. C'est donc également une partie importante du composant.

Dinesh Chandrasekhar :

Je suis d'accord. Je pense que c’est un élément majeur de la liste de contrôle pour beaucoup de gens qui évaluent les solutions disponibles. Alors peut-être, terminons-le du point de vue des tendances. Je veux juste vous demander :il se passe beaucoup de choses dans l’espace des données aujourd’hui, n’est-ce pas ? Il existe donc des fournisseurs d'entrepôts de données, des fournisseurs de Lakehouse, des fournisseurs de lacs de données et plusieurs alternatives, des bases de données d'analyse en temps réel, etc.

Les choix sont décidément larges et déroutants pour l’acheteur. Donc, du point de vue des tendances émergentes, voyez-vous une sorte de convergence se produire en ce qui concerne le traitement des données en temps réel, les architectures de lacs de données dont nous venons de parler et l'écosystème open source en général ? Selon vous, envisagez-vous une sorte de convergence qui rendrait les choses plus claires pour l'acheteur dans un avenir proche ?

Justin Borgman :

Je le fais. Je pense que nous commençons à voir émerger des modèles très populaires. Ces modèles proviennent très souvent d’Internet, des hyperscalers et se traduisent ensuite dans l’entreprise au fil du temps. Et je pense que nous en sommes maintenant au point où cela fait son chemin dans l’entreprise. Et les modèles que je vois exploitent des technologies comme Kafka pour la partie streaming. Et bien sûr, vous avez plusieurs choix. Vous pouvez faire Confluent, vous pouvez faire la version Amazon. Vous avez le choix sur toutes ces plateformes open source, ce qui est formidable. Je pense qu'Iceberg, bien sûr, pour le format de stockage de vos données, cela me semble être le pari le plus sûr que vous puissiez faire. Et puis du côté du moteur, encore une fois, trouver le bon moteur pour le bon travail. Je pense que s'il s'agit de SQL Analytics, nous dirions que Trino et Starburst sont le meilleur choix, mais vous devriez vous le prouver.

Si vous entraînez un modèle d'apprentissage automatique, vous utiliserez probablement Spark pour cela. Et ce sont les modèles que nous observons. Je pense que ces quatre technologies seront incroyablement populaires dans les architectures de données open source dans les années à venir. Et encore une fois, l’open source vous offre la flexibilité nécessaire pour pouvoir mélanger et assortir les composants au fil du temps, ce qui permettra à votre architecture de résister à l’épreuve du temps. Et je pense que c’est vraiment ce que vous voulez faire, c’est ne pas créer de dette technique que vous aurez vraiment du mal à remplacer dans 10 ans. Et l'open source vous offre cette flexibilité.

Dinesh Chandrasekhar :

J'adore ce point. Merci. Je pense que nous devrions conclure cela avec cette excellente note. Justin, merci beaucoup d'être parmi nous aujourd'hui. Je pense que ce fut une excellente conversation pour mieux comprendre Trino et Iceberg et comment Starbust propose cette fantastique plate-forme qui combine le meilleur des deux mondes dans votre plate-forme. Merci beaucoup et merci de vous joindre à nous.

Justin Borgman :

Merci Dinesh. C'était avec plaisir.