Elegir plataforma analítica por la restricción que aprieta

Todos los proveedores de este espacio presentan la misma diapositiva: una plataforma para analítica, aprendizaje automático y streaming, con gobernanza incluida. Las diapositivas son indistinguibles, lo que te dice que la diferenciación ya no está en la lista de funcionalidades.

Lo que sí difiere es el modelo de coste, la frontera de gobernanza y la carga en la que cada plataforma es genuinamente buena. Y por debajo de todo eso ha cambiado algo estructural que importa más que la elección de proveedor.

Los formatos de tabla abiertos cambiaron la negociación

Históricamente, cargar datos en un almacén significaba cargarlos en el almacenamiento propietario de ese almacén. Irse significaba exportarlo todo, que es por lo que las migraciones eran raras y el poder de fijar precios estaba del lado del proveedor.

Los formatos de tabla abiertos, principalmente Iceberg y Delta Lake, ponen semántica de tabla sobre ficheros en tu propio almacenamiento de objetos. Obtienes lo que hacía que valiera la pena usar un almacén, transacciones, evolución de esquema, viaje en el tiempo y actualizaciones eficientes, sobre datos que controlas, en un formato que pueden leer varios motores.

La consecuencia es que el almacenamiento y el cómputo se vuelven genuinamente separables. Tu dato está en tu cubo, y el motor de consulta es una elección que puedes revisar. Todas las plataformas grandes admiten ya leer y cada vez más escribir estos formatos, unas de forma más completa que otras, y la interoperabilidad entre ellas está mejorando y todavía no es del todo fluida.

El consejo práctico: aterriza tus datos en un formato abierto en tu propio almacenamiento por defecto, y trata el motor como reemplazable. Esa única decisión preserva una opcionalidad que vale más que cualquier comparación de funcionalidades, y es el mismo instinto que conservar la exportación nativa de facturación junto a una normalizada en FOCUS y comparar dos nubes.

Qué diferencia de verdad a las opciones

Snowflake es un almacén ante todo, y su fuerza es que es genuinamente fácil de operar. El cómputo se separa en almacenes que dimensionas y que se suspenden cuando están ociosos, así que la concurrencia entre equipos es una configuración en vez de un ejercicio de ajuste. Encaja con analítica centrada en SQL con muchos usuarios de negocio simultáneos. El modelo de coste son créditos por segundo de cómputo, que es comprensible y se pone caro cuando un almacén se queda encendido o se dimensiona con generosidad.

Databricks creció desde Spark y es una plataforma de procesamiento que añadió un almacén. Su fuerza es el trabajo heterogéneo: transformación a gran escala, aprendizaje automático, streaming y analítica en un sitio, con los cuadernos como interfaz de primer nivel. Encaja con equipos que hacen ingeniería y ciencia de datos y no solo informes. El modelo de coste es cómputo más un cargo de plataforma por unidad de trabajo, y la configuración del clúster es una palanca que hay que usar de verdad.

Los almacenes nativos de cada nube son la opción que los equipos infravaloran. Si estás en una sola nube, el almacén nativo se integra con la identidad, la red, la facturación y el resto de la plataforma sin proveedor adicional. Su modelo de coste suele ser por byte escaneado o por ranura, lo que es excelente cuando las consultas están bien escritas y particionadas, y es el origen de los fallos de coste más espectaculares cuando no lo están, como se describe en facturas de BigQuery que se triplican.

Los motores de consulta sobre tu propio almacenamiento, como Trino o DuckDB a escalas menores, merecen conocerse. Son una respuesta legítima para un equipo que quiere SQL sobre formatos abiertos sin un contrato de plataforma.

El modelo de coste es aquello con lo que vas a convivir

Todas las plataformas son asequibles usadas con cuidado y caras si no, pero fallan de formas distintas, y conocer el modo de fallo es más útil que comparar precios de catálogo.

Por byte escaneado falla por tablas sin particionar y por seleccionar todas las columnas en un panel que se refresca cada minuto. Los controles son particionado, agrupamiento, filtros obligatorios y límites por consulta.

Por segundo de cómputo falla por almacenes ociosos y clústeres sobredimensionados. Los controles son autosuspensión con tiempo corto, almacenes dimensionados por carga, y separar la carga de paneles de la de transformación para que una no obligue a escalar a la otra.

Por unidad de trabajo falla por trabajos ineficientes que corren más de lo que deberían, lo que es un problema de ajuste y no de configuración.

En los tres casos, el mayor motor de coste individual suele ser el mismo y se discute poco: paneles que se refrescan más a menudo de lo que alguien los mira, y modelos de transformación que se reconstruyen más a menudo de lo que cambia el dato. Arregla la programación antes de ajustar el motor, que es el punto de orquestación y transformación.

Elijas lo que elijas, atribuye el coste a los equipos desde el principio. Todas las plataformas admiten etiquetar consultas o separar el cómputo por equipo, y sin eso tienes una única línea grande que no es de nadie, que es el problema de el número que importa es el coste por cliente.

La gobernanza es donde vive la atadura de verdad

El catálogo, el modelo de control de acceso y el linaje son más difíciles de mover que los datos.

Haz preguntas concretas en vez de aceptar la diapositiva de gobernanza. ¿Puedes aplicar acceso a nivel de fila y de columna para los grupos que tienes de verdad? ¿El control de acceso aplica cuando otro motor lee los mismos ficheros, o solo dentro de esta plataforma? ¿El linaje se captura automáticamente o depende de usar sus herramientas de transformación? ¿Dónde viven los metadatos, y puedes sacarlos?

Para compradores europeos, añade las preguntas de residencia y acceso: dónde corre el plano de control, quién puede acceder al dato durante el soporte, y si el acuerdo encaja con el análisis de transferencias de dónde vive tu dato de verdad. Esto decide la lista corta más a menudo que el rendimiento.

Analítica y aprendizaje automático son cargas distintas

Sé honesto con la mezcla, porque apunta a respuestas distintas.

Sobre todo informes en SQL con muchos usuarios de negocio favorece un almacén, donde dominan la concurrencia y la facilidad de uso y la flexibilidad de Spark es gasto que pagas.

Transformación pesada, datos semiestructurados, streaming y entrenamiento de modelos favorece una plataforma de procesamiento, donde un almacén te obliga a añadir un segundo sistema igualmente.

Las dos cosas, a escala es lo que los proveedores dicen resolver, y cada vez lo hacen más, con la salvedad honesta de que cada uno sigue siendo mejor en su origen. Ejecutar la carga de almacén en una plataforma optimizada para procesamiento, o al revés, es donde los equipos acaban pagando capacidad que no usan.

Un patrón común y sensato: formato de tabla abierto en almacenamiento de objetos, un motor de procesamiento para la transformación y el aprendizaje automático, y un motor de almacén para la capa de servicio que consultan los analistas. Dos motores, una copia del dato, lo cual solo es posible por la decisión de formato del principio de este artículo.

Lo que se olvida

• Los ficheros pequeños destruyen el rendimiento. La ingesta en streaming produce miles de ficheros diminutos y el tiempo de consulta se desploma. La compactación es un trabajo de mantenimiento que hay que programar.
• El viaje en el tiempo es almacenamiento. Retener versiones antiguas para revertir es genuinamente útil y cuesta dinero. Fija la retención a conciencia.
• La capa semántica es una decisión real. Dónde se definen las métricas determina si dos paneles coinciden.
• La salida de datos al irse. Una migración significa mover un volumen grande, y el coste de transferencia es un número real.
• Los límites de concurrencia muerden a fin de trimestre. Todo el mundo lanza el mismo informe el mismo día.
• Prueba de concepto con tus datos, no con los suyos. Los bancos de pruebas de los proveedores usan consultas elegidas para lucir. Lanza tus diez consultas reales más caras.

Qué hacer esta semana

Coge tu factura analítica actual y divídela en tres cubos: transformación programada, refresco de paneles y consultas puntuales de personas. Casi ningún equipo ha hecho nunca ese reparto, y normalmente muestra que una parte grande del gasto son paneles refrescándose con una frecuencia que nadie eligió. Ese hallazgo es independiente de la plataforma en la que estés, y arreglarlo es más barato que migrar. Producimos ese desglose en la fase de costes de un proyecto cloud.