Herramientas y stack tecnológico del Data Analyst: la construcción honesta de 6 capas (con precios reales)

Me incorporé a una empresa en Serie B el año pasado y heredé un stack con tres BI tools, dos proveedores de reverse-ETL cuya contraseña nadie recordaba, un "catálogo de datos" con once entradas y una factura anual de $40 K que producía exactamente una captura de pantalla semanal en Slack. Solo la licencia de Looker era de $52 K. Looker renderizaba doce paneles de control. Dos de ellos se habían abierto en los 90 días anteriores. Uno de esos era el mío, comprobando si el panel de control seguía funcionando.

Ese es el momento en que aprendí lo que realmente significa "stack de datos moderno": una sopa de logos que los proveedores venden a analistas que todavía no se han visto obligados a defender las líneas de gasto. Si no puede dibujar su stack en una servilleta y justificar cada capa ante un CFO que nunca ha oído hablar de dbt, perderá el debate presupuestario, y el debate presupuestario está por llegar.

Aquí está la versión honesta. Seis capas. Precios reales. Los proveedores que eliminaría de la mayoría de los stacks. Y una auditoría de 30 días que puede ejecutar antes de firmar otra renovación.

Por qué esto importa ahora

Todos los CFO con los que hablo hacen la misma pregunta: "¿Por qué el gasto en herramientas de Analytics subió un 40% interanual cuando el headcount es plano?" La respuesta suele ser que alguien compró Snowflake cuando Postgres habría funcionado, otra persona compró Looker porque salió en una entrevista, y una tercera persona añadió Fivetran porque el antiguo ingeniero se fue y nadie quería mantener los scripts de Python.

Ninguna de esas decisiones estaba equivocada de forma aislada. El problema es que nadie es dueño del stack completo. El gasto en herramientas es la línea presupuestaria más fácil que puede cuestionar un CFO y la más fácil que un analista puede defender mal. Si su respuesta a "¿por qué tenemos esto?" es "porque la persona anterior lo configuró", ya perdió.

Los stacks defendibles tienen un rasgo en común: cada herramienta corresponde a exactamente una capa, y cada capa gana su lugar. Seis capas es suficiente.

Las 6 capas esenciales (todo lo demás es opcional)

1. Almacén de datos

Esta es la base. Elija mal y las tres capas siguientes le costarán 3 veces lo que deberían.

• Snowflake: basado en uso, aproximadamente $2-$4 por crédito según su edición y región. Brillante para cargas de trabajo fluctuantes y acceso SQL de todo el equipo. Fácil de gastar de más si no configura el auto-suspend del warehouse a 60 segundos y no obliga a todos a usar X-Small para el trabajo puntual. He visto una sola ejecución de dbt con un error quemar $800 en un fin de semana.
• BigQuery: pago por consulta a $6,25/TB escaneado (bajo demanda), o slots comprometidos si tiene una carga predecible. Ideal si su tráfico es genuinamente variable y no quiere gestionar el cómputo. El modelo de slots es confuso para los principiantes. Lea la documentación antes de comprometerse.
• Redshift: barato si se compromete con una instancia reservada, costoso si no lo hace. Las instancias reservadas comienzan en aproximadamente $0,25/nodo/hora y suben. El modelo de clúster parece anticuado frente a Snowflake/BigQuery, pero si su empresa ya está en AWS y su equipo de ingeniería lo conoce bien, es defendible.
• Postgres: sigue siendo la respuesta correcta por debajo de 1 TB. Deje de disculparse por ello. Una instancia de Postgres gestionada en RDS o Supabase cuesta entre $50 y $500 al mes y maneja todo lo que un equipo de analistas en etapa media consulta realmente. Nunca he visto una carga de trabajo de menos de 1 TB que justificara Snowflake. Ni una sola vez.

El árbol de decisiones: menos de 500 GB, Postgres. De 500 GB a 5 TB con carga variable, BigQuery o Snowflake. Más de 5 TB o muchos usuarios concurrentes, Snowflake. Más de 50 TB y tiene un equipo de Data Engineering, Redshift si se compromete.

2. ELT / ingesta

Cargar datos en el almacén. Aquí es donde muchos presupuestos de "stack moderno" explotan silenciosamente.

• Fivetran: entre $1 K y $10 K al mes según las Filas Activas Mensuales. Brillante cuando funciona. Caro cuando un conector falla y pasa dos días esperando soporte. Su modelo de precios (MAR) es suficientemente opaco como para que haya visto una factura de $1.200/mes saltar a $7.800 en un trimestre porque alguien habilitó una sincronización conversacional de Salesforce.
• Airbyte: código abierto, gratuito si lo aloja usted mismo. La versión Cloud comienza en aproximadamente $360/mes para volúmenes bajos. Alojar la solución en una pequeña instancia EC2 o GKE cuesta aproximadamente $200/mes en infraestructura. El intercambio: corregirá problemas a las 11 p.m. Lo he hecho. Está bien si tiene un buen ingeniero de datos o un Analytics Engineer fuerte. No pretenda que es "gratuito" si su equipo no puede operarlo.
• Stitch: nivel medio, en declive. Aceptable si ya lo tiene. No lo elegiría para una nueva implementación.

Mi opción por defecto: Fivetran para los 5-10 conectores principales que realmente importan (Salesforce, HubSpot, Stripe, NetSuite, réplicas de Postgres). Airbyte para la larga cola de APIs raras que a nadie más le importan. No use dos de estos a la vez para la misma fuente. Elija.

3. Transformación

Esta capa está definida. Es dbt. Deje de buscar alternativas.

• dbt Core: gratuito, código abierto. Se ejecuta en cualquier lugar donde pueda ejecutar Python. La mayoría de los equipos de analistas deberían empezar aquí.
• dbt Cloud: $50/desarrollador/mes para el nivel Team, $300/desarrollador/mes para Enterprise. Está pagando por el IDE, el programador, el alojamiento de documentación y la integración de CI. Vale la pena para equipos de 3 o más analistas sin un Data Engineer. Omítalo si tiene un DE dispuesto a conectar Airflow o Dagster. Ejecutar dbt Core en Airflow está bien, y Airflow en sí es gratuito.

La única alternativa legítima es SQLMesh, y solo si está en una escala donde los patrones de actualización completa de dbt son un problema. Para la mayoría de las implementaciones con menos de 100 modelos, no es su caso.

4. BI / paneles de control

La capa con más compras redundantes. La mayoría de los equipos tienen dos BI tools porque alguien se incorporó desde una empresa con Tableau y otra persona desde una empresa con Looker, y nadie los obligó a elegir.

• Looker: precios empresariales, las estimaciones públicas lo ubican en más de $50 K/año y subiendo rápido. La capa semántica (LookML) es la ventaja diferencial. Es el único BI tool donde la gobernanza realmente funciona a escala. No lo compre hasta que tenga una capa semántica real para construir y una persona para mantenerla. Comprar Looker sin un propietario de LookML es como comprar un Ferrari para conducirlo en su garaje.
• Tableau: $75/usuario/mes para Creator, $42 para Explorer, $15 para Viewer. Todavía los paneles de control más atractivos del mercado. Complicado para la gobernanza y el control de versiones. Bueno si su audiencia son ejecutivos que se preocupan por el acabado.
• Hex: entre $40 y $80/usuario/mes según el nivel. Notebooks más paneles de control en una sola aplicación. La opción correcta si sus analistas pasan la mitad del tiempo en exploración SQL y la otra mitad en informes para partes interesadas. Reemplaza la división "Jupyter para mí, Tableau para ellos".
• Metabase: código abierto, gratuito para alojar. Cloud Pro comienza en $85/mes para 5 usuarios. La respuesta correcta para Serie A y anteriores. Honestamente, la respuesta correcta para muchas Series B también. He visto a Metabase superar una licencia de Looker de $40 K en empresas que aún no tenían necesidades de capa semántica.

Mi regla: un solo BI tool. Si está por debajo de $10 M ARR, Metabase. Si tiene un propietario de LookML y ejecutivos que exigen gobernanza, Looker. Si sus analistas trabajan primero con notebooks, Hex. Tableau si la dirección lo pidió específicamente. Cualquier otra cosa es una renovación de la que se arrepentirá.

5. Notebook / exploración

Donde los analistas hacen realmente el pensamiento desordenado antes de que se convierta en un panel de control.

• Jupyter: gratuito, local, funciona siempre. El estándar. Combínelo con VS Code y está listo.
• Hex: ya en sus libros si lo compró para BI. Cubre dos capas con una sola herramienta. Esta es parte de la razón por la que los precios de Hex tienen sentido para algunos equipos.
• Deepnote: el nivel gratuito es generoso. Los planes de pago comienzan en $39/usuario/mes. Edición colaborativa sólida. Vale la pena si su equipo genuinamente coedita notebooks; menos convincente si todos trabajan solos.

Si compró Hex para BI, no añada Deepnote. Si no lo hizo, Jupyter está bien.

6. Tickets / admisión

La capa que la mayoría de los analistas no consideran como una capa. Lo es.

• Jira, Notion o Linear: elija uno. Lo que use el equipo de ingeniería suele estar bien. El punto no es la herramienta. El punto es eliminar el DM de Slack como canal de admisión.

Los DM de Slack como admisión de Analytics no producen cola, sin prioridad, sin trazabilidad y preguntas "rápidas" infinitas que tardan seis horas. Una herramienta de admisión real le da una cola, un SLA y un registro. Trátela como una herramienta.

Datos de CRM / ventas: la capa que la mayoría de los analistas subpresupuesta

Esta es la realidad que se habla poco: la mitad de los problemas de "calidad de datos" con los que luchan los analistas son problemas de higiene de CRM empujados hacia abajo. Cuando Ops pide "datos B2B limpios", la respuesta estándar es canalizar exportaciones de Salesforce a través de cuatro transformaciones de dbt para deduplicar contactos, normalizar nombres de empresas, corregir formatos de teléfono y completar los códigos de industria que faltan.

Eso no es Data Engineering. Es compensar un CRM que no aplicó higiene en el momento de escritura.

Rework comienza en $12/usuario/mes para CRM y Sales Ops y exporta datos limpios de contactos B2B y pipeline directamente a su almacén. La limpieza que de otro modo haría en dbt desaparece en su mayor parte porque los datos están estructurados en la admisión (campos obligatorios, formatos validados, deduplicación en escritura). He movido equipos de Salesforce más cuatro modelos de limpieza y he visto cómo el tiempo de compilación de dbt bajó de 22 minutos a 6 minutos.

Este no es un argumento de "Rework gana en todos los casos". Si ejecuta Salesforce en una organización de 500 personas con 12 administradores, no va a cambiar mañana. Pero si está en la etapa donde "deberíamos comprar Salesforce algún día" es el plan, haga los números con Rework primero. El ahorro se refleja en el recuento de modelos de dbt, no solo en el costo de la licencia.

La auditoría de 30 días del stack (haga esto antes de comprar cualquier cosa)

Todo analista debería ejecutar esto una vez al año. Se paga solo en la primera semana.

Días 1-3: inventario. Enumere cada herramienta, cada puesto, cada factura mensual. Extraiga el libro de cuentas por pagar. Encuentre el estado de la tarjeta de crédito. La mayoría de los equipos encuentran entre $10 K y $30 K al año en software sin usar en la primera semana. La cuenta de lector de Snowflake que nadie usa. El puesto de Tableau para el analista que se fue en noviembre. La suscripción a Census de cuando probó el reverse-ETL durante un trimestre.

Días 4-10: mapee. Asigne cada herramienta a una capa de las anteriores. Cualquier cosa que no se asigne recibe una entrevista de "¿por qué existe esto?" con quien sea el propietario del contrato. Si no pueden responder en dos oraciones, es candidata para la eliminación.

Días 11-20: encuentre los duplicados. Dos BI tools. Dos herramientas de ELT. Tres cosas que se llaman a sí mismas "catálogos de datos". Elija uno por capa. El duplicado es la eliminación.

Días 21-30: escriba la lista de eliminación. Cantidades en dólares concretas. Razones concretas. Preséntela al Head of Data con evidencia. Traiga el plan de migración alternativo, aunque sea solo "pasar a Metabase, aquí está el cronograma". Los jefes de datos odian las listas de eliminación vagas. Adoran las específicas con planes de reemplazo.

Diagrama del stack en una servilleta (el entregable para su CFO):

Sistemas fuente → ELT (Fivetran) → Almacén (Postgres o Snowflake) → dbt → BI (una sola herramienta) → Partes interesadas
                                          ↑
                                   CRM (Rework)
                                   canaliza datos
                                   limpios aquí
La admisión (Jira) gestiona la cola.

Si su servilleta necesita más cuadros que eso, está sobredimensionado.

La lista de eliminación (proveedores que sacaría de la mayoría de los stacks)

• Reverse-ETL cuando tiene 3 destinos. Hightouch y Census son productos reales, pero si canaliza datos a Salesforce y HubSpot y eso es todo, no necesita una herramienta de $24 K al año. Escriba un script de Python. Prográmelo en dbt Cloud o Airflow. Siga adelante.
• Catálogos de datos con menos de 50 tablas. Atlan, Alation y Collibra son excelentes a escala. Con menos de 50 tablas, una página de Notion los supera y no cuesta nada. Los catálogos solo ganan su lugar cuando nadie puede encontrar la tabla correcta sin uno.
• Cualquier herramienta "potenciada por AI" que envuelva GPT alrededor de un editor SQL. He evaluado cinco de estas. Todas generan SQL plausible que está mal en formas sutiles. Sus analistas pasarán más tiempo corrigiéndolo que escribiendo el SQL ellos mismos. Espere 18 meses.
• Herramientas de observabilidad con 12 modelos de dbt. Monte Carlo, Bigeye y Elementary tienen sentido a escala. Con 12 modelos, su "capa de observabilidad" es una suite de pruebas de dbt y una alerta en Slack. Eso es gratuito.

Errores comunes

Comprar Looker antes de tener una capa semántica. Veo esto cada trimestre. Un equipo compra Looker por la historia de gobernanza, luego se da cuenta de que nadie en el equipo sabe LookML, luego paga a un consultor $200/hora para construir la capa semántica. Dos años después todavía no lo están usando de la forma en que Looker lo concibió.

Elegir Snowflake para una carga de trabajo de 200 GB. Postgres maneja 200 GB en una instancia de RDS de $200/mes. Snowflake lo maneja por un mínimo de $2 K al mes una vez que tiene en cuenta el cómputo, el almacenamiento y los warehouses que la gente olvidó suspender. Si sus datos caben en la RAM de un servidor de $500, todavía no necesita un almacén en la nube.

Tratar dbt Cloud como obligatorio. No lo es. dbt Core más Airflow más un ejecutor gratuito de GitLab CI le da el 90% de dbt Cloud al 0% del costo. El 10% que pierde es el IDE y el sitio de documentación. Ambos son agradables. Ninguno es obligatorio.

Dejar que cada equipo compre su propia BI tool. Marketing compra Tableau. Sales compra Looker. Producto compra Hex. Ahora tiene tres capas semánticas, tres conjuntos de paneles de control que no coinciden y tres renovaciones que defender. Una sola BI tool. Negocie con firmeza. Haga que los equipos se adapten.

Medición del éxito

Ha terminado de auditar cuando:

• Puede nombrar cada línea del presupuesto de Analytics, cada precio mensual y cada capa que sirve.
• El gasto en herramientas por analista está referenciado contra el mercado. (Mi objetivo: $8 K-$15 K por analista por año para todo lo que está por debajo del almacén, más el cómputo del almacén. Si supera los $25 K por analista, algo está mal.)
• Nada en su stack existe "porque la persona anterior lo configuró."

Ese es el estándar. Seis capas, precios reales, defendibles ante un CFO que nunca ha oído hablar de dbt. Si puede escribir ese párrafo en frío, conservará el presupuesto. Si no puede, no lo conservará.

Más información

• Plantilla de descripción de puesto: Data Analyst
• Trayectoria profesional del Data Analyst
• KPIs y métricas del Data Analyst
• Construcción de un equipo de datos desde cero
• Precios de Rework CRM