OLAP и 1С: У 1С прежде всего похожий по задачам инструмент - компоновщик. (C) Demiurg

[mazzy]

Если до вечера понедельника (20 апреля 2009) от Demiurg'а не будет материала на тему "Попробую доказать, что OLAP в привычном понимании не 1С программистов не нужен", то он будет забанен за спам. Оффтопик в этой ветке будет удаляться.
Обсуждение Хочу пояснить что происходит с Demiurg'ом.

Здесь просьба вернуться к теме
OLAP и 1С: У 1С прежде всего похожий по задачам инструмент - компоновщик. (C) Demiurg

to all
ввиду невозможности продолжать тему по независящим от меня причинам здесь, предлагаю следить за моим блогом http://gilev.blogspot.com/ на следующей неделе, где можно будет также оставить свои комментарии,
первоначальная мысль по OLAPу превратилось в более объемную, но интересную тему, что-то будет полюбому ))
Спасибо всем кто принял участие в обсуждении!

[miklenew]

Никогда не работал с Olap.
Но почему то считал, что Olap-у главное БД.
Причём здесь способ работы с данными 1С или Axapta?
Или я не правильно понимаю что такое Olap.

[Raven Melancholic]

Цитата:

саперы, адепты аксапты или другой конкурирующей проги

SAP/R3 или DAX или 1С прога? Интересная интерпретация, никогда не думал о такой формулировке что эти системы Проги, считал что это инструменты решения проблем разных фирм. Нужно будет погуглить что есть прога.
Ну, отвлеклись, вернемся к теме.
Берем среднестатистическую фирму, представителя модного словосочетание "средний бизнес".
В день 1500 "отгрузок" в низкий сезон, в "высокий" сезон 2500-3000 отгрузок. Руководству и аналиткам требуется ежедневно (в течение 15 минут от начала рабочего дня) иметь информацию:
сумма отгрузок за предыдущий день, сумма отгрузок с начала месяца, сумма отгрузок за сравнимый период прошлого года (нужны суммы, количество отгрузок, средняя сумма отгрузки, минимальная и максимальны суммы отгрузок) в разрезе:
а). Филиал.
б.) Регион.
с.) Менеджер.
д.) Категория номенклатуры.
е.) Номенклатура.
При этом кроме суммы нужно знать маржу с учетом косвенных расходов и без учета косвенных расходов. Аналитик должен иметь возможность группировать вышеперечисленные данные не только в указанном порядке, но и в других иерархиях (например, сначала руководитель подразделения, затем менеджер, затем категория номенклатуры ), может быть, то порядок будет несколько другой.
На самом деле количество требований ограничено, то есть, порядок достаточно строго определен. Но это только требования к одному отчету.
Интересно знать, можно ли в таких условиях заменить ОЛАП компоновкой данных от 1С? Напомню: за 15 минут от начала рабочего времени нужно дать руководству аналитику по нескольким интересующим разрезам бизнеса.

[brahma]

Можно.

Цитата:

Сообщение от Raven Melancholic

Интересно знать, можно ли в таких условиях заменить ОЛАП компоновкой данных от 1С?

Уже заменено.

[kuntashov]

Видимо, сложно ожидать в этом обсуждении какого-то конструктива

По определению (см. ссылки в постах выше) OLAP решает задачу выборки и представления многомерных данных с учетом:

• большого объема первичных данных (за большой период или очень большое количество операций)
• большого количества измерений/аналитик
• как следствие - многовариантности запросов пользователя
• требования "не мешать" оперативной работе системе (системам), предоставляющим первичные данные или формированию других выборок
• необходимости визуализации многомерных данных

При этом, в рамках технологии OLAP, озвученный комплекс решаемых проблем разбивается на три группы

1. задачи, связанные с обеспечением скорости выборки
2. задачи, связанные с формированием запроса к данным
3. задачи, связанные с обработкой выборки и представлением данных

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

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

В свете всего вышесказанного (я, кажется, не сильно, наврал), по-моему, должно быть очевидно, что Система Компоновки Данных в 8ке - это инструмент решения задач из второй и третьей групп. Т.е. инструмент для формирования и выполнения запроса к данным, обработки полученной выборки и вывода данных в том виде, в котором пользователь запросил.

Соответственно, вопрос "Интересно знать, можно ли в таких условиях заменить ОЛАП компоновкой данных от 1С?" некорректен, как и ответ "уже замено", потому что СКД сама по себе - не OLAP, это только часть этой технологии.

На решение задач первой группы в контексте 1С:Предприятия можно смотреть двояко. С одной стороны - регистры накопления 1С:Предприятия призваны решать задачи быстрого получения выборки за счет денормализации данных (предрасчитанные итоги по измерениям). С другой стороны они (регистры) многочисленны и специализированы, что порождает проблемы, снова приводящие к снижению скорости выборки.

Таким образом, для себя я делаю следующий вывод: платформа 1С:Предприятие 8 содержит средства построения универсальной OLAP-подобной системы.

Известные же мне типовые решения на базе 8-ки содержат только элементы технологии OLAP, решаюшие частные задачи тех предметных областей, для которых они предназначены. Например, смею утверждать, что конкретные задачи, подобные озвученной в сообщении Raven Melancholic выше, могут быть решены.

Кстати, на днях, на партнерском форуме проскакивала информация, что в 1С:Рарусе делают OLAP-подобную систему на 8ке (универсальную или нет - не знаю), умеющую выполнять предрасчет многомерных данных, чтобы потом их можно было быстро и в нужных разрезах извлекать.

Demiurg, Вы это как-то можете прокомментировать это, если Вам что-то известно и это никак не нарушает NDA?

[mazzy]

Цитата:

Сообщение от kuntashov

При этом, в рамках технологии OLAP, озвученный комплекс решаемых проблем разбивается на три группы

1. задачи, связанные с обеспечением скорости выборки
2. задачи, связанные с формированием запроса к данным
3. задачи, связанные с обработкой выборки и представлением данных

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

Я не знаю куда отнести еще один аспект.
В стандартном ОЛАПе программист может построить несколько разных кубов по одному набору таблиц с фактами. Т.е. OLTP заполняет одну таблицу фактов, а OLAP забирает эти факты в несколько разных кубов.

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

В результате получается, что стандартный ОЛАП дает возможность строить различные варианты анализа после заполнения данных, а вот механизм компоновки должен выкручиваться из структуры уже заданного регистра.

[kuntashov]

Цитата:

Сообщение от mazzy

В результате получается, что стандартный ОЛАП дает возможность строить различные варианты анализа после заполнения данных, а вот механизм компоновки должен выкручиваться из структуры уже заданного регистра.

Полностью согласен, именно это я и имел в виду, говоря, что в типовых решениях 1С регистры "многочисленны и специализированы" со всеми вытекающими последствиями.

Это так потому что в типовых регистры решают задачи получения специализированной оперативной отчетности (отчеты по остаткам и оборотам в общем случае в тех разрезах, которые требует рассматриваемая область учета), а не тех отчетов, о которых идет речь в контексте обсуждения OLAP-систем. Поэтому сравнивать их с универсальным "кубом" неправильно.

И об этом же моя фраза "типовые решения на базе 8-ки содержат только элементы технологии OLAP".

Вы во многих дискуссиях на тему 1С на этом форуме активно и очень правильно, на мой взгляд, наставляете коллег (в том числе профессионально занимающихся 1С) на путь истинный, требуя различать 1С:Предприятие как платформу и типовые решения на базе этой платформы.

Так вот я, придерживаясь такого же мнения, утверждаю, что платформа 1С:Предприятие 8 содержит необходимые средства построения универсальной OLAP-системы, но пока на рынке не существует такого универсального решения на этой платформе.

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

На практике это утверждение вроде никто не опровергал и не доказывал (пока). Как разработчик на платформе 1С я знаю, что гипотетически на регистрах можно сделать инструмент для построения "универсального" куба (т.е. с настройкой условно-произвольного количества измерений задаваемого пользователем типа). Но мне сложно умозрительно оценить эффективность такого решения на очень больших объемах данных, и это делать я пока не берусь.

Цитата:

Сообщение от kuntashov

Полностью согласен, именно это я и имел в виду, говоря, что в типовых решениях 1С регистры "многочисленны и специализированы" со всеми вытекающими последствиями.

Это так потому что в типовых регистры решают задачи получения специализированной оперативной отчетности (отчеты по остаткам и оборотам в общем случае в тех разрезах, которые требует рассматриваемая область учета), а не тех отчетов, о которых идет речь в контексте обсуждения OLAP-систем. Поэтому сравнивать их с универсальным "кубом" неправильно.

И об этом же моя фраза "типовые решения на базе 8-ки содержат только элементы технологии OLAP".

Вы во многих дискуссиях на тему 1С на этом форуме активно и очень правильно, на мой взгляд, наставляете коллег (в том числе профессионально занимающихся 1С) на путь истинный, требуя различать 1С:Предприятие как платформу и типовые решения на базе этой платформы.

Так вот я, придерживаясь такого же мнения, утверждаю, что платформа 1С:Предприятие 8 содержит необходимые средства построения универсальной OLAP-системы, но пока на рынке не существует такого универсального решения на этой платформе.

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

На практике это утверждение вроде никто не опровергал и не доказывал (пока). Как разработчик на платформе 1С я знаю, что гипотетически на регистрах можно сделать инструмент для построения "универсального" куба (т.е. с настройкой условно-произвольного количества измерений задаваемого пользователем типа). Но мне сложно умозрительно оценить эффективность такого решения на очень больших объемах данных, и это делать я пока не берусь.

1) Мой ответ "уже применяется" дан про конкретно сформулированную задачу:
В день 1500 "отгрузок" в низкий сезон, в "высокий" сезон 2500-3000 отгрузок. Руководству и аналиткам требуется ежедневно (в течение 15 минут от начала рабочего дня) иметь информацию:
сумма отгрузок за предыдущий день, сумма отгрузок с начала месяца, сумма отгрузок за сравнимый период прошлого года (нужны суммы, количество отгрузок, средняя сумма отгрузки, минимальная и максимальны суммы отгрузок) в разрезе:
а). Филиал.
б.) Регион.
с.) Менеджер.
д.) Категория номенклатуры.
е.) Номенклатура.
У нас клиенты в рознице решают и более тяжелые задачи. 8-10k документов в день. Естественно, что конфигурации не типовые, учитывающие специфику.

2) Поскольку в данном вопросе про Рарус не могу быть частным лицом (представляю компанию), дать ответ не уполномочен.

3) Вы практически на 50% предвосхитили мои заметки, поэтому добавлю, что говоря об OLAP, надо еще помнить о применимости механизма в рамках транзакций, а еще точнее при многопользовательской работе. Понятно, что OLAP не реалтаймовый и если говорить терминами 1С, в обороботку проведения документа в чистом "забугорном" варианте занести его будет самоубиственно. Вместо получения выигрыша получем непредсказуемый результат. А если нужно просто строить отчеты, то господам из других систем может и не известно, но вообще-то практикуются заказные конфигурации, куда попадает только управленческая информация для принятия решений, что позволяет достигать любой требуемой производительности.
Уверен, что и 1С:Консолидация в будущих релизах полноценно вырастет до этих задач. Основные принципы в ней уже есть сейчас.

[mazzy]

Цитата:

Сообщение от kuntashov

Так вот я, придерживаясь такого же мнения, утверждаю, что платформа 1С:Предприятие 8 содержит необходимые средства построения универсальной OLAP-системы, но пока на рынке не существует такого универсального решения на этой платформе.

Хорошо. Предположим, что так.
Как по вашему мнению, что разработчики 1С предполагали дать своим клиентам/партнерам, что взялись за огромный труд по созданию "необходимые средства построения универсальной OLAP-системы"

Ведь OLAP-систему так и не построили, а сил затратили очень много. В то время как универсальные OLAP-системы на рынке давно уже существуют.
Зачем?

На ваш взгляд, если бы разработчики 1С дали возможность использовать стандартные OLAP'ы, то решение 1C стало бы более привлекательным для клиентов 1С или нет? И почему?

Цитата:

Сообщение от Demiurg

У нас клиенты в рознице решают и более тяжелые задачи. 8-10k документов в день. Естественно, что конфигурации не типовые, учитывающие специфику.

Совершенно неестественно.
Неужто типовая конфигурация не тянет каких то 8-10К документов в день?

Цитата:

Сообщение от Demiurg

Уверен, что и 1С:Консолидация в будущих релизах полноценно вырастет до этих задач. Основные принципы в ней уже есть сейчас.

Блин, опять завтраки? Опять увод от темы?
Не надо рассказывать ЗДЕСЬ о том, что БУДЕТ НЕИЗВЕСТНО КОГДА в консолидации.
Желающие прочитают на специализированных 1Совских ресурсах.
А также, про консолидацию СЕЙЧАС
http://forums.kuban.ru/forum/viewtopic_new.php?t=68984
http://forums.kuban.ru/forum/viewtopic_new.php?t=169427
http://www.forum.mista.ru/topic.php?id=311204

Напомню ваше обещание:

Цитата:

Сообщение от Demiurg

К чему это я. Попробую доказать, что OLAP в привычном понимании не 1С программистов не нужен

Ждем до вечера понеделька 20 апреля 2009.

[Raven Melancholic]

Цитата:

Можно. Уже заменено.

В моем сообщении не зря были заданы жесткие временные ограничения и требования к быстрому изменению требуемых разрезов. То есть, изменение требований к разрезам должно четко укладываться в эти 15 минут -это время на настройку параметров, формирование отчета и его проверку.
Все-таки:

Цитата:

OLAP в привычном понимании не 1С программистов не нужен

Так нужен или нет ОЛАП? Или в связи с появлением компоновки данных от 1С можно выбрасывать годами наработанные технологии?
Где доказательства? Так и я могу заявить:
Компоновка данных от 1С не нужна, так как сводные таблицы Excel полностью её заменяют. Но доказательствами утруждать себя не собираюсь.
Какие типовые используют данный механизм?

[kuntashov]

Во-первых, я не говорил, что разработчики 1С специально делали средства для построения универсальной OLAP-системы. Я не в курсе их замыслов. Я говорил, что средств, предоставленных ими в рамках платформы 1С:Предприятие 8, достаточно для построения универсальной OLAP-системы. Это моя экспертная оценка как разработчика.

Соответственно на вопрос "зачем?" ответ простой - средствами, про которые я говорю, решаются другие задачи, а именно задачи получения оперативной отчетности различного рода. OLAP-системой или механизмами для построения OLAP-систем это никто не называет. Но технологически подходы используются те же.

Цитата:

Сообщение от mazzy

На ваш взгляд, если бы разработчики 1С дали возможность использовать стандартные OLAP'ы, то решение 1C стало бы более привлекательным для клиентов 1С или нет? И почему?

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

Но ни один из моих текущих клиентов не выдвигал требования внедрить ему именно "OLAP-систему". Они просили решать конкретные задачи, вроде озвученной выше. И для решения этих задач вполне успешно использовались имеющиеся средства платформы 1С:Предприятие 8.

(Чтобы не завышать ожиданий, оговорюсь, что не имею опыта "больших" внедрений. На текущий момент все мои клиенты, это предприятия с численностью до 500 человек, основная масса - от 20 до 100 человек персонала; максимальное количество автоматизированных мест - 60).

[Raven Melancholic]

Цитата:

Сообщение от kuntashov

средствами, про которые я говорю, решаются другие задачи

Спасибо за информацию. Никто и не говорит, что система компоновки данных это ненужное и плохое решение. Я его видел - действительно есть что посмотреть и достаточно интересный подход.
Но мы пытаемся получить доказательство утверждения:

Цитата:

OLAP в привычном понимании не 1С программистов не нужен

PS: кстати, а что в понимании 1С программистов OLAP это что-то отличающееся от понимание не 1С программистов?

[kuntashov]

Цитата:

Сообщение от Raven Melancholic

PS: кстати, а что в понимании 1С программистов OLAP это что-то отличающееся от понимание не 1С программистов?

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

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

Цитата:

Сообщение от mazzy

Неужто типовая конфигурация не тянет каких то 8-10К документов в день?

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

Цитата:

Сообщение от mazzy

Ждем до вечера понеделька 20 апреля 2009.

А вы чего ребята ждете, в этой ветке уже написано. Или чего-то не понятно?!
Кино то уже кончилось

[mazzy]

Цитата:

Сообщение от mazzy

Если до вечера понедельника (20 апреля 2009) от Demiurg'а не будет материала на тему "Попробую доказать, что OLAP в привычном понимании не 1С программистов не нужен", то он будет забанен за спам.

Demiurg забанен за спам.

не думаю, что будет спамом выложить ссылку на обещанный материал http://gilev.blogspot.com/2009/04/olap-vs-1c.html

всех с праздниками

[Aleck]

Вода какая-то...
Попробуйте сделать в 1C аналог классического для Olap кубика анализа продаж при паре-тройке миллионов строчек... и потом попробуйте добиться приемлемой скорости реакции Вашего отчета (до 5 секунд) на игры с измерениями. Может тогда хоть поймете для чего olap нужен.

Цитата:

Сообщение от Aleck

Вода какая-то...
Попробуйте сделать в 1C аналог классического для Olap кубика анализа продаж при паре-тройке миллионов строчек... и потом попробуйте добиться приемлемой скорости реакции Вашего отчета (до 5 секунд) на игры с измерениями. Может тогда хоть поймете для чего olap нужен.

Заметьте, прежде чем запостить сюда, я дал этот материал прочитать архитекторам систем 1С, которые уже РЕАЛЬНО реализовали крупные проекты, и прежде всего реализовали подобные принципы.
Мне не хочется доказывать, что Вы возможно написали, глубоко не вникая в проблемы (вообщем то и не обязаны). К тому же материал действительно написан так, чтобы поняли только 1С-ки.
Я не настаиваю на абсолютной истине, просто изложил собственное видение этого вопроса в данный момент.
Возможно это видение в будущем измениться, возможно нет.
Приемлемых 5 секунд достигал, иначе бы и не писал этот пост. Если у Вас есть факты, изложите их пожалуйста, это будет интересно.