Поставки данных в Yandex DataLens Platform
Поставка данных переносит данные из внешнего подключения-источника (например, базы PostgreSQL) в хранилище на основе REST-каталога. В Yandex DataLens Platform вы можете создавать поставки разных типов:
- регулярное копирование — используйте, когда есть постоянная потребность в поставке данных и необходимость поддерживать приемник данных в актуальном состоянии;
- разовое копирование — используйте, когда нет постоянной потребности в поставке данных, например, для развертывания тестовых сред или для загрузки первичной порции данных;
- захват изменений данных (CDC)
Скоро— используйте для сценариев, когда важно отслеживать изменения данных в реальном времени.
Примечание
В настоящий момент в Yandex DataLens Platform поддерживаются поставки данных из подключений PostgreSQL, MySQL® и ClickHouse®.
Если нужный источник пока не поддерживается поставками данных, загрузку можно организовать с помощью кода в Apache Spark™ или подключения к источнику в Trino. Возможность подключения зависит от доступных библиотек и коннекторов.
После создания поставки вы можете просматривать статистику, изменять настройки, приостанавливать или удалять поставку.
Жизненный цикл поставки
Когда поставка будет подготовлена к работе, она автоматически перейдет в статус Копируется. В этом статусе она будет находиться до тех пор, пока все данные, находящиеся в источнике, не будут перенесены на приемник. Затем поставка автоматически деактивируется и перейдет в статус Завершен. Переход между статусами показан на схеме:
Регулярное копирование
Копирование с обновлением данных по расписанию запускается через определенные интервалы времени. При нем в приемник попадают только те данные, которые были изменены в источнике с момента предыдущего копирования. Этот подход позволяет обновлять данные в приемнике с минимальными задержками и с низкой нагрузкой на источник данных, но не учитывает операции удаления данных в источнике. Копирование только измененных строк позволяет сократить объем передаваемых данных по сравнению с копированием таблиц целиком.
Чтобы найти измененные данные, в таблице используется колонка курсора (ключевая колонка), значения в которой меняются при каждом добавлении или обновлении данных. Для колонки курсора необходимо построить индекс, чтобы каждый вызов не приводил к полному сканированию таблицы (fullscan). Если в таблицу только добавляются данные, в качестве колонки курсора подходит столбец id. Если в таблице могут изменяться существующие данные, в качестве колонки курсора рекомендуется добавить столбец updated_at с временным типом данных и записывать в него текущее время при каждом изменении. Трансфер запоминает максимальное значение в колонке курсора и при следующей активации будет считывать только те данные, которые были добавлены или обновлены с момента последнего запуска.
Рекомендации по настройке
В качестве колонки курсора можно указывать столбцы таблиц с числовым, символьным или временным типом данных. А, например, тип данных UUID не подойдет.
Чтобы периодическое инкрементальное копирование давало корректный результат, в таблице источника должны выполняться следующие условия:
- Значения колонки курсора должны строго возрастать и не принимать значение
null. - Значения в колонке курсора должны изменяться при добавлении и изменении данных.
- Данные не должны удаляться. Если удаление необходимо, сохраняйте данные для удаления в другую таблицу и поставляйте отдельно.
Подробнее о том, как создать регулярное копирование.
Разовое копирование
Разовое копирование однократно переносит данные из источника в приемник. Последующие изменения источника не переносятся. Поставка этого типа может быть полезна, когда на источнике нет пишущей нагрузки, например, при развертывании тестовых сред или когда надо перенести большой объем первичных данных.
Подробнее о том, как создать разовое копирование.
Захват изменений данныхСкоро
CDC (change data capture — захват изменений данных) — это процесс отслеживания изменений в базе данных и поставка этих изменений к потребителям в режиме почти реального времени. CDC может применяться для случаев когда минимальная задержка времени и свежесть данных критичны, а также когда критично получить перечень всех изменения внутри источника данных.
Одним из способов реализации CDC-подхода может быть поставка из базы данных в брокер сообщений. Все обновления в базе отслеживаются и отправляются в брокер сообщений, а потребители подключаются к брокеру и считывают поступающие сообщения, и в дальнейшем из брокера сообщений изменения поступают в REST-каталог.