Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 SCD 2 или 4?  [new]
aleksrov
Member

Откуда:
Сообщений: 825
Всем привет!
На самом деле вопросов несколько, буду крайне признателен за помощь.
1) Есть DimCustimer, обычная такая Dim, НО бизнес хочет хранить историю ЛЮБЫХ изменений, за последнии N месяцев, т.е. если у него изменился хотя бы один из атрибутов, то мы перезаписываем данные как в scd 1, а старую строку делаем historical, при этом у новой SurogateKey должен быть как у старой записи. Т.е. был surkey = 1, cust_id = 1, phone = 44444, у него поменялся телефон, новая строка surkey = 1, cust_id=1, phone = 55555, а старая surkey = (вот здесь что, и куда это строку деть?), cust_id = 1, phone = 44444. Для анализа эти данные не нужны, они понадобятся лишь точечно, когда по клиенту возникнут проблемы (к примеру были случаи мошеничества, и изменения данных клиента пригодились бы), определятся будет во время ETL загрузки, у него есть поле update_at.
Тут было несколько идей: в etl перед обновлением читать строку, сохранять в переменную, обновлять строку, а старую вставлять заново с флагом history, surkey соответственно у нее будет новый.
Или делать тоже самое но вставлять строку в minidim, которая будет хранить только исторические данные и не связана с фактом, с основной dim связь один ко многим.
Также предлагали сделать parent_id в dim, типа у каждой новой строки родитель самая первая, но как-то это не то.....
Кто нибудь делал что нибудь подобное и как это будет выглядеть?
2) Есть большой факт, заявка, у факта много левой инфы которая также нужна но привязана именно к факту, вроде источник откуда пришел клиент (разные сайты, в справочник не вынести), ссылка по которой он клацнул для перехода на наш сайт, столбцы типа в каких он сайтах был залогинен, ip, и прочее прочее. Думал сделать отдельную dim для всего этого, но тогда она будет расти также как fact... В общем здесь тоже вопрос.
17 июл 18, 21:08    [21579078]     Ответить | Цитировать Сообщить модератору
 Re: SCD 2 или 4?  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30393
Блог
Исходя из заявленных целей, историю клиентов я бы вынес отдельно, иначе у вас etl замедлится:
- рассчитываем обычных клиентов
- потом низкоприоритетно сравниваем историю клиентов и клиентов, так формируем набор для истории

По "широким" фактам не понимаю, что вам мешает выделить тот же сайт из факта и отправить его в отдельный справочник?
"столбцы типа в каких он сайтах был залогинен" - это вообще отдельный факт
17 июл 18, 21:47    [21579143]     Ответить | Цитировать Сообщить модератору
 Re: SCD 2 или 4?  [new]
Полковник.
Member

Откуда:
Сообщений: 1728
aleksrov,

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

Для сравнения я бы посоветовал использовать хеш ключи на основе криптографических функций MD5 например - строка с набором колонок даёт единственное значение, сравниваешь со значением в активной строке (последней), мержем закрываешь предыдущую активную, вставляешь новую.
17 июл 18, 21:50    [21579151]     Ответить | Цитировать Сообщить модератору
 Re: SCD 2 или 4?  [new]
aleksrov
Member

Откуда:
Сообщений: 825
Критик,

Спасибо за ответ!
Вопрос если хранить историю отдельно, как это будет выглядеть. Т.е. если взять пример выше, новая строка 1,1,55555, а старая пойдет в другую таблицу вида, id = 1, parent_id = 1, cust_id = 1, phone = 44444. Не идеально, но свою цель выполнит, при необходимости сделать точечный запрос и посмотреть изменения по конкретному клиенту, или вывести клиентов где к примеру было изменение bank_number, т.е. к факту мы даже не обращаемся.
По сайтам возможно засунуть в Dim, а как быть в ip к примеру, или в каждой заявке идет score, что-то вроде рейтинга клиента, но относится именно к заявке, и подобных полей много. По поводу залогинен или нет, там просто одна строка с перечислением сайтов, как это в факт засунуть?
17 июл 18, 22:06    [21579177]     Ответить | Цитировать Сообщить модератору
 Re: SCD 2 или 4?  [new]
aleksrov
Member

Откуда:
Сообщений: 825
Полковник.
aleksrov,

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

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


"темпоральной и битемпоральной модели данных" изучу.
По поводу хеша, смысла нет так заморачиваться, у клиента есть поле update_at, когда будет инкриментальная загрузка мы будем брать всех клиентов у которых created_at или updated_at больше определенной даты, у которых created просто вставляем, у которых updated, обновляем с сохранением сурключа, а старую наверно выносим отдельно. В cтрок с updated будет не сильно много, процентов 5-10%.
17 июл 18, 22:11    [21579192]     Ответить | Цитировать Сообщить модератору
 Re: SCD 2 или 4?  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30393
Блог
aleksrov,

по ip и прочим тестовым полям можно подумать над разделением таблицы фактов на две, которые будут связаны 1-к-1, в одной наиболее часто анализируемые данные, во второй + всякий "проблемный текст"
17 июл 18, 23:11    [21579320]     Ответить | Цитировать Сообщить модератору
 Re: SCD 2 или 4?  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30393
Блог
а так все зависит от ваших конкретных тонкостей - начиная с бизнес-требований, вида вашей системы и заканчивая распределением данных
17 июл 18, 23:13    [21579326]     Ответить | Цитировать Сообщить модератору
 Re: SCD 2 или 4?  [new]
aleksrov
Member

Откуда:
Сообщений: 825
Критик
aleksrov,

по ip и прочим тестовым полям можно подумать над разделением таблицы фактов на две, которые будут связаны 1-к-1, в одной наиболее часто анализируемые данные, во второй + всякий "проблемный текст"


Наверно так и сделаю. Просто разобью факт на две таблицы, в основной будут все ключи измерений, во второй нет, она будет связана только с фактом. Запросы по ip, score, сайтам и прочему хламу тоже запускаются, это используют уже другие люди, типа data science, которые выявляют зависимости и прочие вещи. Они запускают эти запросы редко, и если запускают они все ровно связаны с основными данными, которые уже интересны бизнесу каждый день, типа даты, суммы и прочее, именно это и будет в "главном" факте. Т.е. для каждодневной или недельной отчетности нам интересны лишь часть данных факта, а для глубокого анализа уже все, из этой логики и буду разбивать.
Спасибо за помощь!
18 июл 18, 09:57    [21580078]     Ответить | Цитировать Сообщить модератору
 Re: SCD 2 или 4?  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3443
aleksrov
Всем привет!
На самом деле вопросов несколько, буду крайне признателен за помощь.
1) Есть DimCustimer, обычная такая Dim, НО бизнес хочет хранить историю ЛЮБЫХ изменений, за последнии N месяцев, т.е. если у него изменился хотя бы один из атрибутов, то мы перезаписываем данные как в scd 1, а старую строку делаем historical, при этом у новой SurogateKey должен быть как у старой записи. Т.е. был surkey = 1, cust_id = 1, phone = 44444, у него поменялся телефон, новая строка surkey = 1, cust_id=1, phone = 55555, а старая surkey = (вот здесь что, и куда это строку деть?), cust_id = 1, phone = 44444. .

и что тебя смущает??
ты в dimCustomer PK сделай surrogatekey + effective_date. И все.
И старую запись никуда удалать не надо - храни её с тем же surrogateKey.

Для скорости можно партицировать по флагу history.

Правда витрины собирать станет сложнее.
18 июл 18, 17:36    [21582073]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить