Взаимосвязь ресурсов в Data Transfer

Статья создана

Yandex Cloud

улучшена

Andrey D.

Эндпоинт
Трансфер
- Типы трансферов
- Совместимость источников и приемников
Особенности сервиса
- Обработка пустых объектов
- Обработка представлений (VIEW)
Работа сервиса с источниками и приемниками

Yandex Data Transfer помогает переносить данные между СУБД, объектными хранилищами или брокерами сообщений. Сервис позволяет сократить время на процесс миграции и минимизировать простой при переключении на новую базу данных.

Yandex Data Transfer настраивается через стандартные интерфейсы Yandex Cloud.

Сервис подходит для создания постоянной реплики базы. Перенос схемы базы данных из источника на приемник автоматизирован.

Эндпоинт

Эндпоинт — это конфигурация для подключения к сервису-источнику или приемнику данных. Кроме настроек подключения, эндпоинт может содержать информацию о том, какие данные будут участвовать в трансфере и как они должны быть обработаны в процессе переноса.

В качестве источника или приемника данных могут выступать:

Сервис	Источник	Приемник
Топик Apache Kafka® — собственный или в составе сервиса Managed Service for Apache Kafka®
Поток сообщений AWS CloudTrail
Собственная база данных BigQuery
База данных ClickHouse — собственная или в составе сервиса Managed Service for ClickHouse
База данных Greenplum® — собственная или в составе сервиса Managed Service for Greenplum®
База данных MongoDB — собственная или в составе сервиса Managed Service for MongoDB
База данных MySQL — собственная или в составе сервиса Managed Service for MySQL
Собственная база данных Oracle
База данных PostgreSQL — собственная или в составе сервиса Managed Service for PostgreSQL
S3-совместимый бакет
Поток данных Yandex Data Streams
База данных Managed Service for YDB — в составе сервиса Managed Service for YDB
Бакет Yandex Object Storage

Трансфер

Трансфер — это процесс переноса данных между сервисом-источником и сервисом-приемником. Он должен находиться в одном каталоге с используемыми эндпоинтами.

Если для эндпоинтов заданы подсети, то они должны быть размещены в одной зоне доступности. Иначе активация трансфера с такими эндпоинтами завершится с ошибкой.

Типы трансферов

Трансферы бывают следующих типов:

Копировать — переносит снапшот источника на приемник.
Реплицировать — непрерывно получает изменения из источника и применяет их на приемнике. При этом первоначальная синхронизация данных не выполняется.
Копировать и реплицировать — переносит текущее состояние источника на приемник и поддерживает его актуальность.

Подробнее о различиях между типами трансферов читайте в разделе Жизненный цикл трансфера.

Совместимость источников и приемников

Доступные комбинации источников и приемников:

Источник \ Приемник	Apache Kafka®	ClickHouse	Greenplum®	MongoDB	MySQL	PostgreSQL	YDB	Object Storage	Приемник / Источник
Airbyte®	-	К¹	-	К¹	К¹	К¹	К¹	-	Airbyte®
Apache Kafka®	P¹	P¹	P¹	-	-	-	P¹	P¹	Apache Kafka®
ClickHouse	-	К	-	-	-	-	-	-	ClickHouse
Greenplum®	-	К	К¹	-	-	К¹	-	-	Greenplum®
MongoDB	-	-	-	КР	-	-	-	К¹	MongoDB
MySQL	КР	КР	-	-	КР	-	КР¹	К¹	MySQL
Oracle	-	КР¹	-	-	-	КР¹	-	-	Oracle
PostgreSQL	КP	КР	К¹	-	-	КР	КР¹	К¹	PostgreSQL
YDB	-	К¹	-	-	-	-	-	К¹	YDB
Yandex Data Streams	-	Р¹	Р¹	Р¹	-	Р¹	P¹	P¹	Yandex Data Streams

К — Копирование
Р — Репликация
КР — Копирование и репликация

¹ Функциональность находится на стадии Preview.
² Функциональность находится на стадии Preview и предоставляется по запросу. Обратитесь в техническую поддержку или к вашему аккаунт-менеджеру.

Эндпоинты Airbyte®

С помощью Airbyte® можно настроить следующие эндпоинты-источники:

Особенности сервиса

Обработка пустых объектов

Трансферы между эндпоинтами разных типов (например, из PostgreSQL в ClickHouse) переносят только непустые объекты. Например, таблицы (в реляционных базах данных), не содержащие кортежей или содержащие нулевое число полей, не переносятся.

Трансферы между эндпоинтами одного типа (например, из PostgreSQL в PostgreSQL) переносят пустые объекты как часть схемы.

Обработка представлений (`VIEW`)

В общем случае Yandex Data Transfer переносит VIEW (из баз, где такие объекты могут существовать) с некоторыми ограничениями:

Трансферы типа Реплицировать не реплицируют изменения над данными VIEW;
Трансферы типов Копировать и Копировать и реплицировать (на стадии копирования) между эндпоинтами одного типа (например, из PostgreSQL в PostgreSQL) переносят VIEW только как часть схемы. Данные (строки) в VIEW не переносятся. Перенос схемы регулируется настройкой "Перенос схемы" и смежными настройками, доступными в некоторых эндпоинтах-источниках;
Трансферы типов Копировать и Копировать и реплицировать (на стадии копирования) между эндпоинтами разных типов (например, из PostgreSQL в ClickHouse) переносят VIEW как обыкновенные таблицы (не как представления). Эта функция позволяет трансформировать и экспортировать данные во внешние базы данных и может быть особенно полезна в регулярных трансферах типа Копировать.

Отдельные источники могут налагать дополнительные ограничения на перенос VIEW и аналогичных объектов.

Работа сервиса с источниками и приемниками

ClickHouse

Трансферы типов Копировать и Копировать и реплицировать (на стадии копирования) из ClickHouse в ClickHouse не поддерживают работу с VIEW. В эндпоинте-источнике типа ClickHouse VIEW должны быть включены в "Список исключённых таблиц", если "Список включённых таблиц" пуст или не указан. Если "Список включённых таблиц" непустой, в нём не должно присутствовать объектов VIEW.

Источник поддерживает MATERIALIZED VIEW, но работает с ними как с обыкновенными таблицами. Таким образом, в трансферах из ClickHouse в ClickHouse MATERIALIZED VIEW переносятся как таблицы, а не как объекты MATERIALIZED VIEW.

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

При переносе данных из строковых СУБД будут использоваться движки ReplicatedReplacingMergeTree и ReplacingMergeTree.
При переносе данных из ClickHouse будут использоваться движки семейства ReplicatedMergeTree.

Greenplum®

В трансферах из Greenplum® в Greenplum® и из Greenplum® в PostgreSQL схема не переносится в текущей версии Yandex Data Transfer. При наличии пользовательских типов данных в таблицах в таких трансферах, такие пользовательские типы необходимо создать в целевой базе данных вручную до запуска трансфера. Для переноса схемы вручную можно использовать утилиту pg_dump.

Источник считает FOREIGN TABLE и EXTERNAL TABLE обыкновенными представлениями и работает с ними в соответствии с общим алгоритмом для VIEW.

Источник никогда не переносит данные из MATERIALIZED VIEW, даже в трансферах из Greenplum® в другую базу данных.

MongoDB

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

Трансфер в MongoDB не переносит индексы. Когда трансфер перейдет в статус Реплицируется, создайте индекс для каждой шардируемой коллекции вручную:

db.<имя коллекции>.createIndex(<свойства индекса>)

Описание функции createIndex() см. в документации MongoDB.

PostgreSQL

Источник никогда не переносит данные из MATERIALIZED VIEW, даже в трансферах из PostgreSQL в другую базу данных. В трансферах из PostgreSQL в PostgreSQL MATERIALIZED VIEW считаются обыкновенными представлениями и обрабатываются в соответствии с общим алгоритмом для VIEW.

Источник считает FOREIGN TABLE обыкновенными представлениями и работает с ними в соответствии с общим алгоритмом для представлений.

Если в источнике трансфера из PostgreSQL в PostgreSQL задан непустой "Список включённых таблиц", пользовательские типы данных, присутствующие в этих таблицах, не переносятся. В этом случае перенесите пользовательские типы данных вручную.

При переносе партиционированных таблиц необходимо учитывать следующее:

Для таблиц, партиционированных декларативным методом:
- Пользователю необходим доступ к основной таблице и всем ее партициям на источнике.
- Трансфер выполняется по принципу как есть: на приемнике будут созданы все партиции и основная таблица.
- На этапе копирования партиции переносятся на приемник независимо друг от друга. Благодаря этому пользователь может ускорить трансфер, включив шардирование в настройках трансфера.
- На этапе репликации данные будут автоматически попадать в нужные партиции.
- Если после того, как трансфер перешел на этап репликации, на источнике будут созданы новые партиции, необходимо будет перенести их на приемник вручную.
- Пользователь может перенести на приемник только часть партиций. Для этого он должен добавить эти партиции в Список включенных таблиц или закрыть доступ к ненужным партициям на источнике.
Для таблиц, партиционированных методом наследования:
- Пользователю необходим доступ к родительской таблице и всем таблицам-наследникам.
- На этапе копирования данные из таблиц-наследников не дублируются в родительскую таблицу. Чтобы перенести данные из таблиц-наследников, их необходимо явно указать в списке переносимых таблиц.
- На этапе копирования таблицы-наследники переносятся на приемник независимо друг от друга. Благодаря этому пользователь может ускорить трансфер, включив шардирование в настройках трансфера.
- На этапе репликации данные будут автоматически попадать в нужные таблицы-наследники или в родительскую таблицу, если наследование используется не для партиционирования.
- Если после того, как трансфер перешел на этап репликации, на источнике будут созданы новые таблицы-наследники, необходимо будет перенести их на приемник вручную.
При переносе базы данных из PostgreSQL в другую СУБД пользователь может включить в эндпоинте-источнике настройку Объединять наследуемые таблицы. В этом случае:
- На приемник будет перенесена только родительская таблица, которая будет содержать данные тех таблиц-наследников, которые были явно указаны в списке переносимых таблиц.
- Пользователь по-прежнему может ускорить трансфер, включив шардирование в настройках трансфера, поскольку копирование таблиц-наследников с источника в общую таблицу на приемнике происходит параллельно.

Yandex Data Streams

По умолчанию при переносе данных из Data Streams в ClickHouse для каждой партиции создается отдельная таблица. Чтобы все данные попадали в одну таблицу, укажите правила конвертации в дополнительных настройках эндпоинта для источника.

Oracle

Источник игнорирует VIEW и MATERIALIZED VIEW в трансферах любого типа.