ETL
Одна из важных задач в подготовке данных - управление последовательностью обновления данных в BI-аналитике.
Во время ETL-процесса, далеко не всегда можно взять готовые данные из источника, и только немного их докрутить. Часто для получения нужной структуры данных требуется задействовать несколько источников, что создает запутанные зависимости в процессе обновления данных. Вы обогащаете данные в таблице фактов из некоего справочника. Но обновлен ли был сам справочник на момент обновления фактов? Чтобы всегда быть уверенным в актуальности данных, я выработал следующую схему слоев в ETL-процессе.
Маппинги ключевых полей.
Иногда так бывает, что некоторые связанные таблицы, которые должны быть связаны, не имеют общего ключа. Зато имеют поля, по которым ключ все-таки может быть сопоставлен. Например, GUID сотрудника в ERP, и имя сотрудника в плане продаж из Экселя. Или GUID сотрудника в ERP и идентификатор сотрудника в CRM. Чтобы нормально работать с такой структурой, ключевые поля должны быть приведены к единому варианту. Например, GUID сотрудника. Таким образом, нам нужно будет иметь таблицы сопоставления: Имя сотрудника - GUID сотрудника, и ИД сотрудника - GUID сотрудник. Да, эти сопоставления можно сформировать в момент ETL-трансформаций. Но тогда: 1) мы теряем возможность их удобно переиспользовать. Сегодня мы подменяем имена в GUID в одной табличке планов, а завтра нам упадет еще какая-нибудь ведомость и т.д. 2) это просто удобно - видеть четкий перечень трансформируемых ключевых полей. Естественно, маппинги должны считаться на основе подключений к источникам, чтобы при обновлении этого слоя быть гарантированно актуальными.
Базовый слой для дальнейших трансформаций.
Опциональный слой таблиц, которые выгружаются из источников для дальнейшего ETL-процесса без обращения к самому источнику. Не содержит сложных трансформаций, чтобы не грузить источник и выполняться максимально быстро. Используется по мере необходимости в целях оптимизации нагрузки на источник и ускорения последующей части ETL-процесса. Может быть частью ETL определенной таблицы из п.3 и не выноситься для переиспользования в других процессах.
Первичные аналитические таблицы.
А вот тут уже собираются таблицы, которые пойдут в АХД. Под каждую таблицу проектируется автономный процесс обновления, который использует: 1) Маппинги; 2) Подключение к источникам; 3) Данные из базового слоя; И никогда не использует другие аналитические таблицы, чтобы не создавать зависимостей. Таким образом, выполнение ETL-процесса с созданием первичной аналитической таблицы гарантирует наличие в ней актуальных данных.
Вторичные аналитические таблицы.
После того, что мы получили много причесанных и обогащенных таблиц, вполне возможно что нам захочется создать структуры данных, которых нет в источнике. Посчитать прогноз, произвести моделирование. Вот тут мы можем задействовать таблицы из п.3. Таким образом, у нас получается очень простая модель управления актуальностью данных, в которой всегда легко ориентироваться. А как вы управляете обновлением данных в своих проектах?
