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

Откуда: Нижний Новгород
Сообщений: 2042
Коллеги,

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

может кто такие задачи решал?

спасибо.
15 июн 18, 12:08    [21493346]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2042
ShIgor,

а, ну да забыл, линковать не предлагайте пожалуйста.
15 июн 18, 12:09    [21493347]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5113
про каждый тип процессинга в доке написано приводит ли он к процессингу связанных обектов,
удаляет ли индексы и связи...
измерение же в кубе не само по себе лежит, а со связями, агрегатами и mdx-ом
15 июн 18, 12:56    [21493508]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
vikkiv
Member

Откуда: London
Сообщений: 1420
попытки attach/detach/ подмены с клонированием ID, даже если возможно какими-то кустарными способами - я-бы не рассматривал как серьёзное решение.

в чём именно проблема при процессинге? если тяжесть в поднятии данных из источника (view) из-за сложной логики/трансформаций on-a-fly то можно просто материализовать сначала в таблицу.

(как вариант процессить остальные измерения не из SQL, а из MDX/DAX/DMX источника {который только что отпроцессили})

всё остальное скорее относится к оптимизациям самого измерения (типы данных, properties, ключи, и пр., бывает нагородят в DSV связей и строят измерение на стороне SSAS из десятков объектов - а SSAS потом приходится кучу цепей из join-ов строить по комбинированным ключам) и другим методам ускорения получения данных (конфигурация обоих серверов {источник/ssas-настройки под process} железо/сеть/диски/структура запроса..) и организации операции process (например отдельным job-om или separate transaction чтобы временная копия меньше ресурсов требовала перед commit)

иногда стоит посмотреть что там в результате на диске получается в директории измерения (тоже по весу - какие именно атрибуты тяжелые и какой тип store)

process-as-table тип для такого количества строк наверняка только ухудшит ситуацию.

это если проблемы именно с измерением (и оно хотя-бы иногда получает порцию process-full), бывает что выглядит как затык в измерении - а на самом деле висит на MG-индексах или чём-то ещё.
15 июн 18, 13:16    [21493588]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
vikkiv
Member

Откуда: London
Сообщений: 1420
верно Дедушка советует, убей всё кроме измерения в отдельную тестовую базу, и там удостоверься после каких 100 process_update (с существенными изменениями данных на стороне источника) что проблема всё ещё существует.
15 июн 18, 13:20    [21493613]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
sese
Member

Откуда: маськва
Сообщений: 78
Да простят меня благородные доны,

Но измерение в пару десятков миллионов членов я понимаю только одно-атрибутное и то в виде исключения (аналитика - это взгляд с высоты птичьего полета, знаете ли, и все, что близко к атомарности - не предмет аналитики =)

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

В моем околотке сделано именно так. Древо типов товара - одно измерение, Бренд - другое измерение, Характеристики товара (не перегревать/не охлаждать/etc) - это отдельное junk измерение. И еще наберется по мелочи. А товар, коего под 20 млн - одноатрибутное измерение.

Соррьки, если я не в кассу со своим комментарием =)
15 июн 18, 13:48    [21493704]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
vikkiv
Member

Откуда: London
Сообщений: 1420
sese,

это-же место для проброса идей, даже несмотря на жестко поставленную задачу ТС-ом (на которую ни один из ответов пока не даёт решения)

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

на больших системах такой подход приведёт утяжелению MG для хранения ключей и как следствие большей нагрузкой на память для storage engine на партиции при сканировании одинакового диапазона времени (так-же навигация между атрибутами внутри одного измерения быстрее с т.зр. query performance). Иногда оправдано больше давать нагрузку на измерения (которые всё равно в памяти), иногда на MG/партиции - чисто на вкус и выбор архитектора под характер использования.
15 июн 18, 14:02    [21493765]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 33300
Блог
vikkiv
верно Дедушка советует, убей всё кроме измерения в отдельную тестовую базу, и там удостоверься после каких 100 process_update (с существенными изменениями данных на стороне источника) что проблема всё ещё существует.


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

я бы провел работу над
1) материализаций измерения
2) анализом логов 101010101001, чтобы выкинуть неиспользуемые/редкоиспользуемые атрибуты
3) оптимизацией измерения в части хранимых там данных (например, там какие-нибудь даныне в bigint, хотя хватает и tinyint)

ну и конечно, нужно понять, что тормозит при процессинге - сервер-источник, сеть или сервер-приемник,
затем устранить причину (хотя подозреваю, что SSAS кушает на 100% одно ядро, тогда только апгрейд)
15 июн 18, 14:49    [21493991]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5113
ну, как вариант:
перейти на ROLAP если источник позволяет
(что оставить в молап, а что перевести в ролап нужно смотреть)
тогда при апдейт процессинге куб не будет затрагиваться
15 июн 18, 15:03    [21494042]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2042
затык просто во времени обработки.
построено на вьюхе, которая в свою очередь объединяет 2 таблицы примерно одинакового размера (+- 1%), связь по id 1:1
ключ измерения бигинт уникальный. есть несколько атрибутов у которых ключом является строка но они все на сотни членов, не больше, кроме одного, почти под миллион (varchar(64))
замечены такие нюансы:
при обработке атрибута являющегося простой копией ключевого атрибута тормозов нет, Rows read/sec > 1млн строк.
при обработке простых атрибутов, не участвующих в пользовательских иерархиях или являющихся листовым уровнем пользовательской иерархии тоже тормозов нет.
при обработке атрибутов являющихся верхними уровнями возникают тормоза, особенно если на уровне под миллион и больше членов.
и самое интересное, при обработке ключевого атрибута Rows read/sec совсем падает до 30тыс/сек
дальше все висит на создании индексов для польз.иерархий и ключ атрибута.
В % соотношении выглядит это так:
5% чтение атрибутов + 25% чтение атрибутов польз.иерархий нелистовых уровней + 20% создание их индексов, остальное ключевой атрибут.

тестировал так же на копии результата вьюхи в локальной таблице с кластерным columnstore индексом (SQL 2016 SP2, памяти на сервере 256Гб (64 под SQL, остальное SSAS забирает как хочет, система отдает практически все, в кэше остается не больше 5Гб)
для каждого текстового атрибута при переливке создавался ключ (checksum, int)
прирост в скорости не более 10-15% за счет отсутствия переливки по сети.

но это все о производительности... да и с оптимизацией все понятно..
а вопрос приведения многократного выполнения одних и тех же задач к разовому остается открытым.
15 июн 18, 15:03    [21494046]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
Критик
Member

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

Объединить ваши проекты в один?
15 июн 18, 17:52    [21494723]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2042
Критик,

В смысле наделать разных кубов, но база будет одна?..
мысль конечно интересная...

а есть кто-нибудь у кого так? поделитесь мнением...
15 июн 18, 18:00    [21494766]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
Voyager_lan
Member

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

Критик дело говорит.
Приходилось так поступать пару раз. Задачи ведь (скорее всего) одной области, если используется то же самое измерение.
16 июн 18, 00:27    [21495605]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 3606
ShIgor,

Вопрос, а зачем такое тяжелое измерение? Его кто-то по элементам смотрит? Сдается мне тут архитектурно что-то не так. Это сводит на нет вес эффект от OLAP.
19 июн 18, 14:01    [21503225]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
Andy_OLAP
Member

Откуда: я знаю, что Зенит - чемпион
Сообщений: 2170
a_voronin
ShIgor,

Вопрос, а зачем такое тяжелое измерение? Его кто-то по элементам смотрит? Сдается мне тут архитектурно что-то не так. Это сводит на нет вес эффект от OLAP.

А это наверное измерение позиций заказов. Это даже не аналог измерения чеков, а скорее аналог измерения строк чеков.
Автор темы, я таки прав?
20 июн 18, 11:40    [21506132]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2042
Andy_OLAP,

нет.. с чеками я поступил проще.
нумерация чеков начинается на каждой кассе с 1 на каждую смену. смены открывают закрывают каждый день, поэтому необходимости держать больше 10000 тыс членов в измерении номер чека нет необходимости.
номер позиции в чеке не учитывается вообще нигде, их можно расположить по времени создания. время создания строки в секундах, так что в этом измерении больше 86400 членов тоже никогда не будет (даже больше скажу, грануляция вообще 1 минута).
товаров - 30тыс
ккм - десяток тыс
смен - ну скока там дней за 10 лет * на кол-во ккм
так что это все копейки..

ну, теперь догадался какое, которое не только в группировке, но и по элементам интереснее всего остального?
20 июн 18, 14:48    [21506869]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
Voyager_lan
Member

Откуда:
Сообщений: 1451
ShIgor,
Классика. Сквозные бизнес-процессы никто не отменял :)
20 июн 18, 15:45    [21507158]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: одно измерение для нескольких баз возможно-ли?  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 1837
ShIgor,

в итоге, решение только одно: сливать базы в одну
29 июн 18, 15:42    [21531569]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить