¿Sigue siendo útil la idea del "modern data stack"?

Artículo original ↗ Discusión en Hacker News ↗

Los proveedores y los practicantes de datos cuestionan cada vez más si el “modern data stack” —un conjunto poco definido de ETL en la nube, almacenes de datos, herramientas de transformación como dbt y plataformas de BI— alguna vez aportó suficiente valor como para justificar su costo y complejidad. Los comentaristas describen un ecosistema impulsado por el hype que empujó stacks fragmentados y muy cargados de SaaS a empresas que a menudo no tenían objetivos analíticos claros, buenas prácticas de ingeniería ni una contabilidad realista de costos, lo que llevó a muchos a reconsiderar plataformas integradas o soluciones a medida construidas por ingenieros con experiencia. El consenso emergente es que las decisiones de tooling deberían guiarse por necesidades de negocio concretas, escala y prácticas de observabilidad, y no por términos de marketing como “modern”, con algunos anticipando un giro hacia “analytics stacks” más simples y estrechamente integrados.

Utilidad de “Modern Data Stack” (MDS) como concepto

  • Muchos consideran que “MDS” es una palabra de moda que perdió significado una vez que fue apropiada por proveedores y VC.
  • Críticas: está mal definido, “modern” envejece rápidamente, resonó sobre todo con inversores y analistas, no con practicantes.
  • Algunos sostienen que la etiqueta ayudó al marketing y a los ecosistemas de partners, pero aportó poco valor descriptivo.

Enfoques con muchos proveedores vs enfoques integrados/a medida

  • Fuerte crítica a que el MDS multi‑proveedor creó complejidad innecesaria y gasto elevado (por ejemplo, múltiples herramientas solo para ejecutar pipelines simples).
  • La visión de que ahora las empresas prefieren plataformas integradas o construir in-house, especialmente al darse cuenta de que contratar a unos pocos ingenieros puede ser más barato que acumular muchos productos SaaS.
  • Contraargumento: el tooling modular de “elige tu stack” da flexibilidad, evita el lock-in y permite que los equipos adapten los componentes; los sistemas integrados “todo en uno” suelen ser torpes.
  • Consenso en que la respuesta correcta depende del contexto (tamaño de la empresa, habilidades, requisitos).

dbt y el stack de analítica

  • Ampliamente reconocido como un gran avance para organizar SQL: control de versiones, DAGs, tests, documentación, hooks de CI/CD.
  • También criticado por ser lento e incómodo frente a herramientas de dataframe, por carecer de un gran IDE local y por volverse difícil de gestionar a escala (cientos o más modelos).
  • Algunos ven dbt como más مناسب para transformaciones de “última milla”, no para el manejo desordenado de datos en bruto.

Prácticas de ingeniería de software vs ingeniería de datos

  • Muchos sostienen que el ámbito de datos va una década por detrás de la ingeniería de software estándar en CI/CD, pruebas, observabilidad y disciplina de despliegue.
  • Otros dicen que los problemas de fondo son en realidad los mismos que en SWE general: gestión de dependencias, cambios de contrato, monitorización y manejo de errores.
  • Un sector subraya retos específicos de los datos: los esquemas y distribuciones cambian sin cambios de código; el control de versiones no es la única puerta de entrada al comportamiento del sistema.

Recopilación de datos, costos y sobreinstrumentación

  • Debate entre “medirlo todo” y la recopilación guiada por hipótesis.
  • Algunos justifican la ingesta amplia cuando el almacenamiento y las exportaciones integradas son baratos y requieren poco esfuerzo.
  • Otros señalan costos ocultos: tiempo de ingeniería, mantenimiento de conectores, facturas de herramientas MDS y costo de oportunidad, argumentando que muchos pipelines existen sin preguntas de negocio claras ni ROI.

Cómo se ve en la práctica un stack “moderno”

  • Los stacks sugeridos van desde los pesados (Kafka, Flink, Iceberg, Spark/Ray, herramientas de metadatos) hasta los muy simples (BigQuery + dbt + BI básica; o incluso MySQL + file server + reporting simple).
  • Consejo común: mantenerlo tan simple como sea posible, ajustar las herramientas a necesidades concretas y evitar perseguir tendencias por currículum o hype.