Главная
Arenadata Orchestrator
Сервисы
DBT
Интеграции
Greengage адаптер

Как использовать адаптер dbt-greengage

Елена Костюченко

Свернуть контент Развернуть контент

Обзор

Адаптер dbt-greengage позволяет dbt работать с Greengage DB (на основе Greenplum) и входит в состав сервиса DBT в ADO.

Адаптер dbt-greengage основан на dbt-postgres и добавляет поддержку специфичных для Greengage DB возможностей, включая:

таблицы Append-Optimized (AO);
хранение с ориентацией на столбцы (Column-Oriented, CO);
политики распределения (distribution policies);
партиционирование (partitioning);
внешние таблицы (external tables);
материализованные представления и индексы.

Адаптер предоставляет:

совместимость с версиями dbt Core 1.3-1.11;
поддержку специфичной для Greengage DB функциональности;
обратную совместимость с существующими проектами dbt-greenplum.

ПРИМЕЧАНИЕ

Текущий релиз поддерживает только Greengage DB 6 (на основе PostgreSQL 9). При подключении к серверу Greengage DB 7 операции создания таблиц могут завершаться ошибкой компиляции. Поддержка Greengage DB 7 (на основе PostgreSQL 12) запланирована в будущих релизах.

Конфигурация

Адаптер входит в состав ADO вместе с сервисом DBT. Дополнительную информацию о сервисе DBT можно получить в статье Обзор сервиса DBT.

Чтобы настроить DBT для работы с базой данных Greengage DB, создайте конфигурационный файл profiles.yml, в котором будут описаны параметры подключения к базе данных.

Пример profiles.yml:

my-greengage-project:
  target: dev
  outputs:
    dev:
      type: greengage
      host: localhost
      port: 5432
      user: gpadmin
      password: <password>
      dbname: warehouse
      schema: dbt_dev
      threads: 4

Обязательными являются следующие параметры:

host — хост Greengage DB;
user — пользователь базы данных;
password — пароль пользователя;
dbname — имя целевой базы данных;
schema — схема для объектов dbt.

Конфигурационный файл profiles.yml должен находиться на хосте с компонентом сервиса DBT. Путь к конфигурационному файлу необходимо указать в значении параметра DBT_PROFILES_DIR в конфигурации сервиса DBT в ADCM.

В качестве альтернативы можно указать путь в свойстве Profiles path при запуске команды DBT.

Дополнительные параметры подключения
Параметр	Описание	Значение по умолчанию
port	Порт базы данных	5432
threads	Количество параллельных потоков dbt	1
keepalives_idle	Количество секунд простоя перед отправкой TCP keepalive-проверки	0
connect_timeout	Тайм-аут подключения в секундах	10
search_path	Переопределяет PostgreSQL `search_path`	—
role	Выполняет команду `SET ROLE` после подключения	—
sslmode	Режим SSL, например: `require`, `verify-full`	—
kerberos_service_name	Имя сервиса Kerberos для аутентификации GSSAPI	—

Полный список параметров подключения идентичен dbt-postgres.

Команды DBT

Сервис DBT поддерживает стандартные команды dbt для Greengage DB. Он обеспечивает выполнение моделей dbt, тестов, создание снепшотов (snapshots), генерацию документации и инкрементальные преобразования через действия ADCM и DAG Airflow.

Вы можете выполнить команду DBT с помощью действий сервиса ADCM.

Материализации

dbt-greengage поддерживает несколько типов материализации.

Адаптер автоматически выбирает пути генерации SQL, специфичные для Greengage DB, в зависимости от:

версии Greengage DB;
типа материализации;
конфигурации данных;
настроек партиционирования.

Поддерживаются следующие типы материализации:

table
view
incremental

table

Материализация table создает физическую таблицу и полностью управляет ее жизненным циклом.

Пример:

{{ config(materialized='table') }}

ПРИМЕЧАНИЕ

Greengage DB не поддерживает CREATE OR REPLACE TABLE. Из-за этого ограничения dbt-greengage реализует замену таблиц через явную логику удаления и повторного создания (drop-and-recreate). Этот процесс обрабатывается в GreengageRelation, который ограничивает replaceable_relations только представлениями (views).

При запуске dbt run --full-refresh адаптер выполняет:

для обычных таблиц: DROP TABLE IF EXISTS … CASCADE → CREATE TABLE;
для внешних таблиц: DROP EXTERNAL TABLE IF EXISTS … CASCADE;
для представлений: CREATE OR REPLACE VIEW (работает напрямую).

Пример:

DROP TABLE IF EXISTS users CASCADE;

CREATE TABLE users AS
SELECT 1 AS id, 'Alice' AS name;

Ключевое слово CASCADE необходимо, поскольку схемы часто содержат зависимые объекты.

Материализация table полностью поддерживает параметры хранения Greengage DB.

Пример:

{{ config(
    materialized='table',
    appendoptimized=true,
    orientation='column',
    compresstype='ZSTD',
    compresslevel=4,
    blocksize=32768
) }}

Сгенерированный DDL:

CREATE TABLE users
WITH (
    appendoptimized=true,
    orientation=column,
    compresstype=ZSTD,
    compresslevel=4,
    blocksize=32768
)
AS
SELECT ...

view

Материализация view создает стандартное SQL-представление в Greengage DB. В dbt-greengage ее реализация в основном наследуется от dbt-postgres. Однако Greengage DB добавляет ряд особенностей, специфичных для MPP-систем (Massively Parallel Processing), связанных с зависимостями объектов и удалением отношений (relation cleanup), поэтому адаптер предоставляет собственную реализацию удаления отношений.

В отличие от PostgreSQL, среды Greengage DB часто содержат глубоко взаимосвязанные объекты: иерархии секций (partition hierarchies), зависимые представления, внешние таблицы, материализованные представления и аналитические объекты, расположенные в разных схемах.

Для обеспечения надежной очистки и повторного создания объектов dbt-greengage переопределяет макрос greengage__drop_relation. Удаление всех отношений выполняется с использованием семантики CASCADE, когда это необходимо.

Пример жизненного цикла при замене модели:

DROP VIEW IF EXISTS analytics.products CASCADE;
CREATE VIEW analytics.products AS
SELECT ...

Такое поведение гарантирует корректное удаление зависимых объектов перед их повторным созданием.

Пример:

{{ config(
    materialized='view'
) }}

select
    order_id,
    customer_id,
    total_amount,
    created_at
from {{ ref('stg_orders') }}

incremental

Материализация incremental оптимизирована для больших аналитических наборов данных и поддерживает несколько стратегий загрузки.

Поддерживаемые стратегии
Стратегия	Статус	Описание
append	Унаследована	`INSERT INTO` — работает без дополнительной настройки
delete+insert	Унаследована	`DELETE WHERE key IN (…)` + `INSERT`
truncate+insert	Пользовательская	`TRUNCATE` + `INSERT` — полная перезагрузка без `CASCADE`
microbatch	Пользовательская	`DELETE` по окну `event_time` + `INSERT`

ПРИМЕЧАНИЕ

Адаптер не поддерживает стратегию merge, поскольку оператор MERGE недоступен в Greengage DB 6.

Пример TRUNCATE + INSERT

{{ config(
    materialized='incremental',
    incremental_strategy='truncate+insert'
) }}
select * from {{ ref('source_data') }}

Эта стратегия безопасна для heap-таблиц, поскольку команда TRUNCATE удаляет все строки, не затрагивая структуру таблицы, индексы, права доступа и зависимые объекты. Для партиционированных таблиц TRUNCATE удаляет данные из всех секций. Для таких таблиц рекомендуется использовать delete+insert с опцией incremental_predicates, отфильтрованным по ключу партиционирования.

Пример microbatch

{{ config(
    materialized='incremental',
    incremental_strategy='microbatch',
    event_time='created_at',
    begin='2024-01-01',
    batch_size='month'
) }}
select * from {{ ref('source_data') }}

Стратегия microbatch использует конфигурацию пакетов (batch configuration) и столбец event_time, как описано в документации dbt microbatch documentation. Для каждого пакета выполняется операция DELETE по окну event_time, после чего выполняется INSERT из временной таблицы.

Параметр unique_key не требуется, границы пакетов определяются окном event_time.

Для ссылки на целевую таблицу используйте DBT_INTERNAL_DEST в incremental_predicates следующим образом:

{{ config(
    materialized='incremental',
    incremental_strategy='microbatch',
    event_time='created_at',
    begin='2024-01-01',
    batch_size='month',
    incremental_predicates=["DBT_INTERNAL_DEST.status != 'archived'"]
) }}
select * from {{ ref('source_data') }}

Адаптер заменяет этот псевдоним (alias) реальным именем таблицы (так как в DELETE отсутствует оператор USING).

Ограничения

Адаптер поддерживает контракты моделей dbt (model contracts) и определения ограничений (constraints).

Ограничение

Поддерживается

Принудительно применяется

check

Да

not_null

Да

unique

Да

Нет

primary_key

Да

Нет

foreign_key

Да

Нет

ПРИМЕЧАНИЕ

Если настроен параметр contract.enforced=true, dbt-greengage выводит предупреждение, поскольку полное применение контрактов не гарантируется для всех типов ограничений.

Конфигурация хранения (AO/heap)

Greengage DB поддерживает как heap-таблицы, так и таблицы Append-Optimized (AO) с построчным и колоночным хранением данных.

Параметры AO-хранения настраиваются непосредственно в конфигурации модели и могут быть двух типов:

AO-таблицы с построчной ориентацией (row-oriented AO tables) подходят для нагрузок с частым доступом к отдельным строкам или смешанных сценариев OLTP/аналитической обработки.

Пример:
```
{{ config(
materialized='table',
appendoptimized=true,
orientation='row'
) }}
```
AO-таблицы с колоночной ориентацией (column-oriented AO tables) рекомендуются для аналитических фактных таблиц и нагрузок с интенсивным выполнением агрегаций.

Пример:
```
{{ config(
materialized='table',
appendoptimized=true,
orientation='column',
compresstype='ZSTD',
compresslevel=4
) }}
```

Параметр Описание Значение по умолчанию

appendoptimized

Создает AO-таблицу

true

orientation

Тип хранения: column или row

column

compresstype

Тип сжатия

ZSTD

compresslevel

Уровень сжатия от 1 до 9

blocksize

Размер блока в байтах

32768

Heap-таблицы

Heap-таблицы отключают AO-хранение и ведут себя аналогично стандартным таблицам PostgreSQL.

Пример:

{{ config(
materialized='table',
appendoptimized=false
) }}

Распределение

Адаптер поддерживает следующие политики распределения:

DISTRIBUTED BY — распределяет строки в соответствии с хеш-значениями одного или нескольких столбцов.

Пример:
```
{{ config(
materialized='table',
distributed_by='customer_id'
) }}
```
DISTRIBUTED REPLICATED — копирует всю таблицу на все сегменты.

Пример:
```
{{ config(
materialized='table',
distributed_replicated=true
) }}
```
DISTRIBUTED RANDOMLY — если политика распределения не настроена, адаптер генерирует случайное распределение.

Пример:
```
{{ config(materialized='table') }}
```

Партиционирование

Адаптер DBT Greengage DB поддерживает:

необработанные определения партиционирования (raw partition definitions);
параметризованные партиции RANGE;
параметризованные партиции LIST.

Greengage DB 6 не поддерживает использование CREATE TABLE AS совместно с PARTITION BY. Из-за этого ограничения dbt-greengage автоматически переключается на двухэтапный процесс:

CREATE TABLE ...
INSERT INTO ...

Поэтому для партиционированных таблиц требуется явное определение столбцов с помощью параметра fields_string.

Параметр raw_partition позволяет передать полное выражение партиционирования.

Параметр Конфигурация Описание

fields_string

config.get()

Определения столбцов для CREATE TABLE ( … )

raw_partition

GreengageConfig

Полное выражение PARTITION BY … в виде необработанной SQL-строки

partition_type

GreengageConfig

RANGE или LIST

partition_column

GreengageConfig

Столбец, по которому выполняется партиционирование

partition_start

config.get()

Начальное значение для партиции RANGE

partition_end

config.get()

Конечное значение для партиции RANGE

partition_every

config.get()

Интервал для партиций RANGE, например 1 month (один месяц)

partition_values

config.get()

Выражение PARTITION … VALUES (…) для партиций LIST

default_partition_name

config.get()

Имя партиции по умолчанию (по умолчанию: other)

Пример raw-партиционирования

{% set fields_string %}
id int4 null,
event_date timestamp null
{% endset %}

{% set raw_partition %}
PARTITION BY RANGE (event_date)
(
START ('2024-01-01'::timestamp) INCLUSIVE
END ('2025-01-01'::timestamp) EXCLUSIVE
EVERY (INTERVAL '1 month'),
DEFAULT PARTITION other
)
{% endset %}

{{ config(
materialized='table',
distributed_by='id',
fields_string=fields_string,
raw_partition=raw_partition
) }}

Пример партиционирования RANGE

{{ config(
materialized='table',
distributed_by='id',
fields_string=fields_string,
partition_type='RANGE',
partition_column='event_date',
partition_start='2024-01-01',
partition_end='2025-01-01',
partition_every='1 month'
) }}

Пример партиционирования LIST

{{ config(
materialized='table',
distributed_by='id',
fields_string=fields_string,
partition_type='LIST',
partition_column='region',
partition_values="PARTITION eu VALUES ('EU'), PARTITION us VALUES ('US')"
) }}

Внешние таблицы и загрузка данных

Адаптер предоставляет макросы для создания и удаления внешних таблиц Greengage DB. Поддерживаются протоколы gpfdist и PXF.

gpfdist предоставляет доступ к flat-файлам (flat files) с ETL-хоста (gpfdist://, gpfdists://), поддерживает форматы TEXT и CSV и позволяет указывать несколько URL-адресов в одном выражении LOCATION для параллельной загрузки данных между сегментами.

PXF подключается к внешним источникам данных (HDFS, HBase, Hive, S3, JDBC) через URL вида pxf://. Он поддерживает форматы TEXT, CSV и CUSTOM (с использованием FORMATTER). Для PXF требуется только один URL в каждом выражении LOCATION. Использование нескольких адресов не допускается.

Управление внешними таблицами осуществляется с помощью служебных макросов (utility macros), которые обычно используются в:

pre-hook;
post-hook;
dbt run-operation.

Параметр Описание Значение по умолчанию

relation

Целевое отношение (relation) внешней таблицы (схема и имя таблицы), которое необходимо создать. Этот параметр является обязательным

—

fields_string

Определения столбцов для внешней таблицы в SQL-формате (например, id INTEGER, name TEXT). Этот параметр является обязательным

—

location

Расположение источника внешних данных. Может быть одним URL или списком URL. Несколько URL поддерживаются только для источников gpfdist. Этот параметр является обязательным

—

format

Формат данных во внешней таблице. Поддерживаются значения TEXT, CSV и CUSTOM

TEXT

formatter

Имя пользовательского форматтера, используемого для обработки данных в формате CUSTOM (например, pxfwritable_import)

—

delimiter

Символ, используемый для разделения полей в строке данных

null_string

Строковое значение, которое интерпретируется как NULL при чтении данных

—

escape

Символ экранирования специальных символов. Для отключения экранирования укажите значение off

—

header

Указывает, содержит ли первая строка файла заголовок с именами столбцов

false

encoding

Кодировка символов исходных данных

UTF8

on_clause

Определяет, где выполняется обработка данных: на всех сегментах (ALL) или только на координаторе (MASTER)

—

log_errors

Включает логирование строк, которые не удалось обработать из-за ошибок формата или преобразования данных

false

segment_reject_limit

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

—

segment_reject_limit_type

Единица измерения для параметра segment_reject_limit: количество строк (rows) или процент от общего объема данных (percent)

rows

execute

Определяет, следует ли выполнить сгенерированный SQL-запрос немедленно (true) или только вернуть его текст (false)

true

Пример использования gpfdist CSV с обработкой ошибок

{% set ext_relation = api.Relation.create(schema='ext_schema', identifier='ext_orders') %}

{{ create_external_table(
    relation=ext_relation,
    fields_string='order_id INTEGER, order_date DATE, amount NUMERIC',
    location="'gpfdist://etl-host:8080/orders*.csv'",
    format='CSV',
    delimiter=',',
    header=true,
    log_errors=true,
    segment_reject_limit=100,
    segment_reject_limit_type='rows'
) }}

Пример использования нескольких источников gpfdist для параллельной загрузки

{{ create_external_table(
    relation=ext_relation,
    fields_string='id INTEGER, name TEXT, value NUMERIC',
    location=[
        "'gpfdist://host1:8080/data.csv'",
        "'gpfdist://host2:8081/data.csv'"
    ],
    format='CSV',
    header=true
) }}

Пример использования PXF для работы с текстовыми данными из HDFS

{{ create_external_table(
    relation=ext_relation,
    fields_string='event_id INTEGER, payload TEXT',
    location="'pxf://data/events?PROFILE=hdfs:text'",
    format='TEXT',
    delimiter='|'
) }}

Пример использования PXF для HBase с форматом CUSTOM

{{ create_external_table(
    relation=ext_relation,
    fields_string='row_key TEXT, cf1_col1 TEXT, cf1_col2 TEXT',
    location="'pxf://hbase_table?PROFILE=HBase'",
    format='CUSTOM',
    formatter='pxfwritable_import'
) }}

Внешние таблицы с поддержкой записи

Адаптер также поддерживает внешние таблицы с возможностью записи.

Пример:

{% set ext_relation = api.Relation.create(schema='ext_schema', identifier='ext_export') %}

{{ create_writable_external_table(
    relation=ext_relation,
    fields_string='id INTEGER, name TEXT',
    location="'gpfdist://etl-host:8080/output.csv'",
    format='CSV',
    distributed_by='id'
) }}

Материализованные представления

Адаптер dbt-greengage предоставляет собственную реализацию материализации materialized_view со встроенным управлением индексами.

В отличие от обычных представлений, материализованные представления физически хранят результаты запроса на диске. Поэтому материализованное представление необходимо обновлять при изменении исходных данных.

При создании материализованного представления адаптер выполняет оператор CREATE MATERIALIZED VIEW … AS … и автоматически создает все индексы, определенные в конфигурации модели.

При последующих запусках dbt run адаптер сравнивает текущее определение материализованного представления с требуемой конфигурацией. Если изменились только определения индексов, адаптер выполняет целевое обновление, удаляя и создавая заново только затронутые индексы. Если изменился базовый запрос или материализованное представление необходимо пересоздать, адаптер заменяет объект целиком.

Операции refresh, rename, drop, describe и сравнение конфигураций наследуются от dbt-postgres.

Пример:

{{ config(
    materialized='materialized_view',
    indexes=[
        {'columns': ['user_id'], 'type': 'btree', 'unique': true},
        {'columns': ['order_count'], 'type': 'bitmap'},
    ]
) }}

select
    user_id,
    count(*) as order_count,
    sum(amount) as total_amount
from {{ ref('orders') }}
group by user_id

Индексы также могут быть настроены в dbt_project.yml или schema.yml:

models:
  - name: user_order_summary
    config:
      materialized: materialized_view
      indexes:
        - columns: ['user_id']
          type: btree
          unique: true
        - columns: ['order_count']
          type: bitmap

Конфигурация индексов
Параметр	Тип	Описание	Значение по умолчанию
columns	list	Список столбцов, включенных в индекс. Этот параметр является обязательным	—
unique	bool	Создает уникальный индекс	false
type	string	Используемый метод индекса	btree

ПРИМЕЧАНИЕ

Greengage DB не поддерживает CREATE OR REPLACE MATERIALIZED VIEW. В результате материализованные представления рассматриваются как отношения, которые можно переименовывать, но нельзя заменять на месте. Если требуется полное пересоздание, адаптер удаляет и заново создает материализованное представление вместо выполнения операции замены существующего объекта.

Индексы

Адаптер предоставляет встроенную поддержку создания индексов через макрос greengage__get_create_index_sql.

Если определение индекса указано в конфигурации модели, адаптер автоматически проверяет конфигурацию, генерирует соответствующий SQL-оператор и создает индекс в процессе материализации. Имена индексов генерируются автоматически.

Сгенерированный SQL соответствует следующему шаблону:

CREATE [UNIQUE] INDEX "<generated_name>"
ON <relation>
[USING <index_type>]
(<columns>)

Индексы используются совместно с материализованными представлениями (через параметр indexes) и доступны для вызова из макросов через get_create_index_sql(relation, index_dict).

Поддерживаемые типы индексов
Тип индекса	Описание
btree	Тип индекса по умолчанию. Рекомендуется для предикатов равенства, операций сортировки и диапазонных запросов
bitmap	Специфичный для Greengage DB тип индекса, оптимизированный для столбцов с низкой кардинальностью (low cardinality), таких как флаги состояния, категории и другие столбцы с ограниченным количеством различных значений
hash	Оптимизирован для точного поиска совпадений с использованием операторов равенства
gist	Индекс обобщенного дерева поиска (Generalized Search Tree), подходящий для геопространственных данных, полнотекстового поиска и других сложных типов данных
spgist	Индекс GiST с пространственным разбиением (Space-Partitioned GiST), предназначенный для IP-адресов, телефонных номеров и иерархических данных
gin	Обобщенный инвертированный индекс (Generalized Inverted Index), обычно используемый для массивов, документов JSONB и полнотекстового поиска
brin	Индекс диапазонов блоков (Block Range Index), предназначенный для очень больших таблиц, в которых данные естественным образом упорядочены; например, фактных таблиц на основе временных меток (timestamp)

Расширения

Адаптер предоставляет набор макросов Jinja для управления расширениями базы данных в Greengage DB.

Эти макросы могут выполняться из:

моделей dbt;
хуков on-run-start и on-run-end;
pre-hook и post-hook;
команд dbt run-operation.

Пример создания расширения базы данных:

{{ create_extension(
    extension_name='hstore',
    schema='public',
    version='1.4',
    cascade=true
) }}

Сгенерированный SQL:

CREATE EXTENSION "hstore"
WITH SCHEMA "public"
VERSION '1.4'
CASCADE

Создание расширения только в том случае, если оно еще не существует:

{{ create_extension_if_not_exists(
    extension_name='postgis'
) }}

Сгенерированный SQL:

CREATE EXTENSION IF NOT EXISTS "postgis"

Этот макрос является идемпотентным и может безопасно выполняться несколько раз, что позволяет использовать его в автоматизированных пайплайнах.

Удаление существующего расширения:

{{ drop_extension(
    extension_name='hstore',
    if_exists=true,
    cascade=true
) }}

Сгенерированный SQL:

DROP EXTENSION IF EXISTS "hstore" CASCADE

Параметры макросов
Параметр	Тип	Описание	Значение по умолчанию
extension_name	string	Имя расширения, которое необходимо создать или удалить, например `hstore`, `postgis` или `plpython3u`. Этот параметр является обязательным	—
schema	string	Схема, в которой должно быть установлено расширение. Генерирует оператор `WITH SCHEMA`	—
version	string	Конкретная версия расширения для установки	—
cascade	boolean	Автоматически устанавливает или удаляет зависимые объекты, если это поддерживается расширением	false
if_exists	boolean	Добавляет оператор `IF EXISTS` при удалении расширения. Применимо только к `drop_extension`	true
execute	boolean	Немедленно выполняет сгенерированный SQL. Если установлено значение `false`, макрос возвращает SQL-оператор без его выполнения	true

Установка расширения во время инициализации DBT

Пример установки расширения plpython3u перед началом выполнения моделей:

on-run-start:
  - "{{ create_extension_if_not_exists(extension_name='plpython3u') }}"

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

Снепшоты

Адаптер dbt-greengage поддерживает отслеживание изменений на основе снепшотов для сценариев Slowly Changing Dimension (SCD). Обработка снепшотов использует ту же реализацию, что и dbt-postgres, основанную на операторах UPDATE … FROM и INSERT, а не на SQL MERGE, который недоступен в Greengage DB.

Поддерживаются следующие стратегии создания снимков:

timestamp — создает новую версию снимка при изменении значения указанного столбца с временной меткой (например, updated_at);
check — создает новую версию снимка при изменении значений одного или нескольких отслеживаемых столбцов.

Адаптер также поддерживает параметр hard_deletes (доступен начиная с dbt 1.9), который позволяет отслеживать записи, удаленные из исходного набора данных.

Пример использования стратегии timestamp

{% snapshot orders_snapshot %}
{{
config(
target_schema='snapshots',
unique_key='order_id',
strategy='timestamp',
updated_at='updated_at'
)
}}
select * from {{ source('raw', 'orders') }}
{% endsnapshot %}

Пример использования стратегии check

{% snapshot products_snapshot %}
{{
config(
target_schema='snapshots',
unique_key='product_id',
strategy='check',
check_cols=['name', 'price', 'status']
)
}}
select * from {{ source('raw', 'products') }}
{% endsnapshot %}

Пример использования hard_deletes

Если параметр hard_deletes установлен в значение new_record, удаленные записи фиксируются как новая строка со значением dbt_is_deleted = True.

{% snapshot customers_snapshot %}
{{
    config(
        target_schema='snapshots',
        unique_key='customer_id',
        strategy='timestamp',
        updated_at='updated_at',
        hard_deletes='new_record'
    )
}}
select * from {{ source('raw', 'customers') }}
{% endsnapshot %}

Специфика работы снепшотов в Greengage DB

Greengage DB 6 основан на PostgreSQL 9 и имеет особенности разрешения типов (type resolution) для строковых литералов в запросах UNION ALL.

Чтобы избежать проблем компиляции снепшотов, адаптер автоматически добавляет явные приведения типов ::text в вспомогательный SQL-код (helper SQL) для снепшотов.

Это необходимо для обеспечения совместимости с будущими версиями Greengage DB.

Миграция

Миграция с dbt-greenplum

Адаптер dbt-greengage разработан с учетом максимальной совместимости с существующими проектами dbt-greenplum. Поэтому миграция не требует больших изменений конфигурации.

Обновите тип адаптера в profiles.yml:
```
type: greengage
```
Установите адаптер dbt-greengage (либо установив сервис DBT, либо вручную) и удалите старый пакет адаптера:
```
$ pip uninstall dbt-greenplum
$ pip install dbt-greengage
```
Замените appendonly на appendoptimized в конфигурациях моделей (рекомендуется). Параметр appendonly, используемый ранее, по-прежнему поддерживается для обеспечения обратной совместимости, поэтому существующие проекты продолжают работать без изменений. Однако рекомендуется использовать appendoptimized, поскольку он соответствует терминологии Greengage DB.
```
{{ config(
    appendoptimized=true,
    orientation='column'
) }}
```
Проверьте инкрементальные модели (incremental models) и удалите стратегию merge, если она настроена. Greengage DB не поддерживает SQL MERGE, поэтому инкрементальная стратегия merge недоступна. Если она настроена, адаптер выдаст ошибку валидации во время выполнения. Вместо этого вы можете использовать одну из поддерживаемых альтернатив.
Проверьте конфигурацию пользовательских схем. В отличие от некоторых других адаптеров, dbt-greengage не добавляет автоматически target.schema к именам пользовательских схем, заданным через свойство schema:. Если ваш проект использует конкатенацию (объединение) имен схем, после миграции необходимо проверить и скорректировать определения схем.

Адаптер наследует механизм управления подключениями от dbt-postgres, что означает, что все стандартные параметры подключения остаются без изменений. Существующие настройки можно использовать повторно без модификаций.

Миграция с dbt-postgres

Поскольку адаптер dbt-greengage построен поверх dbt-postgres и поддерживает ту же модель конфигурации подключения, для миграции с dbt-postgres на dbt-greengage достаточно установить адаптер и изменить его тип в конфигурации.

Обновите тип адаптера в конфигурационном файле profiles.yml:

type: greengage

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней