company_banner

Как создать систему бизнес-аналитики и не наломать дров

    Для правильного принятия бизнес-решений необходимо владеть наиболее полной и подробной информацией о состоянии дел в компании. Но нередко такая информация ограничена годовыми да квартальными отчётами.

    Этого, безусловно, мало. Для эффективного анализа на предприятиях часто внедряют системы бизнес-аналитики (англ. business intelligence, далее — BI-системы). Сегодня мы хотим поделиться несколькими советами, которые могут помочь при создании BI-системы в вашей компании (и которые помогли бы нам самим год назад).




    Проектирование


    Храните исходные данные, а не срезы по ним


    Никогда не стоит надеяться на то, что фиксированных графиков и отчётов будет достаточно. Наоборот, менеджеры будут просить вас построить всё более детальные графики. И уточнений будет масса.

    Например, к нам поступил запрос о том, сколько денег потратили холостые гетеросексуалы из Калифорнии возрастом до 25 лет за каждый месяц прошлого года. Чтобы быть готовым ответить на подобный вопрос, нам необходимо иметь под рукой не только таблицу с полными профилями пользователей, но и таблицу с их платежами.

    Анализируйте «сырые» данные, а не готовые срезы


    Старайтесь анализировать «сырые» данные. Не делайте предварительной агрегации. Помните: как только вы делаете агрегацию данных, вы теряете информацию.

    Например, необходимо получить статистику о количестве новых контактов в день для жителей Нью-Йорка. Если делаете анализ непосредственно самих данных, то вы можете подтвердить полученные результаты конкретными примерами: кто, когда и с кем.

    Забудьте про синдром «Not Invented Here»


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

    Сегодня в Badoo используется колоночная база данных Vectorwise и аналитический «фронтэнд» Pentaho. Таким образом практически всё сводится к загрузке данных в БД.

    Помните о заказчиках


    Системой, которую вы проектируете, будут пользоваться обычные менеджеры, у которых слова «первая производная по времени» могут вызвать нестерпимую изжогу. Интерфейс к данным должен быть предельно простым и однозначным. Именно поэтому не стоит заново изобретать интерфейс. Лучше посмотреть, что уже придумано до вас.

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

    Не откладывайте создание BI-системы


    Проектирование, разработка и внедрение BI-системы — процесс довольно долгий и сложный. Это тот самый случай, когда 9 женщин не смогут родить ребёнка за один месяц. Внедрение BI-системы в Badoo ещё не завершено, но первые значимые результаты были достигнуты как раз примерно через 9 месяцев после начала. В составе BI команды было 3 человека плюс 1 консультант.

    Разработка


    Собирайте данные асинхронно


    Если вы хотите начать собирать данные о поведении пользователей, то делайте это асинхронно. Можно писать в логи, можно писать в Scribe. Помните, что сбор данных об объекте надо проводить без заметного вмешательства в поведение этого объекта. Да и в принципе неполадки в BI-системе не должны отражаться на исследуемом объекте.

    При разработке инфраструктуры для сбора информации о поведении пользователей мы знали о большом объёме обрабатываемых данных. И все эти данные было необходимо собрать в одном хранилище данных. Разумеется, любые проблемы в работе этого хранилища должны быть незаметны пользователям сайта. Потому было решено записывать первичные данные в логи, и только затем перекладывать их в хранилище отдельным фоновым скриптом. В дальнейшем логи и парсеры были заменены сервисом Scribe.

    Забудьте про нормализацию


    Не бойтесь «денормализовать» данные. Так, если у вас есть таблица с пользователями и таблица с их платежами, возможно, вам окажется полезна таблица с парами «пользователь-платёж» (результат соединения двух таблиц). С одной стороны, вы получаете жёсткое дублирование данных. С другой стороны, вместо сложной операции «join» на каждый запрос вы получите более простую операцию подсчёта уникальных значений.

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

    SELECT sum(money), gender FROM UserPayment WHERE gender IN (‘M’,’F’) and year(payment_date) = year(now()) GROUP BY 2


    Этот запрос может быть легко «распараллелен», так как всё, что нужно сделать СУБД для его выполнения — обработать таблицу за один проход.

    Следите за потоками данных


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

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

    Внедрение


    Проверяйте собранные данные


    При внедрении BI-системы необходимо проверять поступающие данные, причём делать это нужно очень тщательно. Например, если вы получаете параметры пользователей системы, обязательно проверьте распределение дат регистрации, дней рождения и т.д. В идеале стоит проверить распределение значений в каждом столбце или даже в парах столбцов.

    Часто при добавлении новых данных встречается ситуация, когда значение столбца во всех строках одинаково. Практически всегда причиной является человеческий фактор — разработчик просто забыл про этот столбец.

    Лишних данных не бывает, бывают повторы


    Когда вы смотрите, какие данные нужно импортировать в систему, помните, что лишних данных не бывает. Бывают повторы данных. И вот к повторам нужно отнестись с подозрением. Лучше взять дополнительные данные и убедиться, что у вас есть те же самые значения, чем заранее отказаться от повторов. Это помогает выявить ошибки в системах.

    Именно так в процессе внедрения BI-системы в Badoo было исправлено множество ошибок. Это были и ошибки в профилях пользователей, и ошибки в данных о городах, и даже несколько ошибок в финансовых данных.

    Не стремитесь за 100% соответствием


    Сравнивая и сопоставляя данные из разных источников, не гонитесь за 100% соответствием. Если вы достигли 95% совпадения, этого, скорее всего, уже достаточно. Вы всё же не бухгалтерскую систему проектируете, когда за каждой копейкой следить надо.

    Очень часто расхождение данных вызвано объективными причинам, например, такими как рассинхронизация времени. Например, время регистрации платежа в собственном «биллинге» и в платёжной системе. Разница во времени в 1 секунду 31 декабря может привести к тому, что один и тот же платёж будет датирован разными годами.

    Заключение


    Эти советы не универсальны, на каждый из них можно найти исключение. Не нужно их воспринимать как абсолютную истину. Наоборот, чем больше контр-примеров вы сможете привести, тем лучше вы поймёте суть этих правил. А если у вас есть конкретные вопросы, мы постараемся на них ответить.

    Алексей alexxz Еремихин, разработчик Badoo.
    Badoo
    264.47
    Big Dating
    Share post

    Comments 17

      0
      Утверждение про то, что нужно анализировать «сырые» данные, очень спорное. По мере расширения перечня задач, которые решает система, я, например, пришел к тому, что в конечные отчеты вообще не должны попадать непредрассчитанные и не сохраненные в БД агрегации. Кроме того, в случае изменения исходных данных и их перерасчета, предыдущую версию данных пользовательского отчета во многих случаях лучше сохранить. Соображений в пользу этого несколько. Основные: 1) не оставить пользователя без отчета, когда идет обновление «сырых» данных; 2) давать возможность получить предварительный отчет по неполным данным, а потом узнать какая составляющая изменилась.
        0
        Сколько уходит времени у пользователя вашей системы, чтобы создать новый отчёт, который до этого никому кроме него и не нужен был? У нас это время меньше минуты (на манипуляции с интерфейсом).
          0
          Смотря, что понимать под новым отчетом.
          1. Если новый перечень объектов/агрегация (даты, подразделения, продукты...) — то они все они предсказуемы и предрасчитаны (даты — месяца, кварталы, годы; подразделения — более крупные подразделения и т.д.)
          2. Если совсем новый показатель — то печалька: пользователь его сам не создаст. Но это не страшно при "вытягивающей" системе работы, если данных, которых пользователи не заказывали, в БД не появляется.
            0
            Давайте снова рассмотрим пример «сколько денег потратили холостые гетеросексуалы из Калифорнии возрастом до 25 лет за каждый месяц прошлого года».

            У нас менеджер для этого
            — Указывает метрику IncomeLog
            — Указывает размерности: gender search, country, state, payment month, marital status, age
            — Указывает фильтры по размерностям.

            То есть мы указываем доступные метрики и размерности. А как их комбинировать — дело пользователя.

            Если я правильно понял ваш пример — у вас нет свободы комбинирования размерностей. Только те, что посчитаны заранее.
              0
              Да, Вы правильно поняли.
              Но, хотелось бы ещё отметить три разноплановых момента:
              1. Ваша свобода комбинирования размерностей ограничивается производительностью системы. Ну и структурой данных, если пользователи не создают сами индексы/кубы и т.д. для своих задач.
              2. Необходимо помнить, что описанный Вами отчет — промежуточный материал в работе аналитика над его задачами. Конечный отчет, который ляжет на стол менеджеру, будет содержать именно сгруппированные данные, которые этот аналитик будет досчитывать в Excel-е.
              3. Система, которую я описал, идеальная абстракция. На практике приходится быть гибче, и поддерживать промежуточные варианты обращения к данным. Диалектика, так сказать, в ответ на Ваш тезис)
                0
                Да. Вопросы производительности часто являются указанием насколько сырые данные надо хранить и анализировать.

                Да. Окончательная визуализация в Excel — тоже необходима. Но и без красивых графиков в фронтенде тоже никуда 8)

                PS Не представляю себе проектирования без диалектики.
        +1
        Спасибо, очень интересная статья и полезные советы! Как раз думаем о внедрение чего то для BI. А можно немного подробностей?

        Вы используйте pentaho business analytics я так понимаю?
        Я так понимаю OLAP кубы тоже используются? Если да, то не совсем понятно что используется в качестве OLAP сервера? Используется ли mondrian.pentaho.com/?

        Так же очень интересно, насколько эта связка позволяет вам быстро создавать новые отчеты? Грубо говоря, менеджер захотел новый отчет — какие ваши дальнейшие действия и как быстро он получит желанные данные?

        Какие северные мощности выделенные под проект?
          0
          Данные для анализа (OLAP-кубы) располагаются и обрабатываются в Vectorwise.

          Составление нового отчёта в комментарии выше

          Серверные мощности критичны для базы данных. Сейчас конфигурация сервера БД такая
          Диск 2Тb
          Процессор 12 Cores (+12 Hyper-threading но толку от них почти нет)
          192Gb RAM

          Ну и плюс несколько более слабых серверов для «прочего».
            0
            Благодарю за ответ!

            > Данные для анализа (OLAP-кубы) располагаются и обрабатываются в Vectorwise.
            Верно ли я понимаю что у вас получается ROLAP, где pentaho business analytics (подозреваю что как раз через mondrian) преобразует MDX в SQL? Если не секрет, почему выбрали именно это решение? Рассматривали ли какие то MOLAP решения?

            > 192Gb RAM
            о да! охотно верю что менеджер получают отчеты в течение минут :)

            В статье вы фактически описывали получения ответов на четко поставленные вопросы. А в сторону Data mining смотреть планируйте? Вроде как в продуктах pentaho какие то элементы DM заявлены.
              0
              Прочитал про ROLAP и MOLAP. На сколько я понял из описания, мы действительно используем ROLAP подход.

              Думаю, что ваша гипотеза про использование Mondrian для преобразования MDX в SQL верна. Я не залезал в Pentaho глубоко.

              Выбор ПО и технологий для построения системы прошёл без моего участия, потому я не осведомлён какие конкуренты рассматривались в том выборе. Если вас действительно интересуют детали, предлагаю увести переписку по этому вопросу в приват.

              Да, DM запланирован. Практически же кроме «интуиции оператора» пока никакого DM нет.
            +2
            Расскажите, что используете для визуализации Pentaho. Стандартный JPivot слишком устарел и выглядит откровенно плохо. Наблюдаю за Saiku — вроде как официальная замена, но тоже вроде еще в разработке. Есть еще разработка FlexMonster — красивая, но платная… Подскажете еще что-то?
              0
              Я думаю вопрос был не мне. Но он мне тоже интересен и актуален :)
              Из того что знаю я более менее живым выглядит только openi. Но не пробовал его. Был еще какой то jrubik, но он явно мертв.

              За FlexMonster спасибо — не видел его раньше. Выглядит милым. Хотя не радует что Flash. С планшета уже толком не посмотришь.
                0
                У нас используется родной Pentaho Reporting (EE). Спасибо за ссылки на альтернативу.
                  0
                  Причина использования — почти единственный визуализатор с платной поддержкой. И как мне тут подсказывают англоязычные коллеги «with Pentaho each consultancy seems to have their own front end».
              0
              Мне кажется или женщин действительно больше?
                0
                Согласно вики на каждую женщину приходится 1.01 мужчины. Так что вам показалось.

                PS Да, название на графике немного смущает. Там правильнее написать — доля людей указавших интересы в конкретной категории по отношению к числу людей указавших категорию вообще. Так что у наблюдаемого вами эффекта правильная трактовка — женщины склонны указывать интересы из большего числа категорий, чем мужчины.
                  0
                  спасибо, что разъяснили.

              Only users with full accounts can post comments. Log in, please.