Del tablero financiero al trabajo técnico
Capital One Software anunció este 21 de septiembre de 2026 la disponibilidad general de Data Explorer y Query Details en Slingshot, su herramienta para investigar costes y rendimiento de cargas de datos en Snowflake. Según el anuncio de la compañía, las funciones permiten recorrer el gasto desde una visión agregada hasta el detalle de las consultas.
Data Explorer reúne el gasto de distintas cuentas de Snowflake y permite desglosarlo por recursos, consultas, usuarios y etiquetas. Puede integrar hasta dos años de historial de costes y aplica controles de acceso por roles, de acuerdo con la información publicada por Capital One Software.
Query Details, por su parte, agrupa ejecuciones mediante Parameterized Query Hashes y presenta tiempos P50 y P90, bytes escaneados, espera en cola y desbordamientos a disco. La lectura editorial es operativa: esa visibilidad puede servir para convertir una desviación presupuestaria en una investigación técnica concreta, pero no equivale por sí sola a una reducción del gasto.
La unidad de análisis importa tanto como el total
Para conectar FinOps con ingeniería de datos, conviene formular una pregunta más precisa que «¿cuánto gastamos?»: qué trabajo produjo ese consumo, quién puede modificarlo y qué nivel de servicio debe preservar. La propuesta es tratar cada oportunidad de optimización como una tarea con responsable, hipótesis y evidencia de resultado.
La documentación de Snowflake explica que los hashes parametrizados permiten agrupar consultas con una estructura equivalente aunque cambien determinados valores literales. Esto ofrece una base para estudiar patrones recurrentes en lugar de depender únicamente de ejecuciones aisladas. ([docs.snowflake.com](https://docs.snowflake.com/en/user-guide/query-hash?utm_source=openai))
Para la gestión, sería útil comparar cada familia de consultas consigo misma en periodos equivalentes. El coste total debería leerse junto con el número de ejecuciones y el volumen de trabajo: una subida de consumo merece investigación, no una conclusión automática de ineficiencia.
Cinco indicadores para llevar al trabajo diario
Cobertura de atribución. Medir qué proporción del gasto analizado tiene equipo, producto de datos y entorno identificados. La recomendación es registrar también el consumo sin asignar y acordar quién lo revisa. Una etiqueta debería facilitar una decisión, no limitarse a completar un campo.
Coste por unidad de trabajo. Elegir un denominador útil para cada proceso, como una ejecución satisfactoria o un lote procesado, y mantener explícito el alcance del coste. Acompañarlo del volumen total ayudaría a distinguir crecimiento de actividad de posibles pérdidas de eficiencia.
Rendimiento por familia de consultas. Revisar conjuntamente P50 y P90, sin convertirlos en una clasificación entre procesos con objetivos diferentes. Para cada cambio, convendría fijar de antemano qué evolución del tiempo de respuesta sería aceptable.
Señales técnicas para investigar. Utilizar bytes escaneados, espera en cola y desbordamientos como preguntas de diagnóstico, no como órdenes automáticas de ampliar o reducir recursos. Snowflake incluye el análisis de colas y la agrupación de consultas entre sus prácticas de evaluación del rendimiento. ([snowflake.com](https://www.snowflake.com/en/developers/guides/well-architected-framework-performance/?utm_source=openai))
Resultado de las intervenciones. Registrar el consumo y el rendimiento antes y después de cada ajuste, bajo condiciones comparables. La propuesta es cerrar una tarea de optimización solo cuando exista evidencia del resultado y se haya comprobado que el servicio sigue cumpliendo su objetivo.
El coste atribuido a consultas no es toda la factura
Existe una precaución metodológica relevante. En Snowflake, la vista QUERY_ATTRIBUTION_HISTORY atribuye créditos de cómputo a la ejecución de consultas, pero excluye el tiempo ocioso del almacén de cómputo. Sumar esos créditos no debe confundirse con reconstruir todo el consumo de ese recurso. ([docs.snowflake.com](https://docs.snowflake.com/en/en/sql-reference/account-usage/query_attribution_history?utm_source=openai))
Por eso, cualquier tablero interno debería declarar qué incluye cada indicador y mantener separado el consumo atribuido del que requiere otro criterio de reparto. Esta limitación documentada por Snowflake no permite deducir cómo Slingshot resuelve cada componente: ese alcance debe verificarse antes de utilizar sus datos para imputaciones internas.
Una revisión compartida, no una tabla de culpables
La propuesta para los equipos es incorporar una revisión periódica entre plataforma, ingeniería y responsables de producto: seleccionar una desviación, identificar las consultas asociadas, acordar una intervención y comprobar su efecto. También convendría revisar quién necesita acceder al detalle y con qué finalidad.
El anuncio aporta nuevas funciones de observación. El valor para la organización dependerá de cómo se incorporen al trabajo: no se trata de exigir que toda consulta cueste menos, sino de justificar su consumo, preservar el servicio y demostrar qué mejoras merecen repetirse.