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

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

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

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

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

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

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

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

Откуда:
Сообщений: 1609
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!!!
Сообщений: 3315
HF
Ivan Durak,

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

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

Откуда: Minsk!!!
Сообщений: 3315
Полковник.
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

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

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

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

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

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

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

Откуда: Minsk!!!
Сообщений: 3315
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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
Все форумы / OLAP и DWH Ответить