Как узнать, кто потратил $1000 за 15 минут или почему важно иметь мониторинг трат в Google BigQuery

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

Как узнать, кто потратил $1000 за 15 минут или почему важно иметь мониторинг трат в Google BigQuery

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

Эта база данных очень легка в освоении и абсолютно точно намного более user-friendly по сравнению с некоторыми другими инструментами для работы с данными. Тем не менее на другой чаше весов расположился и некоторый минус, а именно угроза того, что стоимость обработки выйдет за рамки ваших ожиданий. В особенности если у вас в команде появились некомпетентные специалисты, которые не понимают, как работать с BigQuery, и пишут запросы вида `SELECT * FROM table LIMIT 100` с обращением к главной таблице с сырыми событиями. Но это уже другая сторона вопроса...

BigQuery берет плату за объем обработанных во время запроса данных, а не за аренду некоего сервера или время обработки запроса. Тем не менее стоит обращать внимание не только на то, каков ваш SQL запрос, но и на оптимизацию того, как хранятся ваши данные: желательно, чтобы все ваши таблицы были партицированы.

Но все-таки как же грамотно контролировать свои расходы? Все довольно просто. С помощью BigQuery можно легко узнать, кто и когда создал определенный запрос, сколько именно данных этот запрос обработал, как он выглядел и какова была его примерная стоимость. То есть можно подглядывать вообще за всеми.

Есть два способа для того, чтобы это осуществить и начнем с того, что существует уже довольно давно. Для его реализации необходимо включить мониторинг трат в специальном разделе внутри Google Cloud Platform (советую делать это сразу при создании проекта).

Путь первый. Logging

Внутри блока Operations зайдите в раздел Logging, далее в Logs Router и нажмите там Create sink.

Рис. 1. Раздел Logs Router
Рис. 1. Раздел Logs Router

После нажатия Create sink откроется специальное окно, где вам нужно будет заполнить некоторые поля.

Рис. 2. Блок Create Sink
Рис. 2. Блок Create Sink

Придумайте какое-нибудь название (на примере выше это GCP_logs). В разделе Sink destination в Select service выбрите BigQuery Dataset и далее bigquery.googleapis.com/projects/YOUR-PROJECT/datasets/GCP_logs . Скорее всего вы ещё не создавали такого датасета для логов, поэтому создаете его прямо здесь и можете тоже назвать GCP_logs. Обязательно поставьте галочку на Use partitioned tables.

В разделе Choose logs to include in sink напишите protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.BigQueryAuditMetadata".

После того, как вы проделали все эти шаги, у вас уже начнет появляться некоторая информация в датасете, который вы создали для этих целей. Системе нужно некоторое время, чтобы начать его заполнять, поэтому не ожидайте секундного результата. Тем не менее теперь обращаясь к таблице `ваш-проект/ваш-датасет/cloudaudit_googleapis_com_data_access`, вы сможете увидеть все операции, которые происходили с вашими данными и их стоимость. Например, вы можете отправить вот такой запрос:

SELECT TIMESTAMP_TRUNC(TIMESTAMP(JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobChange.job.jobStats.endTime")), DAY) AS day, protopayload_auditlog.authenticationInfo.principalEmail as email, FORMAT('%9.2f',5.0 * (SUM(CAST(JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobChange.job.jobStats.queryStats.totalBilledBytes") AS INT64))/POWER(2, 40))) AS usd_cost FROM `YOUR PROJECT.YOUT DATASET.cloudaudit_googleapis_com_data_access` WHERE JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobChange.job.jobConfig.type") = "QUERY" GROUP BY 1,2

Подробнее про этот способ можно почитать также в официальной справке Google Cloud Platform вот здесь - ссылка.

Путь второй. Техническая таблица

Есть и ещё один вариант, который появился относительно недавно - обратиться к сырой таблице INFORMATION_SCHEMA.JOBS . Эта таблица содержит данные о запросах за последние 180 дней и она скрыта. Но тем не менее, если знать о её существовании, с ней можно отлично работать. Важно: при обращении к этой таблице нужно включать регион обработки ваших данных и конечно же, у вас должно быть достаточно прав для того, чтобы работать с этой информацией: вы должны быть владельцем проекта или его администратором.

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

SELECT * FROM `ВАШ ПРОЕКТ`.`region-ВАШ РЕГИОН ОБРАБОТКИ (чаще всего это us)`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP() AND job_type = "QUERY" AND end_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()

Или, например, вот как можно посмотреть объем обработанных данных в зависимости от пользователя - этот пример приводит у себя в инструкции GCP.

SELECT user_email, SUM(total_bytes_billed) AS bytes_billed FROM `ВАШ ПРОЕКТ`.`region-ВАШ РЕГИОН ОБРАБОТКИ (чаще всего это us)`.INFORMATION_SCHEMA.JOBS WHERE job_type = 'QUERY' AND statement_type != 'SCRIPT' GROUP BY user_email;

Более подробно про INFORMATION_SCHEMA.JOBS можно почитать в официальной справке Google Cloud вот здесь - ссылка.

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

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

P.S. Не забывайте выставлять и ограничение спенда в вашем аккаунте дабы избежать всяких неприятных ситуаций. В нашем случае виновником всего оказался не человек, а Tableau, которое засбоило так, что отправило кучу запросов к данным за 15 минут. Если бы мы выставили ограничение по спенду с аккаунта до этого случая, то такого бы не случилось, но наш опыт, к сожалению, стоил неплохих денег.

11
4 комментария

Да ну нахер такое использовать...

Мало того, что облака это абсолютно ненадежно после 24 февраля,
так еще и любой залетевший дятел пустит по миру или остановит бизнес (в случае ограничения по спенду).

Только собственные серверы, реплицированные по нескольким локациям, только хардкор, только дух старой школы.

2
Ответить

Правильно, а поднимать базы данных надо на серверах «эльбрус» с процессорами МЦСТ, а то поставки железа уже прекратились

1
Ответить

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

Ответить

У моих знакомых есть пример того, когда потеряли месяц данных, хотя у компании был свой SDK и Clickhouse в качестве БД, но на арендованных серверах. Поэтому откажет не откажет но, к сожаланию, сломаться может все, что угодно и на любом участке.

Я не пытаюсь никого принуждать работать с этой БД, в статье инструкция скорее для тех, кто уже работает с BigQuery, но просто хочет грамотнее все контролировать.

Ответить