Надеюсь, вы читаете эту статью до того, как увидели тысячи и тысячи долларов неясных затрат в вашем платежном аккаунте в BigQuery. Потому что у нас все было, к сожалению, наоборот. И началось все с необъяснимого феноменального скачка спенда... В конце статьи скажу, кто же в нашей команде отличился.
Можно с уверенностью отметить, что BigQuery представляет собой прекрасный инструмент для работы с данными. Она позволяет без специальных знаний и большой команды профессионалов наладить работу. При этом подсказки в поле написания SQL-запроса всегда помогут понять, что конкретно не так, сколько данных он потенциально может обработать и где вы могли допустить ошибку.
Эта база данных очень легка в освоении и абсолютно точно намного более user-friendly по сравнению с некоторыми другими инструментами для работы с данными. Тем не менее на другой чаше весов расположился и некоторый минус, а именно угроза того, что стоимость обработки выйдет за рамки ваших ожиданий. В особенности если у вас в команде появились некомпетентные специалисты, которые не понимают, как работать с BigQuery, и пишут запросы вида `SELECT * FROM table LIMIT 100` с обращением к главной таблице с сырыми событиями. Но это уже другая сторона вопроса...
BigQuery берет плату за объем обработанных во время запроса данных, а не за аренду некоего сервера или время обработки запроса. Тем не менее стоит обращать внимание не только на то, каков ваш SQL запрос, но и на оптимизацию того, как хранятся ваши данные: желательно, чтобы все ваши таблицы были партицированы.
Но все-таки как же грамотно контролировать свои расходы? Все довольно просто. С помощью BigQuery можно легко узнать, кто и когда создал определенный запрос, сколько именно данных этот запрос обработал, как он выглядел и какова была его примерная стоимость. То есть можно подглядывать вообще за всеми.
Есть два способа для того, чтобы это осуществить и начнем с того, что существует уже довольно давно. Для его реализации необходимо включить мониторинг трат в специальном разделе внутри Google Cloud Platform (советую делать это сразу при создании проекта).
Путь первый. Logging
Внутри блока Operations зайдите в раздел Logging, далее в Logs Router и нажмите там Create sink.
После нажатия 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`, вы сможете увидеть все операции, которые происходили с вашими данными и их стоимость. Например, вы можете отправить вот такой запрос:
Подробнее про этот способ можно почитать также в официальной справке Google Cloud Platform вот здесь - ссылка.
Путь второй. Техническая таблица
Есть и ещё один вариант, который появился относительно недавно - обратиться к сырой таблице INFORMATION_SCHEMA.JOBS . Эта таблица содержит данные о запросах за последние 180 дней и она скрыта. Но тем не менее, если знать о её существовании, с ней можно отлично работать. Важно: при обращении к этой таблице нужно включать регион обработки ваших данных и конечно же, у вас должно быть достаточно прав для того, чтобы работать с этой информацией: вы должны быть владельцем проекта или его администратором.
Пример запроса, который вы можете отправить к этой таблице выглядит следующим образом:
Или, например, вот как можно посмотреть объем обработанных данных в зависимости от пользователя - этот пример приводит у себя в инструкции GCP.
Более подробно про INFORMATION_SCHEMA.JOBS можно почитать в официальной справке Google Cloud вот здесь - ссылка.
В общем-то на этом и все. Следить за стоимостью запросов важно, как важно и иметь возможность выяснить причину резкого скачка в расходах, если у вас такое имело место быть.
Надеюсь, эта информация была для вас полезна и ваша работа с этой прекрасной базой данных будет становиться только лучше с каждым днем.
P.S. Не забывайте выставлять и ограничение спенда в вашем аккаунте дабы избежать всяких неприятных ситуаций. В нашем случае виновником всего оказался не человек, а Tableau, которое засбоило так, что отправило кучу запросов к данным за 15 минут. Если бы мы выставили ограничение по спенду с аккаунта до этого случая, то такого бы не случилось, но наш опыт, к сожалению, стоил неплохих денег.
Да ну нахер такое использовать...
Мало того, что облака это абсолютно ненадежно после 24 февраля,
так еще и любой залетевший дятел пустит по миру или остановит бизнес (в случае ограничения по спенду).
Только собственные серверы, реплицированные по нескольким локациям, только хардкор, только дух старой школы.
Правильно, а поднимать базы данных надо на серверах «эльбрус» с процессорами МЦСТ, а то поставки железа уже прекратились
А гугл будет подглядывать за вами и в один прекрасный день откажет в предоставлении сервиса, ну вот потому что может.
У моих знакомых есть пример того, когда потеряли месяц данных, хотя у компании был свой SDK и Clickhouse в качестве БД, но на арендованных серверах. Поэтому откажет не откажет но, к сожаланию, сломаться может все, что угодно и на любом участке.
Я не пытаюсь никого принуждать работать с этой БД, в статье инструкция скорее для тех, кто уже работает с BigQuery, но просто хочет грамотнее все контролировать.