Комментарии 13
Анонимизация понятно, уложилась в бесплатный кусок. А аналитика? Данные же хранятся не затем, чтобы удалять :)
Аналитика — это хорошо)
Но цель данной статьи — поделиться кейсом по анонимизации данных(GDPR) в BigQuery и рассказать об интересных инструментах в BQ, с которыми нам удалось поработать.
А аналитикой данных занимается другое подразделение.
Но цель данной статьи — поделиться кейсом по анонимизации данных(GDPR) в BigQuery и рассказать об интересных инструментах в BQ, с которыми нам удалось поработать.
А аналитикой данных занимается другое подразделение.
:) понятно, это было не совсем очевидно мне, моя кульпа.
А пробовали партицировать по customDimensions.index, чтобы запросы трогали только нужные данные? По идее должно хорошо срезать потребление и для выборки и для обновлений.
Схему данных, к сожалению, формируем не мы а google аналитика. Данные загружаются ежедневно и нам с ними приходится работать as is.
Подробнее про схему можно прочесть тут support.google.com/analytics/answer/3437719?hl=ru
Подробнее про схему можно прочесть тут support.google.com/analytics/answer/3437719?hl=ru
А еще вот это для меня было сюрпризом: cloud.google.com/bigquery/docs/creating-integer-range-partitions#limitations
«The partitioning column must be a top-level field. You cannot use a leaf field from a RECORD (STRUCT) as the partitioning column.»
то же самое с кластерингом:
cloud.google.com/bigquery/docs/creating-clustered-tables#limitations
«Clustering columns must be top-level, non-repeated columns of one of the following...»
надо почаще в документацию заглядывать :D
«The partitioning column must be a top-level field. You cannot use a leaf field from a RECORD (STRUCT) as the partitioning column.»
то же самое с кластерингом:
cloud.google.com/bigquery/docs/creating-clustered-tables#limitations
«Clustering columns must be top-level, non-repeated columns of one of the following...»
надо почаще в документацию заглядывать :D
Я работаю в БигКвири — статья хорошая, вот только мне не совсем понятно вот это:
Избегайте в таблицах полей с типами данных record, array (repeated record).
Запросы, в которых присутствуют данные столбцы, будут потреблять больше трафика, т. к. BigQuery придётся обработать все данные этого столбца.
БигКвири — columnar storage. Даже поля рекордов хранятся по отдельности, поэтому вычитывая одно поле из рекорда вы заплатите только за это поле. Это верно и для repeated records. Платить придется только за то leaf level поле, которое вы читаете. Даже если это поле находится внутри repeated of repeated record. Бигквири умеет вычитывать только это конкретное поле
БигКвири — columnar storage.
Да, на самом деле, так и есть, убрал из рекомендаций, спасибо за ваше замечание.
Как автору, очень приятно что на данную статью обратил внимание разрабочтик BQ и внес свои замечания!
Например, чтобы получить все данные за 1 и 5 января, можно выполнить следующий запрос:
select * from test_dataset.test_table_202001* where _TABLE_SUFFIX="01" and _TABLE_SUFFIX="05"
То ли я подустал, то ли запрос ничего не вернёт, и там бы and заменить на or…
Да, конечно же OR.
Спасибо за статью!
Расскажите подробнее как в BQ соотносятся вычислительные ресурсы и внешняя память:
1. Можно контролировать число слотов для моего ХД, например 5?
2. У каждого слота свой SSD и пользователь видит заполненность или для пользователя все данные одинаково доступны всем слотам в регионе?
3. Таблицы которые не входят на диск автоматически шардятся или пользователь должен сам задать настройки?
4. Когда при джойне больших таблиц данные пересылаются между слотами как пользователь может повлиять на оптимизацию запрос?
4.
Расскажите подробнее как в BQ соотносятся вычислительные ресурсы и внешняя память:
1. Можно контролировать число слотов для моего ХД, например 5?
2. У каждого слота свой SSD и пользователь видит заполненность или для пользователя все данные одинаково доступны всем слотам в регионе?
3. Таблицы которые не входят на диск автоматически шардятся или пользователь должен сам задать настройки?
4. Когда при джойне больших таблиц данные пересылаются между слотами как пользователь может повлиять на оптимизацию запрос?
4.
Немного описано в статье.
Вкратце: compute и storage полностью виртуализированы. Промежуточное представление (shuffle) тоже виртуализовано.
Каждый слот читает свой файл (или свою область файла), пишет результат в shuffle, потом другие слоты читают из шафла, обрабатывают пишут в другой шафл. В конце работы читают из последней стадии и пишут в финальный файл.
1. Что такое «ХД»? Для проектов при оплате по обработанным данным, доступно до 2000 слотов. Они заняты выполнением всех запросов одного проекта, если надо. Если покупать именно слоты, то они продаются пачками по 100 штук.
То есть если данных много, вполне могут все 2000 читать из 2000 разных файлов исходных таблиц одновременно. Если данных мало, то столько слотов получится занять, сколько есть файлов для стадии чтения данных, а дальше смотря как план запроса получится построить. БигКвери сам занимается оптимизацией хранилища подбирая оптимальное для итоговой времени работы запросов учитывая (много разных факторов). Кластеризация и партицирование дают подсказку как лучше нарезать, позволяя для селективных запросов не лазить в ненужные файлы, сокращая IO потребление пропуская ненужные файлы вообще.
2. Каждый слот это Compute ресурсы + квота на shuffle ресурсы. Заполненность не видно, но его «достаточно для любых практических применений» (ц) анек. Если не хватает, то либо что-то не то делается (например, вместо union — случайно сделали Cartesian product перечислив таблицы через запятую), и слава богу что не работает — либо придётся купить больше слотов. В теории можно собрать простой запрос который будет требовать дохренилиард шафла но при этом не требовать слотов — но это уже очень особый случай, который если действительно надо — то докупить слотов как решение.
3. Диск «бесконечен». Сотни петабайт вполне могут быть одной таблицей, и обработка будет достаточно быстрой и даже зачастую автоселективной — но всё же для таких размеров задать по какому полю партицировать и/или кластеризировать рекомендуется.
4. Любые запросы идут через промежуточное общее хранилище, BQ меняет план запроса на лету если требуется адаптируясь к тому что видит здесь и сейчас. Пользователь может переписать сам запрос, избавившись от ненужных джойнов например. В остальном, оптимизатор очень хороший (на мой вкус) и хорошо выворачивает очень много вещей в разные стороны, самостоятельно решая какая таблица будет использовать опорной, например. Самое эффективное что можно сделать — вместо точных функций использовать Approx варианты, где это допустимо. А так — если есть пример медленного запроса, тащите в студию — будем смотреть можно ли постучать где-нибудь молоточком :)
Вкратце: compute и storage полностью виртуализированы. Промежуточное представление (shuffle) тоже виртуализовано.
Каждый слот читает свой файл (или свою область файла), пишет результат в shuffle, потом другие слоты читают из шафла, обрабатывают пишут в другой шафл. В конце работы читают из последней стадии и пишут в финальный файл.
1. Что такое «ХД»? Для проектов при оплате по обработанным данным, доступно до 2000 слотов. Они заняты выполнением всех запросов одного проекта, если надо. Если покупать именно слоты, то они продаются пачками по 100 штук.
То есть если данных много, вполне могут все 2000 читать из 2000 разных файлов исходных таблиц одновременно. Если данных мало, то столько слотов получится занять, сколько есть файлов для стадии чтения данных, а дальше смотря как план запроса получится построить. БигКвери сам занимается оптимизацией хранилища подбирая оптимальное для итоговой времени работы запросов учитывая (много разных факторов). Кластеризация и партицирование дают подсказку как лучше нарезать, позволяя для селективных запросов не лазить в ненужные файлы, сокращая IO потребление пропуская ненужные файлы вообще.
2. Каждый слот это Compute ресурсы + квота на shuffle ресурсы. Заполненность не видно, но его «достаточно для любых практических применений» (ц) анек. Если не хватает, то либо что-то не то делается (например, вместо union — случайно сделали Cartesian product перечислив таблицы через запятую), и слава богу что не работает — либо придётся купить больше слотов. В теории можно собрать простой запрос который будет требовать дохренилиард шафла но при этом не требовать слотов — но это уже очень особый случай, который если действительно надо — то докупить слотов как решение.
3. Диск «бесконечен». Сотни петабайт вполне могут быть одной таблицей, и обработка будет достаточно быстрой и даже зачастую автоселективной — но всё же для таких размеров задать по какому полю партицировать и/или кластеризировать рекомендуется.
4. Любые запросы идут через промежуточное общее хранилище, BQ меняет план запроса на лету если требуется адаптируясь к тому что видит здесь и сейчас. Пользователь может переписать сам запрос, избавившись от ненужных джойнов например. В остальном, оптимизатор очень хороший (на мой вкус) и хорошо выворачивает очень много вещей в разные стороны, самостоятельно решая какая таблица будет использовать опорной, например. Самое эффективное что можно сделать — вместо точных функций использовать Approx варианты, где это допустимо. А так — если есть пример медленного запроса, тащите в студию — будем смотреть можно ли постучать где-нибудь молоточком :)
Спасибо за подробный ответ!
Я просто недавно прочитал «Google BigQuery. Всё о хранилищах данных, аналитике и машинном обучении», и там на мой взгляд, эти моменты были не раскрыты.
Я сам работаю на Greenpllum. Получается BigQuery радикально отличается от Greenpllum.
Я просто недавно прочитал «Google BigQuery. Всё о хранилищах данных, аналитике и машинном обучении», и там на мой взгляд, эти моменты были не раскрыты.
Я сам работаю на Greenpllum. Получается BigQuery радикально отличается от Greenpllum.
Я эту книгу не читал, проглядел только мельком; она (как мне показалось) больше на как пользоваться сосредоточена, а вопросы выше больше о том «как оно устроено». Тогда paper на который я сослался лучше опишет, а так же документы на которые он ссылается. В целом да, отличие от масштабированных классических БД массивное :)
Так ли это уж важно для использования — я не скажу, так я практически не пользователь…
Так ли это уж важно для использования — я не скажу, так я практически не пользователь…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с Google BigQuery. Считаем деньги