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