Большое число компаний стремятся реализовать высокоскоростную и надежную репликацию данных. В поиске наилучшего решения компании сталкиваются с выбором между коммерческими и open-source решениями. В данном сравнительном тесте рассматриваются две альтернативы: Датафлот Репликация, российская разработка, и Debezium, международная open-source платформа на базе Apache Kafka. Датафлот Репликация демонстрирует значительное преимущество в скорости обработки данных и снижении нагрузки на сервер-источник. Благодаря использованию прямого анализа (парсинга) логов БД. В тестах его парсер оказался быстрее Debezium в 6,6–10,9 раз, а нагрузка на сервер снизилась в 8,3–9,8 раз. В отличие от Debezium, Датафлот также поддерживает репликацию изменений структур данных (DDL-операций) в Postgres. Debezium, будучи open-source решением, требует дополнительного развертывания и администрирования инфраструктуры Kafka, и не предоставляет технической поддержки производителя. Его работа с API СУБД создает дополнительную нагрузку на сервер, а управление системой ограничено консольными инструментами. В результате тестирования Датафлот Репликация продемонстрировал уверенное преимущество в производительности, удобстве развертывания и низкой нагрузки на сервер, особенно при работе с копиями логов на отдельном сервере. Система может работать в различных видах развертывания, в том числе отдельных компонентов для чтения и записи на серверах-источниках и серверах-получателях, соответственно. Эти особенности делают Датафлот перспективным выбором для компаний, которым критичны стабильность, скорость обработки и поддержка на русском языке. Сводная информация о сравнении решений для репликации данных Датафлот Репликация и Debezium.

Датафлот Репликация: российское коммерческое решение для репликации транзакционных данных, использующее в основе захват изменений данных в журналах баз данных источников (Change Data Capture) и осуществляющее доставку изменений в гетерогенные системы-приемники. Ядро системы (бэк), компоненты парсинга и загрузки реализованы на C++. Решение Датафлот Репликация зарегистрировано в едином реестре российского ПО, реестровая запись №18777 от 22.08.2023. Мастер-дистрибьютор решения: компания DIS Group. Техническая поддержка 24×7 на русском языке. Документация и пользовательские интерфейсы на русском языке.

Платформа Debezium: open source проект, по сути, представляет собой набор совместимых с Apache Kafka Connect специализированных коннекторов, осуществляющих чтение изменений журналов БД различных типов и передающих данные об изменениях в топики Apache Kafka. Требует для работы развертывания инфраструктуры Kafka. Техническая поддержка на русском языке отсутствует/реализуется внутренними командами. Документация на английском языке. Пользовательские интерфейсы – практически отсутствуют, управление из консоли, скриптами или из внешних приложений.

1.Ядро системы (бэк), компоненты парсинга и загрузки Датафлот реализованы на C++. Debezium использует инфраструктуру kafka: zookeeper, kafka, kafka connect/debezium connectors, стек Java. 2.Установка Датафлот Репликации представляет собой простое развертывание архива на сервере linux. Установка Debezium требует развертывания инфраструктуры kafka: zookeeper, kafka, kafka connect/debezium connectors. 3. Датафлот Репликация позволяет использовать прямой парсинг логов БД, в то время как Debezium использует API СУБД и plugin-ы для работы с API. Использование решением Датафлот Репликация прямого парсинга логов БД в сравнении с работой решения Debezium через API СУБД дает выигрыш в скорости обработки данных парсером Датафлот в 6,6 – 10,9 раз при снижении нагрузки на сервер-источник СУБД в 8,3 – 9,8 раз (при парсинге логов находящихся непосредственно на сервере СУБД). Дополнительная утилизация CPU на источнике при работе Debezium (только overhead) составляла при проведении тестов 20-25%. При работе решения Датафлот с копиями логов, перенесенными на другой сервер, Датафлот вообще не оказывает влияния на сервер-источник при парсинге логов. 4. Использование прямого парсинга логов Postgres Датафлотом позволяет реплицировать DDL операции. Работа Debezium через API Postgres не позволяет реплицировать DDL операции. 5. По результатам тестирования производительности решение Датафлот Репликация показало многократный выигрыш в скорости первоначальной синхронизации и в скорости репликации изменений (см. документ Сравнительный тест Датафлот vs Debezium.pdf). 6. Датафлот Репликация зарегистрирован в едином реестре российского ПО. Предоставляется техническая поддержка 24×7 на русском языке. Документация и пользовательские интерфейсы на русском языке. Для Debezium техническая поддержка на русском языке отсутствует или реализуется внутренними командами. Документация на английском языке.

Чем больше объем данных в компании, тем более эффективные технологии по управлению и обработке данных необходимы бизнесу. Инструменты ETL и ELT играют ключевую роль в процессе обработки данных и загрузки их в системы для анализа и дальнейшего использования. Далее рассмотрим подробнее основные принципы и различия между этими двумя процессами.

ETL (Extract, Transform, Load) и ELT (Extract, Load, Transform) — это процессы управления данными. ETL представляет собой процесс извлечения данных из различных источников, их трансформации (очистка, преобразование, объединение) и загрузки в целевую базу данных или хранилище данных. ELT — это процесс, при котором данные сначала извлекаются и загружаются в хранилище данных, а затем происходит их трансформация. Обе системы играют важную роль в обработке данных компании, обеспечивая их достоверность для дальнейшей аналитики. Основные отличия подходов:

1. Порядок процесса трансформации данных;
2. Работа с разным размером данных (системы ELT обрабатывают более большие объемы данных);
3. Работа с неструктурированными данными: в процессе ELT в целевое хранилище данных или базу данных могут передаваться как структурированные, так и неструктурированные данные, в отличие от ETL.

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

• при интеграции данных в процессе наполнения озер и хранилищ данных;
• при передаче данных для последующего машинного обучения;
• при объединении и структуризации данных о спросе, покупках и других аспектах;
• при интеграции информации IoT в одну систему;
• при проверке качества данных и их очистке;
• при репликации данных и их передаче в облако.

Среди преимуществ ETL: наличие контролируемой среды для сложных преобразований, возможность приводить данные из разных систем в единый согласованный формат и осуществлять сложные преобразования данных, вносить значительные изменения в структуру данных, снижать требования к ресурсам аналитики благодаря трансформации данных до загрузки в целевую систему, также это может приводить к уменьшению их объема, что экономит место и снижает затраты на инфраструктуру. ETL способствует повышению производительности запросов на этапе загрузки в целевую систему при трансформации данных и обеспечивает безопасность данных (есть возможность шифрования), это актуально при отправке данных во внешние системы. Из недостатков ETL: необходимость достаточного количества ресурсов, вычислительной мощности и емкости хранилища при большом объеме данных, риск пропуска данных, если правила преобразования не достаточно разработаны и протестированы, предварительная трансформация данных увеличивает время загрузки данных в целевую систему.

ELT-подход работы с данными решает те же интеграционные задачи, что и ETL, но имеет свои особенности. При ETL необходимо сначала определить, какие действия будут выполнены с данными, задать метрики и затем приступать к загрузке и использованию данных. А при ELT трансформация данных переносится на конец процесса и выполняется по требованию в зависимости от конкретных задач и запросов. Это обеспечивает большую гибкость в использовании данных. ELT-подход становится все более популярным с развитием технологий хранения данных, таких как озера данных и облачные хранилища, которые позволяют эффективно обрабатывать данные после их загрузки. В том числе это касается больших объемов данных. Плюсы ELT:

• Быстрая загрузка большого объема данных в целевую систему, так как их трансформация происходит после загрузки;
• Гибкость обработки данных и возможности расширенной аналитики;
• Возможность обработки больших объемов данных;
• Широкое применение в работе с облачными хранилищами;
• Низкая вероятность потери данных при изменении методологии или появлении ошибок.

Минусы ELT:

• Необработанные данные требуют больше времени для аналитики;
• Необходимость дополнительных инструментов для управления качеством данных;
• Большие затраты на инфраструктуру и хранение данных;
• Зависимость от конкретных решений для хранения данных.

Работа ETL состоит из нескольких этапов: 1. Извлечение данных из источника В качестве источников информации могут выступать различные виды систем, бизнес приложения, мобильные приложения, веб-сайты, инструменты передачи данных с датчиков IoT, транзакционные и аналитические СУБД, структурированные и неструктурированные файлы и т.д. Данные из различных источников зачастую имеют разные форматы, поэтому важно определить целевые данные и связи между данными и их источником. На этом этапе проверяется соответствие извлеченной информации исходной, наличие нежелательных данных и соответствие информации требованиям хранилища, в которое будут перенесены данные. На этом этапе важно учитывать:

• количество и состав данных, загруженных из источника;
• требования к времени загрузки данных;
• особенности загрузки;
• загрузку данных с ошибками (может потребоваться разделение пакета файлов на части).

2. Трансформация данных На этом этапе данные подвергаются преобразованию, агрегации, обогащению и другим операциям для подготовки к загрузке. 3. Загрузка данных в целевую систему Существуют различные способы загрузки данных:

• первичная загрузка, когда данные загружаются в систему-приемник впервые;
• инкрементная загрузка, при которой данные обновляются периодически;
• полное обновление, когда все содержимое системы-приемника удаляется и заменяется последними данными.

В случае процесса ELT этапы загрузки и трансформации данных меняются местами. Поэтому процесс выглядит следующим образом: 1. Извлечение данных из источника Данные могут быть извлечены полностью или частично. 2. Загрузка данных в целевую систему После извлечения данные загружаются в целевую систему. Этот этап включает в себя различные методы загрузки данных, такие как инкрементная, полная или потоковая загрузка. 3. Трансформация данных После загрузки данных в целевую систему происходит их трансформация. На этом этапе данные обрабатываются, очищаются, преобразуются и агрегируются для дальнейшего использования. ELT обычно используется в случаях, когда требуется обработка больших объемов данных и когда хранилище данных обладает достаточной мощностью для выполнения трансформаций после загрузки, так как эта работа с данными происходит в целевой системе.

Выбор инструментов ETL и ELT зависит от конкретных требований проекта, объема данных, сложности трансформаций и доступных ресурсов. Следующие вопросы помогут определиться с выбором:

• Какой объем данных необходимо обработать и есть ли много неструктурированных данных?
• Какие типы данных есть (структурированные, полуструктурированные, нестуркутурированные)?
• Как часто они обновляются и изменяются?
• Каковы требования к скорости обработки данных?
• Какие инструменты и технологии для обработки данных уже используются в компании, какие облачные решения, и поддерживают ли они ELT?
• Нуждаются ли данные для загрузки в целевую систему в сложной трансформации?
• Есть ли у сотрудников в компании навыки работы с ETL и ELT-инструментами?
• Какие аналитические задачи стоят перед компанией, необходимы ли гибкие возможности для анализа данных?
• Есть ли требования по безопасности данных и управлению доступом к данным?
• Какой бюджет есть для работы с ETL и ELT-инструментами, есть ли ресурсы для поддержки выбранного подхода?
• Будет ли в будущем увеличиваться объем данных и сложность аналитики?

ELT подходит, когда требуется быстрая загрузка данных без предварительной трансформации, сохранение необработанных или неизмененных данных для анализа, обработка данных в условиях, близких к реальному времени, и когда происходят частые изменения в структуре данных. ETL обычно применяется в случаях, когда нужна значительная трансформация данных перед загрузкой в целевое хранилище данных, при наличии сложных требований к структурированию данных, при работе с большими объемами данных, когда необходимо оптимизировать процесс трансформации перед загрузкой, при работе с устаревшими системами, когда требуется преобразовать данные. Также при ETL снижается риск утечки конфиденциальной информации, создаются агрегированные наборы данных во время преобразования. Интегрировать корпоративные данные для создания отчетности и подготовки данных для аналитики удобно с помощью решения Плюс7 ФормИТ. Его можно использовать при решении задач построения единого цифрового пространства и цифровой компании, в основе которой лежит интеграция и быстрый обмен данными между подразделениями или юридическими лицами. Из ключевых возможностей решения: выгрузка данных из любых источников, обработка любых типов данных, улучшение качества данных, маскирование, работа с Hadoop, формирование документов по требованию, управление рассылками и шаблонами. Плюс7 ФормИТ может использоваться в разных сферах бизнеса. Например, для интеграции данных его использовал Московский кредитный банк. Задачи, которые требовалось решить компании: быстрое и точное построение аналитической и управленческой отчётности для различных подразделений банка, замещение иностранной ETL-платформы отечественным аналогом без потери эффективности и нарушения бизнес-процессов, бесперебойная поставка качественных, актуальных и достоверных данных для принятия управленческих решений на их основе. В результате использования решения в сжатые сроки была подготовлена и начата миграция на отечественную ETL-платформу без потери операционной эффективности, а также произошло выполнение SLA по поставке данных в срок. Сравнительные характеристики процессов:

При интеграции данных компаниями широко используются инструменты ETL и ELT. Они автоматически передают информацию в хранилище из разных источников, структурируют и повышают качество данных. Это положительно сказывается на аналитике и способствует увеличению прибыли в бизнесе.

Предлагаем Вам посмотреть вебинар в записи «Как просто и быстро создать реплику данных в гетерогенной среде» от компании DIS Group. На вебинаре эксперты компании говорят о том, как создавать и поддерживать реплики данных в гетерогенных средах, с использованием российского ПО. Ключевые темы, которые рассмотрены на вебинаре:

• Сравнение решения Датафлот Репликации с Debezium и Oracle GoldenGate
• Типовые сценарии использования решения
• Основные возможности решения, источники и приемники данных
• Примеры развертывания решения, принципы лицензирования и дорожная карта развития Датафлот Репликации

Вебинар полезен специалистам, работающим в области интеграции данных, архитекторам и IT-специалистам. Датафлот Репликация – качественное решение промышленного уровня, включено в реестр российского ПО. Решение основано на использовании принципов Change Data Capture (CDC).

• Василий Хасанов, Заместитель технического директора, DIS Group

Современные предприятия располагают огромными объёмами данных самых разных типов. Из-за этого при работе система, в которой хранятся данные, может испытывать высокую нагрузку, что приводит к снижению ее производительности. В таком случае можно прибегнуть к репликации данных.

Репликация данных – это процесс перемещения или копирования данных в резервное место хранения в реальном времени. С помощью репликации можно создавать копии данных высоконагруженных систем. Далеко не всегда можно обратиться напрямую к какой-либо системе, чтобы в неограниченном количестве запросов использовать ее данные. Это не только может замедлять ее работу, но и приводить к остановке бизнес-процессов в случае сбоя в работе системы. Чтобы этого избежать, с помощью репликации создается одна или несколько резервных копий данных системы, в том числе хранилища данных. Когда чаще всего используется репликация:

1. Для снижения нагрузки на информационную систему: данные реплицируются из высоконагруженной базы данных в режиме близком к реальному времени в другую систему;
2. Для оперативной отчетности при предоставлении данных из транзакционных систем в хранилище данных;
3. Для аудита систем, чтобы понимать кто и как менял данные в базе данных;
4. Для миграции данных из одной базы данных в другую с минимальным временем простоя.

Репликация данных бывает разных видов:

• Однонаправленная (задачи: организация онлайн-копий, миграция данных, обновление версий, распределение нагрузки чтения данных);
• Двунаправленная (задачи: построение отказоустойчивых систем, поэтапная миграция данных, синхронизация данных OLTP системами);
• Каскадная (задачи: организация нескольких копий данных без нагрузки источника, снижение нагрузки на хранилище данных, построение хранилищ и озер данных).

При проведении репликации данных бизнес должен учитывать несколько ключевых аспектов, чтобы обеспечить эффективность и безопасность процесса:

1. Выбор подходящего вида репликации в зависимости от потребностей в доступности, производительности и безопасности данных в компании;
2. Настройка параметров репликации: необходимо правильно настроить параметры репликации, такие как частота обновлений, метод синхронизации, обработка конфликтов и т.д. Это поможет избежать проблем с целостностью данных и обеспечить эффективную работу системы;
3. Мониторинг и управление репликацией. Это поможет предотвратить потерю данных и снизить риск простоев системы;
4. Безопасность данных: при репликации данных необходимо обеспечить их защиту от несанкционированного доступа и утечек информации;
5. Резервное копирование и восстановление данных: важно иметь планы резервного копирования данных и процедуры восстановления в случае сбоев в процессе репликации. Это поможет минимизировать потенциальные потери и обеспечить быстрое восстановление работоспособности системы.

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

Репликация данных включает в себя несколько шагов: определение системы-источника и системы-приемника, выбор данных, которые нужно будет копировать, сроков (как часто необходимо делать обновление), определение метода репликации данных (полный, частичный), выбор ПО для осуществления репликации. Исходя из бизнес-задач, которые стоят перед компанией, она выбирает то или иное решение для репликации. Например, Датафлот Репликация поддерживает широкий спектр источников, целей и платформ, упрощает операции чтения и записи, использует все доступные вычислительные мощности для создания реплики, обеспечивает готовность и доступность соответствующих данных в тот момент, когда они необходимы, обеспечивает доступ к данным в режиме реального времени, позволяет развивать передовую аналитику, машинное обучение и искусственный интеллект. Датафлот Репликация – это промышленное решение, использующее журналы базы данных той системы, с которой работает, чтобы отслеживать все изменения, происходящие в данных в любой момент времени. Затем решение формирует блок данных, передавая его на сторону приемника данных (системы, в которой будут храниться копии). Системы-приемники могут быть разных типов в одном процессе репликации. Решение позволяет обогащать реплику данных такими значениями, как дата изменения, тип операции, выполняемой на стороне источнике, значения бизнес полей до их изменения, и выполнять небольшие трансформации данных: преобразование типов, расчет значений атрибутов, обработка строк и т.п. Датафлот Репликация может отслеживать изменение структуры данных источника: если структура данных источника будет меняться, то изменится и среда той копии, которая создается.

Решение поддерживает и возможность аудита. Аудит представляет собой загрузку данных в приемник как лог DML изменений данных, производимых в источнике. Он нужен для разбора внештатных ситуаций, отслеживания последовательности и полноты DML операций, передаваемых с источника, аудита действий пользователей в системе-источнике (отслеживания кто, когда и что изменил в данных). Важные особенности Датафлот Репликации:

• возможность работы с большим количеством реляционных источников и большим количеством приемников данных, включая нереляционные базы данных (данные можно перенести в любую on-premise или облачную базу данных, озеро или хранилище);
• визуальная разработка (пользователь указывает, какие данные необходимо выбрать для работы и в каком виде они будут находиться в системе-приемнике);
• поддержка транзакционной целостности и согласованности данных;
• автоматическое восстановление при сбоях;
• минимальное воздействие на системы-источники;
• многопоточность загрузки данных;
• возможность трансформации данных;
• высокая производительность;
• репликация больших объемов изменений;
• наличие механизмов первичной синхронизации данных;
• мониторинг производительности и процесса (в решении заложена возможность аудита, чтобы всегда можно было отследить сбой на любом этапе и чтобы впоследствии система правильно работала без потери записей данных);
• данные можно копировать в обновленном виде и синхронизировать с любым их источником;
• клонирование схем источников в приемники.

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

Под любой миграцией понимают перемещение чего-то или кого-то из одного места в другое. По этому же принципу работает миграция баз данных (БД). Миграция данных – процесс, все этапы которого необходимо тщательно спланировать. Это позволит сохранить целостность и безопасность ваших данных при их переносе. Сначала необходимо изучить исходную базу данных и определить, какие данные нужно перенести, какие будут удалены или объединены. Кроме того, важно определить, какой формат данных будет использоваться в целевой системе. Одним из наиболее важных этапов миграции данных является тестирование. Оно позволяет убедиться, что все данные были правильно перенесены и работают в новом окружении. Это также помогает выявить и устранить возможные проблемы или ошибки до того, как они окажутся в живой среде. Важно также уделить внимание безопасности данных. При миграции данных нужно обеспечить защиту конфиденциальной информации и избежать утечек данных или несанкционированного доступа к ним. Если у вас нет необходимых навыков и опыта для проведения миграции данных, рекомендуется обратиться к профессионалам. Специалисты в области ИТ смогут помочь вам спланировать и выполнить процесс миграции данных таким образом, чтобы вы избежали потери информации или проблем с функционированием системы.

Миграция данных может потребоваться при обновлении программного обеспечения, переходе на новую платформу, объединении баз данных или при переезде в облако, а также при импортозамещении систем управления данными. Независимо от причины, миграция данных — критически важный этап, который требует тщательного планирования и исполнения.

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

• Миграция баз данных. Этот тип миграции включает перенос данных из одной базы данных в другую. Он может быть выполнен для обновления базы данных до новой версии, смены поставщика системы управления базами данных (СУБД) или объединения нескольких баз данных в одну.
• Миграция приложений. Этот вид миграции включает перенос данных, связанных с конкретным приложением, из одной среды выполнения в другую. Например, при переносе приложения из локальной сети в облако или на другой сервер.
• Миграция облачных данных. Этот тип миграции включает перенос данных из одного облачного провайдера в другой или из облака в локальное хранилище. Он может быть выполнен из-за изменения условий предоставления облачных услуг или для сохранения резервной копии данных.
• Миграция центра обработки данных (ЦОД). Этот вид миграции включает перенос данных из одного ЦОД в другой. Он может быть выполнен для улучшения инфраструктуры, смены поставщика услуг ЦОД или из-за роста бизнеса.
• Миграция операционных систем. Этот тип миграции включает перенос данных при смене операционной системы. Например, при переносе с Windows на Linux или наоборот. Каждый из этих видов миграции данных требует особого подхода и набора инструментов для успешного выполнения. Кроме того, необходимо учитывать возможные риски и потери данных при миграции, поэтому важно провести тщательное планирование и тестирование перед началом процесса.

Одной из лучших технологий для миграции данных сегодня является «Плюс7 ФормИТ». Она позволяет работать со всеми видами источников приемников данных, хорошо прослеживать зависимость при любой логике трансформации данных. Также она решает вопросы с качеством данных, потому что внутри этого инструмента есть профилирование, которое позволяет понять, что и как заполнено, под какие маски оно попадает, насколько вообще данные соответствуют требованиям новой системы. При использовании этого ETL-инструмента задачи по миграции данных решаются на порядок быстрее – в среднем в 5-8 раз, чем даже при применении SQL опытными специалистами, потому что найти в коде ошибку, особенно когда миграция уже идетможет быть крайне затруднительно. Кроме того, ETL-инструмент позволяет делать сверку данных, дает возможность работать с динамическими маппингами, шаблонами. Те самые шаблоны, которые позволяют вам перемещать данные из одного хранилища в другое, оставлять их и повторно потом использовать, например, для синхронизации данных. При проведении миграции данных необходимо учитывать множество нюансов, однако условно этот процесс можно разделить на три этапа.

Подробнее про Плюс7 ФормИТ

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

Это фактический процесс переноса данных из одной системы в другую. Перенос данных может быть выполнен с помощью специальных программных инструментов или вручную. Здесь необходимо убедиться, что данные переносятся без ошибок и потерь, что они сохраняют свою структуру и целостность, и что они корректно загружаются в новую систему. Также целесообразно провести тестирование новой системы перед началом процесса миграции, а также после ее завершения, чтобы убедиться, что все данные перенесены правильно, и что система полноценно функционирует. Одной из важных задач на этом этапе является обеспечение безопасности и конфиденциальности данных в процессе их переноса. Для этого необходимо использовать шифрование и другие методы защиты данных, чтобы предотвратить их утрату или несанкционированный доступ. Также важно иметь план восстановления данных в случае возникновения проблем во время миграции, чтобы быстро и эффективно восстановить данные и минимизировать потенциальные потери. По завершении миграции базы данных необходимо провести анализ результатов и оценить успешность процесса. Это позволит выявить проблемы и ошибки, которые возникли в процессе миграции, и учесть их при подготовке к следующим переносам данных.

Проверка и тестирование данных после их переноса. На этом этапе необходимо убедиться, что данные были успешно перенесены и сохранены в новой системе, что они соответствуют заявленным требованиям и ожиданиям, и что они доступны и корректно работают для пользователей. Итак, важные моменты при миграции данных:

• Планирование: необходимо тщательно спланировать процесс миграции, чтобы минимизировать риск потери данных или негативного воздействия на бизнес-процессы.
• Бэкап: перед началом миграции необходимо создать резервную копию всех данных, чтобы в случае неудачи можно было быстро восстановить информацию.
• Тестер: важно провести тестирование миграции на тестовой версии системы, чтобы исключить возможные проблемы при переносе данных.
• Безопасность: обеспечение безопасности данных во время миграции – один из ключевых моментов. Необходимо убедиться, что данные защищены в процессе их передачи и хранения.

Ошибки, которых следует избегать при миграции данных:

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

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

Первая часть вопросов и ответов можно прочитать здесь. 1. Как реализована многопользовательская работа над одним и тем же проектом? В данный момент многопользовательская работа внутри одного проекта не поддерживается. 2. Таблица может храниться в облаке? Да, если возможно организовать соответствующее подключение (указав имя хоста, порт, имя БД и т.п.) 3. Возможна ли динамическая репликация? Если под динамической репликацией понимается автоматическое добавление в репликацию новых таблиц, то такая репликация возможна при использовании DDL репликации. При этом в зависимости от типа источника могут быть свои особенности. Например, для Oracle при создании таблицы нужно будет добавлять ее в supplemental log либо включить опцию автодобавления на уровне БД. Для Postgres такие действия не потребуются. 4. Если добавить колонку в таблицу, то она подхватится автоматически при выборе опции захвата данной операции? Да, если включить репликацию DDL. 5. Возможно ли игнорирование захвата определенных данных? Да, поддерживаются возможности фильтрации на уровне источника по значениям колонок (парсер будет добавлять соответствующие условия WHERE), а также при записи в приемник с использованием выражений SQL или скриптов TCL. 6. Будет ли создана новая колонка в таблице источнике или её необходимо будет добавить руками? Да, будет создана и в источнике, и в приемнике. Для этого в проекте необходимо включить дополнительно репликацию DDL. 7. Возможна ли двунаправленная (мультимастер) репликация? Да, двунаправленная репликация возможна. Также есть возможность управления разрешением конфликтов. 8. Чем вариант репликации История отличается от Хранилища? В режиме “История” на приемнике создается таблица аудита. В таблицу журнала аудита записывается строка для каждой SQL-операции обновления, вставки или удаления в исходной таблице. В каждой строке таблицы аудита хранятся метаданные об операции SQL, а также снимки before- и after- данных для каждого столбца замаппированной таблицы. В режиме “Хранилище” каждая таблица-источник имеет соответствующую таблицу-приемник и соответствующую таблицу журнала аудита в приемнике. Перед запуском репликации в режиме Хранилище необходимо выполнить первоначальную синхронизацию, синхронизирующую данных источника и приемника. При репликации изменений Загрузчик аккумулирует изменения для цикла загрузки в таблицах журнала аудита, объединяет изменения в меньшее количество операторов SQL, а затем применяет изменения к таблицам-приемникам. Таблицы журнала аудита очищаются в начале каждого цикла Загрузки. Т.е., другими словами, загрузка в таблицы-копии осуществляется мини-пакетами на основе данных таблиц аудита. Вы можете использовать режим Хранилище для репликации данных в приемники Greenplum, Netezza, Oracle, Teradata и Vertica. 9. Что будет если архивные логи “протухли” В случае, если данные архивных логов потеряны по каким-либо причинам до того, как парсер Датафлот успел их обработать, необходимо либо заново выполнять полную синхронизацию как при начале работы решения средствами Датафлот, либо каким-то образом синхронизировать данные источников и приемников сторонними средствами с последующим указанием парсеру с какого SCN/LSN он должен продолжить чтение логов. 10. Зависимости в расписании могут быть? Да, можно настроить зависимости одних задач от других. 11. Канал оповещения (рассылки уведомлений) только почта? На данный момент поддерживаются рассылки уведомлений по email и SNMP протоколу. 12. Какие минимальные/оптимальные аппаратные требования к серверной части? Под управлением какой ОС работает серверная часть? Решение работает на ОС Linux (проверены в т.ч. российские варианты Astra и Alt) и windows (актуально для источников с MS SQL). Рекомендуемая начальная конфигурация сервера для проведения пилотов при использовании выделенного сервера для Датафлот Репликации: Linux сервер, от 4 ядер CPU, от 16 GB RAM, диск от 500 GB. Если объемы изменений большие, то дисковое пространство нужно планировать в соответствии с планируемым объемом обрабатываемых изменений. Как минимум объем диска должен иметь возможность хранить в буфере ежедневные объемы журналов изменений за несколько дней. 13. Есть ли данные по времени отставания от источника? Это очень индивидуальная история, зависящая от многих факторов – нагрузка и интенсивность изменений на источнике, дисковая подсистема хранения журналов, частота процессора парсера, способность приемника своевременно принимать соответствующий объем изменений и т.п. Если “узких” мест нет, то сколько-нибудь заметного отставания практически не будет. Пожалуйста, свяжитесь с представителями DIS Group, если вы заинтересованы в пилотировании решения Датафлот в вашем окружении. 14. Создаются ли временные объекты? Если да, то где хранятся? Парсер читает журналы БД и записывает данные в файловый буфер. Загрузчик читает данные из файлового буфера и применяет изменения на приемнике. Может использоваться один буфер(например, на одном выделенном сервере Датафлот) или “цепочка” буферов на разных серверах, если это вызвано особенностями архитекторы организации. 15. Как реализован аудит действий пользователей? Есть выгрузка лога аудита для ИБ? Действия сохраняются в системном журнале. Какой-то специальной выгрузки для ИБ на данный момент нет, но этот вопрос находится в проработке. 16. Как технически выполняется инициализирующая выгрузка? В одну JDBC-сессию? Для выгрузки и загрузки в зависимости от типа источника и приемника используются ODBC, нативные клиенты БД (например OCI) и нативные утилиты bulk загрузки и библиотеки приемников (например, libpq). JDBC не используется. Выгрузка и загрузка происходят в рамках одного процесса. 17. В enterprise, обычно, на продуктовом контуре, делать руками ничего нельзя. Как релизован процесс передачи конфигурации с тестового контура на препрод/прод? Можно ли переносить конфигурации Датафлот между средами (дев/тест/прод)? Да, есть механизмы экспорта/импорта проектов. 18. Можно ли сохранять конфигурации в Git? Какой-то специальной интеграции с Git нет. Конфигурация представляет собой бинарный файл, необходимость интеграции с Git не очевидна. 19. Есть ли ограничения для той или иной СУБД источника/приемника? По каждому типу источника и приемника могут быть свои особенности. Все они подробно описаны в документации. 20. Захват транзакционный, если да то, как обстоят дела с долгими транзакциями (несколько часов)? Используется “оптимистичная” стратегия – парсер читает и передает в буфер все данные, относящиеся к нужным таблицам, подразумевая, что транзакция закомитится с более высокой вероятностью чем откатится. В случае если произойдет роллбэк, то Загрузчик просто не будет применять соответствующие изменения на приемнике. 21. Может ли одна таблица быть приемником из нескольких источников? Да, технически это возможно. Потребуется создать несколько проектов. Кроме того, необходимо будет решить организационные вопросы с первоначальной синхронизацией и потенциальными конфликтами (например, при дублировании primary key). 22. Как происходит репликация DDL-операций при гетерогенной репликации, например Oracle>PostgreSQL, в частности как перекодируются типы? Решение поставляется с преднастроенными правилами преобразования типов для всех комбинаций источников и приемников. Кроме того, при необходимости, вы можете изменять существующие правила преобразования типов или добавлять свои. 23. Есть ли тесты производительности по сравнению с Debezium Да, проведен ряд сравнительных тестов. По результатам тестирования решение Датафлот Репликация показало выигрыш в скорости первоначальной синхронизации от 282 до 343 раз, выигрыш в скорости репликации изменений от 11 до 26 раз. Также, например, работа с использованием собственного парсера Датафлот при работе с источником Postgres значительно быстрее работы через API Postgres которое использует Debezium (парсер Датафлот быстрее в 7–11 раз по результатам тестов). Кроме того, парсер Датафлот значительно меньше (в 8–10 раз по результатам тестов) нагружает сервер источник Postgres. 24. Есть ли интеграция пользователей с AD, kerberos, openId и т.п.? На данный момент нет. Есть планы по интеграции с LDAP. 25. Поддерживается ли транзакционность при распараллеливании загрузки, например данные в мастер таблицу и детальную таблицу попадают в одной транзакции? Транзакционность в смысле обработки только закоммиченных в рамках одной транзакции данных поддерживается. Однако при использовании многопоточной загрузки в приемник соблюдение порядка, например для появления primary и foreign keys в разных таблицах в общем случае не гарантируется. Для некоторых БД (например, Oracle) существует возможность решить проблему зависимостей при появлении primary и foreign keys при многопоточной загрузке в приемник с использованием deferred constraints и применением глобального коммита по всем потокам. 26. Порядок применения транзакций на приемнике соответствует порядку источника? Загрузчик будет считывать данные о транзакции из буфера в порядке их применения. В случае однопоточной загрузки в приемник порядок будет соответствовать. Однако при использовании многопоточной загрузки в приемник соблюдение порядка, например для появления primary и foreign keys в общем случае не гарантируется. Для некоторых БД (например, Oracle) существует возможность решить проблему зависимостей при появлении primary и foreign keys при многопоточной загрузке в приемник с использованием deferred constraints и применением глобального коммита по всем потокам.

Данные вопросы были озвучены участниками вебинара “Импортозамещение и репликация: эффективные альтернативы для российского рынка”. Запись вебинара можно получить здесь (бесплатно). 1. Какие СУБД поддерживаются в качестве источников? Реляционные источники и приемники решения Датафлот Репликация (на ноябрь 2023):

• DB2
• Microsoft SQL Server
• MySQL
• Oracle
• PostgreSQL
• Sybase ASE

Не реляционные приемники:

• Arenadata DB
• Arenadata Hadoop
• Cloudera
• Hortonworks
• Greenplum
• Kafka
• Netezza
• Teradata
• Vertica
• Файловая система (плоские файлы)

2. Используются ли при работе архивные логи БД или применяется какое-то другое решение? Да, решение Датафлот Репликация использует архивные и онлайн логи БД для захвата данных об изменениях. 3. Как лицензируется решение? Датафлот Репликация это коммерческое (не open source решение). Лицензирование решения осуществляется:

• По количеству ядер CPU на реляционных источниках и приемниках данных, с которыми работает решение (см. перечень ниже);
• По количеству инстансов (кластеров) не реляционных приемников (MPP, колоночные СУБД, кластеры Hadoop и т.п., см. перечень ниже)
• Какие минимальные гранты для пользователя, под которым работает репликация, нужны для PosgtreSQL? (Debezium работает на уровне superuser).

При работе решения Датафлот Репликация с источником Postgres может использоваться работа через API Postgres (такой подход использует также open source решение Debezium), а также работа с использованием парсера журналов Датафлот собственной разработки. Работа с использованием собственного парсера значительно быстрее работы через API Postgres (в 7-11 раз по результатам тестов), и значительно меньше (в 8–10 по результатам тестов) нагружает сервер источник. Работа через парсер Датафлот не требует прав суперюзера. Необходимо обеспечение доступа к месту хранения архивных журналов Postgres. Набор прав на источнике Postgres (пример): create user dfr_user with encrypted password ‘dfr_user’; grant select ON all tables in schema <schema_name> to dfr_user; alter user dfr_user with replication; grant create on database <database> to dfr_user; GRANT EXECUTE ON FUNCTION pg_switch_wal() TO dfr_user; 4. За счет чего обеспечивается отказоустойчивость/гарантированная доставка? Отказоустойчивость и восстановление при сбоях обеспечивается с использованием собственного механизма контрольных точек (checkpoints), которые фиксируют, какую информацию обработал Парсер журналов БД и успешно передал в буфер, а также какую информацию Загрузчик передал в приемник и получил подтверждение о коммите. Кроме того, в БД на сервере-приемнике создается дополнительная таблица для хранения контрольной информации для восстановления. 5. Как реализован забор данных от Oracle-кластера, где есть master/slave/standby узлы? При работе с кластером Oracle решение Датафлот Репликация может взаимодействовать с любым активным узлом. При работе со standby поддерживается работа с физическим standby (read-only) и логическим standby. 6. Можно ли настроить в системе информирование об ошибках при репликации? Да, есть механизм уведомлений. Можно настроить его для рассылки уведомлений об ошибках с приложением соответствующих журналов. 7. Вы в своем роде единственный игрок или есть альтернативы? если есть альтернативы, то, чем вы отличается от других? какие ваши особенности? На рынке представлены как коммерческие, так и open source решения для репликации данных, использующие в основе технологии CDC. Одним из наиболее популярных на рынке коммерческих решений CDC долгое время являлось решение Oracle GoldenGate. Среди open source проектов известен проект Debezium. Однако, в настоящее время необходимость решения задач импортозамещения выводит на первый план российские разработки. 8. Основные отличия Датафлот Репликации:

1. Российская разработка, реестровая запись No 18777 от 22.08.2023
2. Техническая поддержка 24×7 на русском языке
3. Пользовательский̆ интерфейс на русском языке для полной̆ настройки процесса от захвата изменений до доставки в приемники и ведения мониторинга
4. Не требует развертывания, сопровождения и мониторинга дополнительных внешних компонент
5. Простота и легкость настройки
6. Доставка данных в приемник настраивается через визуальный интерфейс, не требует программирования и/или настройки дополнительных внешних коннекторов
7. Оптимальные способы работы с журналами БД: специализированные парсеры журналов, обеспечивающие высокую скорость обработки и минимальную нагрузку на источник. Например, в сравнении с Debezium при работе с Postgres обеспечивается выигрыш по скорости парсинга в 7-11 раз и при этом нагрузка на источнике ниже в 8-10 раз.
8. Встроенные возможности первичной̆ синхронизации данных в т.ч. для больших и очень больших объемов данных с обеспечением многопоточности.
9. Возможность использования опции Датафлот Экспресс для еще более высокоскоростной̆ первичной̆ выгрузки (миграции) данных из Oracle (до 20 раз быстрее native инструментов)
10. Целостность и отсутствие потерь данных обеспечивается в рамках решения
11. Стабильная работа даже в условиях больших DML операций (десятки миллионов строк и выше в одной транзакции)
12. Возможность работы с источниками Oracle Standby (уже поддерживается) и Postgres (roadmap).
13. Не допускается появление дублей̆ в приемнике при восстановлении при сбоях
14. Быстрое обучение команды администрирования и сопровождения.

9. В чем конкурентное отличие парсера Датафлот от OpenSource Debezium? Работа с использованием собственного парсера Датафлот значительно быстрее работы через API Postgres которое использует Debezium (парсер Датафлот быстрее в 7–11 раз по результатам тестов). Кроме того, парсер Датафлот значительно меньше (в 8–10 раз по результатам тестов) нагружает сервер источник Postgres. Работа через парсер Датафлот не требует прав суперюзера. 10. Датафлот Репликация – аналог какой зарубежной системы? Схожим по функционалу и архитектурным принципам является решение Oracle GoldenGate. 11. Через какой клиент (пользовательский интерфейс) осуществляется настройка? В данный момент панель управления решения — это “толстый” клиент разработанный на JAVA. Интерфейс на русском языке. В первом квартале 2024 года планируется разработка “тонкого” веб-клиента. 12. Входит ли система в список ФСТЭК? Датафлот Репликация входит в реестр российского ПО, реестровая запись No 18777 от 22.08.2023. Компания DIS Group (распространяет в т.ч. решения Датафлот) имеет опыт получения лицензий ФСТЭК СЗКИ и сертификации ряда продуктов. Для решения Датафлот Репликация необходимость такой сертификации на данный момент изучается. Пожалуйста, свяжитесь с представителями DIS Group, если вы заинтересованы в использовании решения Датафлот Репликация и, при этом, особенности деятельности вашей организации требуют обязательной сертификации ФСТЭК. 13. Как обеспечивается скорость при репликации очень больших объемов данных? Используется ли для репликации JDBC? Решение Датафлот Репликация предоставляет высокоскоростные парсеры собственной разработки для парсинга журналов БД, а также поддерживает возможности многопоточной загрузки в системы приемники. Драйверы JDBC используется для работы панели управления. Непосредственно для репликации используются парсеры журналов, драйверы ODBC и нативные клиенты БД. Каждый приемник имеет свои особенности. Например, для приемника Greenplum:

• Для создания проекта через панель управления используется JDBC;
• При репликации используется режим Хранилище, при работе которого применяются: libpq для заливки в таблицу аудита и ODBC для выполнения мержа по таблицам аудита;
• При начальной синхронизации используется libpq

14. Требуется ли при работе парсера Датафлот установка дополнительных компонент на сам сервер, где расположена СУБД-источник? Если нет, то чем именно ваш парсер отличается от вызова методов СУБД-источника? Компоненты парсера Датафлот могут быть установлены как непосредственно на сервер-источник, так и на выделенный сервер или даже на сервер-приемник. Необходимым условием при установке не на сервер-источник является обеспечение на сервере парсера доступа к журналам БД источника. Использование парсера Датафлот имеет значительные преимущества по сравнению с работой с захватом изменений через API БД. Так, например, работа с использованием собственного парсера Датафлот при работе с источником Postgres значительно быстрее работы через API Postgres которое использует Debezium (парсер Датафлот быстрее в 7–11 раз по результатам тестов). Кроме того, парсер Датафлот значительно меньше (в 8–10 раз по результатам тестов) нагружает сервер источник Postgres. Работа через парсер Датафлот не требует прав суперюзера. 15. Каким образом обеспечивается отсутствие дублей при репликации? Отсутствие дублей в случае незапланированных отказов и последующего восстановления обеспечивается с использованием механизма контрольных точек (checkpoints), которые фиксируют, какую информацию обработал Парсер журналов БД и успешно передал в буфер, а также какую информацию Загрузчик передал в приемник и получил подтверждение о коммите. Кроме того, в БД на сервере-приемнике создается дополнительная таблица для хранения контрольной информации для восстановления. 16. Есть ли какие-то планы по работе с облаками? Для развертывания решения в облаке на виртуальном сервере и использования его точно также как on-premise решения на данный момент препятствий нет. Относительно необходимости разработки дополнительного специализированного функционала для работы в облаке вопрос изучается. Пожалуйста, свяжитесь с представителями DIS Group, если вы заинтересованы в использовании решения Датафлот Репликация и, при этом, особенности деятельности вашей организации требуют специализированного функционала для работы в облаке. 17. Каков механизм обеспечения целостности данных? Есть ли оценка влияния сложности этого механизма на скорость репликации? Решение передает в приемник только закоммиченные транзакции. Целостность данных при незапланированных отказов и последующем восстановления обеспечивается с использованием механизма контрольных точек (checkpoints), которые фиксируют, какую информацию обработал Парсер журналов БД и успешно передал в буфер, а также какую информацию Загрузчик передал в приемник и получил подтверждение о коммите. Кроме того, в БД на сервере-приемнике создается дополнительная таблица для хранения контрольной информации для восстановления. 18. Что означает Q4.2023 Q2.2024 в roadmap решения — это дата? Да, так был обозначен номер квартала (Q4.2023 – четвертый квартал 2023 года). Расстановка приоритетов в roadmap может быть предметом обсуждения. Пожалуйста, свяжитесь с представителями DIS Group, если вы заинтересованы в использовании решения Датафлот Репликация и, при этом, особенности деятельности вашей организации требуют повышение приоритета для какой-то позиции из roadmap или вы заинтересованы в добавлении новых возможностей не указанных в roadmap. 19. Есть ли возможность получать события было-стало? Да возможность получения данных “до” и “после” изменения, возможность использования этой информации в трансформациях при обработке данных, а также ведение соответствующих таблиц аудита поддерживается. 20. Тонкий/толстый клиент отличия и возможности? “Толстый” клиент реализован на Java. “Тонкий” клиент находится в стадии реализации, будет представлять собой web-приложение и использовать REST API службы управления Датафлот. Планируется постепенный перевод основных функций “толстого” клиента в новый “тонкий”. 21. Есть ли возможность захвата на standby базах? Есть ли возможность переключения репликации с мастера на standby в случае failover? Да, есть возможность работы с Oracle standby (read only или логическим). Планируется реализация работы со standby Postgres. Возможность переключения с мастера на standby в случае failover есть, соответствующие настройки приводятся в документации. 22. Применение изменений идет в один поток или параллельно? Поддерживается многопоточная загрузка изменений в приемник, соответствующие настройки выполняются в панели управления решения. 23. Есть ли возможность захвата с read only standbay. Да, есть возможность работы с Oracle standby (read only или логическим). Планируется реализация работы со standby Postgres. При работе c read-only standby необходимые добавления в supplemental log производиться на primary. 24. Есть ли тесты производительности по сравнению с Oracle GG? Тесты в процессе, ожидаем первых результатов в ближайшее время. 25. Кем был разработан интерфейс? Интерфейс разработан разработчиками компании Датафлот. 26. Есть ли возможность реплицировать одни и те же данные в разные приемники? Да, такая возможность есть. В данный момент внутри одного проекта в разные приемники одного типа (если нужно в приемники разных типов, то нужно будет создать несколько проектов). В roadmap уже запланированы доработки по использованию в одном проекте приемников разных типов. 27. Возможна ли фильтрация/обогащение данных как в Oracle GG? Да, фильтрация и возможности трансформаций поддерживаются.

Миграция данных является неотъемлемой частью развития любого бизнеса. Правильно организованный процесс миграции может существенно повысить эффективность работы вашей компании, улучшить качество данных и обеспечить бесперебойную работу систем. Выбор правильного подхода к миграции данных является серьезной задачей. Наш вебинар призван помочь вам разобраться в этом вопросе и предоставить надежные рекомендации. Посмотрев запись вебинара, вы узнаете:

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

Этот вебинар будет полезен IT-специалистам, директорам по разработке, техническим директорам, тимлидам, руководителям ИТ-служб и всем тем, кто заинтересован в оптимизации процесса миграции данных.

• Олег Гиацинтов, Технический директор, DIS Group

Обратите внимание на другие онлайн-мероприятия серии:

• Импортозамещение и репликация: эффективные альтернативы для российского рынка
• Data Governance в ритейле: специфика и особенности (Magnit Data)

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

• Снижение нагрузки на системы-источники путем использования репликации данных;
• Принципы работы и преимущества репликации данных;
• Как выбрать подходящую платформу для репликации данных в вашем бизнесе;
• Как заменить Oracle GoldenGate на более доступные и не менее эффективные аналоги;
• Технические особенности реализации проектов;
• Какие функциональные возможности у решения Датафлот Репликация.

Запись вебинара будет полезна для всех, кто работает с большими объемами данных и стремится улучшить их управление и доступность. Мероприятие будет особенно интересно администраторам базы данных, разработчикам базы данных, бизнес-аналитикам, архитекторам по данным и IT-специалистам, ответственным за обработку и хранение данных.

• Ольга Объездчикова, Технический менеджер, DIS Group
• Хасанов Василий, Заместитель Технического директора, DIS Group

Обратите внимание на другие онлайн-мероприятия серии:

• Data Governance в ритейле: специфика и особенности (Magnit Data)
• Данные в масштабах банков: ETL-решение для финансовой отрасли (кейс МКБ)

Банки работают с огромными объемами данных каждый день. ETL-решения позволяют извлекать данные из различных источников, преобразовывать их в форматы, удобные для анализа, и загружать их в целевые системы. И это далеко не весь список задач. На данном вебинаре были рассмотрены следующие темы:

• Введение в ETL (Extract, Transform, Load) – концепцию и принципы работы.
• Обзор первого российского промышленного ETL-решения и его главных возможностей.
• Кейс-стади Московского кредитного банка: как МКБ успешно применил ETL-решение для интеграции данных и достижения операционной эффективности.
• Практические рекомендации и лучшие практики по использованию ETL-решения для интеграции данных в банковском секторе и в бизнесе в целом.

Спикеры: МКБ, Николай Федоткин, DIS Group Запись вебинара будет полезна директорам по развитию и цифровой трансформации, ИТ-директорам и директорам по данным из банковского сектора, страхования, сектора телекоммуникаций и других отраслей.

• Артур Коваль, Руководитель направления, МКБ
• Николай Федоткин, Технический менеджер по решениям DIS Group

Обратите внимание на другие онлайн-мероприятия серии:

• Миграция данных: как выбрать правильный подход
• Data Governance в ритейле: специфика и особенности (Magnit Data)