Я имел в виду всякие виртуальные таблички типа __TABLES_SUMMARY__

Я вот не уверен что они прям вьюхи

И вайлдкард таблички его тоже не заставишь смотреть, я правильно понял?

То есть прямо скажем жалкое подобие левой руки

А можно ли заставить его выполнить произвольный sql?

ну почему, это рабочая штука, просто для своих задач

он ничего не выполняет, это сахар вокруг экспорт джобов, все что вы можете выполнить на данных которые экспортнули в GCS - можно сделать и в BigQuery

Спасибо

Мне как-то не хватало этого понимания (и в доке ничего не написано)

новый Storage API слава богу научился проекции колонок и какие-то предикаты, но пока доступен в европке только в одном регионе

у меня европка!

причём кажется даже правильный регион

это же тот, который экспериментальный?

BQ Storage API

чот мне кажется они это не скрывают:
> The connector writes the data to BigQuery by first buffering all the data into a Cloud Storage temporary table, and then it copies all data from into BigQuery in one operation. The connector attempts to delete the temporary files once the BigQuery load operation has succeeded and once again when the Spark application terminates. If the job fails, you may need to manually remove any remaining temporary Cloud Storage files. Typically, you'll find temporary BigQuery exports in gs://bucket/.spark-bigquery-[jobid]-[UUID].

europe-west2

ну как бы вот это совсем не значит что там нельзя выполнить arbitary SQL потому что всегда можно сделать CREATE TABLE FROM SELECT AS (SELECT * FROM ()), а потом её дампануть в gcs

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

BQ же не совсем СУБД, это скорее Presto на стероидах

Но так получается что сабсет дпйствий, который я могу совершить спарком над bq настолько ограничен, что больно.