Как выбрать между представлениями или запланированными запросами для дедупликации таблиц BigQuery, импортированных через Stitch?

Question

Я создаю статистические данные, генерируемые по запросу, из данных, хранящихся в таблицах BigQuery. Некоторые данные импортируются ежедневно с помощью стежка с использованием "Только добавление". Это приводит к дублированию наблюдений в импортированных таблицах (около 20 тыс. Строк растут на 8 тыс. Ежегодно).

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

• затраты на BigQuery на хранение / выполнение запланированных запросов и представлений.
• скорость последующих запросов зависит от дедуплицированных представлений. Кешируются ли просмотры?

Правильно ли я предполагаю, что ежедневные запланированные запросы для хранения дедуплицированных данных более затратны (для перезаписи сохраненных таблиц), но ускоряют последующие запросы к дедуплицированным данным (экономия затрат на использование)?

Дедуплицированные данные, в свою очередь, будут запрашиваться сотни раз в день, чтобы получить вывод панели мониторинга, для которого важна скорость реагирования.

Как мне спорить, выбирая лучшее решение?

Answer 1

Перейдем к фактам:

1. Цена, которую вы заплатите в запросе, одинакова независимо от того, используете ли вы просмотр или запланированный запрос.
2. При использовании запланированного запроса вам нужно будет заплатить за данные, которые вы храните в дедуплицированной таблице. Поскольку View не хранит никаких данных, с вас не будет взиматься дополнительная плата.
3. С точки зрения скорости выигрывает подход с использованием запланированного запроса, потому что ваши данные уже удалены и очищены. Если вы собираетесь снабжать панели мониторинга этими данными, подход View может привести к лени при загрузке панели мониторинга.
4. Другой возможный подход - использование материализованных представлений, которые представляют собой более умные представления, которые периодически кэшируют результаты для повышения производительности. В этом руководстве вы можете найти некоторую информацию о выборе между запланированными запросами и материализованными представлениями:

Когда мне следует использовать запланированные запросы, а не материализованные представления?

Запланированные запросы - удобный способ периодически выполнять произвольно сложные вычисления. Каждый раз, когда запрос выполняется, он выполняется полностью. Предыдущие результаты не используются, и вы оплачиваете полную стоимость запроса. Запланированные запросы отлично подходят, когда вам не нужны самые свежие данные и вы хорошо переносите их устаревание.

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

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

Answer 2

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

Для фактора скорости - определенно лучше запрашивать сокращенную таблицу напрямую, а не представление.Что касается фактора стоимости , я бы попытался понять, как часто будет запрашиваться это представление/таблица и каковы затраты на обработку и хранение:

1. Для представления: приблизительно рассчитайте затраты на обработку * количество раз, которое будет запрашиваться ежемесячно, например
2. Для хранимой таблицы: запланированные запросы, выполняемые в месяц * затраты на обработку + ежемесячные затраты на хранение результатов таблицы.

Это должно дать вам практически все аргументы в пользу вашего решения.