Resumen

  • Las simulaciones sobre tablas protegidas por seguridad a nivel de fila devuelven siempre cero bytes para evitar filtraciones. Ese resultado no sirve para estimar el coste de la consulta.
  • Algunas estadísticas de facturación también quedan ocultas después de ejecutar el trabajo. Sustituir sus valores vacíos por cero falsea la distribución interna del gasto.

Hay un modo estupendo de ganar una competición de ahorro: que el marcador no pueda ver lo que gastamos. Es una mala política financiera, pero un panel de costes puede producirla sin que nadie se proponga hacer trampas.

BigQuery ofrece un caso concreto. Cuando una tabla está protegida mediante seguridad a nivel de fila, la simulación de una consulta devuelve cero bytes. Google ha elegido ese comportamiento para impedir que alguien deduzca información protegida a partir del volumen de datos que procesaría la consulta. El cero cumple una función de confidencialidad.

La documentación de ejecución deja claro que esa simulación no permite estimar de forma fiable el coste. La simulación es gratuita y no consume ranuras de ejecución; ejecutar después la consulta es otra operación, sometida al modelo de precios correspondiente. El cero no es una oferta comercial. Es una cortina.

El consumo desaparece del campo, no de la responsabilidad

La seguridad por filas permite compartir una tabla y limitar los registros que ve cada usuario. Pero la información sensible también deja rastros fuera del resultado: volumen procesado, tiempo de ejecución, errores o datos de facturación.

Por eso, las recomendaciones de Google describen otras estadísticas que BigQuery oculta en consultas sobre estas tablas: bytes y particiones procesados, bytes facturados y etapas del plan de consulta. Haber terminado el trabajo no abre automáticamente esos datos.

En INFORMATION_SCHEMA.JOBS, los campos total_bytes_billed y total_bytes_processed quedan vacíos para consultas que leen tablas con políticas de acceso por filas. La documentación de JOBS incluye un ejemplo de estimación que cuenta los trabajos posiblemente afectados y reconoce que no puede acceder a su consumo facturable. El número de sobres cerrados no revela cuánto suman las cuentas que contienen.

Supongamos que una empresa calcula el coste por equipo y convierte cada valor ausente en cero. Los trabajos con estadísticas ocultas abaratan artificialmente el total atribuido al equipo que los ejecutó. El cuadro puede cuadrar consigo mismo y, aun así, contar una historia falsa. Es un ejemplo hipotético; el error está en transformar desconocimiento en consumo nulo.

La política de seguridad puede haber funcionado perfectamente. La política de incentivos acaba de dar un premio a la opacidad.

Finanzas también necesita una frontera de acceso

Pedir un usuario con más permisos parece la salida obvia. No todas las puertas llevan al mismo sitio.

Según Google, quien tiene el rol de propietario del proyecto puede ver bytes procesados en los registros de auditoría asociados. Eso no hace aparecer los metadatos de facturación ocultos en los detalles del trabajo, ni existe un permiso o rol específico que los desbloquee allí. Por otra vía, Cloud Billing Viewer permite consultar información de facturación.

Precisamente por ello Google recomienda evitar ese acceso para usuarios que solo deban ver filas filtradas. Los costes pueden revelar información sensible. Dar a cada responsable de negocio una factura detallada para que controle su presupuesto puede ampliar, al mismo tiempo, lo que sabe sobre los datos protegidos.

La empresa tiene que elegir quién está autorizado a conciliar la cuenta completa y qué información puede devolver a cada equipo. Una cifra agregada con un propósito concreto, un criterio de reparto y una explicación pueden ser más útiles que un panel muy detallado concedido a la persona equivocada. El trabajo de diseñar ese retorno forma parte del servicio, aunque no aparezca como una línea del precio por consulta.

Ver pocas filas no compra una consulta pequeña

La intuición comercial añade otra trampa: si solo puedo ver una fracción de los registros, debería pagar una fracción equivalente. Las reglas del producto no ofrecen esa proporcionalidad.

Google explica que los filtros de las políticas de acceso por filas no participan en la poda de particiones ni de bloques de tablas agrupadas. Incluir una columna de partición en esa política no aporta por sí mismo el ahorro de dicha poda. Los filtros de la consulta son un mecanismo distinto. El permiso decide lo que se puede ver; no constituye una tabla de descuentos.

La página de precios de BigQuery distingue además la modalidad bajo demanda, basada en bytes procesados, de la modalidad por capacidad de cálculo. Y al consultar datos compartidos, paga el proyecto que ejecuta la consulta mediante su cuenta de facturación asociada. Ser propietario de los datos, poder verlos y pagar por procesarlos son papeles separados.

Las prácticas de control de costes incluyen cuotas diarias y un máximo de bytes facturados por consulta para el modelo bajo demanda. Los documentos consultados no detallan toda la interacción entre ese máximo y la estimación ocultada por la seguridad por filas; hay que comprobar el comportamiento del caso concreto con la autorización adecuada. El cero no prueba que el límite vaya a dejar pasar todo ni que vaya a resolver el presupuesto.

No contamos aquí con una factura de cliente ni con su contabilidad interna para medir pérdidas: hacen falta esos registros. Sí contamos con una separación inequívoca entre información disponible y gasto real. Convertir la primera en el segundo mediante un relleno de ceros es una decisión de la empresa, no una propiedad económica de BigQuery.

Un presupuesto útil conserva el hueco y le asigna un responsable. Alguien autorizado concilia las cifras; alguien acepta el criterio aplicado a costes que no pueden repartirse con precisión; los equipos reciben información suficiente para decidir dentro de sus límites de acceso. La confidencialidad puede ocultar el contador. No debería dejar vacía la silla de quien responde por él.