Насчёт минимальных средств Excel-я, Вы по-моему погорячились. За создание кубов отвечает SQL Server. Excel же здесь выступает в виде viewer-a.
Но это не умаляет ценности примера. =)
Хотел бы дополнить вот что:
— агрегация 30% (особенно если построена встроенным визардом) может быть не самое лучшее решение. Уменьшив количество агрегаций, но сделав целенаправленный, продуманный дизайн может в разы увеличить производительность и уменьшить необходимое дисковое пространство.
— собственно, абсолютно согласен с автором, что OLAP решения могут вполне подходить небольшим компаниям. Например, можно использовать Analysis Services, которые включены в MS SQL Server Standard Edition, или использовать open source-ый Mondrian.
— можно также рассмотреть возможность использования Data Mining и сделать анализ данных еще «более умным!»
— было бы интересно узнать как у вас организованы ETL процессы, используете ли вы MS SQL Server Integration Services (ваша иконка для ETL вроде бы именно оттуда)?
>>агрегация 30% (особенно если построена встроенным визардом) может быть не самое лучшее
>>решение. Уменьшив количество агрегаций, но сделав целенаправленный, продуманный дизайн
>>может в разы увеличить производительность и уменьшить необходимое дисковое пространство.
Согласна. Но именно в этом проекте объем кубов минимален и нет проблем с производительность. До тех пор, конечно, пока кому-нибудь не захочется построить отчет на 200 страниц: в столбцах все клиенты, а в строках все товары.
>>можно также рассмотреть возможность использования Data Mining
>>и сделать анализ данных еще «более умным!»
с Data Mining сложные взаимоотношения. Конечно технология интересная, но, мне кажется, в данной организации использование стандартных алгоритмов не принесет какой либо пользы. Хотя возможно это иллюзия. Было бы замечательно, если бы кто-нибудь написал о своем примере использования Data Mining в таких небольших компаниях.
>>было бы интересно узнать как у вас организованы ETL процессы,
>> используете ли вы MS SQL Server Integration Services
>>(ваша иконка для ETL вроде бы именно оттуда)?
Да, иконка оттуда :)
Но в этом проекте очень простые etl-алгоритмы, поэтому всё реализовано на процедурах t-sql.
SSIS используется только для обновления измерений и создания / пересчета партиций: “cобираются” и выполняются нужные xmla скрипты.
А почему размер многомерной базы такой небольшой?
Я всегда считал что в олапе быстрота агрегирования достигается за счет хранения ненормированных данных, что влечет за собой избыточность и как следствие бльшой размер базы?
Таблицу фактов делают как можно более «узкой», избыточность обычно допускается в таблицах измерений, которые дай бог процентов 5 от общего объема достигают да и то в исключительных случаях.
Автор, лучше поделитесь секретом, как убедили руководство маленькой компании, что оно им надо. :) А то обычно руководство считает, что проще и дешевле нанять пару симпатичных девочек с экселем, чем настаивать бездушную железяку и держать потом толпу программистов, чтоб что-то поддерживать. :)
Я имел ввиду именно Olap разработчика для разработки на готовом хранилище данных. ETL — это другая сфера, хранилище данных как правило используется не только для OLAP, но и для генерации отчетов например, или с прямым анализом данных через SQL.
Руководство – бывшие технари. Контора в этом смысле вообще уникальная. Например, в ней в одной из первых в регионе внедрили «мобильную торговлю” – прием заказов от торговых представителей через КПК
Проект действительно может вести один человек. Человек, начинавший проект, был чуть ли не единственным it-шником в компании (в одном лице и 1с-ник и админ ). Я пришла на его место через год примерно.
По большому счету, за пару дней можно сделать куб, так чтобы пользователь мог попробовать работать. А потом, если понравится, «наращивать мясо”
Я работал с кубами объемом в десятки гигабайт и столкнулся с проблемой их медленной работы, т.к. все наши кубы содержат как правило не меньше 16 измерений и активно используются distinct count. Пришлось для этого применять партицирование. В итоге скорость работы возросла в десятки раз, вместо 10 минут ожидания, пользователи делали запросы за 10-30 секунд. Хотел статью про это написать, да все времени нет.
А как вы справляетесь с вопросами производительности?
PS: Очень интересно также, применять OLAP кубы в веб-аналитике. Система Sitecatalyst похоже так и работает.
в этом проекте вопрос производительности возникал только при формировании больших плоских отчетов предопределенной формы
такие отчеты сейчас либо переведенные в SSRS и формируются по подпискам, либо заменены локальными кубами
были проблемы, когда остатки были вычисляемой мерой, когда перевела расчет в хранилище — стало гораздо быстрее
партиции были изначально. Дело в том что хранилища не было, запросы строились на view. А данные в базе 1с лежали по разным базам ( так называемым «обрезкам»). Так что использование партиций было естественным решением
я имел ввиду горизонтальное партицирование. Например, по id заказа. Чтобы работала быстрее мера distinct count кол-ва заказов, мне пришлось сделать 16 партиций по диапазону id заказа.
В итоге в кубе получилось порядка 50 партиций, т.к. еще были меры distinct count.
Простое агрегирование по мере ditinct count не работает :-(
Ага, типичное мнение. На самом деле плюсы есть, но не очевидны. Управленческая отчётность с данными актуальными «на вчера» позволяет руководству эффективнее руководить. А единственный сервер 1с насиловать — не рационально. :)
от 2,6 Гб ( чистая база, после «обрезки» ) до 6 Гб в конце периода ( перед «обрезкой» )
«обрезку» делают два раза в год примерно
Я как раз и хотела показать, что на таких небольших объемах очень удобно использовать olap
Задача была снизить нагрузку на учетную систему и дать возможность пользователям самим выбирать информацию
Конечно, можно сделать просто хранилище, и строить отчеты в SSRS на нём.
А в том же екселе работать со сводными таблицами выбирая данные select'ами из хранилища
Но следующий, достаточно естественный шаг — построить olap куб. При этом получаем гораздо большую производительность.
Дополнительного софта для этого не нужно: Analysis Services входит MS SQL Server Standard Edition
Проще было бы перенести базу на SQL и потом написать пару необходимых отчётов на прямых запросах, получилось бы просто, быстро и данные всегда оперативные.
Дело в том что отчетов далеко не «пара», сейчас только опубликованных 77 :)
Конечно городить такую систему ради даже 77 отчетов не имеет смысла
Но дело в том что данные нужны в разных разрезах — это даже не отчеты как таковые. Можно сказать интерактивный анализ данных.
Маркетологи за день могут строить десятки разных «отчетов» по-разному выбирая данные.
Отчеты не только по данным продаж
В кубах сейчас данные по остаткам, дебеторка, планирование, просрочка и т.п
И при чем тут «искусственный интеллект»? Интеллект как раз естественный. :)
Основные пользователи — маркетологи и менеджеры. Живые люди, которым для работы нужно «понимать что происходит». А для этого получать данные в разных срезах.
Попробуйте покрутить локальный куб в екселе, может быть тогда станет понятно зачем всё это затевалось :)
А «искусственный интеллект» — это скорее Data Mining
> В кубах сейчас данные по остаткам, дебеторка, планирование, просрочка и т.п
И как менеджер увидит в кубе, который построен вчера, что недавно была закрыта просрочка по платежам? :0)
> Основные пользователи — маркетологи и менеджеры. Живые люди, которым для работы нужно «понимать что происходит». А для этого получать данные в разных срезах.
Если у вас 1с просто для красоты и маркетологов и вы с помощью 1с не управляете процессами, то да, главное чтобы данные в разных разрезах. :0)
>> И как менеджер увидит в кубе, который построен вчера,
>> что недавно была закрыта просрочка по платежам? :0)
1. Кстати куб по просрочке считается чаще, раз в час. :)
Кроме того «специальные люди» могут нажав одну кнопку — пересчитать куб ( но вообще то это атавизм, сейчас есть более гибкие механизмы обновления данных )
2. В кубе менеджер скорее получить ответы на вопросы: как менялась просрочка этого клиента? Насколько оперативно клиент в прошлом гасил задолженность? Сколько дней в среднем была просрочка в прошлом?
>> вы с помощью 1с не управляете процессами
Приведите пожалуйста примеры управления процессами с помощью 1с
1С у нас — учетная система, которую долгое время было совершенно не удобно использовать для анализа собранных данных ( хотя в 8-ке, насколько я знаю, появились какие-то механизмы похожие на олап решение )
> 1. Кстати куб по просрочке считается чаще, раз в час. :)
Задержка обратной связи в час — это просто самоубийство.
> 2. В кубе менеджер скорее получить ответы на вопросы: как менялась просрочка этого клиента? Насколько оперативно клиент в прошлом гасил задолженность? Сколько дней в среднем была просрочка в прошлом?
Прежде всего менеджеру нужно видеть в реальном времени сколько текущая просрочка. Потом, возможно он и захочет проанализировать просрочки за последние два года, но и то это будет скорее простое любопытство, в реальных взаиморасчётах прогнозами на олап кубах как бы не занимаются. :0)
Ты передёргиваешь, я то как раз не против олапов и анализов, просто например пересчитывать олап каждый час и пытаться использовать олап как инструмент оперативного учёта — верх некомпетентности. :0)
Вот это как раз мне кажется мифом, который хотелось бы развеять: олап позволяет дать пользователю удобный и быстрый инструмент для интерактивного анализа информации за большие периоды времени. Ключевые слова: быстро, интерактивно.
А точность до секунд, при анализе информации за несколько лет, совершенно не важна.
> Вот это как раз мне кажется мифом, который хотелось бы развеять: олап позволяет дать пользователю удобный и быстрый инструмент для интерактивного анализа информации за большие периоды времени. Ключевые слова: быстро, интерактивно.
Да я и не спорю что олап может дать хорошие возможности для анализа прошлого. Однако реальность такова, что реальный учёт просто не возможен на только олапе. В реальности нужно чтобы вот человек изменил данные, и тут же нажал кнопку и в течении трёх секунд отчёт показал обновлённые данные.
> А точность до секунд, при анализе информации за несколько лет, совершенно не важна.
Для «пары» отчетов действительно нужно, чтобы «человек изменил данные, и тут же нажал кнопку и в течении трёх секунд отчёт показал обновлённые данные».
Такие отчеты можно замечательно сделать на 1С.
Но, уж поверьте :) есть и другие задачи.
Посмотрите ролик — сколько бы отчетов вам пришлось сделать в 1С для того чтобы дать пользователю информацию в таком же виде?
Правда очень интересное занятие «ваять» такие отчеты? Может быть всё таки проще дать пользователю возможность самому получать информацию?
Мы говорим про учёт и анализ. Все обсуждаемые «задачи» лежат в этих рамках.
> Для «пары» отчетов действительно нужно, чтобы «человек изменил данные, и тут же нажал кнопку и в течении трёх секунд отчёт показал обновлённые данные».
>
Но, уж поверьте :) есть и другие задачи.
>
> Посмотрите ролик — сколько бы отчетов вам пришлось сделать в 1С для того чтобы дать пользователю информацию в таком же виде?
Посмотрел я ролик. Всё что я увидел в ролике можно получить из типовой «Торговли и склад» без программирования. Что тут сказать ты не только не знаешь 1с, но и почему-то считаешь что твоя поделка заменяет 20 отчётов 1с. :0)
> Правда очень интересное занятие «ваять» такие отчеты? Может быть всё таки проще дать пользователю возможность самому получать информацию?
Кто мешает пользователю самому получать информацию из 1с? :0)
>> Всё что я увидел в ролике можно получить >> из типовой «Торговли и склад» без
>> программирования.
В 1с 7.7 без программирования, агрегированные данные за несколько лет, в разных разрезах, за пару секунд – мне кажется Вы либо лукавите, либо мы живем в параллельных вселенных ;D
Возможно, Вы не обратили внимание, но у нас есть sql версия 1C. На схеме это не отраженно, но в эту базу имеют доступ руководители отделов и маркетологи (как раз для оперативной отчетности).
Но почему то они предпочитают пользоваться «поделкой». Дикие люди ;)
Конечно, если учетная система позволяет получить информацию, которая нужна пользователям совершенно бессмысленно делать какую-то надстройку. Но если, всё таки, есть люди заинтересованные в более гибком способе работы с информацией — такое решение наиболее естественно.
ЗЫ: Каждый уверен, что именно он источник огня. И это тема для новой войны ;)
> В 1с 7.7 без программирования, агрегированные данные за несколько лет, в разных разрезах, за пару секунд – мне кажется Вы либо лукавите, либо мы живем в параллельных вселенных ;D
Ничо я не лукавлю, на ваших объёмах — легко. :0)
> Возможно, Вы не обратили внимание, но у нас есть sql версия 1C. На схеме это не отраженно, но в эту базу имеют доступ руководители отделов и маркетологи (как раз для оперативной отчетности).
> Но почему то они предпочитают пользоваться «поделкой». Дикие люди ;)
Тут дело не в руководстве, а в тебе, ты не понимаешь как пользоваться 1с.
> Конечно, если учетная система позволяет получить информацию, которая нужна пользователям совершенно бессмысленно делать какую-то надстройку. Но если, всё таки, есть люди заинтересованные в более гибком способе работы с информацией — такое решение наиболее естественно.
Учётная система то позволяет, твоя квалификация не позволяет. :0)
Для анализа показателей за несколько лет совершенно не важно, что данные не оперативные.
«Картина мира» не изменится от того что произошло ещё несколько отгрузок
При просмотре ролика, у меня теряется связь между «что нужно сделать» и «что получим». Как вы объясняли пользователям, что и куда нужно щелкнуть, что-бы получить то-то??
Как ни странно, но достаточно было один раз показать как «таскать поля мышкой».
Возможно потому, что пользователи знают предметную область.
т.е. пользователь хочет что то получить, а что для этого нужно сделать как правило интуитивно понятно.
Например если человек хочет посмотреть продажи конкретного товара за определенный период в конкретном городе, интуитивно понятно что нужно вытащить города и товар фильтры,
дату — в столбцы, сумму — в показатели.
такая же связка работает и в компаниях федерального уровня :)
сделанная ещё в 2000 году с первыми версиями AS и Excel 2000
данные забираются из 1С, RS баланса, RS фин. Кубы перерассчитываются за последний день-два каждую ночь. И иногда по запросу за пол года, если произошла операция задним числом.
Для удобства пользователей в Excel добавлен плагин, который позволяет загрузить уже готовые отчёты в виде темплейтов документа и показывает только «разрешённые» кубы и позволяет хранить отчёты централизованно и позволяет дорабатывать их. И ещё пара вкусностей, напомню в Excel 2000 работы с кубами была не очень удобной.
Радует, что не мы одни думаем в сторону дешёвых и эффективных решений.
olap для маленькой компании