Кастомизация шагов сценария ETL: как достигается, зачем нужно и при чем тут Модус?
ETL-системы значительно облегчают подготовку отчетности. Они предлагают готовые решения для извлечения, преобразования и загрузки информации, а также имеют встроенные функции и коннекторы для работы с популярными источниками данных.
При этом, стандартные ETL-системы не всегда справляются со сложными алгоритмами или уникальными бизнес-задачами. Поэтому для расширения функционала ETL-систем проводится кастомизация их сценариев. О ее преимуществах и инструментах подробнее расскажем в этой статье.
Что такое шаги в ETL?
Шаги ETL-сценариев — это последовательность действий для преобразования информации в СУБД, DWH или на серверах ETL-системы. Эти процессы можно использовать для выгрузки данных в BI, создания сводных отчетов, расчета KPI и других аналитических операций компании.
При этом на каждом этапе сценария предусмотрен свой «мастер» — специальная форма, где можно задавать параметры выполнения каждого шага, выбирать источники и системы для передачи и преобразования данных, а также настраивать фильтрацию, группировку, агрегацию, трансформацию и другие правила обработки информации.
Например, в «мастере» группировки данных можно выбрать, в каких колонках информация будет объединяться по группам, а в каких — агрегироваться. Также данные можно кластеризовать — например, по модели обучения, плотности объектов или количеству кластеров. Так аналитики смогут быстрее выполнять подготовку информации внутри хранилища без навыков работы с Python или SQL.
Есть несколько видов Шагов ETL-сценариев:
Шаг на SQL. В этом случае выполняются SQL-преобразования данных — например, выборка, соединение, группировка, транспонирование или мэппинг. Поскольку такие операции проводятся через СУБД, в котором хранится информация, необходимость в пересылке данных между системами отпадает — это делает шаги на SQL самыми производительными в сценариях. Результаты SQL-преобразований передаются в виде временной таблицы или текстовых запросов в приемники данных — например, для агрегации или загрузки в целевые системы.
Шаг на Python. Этот способ нужен для выполнения произвольных инструкций на Python и реализации методов машинного обучения — например, при использовании алгоритмов классификации клиентов или прогнозировании продаж. Эти шаги облегчают обработку данных за счет готовых Python-библиотек, таких как Pandas (для работы с таблицами) или Scikit-learn (для машинного обучения).
Шаг на 1С. С помощью этих шагов можно выполнять инструкции и коды на 1С: Предприятие. Поскольку такие процессы проводятся через серверы 1С, обработка данных длится дольше, чем в SQL или Python. Зато с их помощью можно установить связь с объектами конфигурации ETL и интегрировать смежные объекты в систему — например, использовать типовые шаги мэппинга с таблицами НСИ, которые создаются на 1С. Кроме того, за счет доступности открытого кода и возможности добавления собственных функций, шаги на 1С легко расширяются и кастомизируются.
Таким образом, «мастера» шагов — это подготовленные инструкции и формы на языках SQL, 1C или Python, которые можно легко копировать и модифицировать под любые аналитические задачи или процессы обработки данных. А так как «мастера» работают через шаблоны, входящие и исходящие данные или настройки внутри шагов можно интегрировать в уже выполняемый код.
Когда нужно кастомизировать шаги?
Кастомизация шагов сценария ETL используется, когда стандартного функционала системы не хватает для выполнения специфических бизнес-задач или нестандартных преобразований данных.
Возьмем в пример сценарий расчета задолженности клиентов, при котором через Telegram-бот нужно уведомлять менеджеров о персональных данных покупателя и сумме его долга. Обычно в ETL нет стандартного шага для вызова бота — поэтому его можно написать произвольным кодом на 1С или Python, где на вход бы принималась информация из таблицы-источника, а в настройках шага указывались параметры вызова бота для передачи сообщения.
Но можно пойти дальше и создать универсальный шаблон шага, который будет отправлять подготовленную строку с информацией в Telegram-бот, не привязываясь к конкретному сценарию. Такой шаг будет работать независимо от других процессов и аналитик сможет самостоятельно настроить его через BI-интерфейс — например, задавая данные для уведомления и параметры взаимодействия с ботом.
Для этого и нужны шаблоны шагов — они помогают создать гибкие и многократно используемые решения, которые можно настроить без необходимости писать код для каждой отдельной операции.
При этом, шаблоны шагов — это обработки на 1С, которые содержат инструкции о том, как и где эти шаги будут выполняться — в SQL, Python или на сервере 1С. В зависимости от этого, можно выбрать два способа кастомизации:
Создание и подключение внешней обработки на 1С к справочнику «шаблоны шагов сценариев». В этом случае можно создать совершенно любой шаг сценария — например, рассылку уведомлений в Telegram, подготовку Excel-отчета или выполнение сложных математических расчетов. Несмотря на то, что описание обработки реализуется на 1С, ее код будет выполняться на любом выбранном сервере.
Копирование и модифицирование существующей обработки. В этом формате можно перераспределять выполняемый код обработки без замены его логики, а также использовать шаблон произвольных кодов, чтобы пользователям, не знакомым с программированием, было проще создавать новые ETL-сценарии.
Эти методы помогут быстро обойти ограничения стандартных ETL-систем и создать гибкие шаблоны для решения универсальных бизнес-задач.
Кастомизация получения данных
С помощью кастомизации можно не только преобразовывать данные, но и собирать информацию для ETL-систем из разных источников — например, через обработки, включающие код на Python или 1С.
Так, информационная система ГИСП получала данные для своих отчетов из более чем 20 разных источников — при этом, ограничения стандартной ETL-платформы ресурса замедляли обработку больших потоков информации. Для решения этой проблемы в Modus BI разработали 4 различных «мастера» сбора данных, через которые аналитики ГИСП могли загружать информацию из внешних систем без использования кода.
На создание одного сервиса ушло 40–50 часов, зато после его внедрения интеграция одного потока с системой ГИСП занимала не больше 10 минут, так как работники платформы использовали готовые интерфейсы для получения данных.
Кроме «мастеров» интеграций, собирать данные можно с помощью внешних обработок, которые загружаются в ETL — они должны быть написаны на 1С и выполняться с помощью платформы 1С: Предприятие. Для создания этих обработок нужно написать правила получения данных, которые будут включать в себя такие процедуры программного интерфейса, как:
Заполнение параметров получения данных.
Заполнение структуры таблицы.
Выполнение процедуры получения информации.
В этом случае программный интерфейс остается неизменным, что упрощает получение данных из разных систем.
Кастомизация конфигурации
Кастомизация конфигураций проводится на базе 1С. В этом случае большая часть кода остается открытой, что помогает изменять и расширять функциональность системы в соответствии с уникальными потребностями заказчика. Так, через платформу 1С в ETL можно встраивать MDM-системы, модули для согласования данных, а также небольшие подсистемы ввода и расчета KPI, финансовых метрик и других показателей работы предприятия.
Например, логистическим компаниям критически важно отслеживать маршруты доставки в режиме реального времени —, но в стандартных ETL таких функций нет. С помощью кастомизации в систему предприятия можно интегрировать модуль для получения данных от GPS-трекеров, а затем анализировать эту информацию и формировать на ее базе отчеты о задержках или изменениях маршрутов.
Заключение
Кастомизация ETL играет важную роль в гибкости и качестве обработки данных. С ее помощью можно подключаться к нестандартным источникам данных, внедрять сложные бизнес-правила и адаптировать систему к быстро меняющимся условиям.
Это не только оптимизирует аналитические процессы под уникальные требования бизнеса, но и повышает точность отчетности, которая становится основой для принятия более объективных управленческих решений.
