Juego de ajedrez de datos: Databricks vs. Copo de nieve, parte 1

Junio ​​fue un buen mes para los estándares posteriores al cierre. Los eventos en vivo no solo regresaron con fuerza después de un par de años de interminables maratones de Zoom, sino que el comienzo del verano vio una confluencia de eventos del posiblemente trío más well-liked del mundo de los datos: en orden secuencial, MongoDB, copo de nieve y ladrillos de datos.

Puede haber diferencias marcadas y sutiles en cada una de sus trayectorias, pero el hilo común es que cada uno aspira a convertirse en la plataforma de datos en la nube empresarial (CDP) predeterminada de próxima generación. Y eso establece el próximo acto para los tres: cada uno de ellos tendrá que llegar más allá de sus principales grupos de interés para ampliar su atractivo empresarial.

Debido a que tenemos mucho que decir de nuestro informe de viaje de junio con el trío de datos destacados, vamos a dividir nuestro análisis en dos partes. Hoy nos centraremos en el juego de ajedrez entre Databricks y Snowflake. Mañana, en la parte 2, explicaremos por qué las tres empresas deben salir de sus zonas de confort si quieren convertirse en las plataformas de datos de referencia de próxima generación para la empresa.

El lago de datos establece la agenda

Notamos que con análisis y procesamiento de transacciones, respectivamente, MongoDB y Snowflake pueden eventualmente estar en un curso de colisión. Pero por ahora, se trata de la próxima batalla por corazones y mentes en análisis entre Databricks y Snowflake, y ahí es donde limitaremos nuestra discusión aquí.

El gran contexto es la convergencia de almacén de datos y lago de datos. Hace unos cinco años, Databricks acuñó el término «knowledge lakehouse», que posteriormente tocó un nervio. Casi todos en el mundo de los datos, desde Oráculo, teradata, nubera, talento, Google, HPE, cincotran, AWS, dremio e incluso copo de nieve han tenido que intervenir con sus respuestas. Databricks y Snowflake provienen de los mundos del lago de datos y el almacenamiento de datos, respectivamente, y ahora ambos se encuentran con la casa del lago. No son los únicos, pero podría decirse que ambos tienen las bases de crecimiento más rápido.

La casa del lago es simplemente el medio para llegar al fin tanto para Databricks como para Snowflake, ya que buscan convertirse en el destino de datos y análisis para la empresa.

Para simplificar demasiado, Snowflake invita a los Databricks a que se aglomeren con Snowpark, siempre que estén dispuestos a que sus rutinas de Java, Python o Scala ejecuten las funciones de SQL. La clave de Snowpark es que los científicos e ingenieros de datos no tienen que cambiar su código.

Mientras tanto, Databricks está invitando a Snowflake con un nuevo motor de consultas SQL que es mucho más funcional y eficaz que el Spark SQL unique. Irónicamente, en estas peleas, Spark está actualmente al margen: Snowpark (todavía) no es appropriate con la ejecución de Spark, mientras que el nuevo Databricks SQL, construido en el motor de consultas Photon, no usa Spark.

La pregunta capciosa para ambas empresas es cómo dibujar al programador de Python. Para Snowflake, la pregunta es si las funciones definidas por el usuario (UDF) son la ruta de mayor rendimiento, y aquí, la empresa está invirtiendo en Anaconda, que está optimizando sus bibliotecas para ejecutarse en Snowpark. Databricks enfrenta la misma pregunta, dado que Spark se escribió en Scala, que tradicionalmente ha tenido la ventaja de rendimiento. Pero con Python, las diferencias puede estar estrechándose. Creemos que Snowflake eventualmente agregará capacidad para la ejecución nativa en la base de datos de Python y quizás cargas de trabajo de Spark, pero eso requerirá una ingeniería significativa y no sucederá de la noche a la mañana.

Mientras tanto, Databricks está completando el knowledge lakehouse, ampliando las capacidades de su nuevo motor de consulta y agregando un catálogo de Unity como base para la gobernanza, con controles de acceso detallados, linaje de datos y auditoría, y aprovechando las integraciones de socios para políticas y gobernanza avanzadas. administración. andres brust proporcionó la inmersión profunda sobre las nuevas capacidades de lago delta y proyectos relacionados como Undertaking Lightspeed en su cobertura del evento Databricks el mes pasado.

¿Quién es más abierto? ¿Importa?

Databricks y Snowflake también difieren en código abierto. Este puede ser un concepto subjetivo, y no vamos a volver a examinar el debate.

Basta con decir que Databricks afirma que es mucho más abierto que Snowflake, dadas sus raíces en el proyecto Apache Spark. Apunta a empresas que ejecutan Presto, Trino, DIY Apache Spark o almacenes de datos comerciales directamente en Delta sin pagar Databricks. Y extiende el mismo argumento al intercambio de datos, como veremos a continuación. Para resolver el argumento sobre la apertura, Databricks anunció que las funciones restantes de Delta Lake ahora son de código abierto.

Mientras tanto, Snowflake no se disculpa por adherirse al modo propietario tradicional, ya que sostiene que es la forma más efectiva de hacer que su plataforma en la nube funcione. Pero las API de Snowpark están abiertas a todos los interesados, y si no desea almacenar datos en las tablas de Snowflake, acaba de abrir soporte para archivos de Parquet administrados por código abierto. iceberg apache como el formato de la tabla del lago de datos. Por supuesto, eso lleva a más debates sobre qué almacenamiento de tabla de lago de datos de código abierto es el más abierto: Delta Lake o Iceberg (OK, no olvide apache hudi). aquí está una opinión externaincluso si no es verdaderamente imparcial.

Databricks hace del código abierto una parte clave de su diferenciación. Pero excluyendo empresas como percona (lo que hace que su negocio brinde soporte para código abierto), es raro que una plataforma sea 100% de código abierto. Y para Databricks, características como sus notebooks y el motor Photon que impulsa Databricks SQL son estrictamente propietarias. Como si hubiera algo malo en eso.

Ahora el combate cuerpo a cuerpo

Los almacenes de datos son conocidos por ofrecer un rendimiento predecible, mientras que los lagos de datos son conocidos por su capacidad para escalar y admitir datos políglotas y la capacidad de ejecutar análisis exploratorios profundos y modelos complejos. El knowledge lakehouse, un concepto introducido por Databricks hace casi cinco años, pretende ofrecer lo mejor de ambos mundos y, para su crédito, el término ha sido adoptado por gran parte del resto de la industria. La pregunta operativa es, ¿pueden los knowledge lakehouses entregar los SLA consistentes producidos por los knowledge warehouses? Ese es el contexto detrás de la promoción de Databricks de Delta Lake, que agrega una estructura de tabla a los datos almacenados en archivos Parquet de código abierto.

Eso sentó las bases para los puntos de referencia de TPC-DS de Databricks el otoño pasadocual Andrew Brust puesto en perspectivay por supuesto, copo de nieve respondió. En la conferencia, el director ejecutivo de Databricks, Ali Ghodsi, actualizó los resultados. Viéndolo ensalzar el puntos de referencia competitivos vs. copo de nieve reavivó acogedores recuerdos de Larry Ellison descargando en Amazon Redshift con Autonomous Database. Por lo normal, tomamos puntos de referencia con granos de sal, por lo que no nos detendremos en números exactos aquí. Baste decir que Databricks reclama un rendimiento de precio superior al de Snowflake por órdenes de magnitud al acceder a los archivos de Parquet. Por supuesto, si esto refleja configuraciones representativas de las cargas de trabajo de BI es un tema que deben debatir los expertos.

Lo interesante es que Databricks demostró que no estaba ligado religiosamente a Spark. En realidad, aquí hay un hecho divertido: aprendimos que aproximadamente el 30 % de las cargas de trabajo que se ejecutan en Databricks no son Spark.

Por ejemplo, el recién estrenado fotón motor de consulta es una reescritura completa, en lugar de una mejora de Spark SQL. Aquí, Databricks reemplazó el código Java, las construcciones JVM y el motor de ejecución Spark con el C++ probado que usan todos los nombres conocidos. C++ es mucho más simplificado que Java y JVM y es mucho más eficiente en la gestión de la memoria. Lo viejo es nuevo otra vez.

Esta es un área donde Snowflake establece la agenda. Introdujo el concepto moderno de intercambio de datos en la nube hace aproximadamente cinco años con el datos de la casa de accionesque se basaba en organizaciones de línea interna que compartían acceso y análisis en el mismo cuerpo de datos sin tener que moverlo.

La thought fue beneficiosa para Snowflake porque proporcionó una manera de expandir su huella dentro de su base de clientes, y dado que la mayor parte de los ingresos de Snowflake provienen de la computación, no del almacenamiento, compartir más datos significa más uso y más computación. Posteriormente, los hiperescaladores se subieron al carro y agregaron conjuntos de datos a sus mercados.

Avance rápido hasta el presente y el intercambio de datos está detrás del giro de Snowflake del almacén de datos en la nube a la nube de datos. Específicamente, la nube de Snowflake debe ser el destino de análisis de su organización. El atractivo clave del uso compartido de datos de Snowflake es que, si los datos están dentro de la misma región de la misma nube, no es necesario moverlos ni replicarlos. En cambio, el intercambio de datos se trata de la concesión de permisos. La otra cara de la moneda es que el intercambio de datos internos y externos de Snowflake puede extenderse a través de regiones de la nube y diferentes nubes, ya que admite la replicación necesaria.

La última actualización de Snowflake Knowledge Market, que ahora se llama Snowflake Market, es que los proveedores de datos pueden monetizar sus datos y, en una nueva adición, sus UDF a través de un Marco de aplicación nativo, que certifica que esas rutinas se ejecutarán dentro de Snowpark. Pueden vender el acceso a los datos y las aplicaciones nativas que se encuentran en Snowflake sin tener que pagar ninguna comisión a Snowflake. La clave es que esto debe suceder dentro del jardín amurallado de Snowflake, ya que el mercado solo cubre datos y aplicaciones que residen en Snowflake.

El mes pasado, Databricks salió con su respuesta, anunciando la apertura de mercados de datos internos y externos. A diferencia de Snowflake, se ejecuta dentro de una sola región y nube, ya que el servicio Databricks actualmente no tiene funciones de replicación entre regiones o entre nubes. El mercado va más allá de los conjuntos de datos para incluir modelos, cuadernos y otros artefactos. Una de las características del mercado de Databricks es salas limpias de datosen el que los proveedores mantienen el management whole sobre qué partes pueden realizar qué análisis de sus datos sin exponer ningún dato confidencial, como la información de identificación private (PII), una capacidad que Snowflake ya tenía.

Hay varias diferencias básicas entre los mercados de Snowflake y Databricks, que reflejan la política y la etapa de desarrollo. La diferencia de política es sobre la monetización, una capacidad que Snowflake acaba de agregar mientras que Databricks se abstuvo deliberadamente. La opinión de Databricks es que los proveedores de datos probablemente no compartirán datos a través de transacciones de tarjetas de crédito no intermediadas, sino que se basarán en acuerdos directos entre proveedores y consumidores.

La política de transferencia de datos y artefactos de Databricks en su mercado se extiende a la tarifa de admisión, o más específicamente, a la falta de una. Databricks cube que los proveedores y consumidores en su mercado no tienen que ser suscriptores de Databricks.

Hasta hace poco, Databricks y Snowflake realmente no coincidían entre sí, ya que se dirigían a audiencias diferentes: Databricks se enfocaba en ingenieros de datos y científicos de datos que desarrollaban modelos y transformaciones de datos, trabajando a través de cuadernos, mientras que Snowflake atraía a analistas de negocios y datos a través de ETL y BI. herramientas de consulta, visualización y generación de informes. Este es otro caso de la gran escala de cómputo y almacenamiento en la nube que erosiona las barreras tecnológicas entre los lagos de datos y el almacenamiento de datos y, con ello, las barreras entre los diferentes grupos.

Mañana veremos el otro lado de la ecuación. Databricks y Snowflake se están transformando en destinos de datos, al igual que MongoDB. Cada una de ellas es una empresa de bases de datos de gran crecimiento y cada una tendrá que aventurarse fuera de su zona de confort para llegar allí.

Manténganse al tanto.

Esta es la primera de una serie de dos partes. La publicación de mañana describirá los próximos movimientos que deben tomar Databricks, MongoDB y Snowflake para atraer a la empresa en normal.