Об инструментах и стратегиях реализации ETL-процессов, плюсах и минусах кастомных и коробочных решений, а также о том, как с помощью low-code платформы решаются ETL-боли компаний из различных отраслей, поговорили с Михаилом Шмитовым, генеральным директором DECO Systems, спикером Fintech Data Day.
— Какие ETL-инструменты представлены на рынке? Чем они отличаются друг от друга и какие критерии следует учитывать при их выборе?
М. Шмитов: Есть несколько подходов к реализации процессов наполнения хранилища данных. Можно использовать open source инструменты, такие как Airbyte, DBT и Argo Workflows.
Коммерческие инструменты менее известны широкой аудитории, так как принадлежат крупным интеграторам и зарубежным технологическим компаниям. Эти инструменты позволяют реализовывать корпоративное хранилище в облаке, например в Microsoft Azure. К этой же категории относятся классические ETL-инструменты, например Informatica PowerCenter, у которого уже появились российские аналоги.
Все эти инструменты развиваются достаточно давно и обладают своими преимуществами и недостатками. Например, минус проприетарных инструментов заключается в том, что созданные в них ETL-процессы зависят от наличия самого инструмента. Если инструмент будет удален из инфраструктуры, то перестанут функционировать и процессы.
Наша компания занимается развитием продукта DMP «Управление хранилищем», специально разработанного для реализации задач построения корпоративного хранилища данных, создания послойной модели данных и ее наполнения. Он обладает функциональностью генерации исходного кода ETL-процессов, создания модели данных в хранилище, а также включает методологию работы со слоями хранилища данных и поддержку управления историчностью данных. Инструмент обеспечивает возможность очистки дублей в данных в процессе загрузки и учитывает другие технологические нюансы, специфичные для хранилищ данных.
Также есть универсальные инструменты, которые позволяют просто перегонять данные «из пункта А в пункт Б». При наличии определенной экспертизы они могут быть полезны для построения ETL-процессов, однако рынок предпочитает решения, которые учитывают технические аспекты реализации современных принципов и подходов к созданию корпоративного хранилища данных.
— Какую стратегию вы рекомендуете выбрать при внедрении ETL-решений?
М. Шмитов: Выбор стратегии зависит от финансовых возможностей и от желания создать собственный дата-департамент с собственной компетенцией в создании ETL-процессов. Не секрет, что сейчас все компании стремятся стать датацентричными и крупнейшие игроки вкладывают значительные средства в создание своего «офиса CDO». Однако использование кастомной разработки справедливо ассоциируется с долгими сроками, высокими затратами и сложностью обеспечения качества данных.
Поэтому компании, ограниченные в ресурсах, предпочитают использовать коробочные решения, которые отвечают всем требованиям и позволяют быстрее достичь целей, часто столь же амбициозных. Эти решения разработаны и протестированы — значит, их можно сразу внедрять, что значительно ускоряет процесс и снижает затраты. Их проще адаптировать с помощью специалистов, которые знакомы с SQL, — соответственно, требуемая квалификация специалистов меньше, чем при кастомной in-house разработке или кастомной разработке с привлечением подрядчика. Кроме того, коробочные решения включают в себя лучшие технологические практики и минимизируют риски, связанные с внедрением, поскольку разрабатываются специалистами с высоким уровнем компетенции.
Таким образом, использование готовых коробочных решений позволяет компаниям быстрее и дешевле достигать своих целей, не жертвуя качеством.
— Вы сказали, что для компаний важно наличие у разработчика отраслевой экспертизы. Действительно ли существуют различия в применении ETL-процессов при реализации хранилищ данных в различных отраслях?
М. Шмитов: ETL-процессы, независимо от сферы деятельности заказчика, выполняют схожие задачи: они переносят данные из источников и заполняют слои данных хранилища с целью формирования витрин данных и, например, дальнейшего их использования в BI-инструментах. Однако часто заказчики заинтересованы в команде со знанием методологии и аналитическим опытом в конкретной отрасли.
Например, в банках предпочитают подрядчиков, которые уже знакомы с построением регуляторной и управленческой отчетности. В зарубежных банках с участием иностранного капитала часто необходимо знание специфики МСФО-отчетности. В крупных финансовых организациях достаточно многообразный внутренний ИТ-ландшафт, включающий такие системы, как АБС, процессинг, коллекшн, внутренние порталы, HR- и другие специфичные для банковской сферы системы. Если у подрядчика на старте имеются аналитические знания структуры данных в источниках — то наличие такой компетенции может являться для заказчика «триггером» того, что проект с большой долей вероятности «обречен на успех».
Использование инструментов для автоматизации генерации ETL-процессов также добавляет уверенности в выдерживании сроков проекта, так как инструменты проверены практикой и разрабатываются квалифицированной продуктовой командой.
Если мы говорим про госсектор, то основной вызов здесь — это переход от зарубежных систем к отечественным решениям, а также автоматизация работы подразделений, которые до сих пор используют Excel в своей работе, с помощью конкретных прикладных систем. В настоящее время такая неполная автоматизация деятельности подразделений государственных компаний в основном приводит к необходимости использования Excel-файлов в качестве основного источника данных.
Таким образом, отраслевая специфика работы обусловлена, во-первых, аналитическими знаниями в конкретной отрасли, а во-вторых, знакомством аналитиков подрядчика с типовыми источниками данных заказчика. Каждая отрасль имеет свои специфичные типы источников данных: у кого-то преобладают Excel-файлы, у кого-то — конфигурации 1С, у других — различные MES-системы, или биллинги, или автоматизированные банковские системы. Каждый сегмент преследует свои цели: кому-то важнее отчитаться перед регулятором, кому-то — возможность задать коммерческий вектор развития и получить выгоду от использования накопленных данных. Однако с технической точки зрения все эти проекты схожи и отличаются лишь прикладной аналитической составляющей и типами источников данных.
Кроме того, в разных отраслях есть различия по преобладающему типу обработки данных. При реализации ETL-процессов выделяют пакетную и потоковую обработку. Большинство наших заказчиков в основном используют пакетную обработку. Однако те, кто стремится к построению отчетности в режиме near real time (например, для процессов, связанных с противодействием отмыванию денег), нуждаются и в потоковой обработке данных, для того чтобы оперативно загружать и обрабатывать данные в хранилище, а затем передавать их для ML-алгоритмов, например с целью выявления аномалий в данных.
У нашей компании есть проекты в самых разных сегментах. Мы исторически достаточно давно работаем с банковским сегментом, финтехом, телеком-компаниями и госсектором. Накопленный опыт в реализации хранилищ позволяет нам общаться с «бизнесом» и аналитическим департаментом заказчиков на одном языке.
— Почему реализация ETL-процессов является серьезным вызовом даже для опытных ИТ-команд? Какие типовые проблемы могут возникать при различных подходах к организации процессов наполнения данных в корпоративном хранилище на практике?
М. Шмитов: Прежде всего, для успешной реализации ETL-процессов в команде необходимо иметь архитектора с опытом работы и знанием различных методологий организации хранения данных, чтобы выбрать оптимальный подход для создания корпоративного хранилища данных и реализации задач бизнеса.
В случае реализации достаточно объемного корпоративного хранилища данных, где количество ETL-процессов может достигать нескольких тысяч, их можно реализовать качественно и быстро либо при наличии команды со значительной технической экспертизой, либо при использовании шаблонизации и автоматической генерации кода ETL-процессов, позволяющей ускорить создание ETL-процессов и минимизировать время, необходимое для постановки витрин данных на регламент (time-to-market).
При разработке нашего инструмента DMP «Управление хранилищем» мы используем различные шаблоны для генерации типовых процессов загрузки данных на различные слои хранилища и создания/изменения модели данных хранилища. Наш продукт позволяет генерировать типовые запросы для отправки данных в слои ODS/DDS/ADS хранилища и уменьшает необходимость выполнения рутинных действий, например для ведения историчности данных, реализации методологии «Снежинка», Data Vault 2.0, Anchor Modeling для детального слоя и поддержки дедупликации данных.
В отсутствие инструмента автоматизации генерации ETL-процессов придется все перечисленные аспекты постоянно держать в голове и регулярно уделять им внимание. Именно поэтому мы создали наш продукт — чтобы решать однотипные проблемы и автоматизировать рутинные действия, которые повторяются из проекта в проект. При реализации очередной задачи загрузки данных, например из АБС в хранилище, уже нет необходимости заниматься разработкой и вносить изменения в исходный код самостоятельно. Наш инструмент с визуальным интерфейсом позволяет быстро выбрать нужные данные на вход, создать модель и настроить карту соответствия источника с приемником (S2T), автоматически генерируя код ETL-процесса.
При разработке нашего продукта мы адаптировали лучшие практики, применяемые в проектах по реализации крупнейших хранилищ данных объемом в десятки петабайт. Используя наше low-code решение DMP «Управление хранилищем», можно быть уверенным, что вы получаете корпоративное хранилище данных, организованное в соответствии с лучшими методологиями и архитектурными принципами. Помимо этого, в лице специалистов нашей компании заказчики получают значительную аналитическую экспертизу, подтвержденную опытом выполненных проектов.
— Какие конкретные бизнес-преимущества получает компания при правильном подходе к реализации ETL-процессов?
М. Шмитов: Наш low-code продукт DMP «Управление хранилищем» является инструментом для аналитиков, которым не обязательно обладать знанием языка программирования Python и достаточно знания SQL, чтобы управлять загрузкой данных в хранилище. То есть для настройки регламентных процессов, загрузки данных из источников в хранилище и проведения их по слоям достаточно базового понимания принципов построения хранилищ данных, организации послойного хранения данных в КХД и навыков в SQL.
Кроме технических преимуществ наш продукт имеет и коммерческую ценность. Обычно хранилище данных становится центральной системой компании и развивается с каждым годом. Изначально проект по созданию корпоративного хранилища данных может иметь цель в виде автоматизации и постановки на регламент десяти-пятнадцати отчетов, но через год-два, когда заказчик осознает преимущества использования КХД, количество создаваемых витрин данных и сам объем данных могут вырасти в разы.
Наша компания как владелец продукта готова предоставить потенциальным клиентам детальное обоснование экономической эффективности использования нашей low-code платформы по сравнению с использованием команды разработчиков при реализации регламентных ETL-процессов. Речь при этом идет как о создании, так и о поддержке в актуальном состоянии реализованных ETL-процессов, витрин данных и отчетности.
— Какие дополнительные возможности обеспечивает ваше решение помимо генерации ETL-процессов?
М. Шмитов: У нашего продукта есть три модуля, которые помогают автоматизировать работу специалистов, связанных с управлением данными. Основной модуль — «Управление хранилищем» — ориентирован на аналитиков и позволяет им, не будучи программистами со знанием Python, эффективно создавать ETL-процессы для Apache Airflow.
Второй модуль — «Качество данных» — предназначен для автоматизации работы специалистов по качеству данных (офицеров качества данных). Он помогает им в low-code формате создавать комплексные проверки качества данных без необходимости иметь глубокие знания в программировании. Типичный процесс тестирования качества данных, особенно в случае сложных бизнес-проверок, выглядит следующим образом: аналитик пишет параметризируемый SQL-запрос, который должен запускаться после завершения ETL-процесса. Этот запрос может проверять как бизнес-логику, так и техническую целостность данных. Создаваемая проверка качества данных может быть многоэтапной и состоять из различных подпроверок, контекст из которых передается на следующий этап. Такие процессы проверки качества данных требуют не только знания SQL, но и умения интегрировать проверку в общий пайплайн ETL-процессов.
Наш продукт позволяет офицерам качества данных создавать проверки качества данных с передачей контекста между этапами, с предобработкой и постобработкой параметров проверок, с возможностью настройки почтовых и API-нотификаций, а также различной сенсорики. Теперь тестировщики могут самостоятельно создавать полноценные проверки качества, которые учитывают пререквизиты для своего запуска, обрабатывают параметризацию запуска и выполняют постобработку данных для использования на следующем этапе запуска.
Третий модуль — «Маскирование данных». В хранилище данных содержится информация, представляющая собой коммерческую тайну или персональные данные. Также достаточно часто данные из хранилища должны быть доступны подрядчикам, например для реализации ML-платформы и построения ML-моделей. Для передачи такого рода данных из хранилища отделу сопровождения КХД необходим инструмент, который автоматизирует обезличивание данных в значительном объеме и в достаточно короткий срок.
Например, у нас есть хранилище с несколькими терабайтами данных о клиентах, которые нужно правильно замаскировать и перенести в отдельную песочницу, сохраняя значимость данных, таких как, например, ИНН с верификацией контрольных разрядов. Задача создания обезличенных песочниц данных является типовой и рано или поздно возникает в процессе создания корпоративного хранилища данных.
С помощью нашего продукта отдел сопровождения у заказчика может решить задачу маскирования данных с подключением к различным источникам и приемникам данных и настройкой алгоритмов маскирования. Пополняемый список алгоритмов маскирования данных уже на текущий момент содержит более сотни актуальных алгоритмов. DMP «Управление хранилищем» позволяет автоматизировать рутинные задачи маскирования данных в low-code формате, что упрощает и ускоряет процесс без потребности иметь навык в программировании.
— По вашей практике, каковы основные этапы процесса создания корпоративного хранилища данных и как они помогают оптимизировать работу с отчетностью?
М. Шмитов: Мы действуем максимально открыто и ориентированы на клиента, предлагая подход к реализации КХД через пилотный проект. Пилот позволяет потенциальным заказчикам на практике ознакомиться с хранилищем и процессами его наполнения, иметь возможность «потрогать все собственными руками» и протестировать наш продукт. Мы предлагаем клиентам выбрать две витрины данных и реализовать полный путь от источников данных до витрин и их визуализации. Этот процесс включает в себя начальную (инициирующую) загрузку данных на определенную глубину и организацию инкрементальных ETL-процессов для обновления данных. Завершается пилотный проект визуализацией собранных витрин в BI-инструменте.
Таким образом, клиенты, которые только начинают процесс создания корпоративного хранилища данных или миграции существующего КХД на современный стек и не имеют четкого представления о том, как подойти к этому проекту, в рамках пилотного проекта не более чем за месяц работы с нашим продуктом получают развернутую инфраструктуру и возможность протестировать две витрины, стоящие на регламенте, с визуализацией в BI-инструменте. Данный подход позволяет руководству оценить практическую пользу от внедрения КХД, увидеть витрины данных, их регламентное обновление и визуализацию на различных дашбордах.
Процесс создания витрин данных значительно ускоряется благодаря использованию нашего продукта DMP «Управление хранилищем», который дает понятный визуальный интерфейс для создания модели данных хранилища на всех слоях, таких как ODS, DDS и ADS, а также автоматизирует генерацию кода, как его Python-, так и SQL-части. В проектах создания КХД на сегодняшний день мы в основном используем СУБД с массивно-параллельной архитектурой, такую как Greenplum, и ее коммерческие реализации от наших партнеров. В этом году планируем адаптировать свой продукт также под LakeHouse-архитектуру и дать возможность нашим клиентам автоматизированно генерировать код загрузки данных с использованием фреймворка Spark.
Одно из главных улучшений после внедрения КХД, которое получает заказчик, заключается в том, что все отчеты, которые ранее создавались вручную и со значительными трудозатратами, теперь полностью автоматизированы. Помимо этого, до появления хранилища данных аналитикам бизнес-подразделений заказчика достаточно часто приходится строить отчеты напрямую из источников данных. Отсутствие промежуточного звена хранения, которое бы аккумулировало данные и обрабатывало их, приводит к тому, что BI-инструменты напрямую обращаются к источникам данных, тем самым замедляя их работу. Использование хранилища данных позволяет в менее загруженные периоды, например в ночное окно, извлекать данные из источников, минимизируя дальнейшую аналитическую нагрузку на них. Таким образом, внедрение корпоративного хранилища данных позволяет нашим заказчикам уверенно управлять своими данными, следуя проверенным логическим и методологическим принципам, и использовать свои данные для развития бизнеса.
Партнерский материал. ООО «Деко Системс», ИНН 7701847528, erid: 2VtzqxMAGMe
Источник: http://futurebanking.ru/post/4178
Вам также может понравиться
