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 играет важную роль в гибкости и качестве обработки данных. С ее помощью можно подключаться к нестандартным источникам данных, внедрять сложные бизнес-правила и адаптировать систему к быстро меняющимся условиям. 

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

Комментарии (0)