Хранилища данных,
OLAP, CRM: информация
 
 На главную | Книги | Ссылки | Рассылка | Письмо автору | RSS

Порядок разработки ETL-процессов (часть 2)

Автор: Евгений Островский

Рассмотрим основные стадии процесса загрузки данных подробнее.

Извлечение данных (IDC)

Результатом работы, на этой стадии, является перегрузка данных из источника в реляционную СУБД, в промежуточную область. Для этой цели, под каждый источник данных, в промежуточной области создаётся своя таблица. Все таблицы имеют префикс “sttm” (сокр. от “STaging Table for Middle-layer data”), либо “stti” (сокр. от “STaging Table for Initial load”) (также вошла в обиход фраза: «Таблица принадлежит области STTM (STTI)»).

Таблицы, участвующие в загрузке справочников SCF и UCF чаще всего относятся к области STTI, так как не требуют написания процедур обновляющей загрузки; а те, что участвуют в загрузке таблиц фактов и обновляемых RDS – к STTM, так как для них обновляющая загрузка (загрузка данных в ХД с учётом наличия данных в ХД) почти всегда разрабатывается.

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

Извлечение данных из всех частей распределённого источника производится в одну таблицу промежуточной области. Для сохранения информации, откуда поступили данные, в структуру этой таблицы добавляется поле с обозначением исходной оперативной системы или филиала.

Получение (выгрузка) данных (Download)

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

Метод организации выгрузки данных Комментарии
1 Выгрузка из СУБД Обычно не вызывает затруднений. Можно использовать как «родные» утилиты СУБД, так и Pump.
2 Выгрузка из структурированного источника данных Для выгрузки используется ODBC, JDBC, или соответствующие утилиты.
3 Выгрузка из неструктурированного источника данных Это метод всегда требует дополнительного внимания и обсуждения. Если источников неструктурированной информации избежать, всё же, не удаётся, необходимо использование дополнительных утилит для экспорта данных из них. В ходе экспорта данные организуются в жёсткую структуру (см. пункт «Структурирование данных»).
4 Подготовка структурированного файла с данными человеком или сторонней программой Этот метод, по сути, ничем не отличается от выгрузки из структурированного источника. Зачастую, выгрузка сводится к копированию файла по локальной сети.

Отдельным пунктом стоит управление выгрузкой данных, а именно указание глубины выборки данных по времени. Как правило, достаточно обеспечить 2 режима работы процедуры выгрузки: выгрузка всей информации, без учёта времени её поступления, и выгрузка за некоторый последний период (например, за последний закрытый день). Универсальным средством решения является возможность задания, в качестве параметра процедуры, даты, начиная с которой будут выбираться данные.

Структурирование данных (Structuring)

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

  • DBF
  • TXT (TSV, CSV, или файл с выровненными полями)
  • XML

Как уже сказано выше, структурированию подвергаются только данные, которые выгружаются из неструктурированных источников данных.

Обработка данных (Refinement)

Структурированные данные могут потребовать дополнительной обработки (очистки, фильтрации, согласования, и т.д.), с целью повышения качества информации.

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

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

Пересылка данных (Transfer)

В ходе проектирования процедур извлечения данных необходимо учесть местонахождение источников данных и условия обеспечения безопасности при пересылке и обработке данных.

В случае расположения источников данных на сервере, отдельном от сервера СУБД промежуточной области ХД, необходимо обеспечить пересылку данных, уже подготовленных к загрузке в реляционную СУБД, по защищённым (доверенным) каналам связи на место, откуда они смогут быть загружены в соответствующую таблицу промежуточной области. В связи с широкими возможностями современных СУБД по работе с удалёнными данными, эта проблема является не столь сложной в программном смысле, сколь требующей грамотного администрирования. В таком случае этап пересылки данных объединяется с этапом импорта данных в СУБД (Upload).

И наоборот, данные источника не всегда могут быть обработаны (подпроцесс Refinement) на сервере поставщика данных. Тогда их необходимо переслать для обработки на сервер консолидации данных, что также требует наличия защищённых каналов связи и административных ресурсов. В этом случае, этап пересылки выполняется прежде структурирования данных.

Импорт данных в СУБД (Upload)

Для дальнейшей обработки, структурированные данные необходимо подгрузить в соответствующую таблицу СУБД (которую нужно предварительно очистить).

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

Обработка ошибок в стадии IDC

Ошибки могут появляться в любом из подпроцессов стадии извлечения данных. Отследить их возникновение – задача слабо формализуемая. Кроме того, зачастую вся ответственность за обеспечение корректной работы процедур извлечения данных возлагается на программистов, что неверно и может быть оправдано только для жёстко структурированных источников данных (например, когда загрузка производится напрямую из СУБД).

Требования к обработке ошибок в стадии IDC должны определяться в зависимости от типа источника данных, но, в любом случае, обязательной является обработка фатальных для дальнейших стадий ошибок.

Примеры фатальных ошибок:

  • отсутствие файлов источника данных;
  • ошибка доступа к данным;
  • возникновение системной ошибки ОС.

 

 

Для удобства отслеживания новых публикаций на сайте рекомендую подписаться на рассылку или подписаться на канал RSS.

 

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.

Популярные страницы:

Советы разработчику хранилищ данных

OLAP

Моделирование

Книги

Книги на русском языке

Бесплатные книги

Производители OLAP

CRM

Производители CRM

Управление метаданными

Коллекция ссылок


Найти: на

[ На главную | Книги | Ссылки | Рассылка | Письмо автору | Реклама на сайте ]

© Константин Лисянский, 2001-2008.

SpyLOG Rambler's Top100 Rambler's Top100

Используются технологии uCoz