+

Гарне питання🤔
Я правильно зрозумів, що питання більше про завантаження даних аніж про ДБТ перетворення?
Схоже, що в нас немає універсального підходу, але щойно затестив, можна дозволити додавати колонки (SchemaUpdateOption.ALLOW_FIELD_ADDITION), а після того в job_config передати нову схему або розраховувати на автовизначення схеми.
Але в таких випадках я завжди переймаюсь, що якісь аномальні дані на вході можуть перетворити мою таблицю на казна що (+100500 колонок), тому надаю перевагу ігноруванню нових колонок із нотифікацією, що щось змінилось. Потім вручну змінюю🤷

Документація:
cloud.google.com/...​ng-table-schemas#python_1

1. DBT не генерує SQL в тому сенсі, як це роблять ORM. Моделі написані SQL кодом із можливістю використання Jinja темплейтів. Тобто, на етапі розробки буде видно, який запит генерується. Щоправда, певна генерація коду присутня при інкрементальному оновленні, ми б код писали трошки іншим способом (при оновленні партицій в insert_overwrite стратегії), але вирішили що це не критично. Загалом, плюси від використання виправдали зусилля на перехід.
2. Дійсно, завантаження даних залишилось поза кадром, в межах цього допису. Нажаль (чи на щастя) джерел даних багато, вони різні і завантаження з них це теж дуже цікавий виклик. Спробую висвітлити в одній із наступних публікацій.

А за рахунок чого ростуть кости у вашому випадку?
Ми теж стикались у BigQuery, що за певних умов, інкрементальне оновлення ми можемо зробити дещо ефективніше. Мабуть можна законтрібьютити в dbt🤔

Саме так. Захоплюючий досвід, аж кортить поділитись зі спільною🙂
І так, на цю тему я знайшов тільки одну згадку вебінару 2021 року на ДОУ

Якщо правильно зрозумів питання, то DBT — це не ORM, а інструмент для аналітичного сховища, та моделі описані в першу чергу SQL, хоча із використанням Jinja темплейтів (найчастіше Jinja використовується для HTML)

BigQuery як DWH

+

+

+

Що мається на увазі під «іменування»?

Дякую! Звісно, тестував на:
MySQL 5.6
PostgreSQL 9.6
PostgreSQL 9.3
SQLite
Vertica
BigQuery (Standard SQL)
В статті використаний базовий функціонал, спільний для більшості БД, з мінімальними відмінностями. Наприклад в MS SQL Server «LIMIT n» треба замінити на «TOP n» і написати в SELECT. А в Oracle не можна порівняти дату зі строковим типом даних, а треба зробити приведення типу, щось накшталт TO_DATE (‘2020/02/02’, ‘yyyy/mm/dd’). Таким чином вважаю, що питання розбіжності діалектів переоцінене і вирішуються за допомогою google-пошуку або місцевого DBA.

Дякую за відгук!

HAVING зі стандарту SQL, вважаю що важливо було описати цю механіку, її часто використовують аналітики. Вкладені запити будуть в продовженні.

Намагався використати синтаксис, який працюватиме майже на всіх діалектах SQL (LIMIT не буде працювати в T-SQL, деякі запити не працюватимуть в ClickHouse).

Отримати список таблиць в різних БД має свої особливості.