Русский
Русский
English
Статистика
Реклама

Business intelligence

Понятная аналитика. Опыт внедрения сервисом Работа.ру решения Tableau

17.07.2020 16:20:19 | Автор: admin
У каждого бизнеса возникает потребность в качественной аналитике данных и ее визуализации. Еще один важный фактор, который следует учитывать это простота использования для бизнес-пользователя. Инструмент не должен требовать дополнительных затрат на обучение сотрудников на начальном этапе. Одним из таких решений является Tableau.

Сервис Работа.ру выбрал Tableau для многофакторного анализа данных. Мы поговорили с Алёной Артемьевой, директором по аналитике сервиса Работа.ру и узнали как изменилась аналитика после внедренного командой BI GlowByte решения.

Q: Как возникла потребность в решении BI?

Алёна Артемьева: В конце прошлого года команда сервиса Работа.ру начала стремительно расти. Именно тогда возросла потребность в качественной и понятной для всех аналитике со стороны самых разных подразделений и руководства компании. Мы осознали необходимость создания единого и удобного для всех пространства аналитических материалов (ad hoc исследований и регулярных отчетов) и начали активно двигаться в этом направлении.

Q: На основании каких критериев выполнялся поиск BI-решения и кто принимал участие в оценке?

АА: Важнее всего для нас были следующие критерии:

  • наличие автономного сервера для хранения данных;
  • стоимость лицензий;
  • наличие десктоп-клиента Windows/iOS;
  • наличие mobile-клиента Android/iOS;
  • наличие веб-клиента;
  • возможность интеграции в приложение/портал;
  • возможность использования скриптов;
  • простота/сложность инфраструктурной поддержки и необходимость / отсутствие необходимости поиска специалистов для этого;
  • распространенность BI-решений среди пользователей;
  • отзывы пользователей BI-решений.

Q: Кто принимал участие в оценке:

АА: Это была совместная работа команд аналитиков и ML Работы.ру.

Q: К какой функциональной области относится решение?

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

Q: Какую проблему (задачи) решали?

АА: Tableau помог нам решить несколько ключевых задач:

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

Q: Что было до Tableau? Какие технологии использовали?

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

Q: Как происходило внедрение решения?

АА: Мы начали с того, что самостоятельно раскатили серверную часть и начали делать отчеты, соединяя данные из витрин с подготовленными данными на PostgreSQL. Через несколько месяцев передали сервер на поддержку в инфраструктуру.

Q: Какие департаменты первыми подключились к проекту, было ли это сложно?

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

Q: Кто участвовал в команде внедрения?

АА: В основном это была команда ML.

Q: Требовалась ли подготовка сотрудников?

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

Q: Какова сложность освоения?

АА: Для нас всё прошло относительно легко, а платформа оказалась интуитивно понятна всем.

Q: Как быстро получили первый результат?

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

Q: Какие показатели по итогам проекта уже есть?

АА: Мы уже реализовали более 130 отчетов по различным направлениям и в несколько раз повысили скорость подготовки данных. Это оказалось важно и для специалистов нашего PR-подразделения, так как теперь мы можем быстро отвечать на большинство актуальных запросов от СМИ, выпускать объемные исследования по рынку труда в целом и по отдельным отраслям, а также готовить ситуативную аналитику.

Q: Как планируете развивать систему? Какие отделы будут вовлечены в проект?

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

Внедрение подхода Self-Service для самостоятельного анализа данных

08.04.2021 20:08:42 | Автор: admin
Инструменты Business Intelligence (BI) за последние несколько лет проникли почти во все виды бизнеса, а изучению данных уделяется все больше внимания и выделяется больше ресурсов. Если говорить об IT-компаниях, то здесь, наверное, большинству понятно предназначение Business Intelligence и то, какую ценность для компании представляет анализ внутренних данных.



В Playrix на подготовку и анализ данных выделяется значительное количество ресурсов, мы стараемся использовать передовые технологии и серьёзно подходим к обучению сотрудников. Компания входит в топ-3 разработчиков мобильных игр в мире, поэтому мы стараемся держать соответствующий уровень в анализе данных и конкретно в Business Intelligence. Ежедневно в наши игры играют более 27 млн пользователей, и эта цифра может дать примерное представление об объемах данных, генерируемых мобильными устройствами каждый день. Кроме этого, данные забираются из десятков сервисов в различных форматах, после чего они агрегируются и загружаются в наши хранилища. В качестве Data Lake мы работаем с AWS S3, а Data Warehouse на AWS Redshift и PostgreSQL применяется ограниченно. Эти базы данных мы используем для аналитики. Redshift быстрее, но дороже, поэтому там мы храним самые востребованные данные. PostgreSQL дешевле и медленнее, там хранятся либо небольшие объемы данных, либо данные, скорость чтения которых некритична. Для предагрегированных данных используем Hadoop кластер и Impala.

Основным инструментом BI в Playrix является Tableau. Этот продукт достаточно хорошо известен в мире, имеет широкие возможности для анализа и визуализации данных, работы с различными источниками. Кроме того, для простых задач анализа не приходится писать код, поэтому можно обучить пользователей разных отделов самостоятельно анализировать свои бизнес-данные. Сам вендор инструмента Tableau Software также позиционирует свой продукт как инструмент для самостоятельного анализа данных, то есть для Self-Service.

Есть два основных подхода анализа данных в BI:

  1. Reporting Factory. В этом подходе есть отдел и/или люди, разрабатывающие отчеты для бизнес-пользователей.
  2. Self-Service. В этом подходе бизнес-пользователи делают отчеты и строят аналитику своих процессов самостоятельно.

Первый подход традиционный, и в большинстве компаний работает такая фабрика производства отчетов в масштабах всего предприятия. Второй подход относительно новый, особенно для России. Хорош он тем, что данные исследуют сами бизнес-пользователи они намного лучше знают свои локальные процессы. Это помогает разгружать разработчиков, избавлять их от необходимости каждый раз погружаться в особенности процессов команд и заниматься созданием самых простых отчетов. Это помогает решить, наверное, самую большую проблему проблему преодоления пропасти между бизнес-пользователями и разработчиками. Ведь основная проблема подхода Reporting Factory как раз в том, что большая часть отчетов может остаться невостребованной только из-за того, что программисты-разработчики неверно понимают проблемы бизнес-пользователей и, соответственно, создают ненужные отчеты, которые либо переделываются потом, либо просто не используются.

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

В Playrix подразделение Business Intelligence (BI Team) работает над задачами:

  1. Сбора, подготовки и хранения данных.
  2. Разработки внутренних сервисов аналитики.
  3. Интеграции с внешними сервисами.
  4. Разработки web-интерфейсов.
  5. Разработки отчетности в Tableau.

Мы занимаемся автоматизацией внутренних процессов и аналитики. Упрощенно нашу структуру можно представить при помощи схемы:


Мини-команды BI Team

Прямоугольниками здесь обозначены мини-команды. Слева команды бэка, справа команды фронта. Каждая из них обладает достаточными компетенциями для работы с задачами смежных команд и берут их на себя при перегруженности остальных команд.

В BI Team построен полный цикл разработки: от сбора требований до разворачивания на продуктовом окружении и последующей поддержки. В каждой мини-команде есть свой системный аналитик, разработчики и инженеры по тестированию. Они выполняют функцию Reporting Factory, подготавливая данные и отчеты для внутреннего использования.

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

Передача компетенций и запуск пилотного проекта


По нашему опыту работы и общения с другими компаниями основными проблемами при передаче data-компентенций бизнес-пользователям становятся:

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

Поддержка со стороны менеджмента у нас колоссальная, более того, менеджмент и предложил внедрять Self-Service. Желание у пользователей изучать работу с данными и Tableau тоже есть это ребятам интересно, плюс анализ данных сейчас очень существенный скилл, который большинству точно пригодится в будущем.

Внедрение новой идеологии сразу во всей компании обычно требует много ресурсов и нервов, поэтому мы начали с пилота. Пилотный проект Self-Service запустили в отделе User Acquisition полтора года назад и в процессе пилота копили ошибки и опыт, чтобы передать их другим отделам в будущем.

Направление User Acquisition работает над задачами увеличения аудитории наших продуктов, анализирует пути закупки трафика и выбирает, в какие направления привлечения пользователей стоит инвестировать средства компании. Раньше для этого направления готовились отчеты командой BI, либо ребята сами обрабатывали выгрузки из базы при помощи Excel или Google Sheets. Но в динамичной среде развития такой анализ влечет задержки, а число анализируемых данных лимитировано возможностями этих инструментов.

На старте пилота мы провели базовое обучение сотрудников работе с Tableau, сделали первый общий источник данных таблицу в базе Redshift, в которой было более 500 млн строк и необходимые метрики. Следует отметить что Redshift это столбчатая (или колоночная) база данных, и эта база отдает данные намного быстрее реляционных БД. Пилотная таблица в Redshift была действительно большой для людей, которые никогда больше чем с 1 млн строк одновременно не работали. Но это был вызов для ребят, чтобы научиться работать с данными таких объемов.

Мы понимали, что проблемы с производительностью начнутся по мере усложнения этих отчетов. Доступа к самой БД пользователям мы не давали, но был реализован источник на сервере Tableau, подключенный в режиме live к таблице в Redshift. У пользователей были лицензии Creator, и они могли подключаться к этому источнику либо с сервера Tableau, разрабатывая отчеты там, либо с Tableau Desktop. Надо сказать, что при разработке отчетов в вебе (у Tableau есть режим web edit) на сервере есть некоторые ограничения. На Tableau Desktop же таких ограничений нет, поэтому мы преимущественно разрабатываем на Desktop. Кроме того, если анализ нужен только одному бизнес-пользователю, не обязательно такие проекты публиковать на сервере можно работать локально.

Обучение


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

Для всех пользователей, у которых есть лицензии Tableau, мы провели и записали получасовой вебинар по работе с сервером и дашбордами. В нем рассказали о проектах на сервере, работе с нативными контролами всех дашбордов это верхняя панель (refresh, pause, ). Об этом обязательно надо рассказывать всем пользователям Tableau, чтобы они полноценно могли работать с нативными возможностями и не делали запросы на разработку фич, которые повторяют работу нативных контролов.

Основным препятствием для освоения какого-то инструмента (да и вообще чего-то нового) обычно является страх того, что не получится разобраться и работать с этим функционалом. Поэтому обучение, пожалуй, является самым важным этапом внедрения подхода self-service BI. От него будет сильно зависеть результат внедрения этой модели приживется ли она в компании вообще и если да, то насколько быстро. На стартовых вебинарах как раз и надо снять барьеры использования Tableau.

Можно выделить две группы вебинаров, которые мы проводили для людей, не знакомых с работами баз данных:

  1. Стартовый набор знаний новичка:

    • Подключение к данным, типы соединений, типы данных, базовые преобразования данных, нормализация данных (1 час).
    • Базовые визуализации, агрегация данных, базовые вычисления (1 час).
  2. Сложные вычисления и базовые трюки/элементы, принятые в компании (2 часа).

В первом стартовом вебинаре мы рассматриваем все, что касается подключения к данным и преобразования данных в Tableau. Поскольку у людей обычно есть базовый уровень владения MS Excel, то здеcь важно объяснить, чем принципиально отличается работа в Excel от работы в Tableau. Это очень важный пункт, поскольку нужно переключить человека с логики таблиц с раскрашенными ячейками на логику нормализованных данных БД. На этом же вебинаре мы объясняем работу JOIN, UNION, PIVOT, также затрагиваем Blending. На первом вебинаре мы практически не затрагиваем визуализацию данных, его цель объяснить, как работать и преобразовывать свои данные для Tableau. Важно, чтобы люди понимали, что данные первичны и большинство проблем возникает на уровне данных, а не на уровне визуализаций.

Второй вебинар по Self-Service имеет целью рассказать о логике построения визуализаций в Tableau. Tableau сильно отличается от других BI инструментов именно тем, что имеет свой движок и свою логику. В других системах, например, в PowerBI, есть набор готовых визуалов (можно скачать дополнительные модули в магазине), но эти модули не кастомизируются. В Tableau же у вас есть фактически чистый лист, на котором можно строить все что угодно. Конечно же, в Tableau есть ShowMe меню базовых визуализаций, но все эти графики и диаграммы можно и нужно строить по логике работы Tableau. По нашему мнению, если хотите научить кого-то работать с Tableau, то не нужно использовать ShowMe для построения графиков большая их часть людям не пригодится на старте, а нужно учить именно логике построения визуализаций. Для бизнес-дашбордов достаточно знать, как построить:

  1. Time Series. Line/Area Charts (линейные графики),
  2. Bar Charts (столбчатые диаграммы),
  3. Scatter Plots (диаграммы разброса),
  4. Tables (таблицы).

Этого набора визуализаций вполне достаточно для самостоятельного анализа данных.

Time Series: в бизнесе применяются очень часто, поскольку интересно сравнивать метрики в различные периоды времени. У нас в динамике результаты бизнеса смотрят, наверное, все сотрудники компании. Bar Charts используем для сравнения метрик по категориям. Scatter Plots (диаграмма разброса) используются редко, обычно для нахождения корреляций между метриками. Таблицы: то, от чего в бизнес-дашбордах полностью избавиться не удается, но по возможности стараемся минимизировать их число. В таблицах собираем числовые значения метрик по категориям.

То есть мы отправляем людей в свободное плавание после 1 часа обучения работы с данными и 1 часа обучения базовым вычислениям и визуализациям. Далее ребята сами работают со своими данными некоторое время, сталкиваются с проблемами, накапливают опыт, просто набивают руку. Этот этап в среднем занимает 2-4 недели. Естественно, в этот период есть возможность проконсультироваться с командой BI Team, если что-то не получается.

После первого этапа у коллег возникает необходимость совершенствования навыков и изучения новых возможностей. Для этого мы подготовили вебинары углубленного обучения. В них мы показываем, как работать с функциями LOD, табличными функциями, скриптами Python для TabPy. Мы работаем с живыми данными компании, это всегда интереснее фейковых или данных базового датасета Tableau Superstore. В этих же вебинарах мы рассказываем об основных фичах и трюках Tableau, которые используются на продовых дашбордах, например:

  1. Sheet Swapping (замена листов),
  2. Агрегация графиков при помощи параметров,
  3. Форматы дат и метрик,
  4. Отбрасывание неполных периодов при недельных/месячных агрегациях.

Все эти трюки и фичи было принято использовать пару лет назад, поэтому в компании все к ним привыкли, и мы приняли их в стандартах разработки дашбордов. Скрипты Python мы используем для расчета некоторых внутренних метрик, все скрипты уже готовы, и для Self-Service надо понимать, как их вставлять в свои вычисления.

Таким образом, мы проводим только 4 часа вебинаров для старта Self-Service, и этого обычно достаточно, чтобы мотивированный человек начал работать с Tableau и самостоятельно анализировать данные. Кроме того, для дата-аналитиков у нас есть свои вебинары, они находятся в открытом доступе, можно знакомиться и с ними.

Разработка источников данных для Self-Service


После проведения пилотного проекта мы посчитали его успешным и расширили количество пользователей Self-Service. Одной из больших задач была подготовка источников данных для разных команд. Ребята в Self-Service могут работать с 200+ млн строк, поэтому команда Data Engineering должна была придумать, как реализовать такие источники данных. Для большинства аналитических задач мы используем Redshift из-за скорости чтения данных и удобства работы. Но выдавать доступ к базе каждому человеку из Self-Service было рискованно с точки зрения информационной безопасности.

Первой идеей было создание источников с живым подключением к БД, то есть на Tableau Server было опубликовано несколько источников, которые смотрели либо в таблицы, либо в подготовленные view Redshift. В этом случае мы не хранили данные на сервере Tableau, а пользователи через эти источники сами ходили со своих Tableau Desktop (клиентов) в базу. Это работает, когда таблицы небольшие (единицы миллионов) или запросы Tableau не слишком сложные. По мере развития ребята начали усложнять в Tableau свои дашборды, использовать LODы, кастомные сортировки, скрипты Python. Естественно, это привело к замедлению работы некоторых Self-Service дашбордов. Поэтому через несколько месяцев после старта Self-Service мы пересмотрели подход к работе с источниками.

В новом подходе, который мы применяем до сих пор, были реализованы опубликованные на Tableau Server экстракты. Надо сказать, что у Self-Service постоянно возникают новые задачи, и от них поступают запросы на добавление новых полей в источник, естественно, источники данных постоянно модифицируются. Мы выработали следующую стратегию работы с источниками:

  1. По ТЗ на источник со стороны Self-Service собираются данные в таблицах баз данных.
  2. Создается нематериализованное представление (view) в тестовой схеме БД Redshift.
  3. Представление тестируется на корректность данных командой QA.
  4. В случае положительного результата проверки представление поднимается на продовой схеме Redshift.
  5. Команда Data Engineering берет view на поддержку подключаются скрипты анализа валидности данных, сигналы алармирования ETL, выдаются права на чтение команде Self-Service.
  6. На Tableau Server публикуется источник (экстракт), подключенный к этому представлению.
  7. Заводятся сигналы ETL на запуск экстракта.
  8. Источник описывается в базе знаний.
  9. Описание источника, вся информация для подключения и работы передается команде Self-Service.

Немного про пункт 7. Нативно Tableau позволяет создавать экстракты по расписанию с минимальной разницей в 5 минут. Если вы точно знаете, что ваши таблицы в БД обновляются всегда в 4 часа утра, то вам можно просто поставить экстракт на 5 часов утра, чтобы ваши данные собрались. Это покрывает ряд задач. В нашем случае таблицы собираются по данным от различных провайдеров в том числе. Соответственно, если один провайдер либо наш внутренний сервис не успели обновить свою часть данных, то вся таблица считается невалидной. То есть нельзя просто установить расписание на фиксированное время. Поэтому мы используем API Tableau для запуска экстрактов по готовности таблиц. Сигналы запусков экстрактов формирует наш сервис ETL после того, как убедится в том, что все новые данные пришли и они валидны.

Такой подход позволяет иметь в экстракте свежие валидные данные с минимальной задержкой.

Публикация дашбордов Self-Service на Tableau Server


Мы сознательно не ограничиваем людей в экспериментах со своими данными и позволяем публиковать свои воркбуки, делиться ими. Внутри каждой команды, если человек посчитает, что его дашборд полезен другим, либо дашборд нужен этому сотруднику на сервере, он может его опубликовать. Команда BI не вмешивается во внутренние эксперименты команд, соответственно, всю логику работы дашбордов и вычисления они прорабатывают сами. Есть cлучаи, когда из Self-Service вырастает интересный проект, который потом полностью передается на поддержку команды BI и переходит на прод. Это как раз и есть тот самый эффект Self-Service, когда люди, хорошо разбираясь в своих бизнеc-задачах, начинают работать со своими данными и формируют новую стратегию своей работы. Исходя из этого мы сделали следующую схему проектов на сервере:


Схема проектов на Tableau Server

Каждый пользователь с лицензией Creator может публиковать свои воркбуки на сервер либо делать анализ локально. Для Self-Service мы сделали свою песочницу (Sandbox) со своими группами проектов.

Сайты в Tableau идеологически разделены так, чтобы пользователи одного сайта не видели контент другого, поэтому мы разделили сервер на сайты по направлениям, которые не пересекаются: например, игровая аналитика и финансы. Мы используем групповой доступ. В каждом сайте есть проекты, в которых права на их воркбуки и источники наследуются. То есть группa пользователей Group 1 видит только свои воркбуки и источники данных. Исключением из этого правила является сайт Sandbox, который имеет еще и подпроекты. Sandbox мы используем для прототипирования, разработки новых дашбордов, их тестирования и для нужд Self-Service. Все, у кого есть доступ на публикацию в своем проекте Sandbox, могут публиковать свои прототипы.

Мониторинг источников и дашбордов на Tableau Server


Поскольку мы перенесли нагрузку запросов Self-Service дашбордов с базы на Tableau Server, работаем с большими источниками данных и не ограничиваем людей по запросам к опубликованным источникам, то появилась другая проблема мониторинг быстродействия таких дашбордов и мониторинг созданных источников.

Мониторинг быстродействия дашбордов и быстродействия серверов Tableau задача, с которой сталкиваются средние и большие компании, поэтому про быстродействие дашбордов и его тюнинг написано достаточно много статей. Мы пионерами в этой области не стали, наш мониторинг это несколько дашбордов на базе внутренней БД PostgreSQL Tableau Server. Этот мониторинг работает со всем контентом, но можно выделить дашборды Self-Service и посмотреть их быстродействие.

Проблемы оптимизации дашбордов команда BI Team решает периодически. Пользователи иногда приходят с вопросом Почему медленно работает дашборд?, и нам нужно понимать, что такое медленно с точки зрения пользователя и какие числовые критерии могут характеризовать это медленно. Чтобы не интервьюировать пользователя и не отнимать его рабочее время для подробного пересказа проблем, мы мониторим и анализируем http-запросы, находим самые медленные и выясняем причины. После чего оптимизируем дашборды, если это может привести к увеличению производительности. Понятно что при живом подключении к источникам будут задержки, связанные с формированием view в базе задержки получения данных. Есть еще сетевые задержки, которые исследуем с нашей командой поддержки всей IT инфраструктуры, но в этой статье на них мы останавливаться не будем.

Немного о http requests


Каждое взаимодействие пользователя с дашбордом в браузере инициирует свой http request, передаваемый на Tableau Server. Вся история таких запросов хранится во внутренней БД PostgreSQL Tableau Server, срок хранения по умолчанию 7 дней. Этот срок можно увеличить изменениями настроек Tableau Server, но мы не хотели увеличивать таблицу http-запросов, поэтому просто собираем инкрементальный экстракт, в который укладываются только свежие данные каждый день, старые при этом не затираются. Это хороший способ с минимумом ресурсов держать в экстракте на сервере исторические данные, которых уже нет в базе.

Каждый http request имеет свой тип (action_type). Например, _bootstrap первоначальная загрузка view, relative-date-filter фильтр дат (слайдер). По названию можно определить большинство типов, поэтому понятно, что каждый пользователь делает с дашбордом: кто-то больше смотрит тултипы, кто-то меняет параметры, кто-то делает свои custom_view, а кто-то выгружает данные.

Ниже показан наш сервисный дашборд, который позволяет определять медленные дашборды, медленные типы запросов и пользователей, которым приходится ждать.


Дашборд мониторинга http-запросов

Мониторинг VizQL-сессий


Когда открывается какой-то дашборд в браузере, на сервере Tableau запускается VizQL сессия, в рамках которой происходит отрисовка визуализаций, также выделяются ресурсы на поддержание сессии. Такие сессии отбрасываются через 30 минут простоя по умолчанию.

По мере увеличения пользователей на сервере и внедрения Self-Service мы получили несколько пожеланий для увеличения лимитов сессий VizQL. Проблема пользователей была в том, что они открывали дашборды, устанавливали фильтры, что-то смотрели и переходили к другим своим задачам вне Tableau Server, после какого-то времени они возвращались к открытым дашбордам, но они сбрасывались на дефолтный вид, и приходилось заново их настраивать. Наша задача была сделать работу пользователей более комфортной и убедиться, что нагрузка на сервер не возрастает критически.

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

vizqlserver.session.expiry.minimum 5

Number of minutes of idle time after which a VizQL session is eligible to be discarded if the VizQL process starts to run out of memory.

vizqlserver.session.expiry.timeout 30 Number of minutes of idle time after which a VizQL session is discarded.

Поэтому мы решили сделать мониторинг VizQL сессий и отслеживать:

  1. Количество сессий,
  2. Количество сессий на пользователя,
  3. Среднюю длительность сессий,
  4. Максимальную длительность сессий.

Кроме того, нам нужно было понимать, в какие дни и какие часы открывается самое большое количество сессий.

Получился такой дашборд:


Дашборд мониторинга VizQL сессий

C начала января этого года мы стали постепенно увеличивать лимиты и мониторить длительность сессий и нагрузку. Средняя длина сессии увеличилась с 13 до 35 минут это видно на графиках средней длительности сессии. Конечные настройки такие:

vizqlserver.session.expiry.minimum 120vizqlserver.session.expiry.timeout 240

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

Тепловые карты этого дашборда также позволяют нам планировать сервисные работы в часы минимальной востребованности сервера.

Изменение нагрузки на кластер CPU и RAM мы мониторим в Zabbix и AWS console. Значительных изменений нагрузки в процессе увеличения таймаутов мы не зафиксировали.

Если говорить о том, что может сильно нагнуть ваш Tableau сервер, то это может быть, например, неоптимизированный дашборд. Постройте, к примеру, в Tableau таблицу в десяток тысяч строк по категориям и id каких-нибудь событий, а в Measure используйте LOD вычисления на уровне id. С высокой вероятностью отображение таблицы на сервере не отработает, и вы получите вылет с Unexpected Error, поскольку все LODы в минимальной грануляции будут очень сильно потреблять память, и очень скоро процесс упрется в 100% потребления памяти.

Этот пример здесь приведен для того, чтобы было понятно, что один неоптимальный дашборд может съедать все ресурсы сервера, а даже 100 VizQL сессий оптимальных дашбордов не будут потреблять столько ресурсов.

Мониторинг источников данных сервера


Выше мы отмечали, что для Self-Service мы подготовили и опубликовали на сервере несколько источников данных. Все источники экстракты данных. Опубликованные источники сохраняются на сервере, и к ним предоставляется доступ ребятам, которые работают с Tableau Desktop.

В Tableau есть возможность помечать источники как сертифицированные. Так делает команда BI, когда готовит источники данных для Self-Service. Это гарантирует, что сам источник был протестирован.

Опубликованные источники могут достигать 200 млн строк и 100 полей. Для Self-Service это очень большой объем, поскольку не так много компаний имеет источники таких объемов для самостоятельной аналитики.

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

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


Дашборд мониторинга источников

Итог


Мы используем подход Self-Service 1,5 года. За это время 50 пользователей стали самостоятельно работать с данными. Это снизило нагрузку на BI Team и позволило ребятам не ждать, пока BI Team дойдет до конкретно их задачи по разработке дашборда. Примерно 5 месяцев назад мы стали подключать другие направления к самостоятельной аналитике.

В наших планах проведение обучения по data literacy и лучшим практикам визуализаций.

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

Tableau Hyper API BI-команда скажет вам спасибо

28.08.2020 12:23:00 | Автор: admin
Мы хотим рассказать вам о том, как мы помогли нашей BI-команде организовать автоматический процесс доставления данных на Tableau-сервер из MongoDB, используя таблошный формат хранения данных hyper, а сам процесс настройки формирования данных осуществляется через простой веб-интерфейс.

В начале коротко расскажем, как выглядел процесс до и после того, как мы научили наш внутренний продукт А1 программно собирать датасорсы и публиковать их на Tableau Server. Затем подробнее разберем проблему BI-команды и найденное решение, а также заглянем под капот (здесь о создании .hyper файла, публикации файла на tableau-сервере и обновлении хайпера). Добро пожаловать под кат!

Tableau Hyper API BI-команда скажет вам спасибо


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

Жизненный путь данных от сырья до красивых автоматизированных графиков можно условно разбить на 4 шага:
  1. Получение сырых данных
  2. Чистка и доработка данных
  3. Создание источников данных для Tableau
  4. Разработка визуализаций


Было


До того, как мы научились программно генерировать источники данных для Tableau, процесс выглядел так:
Старый жизненный процесс

1. Получение сырых данных
Пользователи формируют табличные-отчеты через внутренний инструмент А1. О нем мы подробнее расскажем далее.

2. Чистка и доработка данных
Возможность трансформации данных также заложена в инструмент А1, после чего очищенные данные можно выгрузить в xslx/csv и продолжить с ними работу вне инструмента. Тут стоит отметить, что некоторые пользователи ограничиваются 1ым пунктом и после выгрузки отчетов дорабатывают данные своими силами.

3. Создание источников данных для Tableau
Раньше заказчики дашбордов приходили с набором экселей, которые они сгенерировали на предыдущих пунктах. А BI-разработчики сводили эти эксели в единый датасорс (таблошный сленг) своими силами. Не всегда удавалось ограничиться только инструментами Tableau, часто писали скрипты на Python.

4. Разработка визуализаций
Наконец, вершина айсберга создание дашборда и публикация его на Tableau Server, где его увидит заказчик. На практике визуализация часто занимает меньше времени, чем сбор данных и настройка обновлений.

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

Стало


Основной задачей было исключить эксели между 2 и 3 шагом. В итоге мы научили А1 собирать датасорсы и публиковать их на Tableau Server. Вот что получилось:
Новый жизненный процесс

Сейчас шаги с 1 по 3 происходят в А1, на выходе BI-команда получает опубликованный на Tableau Server датасорс для разработки визуализаций. Связующим звеном стал Hyper API, о котором дальше и пойдет речь.

Результаты


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

Освободили время BI команды. Раньше было мало шаблонных решений и много кастомизаций. Чаще всего под каждый проект дописывали обработку на Python. В редких случаях, где обработка не нужна была, работали сразу в Tableau Desktop (основной инструмент разработки).
Сейчас подготовка датасорса это: накликать нужные поля в интерфейсе А1, отметить, какие из них разворачиваем в строки (если это необходимо) и опционально заранее определить тип полей.

Не нагружаем Tableau Server обновлением громоздких датасорсов обновление происходит силами А1, а на сервер закачивается уже готовый hyper.

*Бонус стимулируем пользователей работать внутри А1. Если раньше некоторые пользователи после выгрузки сырых отчетов, дорабатывали их вручную вне инструмента, то теперь, так как весь процесс с 1 по 3 шаг происходит в А1, пользователям проще настраивать процесс чистки там же.

Проблема и решение


Немного о А1


Прежде чем мы начнем рассказывать про наше решение, нужно рассказать о нашем внутреннем продукте А1, к которому прикрутили генерацию датасорсов.

А1 это внутренний продукт компании, который призван упростить рабочий процесс сотрудникам, у которых основная работа заключается в следующем:
  • Забирать данные из программных продуктов компании MediaScope
  • Приводить эти данные (чистить) в удобный для аналитиков-предметников вид
  • По необходимости подготавливать данные для создания дашбордов (об этом мы сегодня и поговорим)

После того, как пользователь завершает чистку данных, они хранятся в системе А1. В нашей терминологии это называется Контейнером. Контейнер это обычный документ в MongoDB, который нам и надо передавать на Tableau-сервер.

Проблема BI-команды


Нашей команде BI-разработчиков нужно было как-то получать данные из А1, которые хранились в MongoDB, и на основе полученных данных строить дашборды. В первую очередь мы попробовали забирать данные из MongoDB штатными средствами табло, но проблему это не решало:
  • Поскольку данные хранятся в MongoDB, то на вход в табло поступают данные с произвольной структурой, а это значит, что постоянно пришлось бы заниматься поддержкой данной логики.
  • Для агрегации данных из MongoDB нужно было тащить определенные записи из коллекции, а не коллекцию целиком драйвер Tableau делать это не умеет.
  • Кроме всего прочего, мало было получить данные: иногда их нужно было разворачивать делать unpivot некоторых столбцов в строки. Что тоже не так просто было сделать, от слова совсем.

Что мы придумали


Было принято решение попробовать решить данную задачу своим велосипедом, используя библиотеку Tableau Hyper API. Данная библиотека позволяет создавать файл в формате .hyper, в который легко складывать данные, а потом использовать как источник данных для создания дашборда на табло сервере.

Как описывают хайпер сами разработчики табло:
Hyper это высокопроизводительный in-memory механизм обработки данных, который помогает клиентам быстро анализировать большие или комплексные датасеты, эффективно оценивая запросы в базу данных. Основанная на платформе Tableau, Hyper использует собственные методы динамической генерации кода и передовые технологии параллелизма, позволяющие достигать высокой производительности при создании экстрактов и выполнение запросов.

Примерный процесс работы в нашей программе выглядит следующим образом:
  • Пользователь выбирает контейнеры и нужные колонки
  • Система выдергивает из контейнеров данные
  • По полученным данным система определяет типы колонок
  • Инициализируется создание хайпера и вставка в него данных
  • Загружается хайпер на табло-сервер
  • BI-разработчики видят хайпер на сервере и создает на его основе дашборд

Когда в контейнеры зальют новые данные системе будет подан сигнал, что нужно обновить хайпер:
  • Система скачает с табло-сервера хайпер
  • Заберет из MongoDB свежие данные и обновит хайпер
  • После система загружает на сервер новый хайпер с перезаписью существующего
  • Пользователю достаточно просто нажать на кнопку Refresh, чтобы в дашборде отобразилась актуальная информация


Что видит пользователь


Как уже говорилось ранее, А1 является веб-приложением. Для создания сервиса генерации хайпера на фронте мы использовали Vue.js и Vuetify.

Интерфейс приложения разделен на три экрана.
Экран с выбором контейнеров

На первом экране пользователь выбирает нужные контейнеры и колонки.

Если включена опция Unpivot, то в хайпере будут созданы две дополнительные колонки: variable- наименования колонок, которые выбираются столбцом Metrics и values- значения из этих колонок.

Столбец Dimension добавляет в хайпер колонку с одноименной выбранной колонкой. Количество выбранных колонок Dimensions и их названия должны быть одинаковые во всех контейнерах, чтобы не нарушилась целостность таблицы в хайпере, поэтому присутствует столбец Имя hyper, который позволяет указать имя выбранной колонке, если в контейнерах они называются по-разному.
Логи процесса создания хайпера
На этом процесс настройки хайпера заканчивается. Пользователю достаточно перейти на второй экран, нажать Создать hyper и наблюдать за ходом событий в логах.

Дополнительные настройки

На третьем экране находятся дополнительные настройки:
  • Можно включить игнорирование обновлений, если нам не нужно, чтобы система автоматически обновляла хайпер
  • Можно указать email, на который отправлять отчеты об обновлениях
  • Можно руками указать тип данных для колонки values (используется только при unpivot режиме): float, string или автоматически определять системой (про типы поговорим дальше)
  • Также можно указать типы данных для выбранных колонок у контейнеров.


Что под капотом


А1 написан на Python. Для работы с данными мы используем Pandas, а сами данные мы сериализуем из pandas в pickle и храним в MongoDB GridFS.

Когда поступает команда на создание хайпера, система выполняет следующие операции:
  • Выгружает из MongoDB все необходимые контейнеры и десиреализует данные в датайфремы pandas
  • Производит подготовку данных: оставляет в датафреймах только нужные колонки, дает им новые имена, при необходимости разворачивает таблицы через pandas.melt
  • Если пользователь выставил тип данных у колонок, то произвести конвертацию данных либо во float32, либо в string
  • После всех подготовительных работ с данными система через hyper api создает файл и через tabcmd отправляет файл на табло-сервер.

Стоит немного поговорить о типах данных у колонок. Одной из особенностей хранения данных в контейнерах А1 является то, что пользователи не заморачиваются над тем, какие типы назначать колонкам, за них это прекрасно делает pandas: система спокойно справляется с ситуациями, когда в колонке присутствуют числа и строковые значения. Однако хайперу это не нравится: если сказать ему, что колонка должна иметь тип int, то система ругнется при попытке вставить что угодно кроме целого числа. Поэтому было принято решение использовать в хайперах только два типа данных: string и float.

Итак, с общим принципом работы мы разобрались, давайте поговорим уже про саму работу с hyper.

Создание .hyper файла


Для работы с Hyper API понадобится установить библиотеку, скачать ее можно с официально сайта тут. Там же есть неплохие примеры, как работать с этим инструментом. Мы же кратко укажем основные моменты.

Сам файл хайпера из себя представляет эдакую базу данных, чем-то напоминает SQLite.Через api можно обращаться к данным, используя like SQL синтаксис:
f"SELECT {escape_name('Customer ID')} FROM {escape_name('Customer')}"

Поскольку система у нас написана на Python, то и библиотеку мы будем использовать для соответствующего языка. При создании файла мы должны указать имя схемы, имя таблицы и колонки с типами. Имя схемы и таблицы должны называться Extract, поскольку именно в эту схему с таблицей залезает Tableau Server, чтобы вытащить данные для книжек.

with HyperProcess(Telemetry.SEND_USAGE_DATA_TO_TABLEAU) as hyper:    with Connection(        hyper.endpoint, self.fullpath_hyper, CreateMode.CREATE_AND_REPLACE    ) as connection:        connection.catalog.create_schema("Extract")        main_table = TableName("Extract", "Extract")        example_table = TableDefinition(main_table)

После создания таблицы нам нужно создать колонки и задать типы. Как мы уже говорили ранее, данные у нас имеют только два типа (float или string), поэтому отталкиваясь от того, какой тип стоит у колонок в датафрейме, такой мы и выставляем для колонок:

for column in dataframe.columns:    if dataframe[column].dtype.name in ("category", "object"):        example_table.add_column(TableDefinition.Column(column, SqlType.text()))    elif dataframe[column].dtype.name in ("float32"):        example_table.add_column(            TableDefinition.Column(column, SqlType.double())        )    connection.catalog.create_table(example_table)

После создания таблицы можно и вставить данные:

with Inserter(connection, example_table) as inserter:    for val in dataframe.values:        inserter.add_row(val.tolist())    inserter.execute()

Здесь мы построчно бежим по датафрейму и накапливаем список значениями через inserter.add_row(). На самом деле в апи хайпера есть функция add_rows(), которая принимает список списков и вставляет уже значения. Почему не было так сделано? Ради экономии оперативной памяти: для того чтобы предоставить список списков значений из датафрейма, нужно попросить pandas сделать values.tolist(). А когда у тебя 150 млн строк данных, получается очень дорогая операция для оперативки, при этом на производительности это никак не сказывается (во всяком случае, не было замечено, что из-за итерационного перебора строк как-то просела скорость создания хайпера). Плюс ко всему, add_rows() работает как синтаксический сахар: на деле он принимает список списков и так же итерационно добавляет данные.

На этом создание нашего хайпера заканчивается. Дальше нам нужно опубликовать его на сервере.

Публикация файла на tableau-сервере


Для обращения к tableau-серверу мы будем использовать утилиту tabcmd это консольная утилита, позволяющая подключаться к серверу и выполнять административные функции создавать пользователей, группы, книжки и прочее.

Запускать команду tabcmd будем через питоновский subprocess.Popen:

popen = subprocess.Popen(    f'/opt/tableau/tabcmd/bin/tabcmd publish "{fullpath_hyper}" -n "{filename}" -o -r "A1_test" '    '-s http://tableau.domain.com -u "username" -p "password" --no-certcheck',    shell=True,    stderr=subprocess.PIPE,    stdout=subprocess.PIPE,)return_code = popen.wait()if return_code:    error = str(popen.communicate()[1])    return f"Ошибка сервера во время публикации файла. {error}"

Мы передаем tabcmd следующую команду и ключи:
  • publish: залить файл на сервер
  • -n (--name): какое имя файла будет на сервере
  • -o (--overwrite): если присутствует файл с таким именем, то перезаписать
  • -r A1_test (--project): положить файл в папку (он же проект)
  • -s (--server): адрес tableau-сервера
  • -u -p: логин и пароль для авторизации на сервере
  • --no-certcheck: игнорировать проверку SSL-сертификата

Обновление хайпера


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

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

Чтобы понимать, какие данные из какого контейнера лежат в хайпере, система при создании хайпера также создает дополнительную колонку container_id. При таком подходе обновление становится очень простым:
  • Забираем файл с сервера
  • Удаляем все строки в хайпере, где container_id равняется обновляемому контейнеру
  • Вставляем новые строчки
  • Загружаем обратно на сервер файл с перезаписью.

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

Для того, чтобы забрать файл, мы используем tabcmd:

popen = subprocess.Popen(    f'/opt/tableau/tabcmd/bin/tabcmd get "datasources/{filename_tdsx}" '    f'-s http://tableau.domain.com -u "username" -p "password" '    f'--no-certcheck -f "{fullpath_tdsx}"',    shell=True,    stderr=subprocess.PIPE,    stdout=subprocess.PIPE,)return_code = popen.wait()if return_code:    error = str(popen.communicate()[1])    return f"Ошибка. {error}"

Тут используем следующую команду и ключи:
  • get: забрать с сервера файл. Если на сервере лежит файл test.hyper, то обращаться надо к файлу test.tdsx, а лежат они все в директории datasource (я не смог нагуглить, почему такая особенность работы в табло, если знаете, поделитесь в комментариях )
  • -f (--filename): полный путь, включая имя файла и его расширение, куда надо сохранить файл

После того, как файл будет скачен, его надо разархивировать через zipfile:

with zipfile.ZipFile(fullpath_tdsx, "r") as zip_ref:    zip_ref.extractall(path)

После разархивации хайпер будет лежать в директории ./Data/Extracts.

Теперь, когда у нас есть актуальная версия файла, мы можем удалить из него ненужные строки:

table_name = TableName("Extract", "Extract")with HyperProcess(Telemetry.SEND_USAGE_DATA_TO_TABLEAU) as hyper:    with Connection(hyper.endpoint, self.fullpath_hyper) as connection:        connection.execute_query(            f"DELETE FROM {table_name} WHERE "            f'{escape_name("container_id")}={container_id}'        ).close()

Ну а вставка и публикация файла были уже описаны выше.

Заключение


Что в итоге? Проделав работу по внедрению генерации hyper-файлов и автоматической доставки их на tableau-сервер, мы в разы снизили нагрузку на BI-команду, данные в дашборде обновлять стало проще и, самое главное, быстрее. Само знакомство с hyper api не было болезненным, документация неплохо написана, а сама интеграция технологии в нашу систему прошла легко.

Благодарим за внимание! Если у вас есть вопросы или замечания, пожалуйста, оставляйте их в комментариях.

Статья написана совместно с Василием Лавровым (VasilyFromOpenSpace) Старшим разработчиком бизнес-аналитики
Подробнее..

Рейтинг знаков зодиака среди Великих людей мира

20.10.2020 20:09:53 | Автор: admin
Однажды мы размышляли о рейтинге знаков зодиака среди Великих людей. Задачу выполнили и представляю результаты на ваш суд.
Со скорбью замечу, что Весы (ЭТО Я!) на последнем месте Хотя что-то по данным мне кажется, что есть аномалии. Как-то подозрительно мало Весов!



ЧАСТЬ 1. Парсинг и получение исходных данных:
Wikipedia List of lists of lists
на выходе нужна база с ФИО + дата рождения + (если есть любые другие признаки например м/ж, страна и тд)
есть API

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

В других случаях парсили успешно вот так
Результат: файл BD wiki.zip

ЧАСТЬ 2. О препроцессинге (выполнил Станислав Костенков контакты ниже).
Многие сталкиваются со сложностью обработки входных данных. Так в данной задаче нужно было вытащить из более 42 тысяч статей данные о рождении и по возможности определить страну рождения. С одной стороны, это простая алгоритмическая задача, с другой стороны, средства Excel & BI систем не позволяют это выполнить в лоб.
В такой момент на помощь приходят языки программирования (Python, R), запуск которых предусмотрен в большинстве BI систем. Стоит отметить, что, например, в Power BI существует лимит в 30 минут на выполнение скрипта (программы) на языке Python. Поэтому многие тяжелые обработки делают до запуска BI систем, например, в озере данных.

Как решалась задача.
Первое, что сделал после загрузки и проверки на некорректные значения, было превратить каждую статью в список слов.
В этой задаче, мне повезло с языком, английским. Этот язык характеризует жесткая форма построения предложения, что значительно облегчило поиск даты рождения. Ключевое слово здесь born, затем смотрится и анализируется что находится после него.
С другой стороны, все статьи были взяты из одного источника, что тоже облегчило задачу. Все статьи имели примерно одинаковую структуру и обороты.
Далее, все года имели длину в 4 символа, все даты имели длину 1-2 символа, месяцы имели текстовое представление. Было всего 3-4 возможных вариации написания даты рождения, что решалось простой логикой. Также можно было бы анализировать через регулярные выражения.
Настоящий код неоптимизирован (такой задачи не ставилось, может быть есть огрехи в наименованиях переменных).
По предсказанию страны, мне повезло найти таблицу соответствия стран и национальностей. Обычно в статьях описывается не страна, а принадлежность к ней. Например, Russia russian. Поэтому производился поиск вхождений национальностей, но в виду, что в одной статье, могло быть более 5 разных национальностей, то я сделал гипотезучто нужное слово будет самым ближайшим из всех возможных к ключевому слову burn. Таким образом, критерий был минимальное индексное расстояние между нужными словами в статье. Потом одной строкой делалось переименование из национальности в страну.

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

Немного слов о полезности препроцессинга при очистке данных.
Есть банальные случаи, когда мы можем точно предположить, что должно быть на месте пропусков. Но есть случаи, например, есть пропуски по гендерному признаку покупателя магазина и есть данные о его покупках. Стандартных приемов по решению этой задачи не существует в системах BI, но в тоже время, на уровне препроцессинга можно создать легкую модель и посмотреть различные варианты заполнения пропусков. Существуют варианты заполнения, основанные на простых алгоритмах машинного обучения. И это стоит использовать. Это не трудно.
Исходный код (Python) доступен по ссылке
Результат: файл out_data_fin.xls
Станислав Костенков / Компания Си-Би-Эс Консалтинг (Ижевск, Россия) staskostenkov@gmail.com

ЧАСТЬ 2. Приложение Qlik Sense.
Дальше было сделано классическое приложение, где и выявились некие аномалии с датасетом:
имело смысл выбирать только декады с 1920-1980;
в разных странах были разные лидеры по знакам гороскопа;
топ знаков: Рак, Овен, Близнецы, Телец, Козерог;

Все данные (дата-сет, исходные данные, полученное приложение Qlik Sense для анализа данных) лежат по ссылке





Подробнее..

Recovery mode Рейтинг знаков зодиака среди Великих людей мира

21.10.2020 00:21:19 | Автор: admin
Однажды мы размышляли о рейтинге знаков зодиака среди Великих людей. Задачу выполнили и представляю результаты на ваш суд.

Со скорбью замечу, что Весы (ЭТО Я!) на последнем месте Хотя что-то по данным мне кажется, что есть аномалии. Как-то подозрительно мало Весов!



Часть 1. Парсинг и получение исходных данных


Wikipedia List of lists of lists
на выходе нужна база с ФИО + дата рождения + (если есть любые другие признаки например м/ж, страна и т.д.) есть API.

Данный сайт получилось поскрапить (харвестинг / получение / экстракт (извлечение) / сбор данных полученных с web-ресурсов) сайт при помощи Python библиотеки Scrapy.

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

В других случаях парсили успешно вот так.

Результат: файл BD wiki.zip

Часть 2. О препроцессинге (выполнил Станислав Костенков контакты ниже)


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

В такой момент на помощь приходят языки программирования (Python, R), запуск которых предусмотрен в большинстве BI систем. Стоит отметить, что, например, в Power BI существует лимит в 30 минут на выполнение скрипта (программы) на языке Python. Поэтому многие тяжелые обработки делают до запуска BI систем, например, в озере данных.

Как решалась задача


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

В этой задаче, мне повезло с языком, английским. Этот язык характеризует жесткая форма построения предложения, что значительно облегчило поиск даты рождения. Ключевое слово здесь born, затем смотрится и анализируется что находится после него.

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

Далее, все года имели длину в 4 символа, все даты имели длину 1-2 символа, месяцы имели текстовое представление. Было всего 3-4 возможных вариации написания даты рождения, что решалось простой логикой. Также можно было бы анализировать через регулярные выражения.
Настоящий код неоптимизирован (такой задачи не ставилось, может быть есть огрехи в наименованиях переменных).

По предсказанию страны, мне повезло найти таблицу соответствия стран и национальностей. Обычно в статьях описывается не страна, а принадлежность к ней. Например, Russia russian. Поэтому производился поиск вхождений национальностей, но в виду, что в одной статье, могло быть более 5 разных национальностей, то я сделал гипотезучто нужное слово будет самым ближайшим из всех возможных к ключевому слову burn. Таким образом, критерий был минимальное индексное расстояние между нужными словами в статье. Потом одной строкой делалось переименование из национальности в страну.

Что не делалось


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

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

Немного слов о полезности препроцессинга при очистке данных


Есть банальные случаи, когда мы можем точно предположить, что должно быть на месте пропусков. Но есть случаи, например, есть пропуски по гендерному признаку покупателя магазина и есть данные о его покупках. Стандартных приемов по решению этой задачи не существует в системах BI, но в тоже время, на уровне препроцессинга можно создать легкую модель и посмотреть различные варианты заполнения пропусков. Существуют варианты заполнения, основанные на простых алгоритмах машинного обучения. И это стоит использовать. Это не трудно.
Исходный код (Python) доступен по ссылке
Результат: файл out_data_fin.xls

Станислав Костенков / Компания Си-Би-Эс Консалтинг (Ижевск, Россия) staskostenkov@gmail.com

Часть 3. Приложение Qlik Sense


Дальше было сделано классическое приложение, где и выявились некие аномалии с датасетом:

  • имело смысл выбирать только декады с 1920-1980;
  • в разных странах были разные лидеры по знакам гороскопа;
  • топ знаков: Рак, Овен, Близнецы, Телец, Козерог.

Все данные (дата-сет, исходные данные, полученное приложение Qlik Sense для анализа данных) лежат по ссылке.





Подробнее..

Что под капотом у BI? Детальный разбор технологии In-Memory OLAP

29.12.2020 16:19:06 | Автор: admin
Привет, Хабр! Меня зовут Иван Вахмянин, и сегодня я хочу рассказать о том, что находится под капотом у современной BI-системы, от чего зависит ее производительность (и как можно её ненароком убить), и какие технические оптимизации позволяют технологии In-Memory OLAP выигрывать по скорости у других подходов.




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

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

Когда мы только начинали работать в сфере BI 5 лет назад, в основу продукта Visiology легла open-source библиотека Pentaho Mondrian. Но достаточно быстро мы столкнулись с проблемами по части производительности и начали самостоятельно разрабатывать In-Memory OLAP движок под названием ViQube (об этом можно почитать в другой нашей статье Как разработать BI-платформу наш трудный, но интересный опыт). Собственно, в процессе этой разработки мы и накопили опыт, которым сейчас хотим поделиться.

Как работает OLAP


На первый взгляд, все BI-платформы выглядят одинаково: у вас есть источники информации, у вас есть инструменты загрузки, анализа и визуализации данных, а на выходе пользователь получает разнообразные отчеты от печатных форм до дашбордов, в том числе на мобильных, на видеостенах, на любых устройствах. В своей основе все BI-инструменты используют модель данных на основе OLAP (On-Line Analytical Processing, многомерное представление данных), но техническая реализация OLAP движка (который непосредственно занимается вычислениями) может быть реализован по-разному, и от этого очень сильно зависит производительность и масштабируемость системы.



MOLAP

Технология OLAP возникла ещё в 80-х годах. В то время процессоры были намного медленнее, да и память была в дефиците, поэтому чтобы аналитик мог реально работать с данными в онлайн-режиме, придумали такую вещь как MOLAP (Multidimensional OLAP). Идея подхода в том, что для всего многомерного куба после загрузки данных производится предрасчет: на узлах иерархий предварительно рассчитываются агрегации, чтобы под любой более или менее типовой запрос пользователя можно было получить результат запроса без необходимости пересчитывать все строки. Да, при любом изменении данных нужно долго пересчитывать куб, а объем рассчитанного куба может быть в разы больше исходного датасета, но в то время других вариантов не было. MOLAP до сих пор существует и используется, например, в SQL Server Analysis Services, но на практике его используют все реже и реже.

ROLAP

Позже появилась реляционный OLAP, или ROLAP. Отличие от MOLAP заключается в том, что не происходит никакого предварительного расчёта агрегаций, а вычисления происходят на СУБД из бэкэнда BI-платформы. В этом случае пользователь работает с удобными инструментами, например, с конструктором дашбордов, а под капотом ROLAP-движок преобразует его запросы на лету в SQL, и они просто выполняются на какой-то СУБД.



Подобный подход характерен, например, для таких open-source систем, как Pentaho или Metabase или проприетарного SAP Business Objects, Oracle OBIEE.

У ROLAP есть целый ряд недостатков. Во-первых, если, не использовать на бэкенде специальные аналитические СУБД, такие как ClickHouse или Vertica, все будет работать ооочень медленно (дальше будет понятно, почему). Во-вторых, даже при использовании аналитической СУБД, при работе с ROLAP очень неэффективно используется кэш, потому что СУБД и BI-платформа работают отдельно друг от друга. В-третьих, поскольку не все аналитические задачи можно завернуть в SQL-запрос, ограничивается аналитическая функциональность. Но зато, на сегодняшний день ROLAP это единственный способ работы с реально большими объемами данных, которые не помещаются в память.

In-Memory OLAP

Если речь идет о работе с данными объемом до терабайта, как правило, используется схема In-Memory. Данные постоянно находятся в памяти, и за расчеты отвечает специальный движок. В системах Qlik это QIX, Power BI использует SQL Server Tabular Engine, который раньше был продуктом xVelocity, но Microsoft купил эту компанию, и теперь движок является частью MS SQL Server. У нас в Visiology движок In-Memory OLAP называется ViQube.

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



При этом у подхода In-Memory есть и свои недостатки. И главный из них это предел емкости памяти. Если объем данных измеряется в терабайтах, вам нужно либо строить дорогой кластер, либо склоняться к ROLAP. Кроме этого, при таком подходе не всегда удается минимизировать задержку отображения обновлений, потому что для этого данные приходится перегружать из источника в память.

Гибридный OLAP

Основной схемой работы для большинства промышленных BI становится гибридная схема с одновременным использованием и In-Memory OLAP, и реляционного OLAP-движка. Горячие данные хранятся в In-Memory, холодные данные, которые не влезли в заданный объем, в СУБД. Такое решение в QlikView, например, называется Direct Discovery, в Power BI Direct Query. В Visiology тоже поддерживаются интеграции с несколькими СУБД, в том числе с ClickHouse.



Кстати, выбор СУБД для гибридного режима также критически важен. Если мы будем работать с PostgreSQL, в котором лежит 5 терабайт данных, аналитические запросы будут исполняться крайне медленно. И если у вас не SAP HANA, придется вручную распределять данные на холодные и горячие. Как следствие, не все аналитические функции будут доступны на полном объёме данных. Но если памяти не хватает, увы, с таким положением дел приходится мириться.

Откуда растут плюсы In-memory OLAP?



Для скорости работы In-Memory OLAP есть как очевидные, так и скрытые причины. Тот факт, что работа движка происходит в памяти, а она намного быстрее, чем жесткий диск (спасибо, кэп) это только 1/10 правды. Но давайте подумаем, как работают реляционные СУБД, например, тот же PostgreSQL. Ведь он в какой-то мере тоже является In-Memory. И вообще, любая современная СУБД активно использует как блочный кэш в памяти, так и внутренний.



Когда обычной дисковой СУБД, такой как PostgreSQL, нужно считать данные с жёсткого диска, она обращается к накопителю и считывает какую-то страницу. Эта страница помещается в блочный кэш (в Linux он располагается в свободном пространстве памяти). Допустим, у нас есть 128 гигабайт памяти, и 20 из них мы занимаем софтом. Всё остальное может использоваться под блочный кэш. И если СУБД нужно будет считать с этой страницы ещё что-нибудь, она возьмет эту информацию из памяти. И от того, насколько эффективно используется кэш, зависит производительность. Если для анализа используется, скажем, 30-40 гигабайт данных, мы можем расширить емкость оперативной памяти на сервере и уже после первого чтения СУБД все данные окажутся In-Memory, а обращения к диску на чтения будут происходить лишь эпизодически.



Кроме этого, у умных СУБД, в том числе у Postgres, имеется механизм cache-aware управления. Они могут выбирать, что складывать в кэш, а что нет, какие данные надо заново прочитать с диска.


Источник: www.enterprisedb.com/blog/autoprewarm-new-functionality-pgprewarm

На графике выше влияние прогрева кэша на производительность PostgreSQL. Жёлтым показана производительность в зависимости от времени, и наглядно видно, что по мере работы пользователей СУБД считывает данные, постепенно раскладывает всё в In-Memory и достигает предела своей производительности. Если же использовать prewarm и дать Postgres команду поднять все данные в память сразу, максимальная производительность достигается сразу.

Также стоит учитывать, что мы говорим об аналитической нагрузке. Она очень сильно отличается от транзакционных задач, когда в базу нужно внести запись о покупке в интернет-магазине или считать 10 строк с историей заказов. На графике ниже показан типовой аналитический запрос из теста TPC-H. Этот тест состоит из нескольких десятков реальных аналитических запросов и широко используется для нагрузочного тестирования.


Источник: www.tpc.org/information

В SQL-запросе из теста TPC-H можно найти много чего интересного. Во-первых, запрос идет не на поля, а на агрегации. Во-вторых, здесь присутствуют линейные арифметические операции. В-третьих, здесь часто встречаются фильтры по полям с малой кардинальностью: регионы и федеральные округа, в которых работает компания, типы клиента активный, неактивный и так далее. В-четвертых, часто используются фильтры по полю с датой. Если мы изучаем динамику выручки, то нас интересуют такие периоды как год или квартал.

На входе подобного запроса всегда очень большое количество строк миллионы или даже миллиарды. Поэтому СУБД вынуждена делать серию полных сканирований. С другой стороны, на выходе получается небольшое количество строк, ограниченное количеством точек, которые можно отобразить на графике чаще всего десятки или сотни значений. Зная эти особенности аналитических запросов, можно провести оптимизацию и получить прирост производительности.

In-Memory OLAP: конкретные примеры оптимизации для BI


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

1. Колоночное хранение данных

Это первый шаг, дающий заметный эффект. Для обычных транзакционных запросов хранение в строках подходит оптимально. Но для аналитики необходимо получать данные по столбцам. Казалось бы, какая разница, ведь все это уже In-Memory? Но на практике кроме памяти, которая быстрее дисков, у нас также есть кэш процессора, как правило, трехуровневый. Он работает намного быстрее, чем память, доступ к которой занимает примерно 200 тактов процессора.



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


Источник: arstechnica.com/gadgets/2002/07/caching/2

2. Сжатие

В этой оптимизации есть свои особенности. Для дисковых СУБД это обязательная оптимизация. Здесь мы выигрываем за счет того, что реже ходим в медленное хранилище, но также проигрываем, потому что данные надо распаковать, а это вычислительно ёмкая операция. Для дисковых СУБД получается очень выгодно, для In-Memory все не так очевидно, потому что читать из памяти обычно быстрее, чем заниматься распаковкой.


Источник: www.percona.com/blog/2016/03/09/evaluating-database-compression-methods

Самый быстрый из алгоритмов сжатия по скорости распаковки LZ4. Он в среднем уменьшает размер всего в 2 раза, но зато очень быстро распаковывает, со скоростью порядка 500 мегабайт в секунду на ядро процессора. В бенчмарке на графике LZ4 вообще показал результат 3 гигабайта данных в секунду. Такая скорость дает очень хороший выигрыш для дисковых СУБД, скорость чтения для которых те же 500 мегабайт в секунду. Но для памяти скорость передачи данных составляет десятки гигабайт в секунду, получить преимущество за счёт LZ4 оказывается сложно.

Однако не стоит забывать, что мы чаще всего работаем с данными низкой кардинальности. Например, в строке с названиями торговой точки очень часто будут повторяться одни и те же значения или их ID: Москва, Москва, Москва, Москва


Источник: Guassian and speckle noise removal from ultrasound images using bivariate shrinkage by dual tree complex wavelet transform (Professor G R Sinha, 2015)

Для подобных данных есть ещё один алгоритм, который называется Run-length encoding. Он работает очень просто: строки типа ААААВВВВВСС он сжимает в виде 4A5B2C. Это прекрасный подход для данных с низкой кардинальностью, он помогает экономить память и оптимальнее использовать кэш процессора.

3. Векторные инструкции

Чтобы сложить 2 числа, мы кладём в один регистр процессора одно число, а в другой регистр другое. Для ускорения этого процесса существуют векторные регистры и векторные операции (SIMD Single Instruction Multiple Data). Они позволяют за одну операцию сложить сразу N чисел. Это уже очень зрелая технология, которая появилась в процессорах еще в 1993 году. Она поддерживалась еще в Pentium MMX (166 МГц у меня такой был, до сих пор помню, как на него термопасту намазывал).


Источник: www.codetd.com/en/article/9633503

В Pentium MMX векторных регистров было 8, и они были рассчитаны только на целочисленную арифметику. На текущий момент практически во всех процессорах есть 128-битные регистры SSE и наборы инструкций. Регистры AVX уже 256-битные, а в серверах есть даже AVX 512. Они работают с числами с плавающей запятой, и их можно использовать для оптимизации аналитической нагрузки.


Источник: technews.tw/2020/07/16/linus-torvalds-avx-512-critique

При работе с AVX 512 мы можем обрабатывать в одном регистре 16 чисел со стандартной точностью. Теоретически тут можно получить хороший выигрыш, но для этого необходимо преодолеть ряд технических сложностей. Чтобы при компиляции оптимизация работала, нужно предусмотреть ее при написании кода. Для этого используются интринсики особый набор функций, которые в явном виде указывают компилятору, какие инструкции процессора нужно использовать.

Вот пример, как для расчёта скалярного произведения используется AVX-инструкции 256-битных регистров.



На нашей практике использование именно AVX даёт от 1 до 10% прирост производительности, в зависимости от задач. Когда вы используете современную BI-систему, в зависимости от конкретного процессора, система будет применять разный код. Производительность от этого увеличивается, но не драматически, а в лишь в небольших пределах.

4. Поздняя материализация

Материализация это процесс формирования результата, ответа на запрос. Например, простой SQL-запрос SELECT C1, С2, D1, D2 из 2 таблиц, получит 2 поля из одной и 2 поля из другой таблицы. Далее мы соединяем их по ключу С1=D1.



В случае ранней материализации мы получаем 4 колонки и работаем с колоночной базой. То есть мы сначала берём С1 и С2, соединяем их в таблицу. Потом делаем то же самое с D1, D2 и после этого выполняем Join, то есть формируем строки из этих 2 таблиц, для которых истинно условие С1=D1.

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

При поздней материализации мы сначала разбираемся, что и в какой колонке нам нужно. Сначала выполняется операция JOIN С1 = D1, и мы выбираем нужные нам значения только из правой таблицы. Это можно сделать за один проход. А после этого можем взять из таблицы С только те поля, строки которых после JOIN остались. В итоге не нужно создавать большую промежуточную таблицу.

Конечно, такая оптимизация не сработает на любой нагрузке. Исследования Vertica, например, показывают, как многопрофильная СУБД позволяет выбирать различные стратегии материализации, в зависимости от задач. Но именно для BI характерна нагрузка, связанная с поздней материализацией, поэтому ее использование предпочтительно.

5. Эвристические оптимизации

In-Memory OLAP чаще всего является неотъемлемой частью BI-платформы, а BI-платформа прекрасно знает, какие данные в нее загружаются, как пользователь с ними работает. Конечно, это неочевидные вещи, они происходят под капотом BI-системы и не всегда даже видны, но позволяют получить хороший прирост производительности.

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

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

6. Сортировка по календарю

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

7. Разделяемый кэш

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

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

8. Обратный индекс

Многие BI-системы выстраивают обратный индекс для строковых полей. Он позволяет ускорить поиск с операторами по строкам. И хотя BI-системы и OLAP движок In-Memory это не замена полнотекстовому поиску, подобные оптимизации встречаются достаточно часто.

Каков эффект?


Все перечисленные меры помогают сделать BI-систему, основанную на In-Memory OLAP, более устойчивой и производительной, не прибегая к гибридным схемам работы с подключением реляционных БД. Рост производительности сильно зависит от используемых задач, но в процессе работы над ViQube мы убедились в том, что оптимизации лучше всего закладывать на этапе исходного кода и изначально проектировать систему с учетом особенностей аналитических запросов.

Кроме этого, на своем опыте мы нашли ряд кейсов, которые позволяют легко убить производительность In-Memory OLAP. Можно считать этот набор вредных советов пасхалочкой для тех, кто дочитал до конца :)

5 способов убить производительность In-Memory OLAP


BI-система, работающая на базе In-Memory OLAP, уже по определению имеет высокую производительность однако она не будет неубиваемой! Ниже список из 5 вредных советов по In-Memory, выстраданных на своей шкуре в процессе разработки движка ViQube и его использования в реальных проектах.

1. Сложные вложенные выражения


Прекрасными убийцами производительности In-Memory систем являются запросы, в которых плохо работает векторизация. Любые вычисления с использованием нелинейных функций, которые задействуют много полей, приводят к радикальному снижению скорости работы системы.

Очень часто в своей практике я сталкивался с тем, что аналитик пишет какое-то выражение на Qlik Expressions или на DAX в Power BI, которое хорошо работает, когда в базе 10 тысяч строк. Но по мере роста масштабов производительность начинает деградировать невероятными темпами.

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

2. Вложенные запросы


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

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

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

3. Частое обновление данных


Частое обновление данных не так страшно, если вы используете специальные инструменты для работы в режиме Real-time. Для чего? Почему BI-платформа In-Memory OLAP не очень любят Real-time и для Real-time предлагают, по сути, отдельные инструменты. В Power BI, например, Streaming Dataset. Зачем это сделано? Почему просто не дописывать и не считать заново?

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

Частая инвалидация ведёт к деградации производительности BI-системы, и это особенно заметно, если одновременно BI-система обрабатывает тысячи запросов. Как правило, большинство пользователей работают с готовыми дашбордами, для которых кэш основной источник оптимизации. Когда мы проводили нагрузочное тестирование для профиля пользователя, который просто работает с дашбордом, 90-95% запросов в принципе не доходили до движка и обслуживались из кэша. Именно поэтому частая инвалидация ведет к падению производительности в 10 и более раз.

4. Маленький запас свободной памяти


Иногда кажется, что для работы системы неважно, сколько имеется свободной оперативной памяти, лишь бы хватало общей емкости. Но на самом деле свободная память используется для буферного кэша. Можно сказать, что для In-Memory движков это не так критично, потому что они не так часто работают с жёстким диском. Но в те моменты, когда он поднимает данные, использует snapshot, сохраняет или загружает что-то, наличие буферного кэша оказывается очень даже важным фактором. К тому же, помимо In-Memory движка в любой BI есть и другие части системы, например, компоненты ОС. И если память кончится, они начнут резко тормозить, потому что не смогут использовать буферный кэш.

Но и это еще не все. Нехватка свободной памяти ведет к рискам просадки производительности в сложных запросах. Когда происходит создание больших объемов промежуточных данных, они тоже могут вытеснить буферный кэш, не позволяя использовать его. Что ещё хуже, такие запросы могут достичь предела доступной памяти, и вся система упадёт в swap. Это будет полный коллапс с точки зрения производительности.

5. Строковые поля с высокой кардинальностью


Последний вредный совет загружать строковые поля с высокой кардинальностью. Добавляя к датасету комментарии к заказам, сообщения из чата или что-то подобное, можно сильно просадить производительность. То, что хорошо подходит для полнотекстового поиска, плохо работает для движков In-Memory OLAP. Такие данные не дают использовать RLE, векторные инструкции. Здесь мы снова падаем в выполнение строковых операций, производительность для которых намного меньше, чем для арифметических. BI-система в принципе не всегда может создать индекс на такие строковые поля со всеми вытекающими последствиями.

Да пребудет с вами производительность


Как я уже говорил, In-Memory OLAP это продвинутая и умная технология, которая, чаще всего, просто работает и позволяет не задумываться о том, что внутри у BI-платформы. Но, исключения из правил случаются, и, я надеюсь, что эта статья поможет быть к ним готовым.

Всех с наступающим, и отличной производительности всем вашим сервисам в Новом Году! :)
Подробнее..

Как селф-сервис BI убивает кровавый энтерпрайз

15.02.2021 10:17:19 | Автор: admin

Привет, меня зовут Владимир Шилов, я руководитель направления в департаменте анализа данных Ростелекома. В мае 2019 года я пришёл в команду Business Intelligence (BI) и одной из первых задач была реализация отчётности по анализу посещаемости отчетов во всех BI-инструментах, установленных в компании.

Решение этой задачи позволило собрать любопытную статистику и сделать выводы о востребованности BI-инструментов в Ростелекоме. В этой статье я хочу поделиться следующими результатами нашего анализа:

Какие BI системы наиболее востребованы в реалиях крупной компании;
Какие критерии влияют на внутреннюю популярность решения;
Какие современные тенденции пользовательского поведения можно наблюдать внутри компании и какие вопросы будут стоять перед ИТ-подразделениями в ближайшее время.

С чего всё началось: реализация решения по анализу используемости BI систем

Начну с общего описания ситуации и подходов к сбору информации. У нас в компании целевыми BI-системами являются:

1. Oracle BI
2. Microsoft analysis services
3. Microsoft Power BI
4. Qlik Sense
5. Форсайт

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

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

1. Провести анализ логов BI-систем по запуску отчётов;
2. Спроектировать модель витрины данных;
3. Разработать ETL;
4. Реализовать отчет в Power BI;

Решение получилось примерно следующим:

Числа в зелёных стикерах обозначают общее количество инсталляций, в синих количество self-service инсталляций.Числа в зелёных стикерах обозначают общее количество инсталляций, в синих количество self-service инсталляций.

Очевидно, что любая разработка в крупной компании с некоторой бюрократией превращается в нечто большее, чем просто Возьми и сделай! Ты же мужик! и выполнение простого алгоритма из четырёх шагов. Я довольно сильно погряз в разработку архитектурного решения и согласования его с архитекторами, а также предоставления доступов к логам и ETL. В этой статье описывать свои трудности я детально не буду и сконцентрируюсь на конечном результате.

Для начала предлагаю рассмотреть каждый BI-инструмент в отдельности.

Oracle BI

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

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

Analysis services

Microsoft Analysis services в компании это тоже достаточно распространённый инструмент, что во многом обусловлено удобной для пользователей работой в Excel. Именно этот инструмент получил наибольшее распространение в компании: он даже более популярен в МРФ (макрорегиональных филиалах), чем в корпоративном центре. Это можно увидеть на следующей диаграмме по уникальным пользователям в разрезе территорий за последние 12 месяцев:

Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных OLAP-кубов за период;
Количество уникальных пользователей.

Рост количества используемых OLAP-кубов за последний год не наблюдается, а рост аудитории в BI-системе нестабильный со значительными всплесками. У такой статистики несколько причин:
OLAP-кубы в основном дорабатываются, а новые кубы появляются очень редко;
BI-система больше предназначена для аналитиков, умеющих работать с данными, и она сложно продается широкой аудитории;
Доступ к отчётности требует согласования с владельцем OLAP-куба.

Power BI

BI-система Power BI от Microsoft появилась самой последней в стеке инструментов компании, но именно к этой системе сейчас приковано самое большое внимание со стороны бизнеса по следующим причинам:
Базовый набор визуализаций имеет хороший дизайн;
Лицензирование осуществляется по ядрам на сервере, отсутствует лицензирование по пользователям;
Скорость разработки отчётов довольно высокая, но стоит отметить, что на полный цикл разработки это не сильно влияет.

Ниже представлены динамики показателей аудитории и количество отчётов, которые она использует:

Стоит отметить, что при относительно низком росте количества используемой отчётности аудитория продолжает расти. Это связанно в большей степени с тем, что доступ к отчётам предоставляется без выделения лицензий на каждого пользователя и изначально нет никаких ограничений по доступу, то есть оформлять заявку не нужно. Уже сейчас наблюдается тенденция перевода отчетов с Qlik sense на Power BI именно потому, что новые пользователи подключаются бесплатно.

Qlik sense

Qlik sense была первой корпоративной BI-системой с возможностью реализации полноценных дашбордов. Именно с Qlik sense связан переход от предоставления табличных данных к графическим визуализациям в компании.
Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных отчётов за период;
Количество уникальных пользователей.

Казалось бы, перед нами современный BI-инструмент с высоким спросом, в котором можно создавать красивые решения, но сильного роста отчётности по сравнению с Oracle BI и Analysis services мы не наблюдаем. Тут есть несколько причин, влияющие на аудиторию и количество новых отчётов:
Лицензия на одного пользователя стоит существенных денег, и поэтому бизнес отказывается заказывать отчетность в Qlik sense;
Длительный период реализации отчётов от подготовки данных до реализации не позволяет быстро перенести все бизнес-процессы на новый инструмент.

Теперь поговорим про инструменты Self-service.

Self-service инструменты

Qlik sense self-service

В ноябре 2019 для бизнеса мы развернули self-service и предложили бизнесу реализовывать свои отчеты на своих источниках самостоятельно. С точки зрения лицензирования было одно изменение разработчики лицензируются отдельно. С лицензиями пользователей изменений не было по причине того, что сервера были объединены в один кластер и лицензии, соответственно, тоже.
Графики динамик количества запускаемых отчётов и уникальных пользователей в недельной динамике представлены ниже:

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

Power BI self-service

Вот мы и дошли к самому интересному. Power BI self-service появился примерно в то же самое время, что и Qlik Sense self-service, но у данных систем есть одно существенное отличие в лицензировании. Для подключения команды разработчиков от бизнеса в Power BI self-service надо разово заплатить за лицензию на 2 ядра, что примерно равняется 35 лицензиям пользователей в Qlik sense, но лимита на пользователей в Power BI нет.

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

Ещё более наглядно всё выглядит если показать все рассматриваемые системы вместе:

Какие критерии влияют на развитие отчетности?

В части развития отчетности в BI-системах стоит выделить следующие особенности, которые описаны в таблице:

Свойство\BI-система

Power BI

Power BI self-service

Qlik sense

Qlik sense self-service

Analysis services

Oracle BI

Лицензирование

Бесплатно для бизнеса

Лицензия на 2 ядра на одну команду разработки. Для пользователей бесплатно.

Лицензия на каждого пользователя

Лицензия на каждого пользователя и разработчика

Бесплатно для бизнеса

Бесплатно для бизнеса

Вид визуализации

Дашборды

Дашборды

Дашборды

Дашборды

Excel таблицы

Табличные отчеты без аналитики

Требования к квалификации BI-разработчика

Низкие

Низкие

Средние

Средние

Средние

Выше среднего

Качество дизайна базовых визуализаций

Высокое

Высокое

Среднее

Среднее

Отсутствует

Низкое

Процесс подготовки данных

Централизованное хранилище

Собственные источники

Централизованное хранилище

Собственные источники

Централизованное хранилище

Централизованное хранилище

Предоставление доступа

Все отчеты публичные

Все отчеты публичные

По согласованию владельца лицензий

По согласованию владельца лицензий

По согласованию владельца куба

По согласованию владельца области предметной области

Исходя из результатов нашего анализа именно критерии, описанные в таблице, оказали самое большое влияние как на скорость создания новой отчетности, так и на востребованность отчетности пользователями компании. А ключевым фактором успеха Power BI self-service стала политика лицензирования и его условная бесплатность для разработчиков на стороне бизнеса.

Заключение

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

Если бизнесу предоставить возможность самостоятельно заниматься подготовкой данных или предоставить доступ к уже подготовленным данным и дать простой и дешевый инструмент для анализа, то бизнес очень быстро начнёт самостоятельно удовлетворять свои потребности в аналитике данных. При таком подходе остаётся много открытых вопросов: Кто будет сопровождать отчёты и данные в них?, Каким отчётам можно доверять?, Как сделать единую систему отчётности с общей навигацией в едином стиле?.

Несмотря на то, что у ИТ сейчас нет однозначных ответов на эти вопросы, очевидно, что бизнес уже сделал свой выбор в пользу Self-service инструментов, и на эти вопросы нам придется отвечать. Будем рады присоединиться к обсуждению в комментариях. О том, какие решения мы нашли для self-service контура Ростелекома мы расскажем вам в наших будущих статьях.

Статья подготовлена командой управления данными Ростелекома

Подробнее..

Обзор современных инструментов дата-аналитика

16.02.2021 18:22:34 | Автор: admin
image

Сразу уточню, что видов аналитиков очень много, так как анализировать можно все что угодно. Это и веб-аналитики, и классические data scientists, и бизнес-аналитики, и финансовые аналитики, а также продуктовые, системные и UX аналитики. Причина такого разнообразия, по-видимому, в том, что в ряде крупных компаний над созданием одной платформы или продукта одновременно могут работать десятки, а то и сотни программистов и аналитиков. В таких условиях происходит сильное сужение специализации.

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


1. Языки программирования



Не будем касаться исключительных, уникальных или редких случаев. Рассмотрим все только самое популярное. И конечно же, в первую очередь, это язык python.

Python
Python служит главным инструментом в руках data scientists, не имеет строгой типизации и предназначен для быстрой разработки прототипов или написания коротких сценариев или скриптов. Люди разбирающиеся в программировании и computer science его часто критикуют за то, что алгоритмы написанные на чистом python оказываются не оптимальными в отношении своей производительности и требованиям к памяти.
Но тем не менее у данного языка программирования есть много плюсов. Среди них я бы отметил то, что python преподают уже практически везде, в связи с чем сравнительно легко найти аналитика знающего python. Второе преимущество это библиотеки для работы с данными и машинного обучения, имеющие удобный интерфейс. Например, на основе библиотеки sklearn легко собирать конвейеры предварительной обработки данных и построения моделей. Все алгоритмы и настройки машинного обучения инкапсулированы внутри классов и объектов, что делает код очень простым.

R
До недавнего времени основным конкурентом python был язык R. Пожелания к знанию R и сейчас изредка встречаются в описаниях вакансий по крайней мере в разделе преимущества. До середины 2018-го года я и сам программировал на R. И при попытке автоматизировать часть своей работы по машинному обучению чуть не изобрел велосипед, пытаясь на R создать конвейеры подготовки данных и обучения моделей. Чуть позже узнал, что такие конвейеры уже давно существуют в библиотеке sklearn и называются pipeline.

C++, C#
Если существующих библиотек на python недостаточно и требуется реализовать новый алгоритм с высокой производительностью, к вашим услугам компилируемый и статически типизированный язык C++ или похожий на него язык C#.

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

Прошу немного потерпеть. Обо всем вы узнаете в следующих разделах.

2. AutoML и визуальные конструкторы


AutoML согласно своей основной идее резко упрощает задачу исследователя и сводит несколько шагов по изучению и подготовке данных, конструированию признаков, выбору и сравнению алгоритма машинного обучения и настройке гиперпараметров к одному единственному шагу. И этот шаг заключается в выборе и настройке одного большого ящика под названием AutoML. Результатом запуска алгоритма AutoML является сконструированный и соответствующим образом настроенный и обученный pipeline. Остается только брать сырые данные, подсовывать их в pipeline и ждать на выходе результат в виде прогнозов.

Ящик под названием AutoML выглядит либо как библиотека машинного обучения, либо как веб-сервис куда заливаются данные.
Если это библиотека, то она отличается от sklearn тем, что наш привычный код в 20-30 строк сжимается до 5 строк. Известный пример такой библиотеки H2O.
Другой пример библиотека MLBox. Про нее в интернете можно найти истории, о том как применение MLBox позволило попасть в топовые 5% на соревнованиях kaggle.

Теперь несколько слов об облачных сервисах AutoML. Во первых, свои технические решения спешат представить все основные цифровые гиганты. Вот некоторые из них: Google AutoML Tables, Azure Machine Learning (Microsoft), SageMaker Autopilot (Amazon). Перечисленные сервисы должны быть интересны в первую очередь тем компаниям, которые разрабатывают аналитические системы на облачных платформах. Очень удобно, когда и инфраструктуру данных, и вычислительные ресурсы, и готовые алгоритмы машинного обучения предоставляет один и тот же провайдер. Интеграция получается поистине бесшовной.
Помимо цифровых гигантов на рынке AutoML появляются и игроки поменьше. Например, непосредственно в настоящий момент в компании Bell Integrator идет активная работа над платформой neuton.ai.

В этом же разделе стоит вспомнить про системы машинного обучения, занимающие промежуточные позиции между непосредственным программированием на R и Python и полностью упакованным в коробку AutoML. Это так называемые конструкторы workflow. Два типичных примера: конструктор машинного обучения Azure от Microsoft и платформа SberDS Сбербанка.
Конструктор представляет собой набор кубиков, из которых можно собрать весь конвейер машинного обучения, включая финальную проверку работоспособности модели. Это несомненно красивое решение для людей с визуальным типом мышления, которым удобно представлять процесс машинного обучения и тестирования моделей в виде схем.

3. Инструменты BI


Здесь бы я хотел рассмотреть несколько BI решений в области аналитики: Power BI, Tableau, Qlick Sense, Qlick View и Excel.

Power BI
Power BI это набор аналитических инструментов от Microsoft, которые доступны в виде десктопных приложений и облачных сервисов. Существуют корпоративные решения, работающие на закрытой it-инфраструктуре компании. Работа в Power BI Desktop или Power BI Services не требует навыков программирования. Предусмотрена возможность онлайн-интеграции с внешними источниками данных, а также загрузка данных в формате csv.
Power BI способен решать задачи машинного обучения посредством AutoML, то есть для построения модели классификации или регрессии писать программный код как на питоне не придется. Кроме стандартных задач анализа табличных данных в функционал встроены технологии анализа тональности, извлечения ключевых фраз, распознавания языка и добавления тегов к изображению.

Tableau
Tableau также представляет собой целое семейство онлайн и десктопных приложений, как и Power BI. Данные приложения имеют простой визуальный интерфейс и позволяют работать методом перетаскивания drag-and-drop. Красивые графики строятся буквально за несколько кликов. Также данные можно анализировать в табличном виде и применять к ним различные фильтры.
Tableau позволяет решать и задачи машинного обучения, такие как регрессия, прогнозирование временных рядов, кластерный анализ. А главное, Tableau способен интегрироваться с внешними скриптами на R и Python. Получается легко расширяемый инструмент.

Qlick Sence и Qlick View
Qlick Sence и Qlick View по позиционированию и интерфейсу отличаются между собой, но по сути и по алгоритмам решения задач построены на одном движке. Qlick View корпоративная платформа, которой управляют it-специалисты, Qlick Sence инструмент для личного использования без необходимости обращаться за помощью в тех. поддержку.
При первом же знакомстве бросается в глаза красота и легкость визуализации. Это тот самый инструмент, если надо построить приятный глазу дашборд для руководства. С моей точки зрения особенно зрелищным выглядит возможность менять масштаб при анализе географических карт и кластеров на двухмерных графиках. Вспоминаются кадры из фильмов, где на фото со спутников пытаются разглядеть номер автомобиля или выделить человека из толпы на площади.
Еще одна интересная опция наличие мобильного приложения для выполнения анализа со смартфона. Так и представляется топ-менеджер сети ритейла, спешащий на очередной рейс в аэропорту и получивший неожиданное сообщение в мессенджере со ссылкой на дашборд.
Qlick Sence интегрируется с Python, а следовательно и с машинным обучением.

Excel
Вы меня простите, но я не мог пройти мимо Excel. Сколько не смейся, но любой инструмент по своему хорош. Например, в Excel прекрасно строятся сводные таблицы и графики, буквально в несколько кликов. В сочетании с удобным табличным процессором и работой с форматом csv вполне себе хороший инструмент.

4. Изюминка на торте. Автоматическая генерация кода на основе AI.


Как-то раз при знакомстве в сети мне задали вопрос ты программируешь на python?. И когда я ответил Да, продолжение было совершенно неожиданным.
А ты знаешь про это и далее шла ссылка на ролик в Youtube
https://www.youtube.com/watch?v=fZSFNUT6iY8&t=4s&ab_channel=FazilBabu.
Речь идет о генеративной текстовой модели от OpenAI, обученной на репозитории GitHub. На конкретных примерах показана способность модели генерировать код на Python на основании заголовка функции и ее краткого описания.
А что будет, если такую модель удастся хорошо обучить на скриптах data scientists? Это вопрос для размышлений ))
Подробнее..

Как Microsoft Analysis Services финансовым аналитикам жизнь упростил

07.04.2021 16:22:59 | Автор: admin
Как мало пройдено дорог как много сделано отчетов

Введение


Василий, мы установили новый BI продукт, наш САМЙ ГЛАВНЙ от него просто в восторге!
Да, но я не знаю, как выгрузить данные для анализа из этой системы?! Он, похоже, только в html может что-то показывать.
Ничего, я думаю ты справишься, сам понимаешь, чем шире улыбка шефа, тем выше премия.
Но, Иван Васильевич, этот продукт в качестве источника данных использует только PDF файлы.
Зато он показывает шикарные разноцветные графики, у него анимация как в Звездных войнах, а руководство просто в восторге от его интерактивных возможностей. Там ещё и пасхалочка есть. Если три раза кликнуть в правом нижнем углу, появится Дарт Вейдер и споёт Марсельезу. Да и в целом, Вася, будь оптимистом! Хочешь анекдот в тему?

Что у вас запланировано на 1 января?
Катание на санках
А если снег не выпадет?
Это нас огорчит, но не остановит.

Не грусти Вася, принимайся за работу, а мне пора спешить утренняя планерка, эээ Daily Standup Meeting точнее, всё никак не могу запомнить.

Вася садится за свой рабочий стол и с грустью смотрит в монитор. Да уж, красивые графики, только толку от них? В Excel не выгрузить, с формулами не сверить, хоть бери тетрадку с ручкой и делай всё на бумаге. Плюс ещё как-то KPI на основе этого надо посчитать. Зато в ИТ отдел, говорят, художника взяли, чтобы он красивые отчеты для руководства оформлял. Глядя на новый продукт, Вася загрустил. В голове у него крутились пару строк из стихотворения C.А. Есенина Мне грустно на тебя смотреть:
Так мало пройдено дорог,
Так много сделано ошибок.

Ну что ж, оставим Васю на едине со своей болью и посмотрим на проблему шире. Видя переделку строк C.А. Есенина, которая вынесена в цитату к этой статье, мне кажется, что он не одинок в своих мыслях. Сложно понять, как работают современные BI системы и для кого их пишут то ли для аналитиков, то ли для руководителей. Очень много теории и информации, причём, в зависимости от источника, эта информация может противоречить самой себе. К этому стоит добавить обилие научных терминов и трудный для понимания язык описания. Сложно угадать с выбором, а цена ошибки велика, так как системы дорогие и работа с ними часто требует определенной квалификации. Понимая всё это, я решил поделиться своим опытом в BI сфере. Попытаюсь написать об этом простым языком и не вдаваться глубоко в теорию. Речь пойдет о Microsoft Analysis Services и о том, как он может решить часть проблем связанных с аналитической отчетностью. Другую часть этих проблем, я решил, написав специальную программу, которая позволяла формировать отчеты непосредственно в Excel, минуя HTML формы и минимизируя нагрузку на Web сервер, но о ней я уже писал тут http://personeltest.ru/aways/habr.com/ru/post/281703/, а тут даже видео снял: https://youtu.be/_csGSw-xyzQ. Приятного вам чтения.
Если лень читать, то есть кортокое видео (11 минут)
Создание OLAP-куба в Microsoft Analysis Services: https://youtu.be/f5DgG51KMf8
Но в этом видео далеко не всё то, о чём пойдёт речь далее!!!


Отчетность и её проблемы


Все началось с задачи, поставленной финансовым отделом крупного банка. Надо было создать систему отчетности, которая бы позволяла быстро и оперативно оценивать текущую ситуацию в организации. Для решения этой задачи мы взяли базу данных. Организовали в ней Хранилище (Data Warehouse), настроили процессы загрузки данных и установили систему отчетности. В качестве которой мы взяли SQL Server Reporting Services, так как этот продукт входил в MS Sharepoint, использовавшийся в тот момент в банке. В принципе всё работало, но у заказчика были претензии:

  • Претензия 1. HTML -> MS Excel: отчеты изначально формируются в HTML, а аналитики работают с MS Excel. Надо постоянно делать экспорт из одного формата в другой. При этом часто сбивается разметка и в Excel часто подгружается множество дополнительной информации, большой объём которой, в некоторых случаях, существенно влияет на производительность.
  • Претензия 2. Параметры для отчета: данные в отчетах зависят от параметров, причём при их изменении формируется новый отчет, который надо опять выгружать в Excel, что не всегда удобно.
  • Претензия 3. Добавление изменений в отчет: для того, чтобы что-то изменить в отчете, добавить новую колонку или создать группировку, надо обращаться к специалисту, который может поправить этот отчет на сервере.
  • Претензия 4. Анализ данных: отчеты получаются статическими и когда нужно посмотреть различные разрезы, поменять строки с колонками, отфильтровать или добавить, либо удалить какие-то значения, надо делать все эти манипуляции в Excel, что не всегда удобно, а порой и сложно, из-за проблем с производительностью компьютеров, на которых работают аналитики.

Стоит отметить, что сотрудники банка не рассматривали для себя никакого другого инструмента в качестве замены MS Excel. И на то были веские основания. Весь его функционал сложно чем-то заменить. К примеру, аналитики очень часто:

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

В общем использовали его на все 100%. Хотя были те, кто предлагал им что-то другое, точнее не столько предлагал, сколько заставлял. Как итог таких предложений, у нас в системе появились SAP BO, Oracle Reports Services и ряд других BI инструментов. Возможно, они в чем-то превосходили SQL Server Reporting Services, но суть работы с ними кардинально не изменилась:

  1. формируем отчет в HTML,
  2. экспортируем его в Excel,
  3. начинаем заниматься бесконечными танцами вокруг данных.

Требовалось что-то более кардинальное, не просто отчет, а некий набор данных, с которым удобно было бы работать.

Выход из ситуации


К найденному решению подтолкнули PivotTable в Excel



и PivotGrid от фирмы DevExpress ( https://demos.devexpress.com/blazor/PivotGrid).

Детально изучив эти решения вышли на MS Analysis Services и решили попробовать. Его можно использовать в Excel, и он может работать с Oracle, как с источником данных, что нас на тот момент устраивало. С точки зрения архитектуры, источником данных для него может служить что угодно, был бы нужный провайдер. Суть его в том, что он способен хранить в себе большие объемы данных со всеми их агрегациями и выдавать их клиенту максимально быстро. К Excel его можно легко подключить и манипулировать данными в Pivot Table.



В MS Analysis Services есть возможность партиционирования данных (хранение их в виде множества отдельных частей) и так же инкрементальное обновление данных. Это даёт ему возможность загружать данные из внешних систем небольшими кусочками и хранить их во множестве партиций. С точки зрения максимальных объемов, у него есть ограничения, но они довольно большие https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/maximum-capacity-specifications-analysis-services?view=asallproducts-allversions.

MS Analysis Services является OLAP системой, которая использует отдельный сервер для хранения данных, либо части данных. Его плюсом является то, что он способен довольно быстро работать с миллионами записей, будучи установленным на обычный, современный компьютер. Так же он позволяет анализировать данные непосредственно в Excel и может заменить собой десятки отчетов на MS Reporting Services или ему подобных. Причем при работе с ним не надо писать и править различные запросы типа SQL, хотя при желании можно, только вместо SQL он использует MDX.

Правда есть тут и ложка дегтя. В Excel можно запросить разом очень большой объём данных и OLAP их вернет, но отобразить такой объем Excel не сможет, либо сможет, но работать при этом будет очень медленно. На первых порах это раздражало аналитиков, но поняв причину и настроив фильтры в Pivot Table эту проблему решили.

Секрет быстродействия MS Analysis Services, как и любой другой OLAP системы, кроется в архитектуре хранения данных. В нем все храниться в максимально подготовленном и оптимизированном для запросов виде. Такая подготовка требует времени и запись вновь пришедших данных в OLAP происходит не быстро, но, с другой стороны, чтение данных получается очень быстрым. Выходит долго пишем быстро читаем.

Немного теории


Чаще всего, когда анализируют данные их объединяют в группы, а сами группы так же объединяют в иерархии. Для примера возьмём торговую точку. С точки зрения бизнеса, интерес представляют продажи. То есть сколько товара было продано за день (1-группа), за месяц (2-ая) и за год (3-я). Где день месяц и год это разные уровни одной иерархии. Получается, что продажи за месяц это сумма всех продаж за все дни в месяце, а продажи за год это сумма продаж за все месяцы в этом году. Отсюда получается, что для получения максимального быстродействия, можно заранее собрать данные в группы и рассчитать агрегаты (в нашем примере суммы продаж) для каждого уровня иерархи. Вот на этом принципе и работают MS Analysis Services. Им достаточно сказать что надо считать, по какой формуле и на какие группы это можно разбить. Остальную работу они сделают сами. Тут немного о том как они это делают: http://citforum.ru/consulting/BI/molap_overview/node7.shtml. Стоит отметить, что в современных OLAP системах все агрегаты, чаще всего, не рассчитываются заранее. Это всё делается на лету, в момент запроса.

Теперь о терминах:


MS Analysis Services это одна из OLAP систем, где OLAP это аббревиатура online analytical processing. Дословно это означает интерактивная (online) аналитическая обработка данных. Со временем данная формулировка утратила свой первоначальный смысл, так как появились системы, способные обрабатывать данные с большой скоростью и передавать их пользователю без использования подходов, декларируемых в OLAP. Поэтому, сейчас есть более полное описание требований к системам, которые могут называться OLAP, это:


По своему опыту, могу сказать, что чем больше ваш OLAP куб удовлетворяет описанию Е.Ф. Кодда, тем лучше, как с точки зрения работы с ним, так и с точки зрения его создания.

Вкратце, OLAP это система хранения, организованная таким образом, чтобы данные в ней:

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

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

При построении OLAP выделяют Факты и Измерения. Факты это цифровые значения измеряемых величин. Измерения это сами измеряемые величины. Совокупность всех связанных между собой измерений, фактов и функций для их агрегации называют OLAP-кубом. Факты и Измерения связанны между собой. По типу связи выделяют 2 схемы организации хранения данных Звезда и Снежинка. Звезда это когда все измерения напрямую связаны с фактом, снежинка это когда есть измерения, которые связанны с фактом через другие измерения. Эти схемы можно создавать и просматривать в разделе Data Source Views в SSAS.







Создание OLAP-куба в Microsoft Analysis Services


Построение OLAP кубов делается через проект в Visual Studio. По большей части там реализована технология визуального программирования перетащить, кликнуть мышкой, настроить. Отсюда это проще показать, чем описать. Что я и сделал в моем видео: https://youtu.be/f5DgG51KMf8. Так же стоит отметить то, что Microsoft, в ознакомительных целях, предоставляет свои продукты бесплатно. Отсюда, посмотреть, как он работает можно на любом компьютере с ОС Windows 10, удовлетворяющем следующим требованиям: https://docs.microsoft.com/en-us/sql/sql-server/install/hardware-and-software-requirements-for-installing-sql-server-ver15?view=sql-server-ver15. Требования по ссылке к MS SQL Server, так как MS Analysis Services являются его частью.

Заключение


OLAP это относительно простой способ повысить скорость и удобство работы с данными. В данный момент существует множество решений, основанных на этой технологии. Я работал с MS Analysis Services (SSAS) и вот что мне в нём понравилось:

  • теоретически он позволяет работать с любым источником данных, не требуя при этом существенных затрат с точки зрения оборудования.
  • хранит данные на выделенном сервере, что снижает вероятность их потри, в отличие от систем, хранящих такие данные в памяти.
  • интегрирован с MS Excel, что облегчает работу с ним для тех, кто привык работать с данным продуктом.

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

Развитие BI-систем тренды и движение в сторону ABI. Взгляд со стороны визуализации

04.05.2021 16:09:09 | Автор: admin

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

Заметка от партнера IT-центра МАИ и организатора магистерской программы VR/AR & AI компанииPHYGITALISM.

Кратко о BI-системах и их преимуществах

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

Рис.1. Преобразование данных в аналитику в BI-системахРис.1. Преобразование данных в аналитику в BI-системах

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

Рис 2. Для каких задач внедряют BI-системыРис 2. Для каких задач внедряют BI-системы

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

Рис 3. Преимущества BI-системРис 3. Преимущества BI-систем

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

Рис.4. Объем рынка BI-системРис.4. Объем рынка BI-систем

Расширяются границы их применения для стратегического и тактического планирования.

Рис 5. BI-системы как часть бизнесаРис 5. BI-системы как часть бизнеса

Внедрение BI-систем становится все более нужным и прибыльным для компаний.

Рис 6. Эффекты от внедрения BI-систем для компанийРис 6. Эффекты от внедрения BI-систем для компаний

Рынок BI-систем развивается в сторону кроссплатформенности и внедрения новых подходов к аналитике. Именно поэтому важно понимать, какие тренды сейчас есть.

Тренды в развитии BI-систем: эволюция до ABI

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

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

Рис.7. Интерактивность современных BI-системРис.7. Интерактивность современных BI-систем

За все время настолько изменилось представление о BI-системах, что большинство специалистов называют используемые self-service BI-системы (такие как Tableau, Power BI или Qlik Sense) просто BI-системой, хотя различия тут есть в традиционных системах в аналитику были вовлечены IT-специалисты, а в self-service пользователи сами выполняют всю работу, без обращения к IT.

Рис.8. Разница между традиционной и self-service BI-системамиРис.8. Разница между традиционной и self-service BI-системами

Появление ABI-систем

Эволюция BI-систем не стоит на месте, появляются новые подходы к аналитике, а данных становится все больше именно поэтому возникла новая концепция Augmented Business Intelligence, которую выделили Gartner.

Рис.9. Эволюция аналитики в BI-системы и в Augmented Business IntelligenceРис.9. Эволюция аналитики в BI-системы и в Augmented Business Intelligence

Augmented Business Intelligence это модель партнерства людей и искусственного интеллекта, которая ориентирована на совместное взаимодействие машины и человека для улучшения аналитики, принятия решений, подготовки данных и получения инсайтов.

Рис.10. Инновационность ABI-системРис.10. Инновационность ABI-систем

ABI это новая ступень развития BI-платформ, так как в ней есть сразу несколько преимуществ. В ней объединяется не только привычная аналитика и таблицы, но и также новые технологии: от дополненной и виртуальной реальности до решений с компьютерной графикой и 3D.

Рис.11. Отличия BI-системы от ABI-системы и ее преимуществаРис.11. Отличия BI-системы от ABI-системы и ее преимущества

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

Рис.12. Тренды в развитии BI-системРис.12. Тренды в развитии BI-систем

Тремя основными тенденциями бизнес-аналитики на 2020 год являются управление качеством данных (MD/DQ), DataViz и внедрение self-service BI-систем, и особое место занимает внедрение data-driven подхода в культуру компаний. Мы стараемся внедрять все эти подходы в наше решение с BI-системой для Ingrad, и хотели бы побольше рассказать о самых интересных, на наш взгляд.

Развитие предиктивной аналитики

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

В этом контексте также говорят о концепции DIKW: Data-Information-Knowledge-Wisdom.

Рис.13. Концепция DIKWРис.13. Концепция DIKW

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

BI-системы в этом случае выступают инструментом достижения верхушки пирамиды благодаря визуализации мы можем быстро проанализировать любые данные и информацию для получения знаний. Чтобы получить мудрость мы должны видеть всю ситуацию в пространстве, и здесь может помочь визуализация данных (Data Visualization) и 3D-технологии.

Визуализация данных (Data Visualization, DataViz)

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

Рис. 14. Визуальное потребление информацииРис. 14. Визуальное потребление информации

Именно поэтому и существует визуализация данных (Data Visualization) ряд инструментов наподобие графиков, таблиц, диаграмм и схем, которые представляют информацию наглядно.

Рис.15. Инструментарий DataVizРис.15. Инструментарий DataViz

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

Мы все привыкли к 2D-инфографикам, и, да, они прекрасно справляются со своей задачей, но информацию можно донести и более эффективными способами. Во многих случаях 3D-визуализации позволяют передать больше информации об объекте.

Рис.16. Преимущества 3D-визуализацииРис.16. Преимущества 3D-визуализации

Мы считаем, что 3D визуализация данных это не просто тренд, а необходимость для некоторых сфер (AEC, например). Для девелопера на рынке российской недвижимости мы разработали BI-систему аналитики с 3D визуализацией данных, которая намного более эффективна благодаря интерактивности и наглядной демонстрации данных на карте.

Рис.17. Пример 3D визуализации данных на карте для визуализации данных в проекте с IngradРис.17. Пример 3D визуализации данных на карте для визуализации данных в проекте с Ingrad

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

Рис.18. Пример интерактивных BIM-моделей зданийРис.18. Пример интерактивных BIM-моделей зданий

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

Data Storytelling

Одним из главных трендов, который был выделен исследованием Dresner это data storytelling. Чтобы человек лучше запомнил и воспринял суть информации и сообщения, он должен пережить опыт. Наблюдая за развитием ситуации в реальном времени, мы невольно попадаем в раскрытие какой-либо истории.

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

Рис. 19. Фокусирование внимания пользователя на данных с помощью анимацииРис. 19. Фокусирование внимания пользователя на данных с помощью анимации

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

Рис.20. Феномен data storytellingРис.20. Феномен data storytelling

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

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

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

Рис.21. Уникальные черты и roadmap разработанной кроссплатформенной BI-системы для IngradРис.21. Уникальные черты и roadmap разработанной кроссплатформенной BI-системы для Ingrad

За какими технологиями нужно следить, чтобы быть в курсе развития BI-систем?

  • Искусственный интеллект и машинное обучение для создания системы предиктивной аналитики, расшифровки данных и выявления тенденций

  • 3D-технологии для внедрения новых инструментов Data Visualization, показа большего числа данных, в том числе с привязкой к географии

  • XR для совместной работы и визуализации аналитики в интерактивном иммерсивном формате.

Заключение

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

Проследив эволюцию BI-систем, тренды и прогнозы развития, которые делают крупные исследовательские компании, выделим целый ряд трендов:

  • MD/MQ Data management

  • Внедрение data-driven культуры в работу

  • Внедрение self-service BI систем

  • Data Visualization

  • Data Storytelling

  • Развитие ABI систем

  • Аналитика в real time

  • Data warehouse modernization

  • Data governance

  • Предиктивная аналитика

  • Внедрение моделей машинного обучения

  • Cloud BI

  • Самостоятельная работа с данными

  • BI-системы для мобильных устройств

  • Добавление и совершенствование уведомлений в BI-системах

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

Бизнес-аналитика становится проще и доступнее, и развитие технологий только способствует этому.

Источники
Подробнее..

Storytelling отчет против BI, прагматичный подход

08.05.2021 10:22:37 | Автор: admin

Проблематика


Когда говорят про отчеты к данным (неважно, какая тема) все хотят гибкие дашборды, МНОГО дашбордов, играют конкурсы про BI, выдумывают разные сложные требования и кейсы, отсматривают массу вендоров и решений, разбиваются на непримиримые лагеря и на 100% уверены, что это то, без чего жизнь на работе тяжела, уныла и печальна.


Так ли это? По описанию очень сомнительно (похоже на серебряную пулю), а практика дает подтверждение отнюдь не так.


Является продолжением серии предыдущих публикаций.


Что в реальности


В реальности все оказывается совсем по другому. Сразу исключим из рассмотрения настоящих аналитиков, которым этот инструмент может раскрыться в полной мере (остановимся чуть позже). В подавляющем большинстве случаев не нужны менеджерам эти дашборды с сотней ручек. Им нужны ограниченные срезы для решения повседневных задач. Основным драйвером за BI и дашборды являются страх и лень. Страх остаться с данными один на один и невозможностью ответить на какой-либо вопрос. Страх пойти по пути, который не отлит в корпоративных стандартах как бетонный монолит. Лень задуматься о истинных потребностях обычных пользователей и альтернативных способах решениях.


Откуда такие утверждения? Дело в том, что отчетные квесты больше похожи на сеансы психотерапии. Каждый раз приходится медленно пробираться через наслоение индуцированных утверждений и убеждений, чтобы добраться до истинной потребности и после этого объяснить ее компьютеру. Последний точно не умеет и не понимает общих слов и смутных ощущений. У него только 0 и 1.


Итак, какие есть существенные выгоды у storytelling отчетов, выполненных на базе технологии RMarkdown. Для ознакомления с возможностями RMarkdown можно проглядеть галерею. Далее будем по умолчанию подразумевать HTML форму отчета, как наиболее удобную для динамичной работы.


Выгода 1. Предоставление пользователю информации в готовом к употреблению виде


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


Выгода 2. Полная отвязка от инфраструктурных ограничений


В большинстве случаев storytelling отчет нужен по закрытому дню и генерировать его надо один раз в сутки. Оптимальный вариант ночная offline генерация всех необходимых отчетов для текущего рабочего дня. Классическое окно для генерации 2:00-7:00. Когда предыдущий день закрыт и переходные процессы закрытия во всех внутренних ИС завершились. Отсюда четыре существенных плюса:


  • offline генерация на серверной стороне позволяет не заморачиваться на скорость исполнения. В случае интерактивного анализа отклик должен измеряться десятками миллисекунд, иначе пользователи начинают жаловаться на торможение системы. Здесь же мы можем считать секунды. Снижение к требованиям по железу колоссальное.
  • можно использовать любой сложности алгоритмы, в т.ч. весь спектр ML инструментов.
  • нет понятие лицензий на доступ, нет непредсказуемой конкурентности. планируете задания последовательно-параллельно, опираясь на доступные вам аппаратные средства.

Выгода 3. Полная отвязка отчета от источников данных


Будучи собранным, storytelling отчет является самодостаточной и законченной сущностью. Это единый html контейнер, который содержит в себе всю необходимую информацию. Отсюда три существенных плюса:


  • готовый отчет можно как рассылать пользователям по почте, так и предоставлять доступ через корпоративные порталы. пользователь сможет работать с ним везде и за пределом корп.сети, и даже в бункере в режиме полного оффлайна.
  • отчет это html файл. тривальными средствами можно обеспечить историческое хранение на любую требуемую глубину со стоимостью, близкой к 0.
  • в исторической части хорошо известная проблема, когда отлаженный неизменный отчет нельзя собрать на исторических данных так, как он собирался бы тогда, когда эта дата была. Связано это с изменчивостью данных, изменчивостью ландшафта, эволюцией ИС и систем, динамичностью справочников. В тривиальном случае оргструктура любой компании динамична и она сегодня не такова, какой была 3 года назад. Обычному отчету никогда не вернуться в прошлое. А storytelling отчет это след папоротника в известняке.

Выгода 4. Динамическая генерация, основанная на предоставленных данных


Классический отчет жестко зафиксированный состав элементов и их форма. В случае со storytelling отчетом можно использовать подходы динамической генерации, когда сама ткань отчета генерируется на основе структуры полученных данных. Тем самым возможна почти любая вариативность, при этом текст отчета остается связным и без пустых мест. Чуть детальнее с кодом можно посмотреть в публикации R Markdown. Как сделать отчет в условиях неопределенности?.


Также можно параметризировать RMarkdown отчет и получать различные представления на различных данных, используя один и тот же код.


Выгода 5. Динамический контент


Представление html позволяет добавить такой объем динамичности, что пользователь может забыть, что это offline. Включение js виджетов позволяет обеспечить динамичные таблицы, графики. Средствами html и js можно располагать части отчета на закладках, обеспечивать кросснавигацию и оглавление, управлять видимостью объектов. Использование механизмов кросскоммуникации js виджетов позволяет делать связанные обновления элементов. Более конкретно:



Выгода 6. Безопасный доступ к данным


Очень часто возникают требования по управлению доступом к данным. Та или иная группа пользователей должна иметь возможность строить отчет только по своему подмножеству. Но весь парадок в том, что все равно остается ряд показателей, которые считаются по всей компании. И если это делать через self-service bi, то потребуется продумывать как это предоставить. Витрины, кубы, выгрузки или еще что-либо.


В случае с Rmarkdown отчетами пользователи вообще не имеют доступа к данным. Все собирается на сервере с контролируемым полным доступом. А в html фиксируются посчитанные агрегаты в соответствии с ролевой моделью.


Выгода 7. Один источник масса представлений


RMarkdown позволяет из единого источника делать совершенно различные финальные представления. html, pdf, doc, pptx.


Также, технология RMarkdown позволяет делать статические сайты (blogdown) и книги (bookdown).


Выгода 8. Вся мощь devops для гарантий корректности


Поскольку Rmarkdown является набором R инструкций, то управление жизненным циклом отчетов получается идентичным управлениею жизненным циклом ПО. Репозиторий, пакетирование, документирование, автотесты, continious integration, code coverage, профилировка узких мест.


Также, RMarkdown отчеты могут самостоятельно на этапе сборки подключаться к любым источникам данных (не обязательно выверенным SQL таблицам) и строить отчет на актуальных в моменте данных.


Выгода 9, 10, X. ......


Выберите из списка...


Заключение


Еще один важный комментарий. Для того, чтобы корректно использовать дашборды или self-analytics bi нужно очень-очень хорошо знать структуру данных, которые используются в процессе рассчета и визуализации и иметь к ним полный доступ. Данные должны быть чистые, консистентые и рафинированные. Аналитик должен обладать навыками проведения расчетов и проверки результатов. Только так можно получить показатели и картинки, которым как-то можно доверять. В противном случае имеем сплошные жареные факты и желтую прессу. Затраты на такого аналитика никак не середнячковые.


P.S.


По сути, storytelling отчеты являются реализацией давным-давно предложенной Дональдом Кнутом концепции литературного программирования. И вся вычислительная мощь только через 30 лет смогла доехать до практической и удобной реализации.


Алармисты уже не дремлют. Gartner вовсю начал предрекать закат BI в том виде как он есть сейчас. Нет поводов не задуматься:



Предыдущая публикация R в руках маркетолога. Делаем когортный анализ своими руками.

Подробнее..

Business Intelligence на больших данных наш опыт интеграции

20.01.2021 14:20:49 | Автор: admin

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

Если вы читаете наш блог, то уже знаете о платформе Visiology хотя бы в общих чертах (если нет, это можно легко исправить, прочитав наш первый пост). Но сегодня речь пойдет не только о платформе Visiology и BI как таковых, но также о наших новых друзьях Arenadata. А точнее, об интеграции, которая позволила реализовать гибридную работу аналитики с большой скоростью и на больших объемах данных.

Зачем потребовалась интеграция Arenadata и Visiology?

Подходов к работе BI-систем на сегодняшний день несколько. Но когда речь идет о больших данных для самых разных задач, обычно используется ROLAP. Работает он достаточно просто: когда пользователь нажимает что-то на дашборде, например, выбирает какой-то фильтр, внутри платформы формируется SQL-запрос, который уходит на тот или иной бэкэнд. В принципе, под системой BI может лежать любая СУБД, которая поддерживает запросы от Postgres до Teradata. Подробнее о схемах работы OLAP я рассказывал здесь.

Преимущество интеграции BI с СУБД заключается в том, что для работы системы, по сути, нет ограничения по объему данных. Но при этом падает скорость выполнения запросов - конечно, если не использовать специализированную колоночную СУБД, например, ClickHouse или Vertica. И, хотя у ClickHouse спектр возможностей пока еще уже, чем у той же Vertica, система развивается и выглядит очень многообещающей.

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

Второй момент это ограничение аналитической функциональности: все, что не укладывается в SQL-запрос, поддерживаемый распределенной СУБД, отсекается автоматически (например, в случае ClickHouse - это оконные функции). И это проблема, потому что в BI есть много вещей, которые с трудом транслируются в SQL-запросы или выполняются неоптимально.

Второй вариант это In-memory OLAP. Он подразумевает перенос всех обрабатываемых данных в специальный движок, который молниеносно прорабатывает базу в 200-300 Гб это порядок единицы миллиардов записей. Кстати, подробнее про ограничения In-Memory OLAP я уже рассказывал здесь. На практике встречаются инсталляции In-Memory OLAP, укомплектованные 1-2-3 терабайтами оперативной памяти, но это скорее экзотика, причем дорогостоящая.

Практика показывает, что далеко не всегда можно обойтись тем или иным подходом. Когда требуются одновременно гибкость, возможность работы с большим объемом данных и поддержка значительного количества пользователей, возникает потребность в гибридной системе, которая с одной стороны загружает данные в движок In-Memory OLAP, а с другой постоянно подтягивает нужные записи из СУБД. В этом случае движок OLAP используется для доступа ко всему массиву данных, без всяких задержек. И в отличие от чистого In-Memory OLAP, который нужно периодически перезагружать, в гибридной модели мы всегда получаем актуальные данные.

Такое разделение данных на горячие и холодные объединяет плюсы обоих подходов ROLAP и In-Memory, но усложняет проект внедрения BI. Например, разделение данных происходит вручную, на уровне ETL процедур. Поэтому для эффективной работы всего комплекса очень важна совместимость между бэкэндом и самой BI-системой. При том, что SQL-запросы остаются стандартными, в реальности всегда есть аспекты их выполнения, нюансы производительности.

Arenadata и Arenadata QuickMarts

Платформа данных Arenadata состоит из нескольких компонентов, построенных на базе открытых технологий, и используется многими российскими и зарубежными компаниями. В состав решения входит собственное MPP решение на базе Greenplum, дистрибутив Hadoop для хранения и обработки неструктурированных и слабоструктурированных данных, система централизованного управления ADCM (Сluster Management) на базе Ansible и другие полезные компоненты, в том числе Arenadata QuickMarts (ADQM).

СУБД ADQM это колоночная СУБД от Arenadata, построенная на базе ClickHouse, аналитической СУБД, которую развивает Яндекс. Изначально ClickHouse создавалась для внутреннего проекта Яндекс.Метрика, но эта СУБД очень понравилась сообществу. В результате исходный код ClickHouse был переведен в OpenSource (лицензия Apache-2) и стал популярен по всему миру. На сегодняшний день насчитывается порядка 1000 инсталляций ClickHouse по всему миру, и только 1/3 из них в России. И хотя Яндекс остается основным контрибьютором развития СУБД, лицензия Apache-2 позволяет абсолютно свободно использовать продукт и вносить изменения в проект.

Современная колоночная СУБД использует аппаратную оптимизацию CPU (SSE). ClickHouse может очень быстро выполнять запросы за счет векторных оптимизаций и утилизации всего ресурса многоядерных CPU. На базе ClickHouse работают огромные кластера сам Яндекс растягивает эту СУБД на несколько сотен серверов. Это гарантирует, что вместе с этим решением вы можете масштабироваться в достаточно больших объемах.

Но главная фича ClickHouse в нашем контексте это эффективная работа с достаточно специфическими аналитическими запросами. Если витрины уже отстроены и вам нужно предоставить доступ пользователей к BI с минимальной латентностью, эта история как раз для ClickHouse. Эта СУБД прекрасно справляется с запросами без джойнов и соединений.

Во многих сравнениях ClickHouse дает серьезную фору даже классическим СУБД, например, той же Oracle Exadata. Результаты этих тестов можно найти на ресурсах Яндекса.

Производительность QuickMarts

  • Типичные запросы быстрей чем за секунду

  • > 100 раз быстрей чем Hadoop и обычные СУБД

  • 100 млн - 1 миллиард строк в секунду на одной ноде

  • До 2 терабайт в секунду для кластера на 400 нод

Но вернемся к Arenadata QuickMarts. Это сборка ClickHouse, которая немного отличается от сборки Яндекса. Наши коллеги из Arenadata даже позже выпускают релизы, потому что проводят больше тестов, чтобы серьезные задачи в продакшене работали только на стабильных версиях.

При этом установка и настройка ADQM происходит из Arenadata Cluster Manager. Кастомизированная СУБД обладает расширенными механизмами авторизации пользователей, a также средствами мониторинга на базе Graphite и Grafana. Но самое главное, что QuickMarts изначально располагает готовыми коннекторами и прозрачно взаимодействует с другими компонентами платформы, в т.ч. с ADB (Greenplum), что позволяет по мере необходимости подгружать данные из ADB в ADQM.

В нашем случае QuickMarts используется для работы с витринами, к которым через BI обращаются сотни или тысячи пользователей. Архитектура системы позволяет выдать им данные здесь и сейчас, а не ждать 20-30 секунд, когда обработается их запрос по витринам в более медленной СУБД.

Как работает интеграция Arenadata и Visiology

Когда Visiology используется вместе с Arenadata, схема работы системы выглядит следующим образом. Основное хранилище данных может быть реализовано на базе ADB (GreenPlum), из которой создаются витрины данных, хранящиеся уже в ADQM. За счет интеграции между компонентами решения система работает как единое целое, а необходимые для запросов данные поднимаются на нужный уровень автоматически.

Фактически в аналитической системе создается только один дашборд, а графику обрабатывает движок In-Memory ViQube ядро платформы Visiology. Пользователь лишь выбирает те или иные фильтры, а задача по выгрузке самих транзакций выполняется уже на бэкенде ресурсами QuickMarts.

Раньше подобная интеграция была только с Vertica, но сейчас мы совместно с коллегами сделали интеграцию для Arenadata QuickMarts. Это радостная новость для сторонников ClickHouse, потому что BI работает с популярной СУБД по гибридной схеме. При этом Arenadata DB, выполняющая функцию корпоративного хранилища данных, обеспечивает необходимую трансформацию данных для дальнейшей работы QuickMarts и Visiology.

Все запросы BI обрабатываются движком ViQube. Если пользователь обращается к тем данным, которых нет в памяти, система автоматически генерирует SQL-запрос, который выполняется на Arenadata QuickMarts.

Чтобы все это заработало, мы реализовали поддержку диалекта ClickHouse для основных аналитических функций и добавили автоматическое переключение между режимами работы OLAP в зависимости от того, где находятся данные на самом деле. Однако для пользователя все остается предельно прозрачным: он даже не знает, как работает система просто делает запросы в интерфейсе BI и получает результаты, причем достаточно быстро.

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

Развиваемся дальше

Сейчас интеграция находится на стадии версии v1.0, и мы планируем дальнейшие доработки. В частности, уже сейчас речь идет о том, чтобы расширить набор доступных аналитических возможностей, а также об интеграции в единую консоль управления (например, у Arenadata есть решение Cluster Manager (ADCM), которое позволяет управлять всеми компонентами ландшафта из единой консоли, рассматриваем это как один из вариантов).

Также на повестке дня остро стоит задача автоматизации настройки метаданных. Сейчас их нужно размечать в специальном интерфейсе - это довольно трудоемко. Хочется, чтобы система самостоятельно распознавала бы все необходимые параметры, получив путь к той или иной витрине.

В целом, мы остались очень довольны и сотрудничеством с Arenadata, и той интеграцией с ClickHouse и ADQM, которая получилась. Теперь в аналитической платформе Visiology можно одновременно работать с источниками данных любого масштаба - от Small Data (ручной ввод, Excel) до Big Data (миллиардов или даже сотни миллиардов транзакций из распределенных хранилищ данных). А гибридный режим работы, который мы реализовали вместе с Arenadata, еще и позволяет сделать это с разумными затратами на оборудование.

Будем признательны, если вы напишете в комментариях, с какими сценариями запуска BI на больших данных вы сталкивались. Ну а мы всегда готовы поделиться своим опытом в деталях!

Подробнее..

Как аналитика помогает нашей IT компании получать крупные контракты из SEO

02.03.2021 12:21:43 | Автор: admin

Крупные контракты на кастомную разработку для американского бизнеса, которые приходят к нам из SEO, позволили нам, IT аутсорсинговой компанией со 170 сотрудниками в 2017 году (сейчас 300), покрыться небольшим жирком. Он дает нам возможность инвестировать в разработку аналитических инструментов для собственных нужд и настраивать масштабируемый процесс лидогенерации. Началось все с меня как технического сеошника, продолжается созданием маркетинговой команды под меня и под мою методологию. Раз в это инвестирует руководитель B2B компании в сфере разработки ПО на заказ, это работает на западном рынке, и это можно масштабировать, то может и вам будет это интересно?

С чего ты взял, что SEO может давать enteprise контракты?

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

Поэтому давайте рассуждать логически.

  1. Я пришел в компанию в начале 2017 года как единственный специалист по входящему маркетингу в компании, но формально как сеошник, в начале 2018 ушел. Входящий или inbound маркетинг, если кратко, это действия, которые приносят лидов с сайта такого качества, чтобы они потом легко селзами превращаются в клиентов. Этим входящий маркетинг отличается от всех других видов маркетинга.

  2. Ближе к концу 2019 года я вернулся и начал формировать отдел. Теперь в нем я как руководитель, а также еще 3 человека (копирайтер, сеошник и пиарщик) - и мы не собираемся останавливаться на этом размере. Как вы думаете, с чего бы руководителю компании инвестировать в кого-то или во что-то все больше и больше, если только это не выгодно?

Все это хорошо, но так как это статья для аналитиков, то нужно больше пруфов.

Например, как определить, что потенциально крупный клиент пришел именно из SEO, а не других каналов?

Это сделать можно, но только если у вас настроен анализ воронки. Давайте приведу пример:

Это скрин из яндекс метрики, из него видно, что из поиска Google пришел предположительно американец на один из наших лендингов, потом перешел на другой и сразу же оставил заявку, чему подтверждением является срабатывани цели на т.н. thank you page. Из яндекс метрики мы не видим, что за запрос нам пришел (может, спам?), эти данные можно получить только из CRM. На скрине ниже виден текст его запроса.

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

После матчинга данных из счетчика аналитики с данными из CRM мы можем увидеть текст сообщения. Фразы big visualization project и we dont have a budget limit as we need a very high quality dev team как бы намекает, что контракт может быть очень интересным. Заявка пришла с коропоративного домена, что позволяет сделать исследование компании. Эта информация на скрине замазана, могу сказать лишь, что это компания работает со сферой Oil and Gas. Станет она нашим клиентом или нет - пока неизвестно, но лид этот считается качественным, так как полностью соответствует экспертизе компании, а заказчик - из интересующего нас региона. И - он пришел из SEO. Это горячий лид, которого не надо спрашивать, нужна ли вам услуга или нет, она ему нужна, он находится на стадии выбора поставщика решений.

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

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

Ну ок, ты нам показал, что теоретически это возможно. Предположим, мы тебе поверили. Рассказывай, что надо сделать, чтобы у нас тоже приходили лиды из нужной нам страны с запросам на разработку по нужной нам экспертизе из SEO.

Знания - ничто, контекст - все!

Для начала давайте определимся, что может сделать SEO специалист, если бюджет выделен только на его зарплату. Много чего, или мало чего. Зависит от его квалификации.

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

Итак, поехали.

Когда я только пришел, то начал со стандартных активностей по техническому SEO. Например, блог представлял собой архив с пейджингом. Я пересмотрел статьи в блоге, понял, что они на разные темы, попробовал эти темы сформулировать правильно, превратил темы в хайлевельные теги и вынес их в подменю блога, что позволило убрать пейджинг. Сделано было и многое другое, более традиционное для активностей, которые называются техническим SEO. Не хотелось бы на этом останавливаться, так как это не является целью данной статьи. Это особо лидов не увеличило. Трафик с сайта продолжал идти преимущественно нецелевой из Индии. Моя задача по использованию SEO для лидогенерации не решилась.

Пытался заниматься т.н. крауд-маркетингом, т.е. заходил на форум по теме и ссылки там ставил. Но это было как-то скучно, долго и не масштабируемо. Хотя пару лидов было.

Мне рекомендовали закупать ссылки, но у меня был страх экспериментировать с этим, так как это похоже на игру в казино. В результате закупки ссылок ты можешь или получить все или потерять все. Да еще Google стращал, мол, не делайте этого. А западные эксперты твердили на разные лады - главное контент, главное контент, content is a king.

Мне повезло, что я пришел в техническое SEO с бекграндом человека пишущего (формальное журфаковское образование). Также мне повезло, что я на халевельном уровне стараюсь разобраться, как работают технологии. Этот бекграунд, а также отсутствие серьезных результатов после внедрения технического SEO и, соответственно, бюджетов, с одной стороны, и вера в силу бестпрактик, с другой стороны, привел меня к мысли, что надо писать контент (англоязычный). Но совершенно не было понятно, на какую тему. А если мне эти темы предлагали, то мне было совершенно непонятно, почему именно эти темы, а не другие.

Точно я знал только одно: мне нужны ссылки, но только естественные. Также мне нужен трафик, много трафика. Результатом моих изысканий стало предположение, что надо писать холиварные статьи типа JAVA vs PHP или мотивационные типа Software developers who started after 35 (кстати, стала вирусной и дала кучу ссылок и 50 000 переходов на сайт). Результатом этой активности стало малюсенькое увеличение лидов, что было неплохо, но и не очень хорошо. Особенно в свете того, что плохо масшабировалось. Прямо как из истории про проститутку в книге Черный лебедь. Под знаком непредсказуемости.

В общем я выгорел и ушел в другую более крупную компанию, где было поменьше работы. Но оставил наследство в виде методологии: самое главное не SEO, а контент, надо нанять копирайтеров, пусть они пишут и лиды пойдут, а также нужен линкбилдер.

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

К этому времени мне надоело работать в корпорации, куда я перешел, так как для меня там не оказалось по факту интересных задач и я согласился стать руководителем маркетинга. Мы взяли в команду сеошника и поехали.

Первым делом я стал думать, почему у нас нет крупных лидов на разработку. Есть только мелкие. А расходы при этом увеличились на маркетинг. В итоге я сформулировал гипотезу: все дело в том, что мы делаем неправильный мёд контент, мы размещаем неправильно ссылки, и мы снова делаем только техническое SEO!

Меня спросили: ну ок, раз ты такой типа умный, скажи как правильно, будем делать правильно. Я в ответ - э нет, ребята, давайте-ка вместе все это вырабатывать в формате воркшопов. Создадим базу знаний и чеклисты по SEO, копирайтингу, линкбилдингу. Внедрим что-то типа Scrum митингов, поставим KPI, каждую неделю будем подводить итоги. И будем учиться достигать большего.

Тут надо сказать, что big boss из меня так себе. Да, до прихода в IT маркетинг я руководил работающей только на сайт командой из 5-8 человек в одной медийной компании. Но это были контент-менеджеры, они просто загружали готовый контент (его много было ежедневно), ну был еще рерайтер на новости. Там никаких бестпрактик и KPI не было. Соответственно и требования к персоналу были не высокие. Здесь же требовалось высокое качество исполнения.

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

И остался я в какой-то момент - один одинёшенек.

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

Проблема была в том, что у меня не было никакой методологии, а была только профессиональная интуиция, ну и кое-какие навыки работы руками. Это очень мало для создания команды, а тем более для масштабирования.

Пришлось много думать, очень много думать. Думать до работы, думать после работы, думать после того, как проснулся, думать перед тем, как заснуть.

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

Мистер очевидность понял, что надо научиться все цифровывать.

Ладно, вру, не сам додумался, в корпорации где я успел поработать, мой менеджер так всегда делал и я у него подсмотрел.

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

В итоге я изобрел следующий велосипед:

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

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

  3. Теперь нам нужно понять критерии, хорошо ли у нас идет процесс или нет и понять это как можно раньше.
    Тут вот какое дело: результат всегда можно посмотреть - увеличилось или нет количество лидов нужного качества из нужного региона по SEO.
    А вот понять, какой отрезок процесса можно оптимизировать - уже сложнее.

Итогом стала оцифровка процесса работы сеошника, процесса работы отдела и ожидаемых результатов работы.

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

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

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

Что и в каком порядке должен делать SEO специалист в команде

Все активности сеошника я делю на 4 категории:

  1. keyword analysis (сбор семантического ядра).

  2. SEO competitor analysis (анализ конкурентов).

  3. keyword position tracking (анализ результатов SEO-работы).

  4. Другие активности.

Keyword Analysis

Для данной активности признаком завершенной работы является наличие:

  1. Списка слов, по которым планируется продвижение (выход в топ-3 и выше) в этом месяце, потому что именно эти позиции дают максимум трафика.

  2. Обоснования, почему нужно фокусироваться именно на этих словах.

  3. Списка страниц сайтов, которые уже занимают необходимые нам места в топ-3 в нужном нам регионе нужного нам поисковика (Google USA). Это, в первую очередь, список страниц сайтов наших конкурентов.

Давайте остановимся на этой категории подробнее

Надо ли объяснять, зачем продвигать отдельные страницы по отдельным словам?

На всякий случай поясню: потому что существуют слова, которые могут конвертить (т.е. превращать посетителя сайта в лида, который при должной отработке сейлзами станет клиентом). Это не является неким секретом. На слайде ниже виден пример, как это работает, из реальной жизни.

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

Выглядит все сравнительно просто, если не обращать внимание на маленький нюанс: вероятность того, что вы точно узнаете, по какому слову к вам пришли из поиска ваши клиенты, близится к нулю.

Сделал Google это нарочно еще в 2013 году, потому что понял очень простую вещь если слова генерят клиентов, зачем бесплатно отдавать информацию о таких словах владельцам сайтов, пусть узнают о них только заказав услуги поисковой рекламы у Google. Заказ контекста у Google работает, вещь хорошая, если бы не пару проблем: стоимость клика в нашей нише может быть и 20, и 50, и более у.е. за слово. При этом не каждый клик приносит лида и не каждый клик является кликом от человека, а не робота (проблема скликивания бюджета практически не решена в Google Ads). Я уж молчу про особенности алгоритмов Google Ads, которые при наличии конкуренции не будут давать вам гарантированно первое место по словам (даже если вы переплатите), если ваш контент плохо соответствует этим словам.

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

Что вам остается в этой ситуации?

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

Тут возникает другая проблема. Если у нас на сайте сотни страниц и каждая страница может продвигаться по целому списку слов, то этот метод не выглядит рабочим. Это сколько же надо ресурсов, чтобы за всем уследить!

Но благо она решаема не силой, а умом. Решение в свое время сформулировал один известный сеошник Brian Dean: вам не надо сотни постов, у меня 40 постов, которые дают мне трафик в 100 000 человек в месяц.

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

Тут возникают четыре проблемы:

1. Как определить, какие страницы приносят больше всего лидов сейчас?

2. Что надо сделать, чтобы они приносили еще больше лидов?

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

4. Что надо сделать, чтобы страницы, не приносящие лидов вообще, начали приносить хоть сколько-то лидов для начала?

Давайте обо всем по порядку.

Какие cтраницы приносят вам больше всего лидов сейчас?

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

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

Чтобы быстро получать такой отчет (и целый ряд других), мы разработали свой универсальный Business Intelligence Tool (BI), который подключается к базе данных нашего сайта (CRM) и автоматически выдает нам необходимые данные для принятия решений.

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

Что надо сделать, чтобы лидогенерирующие страницы приносили еще больше лидов?

Я лично вижу только два варианта:

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

  2. Эта страница должна иметь потенциал конвертить максимальное количество трафика по этим словам.

Как видим, здесь работа, как минимум, для трех специалистов:

  1. Сеошник должен определить лидогенерирующие слова и предложить SEO ТЗ после анализа конкурентов для копирайтера.

  2. Копирайтер должен не просто вставить слова в текст, но и повысить конвертирующую способность содержимого этой страницы (сonversion rate optimization), т.е. должен быть маркетингоориентированным.

  3. Дизайнер должен визуально контент упаковать наиболее эффективным способом, т.е. должен быть маркетингоориентированным.

Я понимаю, что все вышеизложенное может звучать чересчур теоретизированно, поэтому предлагаю рассмотреть следующий пример из практики.

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

Для этого выгрузим отчет из нашей аналитики и посмотрим, какие позиции по каким словам она занимала по итогам месяца и что это за слова.

С помощью нашего BI solution я автоматически (т.е. не свожу вручную данные из разных таблиц) за 5 минут получаю сведенные данные из Google Search Console и Google Keyword Planner. Это список из более чем 200 слов (на слайде показаны только 9), по которым у нас наибольшее количество показов нашей страницы в нужном нам регионе (Google USA). У нас много impressions? Значит, можем сформулировать гипотезу: Google считает нас высокорелеватными, но надо поднажать, и мы получим результат быстрее, чем если будем делать что-то другое.

Как анализировать этот, в общем-то, типовой отчет?

Сначала мы смотрим, какие слова из перечисленных имеют наибольший Volume. Как видим, это php development company (volume или прогнозируемый спрос равен 210 запросом в месяц) и php development companies (тоже 210).

Эти слова похожи на лидогенерирующие (человек конкретно ищет компанию), аналитика даже показывает, что по этому слову есть клики (при этом стоимость клика, если бы мы покупали рекламу по этому слову в Google ADS доходит до 48.53 у.е. за один клик!).

Формулируем гипотезу, что по слову php development company мы можем продвинуться быстрее в топ-3 и выше, потому что мы уже между 5 и 6 позицией в среднем за месяц. При этом количество impressions на этой позиции этой страницы в этом регионе 539, что больше search volume, а не меньше (т.е. показы не случайны, стабильны, место стабильно).

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

Таким же образом мы проходим по каждому слову и по каждой необходимой нам странице и получаем список слов для продвижения в этом месяце.

Далее задача будет заключаться в том, что сеошник должен копирайтеру составить ТЗ, в котором указать по каждому слову список страниц конкурентов, которые уже в топ-3 по этому слову в необходимом регионе (как правильно снять выдачу в условиях персонализированной выдачи Google это отдельный квест) и бонусом список всех конкурентов из рекламной выдачи.

Если анализ SEO-выдачи может дать представление нам о SEO-показателях, позволивших этой странице выйти в топ, то анализ рекламной выдачи - дать инсайты о методах конверсии, которые мы можем применить в своих статьях.

Пример: проанализировав итоги января, мы определили, что по слову php development company в США:

По такому же принципу мы подготовили выгрузку по другим необходимым нам словам.

Копирайтеры теперь смогут посмотреть, как тексты конкурентов отличаются от наших текстов, сравнив их и улучшив не только по SEO, но и конверсионно.

Кроме того, им можно подготовить SEO ТЗ на основе данного анализа с указанием, например, частотности и других параметров.

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

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

По факту статьи-лендинг по PHP разработке не приносит нам лидов. Хотя по большому количеству слов в топ-3. Что это означает?

Это означает, что нахождение в топ-3 по лидогенерирующим словам не означает автоматически, что у вас появятся лидыПосле такого вывода на SEO хочется поставить крест.

А может быть, не на SEO, а на методологии? Может, методология ошибочна, когда SEO сводится к выводу в топ-3 по лидогенерирующим словам?

Не спешите с выводами.

На самом деле, с методологией все в порядке. У нас, как минимум, осталась одна крупная гипотеза, почему так происходит с этой страницей (а с другим лендингами в топе так не происходит).

Дело в том, что выше нас находятся страницы с более серьезным ценностным предложением (как в рекламе, так и в SEO) и CTA (элементами призыва к действию). А это уже маркетинговые дела, более того, затрагивающие в целом бренд. В итоге наш посетитель удовлетворен результатами тех, кто в топ-1 и в рекламе, а нас уже не включает в свой short-лист кандидатов на рассмотрение.

Если бы мы делали сейчас ставку на PHP development, мы бы увидели, что страница находится в топ-3 по лидогенерирующим словам, но не приносит лидов.

Это означало бы, что мы должны включить эту страницу в свой ближайший план на продвижение по SEO (из топ-3 в топ-1, из топ-10 в топ-3 и так далее) и по увеличению конверсии.

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

Что надо сделать, чтобы страницы, не приносящие лидов вообще, начали приносить хоть сколько-то лидов для начала?

У любого сайта (кроме нового или того, над которым работа ведется неправильно либо недостаточно) всегда есть четыре типа страниц по параметру SEO / конверсии:

1. страницы, приносящие лидов;

2. страницы, не приносящие лидов, хоть и находящиеся в топ-3 по лидогенерирующим словам;

3. страницы, не приносящие лидов и не в топ-3 по лидогенерирующим словам, но находящиеся в индексе поисковой системы по этим словам, например, в топ-10 или ниже;

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

Третий тип страниц самый частый. Впрочем, как и четвертый.

Но третий самый болезненный для бизнеса. Работа работалась, зарплата платилась, контент размещался. Лидов как не было, так и нет.

Поэтому больше всего на свете любого сеошника и маркетолога интересует, как продвигать эти страницы, как обеспечить их вывод в топ? Желательно быстро и недорого.

Но больше, чем сеошника и маркетолога, это интересует владельца бизнеса.

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

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

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

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

К сожалению, я не знаю быстрых и недорогих способов, дающих надежный результат.

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

Да, можно купить много недорогого контента, но вспомним слова Брайана, которые я привел выше.

Зато я знаю работающий, да, долгий и дорогой, но надежный способ:

  1. Разумеется, сначала нам надо определить, лидов на какое направление мы хотим привлекать. Предположим, мы определили, это Custom Business Intelligence Development.

  2. Предположим, у нас на сайте нет ни одной страницы по этому направлению (у нас так было какое-то время назад).

  3. Для начала нам надо определить, есть ли вообще в нише спрос на кастомную разработку. Как мы это можем сделать?

  4. Сначала собрать семантическое ядро. Для этого подойдет тулза типа Semrush.

  5. Мы нашли, к примеру, слово custom business intelligence. По внешнему виду наиболее лидогенерирующее слово из топика, да еще имеет 30 запросов в месяц в Google USA. Перепроверяем спрос через Keyword Planner (Semrush периодически врет) запросов всего 10, ну, тоже неплохо.

  6. Делаем стандартный срез рынка по этому слову.

7. Делаем вывод: рынок есть (так как есть конкуренты). Конкуренты предлагают в основном кастомизировать свои готовые решения, а не просто с нуля что-то создавать. Делаем вывод, что без наличия своего готового решения, которое можно быстро кастомизировать, выход на рынок будет высококонкурентным занятием. Так как для всех сегментов рынка такое решение создать сложно, надо сконцентрироваться на нескольких. И маркетинговая стратегия должна включать создание контента не только и не столько для тех, кто уже хочет заказать кастом, сколько для тех, кто еще находится на ранней стадии воронки продаж (хочет узнать, что такое BI, как им получить бизнес-результат именно в их нише и так далее). То есть это процесс nurturing или взращивания лидов. Он никак не будет быстрым.

А что же должен делать сеошник в этой ситуации?

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

И здесь мы плавно переходим к следующей категории активностей сеошника: анализу SEO конкурентов.

Резюме. Надеюсь, я смог объяснить, почему я считаю, что, во-первых, keyword analysis должен быть первым в списке активностей сеошника, во-вторых, почему результатом активности keyword analysis должен быть список слов, по которым планируется продвижение в текущем месяце, в-третьих, как должно выглядеть объяснение, почему именно эти слова мы должны продвигать, и в-четвертых, зачем нужны списки страниц, которые уже в топ-3 по каждому из этих слов.

SEO Competitor Analysis

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

Конечно, всегда проще улучшать то, что есть. Если у сеошника уже есть сайт с контентом, который надо улучшить, он может проанализировать через ту же Google Search Console+Keyword Planner, по каким лидогенерирующим словам он уже ранжируется, чтобы выбрать слова для приоритетного продвижения и соответствующие страницы.

Сложнее создавать что-то с нуля. В этом случае необходимо не просто искать слова, но и сразу проверять выдачу: а есть ли там страницы конкурентов. И это работа сеошника.

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

Итого, только по результатам правильного анализа одного слова мы можем получить следующую информацию:

  1. Список страниц с рекламной выдачей и SEO-выдачей (до топ-3) по региону. Он нужен, чтобы создать с нуля свою аналогичную страницу или улучшить существующую. Список должен быть привязан к конкретному слову. По этому слову нужно показать данные по Volume, CPC и Competition из Keyword Planner.

  2. Список конкурентов, в приоритете от большего рейтинга домена до меньшего и чтобы было видно сравнение с вашим. В дальнейшем вам надо, в первую очередь, анализировать домены с рейтингом выше вашего, но если и ниже тоже можно смотреть, вдруг там увидите что-то интересное.

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

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

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

Keyword Position Tracking

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

Так мы плавно подходим к необходимости постоянного трекинга позиций. Если вы все равно считаете, что это не так важно, почитайте хотя бы мнение Ренда Фишкина, основателя MOZ и одного из самых уважаемых в SEO-сообществе специалистов.

Как и все в этом мире, анализ позиций нужно делать правильно.

Для данной активности признаком завершенной работы является наличие:

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

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

  3. Уведомление команды о том, что произошло резкое изменение позиций.

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

Здесь не обойтись без специальных инструментов. Мы не смогли найти подходящие инструменты, несмотря на огромный рынок готовых решений (тот же Semrush) и разработали свой BI solution c функцией трекинга. Интерфейсы бесплатных решений типа Google Search Console и даже Google Data Studio для этой задачи не подходят.

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

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

Мониторинг соответствующего отчета может также показать, что по ряду слов (выделено красным) мы резко попали в топ-3 для конкретной страницы. Это тоже повод уведомить отдел, что по определенному отслеживаемому слову у нас рост позиций и имеет смысл ковать железо, пока горячо и попытаться еще улучшить позиции до топ-1.

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

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

Но это все касается только тех слов, на которых мы заранее фокусируемся.

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

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

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

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

Однозначно, надо информировать остальной отдел о том, что нужно вставить в текущий план развития сайта дожимание позиций по этому слову до топ-10 и топ-3. Это выглядит как наиболее выгодное вложение инвестиций в данный момент не так часто удается увидеть, что по словам с большим трафиком ты двигаешься в топ.

Другие активности

Это последняя категория активности, а отнюдь не первая(за исключением случаев, когда с сайтом все действительно плохо, например, он не индексируется и так далее).И, соответственно, она должна выполняться в последнюю очередь, после того, как сделан перерыв в предыдущих активностях.

Что это за активности?

  • On-page optimization(расстановка ключей по тексту, оптимизация метатегов, сниппетов, повышение CTR, прописывание альтов, schema).

  • Off-page optimization(disavow токсичных ссылок, регистрация в простых каталогах, где есть конкуренты и DR которых выше, чем у нас). Здесь я не пишу про массовую закупку ссылок - мы это не практикуем. Мы стараемся писать контент, который сам обрастет ссылками. Речь про регистрации в белых каталогах, например, в нашей сфере, это clutch и другие.

  • Скорость сайта(постановка ТЗ программистам по увеличению скорости, при возможности самостоятельная оптимизация изображений в целом по сайту).

  • Технические ошибки(внедрение всех рекомендаций того же Semrush до 100% отсутствия ошибок).

  • Структура сайта(прописывание навигационных ссылок (хлебных крошек), мониторинг единообразия структуры сайта).

  • Оптимизация краулингового бюджета(отслеживание неработающих статей (ноль позиций) и формулировка рекомендаций: удалить или обновить).

Что нужно сделать, чтобы SEO стало каналом стабильной качественной лидогенерации для IT компании?

Я эту задачу сейчас решаю так.

1) Выберите одно главное тематическое направление, на которое вы будете тратить самое большое количество времени. Мы, например, выбрали направление Custom Elearning Software Development и ряд вспомогательных. Если вы выбрали несколько направлений, но выделили мало ресурсов, то вы не добьетесь результата ни по одному напарвлению. Увеличение количества направлений должно идти рука об руку с ростом количества персонала, их обрабатывающих.

2) Определите, у вас уже есть лиды на это направление с сайта или нет.

  • Если есть лиды уже - определилите, с каких страниц, т.е. какие страницы по этому направлению у вас самые конвертящие. Именно их вам надо будет улучшать: делать лучше контент (сравните с конкурентами и бестпрактиками), увеличивать количество ссылок на него с более авторитетных ресурсов, чем ваш, а также увеличивать количество лидогенерирующих ключевых слов в топ-3, по которому этот контент приносит трафик.

  • Если нет лидов еще - определите, отрабатывают ли по SEO те страницы, которые вы уже разместили на сайте и с которых хотите, чтобы были лиды? Это означает, находятся ли они в топ-3 нужного вам региона (например, Google USA) по нужным вам ключевым словам. Если не находятся, то вам надо бросить усилия, чтобы находились. Если находятся, вам нужно сравнить свой контент с конкурентами на предмет, у кого лучше уникальное торговое предложение. Нахождение в топ-3 даже по коммерческим словам еще не означает, что у вас будут лиды. Вам нужен хороший контент. Также вы должны максимально хорошо понимать, а действительно ли эти слова принесут вам лидов. И держать в голове, что всегда есть риск, что слова, которые вы определили как лидогенерирующие на самом деле такими не являются. Чтобы этот риск диверсифицировать, вам нужно стараться продвигаться сразу по относительного большому количеству слов.

3) Определите лидогенерирующие слова, которые могут принести вам лидов по вашему направлению.

  • Если ваша страница, с которой вы ждете лидов, уже показывалась, то выгрузите из нее статистику по словам с позициями и показами из Google Sarch Console и дополните их данным по спросу и кокнуренции из Keyword Planner. Это можно сделать вручную в Excel, но скучно, мы создали свое собственное BI решение, которое делает это автоматически и предоставляет актуальные данные, которых нет ни в одном из доступных решений, которые есть на рынке.

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

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

4) Анализируйте результаты продвижения каждый день, чтобы оперативно корректировать тактики.

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

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

5) Примите правильные решения по ресурсам.

Один сеошник вряд ли может увеличить лидов компании, особенно, если будет делать только техническое SEO. Нужен, как минимум, один копирайтер, а лучше два (а еще лучше не копирайтер, а журналист), нужен пиарщик. Нужен руководитель маркетингового отдела с готовой методологией, который выступает и как проект менеджер, и как ментор (если вы вынуждены брать с рынка не полностью готовых спецов, потому что или готовых нет, или они не хотят у вас работать - им и так хорошо, либо очень дорогие). Нужно, чтобы этот руководитель собрал именно команду, а не отдельных исполнителей и в этой команде было бы видно, как работа каждого влияет на работу другого и в целом на результаты команды. Естественно, у вас хотя бы парт-тайм должен быть дизайнер и программист, потому что сайту всегда нужны доработки, которые снимают рутину с отдела за счет автоматизации и позволяют заняться более творческими задачами. Дальше - больше. Вам нужна правильная методология линкбилдинга и бюджет на нее (мы вот планируем в качестве эксперимента взять на аутсорс это направление, уже нашли специалистов, но пока не использовали), вам также нужна правильная методология закупки рекламы и бюджет на нее (мы таких спецов нашли, но пока не использовали). И это касается только инбаунда. В идеале вам нужен еще аутбаунд, тот же линкедин, но это уже совсем другая история.

P.S. Поделитесь кармой или комментами, если вы хотите, чтобы я рассказал больше подробностей о том, как мы разрабатывали наше кастомное SEO / Marketing BI solution (относительно недорогое в разработке) на базе SQL Server (Data Warehouse+OLAP cube) и Excel, с какими сложностями мы столкнулись в его разработке, как оно сейчас работает и какие у нас на него планы.

Подробнее..

Перевод Бизнес-аналитика в управлении рисками Некоторые последние достижения (2014 год)

24.04.2021 16:07:19 | Автор: admin

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

Я не согласился с этим высказыванием так как, на мой взгляд, менеджмент создает систему метрик бизнес-аналитики с целью видеть векторы развития предприятия и скрытые проблемы, приводящие к снижению итоговых результатов. И если с помощью метрик вектора развития сложно конкретизировать, то кризисные явления идентифицируются достаточно надежно, при качественном исследовании исторических данных. То есть проявляется явная функция пространства метрик, показывающая зоны, в которые предприятию предпочтительно не попадать и система бизнес-метрик является инструментом риск-менеджмента. В настоящий момент технологии монетизации мероприятий риск-менеджмента хорошо отлажены. Так же ресурс Reports and Data прогнозирует объем рынка анализа рисков к 2026 в объеме 65 млрд. долл.

Посерфил обнаружил в сети, что существует всего лишь один университет, у которого есть программа обучения по данному курсу в The Hong Kong University of Science and Technology и нижепредставленную статью. После таких результатов мне стало ясно, что тема исследована слабо и причина в том, что риск-менеджмент отдельное направление с достаточно широким диапазоном и риски в операционной деятельности предприятия - подраздел этих мероприятий.

Чтобы читатель мог представить широту задач даю ссылку на статью об инструментах в этой области The 19 Best Risk Management Software of 2021.

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

Business intelligence in risk management: Some recent progresses (2014 год)

Предисловие

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

Ключевые слова: бизнес-аналитика, управление рисками, исследование операций.

1. Введение

Мы очень рады видеть завершение этого специального выпуска по информационным наукам: Бизнес-аналитика в управлении рисками. Риски существуют во всех аспектах нашей жизни и могут означать разные вещи для разных людей, хотя в негативном плане они всегда в целом причиняют большой потенциальный ущерб и неудобства для заинтересованных сторон. Например, недавние риски стихийных бедствий включают террористические акты, приведшие к отравлению газом в японском метро, терракту 11 сентября 2001 г., взрывам транспортных систем Испании и Великобритании, а также вирус атипичной пневмонии, нарушающий общественную и деловую деятельность, в частности в Азии.

Совсем недавно вирус H1N1 обострил осведомленность о системе реагирования во всем мире, а глобальный финансовый кризис привел к рецессии во всех аспектах экономики (59).

Для управления рисками, с которыми сталкивается организация, требуются комплексные подходы, и иногда эффективные стратегии принятия рисков могут включать в себя новые бизнес-концепции, такие как управление корпоративными рисками. Большинство инструментов бизнес-аналитики использовалось для улучшения управления рисками, и инструменты управления рисками выигрывают от подходов бизнес-аналитики. Например, модели искусственного интеллекта, такие как нейронные сети и метод опорных векторов, широко используются для создания системы предварительного предупреждения, для мониторинга финансового состояния компании (38, 2, 36). Агентно-ориентированные теории используются в управлении рисками цепочки поставок (27, 34). Модели бизнес-аналитики также полезны для хеджирования финансовых рисков путем включения рыночных рисков, кредитных рисков и операционных рисков (59). Исследование инструментов бизнес-аналитики в области управления рисками полезно как практикам, так и академическим исследователям.

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

2. Риски и управление рисками

Все человеческие усилия связаны с неопределенностью и риском. В области производства продуктов питания наука добилась больших успехов в генетическом управлении. Но есть опасения по поводу некоторых манипуляций, связанных с различными взглядами, преобладающими во все мире. В Соединенных Штатах генетическое управление обычно рассматривается как способ получения качественных и продуктивных источников пищи более надежным способом. Тем не менее, существуют серьезные возражения против биоинженерных продуктов питания в Европе и Азии. Появились некоторые естественные болезни, например, коровье бешенство, с которыми очень трудно бороться. Степень достигнутого контроля часто оспаривается. В Европе существует строгий контроль над биоинженерией, но даже тогда произошел скандал по свиноводству, связанный с опасными кормами и запрещенными лекарствами (57). Риски, связанные с биоинженерией, являются важными факторами в пищевой цепочке (50, 14). Генетическое картирование предлагает огромный прорыв в мире науки, но сопряжено с политическими рисками в применении к управлению человеческими ресурсами (37).

Даже применение информационных технологий для лучшего управления рисками в оказании медицинской помощи сопряжено с рисками (54). Использование компьютерного управления применялось к летающим самолетам, но не всегда работало (13). Риски можно рассматривать как угрозы, но бизнес существует, чтобы справляться с рисками (45). В разных дисциплинах используются разные способы классификации рисков. Чтобы объяснить уроки управления рисками из кредитного кризиса, Jorion (26) классифицировал риски на: известные - известные, известные - неизвестные и неизвестные - неизвестные. Фактически это основано на степени риска и аналогично тому, что обсуждали Olson and Wu (45).

Мы предлагаем следующую общую классификацию рисков: отраслевые и качественные.

- Финансовые риски отраслевого кластера, в основном включают в себя всевозможные риски, связанные с финансовыми секторами и финансовыми аспектами в других секторах. Они включают, но не ограничивают рыночный риск, кредитный риск, операционный риск и риск ликвидности. Нефинансовые риски, включающие риски из источников, не связанных с финансами. К ним относятся, но не ограничиваются ими, политические риски, репетиционные риски, биоинженерные риски и риски стихийных бедствий.

- Качественные риски могут иметь четыре свойства: неопределенность, динамика, взаимосвязь и зависимость, а также сложность. Первые два свойства были широко признаны в межвременных моделях из областей поведенческих решений и поведенческой экономики (3); последние два свойства хорошо изучены в финансовых дисциплинах. Существование риска требует применения различные распределения теории вероятностей для моделирования рисков. Этот подход может быть датирован 1700-ми годами, что привело к созданию моделей событий Бернулли, Пуассона и Гаусса, а также общих распределений Парето и общих распределений экстремальных значений для моделирования экстремальных событий. Динамика рисков в основном предполагает использование теории стохастических процессов в управлении рисками. Это можно отнести к 1930-м годам, когда были разработаны Марковские процессы, броуновские движения и процессы Леви. Взаимосвязь и зависимость рисков имеет дело с корреляцией между факторами риска. Строятся различные функции связки, а также используются преобразования Фурье. Сложность риска требует дальнейшего управления за счет использования различных моделей, основанных на науке о сложности, таких как подходы к моделированию на основе агентских моделей.

Управление рисками можно определить как процесс идентификации, анализа и принятия или уменьшения неопределенности при принятии инвестиционных решений.

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

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

3. Различные точки зрения и инструменты

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

3.1. Системы раннего предупреждения

Во многих работах рассматривалась ценность систем раннего предупреждения как средства контроля риска. Krstevska (30) приводит их использование в макроэкономических моделях с учетом специфики экономики Македонии. Ряд моделей был реализован с помощью компьютерных систем. Flores (15) рассматривал раннее предупреждение в страховании с помощью стохастической оптимизации. Castell and Dacuycuy (9) анализировали механизмы макроэкономического и финансового надзора. Hua (23) рассмотрел методы, используемые для раннего предупреждения в сфере недвижимости. В рамках промышленного применения Xie et al. (61) описал процедуру выявления логистических рисков для малых и средних предприятий.

3.2. Анализ рисков на основе нейронных сетей

Нейронные сети - это инструменты искусственного интеллекта, которые оказались очень полезными для выявления закономерностей в сложных структурах данных, особенно тех, которые связаны с нелинейными отношениями. Schneidewind (51) представил результаты работ по применению нейронных сетей для оценки надежности программного обеспечения, цель которых заключалась в снижении риска провала проекта. Jin and Zhang (25) представили другое приложение, демонстрирующее ценность моделей искусственных нейронных сетей в проектах, в данном случае в проектах, предполагающих государственно-частное партнерство. К отраслевым приложениям относятся банки, использующие модели искусственных нейронных сетей для анализа приложений кредитных карт (62), что позволяет банкам более эффективно контролировать свои риски после пузыря 2008 года. Модели нейронных сетей также были объединены с приложениями для тестового майнинга, такими как Groth и Muntermann (20), где модель применялась к финансовому риску, в дейтрейдинге. (12) применили модели искусственных нейронных сетей для управления риском дефолта малых предприятий в Италии.

3.3. Принятие решений на основе рисков

Использование компьютерных средств для принятия решений на основе риска широко изучается в области информационных систем в качестве систем поддержки принятия решений с 1970-х годов (28,56) Warenski (58) использовал искусственный интеллект для другого применения анализа кредитного риска, в данном случае демонстрируя финансовое моделирование в целлюлозно-бумажной промышленности. Otim et al. (46) представили недавний анализ, специально посвященный оценке стоимости и риска инвестиций в информационные технологии. Такие инвестиции включают в себя сложный набор заинтересованных сторон, что приводит к необходимости учитывать политику организации. Kozhikode and Li (29) изучали роль политического плюрализма в экспансии коммерческих банков в Индии, включая рассмотрение управления рисками. Принятие отраслевых решений включает не только множество заинтересованных сторон, но и множество критериев (44), отчасти обусловленных самим существованием этих многочисленных заинтересованных сторон. Silvestri et al. (53) представили методику многокритериальной оценки рисков для анализа рисков в области безопасности производства. Lakemond et al. (32) дали метод учета риска при разработке продукта, позволяющий на ранней стадии оценить риск и другие проблемы.

3.4. Анализ рисков на основе игр

Nash создал одну из самых плодотворных работ в теории игр (42), изучив роль конкурентной стратегии. Эта хорошо изученная область является одной из основных направлений в менеджменте промышленными рисками. Zhao and Jianq (63) рассмотрели модель полной информационной игры без взаимодействия, которая рассматривает множество возникающих рисков в среде управления проектами. Merrick and Parnell (39) расширили теоретико-игровые модели, включив в них вероятностный анализ рисков в контексте борьбы с терроризмом. Их применение включало в себя экранирование контейнеров для радиологических материалов. Lin et al. (35) использовали теорию игр для моделирования вертикальной дифференциации в онлайн-рекламе, обнаружив, что более высокий уровень дохода от рекламы может привести к снижению цен на услуги. Теория игр также применялась Gnyawali and Park (19) к управлению рисками малых и средних предприятий.

3.5. Определение кредитного риска

Основная задача финансового сектора в управлении рисками - оценка вероятности дефолта. Gurny и Tichy (21) представили скоринговую модель для банков США с использованием линейного дискриминантного анализа. Chen et al. (11) предложили другое исследование, в данном случае с использованием методологии Six Sigma DMAIC для снижения финансового риска.

Wu and Olson (60) продемонстрировали, как прогностические системы оценки использовались для управления крупными банковскими рисками кредитоспособности. Caracota et al. (8) предоставили скоринговую модель для малых и средних предприятий, ищущих банковский кредит. Poon (48) проанализировал эффективность кредитного скоринга финансируемых государством предприятий (Freddie Mac и Fannie Mae), показывая, как скоринг кредитного бюро приводит к поддержке противоположных стратегий избегания риска и скупого инвестирования.

3.6. Data mining в управлении рисками предприятия

Data mining стал очень популярным средством применения инструментов статистического и искусственного интеллекта для анализа больших массивов данных. Среди множества приложений для управления рисками Shiri et al. (52) применили инструменты интеллектуального анализа данных к корпоративным финансам, включая выявление мошенничества в управлении, оценку кредитного риска и прогнозирование результатов деятельности компании. Jans et al. (24) сосредоточили свое исследование интеллектуального анализа данных на устранении риска внутреннего мошенничества, обнаружив, что инструменты интеллектуального анализа данных дают лучшие результаты, чем одномерный анализ. Holton (22) также обратился к профессиональному мошенничеству, применив интеллектуальный анализ текста для поддержки аудита мошенничества. В других отраслях Nateghi et al. (43) применили методы data mining для более точного прогнозирования отключений электроэнергии, особенно, связанных с ураганами. Ghadge et al. (17) проанализировали приложения для интеллектуального анализа текста для поддержки управления рисками в цепочках поставок. Два исследования специально посвящены использованию интеллектуального анализа данных для снижения риска профессиональных травм. (5, 41)

3.7. Агентно-ориентированное управление рисками

Искусственный интеллект часто реализуется с помощью агентных систем, в которых компьютеры имитируют людей, принимающих решения. Этот подход был применен к управлению рисками в цепочках поставок Smeureanu et al. (55) с конкретным исследованием риска банкротства компании-партнера. Giannakis and Louis (18) также рассмотрели управление рисками в цепочке поставок с помощью агентских моделей, в данном случае исследуя риски, присущие как спросу на ресурсы, так и их предложению в период экономических спадов. Агенты также были специально применены к имитационным моделям, что позволяет использовать имитационные модели для анализа более сложных проблем. Caporale et al. (7) представили оптимальную модель финансовых рынков в условиях кризиса, сочетающую моделирование и теорию игр через агентов. Родственным подходом является оптимизация роя частиц, которая была применена Chang Lee et al. (10) для управления проектными рисками и Kumar et al. (31) для разработки более надежных конструкций цепочек поставок. Было обнаружено, что этот подход позволяет моделировать более сложные ситуации. Mizgier et al. (40) прикладное агентно-ориентированное моделирование цепочек поставок, моделирующее риск банкротства фирм-участников саморазвивающихся сетей.

3.8. Анализ инженерных рисков на основе инструментов оптимизации

Инструменты оптимизации имеют фундаментальное значение для инженерных усилий по разработке более совершенных систем. (4) Существование неопределенности нарушает некоторые из требуемых допущений для многих моделей оптимизации. Наличие риска подразумевает наличие неопределенности, что затрудняет разработку моделей оптимизации. Однако были представлены модели оптимизации инженерных систем. Ahmadi and Kumar (1) представили модель, учитывающую повышенную вероятность отказа механических систем из-за старения. Buurman et al. (6) ввел основу для динамического стратегического планирования инженерных систем с использованием анализа реальных вариантов, обнаружив, что этот подход имеет значительные преимущества перед статическим проектированием. Popovic et al. (49) применили комплексную оптимизацию к системам обслуживания, связанным с риском.

3.9. Управление знаниями и data mining для управления рисками стихийных бедствий в промышленности

Управление знаниями - это очень широкая область исследования, развивающаяся от систем поддержки принятия решений, экспертных систем и искусственного интеллекта до интеллектуального анализа данных и бизнес-аналитики. Управление знаниями также включает в себя рассмотрение того, как неявные знания в организациях могут быть зафиксированы в компьютерных системах, таких как аргументация на основе конкретных случаев. Несколько статей можно найти в применении управления знаниями к управлению промышленными рисками. Folino et al. (16) использовали сеточные технологии в геонауках посредством интеллектуального анализа данных для анализа и управления стихийными бедствиями, такими как оползни, землетрясения, наводнения и лесные пожары. Их система предназначалась для оказания помощи в предотвращении стихийных бедствий и реагировании на них. Li et al. (33) сосредоточились на прогнозировании стихийных бедствий с использованием знаний предметной области и пространственных данных для разработки байесовской сети.

4. Краткое содержание статьи

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

В статье Динамическое моделирование рисков в проектах сопровождения ERP с помощью FCM, написанной Cristina Lopez and Jose Salmeron, изучаются риски в проектах планирования ресурсов предприятия (ERP). В частности, они построили нечеткие когнитивные карты (FCM) рисков обслуживания ERP. Главное преимущество FCM заключается в их способности моделировать сложные явления на основе мнений экспертов. Этот инструмент моделирует неопределенность и связанные с ней события, имитируя человеческое мышление. Предлагаемый инструмент специально моделирует результаты проекта технического обслуживания ERP и восприятие рисков, а также их скрытые взаимодействия. Авторы показывают, что FCMS позволяют разрабатывать упражнения по прогнозированию с помощью моделирования. Таким образом, специалисты-практики будут оценивать совместное влияние рисков обслуживания ERP на результаты проекта. Предлагаемый инструмент поможет специалистам-практикам более эффективно и проактивно управлять рисками проекта сопровождения ERP.

В статье Hybrid Kansei-SOM Model using Risk Management and Company Assessment for Stock Trading, авторами Hai Pham, Eric Cooper, Thang Cao и Katsuari Kamei, представлен новый метод торговли акциями с использованием оценки Kansei, интегрированной с самоорганизующейся моделью карты для совершенствования системы биржевой торговли. Предлагаемый подход направлен на объединение нескольких экспертных решений, достижение наибольшей доходности инвестиций и снижение потерь за счет работы со сложными ситуациями в динамичной рыночной среде. Оценка Kansei и модели нечеткой оценки применяются для количественной оценки чувствительности трейдера в отношении торговли акциями, рыночных условий и факторов фондового рынка с неопределенными рисками. В оценке Kansei групповая психология и чувствительность трейдеров измеряются количественно и представляются нечеткими весами. Наборы данных Kansei и фондового рынка визуализируются SOM вместе с совокупными экспертными предпочтениями для того, чтобы найти потенциальные компании, соответствующие торговым стратегиям в нужное время и исключающие рискованные акции.

Авторы апробируют предложенный подход в ежедневных биржевых торгах на фондовых рынках HOSE, HNX (Вьетнам), NYSE и NASDAQ (США). Авторы показывают, что новый подход применения оценки Kansei повышает возможности получения инвестиционной отдачи и снижает потери. Авторы также показывают, что предложенный подход работает лучше, чем другие современные методы, при работе с различными рыночными условиями.

В статье Модель анализа рисков безопасности для информационных систем: причинно-следственные связи факторов риска и анализ распространения уязвимости, авторами которой являются Nan Feng, Harry Jiannan Wang, and Minqiang Li, разработана модель анализа рисков безопасности для выявления причинно-следственных связей между факторами риска и анализа, сложность и неопределенность распространения уязвимости. В предложенной модели разработана байесовская сеть (BN) для одновременного определения факторов риска и их причинно-следственных связей на основе знаний из наблюдаемых случаев и экспертов в предметной области. Авторы проводят анализ распространения уязвимостей безопасности, чтобы определить путь распространения с наибольшей вероятностью и наибольшей подверженностью риску на пути. Оптимизация муравьиной колонии используется в SRAM для установления структуры BN и определения путей распространения уязвимостей и их вероятностей. SRAM позволяет организациям создавать планы упреждающего управления рисками безопасности для информационных систем.

В статье Calibration of the Agent-based Continuous Double Auction Stock Market Scaling Analysis, авторами которой являются Yuelei Li, Wei Zhang, Yongjie Zhang, Xiaotao Zhang, and Xiong, предлагается метод калибровки для фондового рынка с непрерывным двойным аукционом (CDA) и использованием агентов. масштабного анализ на основе работы Pasquini and Serva. (47) Авторы разрабатывают и строят фондовый рынок CDA, основанный на агентах, и используют тот же торговый механизм, что и китайский фондовый рынок. Авторы также проводят масштабный анализ абсолютной доходности, как на искусственных, так и на реальных фондовых рынках и показывают корреляции волатильности в виде степенных законов на всех рынках, где показатель степени не является уникальным, и все такие показатели следуют многомасштабному поведению.

5. Заключительные замечания

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

Благодарности

Приглашенные редакторы хотели бы поблагодарить всех рецензентов, включая Patrick Paulson, Karl Leung, Colin Johnson, Daniel Zeng, Guo H. Huang, Chuen-Min Huang, Ching Huei Huang, Xiaoding Wang, Chichen Wang, Guixiang Wang, Cheng Wang, Magnus Johnsson, Guangquan Zhang, Futai Zhang, and David Mercie.

Мы благодарим редактора W. Pedrycz, редактора специального выпуска P. P. Wang и руководителей журнала за их многочисленные ценные предложения и усилия по выпуску этого специального выпуска. Второй автор также признателен за поддержку исследований в виде гранта NSC 101-2410-H-004-010-MY2.

References

1 A. Ahmadi, U. Kumar, Cost based risk analysis to identify inspection and restoration intervals of hidden failures subject to aging, IEEE Transactions on Reliability 60 (1) (2011) 197209.

2. E. Alfaro, N. Garcia, M. Gamez, D. Elizondo, Bankruptcy forecasting: an empirical comparison of AdaBoost and neural networks, Decision Support Systems 45 (1) (2008) 110122.

3. M. Baucells, F.H. Heukamp, Probability and time tradeoff, SSRN working paper, 2009. http://ssrn.com/abstract=970570

4. Y. Ben-Haim, Doing our best: optimization and the management of risk, Risk Analysis: An International Journal 32 (8) (2012) 13261332.

5. M. Bevilacqua, F.E. Ciarapica, G. Giacchetta, Data mining for occupational injury risk: a case study, International Journal of Reliability, Quality & Safety Engineering 17 (4) (2010) 351380.

6. J. Buurman, S. Zhang, V. Babovic, Reducing risk through real options in systems design: the case of architecting a maritime domain protection system, Risk Analysis: An International Journal 29 (3) (2009) 366379.

7. G.M. Caporale, A. Serguieva, H. Wu, Financial contagion: evolutionary optimization of a multinational agent-based model, Intelligent Systems in Accounting, Finance & Management 16 (1/2) (2009) 111125.

8. R.C. Caracota, M. Dimitriu, M.R. Dinu, Building a scoring model for small and medium enterprises, Theoretical & Applied Economics 17 (9) (2010) 117128.

9. M.R.F. Castell, L.B. Dacuycuy, Exploring the use of exchange market pressure and RMU deviation indicator for early warning system (EWS) in the ASEAN+3 region, DLSU Business & Economics Review 18 (2) (2009) 130.

10. K. Chang Lee, N. Lee, H. Li, A particle swarm optimization-driven cognitive map approach to analyzing information systems project risk, Journal of the American Society for Information Science & Technology 60 (6) (2009) 12081221.

11. Y.C. Chen, S.C. Chen, M.Y. Huang, C.L. Tsai, Application of six sigma DMAIC methodology to reduce financial risk: a study of credit card usage in Taiwan, International Journal of Management 29 (2012) 166176.

12. F. Ciampi, N. Gordini, Small enterprise default prediction modeling through artificial neural networks: an empirical analysis of Italian small enterprises, Journal of Small Business Management 51 (1) (2013) 2345.

13. D. Dalcher, Why the pilot cannot be blamed: a cautionary note about excessive reliance on technology, International Journal of Risk Assessment and Management 7 (3) (2007) 350366.

14. A.L. Fletcher, Reinventing the pig: the negotiation of risks and rights in the USA xenotransplantation debate, International Journal of Risk Assessment and Management 7 (3) (2007) 341349.

15. C. Flores, Management of catastrophic risks considering the existence of early warning systems, Scandinavian Actuarial Journal 2009 (1) (2009) 3862.

16. G. Folino, A. Forestiero, G. Papuzzo, G. Spezzano, A grid portal for solving geoscience problems using distributed knowledge discovery services, Future Generation Computer Systems 26 (1) (2010) 8796.

17. A. Ghadge, S. Dani, R. Kalawsky, Supply chain risk management: present and future scope, International Journal of Logistics Management 23 (3) (2012) 313339.

18. M. Giannakis, M. Louis, A multi-agent based framework for supply chain risk management, Journal of Purchasing & Supply Management 17 (1) (2011) 2331.

19. D.R. Gnyawali, B. Park, Co-opetition and technological innovation in small and medium-sized enterprises: a multilevel conceptual model, Journal of Small Business Management 47 (3) (2009) 308330.

20. S.S. Groth, J. Muntermann, Intraday market risk management approach based on textual analysis, Decision Support Systems 50 (4) (2011) 680691.

21. P. Gurny, T. Tichy, Estimation of future PD of financial institutions on the basis of scoring model, in: 12th International Conference on Finance & Banking: Structural & Regional Impacts of Financial Crises, 2009, pp. 215228.

22. C. Holton, Identifying disgruntled employee systems fraud risk through text mining: a simple solution for a multi-billion dollar problem, Decision Support Systems 46 (4) (2009) 853864.

23. Y. Hua, On early-warning system for Chinese real estate, International Journal of Marketing Studies 3 (3) (2011) 189193.

24. M. Jans, N. Lybaert, K. Vanhoof, Internal fraud risk reduction: results of a data mining case study, International Journal of Accounting Information Systems 11 (1) (2010) 1741.

25. X.H. Jin, G. Zhang, Modelling optimal risk allocation in PPP projects using artificial neural networks, International Journal of Project Management 29 (5) (2011) 591603.

26. P. Jorion, Risk management lessons from the credit crisis, European Financial Management 15 (5) (2009) 923933.

27. N. Julka, R. Srinivasan, I. Karimi, Agent-based supply chain management-1: framework, Computers & Chemical Engineering 26 (12) (2002) 17551769.

28. P.G.W. Keen, M.S. Scott Morton, Decision Support Systems: An Organizational Perspective, Addison-Wesley, Reading, MA, 1978.

29. R.K. Kozhikode, J. Li, Political pluralism, public policies, and organizational choices: banking branch expansion in India, 19482003, Academy of Management Journal 55 (2) (2012) 339359.

30. A. Krstevska, Early warning systems: testing in practice, IUP Journal of Financial Risk Management 9 (2) (2012) 722.

31. S.K. Kumar, M.K. Tiwari, R.F. Babiceanu, Minimisation of supply chain cost with embedded risk using computational intelligence approaches, International Journal of Production Research 48 (13) (2010) 37173739.

32. N. Lakemond, T. Magnusson, G. Johansson, et al, Assessing interface challenges in product development projects, Research-Technology Management 56 (1) (2013) 4048.

33. L. Li, J. Wang, H. Leung, C. Jiang, Assessment of catastrophic risk using Bayesian network constructed from domain knowledge and spatial data, Risk Analysis: An International Journal 30 (7) (2010) 11571175.

34. W. Liang, C. Huang, Agent-based demand forecast in multi-echelon supply chain, Decision Support Systems 42 (1) (2006) 390407.

35. M. Lin, X. Ke, A.B. Whinston, Vertical differentiation and a comparison of on-line advertising models, Journal of Management Information Systems 29 (1) (2012) 195236.

36. P. Lin, J. Chen, FuzzyTree crossover for multi-valued stock valuation, Information Sciences 177 (5) (2007) 11931203.

37. K.S. Markel, L.A. Barclay, The intersection of risk management and human resources: an illustration using genetic mapping, International Journal of Risk Assessment and Management 7 (3) (2007) 326340.

38. D. Martens, B. Baesens, T. Van Gestel, J. Vanthienen, Comprehensible credit scoring models using rule extraction from support vector machines, European Journal of Operational Research 183 (3) (2007) 14661476.

39. J. Merrick, G.S. Parnell, A comparative analysis of PRA and intelligent adversary methods for counterterrorism risk management, Risk Analysis: An International Journal 31 (9) (2011) 14881510.

40. K.J. Mizgier, S.M. Wagner, J.A. Holyst, Modeling defaults of companies in multistage supply chain networks, International Journal of Production Economics 135 (1) (2012) 1423.

41. S. Murayama, K. Okuhara, J. Shibata, H. Ishii, Data mining for hazard elimination through text information in accident report, Asia Pacific Management Review 16 (1) (2011) 6581.

42. J. Nash, Equilibrium points in n-person games, Proceedings of the National Academy of Sciences 36 (1) (1950) 4849.

43. R. Nateghi, S.D. Guikema, S.M. Quiring, Comparison and validation of statistical methods for predicting power outage durations in the event of hurricanes, Risk Analysis: An International Journal 31 (12) (2011) 18971906.

44. D.L. Olson, Decision Aids for Selection Problems, Springer, NY, 1996.

45. D.L. Olson, D. Wu, Enterprise Risk Management Models, Springer, 2010.

46. S. Otim, K.E. Dow, V. Grover, J.A. Wong, The impact of information technology investments on downside risk of the firm: alternative measurement of the business value of IT, Journal of Management Information Systems 29 (1) (2012) 159194.

47. M. Pasquini, M. Serva, Multiscale behaviour of volatility autocorrelations in a financial market, Economics Letters 65 (3) (1999) 275279.

48. M. Poon, From new deal institutions to capital markets: commercial risk scores and the making of subprime mortgage finance, Accounting, Organizations & Society 34 (5) (2009) 654674.

49. V.M. Popovic, B.M. Vasic, B.B. Rakicevic, G.S. Vorotovic, Optimisation of maintenance concept choice using risk-decision factor A case study, International Journal of Systems Science 43 (10) (2012) 19131926.

50. L.A. Reilly, O. Courtenay, Husbandry practices, badger sett density and habitat composition as risk factors for transient and persistent bovine tuberculosis on UK cattle farms, Preventive Veterinary Medicine 80 (2-3) (2007) 129142.

51. N. Schneidewind, Applying neural networks to software reliability assessment, International Journal of Reliability, Quality & Safety Engineering 17 (4) (2010) 313329.

52. M.M. Shiri, M.T. Amini, M.B. Raftar, Data mining techniques and predicting corporate financial distress, Interdisciplinary Journal of Contemporary Research in Business 3 (12) (2012) 6168.

53. A. Silvestri, F. De Felice, A. Petrillo, Multi-criteria risk analysis to improve safety in manufacturing systems, International Journal of Production Research 50 (17) (2012) 48064821.

54. D.H. Smaltz, R. Carpenter, J. Saltz, Effective IT governance in healthcare organizations: a tale of two organizations, International Journal of Healthcare Technology Management 8 (1/2) (2007) 2041.

55. I. Smeureanu, G. Ruxanda, A. Diosteanu, C. Delcea, L.A. Cotfas, Intelligent agents and risk based model for supply chain management, Technological & Economic Development of Economy 18 (3) (2012) 452469.

56. R.H.J. Sprague, E.D. Carlson, Building Effective Decision Support Systems, Prentice-Hall, Englewood Cliffs, NJ, 1982.

57. G. Suder, D.W. Gillingham, Paradigms and paradoxes of agricultural risk governance, Internat Journal of Risk Assess Manage 7 (3) (2007) 444457.

58. L. Warenski, Relative uncertainty in term loan projection models: what lenders could tell risk managers, Journal of Experimental & Theoretical Artificial Intelligence 24 (4) (2012) 501511.

59. D. Wu, D.L. Olson, Introduction to the special section on optimizing risk management: methods and tools, Human and Ecological Risk Assessment 15 (2) (2009) 220226.

60. D. Wu, D.L. Olson, Enterprise risk management: coping with model risk in a large bank, Journal of the Operational Research Society 61 (2) (2010) 179190.

61. K. Xie, J. Liu, H. Peng, G. Chen, Y. Chen, Early-warning management of inner logistics risk in SMEs based on label-card system, Production Planning & Control 20 (4) (2009) 306319.

62. M. Yazici, Combination of discriminant analysis and artificial neural network in the analysis of credit card customers, European Journal of Finance & Banking Research 4 (4) (2011) 110.

63. L. Zhao, Y. Jiang, A game theoretic optimization model between project risk set and measurement, International Journal of Information Technology & Decision Making 8 (4) (2009) 769786.

Размышления переводчика

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

Когда указанные компании обращаются к BI-аналитику, то предоставляют все данные, которые они мониторят и других данных нет. На основе имеющихся данных BI-аналитик создает пространство метрик.

Это пространство может не только отслеживать текущие значения, но и также в ретроспективе. Простой ответ менеджмента на вопрос: Какие периоды в прошлой своей деятельности Вы считаете напряженными, кризисными? дают интервалы на которых, отследив показания метрик, можно с помощью скоринговых инструментов вычленить критические значения метрик. Далее привязываем полученные граничные значения к текущему мониторингу по принципу: нормально - зеленый, опасно - красный и пользователь получает работающий инструмент с детализацией участков, требующих обратить на них внимание.

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

Обратимся к прогнозу Reports and Data где объем рынка анализа рисков к 2026 в объеме 65 млрд.долл.

Чтобы представить в сравнении этот объем, скажу, что они прогнозируют:

- объем рынка автомобильных шин на 2028 год в объеме 118,09 млрд.долл.;

- объем рынка альтернативных двигателей для автомобилей на 2027 год в объеме 541,53 млрд.долл.

Подробнее..

Как построить современное аналитическое хранилище данных на базе Cloudera Hadoop

28.04.2021 12:07:29 | Автор: admin

Привет.

В конце прошлого года GlowByte и Газпромбанк сделали большой совместный доклад на конференции Big Data Days, посвященный созданию современного аналитического хранилища данных на базе экосистемы Cloudera Hadoop. В статье мы детальнее расскажем об опыте построения системы, о сложностях и вызовах с которыми пришлось столкнуться и преодолеть и о тех успехах и результатах, которых мы достигли..


Появление технологии Hadoop десятилетние назад вызвало на рынке интеграции данных небывалый ажиотаж и оптимизм. Индустрия задалась вопросом а готова ли технология вытеснить традиционные системы обработки данных?. За прошедшую декаду было сломано немало копий в этой битве. Кто-то успел разочароваться, кто-то добился локальных успехов, а тем временем сама экосистема прошла короткий, но стремительный эволюционный путь, который позволяет уверенно сказать, что в настоящий момент не существует задачи и вызова в области обработки и интеграции данных, которую не способен решить Hadoop.

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

Газпромбанк АО один их ведущих системообразующих финансовых институтов РФ. Он входит в топ-3 банков по активам России и всей Восточной Европы и имеет разветвленную сеть дочерних филиалов.

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

Розничный банковский сектор является высококонкурентным в РФ и для реализации стратегии Газпромбанку потребовалось создание новой технологической платформы, которая должна удовлетворять современным требованиям, так как основой интенсивного роста на конкурентном рынке могут быть только data driven процессы.

На тот момент в Банке уже было несколько платформ интеграции данных. Основная платформа КХД занята классическими, но критичными с точки зрения бизнеса задачами: управленческой, финансовой и регуляторной отчетности. Внесение изменения в текущую архитектуру КХД несло серьезные риски и финансовые затраты. Поэтому было принято решение разделить задачи и создавать аналитическую платформу с нуля.

Верхнеуровнево задачи ставились следующие:

  • Создание озера данных (как единой среды, в которой располагаются все необходимые для анализа данные);

  • Консолидации данных из озера в единую модель;

  • Создание аналитический инфраструктуры;

  • Интеграция с бизнес-приложениями;

  • Создание витрин данных;

  • Внедрение Self-service инструментов;

  • Создание Data Science окружения.

Этап проработки архитектуры важно начинать после консолидации и уточнения всех ключевых требований к системе. Требования были разделили на два больших блока:

Бизнес-требования

  • Обеспечение данными бизнес-приложений: аналитический CRM, Real Time Offer, Next Best Offer, розничный кредитный конвейер;

  • Возможность работы с сырыми данными из систем-источников as is (функция Data Lake);

  • Среда статистического моделирования;

  • Быстрое подключение новых систем источников к ландшафту;

  • Возможность обработки данных за всю историю хранения;

  • Единая модель консолидированных данных (аналитическое ядро);

  • Графовая аналитика;

  • Текстовая аналитика;

  • Обеспечение качества данных.

Требования ИТ

  • Высокая производительность при дешевом горизонтальном масштабировании;

  • Отказоустойчивость и высокая доступность;

  • Разделяемая нагрузка и гарантированный SLA;

  • ELT обработка и трансформация данных;

  • Совместимость с имеющимися Enterprise решениями (например, SAP Business Objects, SAS);

  • Ролевая модель доступа и полное обеспечение требований информационной безопасности.

Кроме этого, система должна быть линейно масштабируемой, основываться на open source технологиях, и самое главное соотношение стоимость\производительность должно быть самым конкурентным из всех предложений на рынке.

Для создания единой аналитической платформы розничного бизнеса мы выбрали стек Hadoop на базе дистрибутива Cloudera Data Hub

Архитектура решения

Рассмотрим архитектуру решения.

Рис. Архитектура

Система разделена на два кластера Cloudera Data Hub. Кластер регламентных процессов и Лаборатория данных

1. Кластер регламентных процессов

Все регламентные источники данных подключаются к данному кластеру. Все регламентные ETL расчеты также работают на этом контуре. Все системы потребители данных запитываются из регламентного кластера. Таким образом выполняется жесткая изоляция непредсказуемой пользовательской нагрузки от критичных бизнес процессов.

В настоящий момент к Hadoop подключено свыше 40-ка систем-источников с регламентом от t-1 день до t-15 минут для batch загрузки, а также real-time интеграция с процессинговым центром. Регламентный контур поставляет данные во все системы розничного бизнеса:

  • Аналитический CRM;

  • Розничный кредитный конвейер;

  • Антифрод система;

  • Система принятия решений;

  • Collection;

  • MDM;

  • Система графовой аналитики;

  • Система текстовой аналитики;

  • BI отчетность

2. Кластер пользовательских экспериментов Лаборатория данных

В то же время, все данные которые загружаются на регламентный контур в режиме онлайн реплицируются на контур пользовательских экспериментов. Задержка по времени минимальная и зависит только от пропускной способности сетевого канала тк контур лаборатории данных находится в другом ЦОДе. Те пользовательский контур одновременно выполняет роль Disaster Recovery плеча в случае выхода из строя основного ЦОДа.

Дата инженеры и дата science специалисты получают все необходимые данные для проведения своих исследований и проверки гипотез без задержки и без ожидания днями и неделями, когда нужные им данные для расчетов или тренировки моделей куда то выгрузят. Они доступны все в одном месте и всегда свежие. Дополнительно на кластере лаборатории данных создаются пользовательские песочницы, где можно создавать и свои объекты. Также ресурсы кластера распределены именно для высококонкурентной пользовательской нагрузки. На регламентный кластер у пользовательского доступа нет.

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

Дополнительно на контуре лаборатории создано окружение управления жизненным циклом моделей, окружение пользовательских аналитических приложений с управлением ресурсами на K8S, подключены два специализированных узла с GPU ускорением для обучения моделей.

Система мониторинга и управления кластерами, загрузками, ETL, реализована на дополнительных виртуальных машинах, не включенных напрямую в кластера Cloudera.

Сейчас версия дистрибутива CDH 5.16.1. В архитектурный подход закладывалась ситуация выхода из строя двух любых узлов без последующей остановки системы.

Характеристики Data узлов следующие: CPU 2x22 Cores 768Gb RAM SAS HDD 12x4Tb. Все собрано в HPE DL380 в соответствии с рекомендациями Cloudera Enterprise Reference Architecture for Bare Metal Deployments. Такой необычный, как кому-то может показаться, сайзинг связан с выбором подхода по ETL и процессингового движка для работы с данными. Об этом немного ниже. Необычность его в том, что вместо 100500 маленьких узлов, мы выбираем меньше узлов, но сами узлы жирнее.

Основные технические вызовы

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

  • Выбор основного процессингового движка в Hadoop;

  • Подход по трансформации данных (ETL);

  • Репликация данных Система-источник > Hadoop и Hadoop > Hadoop;

  • Изоляция изменений и консистентность данных;

  • Управление конкурентной нагрузкой;

  • Обеспечение требований информационной безопасности

Далее рассмотрим каждый из этих пунктов детально.

Выбор основного процессингового движка

Горький опыт первых попыток некоторых игроков реализовать ХД в Hadoop 1.0 показал, что нельзя построить систему обработки данных руками java программистов, не имеющих опыта построения классических ХД за плечами, не понимающих базовых понятий жизненного цикла данных, не способных отличить дебит от кредита или рассчитать просрочку. Следовательно, для успеха нам надо сформировать команду специалистов по данным, понимающих нашу предметную область и использовать язык структурированных запросов SQL.

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

Для нас это означало что необходимо выбрать правильный SQL движок для работы с данными в Hadoop. Остановили свой выбор на движке Impala так как он имеет ряд конкурентных преимуществ. Ну и собственно ориентация на Impala во многом и предопределила выбор в пользу Cloudera как дистрибутива Hadoop для построения аналитического хранилища.

Чем же Impala так хороша?

Impala движок распределенных вычислений, работающий напрямую с данными HDFS, а не транслирующий команды в другой фреймворк вроде MapReduce, TEZ или SPARK.

Impala движок который большинство всех операций выполняет в памяти.

Impala читает только те блоки Parquet, которые удовлетворяют условиям выборки и соединений (bloom фильтрация, динамическая фильтрация), а не поднимает для обработки весь массив данных. Поэтому в большинстве аналитических задач на практике Impala быстрее чем другие традиционные MPP движки вроде Teradata или GreenPlum.

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

Движок не разделяет общие ресурсы Hadoop с другими сервисами так как не использует YARN и имеет свой ресурсный менеджмент. Это обеспечивает предсказуемую высоко конкурентную нагрузку.

Синтаксис SQL настолько близок к традиционным движкам, что на подготовку разработчика или аналитика, имеющего опыт другой SQL системы, уходит не больше 3-4х часов.

Вот как работа с Hadoop выглядит глазами аналитика:

Рис. Работа с Impala SQL в Hue

Это работа в веб-ноутбуке Hue, который идет вместе с Cloudera. Не обделены и те пользователи, кто предпочитает работать с классическими толстыми SQL клиентами или сводными таблицами Excel.

Рис. SQL доступ к Hadoop в локальном толстом клиенте.

Многие кто читал рекомендации Cloudera могут задаться вопросом а почему Impala не рекомендована как ETL движок, а только как движок пользовательского ad-hoc или BI доступа? Ответ на самом деле прост - Impala не имеет гарантии исполнения запроса чтобы не стало в отличие от Hive. Eсли падает запрос или узел, то запрос автоматически не перезапустится и поднимать его надо вручную.

Это проблема легко решаема ETL поток или запрос в приложении должны уметь перезапускаться в таких ситуациях.

ETL потоки в нашем решении перезапускаются без вмешательства администратора автоматически:

  • При падении запроса происходит автоматический анализ причины;

  • При необходимости автоматически подбираются параметры конкретного запроса или параметры сессии чтобы повторный перезапуск отработал без ошибок;

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

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

Подход по трансформации данных

В разработке трансформации данных важно не только выбрать правильный движок, но и принять правильные стандарты разработки. У нас давно сформировался подход к таким задачам как metadata driven E-L-T при котором трансформация данных отрисовывается в диаграмме ETL инструмента, который в свою очередь генерирует SQL и запускает его в среде исполнения. При этом SQL должен быть максимально оптимальным с точки зрения конкретной среды исполнения. На рынке не так много ETL инструментов, позволяющих управлять генерацией SQL. В данном внедрении использовался инструмент SAS Data Integration.

Весь регламентный ETL выполнен в подходе metadata driven ELT. Никаких ручных скриптов с планировкой на airflow!

Такой подход позволяет

  • Автоматизировать процессы управления метаданными;

  • Автоматизировать процесс построения lineage данных как средствами самого ETL инструмента, так и средствами доступа к API;

  • Повысить качество процессов внесения изменений и управления данными т.к. вся информация о зависимостях всех объектов и всех jobв хранится в метаданных ETL инструмента.

  • Использовать CI/CD процессы в разработке

Рис. Примеры диаграмм ETL процессов

SAS DI позволяет визуализировать граф зависимостей в штатном функционале или можно выгрузить метаданные через API и использовать их для анализа в других средах.

Рис. Граф зависимостей объектов.

Репликация данных

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

Для этой функции был разработан специализированный инструмент Data Replicator. Инструмент позволяет в очень короткие сроки подключать системы источники и настраивать загрузку данных в Hadoop.

Из возможностей

  • Синхронизация метаданных с источника;

  • Встроенные механизмы контроля качества загруженных данных;

  • Загрузка в различных режимах работы в т.ч. полная копия, извлечение и загрузка инкремента (по любой скалярной детерминированной функции), архивация данных источника и т.д.

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

Другая очень важная функция Data Replicatorа - автоматическая репликация данных с регламентного кластера Hadoop на DR кластер. Данные, загружаемые из систем-источников реплицируются автоматически, для деривативных данных существует API. Все регламентные ETL процессы, при обновлении целевой таблицы вызывают API которое запускает процесс мгновенного копирования изменений на резервный контур. Таким образом, DR кластер, который так же выполняет роль пользовательской песочницы, всегда имеет свежие данные.

Нами реализовано множество конфигураций для различных СУБД используемых как источники в ГПБ, также для других процессинговых движков Hadoop (для случаев когда другой кластер Hadoop является источником данных для системы) и есть возможность обрабатывать данные, загруженные в систему другими инструментами, например kafka, flume, или промышленный ETL tool.

Изоляция изменений и консистентность

Любой кто работал в Hadoop сталкивался с проблемой конкурентного доступа к данным. Когда пользователь читает таблицу, а другая сессия пытается туда записать данные, то происходит блокировка таблицы (в случае Hive) либо пользовательский запрос падает (в случае Impala).

Самое распространенное решение на практике выделение регламентных окон на загрузку во время которых не допускается работа пользователей, либо каждая новая порция загрузки записывается в новую партицию. Для нас первый подход неприемлем тк мы должны гарантировать доступность данных 24х7 как по загрузке так и по доступу. Второй подход не применим т.к. он предполагает секционирование данных только по дате\порции загрузке, что неприемлемо если требуется отличное секционирование (по первичному ключу, по системе источнику и т.д.). Так же второй метод приводит к избыточному хранению данных.

Забегая вперед хочется отметить, что в настоящее время в HIVE 3 проблемы решена путем добавления поддержки ACID транзакционности, но, в нашей версии дистрибутива у нас далеко не третий Hive (да еще и на Map Reduce), а хотим получить высокую производительность и конкурентную нагрузку и поэтому нам пришлось реализовать ACID для Impala в Hadoop самостоятельно.

В нашем решении изоляция выполнена с применением подхода HDFS snapshot и разделения слоя хранения и доступа к данным через VIEW.

Когда данные записываются в HDFS, сразу, мгновенно создается снапшот на который переключается VIEW.

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

Все что остается делать это переключать VIEW на новые HDFS снапшоты, число которых определяется максимальной длительностью пользовательских запросов и частотой обновления данных в Hadoop. Те в сухом остатке мы получаем аналог UNDO в Oracle, retention период которого зависит от количества снапшотов и регламента загрузки данных.

Основной секрет в том, что как только процессинговый движок определил какие данные из HDFS он должен прочитать, после этого DDL VIEW или таблицы может быть изменен т.к. оптимизатор больше не будет обращаться к словарю metastore. Т.е. можно выполнить переключение VIEW на другую директорию.

Функционал HDFS Snapshot настолько легковесный и быстрый что позволяет создавать сотни снапшотов в минуту и никак не влияет на производительность системы.

Изоляции изменений в нашем решении также является функцией DataReplictorа. Все загружаемые данные изолируются автоматически, причем на обеих контурах системы, а производные ETL данные изолируются через вызов API. Каждое изменение целевого объекта, которое происходит в рамках ETL процесса завершается вызовом API по созданию снапшота и переключению VIEW.

Благодаря такому решению, все загрузки и все данные доступны в режиме 24х7 без регламентных окон. HDFS снапшоты не приводят к большому избыточному хранению данных в HDFS. Наш опыт показал, что для часто меняющихся регламентных данных хранение снапшотов за трое суток приводит к увеличению размера максимум на 25%.

Управление конкурентной нагрузкой

Следующий большой блок требований управление конкурентной нагрузкой.

На практике это означает что нужно обеспечить

  • Предсказуемую работу регламентных процессов;

  • Приоритизация пользователей в зависимости от принадлежности к ресурсной группе;

  • Отсутствие, минимизация или управление отказами в обслуживании;

Как это обеспечено на практике

  • Настроено разделение ресурсов между сервисами Hadoop на уровне ОС через cgroups;

  • Правильное распределение памяти между нуждами ОС и Hadoop;

  • Правильное распределение памяти внутри кластера между служебными сервисами Hadoop, YARN приложениями и Impala;

  • Выделение ресурсных пулов Impala отдельным пользовательским группам для гарантии обслуживания и приоритизация запросов

Результат предсказуемая высококонкурентная нагрузка десятков пользователей одновременно и десятков тысяч ETL запросов в сутки без влияния на другие составляющие экосистемы Cloudera.

Ри. Количество SQL запросов, завершающихся каждую секунду.

В настоящий момент на кластере регламентных расчетов в сутки регистрируется и успешно выполняется в среднем 900 тыс SQL запросов по трансформации и загрузке данных. В дни массовых загрузок и расчетов эта цифра поднимается до полутора миллионов.

Рис. Средняя утилизация CPU за сутки

При этом мы видим, что остается внушительный запас по производительности с тз возможностей повышения конкурентной работы. Есть понимание что это может быть и 1,5 млн и 2 млн запросов. Это означает что выбранный подход оказался верным и пропускная способность системы как и ее предсказуемость под нагрузкой показывает выдающиеся результаты.

Информационная безопасность

В финансовом секторе традиционно вопросы информационной безопасности являются одними из самых ключевых тк приходится работать с данными, которые не только подлежат защите с тз федерального законодательства, но и с требованиями, которые периодически ужесточаются госрегулятором. При выборе дистрибутива Hadoop стоит особое внимание уделять этим требованиям, так как большинство не вендорских сборок, либо сборок, спроектированных на базе популярных open source дистрибутивов (например Apache Big Top) не позволяют закрывать часть требований и при выводе системы в промышленную эксплуатацию можно столкнуться с неприятными сюрпризами недопуска системы от службы ИБ.

В кластере Cloudera нами были реализованные следующие требования:

  • Ролевая модель доступа к данным

    • Все пользователи включены в группы Active Directory (AD) каталога;

    • Группы AD зарегистрированы в Sentry;

    • В Sentry выполнено разграничение доступа для баз Impala и директорий HDFS;

    • Каждый Target слой данных имеет ролевые слои VIEW с ограничениями на чувствительные данные в соответствии с ролевой моделью доступа;

  • Кластеры керберизированы;

  • Подключение клиентских приложений только с применением SSL шифрования. Также шифрование используется при передачи данных внутри кластера.

  • Выполняется парсинг и приведение всех журналов сервисов Hadoop к единому реляционному формату стандартного журнала ИБ (единая точка интеграции для системы сбора данных ИБ)

    • Пользовательские запросы;

    • Запросы ETL;

    • Точки интеграции Hadoop с другими системами;

  • Все серверы, ОС, компоненты и прикладное ПО настроены в соответствии с согласованными профилями информационной безопасности и периодически проходят проверку на предмет известных уязвимостей.

Единый аналитический слой данных

Наличие общего слоя консолидированных данных основное требование аналитического ХД.

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

Был разработан единый аналитический слой консолидированных данных. Источником для него является копия детального слой КХД, которая регулярно реплицируется в среду Hadoop, а также дополнительные источники, подключаемые напрямую, минуя КХД.

Модель ориентирована на пользовательский ad-hoc доступ и проектировалась с учетом требований типовых задач клиентской аналитики, риск моделей, скоринга.

Реализованы все области данных, необходимые для решения задач розничного бизнеса и моделирования такие как:

  • Аккредитивы

  • Депозиты

  • Залоги

  • Заявки

  • Карты

  • Контрагенты

  • MDM

  • Кредиты

  • Сегмент клиента

  • Рейтинги

  • Агрегаты

  • Справочники

  • Счета

  • Эквайринг

  • Векселя

  • РЕПО

  • Резервы

В настоящий момент слой состоит из 177 целевых объектов и порядка 2350 бизнес-атрибутов. В snappy сжатии объем данных порядка 20 Тб (не менее 100 Тб в RAW).

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

Реализованный единый слой - источник данных для производных прикладных витрин под бизнес-приложения, отчетность и модели. Сейчас у нас около 40 производных регламентных витрин, состоящих из 550 целевых таблиц и примерно 13200 атрибутов.

Надежность

Часто приходится слушать о ненадежности решений, спроектированных на Hadoop. За два года эксплуатации Cloudera Data Hub у нас практически не было каких-либо проблем, связанных с простоем системы. Случилось буквально пара инцидентов, повлиявших не регламентные процессы.

Один раз у нас забилось место, выделенное под БД metastore (недостатки мониторинга).

В другой раз была попытка выгрузить несколько сотен миллионов транзакций через Impala. В результате прилег координатор и другие пользователи и процессы не могли подключиться на этот координатор. Как результат выработали правило каждый отдельный вид процессов (загрузка данных, ETL, пользователи, приложения) подключается к своему координатору, который еще имеет дублера для балансировки. Ну и конечно большие выгрузки данных в системы потребители лучше делать через sqoop export. Ну и в последних релизах Impala уже без проблем может отдавать десятки миллионов записей на подключение.

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

Итоги

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

Реализованный нами проект стал финалистом номинации Cloudera Data Impact 2020 в категории Data For Enterprise AI.

Выводы

После двух лет промышленной эксплуатации нашей Системы мы сегодня с уверенностью можем сказать, то экосистема Hadoop полностью позволяет реализовать все современные требования к аналитической платформе при использовании дистрибутива Cloudera и при правильных архитектурных подходах. Система может полностью вытеснить все традиционные аналитические СУБД без какого-либо ущерба к накопленному опыту разработчиков и аналитиков. Нужно всего лишь принять правильные решения и сделать прыжок веры. Традиционно консервативный Газпромбанк сделал с нами этот прыжок веры и смог построить современную аналитическую платформу, ввязавшись в гонку на розничном рынке в кратчайшие сроки.

Об успехах в цифрах можно посмотреть в записи нашего совместно доклада.

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

Наш архитектурный подход позволяет ускорить внедрение нового функционала и как следствие улучшить time to market новых продуктов, основанных на data driven процессах.

В современных аналитических задачах не существует понятий горячих и холодных данных. Ситуация прилета пачки проводок, за диапазон t - 3-5 лет - это каждодневная регламентная ситуация. И для такого случая вы должны пересчитать остатки, обороты, просрочки и предоставить данные для модели или определения сегмента клиента в аналитическом CRM. Как я уже писал выше, чем глубже в истории данные, тем точнее ваши модели. Такие задачи можно решить только если все данные в одном месте и в одной системе. Наш принцип - все данные горячие!

Для успешной реализации проектной команде недостаточно опыта знания технологии Hadoop. Hadoop это всего лишь инструмент. Необходимо применять подходы проектирования классического ХД на базе SQL MPP, иначе ваша система навсегда останется помойкой под архивные данные, нарисованной внизу слоеного пирога как хранилище неструктурированных и холодных данных на архитектурной картинке.

Наши ближайшие планы

В настоящий момент мы находимся в завершающей стадии миграции на новую платформу Cloudera Data Platform 7.1. Вполне вероятно, что на момент публикации мы уже на CDP и в ближайшее время тут будут опубликованы результаты. Пока, можно с уверенностью сказать, что после проведенных тестов, мы ожидаем ряд оптимизационных улучшений, связанных с Impala 3.4, появлением страничных индексов в parquet, наличием Zstd компрессии. Новые сервисы вроде Atlas и Cloudera Data Flow позволят закрывать функции управления данными и потоковой аналитики из коробки. В ближашее время мы также планируем пилотировать родной для Cloudera BI инструмент - Cloudera Data Visualization.

Что еще мы еще сделали в нашем ландшафте Hadoop

  • Real-time интеграция системы с процессинговым центром с использованием Kudu (real-time клиентские данные, доступные для работы с минимальной задержкой наступления события). Горячие данные в Kudu, холодные в Parquet, общий склеивающий интерфейс доступа для пользователей через SQL Impala. Результат - данные в реальном времени о состоянии карточных транзакций и остатков по карточному счету открывают для бизнеса новые возможности.

  • Историзируемый слой ODS

Построение слоя ODS с использованием Oracle Golden Gate с сохранением истории изменения источника с возможностью задания гранулярности истории по каждому объекту репликации, а также архивированием в Hadoop с возможностью схлопывания интервалов холодных данных.

  • Графовая аналитика

    • Построение витрины property графа в Hadoop;

    • Загрузка в графовую БД Arango;

    • Интерфейс работы с графом для андерайтеров над Arango;

    • Графовые модели (анализ окружения клиента при скоринге);

  • Текстовая аналитика

    • Работа моделей по распознаванию первичных документов клиента и поиска в них аномалий (контроль фронта, антифрод, автоматизация работы с заявкой);

    • Анализ новостных лент, тематических форумов

  • Геоаналитика

    • Анализ удаленности и проходимости офисов от основных пешеходных маршрутов, автомобильных проездов и парковок;

    • Оптимизация курьерских маршрутов

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

  • Контейнеризация пользовательских приложений и моделей с использованием окружения K8S

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

Авторы:

Евгений Вилков, Глоубайт.

Колесникова Елена, Газпромбанк (АО).

Подробнее..

Из песочницы Автоматизация бюджетирования что это, с какими проблемами связано и какие программные продукты использует?

01.08.2020 14:17:18 | Автор: admin
Это вводная статья о том, что такое автоматизация бюджетирования, о каких проблемах говорят, когда используют это словосочетание, и какие IT-инструменты используются в ней.

Если вы хотите понять, как связаны между собой BI, хранилища данных (DWH), системы автоматизации бюджетирования (Cognos, Anaplan, 1С: Управление холдингом, Бит.Финанс) и чем они отличаются от других корпоративных информационных систем вам сюда.

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

Сразу предупреждаю, что я постарался писать статью максимально простым языком, чтобы она была понятна для всех.

Почему я решил ее написать?


Сейчас практически отсутствует краткое систематизированное описание этой области, которое давало бы понятные ответы на вопросы:

  1. В чем специфические проблемы автоматизации бюджетирования? Чем она отличается от автоматизации обычного учета?
  2. Чем отличаются между собой модные программные продукты (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, Бит.Финанс, 1С: УХ) и по какому принципу они построены?
  3. Почему BI не основной инструмент автоматизации бюджетирования?

Объявление: буду рад, если специалисты по тиражным программным продуктам помогут в корректировке и дополнении статьи
Приглашаю всех, кто работает в качестве консультанта/пользователя с системами бюджетирования, к участию в пополнении данной статьи.

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

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

  • Архитектура (взаимодействие с аппаратной частью и другими модулями учета и планирования)
  • Функциональность
  • UX: интуитивность, понятность, простота настройки
  • Стоимость внедрения / владения


Проблемы и принципы их решения


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

Поэтому. Если считать УУ только учетом фактических данных, то УУ и бюджетирование совершенно разные вещи. Если считать, что УУ это и план, и факт, то бюджетирование можно считать частью управленческого учета на верхнем уровне.

У сферы бюджетирования две основные функции:

  • Составить план
  • Сопоставить план с фактом

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


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

Поэтому в учете оптимально работает схема Документ > Таблица (Регистр) > Отчет (которая использовалась задолго до автоматизации, еще в средневековом бухучете).


Рис. 1. Учетная схема Документ > Регистр > Отчет

Пример реализации

Рис. 2

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

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


Рис. 3

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

Проблема 2: Скорость сбора факта. Планы выводятся в отчеты очень быстро (поскольку хранятся в уже укрупненном виде), а фактические данные вычисляются очень медленно.

Проблема 3: Формы ввода планов . Самой удобной формой ввода планов является план-факт отчет. Но отчеты в информационных системах обычно не позволяют вводить данные.

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

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

Проблема 1: Администрирование правил трансформации


На рис. 1-3 все правила трансформации фактических данных (от низшего уровня учета до верхних уровней отчетности) прописаны прямо в коде отчета.

Это плохо:

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

Сложность правил трансформации


Здесь очень важно учитывать, что правила трансформации действительно могут быть достаточно сложными. Далеко не всегда трансформация представляет простое укрупнение данных (от дня к месяцу; от подразделения к организации; от склада к региону; от номенклатуры товара к статье и т.д.). Особенно явно это встречается в СНГ, где управленческий учет часто ведется на основе бухгалтерского. Тогда из самых разных комбинаций разных реквизитов бухучета могут определяться разные значения для управленческого учета.

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

При этом:

  • если закупается номенклатура Горюче-смазочные материалы у поставщика ООО Прямоугольник и по договору Договор 25 это одна статья бюджета;
  • если ГСМ закуплены у другого поставщика; или даже у того же поставщика, но по другому договору это уже другая статья бюджета.


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

Решение проблемы 1: mapping


Для решения этой задачи mapping соответствия между полями разных уровней и/или видов учета и отчетности можно вынести из отчетов, создать как отдельный объект, настраивать и хранить отдельно, и затем обращаться к ним при необходимости.


Рис. 4

Это дает сразу два преимущества:

  • Правила проще администрировать. Их можно сделать интерактивными и настраивать без кода, а значит это зачастую могут делать даже обычные пользователи;
  • Одно правило можно использовать в разных отчетах и/или других алгоритмах

Значимых минусов у такого подхода нет.

Но разработать инструмент для удобного маппинга больших объемов справочников непросто.

Проблема 2: Скорость трансформации фактических данных


Решение проблемы 2: хранение трансформированных данных


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

Для этого, помимо исходных таблиц (которые все равно понадобятся в компании), нужно создать таблицы для хранения агрегированных фактических данных. Это могут быть и отдельные таблицы, и общая таблица и для плана, и для агрегированного факта.

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


Рис. 5

DWH


С этой проблемой связана сфера Хранилищ данных (DWH).

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

Какие плюсы:

  • Скорость чтения данных. Если отчеты читают из таблицы уже трансформированные данные, они делают это очень быстро.
  • Проверяемость. Когда данные предварительно складываются в хранилище, их проще проверить.

Минусы:

  • Точность. На самом деле, этот минус скорее теоретический (максимальная точность обеспечивается именно когда мы берем данные из самого первичного источника информации).
    На практике
    Если в первичном учете данные ведутся качественно и хранилище выстроено качественно, то и в нем данные будут достаточно точными; если же первичный учет ведется плохо, то и без хранилищ в отчеты будут выводиться некорректные данные. То есть, потеря в доли процента в качестве данных после перехода к хранению агрегатов действительно возможна, но в большинстве случаев для компаний такие потери не являются значительными, чтобы принимать их во внимание.
  • Загрузка памяти. Соответственно, чтобы хранить агрегированные данные, мы тратим лишнее место на жестких дисках. Тоже, на самом деле, скорее теоретический минус.
  • Расшифровка. Если мы подключаем отчеты к агрегированным таблицам (в которых данные не детализированы по исходным документам), возникают проблемы с возможностями их расшифровки (drill-down).

ETL-процессы


ETL можно называть любой процесс, в котором данные берутся откуда-то, изменяются и затем куда-то загружаются. Это общепринятое сокращение от Extract (получить), Transform (преобразовать), Load (загрузить).

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

У такого подхода есть плюсы:

  • Распределение нагрузки на систему. Процесс трансформации растягивается во времени. Мы можем заполнять агрегированную таблицу постепенно (по мере изменения/добавления данных в исходных учетных системах) или по расписанию. Например, сложные вычисления можно откладывать на ночь или другое нерабочее время, когда сервер свободнее. Это позволяет управлять нагрузкой на систему.
  • Однократность трансформации. Однажды записав сводную информацию в агрегированную таблицу, мы сможем обращаться к ней из множества разных отчетов. Поэтому одни и те же трансформации не придется выполнять множество раз.

Минус же один:

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

Проблема 3: Форма ввода бюджетов


Дело в том, что в классическом виде отчеты в программных продуктах это средство вывода данных. Но вводить данные в них нельзя.

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

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

Таким образом, форма ввода сильно отличается от формы вывода.

А вот для бюджетирования классическая схема Форма ввода (документ) > внутренние таблицы > Форма вывода (отчет) не подходит.

Например, в свое время мы разработали помесячный отчет по закупкам (как на рис. 2), а теперь начинаем вести планирование, и финансовый директор хочет вводить бюджет закупок в такой же форме.

Что остается делать? Можно создать форму для ввода планов, которая будет очень, очень похожа на этот отчет (что и было показано на рис. 3).

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

И нам придется их поддерживать. То есть, если форма бюджета закупок должна измениться, скорее всего она изменится и для плана, и для факта, и нам придется вносить изменения в обе эти формы.

Второе. При вводе плана хочется видеть факт. А если отчета и ввода разные объекты, делать это неудобно.

Решение проблемы 3: интерактивные формы ввода-вывода


Решение тоже очевидно: вместо привычных документов и отчетов, нужно создать объект, который позволит одновременно и читать, и вводить данные.

Еще лучше, если в этом объекте можно будет еще и выполнять расчеты между вводимыми и/или читаемыми данными то есть, работать наподобие того, как позволяет работать Excel.

При этом планы после ввода можно складывать в то же самое хранилище данных, где лежат фактические данные (см. рисунок).


Рис. 6

Но реализовать такие формы значительно сложнее, чем обычные отчеты или документы в учетных системах.

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

Решение проблемы 4: кубы


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

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

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

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

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

Виды программных продуктов в бюджетировании


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

  • Системы исходных данных (системы учета, ERP-системы)
  • ETL-инструменты
  • Хранилища данных (обычные и OLAP-кубы)
  • BI-системы
  • EPM-системы
  • Конечно же, Excel

У каждого вида систем есть теоретически основная функция (см. таблицу):



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



Важно: Нужно обратить внимание, что обычно перекрытие функций не 100-процентно.

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

Поэтому, например, при максимальной потребности в DWH в компании, приобрести EPM-систему будет недостаточно, и лучше строить отдельную DWH; отдельная BI система может обладать более гибкими и шустрыми возможностями визуализации, чем комплексное EPM-решение и так далее.

Карта видов ПО в бюджетировании


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


Рис. 7

Теперь рассмотрим, какую архитектуру бюджетирования предлагают некоторые популярные программные продукты.

Бюджетирование в ERP-системах


Понятие ERP со временем меняется, и в ERP-системы включаются все новые возможности.

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

Не включает: возможность сбора данных из множества источников; построение кубов и интерактивной аналитики

Есть основания полагать, что понятие EPM (как и BI) задумывалось как нечто, выходящее за рамки ERP. Но сейчас границы стираются, и EPM-функции или даже целые продукты могут включаться в качестве модулей в ERP-системы.

1C: УПП


В УПП реализована следующая схема, но внутри одной базы.


Рис. 8. Архитектура бюджетирования в 1С: УПП

Плюсы бюджетирования в УПП:

  • УПП очень прозрачна и легко дорабатывается. В ней легко выверять данные и достаточно недорого разрабатывать новый функционал.

Mapping в УПП на среднем уровне. Это не плюс и не минус. Настройка средней трудоемкости.

Недостатки бюджетирования в УПП:

  • Отсутствие интерактивных форм ввода-вывода. Создание любых данных выполняется через документы (ввод планов; получение агрегированных фактических данных; проведение калькуляций), где нет и не может быть интерактивности и возможности видеть общую картину.
  • Отсутствие ETL-интерфейса. Маппинг есть, но загрузка фактических данных происходит прямо из формы документа, что неудобно.
  • Старая платформа. Нельзя использовать технологию Управляемые формы 1С, которая дает пользователю современные возможности универсальной фильтрации/сортировки списков и отчетов. Это ухудшает аналитические возможности пользователя.

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

1C:ERP


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


Рис. 9. Архитектура бюджетирования в 1С:ERP

Плюсы бюджетирования в 1С:ERP:

  • Достаточно функциональные формы ввода-вывода

Недостатки бюджетирования в 1C:ERP:

  • Жесткость модели. В принципе, как и в большинстве ERP-систем, бюджетная модель не терпит частых изменений и достаточно придирчива к предварительной настройке
  • Слабый mapping. Почему-то функционал мэппинга хуже, чем в УПП
  • Жесткость продукта. В отличие от УПП, здесь перерабатывать каркас методологии крайне сложно и дорого. Нужно хорошо изучить существующую, и строить бюджетирование на ERP, если она действительно подходит компании
  • Производительность. Интерактивные формы достаточно функциональны, но техническое устройство делает их крайне медленными на больших объемах данных

Также в 1C:ERP нет серьезного функционала по части настройки организационного процесса бюджетирования (workflow) и многопользовательской работы. Например, процессы согласования вынесены в отдельный продукт 1С: Документооборот, который обычно внедряется поверх ERP.

1C: КА


Комплексная автоматизация представляет собой урезанную версию 1С:ERP, поэтому ее развитие проходит по тому же пути, и собственной методологии бюджетирования здесь нет.

MS Axapta / MS Dynamics AX


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


Рис. 10. Архитектура бюджетирования в MS Dynamics

И плюс, и минус системы ее заточенность на собственные учетные модули Dynamics и их готовую структуру.

Плюсы:

  • Интегрированность с учетными модулями. Настройка получения фактических данных из различных модулей ERP-системы достаточно проста.
  • Интеграция. Достаточно много возможностей для загрузки готовых планов из внешних систем. Таким образом, Microsoft четко следует логике отделения EPM от ERP, вследствие чего EPM-системы очень хорошо навешиваются на Dynamics
  • Workflow. Достаточно функциональная и прозрачная настраиваемая организационная модель бюджетного процесса

Минусы:

  • ETL. В целом продукт не предоставляет значимых возможностей трансформации данных
  • Жесткость продукта. Здесь задана готовая, но достаточно ограниченная методология. И (как и в случае с 1C:ERP) дорабатывать ее не только сложно, но и практически бессмысленно.

SAP S4 HANA


Основной продукт SAP, пришедший на смену ERP-системе SAP R/3.

Для бюджетирования сейчас используется отдельный EPM-продукт, который в десктопной версии (SAP BPC) еще можно было считать EPM-системой поверх ERP, но в облачной версии (SAP Analytics Cloud) уже окончательно встроен в ERP-систему SAP S4 HANA Cloud. Подробнее о SAP BPC будет ниже.

Про саму S/4 HANA важно сказать другое: SAP переводит всю работу ERP-системы с реляционной базы данных на комбинированную (смесь реляционной, колоночной и многомерной). Такой комбинированной базой данных выступает собственная технология SAP HANA (не путать с S/4 HANA), которая в зависимости от действий пользователя работает то как транзакционная (учетная система), то как аналитическая система (куб).

Таким образом, SAP переходит к архитектуре, противоположной той, что сегодня хорошо известна в обычной практике: в нем аналитическая база данных строится не над храналищем (SAP BW), а реализована под ERP-системой. При этом хранилище данных (SAP BW), когда пользователь работает с его данными из EPM-системы, передает данные для вычислений обратно в эту исходную комбинированную базу.

Фактически, тот же эффект, ради которого задумывались IN-Memory OLAP, SAP достигает противоположным способом: максимальным вынесением калькуляций из оперативной памяти.

Oracle Cloud ERP


Oracle также пошла по пути встраивания EPM-системы внутрь ERP.

Компания активно переводит свои продукты на облачную версию (возможно, даже активнее, чем это делает SAP). Поэтому для своего главного EPM-решения, Oracle Hyperion, компания продвигает альтернативу в виде облачного Oracle EPM Cloud, который включается в состав облачной Oracle Cloud ERP.

BI-системы


BI-системы (Business Intellegence) в чистом виде это средство вывода данных. То есть, BI это конструкторы отчетов и дашбордов, которые также содержат базовые функции реструктуризации и анализа данных (например, соединять таблицы, находить усредненные тренды и т.д.).

Популярные BI-системы:

  • Power BI
  • Tableau
  • QlikView / QlikSense
  • IBM Cognos TM1
  • SAP BusinessObjects

Как правило, BI подключается к хранилищам данных (как реляционным, так и многомерным) или к исходным SQL-таблицам. Таким образом, можно обращаться к достаточно детализированным исходным данным (чтобы укрупнять их уже в BI). Однако, сложные условные трансформации (с условиями если) это не про классический функционал BI.

EPM-системы


EPM сокращенно Enterprise Performance Management (управление эффективностью предприятия). Также встречаются термины Corporate performance management (CPM) и реже Business performance management (BPM).

Довольно широкий термин, который может подразумевать и смежные функции, однако чаще всего такие системы можно рассматривать как конструкторы интерактивных План-факт форм. Понятие EPM еще не стало общеизвестным, но такие решения, как IBM Planning analytics, Oracle Hyperion, Anaplan, которые иногда рассматривают в контексте Business Intellegence, корректнее называть именно EPM-системами.

Иногда EPM-системы создаются для более широких целей (например, SAP EPM или 1С: Управление холдингом), но мы будем рассматривать их именно в части систем для автоматизации бюджетирования. Поэтому мы будем называть SAP Business Planning & Consolidation (SAP BPC) EPM-системой, хотя сам SAP называет ею более крупный продукт SAP EPM, в который включается BPC.

Как мы сказали, BI не позволяет вводить данные. EPM обычно включают в себя стандартные функции BI, а кроме этого реализует возможность ввода и записи данных.

Известные EPM-системы:

  • Oracle Hyperion
  • IBM Planning Analytics
  • Anaplan
  • SAP BPC
  • Бит.Финанс
  • 1C: Управление холдингом

Начнем с маленьких.

Бит.Финанс


Бит.Финанс основан на методологии бюджетирования УПП, однако он поддерживается, развивается, и кроме того реализован как EPM-система поверх ERP (таким образом, позволяет консолидировать фактические данные из разных внешних источников).


Рис. 11. Архитектура бюджетирования в Бит.Финанс

Плюсы автоматизации бюджетирования в Бит.Финанс:

  • Конструкторы форм ввода или чтения данных. В отличие от УПП, формы учетных документов здесь не фиксированы, их можно настраивать, приводя в достаточно удобный вид.
  • Интерфейс для управления калькуляциями. Пересчет бюджетных моделей здесь можно проводить централизованно, а не создавая вручную документ калькуляции.

Mapping как в УПП. На среднем уровне.

Недостатки автоматизации бюджетирования в Бит.Финанс:

  • Работа через формы учетных документов. Несмотря на то, что формы документов стали гибкими (см. первый плюс), и в целом в этом аспекте сделан большой прогресс по сравнению с УПП, продукт все же не ушел от документно-ориентированной модели работы настолько далеко, насколько хотелось бы. Что, как мы сказали, для бюджетирования архитектурно неправильно и неудобно.
  • Отсутствие интерактивных форм ввода-вывода. В отличие от 1C:ERP, здесь их нет.

Anaplan


Флагманский продукт, недавно набравший большую популярность на мировом рынке. Предлагается только в облачной версии.

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


Рис. 12. Архитектура бюджетирования в Anaplan (популярный сценарий автоматизации)

Плюсы:

  • Калькуляция. Продукт сфокусирован на вычислениях, и хранит все данные в In-Memory OLAP, что позволяет пересчитывать все модели в режиме онлайн
  • Коллективная работа (в рамках подготовки плановых данных)
  • UX и произвольное моделирование.
  • ETL. Собственный и достаточно удобный ETL-инструмент
  • Требует минимальной IT-поддержки. Особенно по части моделирования
  • Стоимость. Дороговата для российского рынка, но в сравнении с международными лидерами (тем же Oracle Hyperion) полная стоимость владения выходит ниже
  • Скорость внедрения. В сравнении с Hyperion и Planning Analytics, продукт проще и в использовании, и во внедрении

Минусы:

  • Форматирование
  • Коллективная работа (в части работы с событиями: уведомления, рассылки и пр.)
  • Собственный синтаксис формул. Вообще использование собственного кода всегда недостаток с точки зрения конечных пользователей.
  • Иерархии. Раньше были проблемы с использованием разной иерархии справочника для разных бюджетных моделей. Проблема неважна для многих компаний, но критична для отдельных. Возможно (я надеюсь на это) к данному моменту Anaplan уже решил эту проблему.
  • Ad-hoc отчетность. Вообще это скорее специализация, чем недостаток: Anaplan в большей мере ориентирован на работу через моделирование, чем на быструю аналитику и репортинг.
  • Ограниченные возможности для масштабирования


И плюсом, и минусом Anaplan является его относительно четкая специализация и то, что он не покушается на IT-экосистему компании. Плюс этого в том, что продукт четко определился со своим функциональным назначением, и направления его развития достаточно предсказуемы. Он представляет собой сервис для проведения анализа Что-Если, расчета и утверждения планов (бюджетов), и планировать архитектуру заказчикам нужно исходя из этого. Минус в том, что продукт не может заменить полноценное корпоративное хранилище данных, не может заменить все возможности BI, на нем не строят сложную корпоративную ETL-инфраструктуру, да и всю систему корпоративных вычислений. Все это не было бы проблемой, если бы продукт не предлагался только в облачной версии.

В отличие от Oracle и SAP (которые как раз претендуют на экосистемность), Anaplan не делает упор на возможности легко перегонять данные и инструменты между облаком и серверами компании. Таким образом, в его случае недостатки облачного продукта (с учетом тарификации в зависимости от объема используемых на сервере данных) проявляются наиболее заметно.

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


Рис. 13. Архитектура бюджетирования в Anaplan (альтернативный сценарий автоматизации)

В целом, использование одновременно EPM и BI-систем является нормальной практикой.

Oracle Hyperion


Поставляется в двух версиях: Oracle Hyperion Planning и Oracle Hyperion Financial Management.
Сейчас активно замещается новым продуктом Oracle EPM Cloud.

Из-за экосистемности, архитектуры могут приобретать самые разные виды, но типовая выглядит примерно так.


Рис. 14. Архитектура бюджетирования в Hyperion (пример)

На рисунке я привел BI-систему в качестве примера, поскольку аналитическая база данных Oracle Essbase является отличной базой для аналитики больших массивов данных в BI-инструментах.

В качестве ETL-решения предлагается Oracle Data Integrator, который выступает как универсальный механизм интеграции данных в экосистеме Oracle.

Плюсы автоматизации бюджетирования в Oracle Hyperion:

  • Экосистемность. В случае с Oracle отмечу как плюс, поскольку Oracle один из крупнейших поставщиков баз данных, и интеграция для компаний, кто работает на Oracle СУБД (а таких компаний много), действительно дает преимущества. В частности, удобнее распределять функционал между облаком и сервером. Кроме того, коллеги говорят о достаточно серьезных преимуществах по части безопасности в Oracleовой архитектуре (в этом я не специалист, если здесь таковые есть просьба поправить).
  • Ad-hoc (отчетность по запросу).

Недостатки автоматизации бюджетирования в Oracle Hyperion:

  • Экосистемность. Отмечу и как минус, поскольку, по имеющейся информации, Hyperion выбирается в основном именно компаниями, работающими на стеке технологий Oracle, и от его использования в не-Oracleовой среде в долгосрочной перспективе возможен меньший эффект.
  • Калькуляции. Продукт в меньшей степени заточен на пересчеты моделей, чем тот же Anaplan.
  • Сложность. Продукт не слишком легкий и с точки зрения инфраструктурной нагрузки, и с точки зрения UX (требует высокой квалификации и подготовленности пользователей).

IBM Planning Analytics


В основном предназначенная для крупного бизнеса, не слишком простая в развертке и администрировании, но весьма функциональная EPM-система. Сейчас IBM Planning analytics строится на базе технологий TM1 (лежащих в основе Cognosа).

Для ETL-процессов IBM предлагает использовать отдельный продукт IBM DataStage (ранее применялся Cognos DataManager), Turbo Integrator, Cognos Integration Server или внешний ETL-инструмент.

Типичная архитектура очень похожа на Hyperion.


Рис. 15. Архитектура бюджетирования в Planning Analytics (пример)

Сильные стороны IBM Planning Analytics:

  • Прогнозирование.
  • Работа с событиями.
  • Гибкость. Продукт нельзя назвать не требовательным к предварительной настройке, но он старается быть адаптированным к изменчивым моделям.
  • Неэкосистемность. Что удивляет в работе с IBM большой объем методических материалов, выпускаемых компанией, направлен на описание лучших практик взаимодействия продуктов IBM с другими решениями (в том числе, Oracle и SAP), причем в самых разных вопросах. На мой субъективный взгляд, хорошо, что в долгосрочной перспективе компания держит тренд на то, чтобы развивать интеграцию со сторонними системами (что позволяет поддерживать самые разные варианты сложившихся в компаниях архитектур), а не сокращать ее.
  • Поддержка продукта.

Минусы

  • Сложность. Как и Hyperion: требуется обучение пользователей, не самая легкая инфраструктура.

SAP BPC


В целом, отличительные особенности SAP экосистемность, сложность архитектуры и инфраструктуры решений.

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


Рис. 15. Архитектура бюджетирования в SAP Business Planning & Consoldation (пример)

Преимущества бюджетирования на базе SAP BPC:

  • Интеграция данных. Хотя она и сложна, она функциональна и быстра, и это главное для крупных компаний.
  • Визуализация.
  • Workflow.

Недостатки бюджетирования на базе SAP BPC:

  • UX и гибкость. Как и практически все продукты SAP, решение для бюджетирования требует высокой квалификации рядовых пользователей, а также очень требовательно к трудоемким предварительным настройкам.
  • Инфраструктурная нагрузка. К тому же, SAP постоянно изменяет архитектуру. С одной стороны, это хорошо (компания ищет новые способы реализации задач), с другой стороны для компаний это часто оборачивается большими трудностями при переходе на новые версии. Например, несколько лет назад SAP стала активно отказываться от версии своего хранилища SAP BW для MS SQL Server, оставляя альтернативную ей версию NetWeaver; затем стала активно продвигать BW/4 HANA как замену NetWeaver; при этом сейчас тенденция идет к тому, что компания переводит фокус с EPC на облачную версию SAP Analytics Cloud, переход на которую также требует некоторого перестроения архитектуры.
  • Цена. С точки зрения полной стоимости владения, фактически оказывается одной из наиболее дорогостоящих EPM-систем в мире, на что влияют в том числе изменения в архитектуре.

Отмечу, что сейчас продукт активно замещается облачной SAP Analytics Cloud.

ETL-инструменты


Для построения ETL-процессов используют известные ETL-инструменты, среди которых множество продуктов тех же вендоров, что выпускают BI/EPM решения:

  • IBM DataStage
  • Informatica PowerCenter
  • Talend
  • Apatar
  • SAP Data Services
  • Oracle Data Integrator
  • Microsoft Azure Data Factory
  • и мн. др.

Статья будет постепенно пополняться, возможно с добавлением информации о новых продуктах и принципах разработки программных продуктов для бюджетирования с нуля.
Подробнее..

Из песочницы Автоматизация бюджетирования что это, с какими проблемами связано и какие программные продукты используются?

01.08.2020 18:14:38 | Автор: admin
Это вводная статья о том, что такое автоматизация бюджетирования, о каких проблемах говорят, когда используют это словосочетание, и какие IT-инструменты используются в ней.

Если вы хотите понять, как связаны между собой BI, хранилища данных (DWH), системы автоматизации бюджетирования (Cognos, Anaplan, 1С: Управление холдингом, Бит.Финанс) и чем они отличаются от других корпоративных информационных систем вам сюда.

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

Сразу предупреждаю, что я постарался писать статью максимально простым языком, чтобы она была понятна для всех.

Почему я решил ее написать?


Сейчас практически отсутствует краткое систематизированное описание этой области, которое давало бы понятные ответы на вопросы:

  1. В чем специфические проблемы автоматизации бюджетирования? Чем она отличается от автоматизации обычного учета?
  2. Чем отличаются между собой модные программные продукты (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, Бит.Финанс, 1С: УХ) и по какому принципу они построены?
  3. Почему BI не основной инструмент автоматизации бюджетирования?

Объявление: буду рад, если специалисты по тиражным программным продуктам помогут в корректировке и дополнении статьи
Приглашаю всех, кто работает в качестве консультанта/пользователя с системами бюджетирования, к участию в пополнении данной статьи.

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

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

  • Архитектура (взаимодействие с аппаратной частью и другими модулями учета и планирования)
  • Функциональность
  • UX: интуитивность, понятность, простота настройки
  • Стоимость внедрения / владения


Проблемы и принципы их решения


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

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

У сферы бюджетирования две основные функции:

  • Составить план
  • Сопоставить план с фактом

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


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

Поэтому в учете оптимально работает схема Документ > Таблица (Регистр) > Отчет (которая использовалась задолго до автоматизации, еще в средневековом бухучете).


Рис. 1. Учетная схема Документ > Регистр > Отчет

Пример реализации

Рис. 2

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

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


Рис. 3

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

Проблема 2: Скорость сбора факта. Планы выводятся в отчеты очень быстро (поскольку хранятся в уже укрупненном виде), а фактические данные вычисляются очень медленно.

Проблема 3: Формы ввода планов . Самой удобной формой ввода планов является план-факт отчет. Но отчеты в информационных системах обычно не позволяют вводить данные.

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

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

Проблема 1: Администрирование правил трансформации


На рис. 1-3 все правила трансформации фактических данных (от низшего уровня учета до верхних уровней отчетности) прописаны прямо в коде отчета.

Это плохо:

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

Сложность правил трансформации


Здесь очень важно учитывать, что правила трансформации действительно могут быть достаточно сложными. Далеко не всегда трансформация представляет простое укрупнение данных (от дня к месяцу; от подразделения к организации; от склада к региону; от номенклатуры товара к статье и т.д.). Особенно явно это встречается в СНГ, где управленческий учет часто ведется на основе бухгалтерского. Тогда из самых разных комбинаций разных реквизитов бухучета могут определяться разные значения для управленческого учета.

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

При этом:

  • если закупается номенклатура Горюче-смазочные материалы у поставщика ООО Прямоугольник и по договору Договор 25 это одна статья бюджета;
  • если ГСМ закуплены у другого поставщика; или даже у того же поставщика, но по другому договору это уже другая статья бюджета.


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

Решение проблемы 1: mapping


Для решения этой задачи mapping соответствия между полями разных уровней и/или видов учета и отчетности можно вынести из отчетов, создать как отдельный объект, настраивать и хранить отдельно, и затем обращаться к ним при необходимости.


Рис. 4

Это дает сразу два преимущества:

  • Правила проще администрировать. Их можно сделать интерактивными и настраивать без кода, а значит это зачастую могут делать даже обычные пользователи;
  • Одно правило можно использовать в разных отчетах и/или других алгоритмах

Значимых минусов у такого подхода нет.

Но разработать инструмент для удобного маппинга больших объемов справочников непросто.

Проблема 2: Скорость трансформации фактических данных


Решение проблемы 2: хранение трансформированных данных


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

Для этого, помимо исходных таблиц (которые все равно понадобятся в компании), нужно создать таблицы для хранения агрегированных фактических данных. Это могут быть и отдельные таблицы, и общая таблица и для плана, и для агрегированного факта.

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


Рис. 5

DWH


С этой проблемой связана сфера Хранилищ данных (DWH).

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

Какие плюсы:

  • Скорость чтения данных. Если отчеты читают из таблицы уже трансформированные данные, они делают это очень быстро.
  • Проверяемость. Когда данные предварительно складываются в хранилище, их проще проверить.

Минусы:

  • Точность. На самом деле, этот минус скорее теоретический (максимальная точность обеспечивается именно когда мы берем данные из самого первичного источника информации).
    На практике
    Если в первичном учете данные ведутся качественно и хранилище выстроено качественно, то и в нем данные будут достаточно точными; если же первичный учет ведется плохо, то и без хранилищ в отчеты будут выводиться некорректные данные. То есть, потеря в доли процента в качестве данных после перехода к хранению агрегатов действительно возможна, но в большинстве случаев для компаний такие потери не являются значительными, чтобы принимать их во внимание.
  • Загрузка памяти. Соответственно, чтобы хранить агрегированные данные, мы тратим лишнее место на жестких дисках. Тоже, на самом деле, скорее теоретический минус.
  • Расшифровка. Если мы подключаем отчеты к агрегированным таблицам (в которых данные не детализированы по исходным документам), возникают проблемы с возможностями их расшифровки (drill-down).

ETL-процессы


ETL можно называть любой процесс, в котором данные берутся откуда-то, изменяются и затем куда-то загружаются. Это общепринятое сокращение от Extract (получить), Transform (преобразовать), Load (загрузить).

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

У такого подхода есть плюсы:

  • Распределение нагрузки на систему. Процесс трансформации растягивается во времени. Мы можем заполнять агрегированную таблицу постепенно (по мере изменения/добавления данных в исходных учетных системах) или по расписанию. Например, сложные вычисления можно откладывать на ночь или другое нерабочее время, когда сервер свободнее. Это позволяет управлять нагрузкой на систему.
  • Однократность трансформации. Однажды записав сводную информацию в агрегированную таблицу, мы сможем обращаться к ней из множества разных отчетов. Поэтому одни и те же трансформации не придется выполнять множество раз.

Минус же один:

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

Проблема 3: Форма ввода бюджетов


Дело в том, что в классическом виде отчеты в программных продуктах это средство вывода данных. Но вводить данные в них нельзя.

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

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

Таким образом, форма ввода сильно отличается от формы вывода.

А вот для бюджетирования классическая схема Форма ввода (документ) > внутренние таблицы > Форма вывода (отчет) не подходит.

Например, в свое время мы разработали помесячный отчет по закупкам (как на рис. 2), а теперь начинаем вести планирование, и финансовый директор хочет вводить бюджет закупок в такой же форме.

Что остается делать? Можно создать форму для ввода планов, которая будет очень, очень похожа на этот отчет (что и было показано на рис. 3).

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

И нам придется их поддерживать. То есть, если форма бюджета закупок должна измениться, скорее всего она изменится и для плана, и для факта, и нам придется вносить изменения в обе эти формы.

Второе. При вводе плана хочется видеть факт. А если отчета и ввода разные объекты, делать это неудобно.

Решение проблемы 3: интерактивные формы ввода-вывода


Решение тоже очевидно: вместо привычных документов и отчетов, нужно создать объект, который позволит одновременно и читать, и вводить данные.

Еще лучше, если в этом объекте можно будет еще и выполнять расчеты между вводимыми и/или читаемыми данными то есть, работать наподобие того, как позволяет работать Excel.

При этом планы после ввода можно складывать в то же самое хранилище данных, где лежат фактические данные (см. рисунок).


Рис. 6

Но реализовать такие формы значительно сложнее, чем обычные отчеты или документы в учетных системах.

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

Решение проблемы 4: кубы


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

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

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

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

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

Виды программных продуктов в бюджетировании


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

  • Системы исходных данных (системы учета, ERP-системы)
  • ETL-инструменты
  • Хранилища данных (обычные и OLAP-кубы)
  • BI-системы
  • EPM-системы
  • Конечно же, Excel

У каждого вида систем есть теоретически основная функция (см. таблицу):



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



Важно: Нужно обратить внимание, что обычно перекрытие функций не 100-процентно.

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

Поэтому, например, при максимальной потребности в DWH в компании, приобрести EPM-систему будет недостаточно, и лучше строить отдельную DWH; отдельная BI система может обладать более гибкими и шустрыми возможностями визуализации, чем комплексное EPM-решение и так далее.

Карта видов ПО в бюджетировании


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


Рис. 7

Теперь рассмотрим, какую архитектуру бюджетирования предлагают некоторые популярные программные продукты.

Бюджетирование в ERP-системах


Понятие ERP со временем меняется, и в ERP-системы включаются все новые возможности.

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

Не включает: возможность сбора данных из множества источников; построение кубов и интерактивной аналитики

Есть основания полагать, что понятие EPM (как и BI) задумывалось как нечто, выходящее за рамки ERP. Но сейчас границы стираются, и EPM-функции или даже целые продукты могут включаться в качестве модулей в ERP-системы.

1C: УПП


В УПП реализована следующая схема, но внутри одной базы.


Рис. 8. Архитектура бюджетирования в 1С: УПП

Плюсы бюджетирования в УПП:

  • УПП очень прозрачна и легко дорабатывается. В ней легко выверять данные и достаточно недорого разрабатывать новый функционал.

Mapping в УПП на среднем уровне. Это не плюс и не минус. Настройка средней трудоемкости.

Недостатки бюджетирования в УПП:

  • Отсутствие интерактивных форм ввода-вывода. Создание любых данных выполняется через документы (ввод планов; получение агрегированных фактических данных; проведение калькуляций), где нет и не может быть интерактивности и возможности видеть общую картину.
  • Отсутствие ETL-интерфейса. Маппинг есть, но загрузка фактических данных происходит прямо из формы документа, что неудобно.
  • Старая платформа. Нельзя использовать технологию Управляемые формы 1С, которая дает пользователю современные возможности универсальной фильтрации/сортировки списков и отчетов. Это ухудшает аналитические возможности пользователя.

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

1C:ERP


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


Рис. 9. Архитектура бюджетирования в 1С:ERP

Плюсы бюджетирования в 1С:ERP:

  • Достаточно функциональные формы ввода-вывода

Недостатки бюджетирования в 1C:ERP:

  • Жесткость модели. В принципе, как и в большинстве ERP-систем, бюджетная модель не терпит частых изменений и достаточно придирчива к предварительной настройке
  • Слабый mapping. Почему-то функционал мэппинга хуже, чем в УПП
  • Жесткость продукта. В отличие от УПП, здесь перерабатывать каркас методологии крайне сложно и дорого. Нужно хорошо изучить существующую, и строить бюджетирование на 1С:ERP, если она действительно подходит компании
  • Производительность. Интерактивные формы достаточно функциональны, но техническое устройство делает их крайне медленными на больших объемах данных

Также в 1C:ERP нет серьезного функционала по части настройки организационного процесса бюджетирования (workflow) и многопользовательской работы. Например, процессы согласования вынесены в отдельный продукт 1С: Документооборот, который обычно внедряется поверх ERP.

1C: КА


Комплексная автоматизация представляет собой урезанную версию 1С:ERP, поэтому ее развитие проходит по тому же пути, и собственной методологии бюджетирования здесь нет.

MS Axapta / MS Dynamics AX


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


Рис. 10. Архитектура бюджетирования в MS Dynamics

И плюс, и минус системы ее заточенность на собственные учетные модули Dynamics и их готовую структуру.

Плюсы:

  • Интегрированность с учетными модулями. Настройка получения фактических данных из различных модулей ERP-системы достаточно проста.
  • Интеграция. Достаточно много возможностей для загрузки готовых планов из внешних систем. Таким образом, Microsoft четко следует логике отделения EPM от ERP, вследствие чего EPM-системы очень хорошо навешиваются на Dynamics
  • Workflow. Достаточно функциональная и прозрачная настраиваемая организационная модель бюджетного процесса

Минусы:

  • ETL. В целом продукт не предоставляет значимых возможностей трансформации данных
  • Жесткость продукта. Здесь задана готовая, но достаточно ограниченная методология. И (как и в случае с 1C:ERP) перерабатывать ее не только сложно, но и практически бессмысленно.

SAP S4 HANA


Основной продукт SAP, пришедший на смену ERP-системе SAP R/3.

Для бюджетирования сейчас используется отдельный EPM-продукт, который в десктопной версии (SAP BPC) еще можно было считать отдельной EPM-системой поверх ERP, но в облачной версии (SAP Analytics Cloud) уже окончательно встроен в ERP-систему (в SAP S4 HANA Cloud). Подробнее о SAP BPC будет ниже.

Про саму S/4 HANA важно сказать другое: SAP переводит всю работу ERP-системы с реляционной базы данных на комбинированную (смесь реляционной, колоночной и многомерной). Такой комбинированной базой данных выступает собственная технология SAP HANA (не путать с S/4 HANA), которая в зависимости от действий пользователя работает то как транзакционная (учетная система), то как аналитическая система (куб).

Таким образом, SAP переходит к архитектуре, противоположной той, что сегодня хорошо известна в обычной практике. В нем аналитическая база данных строится не над храналищем (SAP BW), а реализована под ERP-системой. При этом хранилище данных (SAP BW), когда пользователь работает с его данными из EPM-системы, передает данные для вычислений обратно в эту исходную комбинированную базу.

Фактически, тот же эффект, ради которого задумывались IN-Memory OLAP, SAP достигает противоположным способом: максимальным вынесением калькуляций из оперативной памяти.

Oracle Cloud ERP


Oracle также пошла по пути встраивания EPM-системы внутрь ERP.

Компания активно переводит свои продукты на облачную версию (возможно, даже активнее, чем это делает SAP). Поэтому для своего главного EPM-решения, Oracle Hyperion (о котором мы тоже поговорим ниже), компания продвигает альтернативу в виде облачного Oracle EPM Cloud, который включается в состав облачной Oracle Cloud ERP.

BI-системы


BI-системы (Business Intellegence) в чистом виде это средство вывода данных. То есть, BI это конструкторы отчетов и дашбордов, которые обычно также содержат базовые функции реструктуризации и анализа данных (например, позволяют соединять таблицы, находить усредненные тренды и пр.).

Популярные BI-системы:

  • Power BI
  • Tableau
  • QlikView / QlikSense
  • IBM Cognos TM1
  • SAP BusinessObjects

Как правило, BI подключается к хранилищам данных (как реляционным, так и многомерным) или к исходным SQL-таблицам. Таким образом, можно обращаться к достаточно детализированным исходным данным (чтобы укрупнять их уже в BI). Однако, сложные условные трансформации (с условиями если) это не про классический функционал BI. Если перед вами стоит задача построить систему визуализации дашбордов, лучше постройте трансформацию перед тем как внедрять BI.

EPM-системы


EPM сокращенно Enterprise Performance Management (управление эффективностью предприятия). Также встречаются термины Corporate performance management (CPM) и реже Business performance management (BPM).

Довольно широкий термин, который может подразумевать и смежные функции, однако чаще всего такие системы можно рассматривать как конструкторы интерактивных План-факт форм. Понятие EPM еще не стало общеизвестным, но такие решения, как IBM Planning analytics, Oracle Hyperion, Anaplan, которые иногда рассматривают в контексте Business Intellegence, корректнее называть именно EPM-системами.

Иногда EPM-системы создаются для более широких целей (например, SAP EPM или 1С: Управление холдингом), но мы будем рассматривать их именно в части систем для автоматизации бюджетирования. Поэтому мы будем называть SAP Business Planning & Consolidation (SAP BPC) EPM-системой, хотя сам SAP называет так более крупный продукт SAP EPM, в который включается SAP BPC.

Как мы сказали, BI не позволяет вводить данные. EPM обычно включают в себя стандартные функции BI, а кроме этого реализуют возможность ввода и записи данных.

Известные EPM-системы:

  • Oracle Hyperion
  • IBM Planning Analytics
  • Anaplan
  • SAP BPC
  • Бит.Финанс
  • 1C: Управление холдингом

Начнем с маленьких.

Бит.Финанс


Бит.Финанс основан на методологии бюджетирования УПП, однако, в отличие от него, во-первых, поддерживается и развивается, а во-вторых, реализован как EPM-система поверх ERP (таким образом, позволяет консолидировать фактические данные из разных внешних источников).


Рис. 11. Архитектура бюджетирования в Бит.Финанс

Плюсы автоматизации бюджетирования в Бит.Финанс:

  • Конструкторы форм ввода или чтения данных. В отличие от УПП, формы учетных документов здесь не фиксированы, их можно настраивать, приводя в достаточно удобный вид.
  • Интерфейс для управления калькуляциями. Пересчет бюджетных моделей здесь можно проводить централизованно, а не создавая вручную документ калькуляции.

Mapping как в УПП. На среднем уровне.

Недостатки автоматизации бюджетирования в Бит.Финанс:

  • Работа через формы учетных документов. Несмотря на то, что формы документов стали гибкими (см. первый плюс), и в целом в этом аспекте сделан большой прогресс по сравнению с УПП, продукт все же не ушел от документно-ориентированной модели работы настолько далеко, насколько хотелось бы. Что, как мы сказали, для бюджетирования архитектурно неправильно и неудобно.
  • Отсутствие интерактивных форм ввода-вывода. В отличие от 1C:ERP, здесь их нет.

Anaplan


Флагманский продукт, недавно набравший большую популярность на мировом рынке. Предлагается только в облачной версии.

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


Рис. 12. Архитектура бюджетирования в Anaplan (популярный сценарий автоматизации)

Плюсы:

  • Калькуляция. Продукт сфокусирован на вычислениях, и хранит все данные в In-Memory OLAP, что позволяет пересчитывать все модели в режиме онлайн
  • Коллективная работа (в рамках подготовки плановых данных)
  • UX и произвольное моделирование.
  • ETL. Собственный и достаточно удобный ETL-инструмент
  • Требует минимальной IT-поддержки. Особенно по части моделирования
  • Стоимость. Дороговато для российского рынка, но в сравнении с международными лидерами (тем же Oracle Hyperion) полная стоимость владения выходит ниже
  • Скорость внедрения. В сравнении с Hyperion и Planning Analytics, продукт проще и в использовании, и во внедрении

Минусы:

  • Форматирование
  • Коллективная работа (в части работы с событиями: уведомления, рассылки и пр.)
  • Собственный синтаксис формул. Вообще использование собственного кода всегда недостаток с точки зрения конечных пользователей.
  • Иерархии. Раньше были проблемы с использованием разной иерархии справочника для разных бюджетных моделей. Проблема не важна для многих компаний, но критична для некоторых. Возможно (я надеюсь на это), к данному моменту Anaplan уже решил эту проблему.
  • Ad-hoc отчетность. Вообще это скорее специализация, чем недостаток: Anaplan в большей мере ориентирован на работу через моделирование, чем на быструю аналитику и репортинг.
  • Ограниченные возможности для масштабирования


И плюсом, и минусом Anaplan является его относительно четкая специализация и то, что он не покушается на IT-экосистему компании. Плюс в том, что продукт четко определился со своим функциональным назначением, и направления его развития достаточно предсказуемы. Он представляет собой сервис для проведения анализа Что-Если, расчета и утверждения планов (бюджетов), и планировать архитектуру заказчика нужно исходя из этого. Минус в том, что продукт не может заменить полноценное корпоративное хранилище данных, не может заменить все возможности BI, на нем не строят сложную корпоративную ETL-инфраструктуру, да и всю систему корпоративных вычислений. Все это не было бы проблемой, если бы продукт не предлагался только в облачной версии.

В отличие от Oracle и SAP (которые как раз претендуют на экосистемность), Anaplan не делает упор на возможность легко перегонять данные и инструменты между облаком и серверами компании. Таким образом, в его случае недостатки облачного продукта (с учетом тарификации в зависимости от объема используемых на сервере данных) проявляются наиболее заметно.

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


Рис. 13. Архитектура бюджетирования в Anaplan (альтернативный сценарий автоматизации)

В целом, использование одновременно EPM и BI-систем является нормальной практикой.

Oracle Hyperion


Поставляется минимум в двух версиях: Oracle Hyperion Planning и Oracle Hyperion Financial Management.
Сейчас активно замещается новым продуктом Oracle EPM Cloud.

Из-за экосистемности, архитектуры могут приобретать самые разные виды, но типовая выглядит примерно так.


Рис. 14. Архитектура бюджетирования в Hyperion (возможный вариант)

На рисунке я привел BI-систему в качестве примера, поскольку аналитическая база данных Oracle Essbase является отличной базой для аналитики больших массивов данных в BI-инструментах.

В качестве ETL-решения предлагается Oracle Data Integrator, который выступает как универсальный механизм интеграции данных в экосистеме Oracle.

Плюсы автоматизации бюджетирования в Oracle Hyperion:

  • Экосистемность. В случае с Oracle отмечу как плюс, поскольку Oracle один из крупнейших поставщиков баз данных, и интеграция для компаний, кто работает на Oracle СУБД (а таких компаний много), действительно дает преимущества. В частности, удобнее распределять функционал между облаком и сервером. Кроме того, коллеги говорят о достаточно серьезных преимуществах по части безопасности в Oracleовой архитектуре (в этом я не специалист, если здесь таковые есть просьба поправить).
  • Ad-hoc (отчетность по запросу).

Недостатки автоматизации бюджетирования в Oracle Hyperion:

  • Экосистемность. Отмечу и как минус, поскольку, по имеющейся информации, Hyperion выбирается в основном именно компаниями, работающими на стеке технологий Oracle, и от его использования в не-Oracleовой среде в долгосрочной перспективе возможен меньший эффект.
  • Калькуляции. Продукт в меньшей степени заточен на пересчеты моделей, чем тот же Anaplan.
  • Сложность. Продукт не слишком легкий и с точки зрения инфраструктурной нагрузки, и с точки зрения UX (требует высокой квалификации и подготовленности пользователей).

IBM Planning Analytics


В основном предназначенная для крупного бизнеса, не слишком простая в развертке и администрировании, но весьма функциональная EPM-система. Сейчас IBM Planning analytics строится на базе технологий TM1 (лежащих в основе Cognosа).

Для ETL-процессов IBM предлагает использовать отдельный продукт IBM DataStage (ранее применялся Cognos DataManager), Turbo Integrator, Cognos Integration Server или внешний ETL-инструмент.

Типичная архитектура очень похожа на Hyperion.


Рис. 15. Архитектура бюджетирования в Planning Analytics (возможный вариант)

Сильные стороны IBM Planning Analytics:

  • Прогнозирование.
  • Работа с событиями.
  • Гибкость. Продукт нельзя назвать не требовательным к предварительной настройке, но он старается быть адаптированным к изменчивым моделям.
  • Неэкосистемность. Что удивляет в работе с IBM большой объем методических материалов, выпускаемых компанией, направлен на описание лучших практик взаимодействия продуктов IBM с другими решениями (в том числе, Oracle и SAP), причем в самых разных вопросах. На мой субъективный взгляд, хорошо, что в долгосрочной перспективе компания держит тренд на то, чтобы развивать интеграцию со сторонними системами (что позволяет поддерживать самые разные варианты сложившихся в компаниях архитектур), а не сокращать ее.
  • Поддержка продукта.

Минусы

  • Сложность. Как и в случае с Hyperion: требуется значительное обучение пользователей, не самая легкая инфраструктура.

SAP BPC


В целом, отличительные особенности SAP экосистемность, сложность архитектуры и инфраструктуры решений.

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


Рис. 15. Архитектура бюджетирования в SAP Business Planning & Consoldation (пример)

Преимущества бюджетирования на базе SAP BPC:

  • Интеграция данных. Хотя она и сложна, она функциональна и быстра, и это главное для крупных компаний.
  • Визуализация.
  • Workflow.

Недостатки бюджетирования на базе SAP BPC:

  • UX и гибкость. Как и практически все продукты SAP, решение для бюджетирования требует высокой квалификации рядовых пользователей, а также очень требовательно к трудоемким предварительным настройкам.
  • Инфраструктурная нагрузка. К тому же, SAP постоянно изменяет архитектуру. С одной стороны, это хорошо: разработчики ищут новые способы реализации задач. С другой стороны, для компаний это создает трудности при переходах на новые версии. Например, несколько лет назад SAP стала активно отказываться от версии своего хранилища SAP BW для MS SQL Server, оставляя альтернативную ей версию NetWeaver; затем стала активно продвигать BW/4 HANA как альтернативу NetWeaver; сейчас тенденция идет к тому, что компания переводит фокус с десктопной EPM-системы на облачную версию SAP Analytics Cloud, переход на которую также требует некоторого перестроения архитектуры.
  • Цена. С точки зрения полной стоимости владения, фактически оказывается одной из наиболее дорогостоящих EPM-систем в мире, на что влияют в том числе изменения в архитектуре.


ETL-инструменты


Для построения ETL-процессов используют известные ETL-инструменты, среди которых множество продуктов тех же вендоров, что выпускают BI/EPM решения:

  • IBM DataStage
  • Informatica PowerCenter
  • Talend
  • Apatar
  • SAP Data Services
  • Oracle Data Integrator
  • Microsoft Azure Data Factory
  • и мн. др.

Статья будет постепенно пополняться, возможно с добавлением информации о новых продуктах и принципах разработки программных продуктов для бюджетирования с нуля.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru