Bankir.Ru
21 января, суббота 16:12

Объявление

Свернуть

Конференция «Банки и МСБ. Перезагрузка отношений»

Показать больше
Показать меньше

OLAP для трудовго народа

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • OLAP для трудовго народа

    Весь крещеный мир аналитические отчеты делает в OLAP. А наши банки этим не пользуются. Вот мы в компании Intersoft Lab сделали очень простую и дешевую, но довольно мощную DeskTop OLAP - систему Контур Стандарт. В основном старались для банков. Каждый день приходит больше ста человек почитать, за месяц несколько сотен скачали (12 МБ с банковским примером между прочим). Но никто не критикует. Предлагаю обсудить эту тему вообще и покритиковать нашу программу в частности.
    Предлагаю опровергнуть такие заявления:
    1. 90% нерегламентированных отчетов легче всего сделать в OLAP, кодирование отчетов произвольной формы - анахронизм.
    2. Настольный OLAP подходит для решения 90% аналитических задач в среднем российском банке.

  • #2
    Сколько стоит эта "радость"? Где ссылки?

    Комментарий


    • #3
      Замечательно интересную тему поднимаете, камарад Nekrasov!
      Знакомились с Вашей системой, а также с Вами лично на разных выставках и форумах. Ну что можно такое для затравки сказать? Попробую...
      Необходимость внедрения OLAP-систем в наших банках не может проистекать из предположения о крещенности мира и об использовании им подобных систем. Проблема внедрения OLAP-систем восходит к общей проблеме автоматизации процессов в банке. Что автоматизировать? Как автоматизировать? Сколько это стоит? Какую выгоду и прибыль принесет автоматизация? Говоря о построении аналитической отчетности с помощью OLAP необходимо посмотреть, в каких бизнес-процессах она используется.
      А вот их-то в банке в формализованном виде может и не оказаться. И как следствие - информационные системы используется только на отдельных участочках, для обработки отдельных операций (включая построение аналитики). Называется этот подход, по-моему, простым словом - механизацией работ. Оно, конечно, неплохо и имеет право на существование и в целом облегчает существование персонала банка, но мы же желаем полномасштабной информатизации процессов в банке. А ее мы достигнем, ежели сможем достаточно глубоко формализовать жизнь банка и отразить ее в информационной системе.
      А что же конкретно про OLAP-системы? Считаю, что преимущество при использовании OLAP-систем может быть достигнуто, если в ней будет максимально отражено формализованное представление банка - как внутренние потоки информации, так и даные о внешних факторах.
      А это очень большие объемы информации, которые предъявляют очень высокие требования как к аппаратной платформе, так и к программному обеспечению. Кстати, чуть не забыл - и к пользователям.
      Естественно, учитывая вышесказанное, проблема внедрения аналитических систем в банке должна решаться не на уровне подразделения автоматизации. Это - задача для всего банка на несколько лет. Задача, которая должна быть в приоритете в первую очередь у высшего менеджмента банка.
      Поэтому-то, когда говорится об информационных системах в банке, я очень боюсь слов "...очень простую, дешевую, но довольно мощную DesлTop...".
      При автоматизации отдельных участков - той же самой аналитической отчетности - очень часто подобные DeskTop решения проигрываю анахроничным способам построения отчетности, т.к. последние зачастую бывают достаточно гибкими при своей специализации.
      Построение отчетности - это только одна из задач, решаемая OLAP, причем не самая приоритетная. Есть другие - пересылаю к интересному опыту сотрудников "Пробизнесбанка" по созданию и эксплуатации OLAP системы на платформе Sybase IQ.
      Вот почему хотелось бы обратить Ваше внимание на проблемы и их решения, которые могут появиться при внедрении OLAP-системы, а также при ее эксплуатации.


      Комментарий


      • #4
        to Pearhead:
        1. Программа есть в 2-х редакциях: Developer для создания приложений - настройки на БД, настройки выборок и отчетов стоит 360$, Run - Time для выполнения приложений раздается даром. Приложение - это файл. Его можно копировать, продавать. Т.е. если банк купит 1 шт. Developer, то он может поставить OLAP на сколько угодно рабочих мест.
        2. Скачать можно на www.iso.ru

        Комментарий


        • #5
          to Aha: Готов подписаться почти под всем Вашим сообщением. Особенно под той его частью, где сказано о сложности задачи построения глобальной аналитической системы в банке. Но это совсем другая тема! Это тема не столько OLAP, сколько Хранилища данных. Мы сами в основном этим и занимаемся. Но Хранилища данных создают только те банки, которые действительно поняли, что информация - это их актив, который стоит очень больших денег. А для того, чтобы этот актив заработал и стал приносить прибыль нужны какие-то усилия, да и инвестиции. Т.е. я хочу сказать, что то, о чем Вы говорите, это, наверное, не программа, а проект.
          А DeskTop OLAP - это только инструмент для визуализации имеющихся данных, а не для их сбора, очистки, хранения. Хотя и такие задачи, только не очень большие он может рещшать. Но главное, он может заменить рутинные отчеты, в том числе одноразовые, которые тоннами пишутся вокруг одних и тех же блоков данных, только под разными углами: счетов, клиентов, договоров и пр. Стоит на порядки дешевле чем создание полномасштабного Хранилища, поэтому доступен каждому банку. Но на мой взгляд программисты просто не знают о своем счастье. Мне понравилась рекламная фраза одного производителя про свой DOLAP: "Делает из программиста супергероя". А еще однажды я видел, как программист подброисл в воздух бумажки и возопил: "Кем я работаю? Генератором отчетов!"
          Что касается отчетов, то их можно и не печатать. OLAP - это не генератор отчетов. Это просто для большей понятности, речь конечно идет об анализе, просто интерфейс OLAP - это тоже отчет такой, кроме того в него встроена печать.

          Комментарий


          • #6
            -- Nekrasov,

            Помогите разобраться плз!
            Какую стадию аналитического цикла реализует Ваш OLAP?

            - Извлечение данных из АБС (выгрузка батчами либо
            событийный "realtime" интерфейс на сообщениях);
            - Бизнес-логика проецирования извлеченной первичной
            информации на аналитические агрегаты;
            - Инструмент быстрого апдейта-хранения-доступа
            к агрегатам (hypercubes и прочая);
            - Отчетный уровень аналитики - бизнес-логика
            построения гибких конечных репортов на агрегатах.

            Какие стадии накрывает Контур?

            Thks,
            Psrg
            Скрин Маркет Системз ЗАО www.transaq.ru
            --------------------------------------
            -- интернет-трейдинговые-дилинговые системы --
            -- динамическое управление рисками производных --
            sergp@futures.msk.ru

            Комментарий


            • #7
              to PSrg
              1. Контур Стандарт получает данные из реляционной БД или локальной таблицы. Для этого в программу встроен генератор запросов - инструмент описания таблиц, полей, связей и условий фильтра. Если удастся настроить программу на таблицы АБС(могут быть сложности со структурой БД), то ее можно применять для извлечения данных. Если структура БД закрыта или непригодна(например необходимые данные не хранятся, а вычисляются), то можно создавать простые промежуточные таблицы, или даже создать свое Хранилище данных без интерфеса.
              2. В момент запуска "среза" - конкретного аналитического интерфейса Контур Стандарт выполняет запрос к БД и агрегирует первичные данные по классическми принципам OLAP, т.е вычисляет факты в разрезе измерений. Доступно несколько встроенных алгоритмов агрегации.
              3. Гиперкуб, построенный в оперативной памяти живет только в течение сеанса. При управлении таблицей в on-line интерфейсе (drill-down, drill-up, полный разворот колонок и строк, фильтрация и пр.)используется именно гиперкуб в памяти с агрегатами, построенными в нем. По отношению к источнику работа происходит в off-line, данные обновятся при следующем запуске "среза".
              4. Программа отображает данные в таблице и диаграмме, позволяет распечатаь или выгрузить отчеты в Excel, HTML, тект.

              Другими словами можно применять для каждой из перечисленных Вами стадий, или только для последней. Но, подчеркиваю, это не Хранилище данных и не OLAP -сервер. Его достоинства - дешевизна, нулвеое администрирования, простота. Производительность у программы очень высокая для своего класса, реально можно работать с сотнями тысяч атомарных записей, укладываясь в тест FASMI. Но если вы хотите создать полномасштабное Хранилище понадобится другой инструмент.

              Комментарий


              • #8
                to pSrg
                Насколько мне известно, изначально Контур (ранее Condor) затачивался под структуру данных данных RS-Bank. То есть Контур сразу декларировался как ROLAP-система. Кроме того в продукте использовались не стандартные средства OLAP какой-либо СУБД (кстати, если я не ошибаюсь, Контур работает на Btrive, а там таковых нет) а механизм, написанный системщиками Софтлаба, который принципиально не поддерживал более пяти основных измерений. Поэтому возникает вопрос: если Контур раньше был просто примочкой для генерации отчетов под RS-Bank, о какой подноценной реализации механизмов OLAP (если у кого-то возникают сомнения, предлагаю перечитать 12-ти принципов, изложеных Коддом) может идти речь?
                На мой взгляд, для полноценной реализации механизма OLAP под этот самый OLAP должна быть заточена сама АБС, на данных которой планируется анализ.

                Комментарий


                • #9
                  to Nekrasov
                  Спасибо за разьяснение. Виной всему недостаток информации.
                  Если можно, задам еще вопрос:
                  >Есть 5 основных измерений, для которых сделан специальный сервис и
                  Что значит "специальный сервис"?
                  >до 2000 дополнительных. OLAP анализ замечательно выполняется по всем >измерениям. Хотя больше семи измерений редко требуется.
                  Что значит "дополнительные измерения" и чем они отличаются от основных?

                  Кстати, где можно будет посмотреть Контур Корпорация?

                  VIG (бывший Golovanov).

                  Комментарий


                  • #10
                    to Харибда.
                    2. Это очень правильный вопрос: что такое аналитические отчеты. От него зависит и ответ на вопрос кто ими пользуется в банке. Я так думаю, что все отчеты кроме обязательных являются аналитическими. Даже самые простые из них, а не только навороченные. Потому что для чего они делаются? Для анализа. В этом случае аналитическими отчетами пользуется половина специалистов в банке.
                    3. Ну я не очень понял, что такое отчет по субъективным критериям. А что касается "писать", то как раз прелесть OLAP в том, что он позволяет изрядную часть отчетов не программировать вовсе(но, к сожалению, отнюдь не все). Вместо этого настроить систему на источник данных и передать пользователю. А уже пользователь будет крутить данные под всеми углами и при желании распечатывать результат. Вот ему и отчет будет.

                    Вот простой пример. Грузим в OLAP лицевые счета с такими измерениями: балансовый счет, клиент, правовой статус клиента, операционная дата и одним фактом - остаток. Теперь пользователь получает возможность получить отчеты движением мышки:
                    1. Сравнение отстатков на счетах физических и юридических лиц.
                    2. Динамика собственного капитала банка по кварталам.
                    3. 50 крупнейших клиентам по среднедневным остаткам
                    4. Динамика остатков на счетах клиента "Супер Пупер"
                    И еще штук двести - триста. Это идеальная задача для OLAP.

                    Вот сложный пример:
                    Грузим в OLAP сделки, предварительно выделенные из остатков, кредитных договоров, форвардных контрактов и пр. Измерениями делаем сроки до погашения и пр. Фактами делаем сумму и какое-нибудь среднеквадратичное отклонение или что-нибудь еще хуже. Получаем сложные отчеты типа GAP и пр. Здесь OLAP мб и не нужен. Он будет просто удобной смотрелкой. Гораздо важней иметь данные и владеть этими алгоритмами.

                    Комментарий


                    • #11
                      to VIG.
                      Это касается только системы Контур Крпорация.
                      Пять основных измерений есть всегда: Субъекты, ОШС, Бизнес-операции, Финансовые измерения и время иерархические, с множеством "навигаторов" - заранее описанных наборов реквизитов этих измерений, из которых в интерфейсе показывается эксплорер для выборок и созданы многие другие удобные функции. Я не смогу все в Форуме описать.
                      Дополнительные измерения -это настроенные пользователями реквизиты документов и счетов. Их неограниченное количество, они являются ссылкамми на пользовательские же справочники. Но плоские.

                      А посмотреть и даже попользоваться системой можно на сайте www.banklist.ru. Это проект АРБ (пока упрощенный макет с не очень большой функциональностью), который сделан на системе Контур Корпорация с применением встроенного в нее Web -API. В Хранилище находятся отчетные показатели нескольких сотен банков за два года(данные предоставляет ЦБ), выпустить стандартные отчеты можно в Excel. И есть OLAP - анализ. Кстати, как раз применяется гибридная архитектура HOLAP. Реляционное Хранилище данных + OLAP сервер. Информация для оценки производительности: сервер Intel 400 МГ, 64 МБ.

                      Комментарий


                      • #12
                        to golovanov
                        Уважаемый г-н Голованов. К сожалению, в Вашем сообщении практически все утверждения неверны. Но все равно спасибо за интерес к системе.

                        Во - первых, Вы говорите о Контур Корпорация(Хранилище данных). А здесь обсуждался Контур Стандарт (OLAP - клиент). Это принципиально разные системы. Но можно обсудить и Корпорацию.

                        >Насколько мне известно, изначально Контур (ранее Condor) затачивался под структуру данных данных RS-Bank.
                        Никогда не затачивался. Структура данных в Контур Корпорация принципиально другая и затачивалась под импорт из любой АБС и не только АБС.

                        >То есть Контур сразу декларировался как ROLAP-система.

                        Это так.

                        >Кроме того в продукте использовались не стандартные средства OLAP какой-либо СУБД (кстати, если я не ошибаюсь, Контур работает на Btrive, а там таковых нет) а механизм, написанный системщиками Софтлаба, который принципиально не поддерживал более пяти основных измерений.

                        Никогда система Контур Корпорация не работала на btrieve. Она работает на MS SQL(основная версия) и Sybase. "Стандартным средством OLAP какой-либо СУБД" наверное можно назвать например MS OLAP Services с которым в конфигурации HOLAP работает Контур Корпорация. Очень скоро это можно будет попробовать прямо на живом сайте.
                        А Контур Стандарт - это универсальный OLAP - клиент. Он может работать со многими СУБД: MS SQL, Sybase, Oracle, DB2 и т.д. Если использовать ODBC, то можно работать и на btrieve.

                        Есть 5 основных измерений, для которых сделан специальный сервис и до 2000 дополнительных. OLAP анализ замечательно выполняется по всем измерениям. Хотя больше семи измерений редко требуется.

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

                        >Поэтому возникает вопрос: если Контур раньше был просто примочкой для генерации отчетов под RS-Bank, о какой подноценной реализации механизмов OLAP (если у кого-то возникают сомнения, предлагаю перечитать 12-ти принципов, изложеных Коддом) может идти речь?

                        Звучит немного забавно. Представьте себе примочку ПОД RS-Bank (btrieve), имеющую более миллиона строк кода и сделанную на MS SQL\Sybase. Примочкой для генерации отчетов под RS-Bank был и, если не ошибаюсь, есть проект "Отчеты ЦБ", созданный на той же платформе и в той же идеологии, что и сам RS-Bank. Еще был Visual RSL в качестве именно примочки для генерации отчетов. А команда разработчиков Condor изначально специализировалась на создании корпоративного Хранилища данных.

                        >На мой взгляд, для полноценной реализации механизма OLAP под этот самый OLAP должна быть заточена сама АБС, на данных которой планируется анализ.
                        Очевидно это 13-й принцип Кодда

                        Комментарий


                        • #13
                          2Nekrasov
                          Прошу ответить на ряд вопросов:
                          1. Если говорить об использовании OLAP системы в Банке,
                          не кажется ли Вам, что построением аналитических отчетов
                          занимается небольшое количество специалистов?
                          2. Что понимается под аналитическими отчетами в Банке?
                          3. При построении аналитических отчетов с помощью OLAP
                          системы аналитики Банка используют фактически собственные методики
                          обработки и получения данных. Как быть в случае, если Банк хочет
                          получать аналитические данные по формализованным, а не субъективным
                          критериям? Все равно писать аналитические отчеты?

                          Комментарий


                          • #14
                            2Nekrasov

                            3. Субъективные критерии. Это означает, что пользователь при построении аналитического отчета сам решает как ему строить отчет. На простых данных все просто и для всех пользователей одинаково. Сложные аналитические выборки могут быть сформированы разными пользователями по-разному, т.е. разные пользователи получат разные результаты на одинаковых данных. Причины:
                            3.1. Пользователи могут ошибаться.
                            3.2. Нормативные документы могут трактоваться по-разному. При этом не происходит нарушения нормативной базы,- практически любой норматив допускает множество верных трактований.
                            Таким образом результат сложного аналитического отчета сильно зависит от того, какой человек его получает.
                            Как мне кажется, единственный способ побороть такое вольнодумие это унификация всех отчетов (т.е. фактически унификация технологий получения информации) в Банке.

                            2. По поводу доступности OLAP системы половине сотрудников Банка. Если OLAPом пользуются аналитики Банка, то все нормально, им можно А вот половина пользователей Банка имеет ограниченный доступ к объектам учета Банка (т.е. счета, договора, услуги, документы и т.п.) и OLAP системы тоже должна это учитывать. При этом возникает масса проблем (если конечно OLAP система вообще заботится о распределении прав на объекты учета), решение которых нетривиально. Например:
                            2.1. Падает производительность OLAPа. Т.е. если выборка каждой грани куба содержит условия на проверку доступа, понятно, что общая скорость обсчета куба падает многократно.
                            2.2. Если OLAP система собирает данные слоями по дням (а так чаще всего и бывает), то как быть с историей прав пользователя? Тоже по дням? А если нужно добавить ему прав? А удалить? При этом пользователей много (половина банка), а администраторов мало. Как быть с ошибками, вызванными неправильным распределением прав? Как насиловать OLAP систему, если остатки по балансовому счету пользователю нужны, а лицевые смотреть нельзя? Все это слишком тяжело получается.
                            ИТОГО. Как мне кажется, OLAP системы все-таки предназначена именно для аналитиков, обладающих правами на всю информацию. Аналитиков в Банке не так уж много. Таким образом, получаемая аналитиками с помощью OLAP системы информация получается очень дорогой, ибо OLAP системы недешевы. И главный вопрос в том, а стоит ли получаемая информация вложенных затрат?

                            Комментарий


                            • #15
                              Видел я ваш Орион...Ну что сказать... МС Ассесс работает значительно быстрее (по крайней мере, из 150 банков и 20 дат несколько балансовых счетов выбрать -- легко)... Интересно, почему в балансах вы не могли указать (посчитать) строчку ИТОГО? Потому, что в ЦБ-шносайтовской форме ее нет? Далее, кто вам писал текста на сайте (конкретно про рейтинги)? люди из Ушей (ER-ратинга)? больно уж стиль похож... А можно показывать не один счет, и не 2, а первый + (или -) второй? Уж это то ОЛАП должОн делать? А так -- ничего личного.

                              Комментарий


                              • #16
                                Харибда, согласен, что проблему разграничения прав доступа для OLAP еще никто до конца не решил. У нас для этого кое-что сделано, но нельзя сказать, что это "серебрянная пуля". А насчет цены Вы зря. Наш OLAP -клиент стоит 360$ без ограничения числа конечных пользователей. Дешевле только даром.
                                hi_all, спасибо за критику. Учтем.

                                Комментарий


                                • #17
                                  Кстати. "А можно показывать не один счет, и не 2, а первый + (или -) второй?". Это можно. Просто нужно с кнопкой Ctrl отменить нужные балансовые счета и нужные банки в списке. В произвольном порядке.

                                  Комментарий


                                  • #18
                                    To Nekrasov:

                                    Я не буду пытаться опровергать два Ваших утверждения Лучше вы опровергните моё :-)
                                    Нас останавливает от внедрения OLAP ряд проблем:
                                    1. При её внедрении необходимо будет разделить базу на OLTP и OLAP. Одно дело, когда отчеты пишут программисты - они то знают, что они делают, "обращаются" с базой "нежно", и поэтому эти отчеты "не мешают" обработке транзакций. Другое дело, когда отчеты будут писать пользователи. Если их пустить в онлайновыю базу - они любой сервер загрузят так, что никто работать не сможет. Т.е. необходимо выделять отдельную базу (и отдельный сервер) под OLAP. А это сильно усложняет (и "удорожает") поддержку системы, теряется оперативность и т.д. Разделение базы на OLTP и OLAP вообще один из самых сложных на сегодня вопросов в СУБД. Все говорят, что это очень круто, но мало кто это делает.
                                    2. Необходимо обучать пользователей и работе с OLAP системой, и структуре базы и много чему еще. А они все люди занятые, они хотят, чтобы кнопку нажал и получил нужные данные. :-)
                                    3. Допустим, что я заставил пользователей изучить всё это и они стали сами писать себе отчеты. Тут неизбежно будет тоже ряд издержек. Они начнут ошибаться, дублировать работу (два пользователя независимо друг от друга будут делать одно и то де) и т.д.


                                    ------------------

                                    Комментарий


                                    • #19
                                      To Fomin. Полностью согласен, эти проблемы есть. Платить за все приходится, вопрос лишь в том перевесит ли снижение издержек дополнительные расходы. Может быть это можно посчитать?

                                      Комментарий

                                      Пользователи, просматривающие эту тему

                                      Свернуть

                                      Присутствует 1. Участников: 0, гостей: 1.

                                      Обработка...
                                      X