Episódio 8 do Smart Talk:Desbloqueando insights em tempo real sobre Data Lakehouses

O data lakehouse surgiu como um repositório flexível e multiuso. Neste episódio do Smart Talk, Dinesh Chandrasekhar, CEO da Stratola, e seu convidado, Justin Borgman, CEO e presidente da Starburst, discutem como ampliar os recursos de um data lakehouse para incluir dados em tempo real e consultas de alto desempenho que podem fornecer insights quase em tempo real – um caso de uso cada vez mais comum. São necessárias duas tecnologias principais:fluxos Kafka e um poderoso mecanismo de consulta.

Especialmente interessantes são suas perspectivas sobre a importância do software de código aberto e dos formatos abertos que foram validados pela Snowflake e Databricks anunciando o suporte do Apache Iceberg. Justin compartilha seus conselhos para soluções de benchmarking:use os dados da sua empresa, execute suas consultas reais, simule a escala e, por fim, calcule os custos.

Os tópicos abordados incluem:

• Kafka para streaming de dados em tempo real em data lakehouses (4:22)
• Vantagens dos formatos abertos (5:56)
• O papel de suporte do SQL para GenAI (8:53)
• Floco de neve, blocos de dados e iceberg (11:56)
• Estratégia flexível de repositório de dados (17:21)

Convidado

Justin Borgman, CEO e presidente da Starburst

Justin Borgman é um especialista no assunto de big data e análises. Antes de fundar a Starburst, ele foi vice-presidente e gerente geral da Teradata (NYSE:TDC), onde foi responsável pelo portfólio de produtos Hadoop da empresa. Justin ingressou na Teradata em 2014 através da aquisição de sua empresa Hadapt, onde foi cofundador e CEO. A Hadapt criou o “SQL on Hadoop”, transformando o Hadoop de um sistema de arquivos em um banco de dados analítico acessível por qualquer ferramenta de BI. Ele fundou a Starburst em 2017, buscando dar aos analistas a liberdade de analisar diversos conjuntos de dados onde quer que estejam, sem comprometer o desempenho. 

Anfitrião

Dinesh Chandrasekhar é um evangelista de tecnologia, um líder inovador e um analista experiente do setor de TI. Com quase 30 anos de experiência, Dinesh trabalhou em software empresarial B2B, bem como em produtos SaaS, entregando e comercializando soluções sofisticadas para clientes com arquiteturas complexas. Ele também definiu e executou estratégias GTM altamente bem-sucedidas para lançar vários produtos de alto crescimento no mercado em várias empresas como LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM etc. Dinesh possui MBA pela Universidade de Santa Clara e mestrado em Aplicações de Computador pela Universidade de Madras. Atualmente, Dinesh dirige sua própria empresa, Stratola, uma empresa de consultoria de estratégia de negócios e serviços de marketing full-stack com foco no cliente.

Recursos

Episódio 7 do Smart Talk:Cardinalidade, controle e custos na observabilidade

Episódio 6 do Smart Talk:AIOps e o futuro do monitoramento de TI

Episódio 5 do Smart Talk:Desagregação da pilha de observabilidade

Episódio 4 do Smart Talk:dados em tempo real e bancos de dados vetoriais

Episódio 3 do Smart Talk:Pipelines de dados modernos e LLMs

Episódio 2 do Smart Talk:A ascensão dos aplicativos GenAI com dados em movimento

Episódio 1 do Smart Talk:O cenário do ecossistema de dados em movimento

Veja o mapa do ecossistema de dados em movimento aqui

Saiba mais sobre dados em movimento no RTInsights aqui

Transcrição

Dinesh Chandrasekhar:

Olá e bem-vindo a este episódio da série Smart Talk at Data and Motion Leadership. Sou seu anfitrião, Dinesh Chandrasekhar, analista-chefe e fundador da Stratola. Nosso convidado de hoje é Justin Borgman, CEO e presidente da Starburst. Justin teve uma carreira estelar em empresas de segurança e análise de dados e, antes de fundar a Starburst em 2017, fundou uma empresa chamada Had Adapt, que mais tarde foi adquirida pela Teradata, onde atuou como vice-presidente e gerente geral por vários anos. Bem vindo Justino. E então vamos começar com Starburst, certo? Acho que muitas pessoas conhecem a Starburst como uma marca, mas há muitas pessoas que também estão ansiosas para aprender um pouco mais sobre a Starburst. Conte-nos sobre a Starburst, especialmente suas origens e sua motivação para iniciar a empresa.

Justin Borgman:

Sim, é um prazer. Como você mencionou na introdução, estou na área de análise de dados há cerca de 15 anos, desde aquela primeira startup, que foi adquirida pela Teradata. É claro que, como tenho certeza de que seu público sabe, a Teradata, francamente, por muitas décadas, foi líder em análise de armazenamento de dados. E esse modelo realmente exigia a transferência de todos os seus dados para um banco de dados proprietário, que era o data warehouse de sua empresa. E a partir daí você poderá executar análises rápidas e entender seu negócio. Acho que o que vimos foi uma oportunidade de basicamente virar esse modelo de cabeça para baixo, principalmente de duas maneiras. Número um, a capacidade de aproveitar formatos de tabela abertos em um data lake, proporcionando assim desempenho de armazenamento de dados. Mas em um data lake, às vezes as pessoas chamam isso de arquitetura lakehouse hoje, além de serem capazes de acessar outras fontes de dados e unir tabelas que residem em outro banco de dados com tabelas nesse data lake.

Por exemplo, você pode ter um banco de dados Oracle ou SQL Server e deseja unir uma tabela em um desses sistemas com uma tabela em formato de arquivo Iceberg em um data lake. E é essencialmente isso que a nossa tecnologia faz. É a tecnologia subjacente chamada Trino. É um projeto de código aberto. Ele nasceu originalmente do Facebook e é assim que muitas das maiores empresas de internet, LinkedIn, Airbnb, Netflix, Apple, etc., fazem suas próprias análises de armazenamento de dados. Novamente, naquele modelo onde o data lake é o repositório central onde eles podem obter um custo de propriedade muito baixo, armazenando dados nesses data lakes, além de poder juntar outras tabelas também. E então, na verdade, Starburst é apenas a comercialização desse projeto de código aberto. Fornecemos uma versão empresarial do Trino que possui recursos extras de segurança, conectores extras, benefícios extras de desempenho e uma série de outros recursos e funcionalidades.

Dinesh Chandrasekhar:

Obrigado. E eu definitivamente quero mergulhar um pouco mais fundo em Trino e Iceberg e tudo mais. Acho que todos esses são ótimos tópicos para hoje, mas posso recuar um pouco e perguntar se você olhasse para a evolução das arquiteturas de dados, tivemos os bancos de dados tradicionais e depois surgiram os data warehouses, e com a explosão de dados e a necessidade de processamento de mais dados em tempo real, surgiram as arquiteturas lakehouse e outras. Então, no seu mundo, ao observar a evolução das arquiteturas de dados, data lakehouse e, no seu caso, acho que você também tem um conceito chamado Icehouse, como isso impactou a capacidade das organizações de lidar com dados em tempo real de maneira eficaz?

Justin Borgman:

Sim, ótima pergunta. E só para esclarecer aos seus ouvintes, o conceito de casa de gelo é, na verdade, apenas uma casa de lago baseada em um iceberg. Assim, os dados são armazenados em um formato de tabela iceberg e você pode fazer análises no estilo data warehousing além disso. O resultado líquido fornece um custo total de propriedade realmente baixo, bem como a capacidade de lidar com dados quase em tempo real, conforme você descreveu. E a maneira como pensamos sobre isso é que vemos um tremendo aumento na quantidade de tecnologias de streaming de dados no mercado, como Kafka, por exemplo, onde os clientes estão cada vez mais usando isso para transmitir dados quase em tempo real para um data lake.

E do nosso ponto de vista, é aí que queremos continuar. Construímos algo que chamamos de ingestão de streaming, onde você pode se conectar a um fluxo Kafka e transformaremos isso automaticamente em tabelas Iceberg e as disponibilizaremos para consulta quase instantaneamente. Portanto, isso permite que uma empresa agora tenha insights mais recentes e muito mais rápidos sobre seus dados como resultado dessa arquitetura.

Dinesh Chandrasekhar:

Obrigado. Portanto, o Lakehouse promete definitivamente ser uma abordagem de arquitetura muito unificada para análises em lote e em tempo real. Poderíamos dizer isso, quero dizer, como você vê essa mudança arquitetônica transformando o BI e a tomada de decisão tradicional em todos os setores hoje? Como isso mudou?

Justin Borgman:

Sim, eu vejo isso mudando as coisas dramaticamente. Acho que um dos motivadores e um dos benefícios dessa arquitetura é tão simples quanto a economia. No final das contas, esses data warehouses tradicionais podem ficar muito caros. Na verdade, essa foi provavelmente uma das reclamações mais frequentes durante meu tempo na Teradata. Ninguém nunca disse que o Teradata era um banco de dados ruim. Na verdade, é um ótimo sistema de banco de dados. Acontece que é extremamente caro e, uma vez que você entra, você está dentro e meio que comprometido.

E então esse data lake permite uma flexibilidade maior porque você está usando formatos abertos, o que permite ao cliente escolher qual é o mecanismo certo para acessar meus dados. Ele oferece muita flexibilidade, reduz o aprisionamento, mas também permite que você armazene seus dados em um armazenamento de commodities realmente barato, que no contexto da nuvem é cada vez mais o armazenamento S3, Google GCS ou Azure Data Lake. E mesmo no mundo local, vemos armazenamento de objetos compatível com S3 de empresas como Dell ou IBM ou o que quer que seja, onde você pode basicamente obter S3. Portanto, isso se torna uma espécie de camada de base comum para o armazenamento de dados de maneira muito, muito econômica, e é parte do que está impulsionando essa transformação.

Dinesh Chandrasekhar:

Ok, então vamos entrar agora, já que acho que esse é o motivo por trás de sua oferta, ele ganhou popularidade ao longo dos anos como um mecanismo de consulta muito poderoso no espaço de dados em tempo real. Como você vê a evolução do seu papel no ecossistema de dados moderno? Especialmente como você mencionou, existem outras tecnologias de código aberto, como o Apache Iceberg, que também oferecem muita interoperabilidade entre diferentes sistemas de dados e assim por diante. Então, como isso se combinou com a combinação de algumas dessas outras tecnologias de código aberto, mudando o ecossistema de dados moderno?

Justin Borgman:

Acho que está se tornando realmente uma espécie de Postgres de armazenamento de dados. É claro que o Postgres é um banco de dados de código aberto extremamente popular e amplamente implantado. É um nó único R-D-B-M-S tradicional. Trino é como o equivalente analítico de armazenamento de dados de processamento massivamente paralelo do MPP. E assim, para seu big data, para suas atividades de estilo de armazenamento de dados, isso agora está se tornando a escolha de fato de código aberto.

Agora, às vezes as pessoas perguntam:bem, e o Spark em comparação? Spark é um excelente mecanismo de processamento de uso geral, mas não é realmente otimizado para análise SQL. E acho que, falando anteriormente sobre inteligência de negócios e tomada de decisões, SQL ainda é a linguagem desses tipos de casos de uso, seja conectando uma ferramenta de BI, executando relatórios ou até mesmo construindo aplicativos baseados em dados, SQL continua a ser uma linguagem realmente importante para interface, e Trino é o mecanismo número um para isso no mercado hoje.

Quando você combina isso com algo como o Iceberg, como você disse, agora você tem essencialmente um data warehouse completo. Você tem a parte do mecanismo de consulta, a parte de armazenamento e agora tem um data warehouse aberto completo. Eles também podem ser executados em qualquer lugar, no local e na nuvem. Então você tem muita flexibilidade com essa pilha.

Dinesh Chandrasekhar:

Posso fazer uma pequena pergunta? Já que você mencionou o SQL como uma espécie de referência para muitos desses armazenamentos de dados hoje em dia, e acredito que nos últimos 30, 40 anos, nada foi capaz de abalar isso com certeza, mas com o advento das tecnologias de geração de IA e processamento de linguagem natural em todos os lugares, as pessoas agora podem falar sobre a democratização dos dados, onde agora você os distribui até mesmo para analistas de negócios que provavelmente não têm o mesmo conhecimento, mas podem usar a linguagem natural para dizer, me dê os últimos três meses de vendas nesta região específica e assim adiante.

E obviamente traduz isso internamente para SQL e depois consulta o mecanismo ou algo assim, certo? Então você vê uma mudança nisso também? O SQL irá prosperar e sobreviver ou haverá uma mudança na forma como encaramos os dados de consulta daqui para frente?

Justin Borgman:

Essa é uma pergunta realmente ótima e acho que você está no caminho certo. Acho que, gradualmente, com o tempo, acho que a IA generativa como interface se tornará super popular porque, na sua opinião, ela meio que simplifica para qualquer um usar francamente. Portanto, agora é mais uma experiência do Google com todos os dados de uma empresa, e isso é muito emocionante. Na verdade, incorporamos uma versão inicial disso em nosso próprio produto e acho que todos irão, isso se tornará uma aposta na mesa.

Eu acho que, nos bastidores, essas tecnologias estarão apenas convertendo essa linguagem natural em uma sintaxe SQL para o mecanismo realmente executar. Portanto, acho que a linguagem ainda será importante, mas pode se tornar mais um detalhe de implementação por trás de uma interface generativa de estilo de linguagem natural de IA. Acho que você acertou em cheio. Isso me lembra de quando as calculadoras ou mesmo as calculadoras gráficas foram inventadas, de repente não precisávamos saber todas as fórmulas e exatamente como fazer a divisão longa porque nossa calculadora cuidava disso. Acho que é isso que a IA generativa fará por nós aqui.

Dinesh Chandrasekhar:

Acesso mais fácil aos dados, com certeza. Acho que é para onde estamos indo. Então, definitivamente, um espaço emocionante. Então falamos sobre Trino. Posso mudar de assunto e perguntar sobre o Iceberg novamente? Isso está se tornando muito, muito popular. Vejo os maiores gigantes da indústria começando a adotar o iceberg como uma forma muito natural de dizer que somos interoperáveis, que o apoiamos e assim por diante. Assim, à medida que as organizações adotam cada vez mais análises em tempo real, qual é o papel do iceberg para permitir uma gestão de dados mais eficiente e escalável? Qual é a sua opinião sobre isso?

Justin Borgman:

Sim, acho que é um grande negócio. Acho que é a maior história além da IA ​​de 2024. E a razão pela qual digo isso é que o formato já existe há alguns anos, mas na verdade este ano o mercado meio que resolveu o debate sobre qual formato vai vencer. Houve um breve período em que existem três formatos concorrentes populares, e a questão era quem vai ganhar?

Nossa aposta sempre foi Iceberg, acho que previmos que seria assim, mas acho que o mercado realmente concordou neste verão, quando Snowflake e Databricks anunciaram suas próprias intenções de apoiá-lo, e isso meio que acabou com o debate como Iceberg é o padrão de fato e o que isso faz para os clientes, os clientes são, de longe, os verdadeiros vencedores nisso. E isso porque agora eles podem armazenar os dados em um formato de sua propriedade, que eles controlam e que é portátil para eles, que não está nas mãos de algum fornecedor de banco de dados que os manterá como reféns nas próximas décadas.

Eles são donos disso e isso significa que podem usar os motores uns dos outros. Eles podem dizer, ok, o Starburst fará essa carga de trabalho que me dará o melhor desempenho de custo para isso. Talvez o Snowflake seja melhor para esta carga de trabalho. Talvez o Databricks seja melhor para essa carga de trabalho e o cliente possa escolher entre esses mecanismos, o que é incrível. Quando os motores competem, você ganha como cliente e acho que é isso que a Iceberg disponibiliza.

Dinesh Chandrasekhar:

Mas esse foi um ótimo resumo. Acho que isso deixou claro a importância do iceberg olhando para o futuro, à medida que as empresas estão se padronizando em um modelo onde acho que todos são mais interoperáveis ​​e acho que isso beneficia o cliente, como você disse, sem ter que estar vinculado a um fornecedor específico, mas permite que eles sejam um pouco mais abertos e flexíveis. Esse é um ótimo ponto, com certeza.

Justin Borgman:

Exatamente.

Dinesh Chandrasekhar:

Justin, por que não falamos sobre talvez um exemplo de cliente aqui, porque Trino e Iceberg são o centro da conversa hoje, conte-nos sobre talvez um estudo de caso de cliente onde você viu isso praticamente colocado em uso e quais são os tipos de benefícios que eles viram ao adotar Trino e Iceberg?

Justin Borgman:

Feliz por. Há uma série de exemplos, desde empresas líderes de Internet, como a DoorDash, até empresas mais tradicionais, como a Comcast, que já existem há muito tempo e que, em ambos os casos, estão saindo do que eu chamaria de plataformas tradicionais de data warehouse, movendo cargas de trabalho para começar fora das plataformas tradicionais de data warehouse.

No caso da Comcast, data warehouse local muito tradicional. No caso do DoorDash, eu o chamaria de data warehouse em nuvem muito tradicional. E, em ambos os casos, o que eles estão tentando fazer é obter um melhor TCO em suas análises SQL e fornecer a flexibilidade para trabalhar com as mais recentes tecnologias de ponta que podem interagir com esse formato comum.

Novamente, ao ponto anterior, acho que o que eles também estão tentando fazer, e isso está relacionado ao tópico de IA, é estabelecer as bases para colocar sua arquitetura de dados em um lugar onde agora possam ter acesso fácil aos dados de que precisam para treinar seus próprios modelos ou executar fluxos de trabalho RAG, em última análise, para apoiar suas próprias ambições de IA. E acho que muitas empresas estão começando a descobrir o que a IA pode fazer por mim? Como isso pode me dar uma vantagem competitiva?

E enquanto eles estão descobrindo isso, uma coisa que acho que todos eles estão muito claros é que seus próprios dados proprietários serão fundamentais para lhes proporcionar vantagem competitiva. Portanto, configurar uma infraestrutura de dados que lhe dê acesso ao que você precisa com baixo custo e alto desempenho é uma etapa fundamental nesse processo.

Dinesh Chandrasekhar:

Então, como forma de benefício, posso clicar duas vezes nisso e dizer ou perguntar a você, principalmente com dados em tempo real, isso geralmente apresenta desafios como mudanças na evolução do esquema no esquema conforme as fontes mudam, o destino precisa se adaptar e assim por diante, e controle de versão de dados também. Como o Apache Iceberg ajuda a enfrentar alguns desses desafios em plataformas de dados modernas como esta?

Justin Borgman:

Portanto, existe o conceito de versionamento e viagem no tempo e ser capaz de ver como os dados evoluíram em nossa plataforma. Também adicionamos linhagem de dados, métricas de qualidade de dados que podemos capturar e apresentar aos nossos usuários para que você possa realmente entender de onde vieram esses dados, como eles evoluíram, como foram iterados e fornecer essa visibilidade novamente, em última análise, para o usuário final.

Dinesh Chandrasekhar:

Ok. Depois, com Trino, você falou sobre como combinar diversas fontes de dados e fazer algumas consultas conjuntas e tudo mais. A arquitetura está se movendo mais em direção a uma fonte de dados ou armazenamento de dados centralizado, ou está mantendo-os onde estão, mas fornecendo a capacidade de combiná-los e dando visibilidade aos consumidores? Qual é a arquitetura estadual que estamos vendo aqui?

Justin Borgman:

Sim, ótima pergunta. Existem elementos de ambos, e acho que foi isso que sempre tornou desafiador para nós até mesmo articular nossa própria proposta de valor, porque as pessoas estão acostumadas com um modelo e um estado de espírito, que é centralizar tudo em um data warehouse tradicional ou você simplesmente não tem acesso a ele. E acho que a maneira como vemos o mundo evoluindo é que haverá um repositório central que será, sem dúvida, um lago de dados, que armazenará a maioria dos dados ou o máximo possível de dados, porque você obterá benefícios econômicos, obterá benefícios de desempenho ao armazenar o máximo que puder em formatos de iceberg em seu lago. Portanto, achamos que essa é uma ótima estratégia para muitos dos seus dados, mas também achamos que sempre haverá casos de uso em que você desejará acessar alguma outra fonte de dados.

Talvez seja análise exploratória. Tenho apenas uma hipótese que quero testar e que acho que pode ser muito grande para o nosso negócio, mas não quero desenvolver todos os pipelines de ETL e passar por todo esse processo só por uma ideia, só por um palpite que tenho. Bem, esse é um ótimo caso de uso em que poder ingressar em uma mesa que mora em outro lugar com o que você tem é uma virada de jogo. Na verdade, isso pode permitir que você ateste essa hipótese em questão de minutos, em vez de semanas, para que as equipes movam os dados da maneira que você precisa. E então eu acho que ambos são valiosos, mas pensamos nisso como a maioria no lago e, então, ir além desse lago é a maneira como pensamos sobre isso.

Dinesh Chandrasekhar:

Então, se eu sou uma empresa terceirizada que está, digamos, em busca de uma plataforma de dados moderna, quais são algumas das considerações críticas de desempenho que eu gostaria de ter em minha lista de verificação quando estou olhando para o Trino em comparação com um monte de outras alternativas? Então minha prioridade é, digamos, lidar com consultas de dados em tempo real, garantindo que haja baixa latência e coisas assim. Então esses são meus requisitos. Quais são algumas das considerações que eu gostaria de ter em minha lista de verificação?

Justin Borgman:

Sim. Bem, os dois principais conselhos que eu daria são, número um, use consultas reais que você realmente usa. Acho que é muito comum as pessoas usarem benchmarks do setor, e isso pode ser uma etapa muito superficial, mas não refletirá suas cargas de trabalho. Simplesmente nunca é. Cada empresa tem suas próprias coisas que está tentando fazer. Portanto, é sempre melhor tentar simular seu estado final da melhor maneira possível.

E isso significa aproveitar suas próprias consultas e seus próprios dados enquanto você monta sua própria prova de conceito e faz benchmarking. Você nunca deve confiar exclusivamente nos benchmarks de outros fornecedores. Até o nosso. Nós os temos, você pode vê-los, mas você realmente deve testar isso sozinho com suas próprias consultas e seus próprios dados.

A segunda coisa que eu diria é também ter certeza de que você está simulando escala e escala é importante porque é aqui que pelo menos encontramos algumas de nossas próprias oportunidades com os clientes para, digamos, substituir um fornecedor que eles compraram, onde no processo POC, eles pensaram que aquele fornecedor atendia às suas necessidades, mas quando chegaram à escala de produção real, ele simplesmente não conseguiu lidar com isso.

E é aqui que eu acho que também há um grande benefício em aproveitar tecnologias de código aberto como o Trino, que foram comprovadas na maior escala imaginável, como se a Apple estivesse executando isso em uma escala insana, obviamente, em uma escala insana do Facebook. Então essas coisas podem funcionar. Funciona nessa escala. Isso deve lhe dar um pouco de paz de espírito. Mas mesmo assim, eu diria que simule você mesmo em seu próprio processo de benchmarking para realmente garantir que essas diferentes tecnologias atenderão às necessidades que você tem na produção. Legal.

E então a terceira peça que talvez acrescentarei é o custo. O custo também é muito importante, certo? Custo e desempenho são, na verdade, apenas duas faces da mesma moeda. E você também precisa levar isso em consideração no seu benchmarking, certo? Você não vai apenas escolher o mais rápido. Você deseja escolher o melhor desempenho de custo. E por isso também é uma parte importante do componente.

Dinesh Chandrasekhar:

Eu concordo. Acho que esse é um item importante da lista de verificação para muitas pessoas que estão avaliando soluções por aí, com certeza. Então, talvez vamos encerrar isso do ponto de vista das tendências. Só quero perguntar a você, há muita coisa acontecendo no espaço de dados hoje, certo? Portanto, existem fornecedores de data warehouse, fornecedores de lakehouse, fornecedores de data lake e várias alternativas, bancos de dados analíticos em tempo real e outros enfeites.

As opções são definitivamente amplas e confusas para o comprador. Então, do ponto de vista das tendências emergentes, você vê algum tipo de convergência acontecendo quando se trata de processamento de dados em tempo real, das arquiteturas de data lakehouse de que acabamos de falar e do ecossistema de código aberto em geral? Existe algum tipo de convergência que você vê acontecendo que vai deixar isso mais claro para o comprador em um futuro próximo?

Justin Borgman:

Eu sim. Acho que estamos começando a ver padrões muito populares surgindo, muitas vezes esses padrões se originam na Internet, em hiperescaladores e depois se traduzem na empresa ao longo do tempo. E acho que agora estamos no ponto em que isso está entrando na empresa. E os padrões que vejo aproveitam tecnologias como Kafka para a parte de streaming. E é claro que você tem várias opções lá. Você pode fazer o Confluent, você pode fazer a versão da Amazon. Você tem opções em todas essas plataformas de código aberto, o que é ótimo. Acho que o Iceberg com certeza, para o formato de armazenamento dos seus dados, me parece a aposta mais segura que você poderia fazer. E então, no lado do motor, novamente, encontrar o motor certo para o trabalho certo. Acho que se for SQL Analytics, diríamos que Trino e Starburst são a melhor aposta, mas você deveria provar isso para si mesmo.

Se você estiver treinando um modelo de aprendizado de máquina, provavelmente usará o Spark para isso. E esses são os padrões que vemos. Acredito que todas essas quatro tecnologias serão incrivelmente populares em arquiteturas de dados derivadas de código aberto nos próximos anos. E, novamente, o código aberto oferece flexibilidade para poder misturar e combinar componentes ao longo do tempo, o que fará com que sua arquitetura resista ao teste do tempo. E acho que isso é realmente o que você quer fazer:não criar uma dívida técnica que será muito difícil de substituir daqui a 10 anos. E o código aberto oferece essa flexibilidade.

Dinesh Chandrasekhar:

Adorei esse ponto. Obrigado. Acho que deveríamos encerrar isso com essa ótima nota. Justin, muito obrigado por se juntar a nós hoje. Acho que foi uma ótima conversa entendendo mais sobre Trino e Iceberg e como a Starbust oferece essa plataforma fantástica que combina o melhor dos dois mundos na sua plataforma. Muito obrigado e agradecemos por se juntar a nós.

Justin Borgman:

Obrigado, Dinesh. Foi um prazer.