В поисках потерянных данных: переход со StreamSets на Data Boring
В современном мире обработки данных обновление инструментов и технологий — необходимость. Казалось бы, непреложная истина, однако на практике к обновлению подкапотного пространства подходят, когда уже ресурсы прежнего решения исчерпаны на полную, а работа продолжается на честном слове. В одном из проектов наша команда организовала миграцию со StreamSets на Luxms Data Boring, когда заказчик обратился с болью из-за невозможности обработать часть пакетов с данными, а в ежедневных бизнес-процессах это сказывалось ощутимыми ударами по кошельку.
StreamSets — оркестратор, запускающий конвейерные обработки данных, в более привычной терминологии — ETL-инструмент. Внедренный у заказчика годами ранее, к 2023 стал сыпать ошибками и прерывать пайплайны. К нам обратились с задачей разобраться с ситуацией.
Поскольку StreamSets — иностранное ПО, которое нецелесообразно обновлять и сопровождать, а наша команда обладает компетенциями в отечественном ETL/ELT-сервисе, было рекомендовано резать, не дожидаясь перитонитов, т. е. мигрировать на другое ПО, попутно проводя апгрейд БД. Data Boring — продукт российского происхождения, подходящий под условия импортозамещения и имеющий поддержку российского вендора, то есть нас — группы компаний Luxms.
Я, Николай Павлов, инженер по обработке данных, и моя коллега Наталья Глодя, руководитель этого проекта, рассказываем свою повесть о поисках потерянных данных, чтобы предостеречь те бизнесы, которые могут узнать в тексте себя.
В поисках потерянных данных
Проект и его цели
Компания обратилась с проблемой: автоматизированные процессы обработки данных стали давать сбои. Как следствие — складские работники получали неточную информацию по остаткам, соответственно, при формировании отгрузки на точки продаж могли не укомплектовать часть товара.
Специалистами Luxms было предложено решение – технический и логический апгрейд, способствующий предотвращению потери данных из всех источников, а также отказоустойчивость системы согласно требованиям 2024 года.
В анамнезе у заказчика значилась устаревшая версия основной СУБД Greenplum, которая требовала освежиться по мажорной версии до v 6.23.3. Однако обновление ПО без целостного архитектурного подхода не гарантирует устранение ошибок. Поэтому помимо обновления мы:
провели анализ архитектуры текущего хранилища данных;
создали кластерную архитектуру для поддержания отказоустойчивости;
мигрировали с CentOS 7 на RockyLinux 8, поскольку компания-производитель перестала выпускать обновления для CentOS 7 с 30 июня 2024 года;
а также мигрировали со StreamSets на Luxms Data Boring.
Для заядлых технарей далее даем технические подробности.
Переход со StreamSets на Data Boring
Перед началом миграции мы освежили в памяти наши представления о StreamSets с помощью документации продукта на сайте и технического опросника заказчика. Инструмент представляет собой графический, интуитивно-понятный интерфейс со множеством узлов или нод (от англ. Node), каждая из которых выполняет конкретную функцию. Например, ноды могут использоваться для запуска процессов, управления переменными или выполнения SQL-запросов.
Выполнение функций в СУБД
Рис. 1 Функции в СУБД в StreamSets и Luxms Data Boring
Cлева — один из пайплайнов StreamSets, справа — тот же пайплайн, переписанный в интерфейсе Data Boring (рис. 1). Также на визуале потока больше разветвлений и декомпозиции больших скриптов по нодам. Ниже располагаются механизмы журналирования, позволяющие заказчику отслеживать выполнение всех процессов в базе данных.
Рис. 2 Запуск и выполнение SQL-запроса (SQL query)
Мы использовали ноду «запуск/inject» для задания расписания запуска потока (рис. 2) . Это давало возможность как автоматического, так и ручного запуска. Также мы внедрили возможность установки переменных, которые могут быть как локальными, так и глобальными.
Выполнение функций и Python-скрипта
Рис. 3 Выполнение функций и Python-скрипта, загрузка Excel в СУБД
В предыдущем процессе со StreamSets использовалось три основных блока, а также один вспомогательный. Мы переосмыслили процесс и к первоначальной логике добавили опции:
создание переменных для изменения прав доступа к скриптам;
нода, которая перенаправляет поток только если получит msg-сообщение об успешном парсинге xlsx-файлов в csv;
распознавание загруженных csv и в зависимости от ответа создание таблиц разных типов;
отслеживание статуса работы с отправкой в журнал.
Рис. 4 Шаблонизатор (Template) и запись файла (write file)
Выполнение функций и SQL в СУБД, выполнение bash-скриптов
Рис. 5 Выполнение функций и SQL в СУБД, bash-скриптов
В нашей архитектуре мы воспроизвели структуру StreamSets с началом процесса и возможностью разветвления для параллельного выполнения.
Рис. 6 Функции и терминал
Используя ноды «Function», мы начали писать JS-код для обработки переменных, а также реализовали узел «Exec», который выполняет действия с полученными переменными.
Мониторинг длительности выполнения потоков
Заказчик также поставил перед нами задачу мониторинга длительности выполнения потоков. Мы разработали систему на базе Redis для отслеживания времени выполнения потоков и их отклонений.
Рис. 7 Мониторинг длительности выполнения потоков
Запустив процессы, сначала мы накопили в таблицах данные о фактическом времени успешного выполнения каждого потока (общее количество потоков около 20). Далее с помощью функций и формул для вычисления математического ожидания и среднеквадратического отклонения мы вывели среднее эталонное. На основе полученных данных, заказчик смог самостоятельно настраивать допустимые отклонения в виде сигм, что обеспечивало реальный контроль за производительностью. Среднее эталонное корректируется автоматически с каждой новой записанной строкой выполнения в журнал.
Более того, через ноду Data Boring интегрировали отправку уведомлений в чат Telegram, чтобы фокусировать внимание ответственных за сопровождение системы на возможных нештатных ситуациях.
При миграции со StreamSets мы успешно перевели половину пайплайнов, в то время как заказчик управлял переводом второй части самостоятельно, потому что хотел освоить новый инструмент и проверить, сможет ли самостоятельно поддерживать его в актуальном состоянии. Как показала практика, Data Boring имеет низкий порог входа и позволяет быстро автоматизировать ETL задачи даже без привлечения вендора и внешних консультантов.
Резюме
Бизнес-результаты:
система работает в штатном режиме, ошибки потери пакетов ушли;
все розничные точки бесперебойно получают пополнение товара;
быстрые уведомления в чат повысили оперативность реагирования на нештатные ситуации;
отечественная разработка соответствует программе импортозамещения;
команда заказчика обрела новый ETL-инструмент, в котором также научилась работать и далее поддерживать самостоятельно.
Технические результаты (обновлённая инфраструктура Greenplum):
мастер и стендбай мастер-сервера на виртуальных хостах разных физических гипервизоров. Быстрое восстановление сервисов PXF и ETL. Бэкап системой Veeam;
два сегмент-хоста на идентичных железных серверах HP дают высокую производительность и отказоустойчивость;
два массива RAID10, состоящих из HDD дисков (тёплые данные) и SSD дисков (горячие данные), обеспечивают надёжность и распределение данных по востребованности;
зеркалирование сегмент-хостов в режиме группы (group mirroring) позволяет бесшовно перестраивать работу системы онлайн при потере одного из серверов.
Видео выступления заказчика с рассказом о проекте — VK.Video и Youtube
Наш рассказ, как вендора, о реализации — VK.Video и Youtube