Разделение не работает нормально в Google BigQuery, когда SQL Query содержит подзапрос - PullRequest
0 голосов
/ 03 сентября 2018

У меня есть следующая структура таблицы в большом запросе

**query_all_partition**
property_unique_date    DATE    REQUIRED    
page_url    STRING  REQUIRED    
click   INTEGER REQUIRED    
impression  INTEGER REQUIRED    
position    FLOAT   REQUIRED    

Здесь я указал разбиение на property_unique_date

**property_data**

fetch_date  DATE    REQUIRED    
property_url    STRING  REQUIRED    
property_unique_date    DATE    REQUIRED

Позвольте мне дать вам краткую справку

Я хотел получить данные поисковой аналитики Google для разных веб-сайтов (например, клики, показы на определенном веб-сайте или перенаправление на эти веб-сайты на основе некоторых ключевых слов и т. Д.)

Раньше у меня была одна таблица со следующими полями, а разбиение было в fetch_date

  • fetch_date
  • property_url
  • PAGE_URL
  • нажмите
  • впечатление
  • положение

Итак, когда я делал запросы на основе fetch_dates, то есть между двумя датами, обработка запросов происходила только для требуемых данных, и это учитывало снижение затрат. Однако такой подход был бы подходящим, если мы храним только данные для одного веб-сайта или URL-адреса свойства. Когда я начал хранить данные для другого свойства, даже запрашивая одно из свойств и определенный диапазон дат выборки, он обрабатывал данные для всех свойств в указанном диапазоне дат, что приводило к большой обработке данных и затратам, поскольку разделение не может быть выполнено для поля, отличные от даты / времени.

Итак, я предложил подход, в котором я создал две таблицы

  • query_all_partition
  • property_data

Итак, я начал хранить дату для комбинации property_url и fetch_date. Как я дал диапазон от 1971-01-01 до 1980-12-31 для хранения данных, скажем, для свойства P1. Так, скажем, я храню данные для каждого из данных для P1 с января 2018 года, это будет

fetch_date  property_url   property_unique_date
2018-01-01   P1               1971-01-01
2018-01-02   P1               1971-01-02
2018-01-01   P2               1981-01-01
2018-01-02   P2               1981-01-02

При таком подходе я могу хранить как минимум 10 лет данных для каждого свойства. В разделе query_partition_all я начал хранить property_unique_date вместо fetch_date и property_url

Теперь для тестирования я сохранил данные за 1 месяц для двух свойств. P1 - очень большое свойство, P2 - очень маленькое свойство. Хранение данных за июль 2018 года как для объекта с уникальной датой свойства, назначенной для P1 с 1971-01-01 по 1971-01-31 как июль, составляет 31 день, так и для P2 с 1981-01-01 по 1981-01-31. *

Запустил приведенные ниже запросы и прикрепил снимки к тому же

Два свойства - P1 (крупная собственность) (с 1971-01-01 по 1971-01-31) - P2 (небольшая собственность) (с 1981-01-01 по 1981-01-31)

Я запустил следующие запросы

select page_url, sum(click) as click,sum(impression) as impression from `searchanalytics.query_all_partition` where property_unique_date BETWEEN ('1971-01-01') and ('1971-01-31') group by page_url

Изображение с property_unique_dates, жестко запрограммированным для свойства P1. Пожалуйста, смотрите данные обрабатываются.

select page_url, sum(click) as click,sum(impression) as impression from `searchanalytics.query_all_partition` where property_unique_date BETWEEN ('1981-01-01') and ('1981-01-31') group by page_url

Изображение с property_unique_dates жестко запрограммировано для свойства P2. Пожалуйста, смотрите данные обрабатываются. Это маленький, так что пока здесь все в порядке

Проблема возникает, когда вместо жестко заданных уникальных дат свойства я начинаю извлекать его из подзапроса (запрос из таблицы propertydata). Пожалуйста, смотрите запрос и данные, обработанные как часть 3-го и 4-го изображений. ниже приведены вопросы. Обработанные данные являются полными данными

select page_url, sum(click) as click,sum(impression) as impression from `searchanalytics.query_all_partition` where property_unique_date BETWEEN (select property_unique_date from `searchanalytics.property_data` where fetch_date='2018-01-01' and property_url='P1') and (select property_unique_date from `searchanalytics.property_data` where fetch_date='2018-01-31' and property_url='P1') group by page_url

select page_url, sum(click) as click,sum(impression) as impression from `searchanalytics.query_all_partition` where property_unique_date BETWEEN (select property_unique_date from `searchanalytics.property_data` where fetch_date='2018-01-01' and property_url='P2') and (select property_unique_date from `searchanalytics.property_data` where fetch_date='2018-01-31' and property_url='P2') group by page_url

Данные для свойства P1 с уникальными датами свойства не жестко

Данные для свойства P2 с уникальными датами свойства не жестко

На 3-м и 4-м этапах обрабатываются полные данные таблицы, а не подмножества. Почему это так? Кто-нибудь может объяснить и как решить эту проблему?

Буду признателен за ваш подробный ответ.

1 Ответ

0 голосов
/ 03 сентября 2018

С документация :

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

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

...