Лекция
Привет, Вы узнаете о том , что такое разработка etl, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое разработка etl, проектирование etl , настоятельно рекомендую прочитать все из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL.
Для того чтобы заставить ХД заработать, необходимо не просто обеспечить взаимодействие многих источников данных – важно тщательно спланировать это взаимодействие. Поэтому процессы извлечения, преобразования и загрузки данных играют важную роль в создании и эксплуатации ХД.
Чтобы процесс преобразования данных протекал без сбоев, необходимо обеспечить наличие необходимой документации и метаданных. Процесс извлечения данных влияет на производительность других систем, поэтому его следует рассматривать в аспекте управления изменениями и конфигурацией систем – источников данных.
Под аббревиатурой ETL (extraction, transformation, loading — извлечение, преобразование и загрузка данных ) понимается составной процесс переноса данных одного приложения или автоматизированной информационной системы в другие.
Процесс ETL реализуется путем либо разработки приложения ETL, либо создания комплекса встроенных программных процедур, либо использования ETL-инструментария. Приложения ETL извлекают информацию из исходных БД источников, преобразуют ее в формат, поддерживаемый БД назначения, а затем загружают в эту БД преобразованные данные.
Цель любого ETL-приложения состоит в том, чтобы своевременно доставить данные из внешних систем в систему, с которой работают пользователи. Как правило, ETL-приложения используются при переносе данных внешних источников в ХД систем бизнес-аналитики. Поэтому организация процесса ETL является составной частью проекта разработки практически любого ХД.
Проектирование и разработка etl -процесса является одной из самых важных задач проектировщика ХД. Для ХД процесс ETL имеет следующие свойства. Во-первых, объем данных, который выбирается из систем источников данных и помещается в ХД, как правило, бывает достаточно большим, до десятков Гб. Во-вторых, процесс ETL является необходимой составной частью эксплуатации ХД. Периодичность процесса ETL определяется не только потребностью пользователя в своевременных данных, но и размером загружаемой порции данных. По оценкам специалистов, ETL-процесс может занимать до 80% времени. В-третьих, на разных стадиях процесса ETL формируются метаданные ХД и обеспечивается качество данных. В-четвертых, во время процесса ETL может произойти потеря данных, поэтому необходимо обеспечивать контроль за поступлением данных в ХД. В-пятых, процесс ETL обладает свойством восстанавливаемости после сбоев без потери данных.
На рис. 15.1 показано место процесса ETL в архитектуре системы бизнес-аналитики на основе ХД.
Как видно из рисунка, на процесс ETL возложена вся работа по подготовке данных для доставки их в ХД, формирование и обновление метаданных ХД, а также управление данными, извлеченными в результате Data mining.
Таким образом, процесс ETL состоит из трех основных стадий.
Существует несколько подходов к реализации процесса ETL. Общепринятый подход состоит в извлечении данных из систем источников, размещении их в промежуточной области дисковой памяти (Data Staging Area), выполнении в этой промежуточной области процедур преобразования и очистки данных, а затем загрузки данных в ХД, как показано на рис. 15.2.
Размещение извлеченных данных в промежуточной области означает запись данных в БД или файлы дисковой подсистемы. Альтернативным подходом к реализации процесса ETL является выполнение преобразований в оперативной памяти ETL-сервера и непосредственную загрузку в ХД, как показано на рис. 15.3.
Преобразование данных в оперативной памяти выполняется быстрее, чем при размещении их предварительно на диске. Однако применение такого подхода лимитируется размером порции загружаемых данных. Если размер порции загружаемых данных достаточно большой, то необходимо использовать промежуточную область.
Иногда применяется еще один подход к реализации процесса ETL, когда преобразование данных выполняется на сервере ХД, в процессе их загрузки. Использование такого подхода определяется вычислительными возможностями сервера ХД. Обычно такой подход применяется для MPP серверов ХД.
В зависимости от того, кто извлекает данные из систем источников, реализация ETL-процесса может быть выполнена следующими способами.
В зависимости от того, где выполняется процесс извлечения данных из систем источников, реализация ETL-процесса может быть выполнена следующими способами.
Таким образом, при проектировании процесса ETL проектировщик ХД должен на основе анализа требований к функционированию ХД совместно с руководителем ИТ-проекта выбрать программно-аппаратное решение для реализации ETL-процесса, а именно – точно определить, где и каким способом будет выполняться ETL-процесс. На это решение может сильно повлиять бюджет проекта. Например, может быть недостаточно финансовых средств, чтобы реализовать процесс ETL на выделенном сервере.
Как правило, при конструировании процесса ETL для ХД придерживаются следующей последовательности действий.
Процесс преобразования данных играет весьма важную роль в достижении успеха реализации проекта ХД, поэтому он должен быть хорошо спланирован. Разработка плана носит интерактивный характер.
Сначала создается обобщенный план, в котором отражается перечень систем –источников данных и указываются планируемые целевые области данных (данных, которые будут размещаться в ХД). Источник целевых данных определяется на основе сформулированных бизнес-требований к ХД. Как правило, источники данных существенно различаются: от БД и текстовых файлов до SMS-сообщений. Это обстоятельство может значительно усложнить задачу преобразования данных.
Назначение таких высокоуровневых описаний источников дает, с одной стороны, разработчикам представление и о создаваемой системе, и о существующих источниках данных, а с другой, руководству организации, — понимание сложности, связанной с процессами преобразования данных.
К составлению обобщенного плана лучше всего приступать, когда разработана многомерная модель ХД. Тогда для каждой таблицы многомерной схемы можно определить таблицы – источники данных.
Рассмотрим пример многомерной схемы ХД системы поддержки принятия решений на рис. 15.4.
Связи между таблицами многомерной схемы ХД и таблицами – источниками данных можно указать с помощью стрелочек, как на диаграмме на рис. 15.5.
Каждую стрелочку на диаграмме следует пронумеровать и сопроводить комментарием, который должен служить напоминанием разработчикам о необходимости следить за целостностью ссылочных данных или других определенных бизнес-правилами особенностях обработки каждой таблицы источника.
На этой стадии планирования необходимо зафиксировать все обнаруженные расхождения в определениях данных и схемах кодирования.
Детальное планирование ETL-процесса во многом зависит от использования выбранных ETL-инструментов. К настоящему времени разработано достаточно много таких инструментов как компаниями производителями комплексных решений в области ХД (IBM, Oracle, MicroSoft), так и сторонними производителями программного обеспечения (Sunopsis). Поэтому задача выбора подходящих ETL-инструментов должна быть решена до того, как приступать к детальному планированию.
Программное обеспечение этого класса предназначено для извлечения, приведения к общему формату, преобразованию, очистки и загрузки данных в хранилище. Существуют два подхода к написанию ETL-процедур: 1) их можно написать вручную; 2) можно воспользоваться специализированными средствами ETL.
Каждый из подходов имеет ряд преимуществ и недостатков, поэтому выбор того или иного метода реализации процедур ETL определяется требованиями к подсистеме загрузки данных в каждом конкретном случае. Выделим наиболее важные достоинства каждого из способов написания ETL-процедур.
Написание вручную:
Применение ETL-инструментов:
Следует обратить внимание на выбор технологии для реализации процедур ETL, в случае если одной из систем-источников данных выступает ERP-система. Об этом говорит сайт https://intellect.icu . Системы данного класса являются наиболее сложными, так как обладают очень запутанной моделью данных и зачастую содержат десятки тысяч таблиц. Для реализации процедур загрузки данных из ERP-систем в команду разработчиков должен быть включен специалист, хорошо знакомый с данной системой-источником, так как анализ подобного рода систем с нуля занимает слишком длительное время. Кроме того, большинство поставщиков средств ETL предоставляют коннекторы ко многим ERP-системам, позволяющим импортировать метаданные ERP-систем и работать с ними на более высоком уровне. Наличие коннекторов к ERP-системам предоставляет специализированным средствам ETL большое преимущество над написанием вручную процедур загрузки данных, в случае если в качестве источника данных выступает ERP-система.
После выполнения предварительного планирования приступают к детальному планированию.
Детализированные планы преобразования данных составляются для всех таблиц, участвующих в процессе преобразования.
В настоящей лекции мы не даем рекомендаций по формированию детального плана, поскольку в каждом конкретном случае детальное планирование выполняется руководителем проекта создания ХД и включает в себя учет различных факторов, связанных со спецификой предметной области ХД. Так, например, для банковских ХД, возможно, будет необходимо выполнить проверку корректности бухгалтерской базы по бизнесправилам (провести в процессе ETL подсчет остатков и оборотов по отдельным лицевым и/или балансовым счетам).
Для таблиц измерений ХД, которые не будут изменяться со временем, в разработке процесса ETL первой основной задачей является выбор первичного ключа таблицы. Выбор ключа осуществляется проектировщиком ХД на основе анализа источников данных.
Второй основной задачей является проверка наличия в измерении отношений "один к одному" и "один ко многим". Как правило, для такой проверки используется сортировка.
Затем следует рассмотреть изменяющиеся измерения, определить тип изменений и описать процедуры работы с такими измерениями.
Загрузка таблиц измерений выполняется либо путем перезаписи таблицы измерения (для небольших по объему таблиц), либо загружаются только изменения в данных таблиц измерений.
При конструировании процесса заполнения таблиц фактов проектировщик решает следующие основные задачи:
Процесс загрузки таблиц фактов бывает двух типов: первоначальная загрузка и периодическая загрузка изменений.
Проблемы, связанные с первоначальной загрузкой, состоят в том, что с большой долей вероятности вы не получите корректных исторических данных из-за больших объемов данных. Поэтому важно оценить, какой тип загрузки для какой таблицы фактов подходит наилучшим образом.
Отметим, что в процессе ETL таблицы измерения должны обновляться до обновления таблиц фактов, поскольку релевантные строки таблиц измерений должны быть размещены для загружаемых новых фактов.
Источники данных для ХД можно разбить на следующие основные типы.
Отметим, что стратегия извлечения данных в значительной степени зависит от типа источника данных.
Целью процесса извлечения данных является быстрое извлечение релевантных данных из источников данных.
Процесс извлечения данных из источников данных можно разбить на следующие основные типы:
Процесс извлечения данных может выполняться ежедневно, еженедельно или, в редких случаях, ежемесячно. Отметим, что существует целый класс систем бизнес-аналитики, которые требуют извлечения данных в режиме реального времени: например, системы, анализирующие биржевые операции (каждую секунду), или системы в области телекоммуникаций.
Процесс извлечения данных может выполняться либо в среде оперативных систем обработки данных (источников), либо в среде функционирования ХД.
Процесс преобразования данных источников включает в себя следующие основные действия.
Как правило, данные источников не обладают необходимым уровнем качества данных. Заметим, что данные в ХД должны быть:
Для обеспечения качества данные при преобразовании подвергаются процедуре очистки. Процедура очистки данных необходима, поскольку системы бизнес-аналитики не работают с несогласованными и неточными данными, иначе бизнес-анализ становится бессмысленным.
Процедура очистки данных включает в себя согласование форматов данных, кодирование данных, исключение ненужных атрибутов (например, комментариев), замещение кодов значениями (например, почтового индекса наименованием населенного пункта), комбинирование данных из различных источников под общим ключом (например, собрать все данные о покупателях), обнаружение одинаково поименованных атрибутов, которые содержат различные по смыслу значения.
Очистку данных можно разделить на следующие типы:
Процедуры очистки также включают в себя создание меток статуса фактов в таблицах измерения (нормальный, ненормальный, невозможный, выходящий за границы, анализируемый или нет и т.д.), распознавание случайных и зашумленных значений (замещение их NULL-значением или оценкой), унификация использования NULL-значений, маркирование фактов с изменившимся статусом (например, покупатель аннулировал контракт), агрегирование фактов и т.п.
Основная цель процесса загрузки данных состоит в быстрой загрузке данных в ХД. Отметим некоторые особенности выполнения процесса загрузки данных в ХД.
Во-первых, загрузка данных, основанная на использовании команд обновления SQL, является медленной. Каждая команда SQL выполняется СУБД по определенному плану выполнения, и ее обработка включает выполнение нескольких фаз. Поэтому загрузка с помощью встроенных в СУБД средств импорта/экспорта является предпочтительной.
Во-вторых, индексы таблиц загружаются медленно. Во многих случаях целесообразно удалить индекс и построить его заново.
В-третьих, следует максимально использовать параллелизм при загрузке данных. Измерения могут производиться одновременно с фактами и секциями таблиц. Аналогично факты и секции таблиц могут загружаться одновременно с измерениями.
Следует заметить, что при загрузке данных должна быть гарантирована ссылочная целостность данных, а агрегаты должны быть построены и загружены одновременно с подробными данными.
Настройка производительности загрузки данных в ХД выполняется администратором ХД с помощью набора процедур, предусмотренных используемой СУБД.
Таким образом, мы рассмотрели в общих чертах основные элементы ETL-процесса. Теперь разберем, как проектировать ETL-процессы.
В компьютерных системах организации информация хранится в различных БД систем оперативной обработки данных, корпоративных приложениях и ХД. Для использования этой информации необходима ее систематизация. Систематизация информации приводит к решению задач комбинирования информации из различных источников, преобразованию ее к единому формату для производства корпоративной отчетности и интеллектуального анализа данных.
Для решения поставленной выше задачи используются две технологии – технология ETL-процессов и технология процессов интеграции данных, или технология EII- (Enterprise Information Integration) процессов.
Как уже указывалось в этой лекции, ETL является процессом в складировании данных, который выполняет три функции в одной программной среде: чтение данных из определенных источников ( извлечение ), преобразование данных в соответствии с принятыми соглашениями (преобразование) и запись преобразованных данных в источник назначения ( загрузка ).
EII комбинирует необработанные данные посредством управления и организации запросов к различным системам без предварительной агрегации контента. Полученные данные не помещаются, как правило, на хранение в какие-либо БД или ХД.
CASE-инструменты предоставляют графическую среду для моделирования и документирования ETL- и EII-процессов. В CASE PowerDesigner для этого служит модель движения данных (Information Liquidity Model, или ILM).
ILM предоставляет проектировщику ХД средства моделирования и анализа преобразования данных как на общем уровне рассмотрения, так и на детальном уровне рассмотрения.
На рис. 15.6 приведен пример того, как могут быть связаны входные и выходные источники данных на высоком уровне и как преобразования моделируются на диаграммах более низкого уровня.
Движение данных — один из главных вопросов для любой организации. Моделирование движения данных позволяет определить в модели, где данные генерируются, где загружаются в систему и как они преобразуются в процессе их использования.
PowerDesigner Information Liquidity Model (ILM) является графическим инструментом моделирования движения данных, который позволяет построить модели:
Теперь построим модель движения данных (ILM), содержащую диаграмму движения данных (Information Liquidity Diagrams), диаграмму управления преобразованием (Transformation Control Flow Diagrams) и диаграммы преобразования данных (Data Transformation Diagrams), и создадим тем самым модель ETL-процесса.
Для того чтобы создать ILM-модель, необходимо выполнить следующую последовательность действий.
В результате на экране будет показано диалоговое окно, как на рис. 15.7.
Таким образом, ILM-модель создана. Теперь ее нужно наполнить диаграммами.
Создадим диаграмму преобразования. Диаграмма преобразования является диаграммой высокого уровня для документирования ETL- и EII-процессов. На ней показываются входные и выходные источники данных, вовлекаемые в процесс преобразования. Источники связываются процессом преобразования, которое определяется на последующих диаграммах преобразования данных.
Предположим, в наше ХД Giant Corp данные поступают из следующих источников: двух оперативных БД системы организации Small Corp и Acme, модели бизнес-процессов Small Corp Role и XML-модели Acme Role.
С помощью палитры инструментов ( рис. 15.8) разметим объекты модели.
| Действие | Пиктограмма |
|---|---|
| три источника данных типа БД |
 |
| один источник данных типа "XML-документ" |
 |
| один источник данных типа "Бизнес-процесс" |
 |
| установим "Процесс преобразования" |
 |
Установим связи между ними с помощью стрелок и таким образом получим диаграмму преобразования, как показано на рис. 15.9.
Теперь необходимо связать объекты диаграммы с описанием источников данных. Пусть для нашего примера БД Small Corp имеет схему, как показано на рис. 15.10, БД Small Corp — схему, как на рис. 15.11, ХД Giant Corp — как на рис. 15.12, Acme Role XML-документ имеет модель, как показано на рис. 15.13.
Покажем на примере БД Small Corp, как связать объект диаграммы с описанием источника данных. Дважды щелкнем левой кнопкой на пиктограмме объекта, на панели " Database property sheet " откроем вкладку " Physical Data Models ". Щелкнем кнопкой мыши на пиктограмме " Add Physical Data Models ", откроется список моделей. Выберем из списка соответствующую модель и щелкнем кнопкой мыши на ОК (см. рис. 15.14). Связь установлена.
Рис. 15.14. Установление связи объекта диаграммы ILM-модели со схемой БД
Объект ILM-диаграммы "Процесс преобразования" определяет список задач преобразования данных и поток управления преобразованием.
Построим диаграмму преобразования данных. Задача преобразования данных включает одну или несколько диаграмм преобразования данных, которые позволяют моделировать процессы извлечения данных из источников данных, преобразования данных и загрузки данных в источник назначения. Данные поступают из источников данных (data inputs), преобразуются посредством выполнения определенных манипуляций над ними и загружаются в источник назначения (data outputs). Последовательность этих процессов связывается вместе посредством потока данных (data flows), а сами данные представляются посредством колонок структуры данных, которые используются в каждом из перечисленных процессов.
На рис. 15.15, на диаграмме преобразования данных, показано, что данные извлекаются из БД Acme и Small Corp, затем объединяются в БД DataMerge, фильтруются фильтром DataFilter, сортируются процедурой DataSort и загружаются в БД Giant Corp.
Для каждого объекта нужно определить перечень колонок, который будет задействован в процессе преобразования на этом объекте. Эти действия выполняются на диалоговом окне " Data Projection Properties "" как показано на рис. 15.16.
Изображенная на рис. 15.15 диаграмма преобразования данных может быть развернута таким образом, чтобы видеть структуры данных на каждом элементе диаграммы, как показано на рис. 15.17.
Поток данных (стрелочки на диаграмме) передает данные между объектами диаграммы преобразования данных. Для определения потока данных может быть использован редактор отображения (Mapping Editor), как показано для потока данных между DataMerge и DataFilter на рис. 15.18.
Диаграммы управления потоком преобразования данных предназначены для моделирования последовательных или параллельных задач преобразования данных. Диаграмма управления потоком содержит одну или несколько диаграмм управления потоком преобразования, моделирующих порядок, в котором последовательность задач преобразования данных выполняется. Последовательность задач включает в себя инициализацию задачи (starts), выполнение задачи (task executions), решение (decisions), синхронизацию (synchronizations) и завершение задачи. Связанные вместе, они составляют поток управления.
На рис. 15.19 показана диаграмма управления потоком преобразования данных для нашего примера.
Пиктограмма инициализации задачи преобразования ( TransformationStart_1 ) инициирует выполнение последовательности задач преобразования данных на диаграмме управления потоком. Далее последовательно выполняются задачи "Объединить сотрудников" ( Merge Employe ) и "Объединить роли" ( Merge Role ). Решений никаких не принимается, синхронизация не выполняется. Процесс заканчивается выполнением задачи завершения процесса преобразования ( TransformationEnd_1 ).
Все построенные диаграммы связаны между собой на диаграмме высокого уровня ILM-модели (см. рис. 15.9) в объекте "Процесс преобразования" ( TransformationProcess_1 ). На рис. 15.20 и 10.21 соответственно изображены вкладки диалогового окна свойств этого объекта, на которых показана привязка задач преобразования и потока управления.
Таким образом, проектировщик ХД данных может моделировать ETL-процессы для разрабатываемого хранилища данных с помощью CASE-инструментов.
Заметим, что при изложении материала последнего раздела мы опустили многочисленные детали определения объектов и их свойств при проектировании модели ETL-процесса. Нашей задачей в данном случае является иллюстрация возможностей CASE-инструментов. Отметим также, что ведущие компании, производители комплексных решений для создания ХД, такие как IBM, Oracle, MicroSoft и ряд других, поставляют встроенные средства для проектирования ETL-процессов. Поэтому проектировщику ХД будет необходимо ознакомиться с возможностями таких инструментов после выбора несущей СУБД.
Таким образом, разработка ETL-процесса включает в себя следующие основные стадии:
При проектировании процессов преобразования данных проектировщик ХД должен решить следующие задачи:
Исследование, описанное в статье про разработка etl, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое разработка etl, проектирование etl и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Комментарии
Оставить комментарий
Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL