Smart Talk Episodio 8:Cómo desbloquear información en tiempo real sobre Data Lakehouses

El lago de datos se ha convertido en un repositorio flexible y de usos múltiples. En este episodio de Smart Talk, Dinesh Chandrasekhar, director ejecutivo de Stratola, y su invitado, Justin Borgman, director ejecutivo y presidente de Starburst, analizan cómo ampliar las capacidades de un data lakehouse para incluir datos en tiempo real y consultas de alto rendimiento que puedan proporcionar información casi en tiempo real, un caso de uso cada vez más común. Se requieren dos tecnologías clave:Kafka Streams y un potente motor de consultas.

Especialmente interesantes son sus perspectivas sobre la importancia del software de código abierto y los formatos abiertos que han sido validados por Snowflake y Databricks al anunciar el soporte de Apache Iceberg. Justin comparte sus consejos para comparar soluciones:utilice los datos de su empresa, ejecute sus consultas reales, simule la escala y, finalmente, calcule los costos.

Los temas cubiertos incluyen:

• Kafka para transmitir datos en tiempo real a data lakehouses (4:22)
• Ventajas de los formatos abiertos (5:56)
• Función de soporte de SQL para GenAI (8:53)
• Copo de nieve, ladrillos de datos y iceberg (11:56)
• Estrategia de repositorio de datos flexible (17:21)

Invitado

Justin Borgman, director ejecutivo y presidente de Starburst

Justin Borgman es un experto en todo lo relacionado con big data y análisis. Antes de fundar Starburst, fue vicepresidente y director general de Teradata (NYSE:TDC), donde era responsable de la cartera de productos Hadoop de la empresa. Justin se unió a Teradata en 2014 mediante la adquisición de su empresa Hadapt, donde fue cofundador y director ejecutivo. Hadapt creó "SQL en Hadoop" convirtiendo Hadoop de un sistema de archivos a una base de datos analítica accesible mediante cualquier herramienta de BI. Fundó Starburst en 2017, buscando brindar a los analistas la libertad de analizar diversos conjuntos de datos dondequiera que se encuentren, sin comprometer el rendimiento. 

Anfitrión

Dinesh Chandrasekhar es un evangelista tecnológico, un líder intelectual y un analista experimentado de la industria de TI. Con cerca de 30 años de experiencia, Dinesh ha trabajado en software empresarial B2B, así como en productos SaaS, brindando y comercializando soluciones sofisticadas para clientes con arquitecturas complejas. También ha definido y ejecutado estrategias GTM de gran éxito para lanzar al mercado varios productos de alto crecimiento en varias empresas como LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM, etc. Es un prolífico orador, bloguero y programador de fin de semana. Dinesh tiene un MBA de la Universidad de Santa Clara y una maestría en Aplicaciones Informáticas de la Universidad de Madras. Actualmente, Dinesh dirige su propia empresa, Stratola, una firma de servicios completos de marketing y consultoría de estrategia empresarial centrada en el cliente.

Recursos

Smart Talk Episodio 7:Cardinalidad, control y costos en observabilidad

Smart Talk Episodio 6:AIOps y el futuro del monitoreo de TI

Smart Talk Episodio 5:Desglose de la pila de observabilidad

Smart Talk Episodio 4:Datos en tiempo real y bases de datos vectoriales

Smart Talk Episodio 3:Canalizaciones de datos modernas y LLM

Smart Talk Episodio 2:El auge de las aplicaciones GenAI con datos en movimiento

Smart Talk Episodio 1:El panorama del ecosistema de datos en movimiento

Vea el mapa del ecosistema de datos en movimiento aquí

Obtenga más información sobre datos en movimiento en RTInsights aquí

Transcripción

Dinesh Chandrasekhar:

Hola y bienvenido a este episodio de la serie Smart Talk at Data and Motion Leadership. Soy su anfitrión, Dinesh Chandrasekhar, analista jefe y fundador de Stratola. Nuestro invitado de hoy es Justin Borgman, director ejecutivo y presidente de Starburst. Justin ha tenido una carrera estelar en empresas de seguridad y análisis de datos, y antes de fundar Starburst en 2017, fundó una empresa llamada Had Adapt, que luego fue adquirida por Teradata, donde se desempeñó como vicepresidente y gerente general durante varios años. Bienvenido Justino. Y entonces comencemos con Starburst, ¿verdad? Creo que mucha gente conoce Starburst como marca, pero hay mucha gente que también está ansiosa por aprender un poco más sobre Starburst. Cuéntenos sobre Starburst, en particular sus orígenes y su impulso para iniciar la empresa.

Justin Borgman:

Sí, es un placer. Como mencionaste en la introducción, he estado en el espacio del análisis de datos durante unos 15 años, desde esa primera startup, que fue adquirida por Teradata. Por supuesto, como estoy seguro que su audiencia sabe, Teradata durante muchas décadas, francamente, fue el líder en análisis de almacenamiento de datos. Y ese modelo realmente requería mover todos sus datos a una base de datos patentada, que era el almacén de datos de su empresa. Y desde allí podrá ejecutar análisis rápidos y comprender su negocio. Creo que lo que vimos fue una oportunidad para básicamente darle la vuelta a ese modelo, particularmente de dos maneras. Número uno, la capacidad de aprovechar los formatos de tablas abiertas en un lago de datos, brindándole así rendimiento de almacenamiento de datos. Pero en un lago de datos, a veces la gente hoy en día llama a esto una arquitectura de casa de lago, además de poder llegar a otras fuentes de datos y unir tablas que viven en otra base de datos con tablas ubicadas en ese lago de datos.

Entonces, por ejemplo, es posible que tenga una base de datos Oracle o una base de datos SQL Server y desee unir una tabla en uno de esos sistemas con una tabla en un formato de archivo Iceberg en un lago de datos. Y eso es esencialmente lo que hace nuestra tecnología. Es la tecnología subyacente llamada Trino. Es un proyecto de código abierto. Nació originalmente de Facebook, y es así como muchas de las empresas de Internet más grandes, LinkedIn, Airbnb, Netflix, Apple, etc., realizan sus propios análisis de almacenamiento de datos. Nuevamente, en ese modelo donde el lago de datos es el repositorio central, pueden obtener un costo de propiedad muy bajo, almacenando datos en estos lagos de datos, además de poder unirse a otras tablas también. Y realmente Starburst es solo la comercialización de ese proyecto de código abierto. Proporcionamos una versión empresarial de Trino que tiene características de seguridad adicionales, conectores adicionales, beneficios de rendimiento adicionales y una gran cantidad de otras características y funcionalidades.

Dinesh Chandrasekhar:

Gracias. Y definitivamente quiero profundizar un poco más en Trino e Iceberg y todo eso. Creo que todos esos son grandes temas para hoy, pero ¿puedo dar un paso atrás un poco y preguntarle si observara la evolución de las arquitecturas de datos, tuvimos las bases de datos tradicionales y luego surgieron los almacenes de datos, y con la explosión de datos y la necesidad de procesar más datos en tiempo real, surgieron las arquitecturas lakehouse y otras? Entonces, en su mundo, si observa la evolución de las arquitecturas de datos, el lago de datos y, en su caso, creo que también tiene un concepto llamado Icehouse, ¿cómo ha impactado eso en la capacidad de las organizaciones para manejar datos en tiempo real de manera efectiva?

Justin Borgman:

Sí, gran pregunta. Y solo para aclarar a sus oyentes, el concepto de casa de hielo es en realidad solo una casa de lago basada en un Iceberg. Por lo tanto, los datos se almacenan en un formato de tabla iceberg y, además, se pueden realizar análisis de estilo de almacenamiento de datos. El resultado neto proporciona un costo total de propiedad realmente bajo, así como la capacidad de manejar datos casi en tiempo real como usted describió. Y la forma en que pensamos al respecto es que vemos un enorme aumento en la cantidad de tecnologías de transmisión de datos en el mercado como Kafka, por ejemplo, donde los clientes las utilizan cada vez más para transmitir datos casi en tiempo real a un lago de datos.

Y desde nuestro punto de vista, ahí es donde queremos retomarlo. Hemos creado algo que llamamos ingesta de transmisión en la que puede conectarse a una transmisión de Kafka y automáticamente la convertiremos en tablas Iceberg y las pondremos a disposición para consultas casi instantáneamente. Por lo tanto, esto permite que una empresa tenga ahora información mucho más actualizada sobre sus datos como resultado de esta arquitectura.

Dinesh Chandrasekhar:

Gracias. Por lo tanto, Lakehouse promete ser definitivamente un enfoque de arquitectura muy unificado para análisis por lotes y en tiempo real. ¿Podríamos decir eso? Quiero decir, ¿cómo ve este cambio arquitectónico que transforma la BI y la toma de decisiones tradicional en todas las industrias actuales? ¿Cómo ha cambiado eso?

Justin Borgman:

Sí, veo que esto cambia las cosas de manera bastante dramática. Creo que uno de los impulsores y uno de los beneficios de esta arquitectura es tan simple como la economía. Al final del día, esos almacenes de datos tradicionales podrían resultar muy costosos. En realidad, esa fue probablemente una de las quejas número uno durante mi tiempo en Teradata. Nadie dijo nunca que Teradata fuera una mala base de datos. En realidad, es un gran sistema de base de datos. Resulta que es extremadamente caro y una vez que estás dentro, estás dentro y estás comprometido.

Entonces, este lago de datos le permite una mayor flexibilidad porque utiliza formatos abiertos, lo que permite al cliente elegir cuál es el motor adecuado para acceder a mis datos. Le brinda mucha flexibilidad, reduce el bloqueo, pero también le permite almacenar sus datos en un almacenamiento básico realmente económico, que en el contexto de la nube es cada vez más el almacenamiento S3 o Google GCS o Azure Data Lake. E incluso en el mundo local, vemos almacenamiento de objetos compatible con S3 de compañías como Dell o IBM o lo que sea, donde básicamente se puede obtener S3. Entonces eso se convierte en una especie de capa base común para almacenar datos de manera muy, muy rentable, y eso es parte de lo que está impulsando esta transformación.

Dinesh Chandrasekhar:

Bien, entonces tal vez entremos ahora, ya que creo que es como el motor detrás de su oferta, ha ganado popularidad a lo largo de los años como un motor de consulta muy poderoso en el espacio de datos en tiempo real. ¿Cómo cree que evolucionará su papel en el ecosistema de datos moderno? Especialmente como usted mencionó, existen otras tecnologías de código abierto como Apache Iceberg, que también ofrecen mucha interoperabilidad entre diferentes sistemas de datos, etc. Entonces, ¿cómo se ha combinado esto con la combinación de algunas de estas otras tecnologías de código abierto cambiando el ecosistema de datos moderno?

Justin Borgman:

Creo que se está convirtiendo en una especie de Postgres del almacenamiento de datos. Postgres, por supuesto, es una base de datos de código abierto extremadamente popular y ampliamente implementada. Es un nodo único R-D-B-M-S tradicional. Trino es algo así como el equivalente de análisis de almacenamiento de datos de procesamiento masivo paralelo de MPP. Y así, para sus big data, para sus actividades de estilo de almacenamiento de datos, esto ahora se está convirtiendo en la opción de facto de código abierto.

Ahora a veces la gente pregunta, bueno, ¿qué pasa con Spark en comparación? Spark es un excelente motor de procesamiento de propósito general, pero no está realmente optimizado para análisis SQL. Y creo que, siguiendo su punto anterior sobre la inteligencia empresarial y la toma de decisiones, SQL sigue siendo el lenguaje de ese tipo de casos de uso, ya sea para conectar una herramienta de BI, ejecutar informes o incluso crear aplicaciones basadas en datos, SQL sigue siendo un lenguaje de interfaz realmente importante, y Trino es el motor número uno para eso en el mercado actual.

Cuando lo combinas con algo como Iceberg, como dijiste, ahora tienes esencialmente un almacén de datos completo. Tiene la parte del motor de consultas, tiene la parte de almacenamiento y ahora tiene un almacén de datos abierto completo. También pueden ejecutarse en cualquier lugar, pueden ejecutarse localmente o pueden ejecutarse en la nube. Así que tienes mucha flexibilidad con esa pila.

Dinesh Chandrasekhar:

¿Puedo hacerte una pequeña pregunta secundaria? Dado que usted mencionó SQL como una especie de opción para muchos de estos almacenes de datos en estos días, y creo que en los últimos 30 o 40 años, nada ha podido cambiar eso con seguridad, pero con el advenimiento de las tecnologías de inteligencia artificial de generación y el procesamiento del lenguaje natural en todas partes, la gente ahora puede hablar sobre la democratización de los datos y ahora se los distribuye incluso a los analistas de negocios que probablemente no tengan el mismo conocimiento, pero que pueden usar el lenguaje natural para decir, consíganme los últimos tres meses de ventas dentro de esta región en particular, etc. adelante.

E internamente, obviamente, lo traduce a SQL y luego consulta el motor o lo que sea, ¿verdad? ¿Ves entonces un cambio en eso también? ¿SQL prosperará y sobrevivirá, o habrá un cambio en la forma en que analizamos los datos de las consultas en el futuro?

Justin Borgman:

Esa es una gran pregunta y creo que has descubierto algo. Creo que, gradualmente, con el tiempo, creo que la IA generativa como interfaz se volverá muy popular porque, según tu punto, en cierto modo la simplifica para que cualquiera pueda usarla. Ahora es más una experiencia de Google con todos los datos de una empresa, y eso es muy emocionante. De hecho, hemos incorporado una versión inicial de eso en nuestro propio producto y creo que todos lo harán, se convertirá en algo en juego.

Sin embargo, creo que, detrás de escena, esas tecnologías en realidad simplemente convertirán ese lenguaje natural en una sintaxis SQL para que el motor realmente lo ejecute. Así que creo que el lenguaje seguirá siendo importante, pero puede convertirse más en un detalle de implementación detrás de una interfaz de estilo de lenguaje natural de IA generativa. Creo que estás en lo cierto. Me recuerda un poco a cuando se inventaron las calculadoras o incluso las calculadoras gráficas, de repente no necesitábamos saber todas las fórmulas ni exactamente cómo hacer divisiones largas porque nuestra calculadora se encargaba de eso. Creo que eso es lo que la IA generativa hará por nosotros aquí.

Dinesh Chandrasekhar:

Acceso más fácil a los datos, definitivamente, seguro. Creo que hacia allí nos dirigimos. Definitivamente es un espacio emocionante. Entonces hablamos de Trino. ¿Puedo cambiar de tema y preguntarte sobre Iceberg otra vez? Eso se está volviendo muy, muy popular. Veo que los gigantes más grandes de la industria están empezando a adoptar el iceberg como una forma muy natural de decir que somos interoperables, lo apoyamos, etc. Entonces, a medida que las organizaciones adoptan cada vez más análisis en tiempo real, ¿cuál es el papel del iceberg para permitir una gestión de datos más eficiente y escalable? ¿Cuál es tu opinión al respecto?

Justin Borgman:

Sí, creo que es un gran problema. Creo que es la historia más importante aparte de la IA de 2024. Y la razón por la que digo esto es que el formato existe desde hace algunos años, pero en realidad este año el mercado resolvió el debate sobre qué formato ganará. Hubo un breve período en el que había una especie de tres formatos populares en competencia, y la pregunta era ¿quién ganaría?

Nuestra apuesta siempre fue Iceberg, supongo que diría que predijimos que iría de esta manera, pero creo que el mercado realmente estuvo de acuerdo este verano cuando Snowflake y Databricks anunciaron sus propias intenciones de respaldarlo, y eso simplemente acabó con el debate como si Iceberg fuera el estándar de facto y lo que eso hace por los clientes, los clientes son los verdaderos ganadores en esto con diferencia. Y eso se debe a que ahora pueden almacenar los datos en un formato que les pertenece, que controlan, que les resulta portátil y que no está en manos de algún proveedor de bases de datos que los mantendrá como rehenes durante las próximas décadas.

Ellos son dueños de eso y eso significa que pueden enfrentarse entre sí. Pueden decir, está bien, Starburst hará esta carga de trabajo que me brindará el mejor rendimiento de costos para eso. Quizás Snowflake sea mejor para esta carga de trabajo. Quizás Databricks sea mejor para esa carga de trabajo y el cliente pueda elegir entre estos motores, lo cual es sorprendente. Cuando los motores compiten, ganas como cliente y creo que eso es realmente lo que Iceberg ofrece.

Dinesh Chandrasekhar:

Pero ese fue un gran resumen. Creo que eso dejó en claro la importancia del iceberg de cara al futuro a medida que las empresas se están estandarizando en un modelo en el que creo que todos son más interoperables y creo que beneficia al cliente, como usted dijo, sin tener que estar atado a un proveedor en particular, pero les permite ser un poco más abiertos y flexibles. Sin duda, ese es un gran punto.

Justin Borgman:

Exacto.

Dinesh Chandrasekhar:

Justin, ¿por qué no hablamos de un ejemplo de cliente aquí porque Trino e Iceberg son el centro de la conversación hoy? Cuéntanos quizás un estudio de caso de cliente en el que hayas visto esto en práctica y cuáles son los tipos de beneficios que han visto al adoptar Trino e Iceberg.

Justin Borgman:

Feliz de hacerlo. Hay una serie de ejemplos, tanto de empresas líderes de Internet como DoorDash, como de empresas más tradicionales como Comcast que existen desde hace mucho tiempo y que en ambos casos se están alejando de lo que yo llamaría plataformas de almacenamiento de datos tradicionales, trasladando cargas de trabajo para comenzar con plataformas de almacenamiento de datos tradicionales.

En el caso de Comcast, un almacén de datos local muy tradicional. En el caso de DoorDash, lo llamaría un almacén de datos en la nube muy tradicional. Y en cualquier caso, lo que están tratando de hacer en última instancia es mejorar el TCO en sus análisis SQL y brindar la flexibilidad para trabajar con las últimas tecnologías de vanguardia que pueden conectarse a partir de este formato común.

Nuevamente, a nuestro punto anterior, creo que lo que también están tratando de hacer, y esto se relaciona con el tema de la IA, es sentar las bases para implementar su arquitectura de datos donde ahora puedan tener fácil acceso a los datos que necesitan para entrenar sus propios modelos o realizar flujos de trabajo RAG en última instancia para respaldar sus propias ambiciones de IA. Y creo que muchas empresas están en esos primeros días averiguando qué puede hacer la IA por mí. ¿Cómo puede esto darme una ventaja competitiva?

Y mientras se dan cuenta de eso, una cosa que creo que todos tienen muy clara es que sus propios datos patentados serán fundamentales para brindarles una ventaja competitiva. Por lo tanto, configurar una infraestructura de datos que le brinde acceso a lo que necesita a un bajo costo y con un alto rendimiento es un paso fundamental en ese proceso.

Dinesh Chandrasekhar:

Entonces, como una forma de beneficio, ¿puedo hacer doble clic en eso y decirle o preguntarle con datos en tiempo real en particular? A menudo presenta desafíos como la evolución del esquema, cambios en el esquema a medida que cambian las fuentes, el objetivo necesita adaptarse, etc., y también el control de versiones de los datos. ¿Cómo ayuda Apache Iceberg a abordar algunos de estos desafíos en plataformas de datos modernas como ésta?

Justin Borgman:

Entonces existe el concepto de versionar y viajar en el tiempo y poder ver cómo han evolucionado los datos dentro de nuestra plataforma. También agregamos linaje de datos, métricas de calidad de datos que podemos capturar y presentar a nuestros usuarios para que realmente puedan comprender de dónde provienen esos datos, cómo han evolucionado, cómo se han iterado y, en última instancia, brindar esa visibilidad nuevamente al usuario final.

Dinesh Chandrasekhar:

Está bien. Luego, con Trino, habló sobre cómo se pueden combinar diversas fuentes de datos y realizar consultas conjuntas y todo eso. ¿La arquitectura se está moviendo más hacia una fuente de datos o un almacén de datos centralizados, o los mantiene donde están, pero brinda la capacidad de combinarlos y brindar visibilidad a los consumidores? ¿Cuál es la arquitectura estatal que estamos analizando aquí?

Justin Borgman:

Sí, gran pregunta. Hay elementos de ambos, y creo que eso es lo que siempre nos ha dificultado incluso articular nuestra propia propuesta de valor porque la gente está acostumbrada a un modelo y un estado de ánimo, que es centralizar todo en un almacén de datos tradicional o simplemente no tener acceso a él. Y creo que la forma en que vemos la evolución del mundo es que habrá un repositorio central que será, sin duda, un lago de datos, que almacenará la mayoría de los datos o la mayor cantidad de datos posible porque obtendrá beneficios económicos, obtendrá beneficios de rendimiento al almacenar tanto como pueda en formatos de iceberg en su lago. Creemos que es una excelente estrategia para muchos de sus datos, pero también creemos que siempre habrá casos de uso en los que querrá comunicarse con alguna otra fuente de datos.

Quizás sea un análisis exploratorio. Solo tengo una hipótesis que quiero probar y que creo que podría ser realmente importante para nuestro negocio, pero no quiero desarrollar todos los procesos de ETL y pasar por todo ese proceso solo por una idea, solo por una corazonada que tengo. Bueno, ese es un gran caso de uso en el que poder unirte a una mesa que vive en otro lugar con lo que tienes es un punto de inflexión. De hecho, podría permitirle dar fe de esa hipótesis en cuestión de minutos en lugar de semanas para lograr que los equipos muevan los datos de la manera que usted necesitaría. Por eso creo que ambos son valiosos, pero lo consideramos una mayoría en el lago y luego llegar más allá de ese lago es la forma en que lo pensamos.

Dinesh Chandrasekhar:

Entonces, si soy una empresa de terceros que, digamos, busca una plataforma de datos moderna, ¿cuáles son algunas de las consideraciones críticas de rendimiento que me gustaría tener en mi lista de verificación cuando analizo Trino frente a muchas otras alternativas? Entonces mi prioridad es, digamos, manejar consultas de datos en tiempo real, asegurarme de que haya baja latencia y cosas así. Entonces esos son mis requisitos. ¿Cuáles son algunas de las consideraciones que me gustaría tener en mi lista de verificación?

Justin Borgman:

Sí. Bueno, los dos principales consejos que daría son, el número uno, utilizar consultas reales que realmente utilices. Creo que es muy común que la gente utilice puntos de referencia de la industria, y eso está bien porque tal vez sea un paso muy superficial, pero no reflejará sus cargas de trabajo. Simplemente nunca lo es. Cada empresa tiene sus propias cosas que intenta hacer. Por eso siempre es mejor intentar simular el estado final lo mejor que puedas.

Y eso significa aprovechar sus propias consultas y sus propios datos mientras elabora su propia prueba de concepto y realiza evaluaciones comparativas. Nunca debes confiar exclusivamente en los puntos de referencia de otros proveedores. Incluso el nuestro. Los tenemos, puedes verlos, pero deberías probarlo tú mismo con tus propias consultas y tus propios datos.

Lo segundo que diría es también asegurarse de simular la escala y la escala es importante porque aquí es donde al menos encontramos algunas de nuestras propias oportunidades con los clientes para, digamos, reemplazar a un proveedor que compraron, donde en el proceso de POC, pensaron que ese proveedor satisfacía sus necesidades, pero cuando llegaron a la escala de producción real, simplemente no pudo manejarlo.

Y aquí es donde creo que también hay un gran beneficio al aprovechar tecnologías de código abierto como Trino, que han sido probadas a la escala más grande imaginable, como si Apple las estuviera ejecutando a una escala increíble, obviamente a una escala increíble de Facebook. Entonces esto puede funcionar. Funciona a esa escala. Eso debería darle algo de tranquilidad. Pero aun así, diría que lo simule usted mismo en su propio proceso de evaluación comparativa para garantizar realmente que estas diferentes tecnologías satisfagan las necesidades que tiene en producción. Fresco.

Y luego, la tercera pieza que tal vez agregaré es el costo. El costo también es muy importante, ¿verdad? El coste y el rendimiento son en realidad sólo dos caras de la misma moneda. Y también debes tener eso en cuenta en tu evaluación comparativa, ¿verdad? No vas a elegir simplemente el más rápido. Quiere elegir el mejor rendimiento de costes. Por eso también es una parte importante del componente.

Dinesh Chandrasekhar:

Estoy de acuerdo. Creo que ese es un elemento importante de la lista de verificación para muchas personas que seguramente están evaluando soluciones disponibles. Entonces, tal vez terminemos esto desde una perspectiva de tendencias. Solo quiero preguntarle, están sucediendo muchas cosas en el espacio de datos hoy en día, ¿verdad? Por lo tanto, existen proveedores de almacenes de datos, proveedores de lagos, proveedores de lagos de datos y varias alternativas, bases de datos de análisis en tiempo real y todo eso.

Las opciones son definitivamente amplias y confusas para el comprador. Entonces, desde la perspectiva de las tendencias emergentes, ¿ve algún tipo de convergencia en lo que respecta al procesamiento de datos en tiempo real, las arquitecturas de data lakehouse de las que acabamos de hablar y el ecosistema de código abierto en general? ¿Cree que se está produciendo algún tipo de convergencia que lo hará más claro para el comprador en un futuro próximo?

Justin Borgman:

Yo lo hago. Creo que estamos empezando a ver que surgen patrones muy populares, muy a menudo estos patrones se originan en Internet, en los hiperescaladores y luego se trasladan a la empresa con el tiempo. Y creo que ahora estamos en ese punto en el que se está abriendo camino en la empresa. Y los patrones que veo están aprovechando tecnologías como Kafka para la parte de transmisión. Y, por supuesto, tienes múltiples opciones allí. Puedes hacer Confluent, puedes hacer la versión de Amazon. Tienes opciones en todas estas plataformas de código abierto, lo cual es genial. Creo que Iceberg, por supuesto, para el formato para almacenar sus datos, me parece la apuesta más segura que podría hacer. Y luego, en el lado del motor, nuevamente, encontrar el motor adecuado para el trabajo correcto. Creo que si se trata de SQL Analytics, diríamos que Trino y Starburst son la mejor opción, pero deberías demostrártelo a ti mismo.

Si estás entrenando un modelo de aprendizaje automático, probablemente usarías Spark para eso. Y esos son los patrones que vemos. Creo que esas cuatro tecnologías serán increíblemente populares en las arquitecturas de datos derivados de código abierto en los próximos años. Y nuevamente, el código abierto le brinda esa flexibilidad para poder mezclar y combinar componentes a lo largo del tiempo, lo que hará que su arquitectura resista la prueba del tiempo. Y creo que eso es realmente lo que se quiere hacer, no crear deuda técnica que será muy difícil reemplazar dentro de 10 años. Y el código abierto le brinda esa flexibilidad.

Dinesh Chandrasekhar:

Me encanta ese punto. Gracias. Creo que deberíamos concluir esto con esa gran nota. Justin, muchas gracias por acompañarnos hoy. Creo que fue una gran conversación para comprender más sobre Trino e Iceberg y cómo Starbust ofrece esta fantástica plataforma que combina lo mejor de ambos mundos en su plataforma. Muchas gracias y apreciamos que te unas a nosotros.

Justin Borgman:

Gracias Dinesh. Fue un placer.