ETL – технология, сопутствующая любой BI-инициативе

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

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

Точки внимания

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

Первый аспект связан непосредственно с системами-источниками.

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

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

Второй аспект связан с качеством данных.

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

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

Вопросы консолидации данных можно успешно решить с помощью самостоятельных систем класса MDM (Master Data Managment). Использовать промышленную систему или разрабатывать собственную – предмет проектного решения. В любом случае эти задачи существенно увеличивают объем проекта и требуют отдельного внимания. По оценкам наших специалистов, разработка и/или внедрение подсистемы консолидации могут в разы превышать трудоемкость, предусмотренную на ETL-составляющую проекта, и требовать серьезных усилий со стороны команды заказчика.

Третий подводный камень касается обратной связи с исходными системами.

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

Следующий аспект связан с архитектурой ETL-решения.

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

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

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

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

Последний, но не менее важный вопрос – выбор ETL-инструментария.

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

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