Кратко

  • Пробный запуск запроса к таблицам с защитой на уровне строк всегда возвращает ноль байтов, чтобы не раскрывать сведения о данных. Оценивать стоимость по этому результату нельзя.
  • Некоторые показатели остаются скрытыми и после выполнения. Замена пустых значений нулями способна исказить внутреннее распределение расходов.

В управленческой отчётности пустая клетка выглядит хуже нуля. Пустая клетка требует вопроса, ноль позволяет закончить презентацию. BigQuery даёт хороший повод не торопиться с этим удобным исправлением.

Для таблиц с защитой на уровне строк пробный запуск запроса — dry run — всегда возвращает ноль байтов. Так Google закрывает возможность делать выводы о защищённых данных по предполагаемому объёму обработки. В руководстве по выполнению запросов прямо сказано: на такую пробу нельзя полагаться при оценке стоимости.

Сама проба бесплатна и не занимает вычислительные слоты запросов. Настоящее выполнение затем подчиняется своей модели оплаты. Ноль отвечает за сохранность сведений, а не обещает бесплатную работу. Финансовый отдел может вставить его в бюджет, но сменить ему профессию этим не получится.

Расход не обязан быть виден тому, кто его создаёт

Защита строк позволяет нескольким пользователям работать с одной таблицей, показывая каждому лишь разрешённые записи. Однако содержание выдачи — не единственный источник информации. Объём обработки, длительность, ошибки и данные начислений тоже способны рассказать о скрытой части.

Поэтому рекомендации Google описывают целый набор закрываемых показателей: обработанные байты и разделы, оплачиваемые байты, этапы плана запроса. Завершение работы не отменяет это ограничение.

В представлении INFORMATION_SCHEMA.JOBS поля total_bytes_billed и total_bytes_processed пустуют для запросов, читающих таблицы с политиками доступа к строкам. Официальный пример оценки расходов отдельно считает задания, возможно затронутые такой защитой, но предупреждает, что их оплачиваемое потребление недоступно. Число закрытых конвертов ещё не сумма счетов внутри.

Представим внутренний отчёт, который перед суммированием заменяет все пропуски нулями и распределяет расходы между командами. Работа со скрытой статистикой в соответствующей части выпадет из расчёта. Команда станет выглядеть экономнее, хотя отчёт просто знает о ней меньше. Это условный пример, а место ошибки вполне определённое: превращение отсутствующей информации в нулевое потребление.

Система защиты при этом может работать безупречно. Ошибку внесёт компания, решившая, что аккуратная таблица важнее смысла её клеток.

Право сверить счёт — тоже право узнать данные

Обычно недостающий показатель пытаются получить у администратора. Документация BigQuery требует более точного разделения полномочий.

Владелец проекта может увидеть обработанные байты в соответствующих журналах аудита. Но скрытые метаданные начислений от этого не появляются в подробностях задания; специального разрешения или роли, открывающих их там, нет. В то же время роль Cloud Billing Viewer даёт доступ к информации о выставленных расходах.

Google рекомендует не предоставлять такой доступ пользователям, которым положено видеть только отфильтрованные строки. По стоимости тоже можно сделать выводы о чувствительных данных. Значит, лозунг «пусть каждый руководитель видит свой расход» нуждается в технически и организационно точном продолжении.

Кто уполномочен сверять общий счёт? Какие сведения он передаёт отдельным подразделениям? Кто объясняет расход, который не удаётся точно приписать конкретному заданию? На эти вопросы нельзя ответить одним расширением роли. Полезная обратная связь о бюджете и полный доступ к платёжным деталям — разные продукты для разных получателей.

Меньше видимых строк — ещё не меньше обработки

Есть и другая ловушка здравого смысла: если сотруднику доступна малая доля таблицы, счёт будто бы должен уменьшиться в той же пропорции. Правила BigQuery этого не обещают.

Google указывает, что фильтры политик доступа к строкам не участвуют в исключении ненужных разделов и блоков кластеризованных таблиц из обработки. Упоминание столбца разбиения в политике само по себе не даёт выгоды такого отсечения. Условия непосредственно в запросе — отдельный механизм.

Правило доступа ограничивает видимость, а не выдаёт скидку на обработку. Тарифная документация также различает оплату по объёму обработанных байтов и оплату вычислительной мощности и времени. Запрос к общим данным оплачивается через платёжный аккаунт проекта, который его выполняет. Само владение таблицей не делает её хозяина спонсором чужих вычислений.

Получается три границы: что разрешено увидеть, сколько требуется обработать и кто платит. Совпадение этих границ надо установить, а не нарисовать по привычке.

Рекомендации по контролю стоимости описывают суточные квоты и максимальное число оплачиваемых байтов на запрос для модели оплаты по потреблению. Изученные документы не раскрывают всех деталей взаимодействия этого максимума с оценкой, скрытой защитой строк; поведение конкретной нагрузки требует разрешённой проверки. Ноль в пробном запуске не доказывает ни автоматический обход лимита, ни полную защиту бюджета.

В данном исследовании нет клиентского счёта и записей внутреннего распределения, по которым можно было бы посчитать ущерб. Для суммы нужны эти документы. Для управленческого вывода достаточно установленного различия между неизвестным потреблением и отсутствием потребления.

Оставить пустое значение пустым — дешёвое начало. Дальше нужно назначить уполномоченного сверять расходы, объяснить правила распределения неразложимой части и дать командам полезные сведения в пределах их доступа. Защита вправе скрыть счётчик. Ответственный за него всё равно должен быть на месте.