Если не хватает какого то поля, то загружаем его. Если таблица на источнике неисторичная, то это поле забираем на текущий момент. Если есть таблица на источнике историчная, и по новому полю есть данные за прошлые периоды, то перегружаем за все время или с нужной даты.
1) У нас DL историчный, так как мы все почти грузим SCD2 (то есть даже неисторичные таблицы источников у нас обретают историю). На IL формируем таблицу с датами valid_from/valid_to по изменениям обеих таблиц (так как есть история на DL).
С бизнесом договоренности есть только по витринам на BL, так как бизнес не знает о всей логике хранилища - отображаем неисторичное на дату последнего изменения (то есть на текущий момент значения).
2) Если случаются на источнике такие правки, то перегружаем DL/IL таблицы с нужной даты или за все время.
В системах отчетности SAP BusinessObjects и PowerBI все формулы прописаны для метрик (продажи, себестоимость, коэффициенты возврата, продаж и др), которые используют пользователи, им не приходится заново рассчитывать их. И также мы делаем описания в confluence в спейсе, к которому есть доступ у всей компании.
Если происходят моменты несходимости данных в отчетах, то обсуждаем с отделами, что и как они используют, анализируем их отчеты, стараемся прийти к единой логике, и если есть необходимость в создании новых метрик, то добавляем их в SAP BO и Power BI. Это помогает избежать ошибок в дальнейшем.
Спасибо!
У нас города в системе-источнике в транслитерации, поэтому для удобной связи в APEX создали справочник с такими же названиями.
Генерируем сурругатные ключи не для каждой версии записи, по ключу таблицы на DL.
Если не хватает какого то поля, то загружаем его. Если таблица на источнике неисторичная, то это поле забираем на текущий момент. Если есть таблица на источнике историчная, и по новому полю есть данные за прошлые периоды, то перегружаем за все время или с нужной даты.
1) У нас DL историчный, так как мы все почти грузим SCD2 (то есть даже неисторичные таблицы источников у нас обретают историю). На IL формируем таблицу с датами valid_from/valid_to по изменениям обеих таблиц (так как есть история на DL).
С бизнесом договоренности есть только по витринам на BL, так как бизнес не знает о всей логике хранилища - отображаем неисторичное на дату последнего изменения (то есть на текущий момент значения).
2) Если случаются на источнике такие правки, то перегружаем DL/IL таблицы с нужной даты или за все время.
В основном забираем с источника батчами средствами SQL (полный или инкрементальный забор данных).
Спасибо, Коля!
Модель будет определяться многими факторами (команда, мощности, интенсивность загрузки). Железо придется сменить, но это не точно.
Хадуп не очень хорошо себя показал для наших основных потребностей.
Базовые показатели на уровне DWH. Остальные, которые можно вынести - в SAP BO и PowerBI.
Мы давно используем Oracle, как правило, миграция - это дорого, плюс не считали профит от перехода.
Но ClickHouse используется в отделе R&D для решения их задач.
В системах отчетности SAP BusinessObjects и PowerBI все формулы прописаны для метрик (продажи, себестоимость, коэффициенты возврата, продаж и др), которые используют пользователи, им не приходится заново рассчитывать их. И также мы делаем описания в confluence в спейсе, к которому есть доступ у всей компании.
Если происходят моменты несходимости данных в отчетах, то обсуждаем с отделами, что и как они используют, анализируем их отчеты, стараемся прийти к единой логике, и если есть необходимость в создании новых метрик, то добавляем их в SAP BO и Power BI. Это помогает избежать ошибок в дальнейшем.