Рекомендации

Следующие рекомендации помогут вам разработать запросы, ориентированные на конфиденциальность и высокую производительность. Рекомендации по выполнению запросов в режиме «шумового ввода» см. в разделах о поддерживаемых и неподдерживаемых шаблонах запросов в документе «Шумовое ввод» .

Конфиденциальность и точность данных

Разрабатывайте запросы к данным песочницы.

Рекомендация : запрашивайте данные из производственной среды только тогда, когда система находится в рабочем режиме.

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

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

Внимательно изучите исторические результаты.

Рекомендация : Снизьте вероятность пересечения наборов результатов между недавно выполненными запросами.

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

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

Не стоит подвергать сомнению сегодняшние данные.

Рекомендация : не выполняйте несколько запросов, где конечная дата совпадает с сегодняшней.

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

Не следует запрашивать одни и те же данные чаще, чем это необходимо.

Передовые методы :

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

Ads Data Hub ограничивает общее количество запросов к одним и тем же данным. Поэтому следует стараться ограничить количество обращений к определенному фрагменту данных.

Не используйте в одном запросе больше агрегаций, чем необходимо.

Передовые методы:

• Сведите к минимуму количество агрегаций в запросе.
• Перепишите запросы, чтобы по возможности объединять агрегированные данные.

Ads Data Hub ограничивает количество агрегаций между пользователями, разрешенных для использования в подзапросе, до 100. Поэтому в целом мы рекомендуем писать запросы, которые выводят больше строк с целевыми ключами группировки и простыми агрегациями, а не больше столбцов с широкими ключами группировки и сложными агрегациями. Следует избегать следующего шаблона:

SELECT
  COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
  COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
  table

Запросы, подсчитывающие события в зависимости от одного и того же набора полей, следует переписать с использованием оператора GROUP BY.

SELECT
  field_1,
  field_2,
  COUNT(1) AS cnt
FROM
  table
GROUP BY
  1, 2

В BigQuery результаты можно агрегировать аналогичным образом.

Запросы, которые создают столбцы из массива, а затем агрегируют их, следует переписать таким образом, чтобы объединить эти шаги.

SELECT
  COUNTIF(a_1) AS cnt_1,
  COUNTIF(a_2) AS cnt_2
FROM
  (SELECT
     1 IN UNNEST(field) AS a_1,
     2 IN UNNEST(field) AS a_2,
   FROM
     table)

Предыдущий запрос можно переписать следующим образом:

SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1

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

SELECT
  COUNTIF(field_1 = a_1) AS cnt_a_1,
  COUNTIF(field_1 = b_1) AS cnt_b_1,
  COUNTIF(field_2 = a_2) AS cnt_a_2,
  COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table

Предыдущий запрос можно разделить на следующие части:

SELECT
  field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1

и

SELECT
  field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1

Вы можете разбить эти результаты на отдельные запросы , создать и объединить таблицы в одном запросе или объединить их с помощью оператора UNION, если схемы совместимы.

Оптимизация и понимание соединений

Рекомендация : используйте LEFT JOIN вместо INNER JOIN для объединения кликов или конверсий с показами.

Не все показы связаны с кликами или конверсиями. Поэтому, если вы INNER JOIN для кликов или конверсий по показам, показы, не связанные с кликами или конверсиями, будут отфильтрованы из результатов.

Присоедините некоторые окончательные результаты в BigQuery

Рекомендация : Избегайте запросов к Ads Data Hub, объединяющих агрегированные результаты. Вместо этого напишите два отдельных запроса и объедините результаты в BigQuery.

Строки, не соответствующие требованиям агрегации, отфильтровываются из результатов. Поэтому, если ваш запрос объединяет недостаточно агрегированную строку с достаточно агрегированной строкой, результирующая строка будет отфильтрована. Кроме того, запросы с несколькими агрегациями работают с меньшей производительностью в Ads Data Hub.

В BigQuery можно объединять результаты нескольких агрегационных запросов (из Ads Data Hub). Результаты, вычисленные с помощью общих запросов, будут иметь общие итоговые схемы.

Следующий запрос берет отдельные результаты Ads Data Hub ( campaign_data_123 и campaign_data_456 ) и объединяет их в BigQuery:

SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)

Примечание: вы можете использовать таблицы с подстановочными знаками для запроса объединения нескольких таблиц с похожими именами в одном и том же наборе данных.

Используйте отфильтрованные сводки строк.

Рекомендация : добавляйте в запросы сводные данные по отфильтрованным строкам.

Сводные данные по отфильтрованным строкам суммируют данные, отфильтрованные в соответствии с требованиями конфиденциальности. Данные из отфильтрованных строк суммируются и добавляются в общую строку. Хотя отфильтрованные данные не подлежат дальнейшему анализу, они дают представление о том, какой объем данных был отфильтрован из результатов.

Примечание: Требования к агрегированию применяются к самим отфильтрованным сводным данным. Если результирующая отфильтрованная сводная информация не соответствует требованиям агрегирования, фильтрация будет производиться непосредственно к отфильтрованной сводной информации.

Учитывайте обнуленные идентификаторы пользователей.

Рекомендация : учитывайте обнуленные идентификаторы пользователей в результатах поиска.

Идентификатор конечного пользователя может быть установлен равным 0 по ряду причин, включая: отказ от персонализации рекламы , нормативные требования и т. д. Таким образом, данные, поступающие от нескольких пользователей, будут привязаны к user_id равному 0.

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

Вы можете исключить эти данные из результатов, добавив в свои запросы WHERE user_id != "0" .

Примечание: События с нулевыми идентификаторами пользователей учитываются как один пользователь в рамках минимального количества 50 пользователей в строке, независимо от того, сколько фактических пользователей создали эти события.

---

Производительность

Избегайте повторной агрегации

Рекомендация : Избегайте многоуровневой агрегации данных от разных пользователей.

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

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

Следует избегать следующих шаблонов:

SELECT SUM(count)
FROM
  (SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)

Запросы, использующие несколько уровней агрегации, следует переписать таким образом, чтобы они использовали один уровень агрегации.

(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )

Запросы, которые легко разбить на части, следует разбивать. В BigQuery можно объединять результаты.

Оптимизация для BigQuery

Как правило, запросы, выполняющие меньший объем работы, показывают лучшие результаты. При оценке производительности запросов объем необходимой работы зависит от следующих факторов:

• Входные данные и источники данных (ввод/вывод) : Сколько байтов считывает ваш запрос?
• Обмен данными между узлами (перетасовка) : Сколько байтов ваш запрос передает на следующий этап?
• Вычисления : Сколько вычислительной нагрузки требует ваш запрос?
• Выходные данные (материализация) : Сколько байтов записывает ваш запрос?
• Антипаттерны запросов : соответствуют ли ваши запросы передовым методам работы с SQL?

Если выполнение запросов не соответствует вашим соглашениям об уровне обслуживания или вы сталкиваетесь с ошибками из-за исчерпания ресурсов или превышения времени ожидания, рассмотрите следующие варианты:

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

Советник по запросам

Если ваш SQL-запрос корректен, но может вызвать проблемы с конфиденциальностью, советник по запросам предоставит полезные рекомендации в процессе его разработки, чтобы помочь вам избежать нежелательных результатов.

Для использования советника по запросам:

• UI . Рекомендации будут отображаться в редакторе запросов, над текстом запроса.
• API . Используйте метод customers.analysisQueries.validate .