Google Bigquery присоединиться к чрезвычайно медленно - PullRequest
0 голосов
/ 03 ноября 2018

У меня есть стол с 2 миллионами строк Дело в том, что когда я делаю левое соединение с другой таблицей, которая имеет 60 строк, запрос становится очень медленным. Я делаю отчет в Data Studio, и это был не первый случай, когда после присоединения к Bigquery отчет больше не является полезным. Каждое изменение параметра занимает более 40 секунд или 1 минуту, когда таблица соединяется. Если таблица не объединена, запрос занимает от 6 до 8 секунд. Как обычный запрос. Я не знаю, проблема в Data Studio или BigQuery. Может ли кто-нибудь помочь мне? Потому что теперь невозможно создать информационную панель в Data Studio с помощью соединения, используя Bigquery

Здесь оба запроса: без регистрации

SELECT
Tag_Id,
Image_Id,
Stream,
Tagging_Worker_Id,
Tagging_Worker_Name,
Tagging_Task_Id,
CASE WHEN Tagging_Time_Per_Tag > 200 THEN 200 ELSE Tagging_Time_Per_Tag END AS Tagging_Time_Per_Tag,
Tagging_Date,
Tagging_Class_Name,
Tagging_Class_Id,
Tagging_Template_Id,
Tagging_Top,
Tagging_Left,
Tagging_Width,
Tagging_Height,
Is_Tag_Adjusted,
Is_Class_Adjusted,
CASE WHEN (Is_Tag_Adjusted+Is_Class_Adjusted > 0) THEN 1 ELSE 0 END AS TagsAdjusted
FROM Stats.TaggingStats
where Tagging_Date>=  '2018-10-01'

с присоединением

SELECT
  st.Tag_Id,
  st.Image_Id,
  st.Stream,
  st.Tagging_Worker_Id,
  st.Tagging_Worker_Name,
  st.Tagging_Task_Id,
  st.Tagging_Time_Per_Tag,
  st.Tagging_Date,
  st.Tagging_Class_Name,
  st.Tagging_Class_Id,
  st.Tagging_Template_Id,
  st.Tagging_Top,
  st.Tagging_Left,
  st.Tagging_Width,
  st.Tagging_Height,
  st.Is_Tag_Adjusted,
  st.Is_Class_Adjusted,
  st.TagsAdjusted,
  CASE
    WHEN (sal.Type_Salary=2 AND (st.Is_Tag_Adjusted=1 OR st.Is_Tag_Adjusted=1)) THEN 0
    WHEN sal.Type_Salary=1 THEN st.Tagging_Time_Per_Tag*sal.Salary_Per_Second
    WHEN sal.Type_Salary=2 AND st.Is_Tag_Adjusted=0 AND st.Is_Tag_Adjusted=0 THEN 3
    ELSE st.Tagging_Time_Per_Tag
  END AS CostPerTag,
  CASE
    WHEN sal.Type_Salary IS NULL THEN 'Workers Without Costing'
    WHEN Type_Salary=1 THEN 'Workers With Salary Per Hour'
    WHEN Type_Salary=2 THEN 'Workers With Fixed Price Per Tag'
    ELSE 'Error'
  END AS Costing_Method
FROM (
  SELECT
    Tag_Id,
    Image_Id,
    Stream,
    Tagging_Worker_Id,
    Tagging_Worker_Name,
    Tagging_Task_Id,
    CASE
      WHEN Tagging_Time_Per_Tag > 200 THEN 200
      ELSE Tagging_Time_Per_Tag
    END AS Tagging_Time_Per_Tag,
    Tagging_Date,
    Tagging_Class_Name,
    Tagging_Class_Id,
    Tagging_Template_Id,
    Tagging_Top,
    Tagging_Left,
    Tagging_Width,
    Tagging_Height,
    Is_Tag_Adjusted,
    Is_Class_Adjusted,
    CASE
      WHEN (Is_Tag_Adjusted+Is_Class_Adjusted > 0) THEN 1
      ELSE 0
    END AS TagsAdjusted
  FROM
    Stats.TaggingStats) st
LEFT JOIN
  Stats.Salary sal
ON
  sal.Tagging_Worker_Id=st.Tagging_Worker_Id
WHERE
  Tagging_Date>= '2018-10-01'

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

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

Второй вывод Когда я запрашиваю все данные таблицы A (строка 2 миллиона), время почти такое же, как когда я запрашиваю все данные таблицы A и выполняю левое соединение с таблицей B (60 строк). Таким образом, для всей таблицы время с объединением или без него практически одинаковое и составляет всего 400 МБ. Разница видна только тогда, когда я использую предложение Where в течение одного месяца.

Третий вывод Отчету студии данных Google требуется 90 секунд для извлечения данных после изменения параметра. Google Data Studio автоматически генерирует различные запросы, чтобы дополнить данные параметрами, оценочными карточками и диаграммой. Каждый раз, когда я изменяю параметр, Google Data Studio отправляет 6 разных запросов для получения этих данных. Я проанализировал шесть запросов и вставил в этот документ Google время каждого из них, выполняемых вручную в консоли. https://docs.google.com/document/d/1z_y5CqJW-LrLY5YyLXjSrc455RLUbklPxhnKmAS5zFk/edit?usp=sharing Каждый из этих шести запросов занимает (около 2,5 секунд). Я копирую их и запускаю вручную каждый. Таким образом, в случае, если им нужно обрабатывать одну за одной, общее количество секунд должно составлять около 12 секунд. Таким образом, это проблема Google Data Studio для извлечения данных из BigQuery. Это займет больше одной минуты. Невозможно предложить это клиенту. До того, как я присоединился, я работал с приборной панелью с разумным временем отклика. Но JOIN, похоже, убивает Google Data Studio. Я не знаю.

Я оставляю здесь числа, поддерживающие вывод 1 и 2 https://docs.google.com/document/d/1sc3qjVpQrETofIgToJPIhZVs9HTjHsjTcrZvbt2NYcI/edit?usp=sharing Со всеми запросами и вариантами для анализа влияния объединения, case case и where.

Запрос перед JOIN Запрос перед JOIN и предложение Where на этот месяц Запрос с JOIN и предложение Where на этот месяц Запрос с JOIN для всего TABLE Запрос с JOIN и предложение Where на этот месяц и предложения CASE Запрос с JOIN для всех предложений TABLE и CASE

Другие вопросы: Расхождение: Запускаясь вручную с помощью консоли Big Query, я обнаружил много расхождений во время выполнения одного и того же запроса. Я запускаю один и тот же запрос три раза.

RUN 1) Запрос завершен (прошло 12,955 с, обработано 490,83 МБ)

RUN 2) Запрос завершен (прошло 20,782 с, обработано 490,83 МБ)

RUN 3) Запрос завершен (прошло 10,814 с, обработано 490,83 МБ)

1 Ответ

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

Вы объединяете две таблицы, которые создают широковещательное соединение , которое отправляет все данные в один слот. Кроме того, вы делаете много вычислений (CASE). Все это вместе является причиной того, что запрос занимает больше времени. Я рекомендую уменьшить данные до объединения и / или материализовать данные .

Чтобы лучше понять, как работает BigQuery, вы можете просмотреть эту ссылку .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...