[Документация Yandex Cloud](../../../../index.md) > [Yandex DataLens](../../../index.md) > [Yandex DataLens Platform](../../index.md) > Поставки данных > Типы поставок

# Поставки данных в Yandex DataLens Platform

Поставка данных переносит данные из внешнего [подключения-источника](../../../concepts/connection/index.md) (например, базы PostgreSQL) в хранилище на основе [REST-каталога](../rest-catalog/index.md). В Yandex DataLens Platform вы можете создавать поставки разных типов:

* [регулярное копирование](#regular-copy) — используйте, когда есть постоянная потребность в поставке данных и необходимость поддерживать приемник данных в актуальном состоянии;
* [разовое копирование](#one-time-copy) — используйте, когда нет постоянной потребности в поставке данных, например, для развертывания тестовых сред или для загрузки первичной порции данных;
* [захват изменений данных (CDC)](#cdc) `Скоро` — используйте для сценариев, когда важно отслеживать изменения данных в реальном времени.

{% note info %}

В настоящий момент в Yandex DataLens Platform поддерживаются поставки данных из подключений PostgreSQL, MySQL® и ClickHouse®.

{% endnote %}

Если нужный источник пока не поддерживается поставками данных, загрузку можно организовать с помощью кода в Apache Spark™ или подключения к источнику в Trino. Возможность подключения зависит от доступных библиотек и коннекторов.

После создания поставки вы можете [просматривать статистику, изменять настройки, приостанавливать или удалять поставку](../../operations/data-transfer/manage-transfer.md).

## Жизненный цикл поставки {#lifecycle}

Когда поставка будет подготовлена к работе, она автоматически перейдет в статус **Копируется**. В этом статусе она будет находиться до тех пор, пока все данные, находящиеся в источнике, не будут перенесены на приемник. Затем поставка автоматически деактивируется и перейдет в статус **Завершен**. Переход между статусами показан на схеме:

![lifecycle-copy](../../../../_assets/data-transfer/lifecycle/copy.svg)

## Регулярное копирование {#regular-copy}

Копирование с обновлением данных по расписанию запускается через определенные интервалы времени. При нем в приемник попадают только те данные, которые были изменены в источнике с момента предыдущего копирования. Этот подход позволяет обновлять данные в приемнике с минимальными задержками и с низкой нагрузкой на источник данных, но не учитывает операции удаления данных в источнике. Копирование только измененных строк позволяет сократить объем передаваемых данных по сравнению с копированием таблиц целиком.

Чтобы найти измененные данные, в таблице используется _колонка курсора_ (ключевая колонка), значения в которой меняются при каждом добавлении или обновлении данных. Для колонки курсора необходимо построить индекс, чтобы каждый вызов не приводил к полному сканированию таблицы (fullscan). Если в таблицу только добавляются данные, в качестве колонки курсора подходит столбец `id`. Если в таблице могут изменяться существующие данные, в качестве колонки курсора рекомендуется добавить столбец `updated_at` с [временным](https://postgrespro.ru/docs//postgresql/current/datatype-datetime) типом данных и записывать в него текущее время при каждом изменении. Трансфер запоминает максимальное значение в колонке курсора и при следующей активации будет считывать только те данные, которые были добавлены или обновлены с момента последнего запуска.

{% cut "Рекомендации по настройке" %}

В качестве колонки курсора можно указывать столбцы таблиц с [числовым](https://postgrespro.ru/docs//postgresql/current/datatype-numeric), [символьным](https://postgrespro.ru/docs//postgresql/current/datatype-character) или [временным](https://postgrespro.ru/docs//postgresql/current/datatype-datetime) типом данных. А, например, тип данных [UUID](https://postgrespro.ru/docs//postgresql/current/datatype-uuid) не подойдет.

Чтобы периодическое инкрементальное копирование давало корректный результат, в таблице источника должны выполняться следующие условия:

* Значения колонки курсора должны строго возрастать и не принимать значение `null`.
* Значения в колонке курсора должны изменяться при добавлении и изменении данных.
* Данные не должны удаляться. Если удаление необходимо, сохраняйте данные для удаления в другую таблицу и поставляйте отдельно.

{% endcut %}

Подробнее о том, [как создать регулярное копирование](../../operations/data-transfer/regular-copy.md).

## Разовое копирование {#one-time-copy}

Разовое копирование однократно переносит данные из источника в приемник. Последующие изменения источника не переносятся. Поставка этого типа может быть полезна, когда на источнике нет пишущей нагрузки, например, [при развертывании тестовых сред](../../../../data-transfer/concepts/use-cases.md#testing) или когда надо перенести большой объем первичных данных.

Подробнее о том, [как создать разовое копирование](../../operations/data-transfer/one-time-copy.md).

## Захват изменений данных {#cdc} `Скоро`

CDC (change data capture — [захват изменений данных](https://en.wikipedia.org/wiki/Change_data_capture)) — это процесс отслеживания изменений в базе данных и поставка этих изменений к потребителям в режиме почти реального времени. CDC может применяться для случаев когда минимальная задержка времени и свежесть данных критичны, а также когда критично получить перечень всех изменения внутри источника данных.

Одним из способов реализации CDC-подхода может быть поставка из базы данных в брокер сообщений. Все обновления в базе отслеживаются и отправляются в брокер сообщений, а потребители подключаются к брокеру и считывают поступающие сообщения, и в дальнейшем из брокера сообщений изменения поступают в REST-каталог.