Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Регрессионное тестирование хранилища  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1390
Ищу способ оценивать влияние разработки на хранилище .. Кто нить раскроет инфу по своим лучшим практикам ?
2 авг 17, 11:22    [20694233]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Jack Carver
Member

Откуда: obi2ru.blogspot.com
Сообщений: 1691
DbFit
2 авг 17, 11:52    [20694423]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Sintetik
Member

Откуда: SpB->Msk->...
Сообщений: 4582
[новый срок разработки] = [старый срок] * [количество изменений схемы в неделю]
2 авг 17, 12:51    [20694660]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1390
Sintetik,

Ок. про деньги тоже интересно ) но больше всего болит о том как проверить что новая разработка не сломает замок на костылях , который возник в прошлый раз
2 авг 17, 13:52    [20694895]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1390
Sintetik
[новый срок разработки] = [старый срок] * [количество изменений схемы в неделю]



для инфо - в науке готворят - чем больше делаешь - тем меньше должен времени тратить

http://baguzin.ru/wp/?p=2222
2 авг 17, 14:08    [20694955]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Sintetik
Member

Откуда: SpB->Msk->...
Сообщений: 4582
essbase.ru
Sintetik
[новый срок разработки] = [старый срок] * [количество изменений схемы в неделю]



для инфо - в науке готворят - чем больше делаешь - тем меньше должен времени тратить

http://baguzin.ru/wp/?p=2222

может мы о разном? я про опыт когда исходные системы откуда тащили данные в ХД быстро изменялись, и менялись не нами
2 авг 17, 14:46    [20695071]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 3534
essbase.ru,

Мы начали смотреть в сторону Anchor Modeling aka 6th Normal Form

Эта концепция ориентирована на частые изменения в ХД
8 авг 17, 17:39    [20709140]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Критик
Member

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

только удобство работы будет околонулевое
8 авг 17, 17:49    [20709164]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Гулин Федор
Member

Откуда: МИНСК
Сообщений: 901
Jack Carver
DbFit

а пару слов как что и зачем ?
кто пишет тесты как они запускаются (автоматически через какой-то CI )
и т.д и т.п
поделитесь плз опытом ( можно без деталей - общая схема плюсы и минусы)
8 авг 17, 17:52    [20709168]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 4638
как говорится: "мопед не мой..."
тестирование ХД в Тинькофф
8 авг 17, 19:27    [20709329]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1390
a_voronin
essbase.ru,

Мы начали смотреть в сторону Anchor Modeling aka 6th Normal Form

Эта концепция ориентирована на частые изменения в ХД


Да меня тоже заинтересовал cпич архитектора из AVITO. Такой жесткий PR заставляет задуматься .( и для новго проекта я тоже это попробую )

* осталось придумать как развивать старье ) вот ради этого и подпрыгиваю.
8 авг 17, 21:39    [20709508]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Полковник.
Member

Откуда:
Сообщений: 1606
essbase.ru
a_voronin
essbase.ru,

Мы начали смотреть в сторону Anchor Modeling aka 6th Normal Form

Эта концепция ориентирована на частые изменения в ХД


Да меня тоже заинтересовал cпич архитектора из AVITO. Такой жесткий PR заставляет задуматься .( и для новго проекта я тоже это попробую )

* осталось придумать как развивать старье ) вот ради этого и подпрыгиваю.


Data Vault то чем не угодил? Любое нормализованное ХД поддерживает изменения, даже простая 3NF.

Встречал такого Гопова, который затеял анкер в одном из банков, уж не знаю ради чего, подозреваю, что ради собственных амбиций. Идея провалилась, архитектор сбежал, люди которые остались переделывали все это на звезду-снежинку.

А ведь есть ещё и "голандская" модель КХД.
9 авг 17, 07:56    [20709791]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1390
Полковник.
Идея провалилась

эх.. анализ провала бы найти и почитать )
9 авг 17, 13:54    [20710780]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 4638
essbase.ru
эх.. анализ провала бы найти и почитать )
ну а чего там читать :)
что DataVault, что Anchor разбивает бизнес сущность на много объектов и на этапе построения денормализованной витрины у вас начинается "ад" (ad-hoc ту да же).
это как EAV... нужно стараться избегать пока возможно и использовать когда припрёт (понимая все плюсы\минусы).
когда у вас большое ХД и частые изменения структуры (добавление сущностей, атрибутов и тд), то деваться некуда и приходится идти по этому пути "мышей с кактусом".
9 авг 17, 14:22    [20710883]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Voyager_lan
Member

Откуда:
Сообщений: 1437
Дедушка
essbase.ru
эх.. анализ провала бы найти и почитать )
ну а чего там читать :)
что DataVault, что Anchor разбивает бизнес сущность на много объектов и на этапе построения денормализованной витрины у вас начинается "ад" (ad-hoc ту да же).
это как EAV... нужно стараться избегать пока возможно и использовать когда припрёт (понимая все плюсы\минусы).
когда у вас большое ХД и частые изменения структуры (добавление сущностей, атрибутов и тд), то деваться некуда и приходится идти по этому пути "мышей с кактусом".

От себя добавлю. Для долгоиграющих проектов (так сказать, "есть слона по кускам" несколько лет) оное актуально, т.к. ТЗ уже раз 10 устареет пока напишешь плюс сокращение времени на доработку ETL/DWH. Расплата же все равно настигент на этапе построения денормализованной витрины :) Но оно того будет стоить.
Ежели скоуп известен заранее, то Kimball рулит, т.к. все преимужества Anchor / DV modelling будут несущественны.
9 авг 17, 17:30    [20711554]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
sergei_go
Member

Откуда: BETWEEN SPB AND MSC
Сообщений: 206
Полковник.,
Не амбиций, а ради реалий, когда ресурсов на работу с требованиями внутри заложено не было, а внешний подрядчик обладал экспертизой студентов.
Не амбиций, а ради итерационного постепенного развития.
Не оставшиеся люди, а вновь пришедшие, которые не смогли понять идею.
Там не просто Anchor был, а bitemporal Anchor.
Безусловно Anchor, как и любой другой подход, уместен при определённых вводных, и должен сказать при высоком уровне автоматизации. В AVITO, как раз, это и сделали. В противном случае очень много рутины.
9 авг 17, 18:14    [20711692]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1390
sergei_go
при высоком уровне автоматизации

автоматизация чего?
* очень странный посыл - априори - хранилище это не про ручной ввод ))
9 авг 17, 20:23    [20711919]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 4638
essbase.ru
автоматизация чего?
пример:
ХД DataVault на mssql (около 1000 таблиц)
ETL на ssis (около 1000 пакетов)
автоматизация - построение ETL biml-ом по метаданным, а не руками
9 авг 17, 22:49    [20712199]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 31048
Блог
Дедушка
автоматизация - построение ETL biml-ом по метаданным, а не руками


имеет ли смысл такая автоматизация?
девочку-студентку нанять за 30 тыр, она за месяц всю тысячу сделает,

а с biml`ом требования к разработчику повышаются, а раз так, то и зп ему нужно большую платить
9 авг 17, 23:04    [20712224]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Alex_496
Member

Откуда: Moscow http://dvbi.ru
Сообщений: 3467
Критик
Дедушка
автоматизация - построение ETL biml-ом по метаданным, а не руками


имеет ли смысл такая автоматизация?
девочку-студентку нанять за 30 тыр, она за месяц всю тысячу сделает,

а с biml`ом требования к разработчику повышаются, а раз так, то и зп ему нужно большую платить


телефончик той студентки дадите?
10 авг 17, 00:17    [20712284]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
sergei_go
Member

Откуда: BETWEEN SPB AND MSC
Сообщений: 206
essbase.ru,
Дедушка уже ответил.
Критик,
человеческий фактор никто не отменял, девочку найти нужно, за девочкой следить нужно.
Да есть на рынке уже автоматизация ETL, и для Anchor, и для DataVault - этим они и хороши, но в отличии от от DataVault, где можно себе волю дать в объединении атрибутов, AM содержит более строгие правила для создания модели.
Как и везде свои плюсы, свои минусы.
10 авг 17, 01:09    [20712314]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
HF
Member

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

Про расплату можно подробнее? Кроме серьезных требований к железу, для построения витрин, какие еще последствия?
11 авг 17, 12:41    [20716425]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
Дедушка
essbase.ru
автоматизация чего?
пример:
ХД DataVault на mssql (около 1000 таблиц)
ETL на ssis (около 1000 пакетов)
автоматизация - построение ETL biml-ом по метаданным, а не руками

м-м-м-м.... а можно было настроить простую репликацию.....
11 авг 17, 13:41    [20716722]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
HF
Voyager_lan,

Про расплату можно подробнее? Кроме серьезных требований к железу, для построения витрин, какие еще последствия?

частые изменения структуры - получи частую ручную переделку витрин.
11 авг 17, 13:42    [20716730]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
Дедушка
как говорится: "мопед не мой..."
тестирование ХД в Тинькофф

по факту там смоук теститнг - накатили изменения - весь etl не упал - хорошо. Регрес пройден
11 авг 17, 13:46    [20716748]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 4638
Ivan Durak
по факту там смоук теститнг
ну почему же? я бы сказал, что и юнит то же.
есть исходные данные (это может быть и суррогатный тестовый набор) есть результирующий набор (то как мы его представляем исходя из ТЗ и логики работы наших алгоритмов)
после отработки ETL (его части) полученный набор должен совпадать (по неким метрикам) с результирующим.
Ivan Durak
м-м-м-м.... а можно было настроить простую репликацию...
тут вам стоит пояснить свою мысль...
11 авг 17, 14:08    [20716864]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
Дедушка
Ivan Durak
по факту там смоук теститнг
ну почему же? я бы сказал, что и юнит то же.
есть исходные данные (это может быть и суррогатный тестовый набор) есть результирующий набор (то как мы его представляем исходя из ТЗ и логики работы наших алгоритмов)
после отработки ETL (его части) полученный набор должен совпадать (по неким метрикам) с результирующим.

представить результирующий набор по ТЗ - это уже функциональное тестирование. Оно конечно тоже нужно. Но пишется руками. Потому применение очень дорого и ограничено.
11 авг 17, 14:44    [20717006]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
Дедушка
тут вам стоит пояснить свою мысль...

ну быстро дотащить хлам из реляционных источников в хд - это как раз задача репликации.
причем в неизменном виде как он прийдет из реплик - он будет еще и удобнее для построения витрин, нежели дата ваулт
11 авг 17, 14:48    [20717028]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
HF
Member

Откуда:
Сообщений: 27
Ivan Durak,

Так это с анкором вообще никак не связано. При любой архитектуре изменение модели может повлечь за собой изменение витрин. И кост на переработку будет одинаковый.
11 авг 17, 15:17    [20717160]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Полковник.
Member

Откуда:
Сообщений: 1606
Ivan Durak
Дедушка
тут вам стоит пояснить свою мысль...

ну быстро дотащить хлам из реляционных источников в хд - это как раз задача репликации.
причем в неизменном виде как он прийдет из реплик - он будет еще и удобнее для построения витрин, нежели дата ваулт


Мощно задвинул, внушает. А люди мучаются темпоральные КХД создают. А тут взял репликацию источника свалил в кучу и получил кучу...

У меня сейчас 30 источников - ERP систем от Калининграда до Владивостока, мне их все нужно связать в единый узел с сохранением всей истории любого изменения данных.
Куда здесь я прикину репликацию?
11 авг 17, 16:33    [20717400]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1390
Полковник.
Куда здесь я прикину репликацию?


Какой тип хранилища выбрали ? Будите ли делать регрессионые тесты ?
11 авг 17, 20:52    [20717841]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
HF
Ivan Durak,

Так это с анкором вообще никак не связано. При любой архитектуре изменение модели может повлечь за собой изменение витрин. И кост на переработку будет одинаковый.

не одинаковый, совсем не одинаковый
14 авг 17, 09:37    [20720885]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
Полковник.
Ivan Durak
пропущено...

ну быстро дотащить хлам из реляционных источников в хд - это как раз задача репликации.
причем в неизменном виде как он прийдет из реплик - он будет еще и удобнее для построения витрин, нежели дата ваулт


Мощно задвинул, внушает. А люди мучаются темпоральные КХД создают. А тут взял репликацию источника свалил в кучу и получил кучу...

У меня сейчас 30 источников - ERP систем от Калининграда до Владивостока, мне их все нужно связать в единый узел с сохранением всей истории любого изменения данных.
Куда здесь я прикину репликацию?

найти баланс между велосипедом и коробочным солюшеном всегда сложно. Но видно, что у вас его нет.
14 авг 17, 09:39    [20720892]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
HF
Member

Откуда:
Сообщений: 27
Ivan Durak,

Вопрос был не праздный. Разница в костах на изменение модели хранилища при DV/Anchor в сравнении с 3NF/Звезда очевидна.
А вот при построении витрины, после того как в само ХД изменения уже внесены - с первого взгляда я не вижу. Для витрины принципиально изменение логической модели данных, а способ ее физического представления на входе принципиального значения не имеет. Какие будут аргументы за усложнение перестроения витрин при Anchor модели?
14 авг 17, 11:18    [20721220]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1390
HF
Вопрос был не праздный. Разница в костах на изменение модели хранилища при DV/Anchor в сравнении с 3NF/Звезда очевидна.


Кому очевидна ? Вам ?
Аргументы ? Как считали ?
14 авг 17, 12:02    [20721372]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
HF
Member

Откуда:
Сообщений: 27
essbase.ru,

Ну, например, при Anchor добавление/удаление показателя не требует переработки ранее реализованного функционала ETL и модификации структур существующих таблиц. Фактически, в большинстве случаев можно обойтись внесением изменений в метаданные. В том случае, когда изменения требуются, они более четко локализованы, что также упрощает процесс изменения.
14 авг 17, 14:10    [20721879]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Критик
Member

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

да? и даже не требуется модифицировать то, что показывается пользователям?
14 авг 17, 14:30    [20721966]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
HF
Member

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

Стоп :) Речь шла об изменении модели самого хранилища (или точнее, детального слоя данных), а не витрин. Про витрины я спрашивал выше. По моему мнению, изменение витрин стоит сопоставимо при любой физической модели самого детального слоя. Если есть аргументы, почему это не так, было бы очень полезно их услышать.
14 авг 17, 14:37    [20722000]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 4638
Критик
да? и даже не требуется модифицировать то, что показывается пользователям?
смысл троллить колеги?
очевидно же, что если добавляемый показатель\атрибут должен показываться в отчётах (сам по себе или как элемент расчётных показателей), то отчёты требуют модификации.
тут дело в том, что модификация отчётов (в большинстве случаев) менее трудоёмка чем модификация существующих таблиц ХД и ETL процессов и более проста в тестировании.

что касается затрат на сборку витрины в проекте DV...
если вы решаете собирать именно "классическую" витрину поверх DV, то трудозатраты выше чем сборка поверх "классического" ХД.
это проистекает из-за того, что в DV бизнес сущность размазана на много таблиц каждая из которых может содержать свои временные диапазоны версий и собрать всё это вместе не просто особенно если у вас слабое железо или реляционная платформа.
если же вы делаете DV на MPP системе, то эта трудность сильно сглаживается, а плюсы от лёгкого добавления атрибутов в ХД\ETL наиболее заметны.
как я писал выше, нужно понимать плюсы и минусы DV схемы при выборе её для ХД проекта и использовать только если вас припёрли к стенке требованиями частых и непредсказуемых изменений в требованиях на ХД.
14 авг 17, 15:05    [20722131]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3268
HF
Ivan Durak,

Вопрос был не праздный. Разница в костах на изменение модели хранилища при DV/Anchor в сравнении с 3NF/Звезда очевидна.

че-то мне вот не очевидно.
Огласите пожалуйста разницу с примерами: например новый линк в DV vs новый факт в звезде.
14 авг 17, 16:25    [20722532]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
HF
Member

Откуда:
Сообщений: 27
Дедушка,

В целом придерживаюсь того же мнения.

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


- задача сборки сущности из нескольких таблиц с разной историей не является исключительной для DV/AM (Anchor Model), также присутствует и при 3NF модели. Хорошо то, что решить ее можно один раз и в дальнейшем переиспользовать для различных сущностей и в различных проектах. Поэтому в данном случае, я бы говорил не про трудозатраты на реализацию, а про требования к оборудованию.

Проекты DWH длинные как в разработке так и в дальнейшем саппорте, поэтому изменение требований скорее данность, чем исключение. Использование AM позволяет не только повысить гибкость модели, но и позволяет значительно автоматизировать процесс разработки ETL, а также больше переиспользовать код как внутри проекта, так и в последующих проектах, а также масштабировать процесс разработки. На другой чаше весов стоимость железа и первичной разработки (прежде чем переиспользовать, надо один раз сделать).

Выбор стар как мир - что лучше, один раз "день потерять, потом за 5 минут долететь" или "посадить сто человек с Excel, пусть считают".
Как инженер, я за первый подход, но для бизнеса часто второй бывает выгодней ;)

Поэтому к перечисленным Дедушкой критериям использовать или нет DV/AM я бы добавил еще, будете ли вы реализовывать еще подобного рода проекты в будущем или это разовая разработка.
14 авг 17, 16:44    [20722600]     Ответить | Цитировать Сообщить модератору
 Re: Регрессионное тестирование хранилища  [new]
sergei_go
Member

Откуда: BETWEEN SPB AND MSC
Сообщений: 206
Ivan Durak, по-моему не в тему. Сравнить можно Link и новую ссылку на факте/измерении.
И даже так сравнивать будет тяжело без определенных вводных.
Навскидку,
под загрузку линка нужен будет отдельный ETL-task, для загруки ссылки нужно будет менять существующий ETL-task со всеми вытекающими.
загрузка линка - insert, загрузка ссылки - update, ну или если хотите recreate
и как я сказал - минусы и плюсы определите сами.
14 авг 17, 16:56    [20722648]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / OLAP и DWH Ответить