Пошаговый план, как внедрить систему аналитики

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

Вот пошаговый план, как построить собственную BI-систему, заточенную под требования вашего бизнеса и основанную на ПО с открытым исходным кодом. Для этого нужны 3 разработчика — 2 мидла и 1 сеньор, которые разбираются в хранении и обработке данных, подключении источников и настройке BI-систем. И — ваше желание.

Система аналитики — это инструмент с определёнными задачами и функциями. Поэтому важно на старте определить, для чего она вам нужна. Например:

Определились с целью — решите, какие данные вам необходимы для её достижения. И, соответственно, где эти данные брать.

В качестве источников к системам аналитики можно подключить все, у чего есть api:

Что важно при подключении источников:

Например, статусы задач из таск-трекера нужно получать практически в реальном времени. А вот финансовую аналитику можно получать реже — кому-то и раза в месяц хватит.

Обычно есть 2 стартовые позиции: источники данных в наличии, а сбор и хранение не ведутся, или же — по-гречески — есть всё, кроме системы аналитики.

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

Этот сценарий более ресурсозатратный, поэтому вот подробности про выбор ПО для каждой составляющей.

Данные для аналитики можно хранить в озере данных или в обычном хранилище.

Хранилище данных — обычная БД, хранит только структурированные данные. То есть данные, прежде чем попасть туда, должны пройти обработку.

Организовать такое хранилище можно на Greenplum.

Озеро данных — это большое хранилище с неструктурированными и\или частично структурированными исходными данными. Данные поступают туда из разных источников и хранятся по сути в том виде, в котором они поступили.

Для озера данных можно использовать, к примеру, Apache Hadoop.

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

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

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

Разные решения написаны на разных языках, и для некоторых найти разработчика — тот ещё квест. Чем реже встречается компетенция — тем дороже услуги её обладателя

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

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

Apache Superset позволяет тонко настраивать доступы из коробки. А вот настраивать визуализацию в нем сложнее, поскольку для этого требуются другие компетенции: если в Redash все делается с помощью SQL-запросов, то в Apache Superset работает примерно, как графики в Google Sheets.

Всё просто: плохие данные приведут к неверным результатам анализа, следовательно, и неверным решениям, которые на них основаны.

Проверка качества данных происходит через их соответствие задаче. Соответствуют — отлично, передаём их дальше, для преобразования и анализа. Не соответствуют — не передаём.

Проверить качество данных можно двумя способами — фильтровать их "на лету" или вначале всё собрать, а потом уже проверить.

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

Ко второму способу можно применить метафору склада: вначале все собрали, а потом уже без спешки сортируем 👇

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

Если же вам важно собирать и хранить все данные, вы можете проверять их непосредственно перед использованием: подходят или не подходят они текущему запросу.

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

И вам понадобится специалист по Python. Можно использовать другие языки — Scala, Java Script, — но большая часть решений для бизнес-аналитики сделана именно на нем. К тому же, с помощью скриптов, написанных на Python, просто извлекать и передавать данные из любых приложений.

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

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

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

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

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

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

Если вы уже начали внедрение, но у вас есть вопросы по какому-то из шагов, или требуется консультация о процессе в целом, напишите нам на [email protected] — постараемся помочь 👌