Как измерять время и тестировать сценарии Bigquery Standard SQL?

У меня разные версии сценариев Bigquery Standard, т. е. я использую стандартный API здесь. Я пытаюсь выяснить время в стиле Matlab или время разогрева для сравнения различных скриптов:

Версия A: очень читаемый код с модульным кодом

WITH a AS
(
SELECT * FROM SOURCE
), 
a_ AS
(
SELECT ... FROM a
)
SELECT * FROM a_

Версия B: очень нечитаемый код с подзапросами, но заявлено, что он эффективен

SELECT * FROM (SELECT * FROM (SELECT * FROM SOURCE))

Как определить время и сравнить различные стандартные SQL-запросы в Google Bigquery?

Возможные перспективы

  1. Нужно ли мне разогревать стандартные SQL-запросы BQ, как в Matlab?

  2. Каковы общие различия в производительности между версиями A и B? Есть плюсы и минусы? Как вы можете продемонстрировать это в Bigquery?

  3. Любая документация или рекомендации, доступные для двух разных подходов (чрезмерное использование подзапросов по сравнению с модульным кодированием)?


sql google-bigquery performance-testing timeit code-readability
person hhh    schedule 17.01.2018    source источник
comment
проверьте cloud.google.com/bigquery/query-plan-explanation   -  person Mikhail Berlyant    schedule 18.01.2018
comment
@MikhailBerlyant, я пропустил это или в этой статье было что-то о модульном стиле кодирования (A) и стиле подзапросов (B)? Я понимаю фильтрацию, которую вы можете достичь с помощью обоих подходов. Кроме того, я не смог найти никаких тестовых параметров.   -  person hhh    schedule 18.01.2018
comment
причина, по которой я сослался на эту статью, заключается в том, что понимание query plan explanation помогает понять, что происходит под капотом в BigQuery — независимо от того, насколько причудливым и [не]читаемым мы иногда пишем запрос.   -  person Mikhail Berlyant    schedule 18.01.2018
comment
Читаемость ‹› Производительность. Как вы думаете, почему будет разница в производительности? Общие табличные выражения (CTE) не являются функцией, ориентированной на производительность. В том, как вы описали варианты запросов A и B, существует большая вероятность того, что оптимизатор будет интерпретировать запросы с одним и тем же планом запроса. Использование объяснения поможет вам понять, выполняются ли варианты запроса одинаково или нет.   -  person Paul Maxwell    schedule 18.01.2018
comment
CTE ‹› Улучшение читаемости. Читабельность по своей сути субъективна. Лично я ненавижу чтение SQL-запросов, которые используют CTE исключительно для удобства чтения, потому что все, что они продвигают, — это последовательное мышление. Традиционные подзапросы гораздо ближе к природе SQL, основанной на наборах, и при знакомстве и хорошем форматировании в любом случае легко читаются.   -  person Paul Maxwell    schedule 18.01.2018
comment
@Mikhail непустые значения, по-видимому, NULL, занимают место? Итак, могу ли я фильтровать поля w IF(..., Val1, NULL) вместо того, где в подзапросах? Актуальны? "Cloud Bigtable tables are sparse. Empty columns don't take up any space. As a result, it often makes sense to create a very large number of columns, even if most columns are empty in most rows"? cloud.google.com/bigtable/docs/schema-design   -  person hhh    schedule 18.01.2018
comment
@Used, поэтому выбор CTE / подзапросов имеет значение для оптимизации производительности? Но является ли предварительная фильтрация более важной, чтобы вы могли более эффективно оптимизировать ранние IF в полях, прежде чем назначать их или фильтровать с помощью WHERE?   -  person hhh    schedule 18.01.2018
comment
Нет. Это обратное тому, что я пытался донести. Вы можете взять практически любой подзапрос и сделать его подзапросом, или наоборот взять тип подзапроса в вашем вопросе и сделать его подзапросом. Чистый эффект, скорее всего, будет нулевым или неизмеримым.   -  person Paul Maxwell    schedule 18.01.2018

Ответы (1)


arrow_upward
0
arrow_downward

Я обобщаю комментарии и рассказываю о возможностях ускорения с точки зрения затрат.

A демонстрирует CTE (Common Table Expressions), а B демонстрирует построение с подзапросами, такими как наборы. Пользователь Used_By_Already прокомментировал, что разница в производительности не должна иметь значения, поэтому не говорит о возможностях ускорения.

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

Важна предварительная фильтрация, подробнее здесь, присланная Михаилом Берлянтом в комментарии. . Таким образом, вы можете сделать свои запросы более эффективными, предварительно отфильтровав данные.

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

person hhh    schedule 18.01.2018