Разбираем, какой SQL под капотом у Bigquery
В последние годы, IT-компании все чаще стремятся перенести свою инфраструктуру от традиционных on-premise решений в облако. Облачные сервисы от Amazon, Google, Microsoft и других произвели революцию в подходах к обработке и хранению данных. Они упростили доступ к данным, аналитике и вычислительной мощности. Они изменили наше представление о расходах, связанных с хранением данных и аналитикой. Экономия затрат, повышение производительности и оптимизация операций - все это весомые выгоды для бизнес-пользователей. Но давайте посмотрим, с чем вам придется столкнуться, если вы дата-инженер или дата-аналитик и ваш топ-менеджмент принял решение - “переезжаем в Bigquery! “
Bigquery - это облачное хранилище ваших данных (очень больших данных!), работающее по serverless технологии, позволяющее супер-быстро выполнять ваши SQL-запросы. В его основе - колоночное хранение, партиционирование и кластеризация. Рассмотрим поближе, чем отличается GBQ SQL от того, который мы привыкли встречать в традиционных СУБД.
Чувствительность к регистру - в отличие от большинства СУБД BigQuery чувствителен к регистру не только для служебных операторов, но и для имен объектов. Небольшим нюансом является то, что имена столбцов перечисленные в предложении FROM не являются чувствительными к регистру.
Полный путь до имен объектов - все имена объектов, упомянутые в предложении FROM, должны быть полностью уточнены либо до уровня набора данных, либо до имени проекта, если они взяты другого проекта (не вашего аккаунта) Все полное имя должно быть заключено в обратные одинарные кавычки (те, которые находятся на одной кнопке в тильдой ~). Можно провести много десятков минут громко ругаясь, и пытаясь понять почему ваш запрос содержит ошибку, пока не заметите эту тонкую грань между одиночной кавычкой(`) и апострофом(‘)
Standard SQL против Legacy SQL. По некоторым причинам в BigQuery есть две разновидности SQL. Standard SQL очень похож на ANSI SQL. Однако в классическом веб-интерфейсе BigQuery по умолчанию используется Legacy SQL. Вы можете переопределить, какой диалект вам использовать в самом начале запроса.
В GBQ Нет хранимых процедур или функций - это проблема и на самом деле нет простого способа обойти ее штатными средствами. Google предоставляет инструменты для выполнения ETL, преобразования и подготовки данных, но они не позволяют гибко кодировать собственные процедуры. Функции могут быть созданы, но они временные и существуют только для одного сеанса. Вы можете использовать такую вещь, как DBTool - отличный инструмент, который позволяет проводить гибкие трансформации с вашими датасетами.
Нет оценок плана выполнения запросов. Да, Google подскажет вам, сколько секунд (минут?) будет выполняться ваш запрос и сколько Kb/Gb он в итоге составит. Но вы не увидите его конечную стоимость в $$ (и да, Bigquery не бесплатен, после первого года использования). Проще говоря, невозможно определить, будет ли ваш сложный запрос выполняться эффективно, пока вы его не запустите.
Урезанный DDL - очень мало возможностей изменить таблицу, когда она существует. Вы не можете удалить столбец или изменить тип данных. Вы не можете переименовывать поля или таблицы. Практически любая операция изменения самой таблицы или представления включает операцию типа «CREATE TABLE AS SELECT», то есть технически вы получите «новую» таблицу или представление.
Было бы несправедливо остановиться на этом. Ведь у Bigquery есть и свои плюшки!
Сроки хранения объектов - это фишка для ленивых администраторов, у которых всегда есть 25 временных таблиц, покрытых пылью, где-то в уголке своей базы данных. В GBQ вы можете (и должны), создавая набор данных, указать короткий срок жизни объекта. Таким образом, у вас появляется своя песочница, которая самоочищается, и вам больше не нужно беспокоиться о дополнительных расходах на хранение данных, которые вам больше не нужны.
История запросов - GBQ, конечно же, регистрирует все запросы, которые вы выполняете (для выставления вам ежемесячных счетов на оплату), но также предоставляет их вам в виде легко доступного для поиска списка. Это может быть очень удобно, если вы когда-нибудь потеряете из виду часть кода, что иногда случается.
Кэшированные результаты запросов - GBQ взимает плату и за хранение данных и, в большинстве случаев, за их получение. В процессе работы мы можем периодически запускать один и тот же запрос по нескольку раз. Так вот, GBQ будет кэшировать эти результаты по умолчанию, и с вашего проекта не будет взиматься плата. При желании эту функцию можно отключить в настройках.
Автозаполнение -сейчас этим никого не удивишь, но я на всякий случай упомяну про это. GBQ предлагает автозаполнение имен таблиц и столбцов при написании запроса.
А по кнопке “Отправить запрос к таблице” в редакторе запросов сразу подставляется простейший SELECT запрос , который остается только подправить под ваши нужды.
Создание таблицы прямо из Web UI. Иногда вам просто нужно быстро создать небольшую табличку для хранения параметров или вам просто лень вбивать все эти VARCHAR(50) в запросе. GBQ позволяет пользователю быстро создавать таблицы и добавлять столбцы с различными типами данных минуя консоль.
Комментарии
Отправить комментарий