Итак, если посмотреть на вот эту картинку, которая приводилась для описания области стейджа,
можно выделить несколько этапов, которые имеют место при загрузке данных из систем источников в ХД, и, далее, в витрины данных.
Попробую описать некоторые особенности загрузки, имеющие место на каждом этапе.
- Загрузка данных в область стейджа ХД.
Несколько систем источников данных, из каждой системы выгружаются одна или более таблиц источников данных. Данные в этих таблицах источниках, с точки зрения разработанного ETL, обычно совсем не связанны или связанны достаточно слабо.
Данные забираются на периодической основе, возможны также некоторые особенности характера загрузки этих данных, например, временные ограничения на начало загрузки, либо ограничения на количество одновременно загружаемых потоков данных. - Загрузка данных в ХД из области стейджа.
Большое количество сильно связанных таблиц. Так как ХД как раз предназначено для обобщения и унификации данных из разных источников, возникает вопрос последовательности обработки таблиц источников для правильного формирования результирующего набора таблиц ХД.
Для таблиц хранилищ данных также довольно частой ситуацией является зависимость одних данных в ХД от других данных в ХД, которые должны быть загружены ранее.
Большое количество таблиц источников и таблиц приемников данных. - Загрузка данных в витрины данных из ХД.
Аналогично предыдущему этапу. Отличие, возможно, будет заключаться в том, что в случае витрины данных одна таблица (витрина) зависит от нескольких таблиц из ХД.
В своей практике я сталкивался с двумя подходами к организации загрузки зависимых таблиц.
Первый - строить workflow загрузки зависимых таблиц вручную, организовав последовательность загрузки в виде иерархии.
Второй подход - организовать расчет зависимостей таблиц на основе метаданных, которые хранятся в моделях Oracle Data Integrator, а точнее, в репозитории данных.
Ручное определение зависимостей.
При ручном определении зависимостей, сами зависимости реализовываются в виде иерархии вызовов загрузки отдельных таблиц или наборов таблиц. При этом весь процесс загрузки можно схематично представить в следующем виде:
Главный пакет (в том числе с мониторингом загрузки)
- Загружаем стейдж (в том числе следим за временем начала загрузки подсистем)
- Загружаем систему 1 (следим за количеством одновременных загрузок)
- Загружаем таблицу 1
- Загружаем таблицу 2
- ...
- Загружаем таблицу N.
- Загружаем систему 2
- ...
- Загружаем систему N
- Загружаем ХД
- Загружаем таблицы ХД уровня 1
- Загружаем таблицу 1
- Загружаем таблицу 2
- ...
- Загружаем таблицу N.
- Загружаем таблицы ХД уровня 2
- ...
- Загружаем таблицы ХД уровня N
- Загружаем витрины
- Загружаем витрину 1
- Загружаем витрину 2
- ...
- Загружаем витрину N
Такая иерархия процессов загрузки очень хорошо реализовывается через пакеты ODI. Для загрузки данных на стейдж, например, разрабатывается ряд интерфейсов, каждый из которых загружает данные в одну таблицу стейджа.
Далее каждый интерфейс, при необходимости, вставляется в пакет, дополняется процедурами или переменными, и из пакета генерируется сценарий. Вполне возможна и ситуация, когда интерфейс может использоваться в виде сценария и без его добавления в пакет.
Далее несколько сценариев оформляются в виде пакета, который реализует шаг Загружаем систему N из описанной выше иерархии. Сгенерировав сценарий из этого пакета мы получим единицу запуска для пакета Загружаем стейдж.
Добавляем сценарии загрузок других систем источников, обеспечиваем запуск в нужное время и в нужной последовательности, а затем, сгенерированный из этого пакета сценарий, добавляем в главный пакет загрузки данных в ХД.
Для загрузки данных в ядро ХД применяется примерно такой же подход. Сценарии, загружающие отдельные таблицы группируются в пакеты. Группировка производится по принципу независимости данных в загружаемых таблицах друг от друга.
Например, первый уровень данных ХД - данные, которые зависят только от таблиц стейджа, второй уровень - загрузка тех данных, которые зависят от стейджа и таблиц первого уровня и т.п.
Далее сценарии загрузки каждого уровня последовательно вызываются из пакета загрузки всех данных в ХД.
Небольшая иллюстрация подобного пакета верхнего уровня, для которого убрана обвязка в виде мониторинга процесса загрузки:
Автоматическое определение зависимостей.
При автоматическом определении зависимостей запуск сценариев загрузки каждой таблицы производится согласно последовательности, которая может изменяться от запуска к запуску. Эта последовательность хранится отдельно от главного пакета, загружающего все данные в ХД.
Схематически, такая организация загрузки может выглядеть так:
Главный пакет (в том числе с мониторингом загрузки)
- Сценарий запуска сценариев загрузки данных
- Получить следующий сценарий для запуска из таблицы зависимостей.
- Есть сценарий для запуска? Если да, идем к пункту 3, иначе пункт 6.
- Запустить сценарий на выполнение.
- Количество запущенных сценариев или загруженность системы достигло пороговых значений? Если да пункт 5, иначе пункт 1.
- Заснуть на 30 секунд. Перейти к пункту 4.
- Завершить работу сценария.
Самый главный и самый ответственный участок здесь - это получение следующего (первого) сценария для запуска. Теоретически, иерархию зависимостей можно строить каждый запуск, практически, конечно же, достаточно в отдельной таблице хранить список зависимостей, который генерируется с определенной периодичностью, возможно, путем ручного запуска некой сохраненной процедуры.
Процесс выбора следующего сценария, в этом случае, может выглядеть так:
- Найдем сценарий, который уже готов к запуску, т.е. все таблицы источники которого уже загружены (также в вышеприведенный алгоритм необходимо, таким образом, добавить механизм отслеживания выполненных сценариев).
- Из этих сценариев выберем тот, который имеет более высокий приоритет (каким-то образом необходимо задавать приоритет сценариев)
Процедура расчета зависимостей может опираться на те метаданные, которые находятся в репозитории ODI, и из которых можно получить информацию о том, какая целевая (зависимая) таблица, от каких таблиц источников зависит.
Далее необходимо каким-то образом устанавливать зависимость между именем целевой таблицы и наименованием сценария. Для сценариев, сгенерированных из интерфейсов, таким способом может быть установление правил именования интерфейсов, при котором интерфейс называется так же как и целевая таблица, которую он загружает.
Приоритеты и другие категории сценариев могут задаваться, например, через использование маркеров на папках в дереве проекта, или на особенностях наименования этих папок и т.п.
Так же, при формировании таблицы зависимостей, можно на основе неких правил создавать несколько групп загрузки. Т.е. вполне возможно выделить из всего набора интерфейсов (так как зависимости строятся через анализ интерфейсов, пакетов или переменных, т.е. в общем-то, оперируем мы объектами разработки) только некоторые из них, а затем внести их в отдельную группу, и потом эту отдельную группу рассчитывать главным пакетом.
Сравнение этих двух подходов.
Мне довелось поработать и с ручным и с автоматическим использованием зависимостей в ежедневной загрузке данных. Плюсы и минусы каждого подхода как с моей точки зрения, так и по словам моих коллег, которых я просил прокомментировать этот вопрос, представлены ниже.
Плюсы ручной организации загрузки зависимых таблиц
- Более простая и наглядная структура, более быстрая реализация.
- Возможны тонкие настройки процесса загрузки, когда часть загрузки таблицы может быть выполнена на одном уровне, и некоторая другая часть, возможно, как обновление некоторых столбцов, на другом уровне.
- Возможность управления приоритетами, когда часть таблиц ХД, важных для главных отчетов, может быть жестко настроена на первоочередной рассчет.
- Хорошая наглядность. Отображение сессии выполнения ежедневной загрузки в Операторе покажет процесс загрузки в виде дерева сценариев, по которому ясно, на каком уровне или этапе идет загрузка.
Минусы ручной организации
- Необходимость поддержки и аккуратного добавления ETL сценариев загрузки таблиц в иерархию загрузок.
- Необходимость поддерживать равномерность загрузки уровней вручную. Так как следующий уровень не может начаться до того, как закончится текущий, необходимо следить за тем, чтобы время загрузки таблиц одного уровня было сопоставимым.
- Жесткая схема загрузки требует быстрой реакции по исправлению ошибок нижнего уровня, так как каждый следующий уровень загрузки данных зависит от предыдущего.
Плюсы автоматического workflow
- Простота добавления или исключения сценария из процесса загрузки. Разработчик может не беспокоиться о том, в какое именно место необходимо добавить вызов его сценария. При изменениях в ETL, добавлении или удалении таблиц источников, порядок загрузки изменится автоматически.
- Простота перезапуска процесса загрузки после исправления ошибок.
- Данные в независимых потоках могут быть рассчитаны до конца, несмотря на ошибки в рассчетах данных нижнего уровня.
- При наличии дополнительных метаданных для описания сценариев, становится возможным запуск загрузок по группам, передача дополнительных параметров в сценарии, приоретизация сценариев, назначения сценариям такой характеристики как стоимость выполнения и т.д. и т.п.
Минусы автоматического workflow
- Необходимость разработки и поддержки системы перестроения зависимостей, а также дополнительных метаданных для хранения и управления этими зависимостями.
- Недостаточная управляемость процессом организации загрузки данных. Процесс загрузки регламентируется правилами, которые заданы в пакете запускателе.
- Недостаточная гибкость в использовании средств ODI. Загрузка одной таблицы несколькими интерфейсами, обновление таблицы после основной загрузки данных в нее, расчет зависимостей для пакета из нескольких интерфейсов и т.п. может потребовать неординарного процесса расчета зависимостей и (или) добавления в алгоритм пересчета зависимостей большого количества исключений.
- Необходимость, каким-то образом, ограничивать разработчиков ETL процедур от изменений в боевых интерфейсах, так как именно на их основе строится система зависимостей.
- Меньшая наглядность при просмотре процесса выполнения загрузки в Операторе.
Конечно, в одном ХД могут использоваться обе этих схемы в какой-то пропорции. Изначально, мне больше нравился подход с ручным определением порядка загрузки, но теперь я, все же, больше склоняюсь ко второму подходу.
а ещё мы добавили расчёт приоритетов в зависимости от количества "зависимых" ETL
ОтветитьУдалить