Это вторая часть цикла статей об аналитических системах (ссылка на часть 1).
Сегодня уже не вызывает сомнений, что аккуратная обработка данных и интерпретация результатов могут помочь практически любому виду бизнеса. В связи с этим аналитические системы становятся все более нагруженными параметрами, растет количество триггеров и пользовательских ивентов в приложениях.
Из-за этого компании отдают своим аналитикам все больше и больше «сырой» информации для анализа и превращения ее в правильные решения. Важность системы аналитики для компании не должна быть недооцененной, а сама система должна быть надежной и устойчивой.
Клиентская аналитика — это сервис, который компания подключает для своего веб-сайта или приложения через официальное SDK, интегрирует в собственную кодбазу и выбирает ивенты-триггеры. У такого подхода есть очевидный недостаток: все собранные данные не могут быть обработаны в полной мере так, как вы хотели бы, из-за ограничений любого выбранного сервиса. Например, в одной системе будет нелегко запустить MapReduce задачи, в другой вы не сможете запустить свою модель. Еще одним минусом будет регулярный (внушительный) счет за услуги.
На рынке представлено много решений клиентской аналитики, но, рано или поздно аналитики сталкиваются с тем, что нет одного универсального сервиса, подходящего для любой задачи (тогда как цены на все эти сервисы все время растут). В такой ситуации компании нередко решают создать свою собственную систему аналитики со всеми нужными кастомными настройками и возможностями.
Серверная аналитика — это сервис, который может быть развернут внутри компании на ее собственных серверах и (обычно) своими усилиями. В такой модели все пользовательские ивенты хранятся на внутренних серверах, позволяя разработчикам попробовать разные базы данных для хранения и выбрать самую удобную архитектуру. И даже если вы все еще хотите использовать сторонние клиентские аналитики для некоторых задач, это все еще будет возможно.
Серверную аналитику можно развернуть двумя способами. Первый: выбрать какие-то опенсорс утилиты, развернуть на своих машинах и разработать бизнес-логику.
Второй: взять сервисные услуги SaaS (Amazon, Google, Azure) вместо того, чтобы развертывать самому. Про SaaS более подробно расскажем в третьей части.
Если мы хотим уйти от использования клиентских аналитик и собрать свою, прежде всего нужно продумать архитектуру новой системы. Ниже я пошагово расскажу, что нужно учесть, зачем нужен каждый из шагов и какие инструменты можно использовать.
Так же, как в случае клиентской аналитики, в первую очередь аналитики компании выбирают виды ивентов, которые хотят изучать в дальнейшем и собирают их в список. Обычно, эти ивенты происходят в определенном порядке, который называется «схемой ивентов».
Дальше, представим, что у мобильного приложения (веб-сайта) есть постоянные пользователи (устройства) и много серверов. Для безопасной передачи ивентов с устройств на серверы нужен промежуточный слой. В зависимости от архитектуры может возникать несколько разных очередей ивентов.
Apache Kafka — это pub/sub queue, которую используют как очередь для сбора ивентов.
В нашем примере есть множество производителей данных и их потребителей (устройства и серверы), и Кафка помогает соединить их друг с другом. Потребители будут описаны подробнее на следующих шагах, где они будут главными субъектами. Сейчас рассмотрим только производителей данных (ивентов).
Кафка инкапсулирует понятия очереди и партиции, более конкретно об этом лучше почитать в другом месте (например, в документации). Не погружаясь в детали, представим, что мобильное приложение запущено для двух разных ОС. Тогда каждая версия создает свой отдельный поток ивентов. Продюсеры отправляют ивенты в Кафку, они записываются в подходящую очередь.
(картинка отсюда)
В то же время, Кафка позволяет считывать кусками и обрабатывать поток ивентов мини-батчами. Кафка очень удобный инструмент, который хорошо масштабируется с ростом потребностей (например, по геолокации ивентов).
Обычно одного шарда достаточно, но дела становятся сложнее в связи при масштабировании (как и всегда). Вероятно, никто не захочет использовать лишь один физический шард в продакшне, так как архитектура должна быть отказоустойчивой. Помимо Кафки есть еще одно известное решение — RabbitMQ. Мы не использовали его в продакшне как очередь для аналитики ивентов (если у вас есть такой опыт, расскажите о нем в комментариях!). Однако, использовали AWS Kinesis.
Прежде, чем перейти к следующему шагу, нужно упомянуть еще один дополнительный слой системы — хранилище сырых логов. Это не обязательный слой, но он будет полезен в случае, если что-то пойдет не так, и очереди ивентов в Кафке обнулятся. Хранение сырых логов не требует сложного и дорогого решения, можно просто записывать их куда-либо в правильном порядке (хоть на жесткий диск).
После того, как мы подготовили все ивенты и поместили их в подходящие очереди, переходим к шагу обработки. Здесь расскажу о двух наиболее частых вариантах обработки.
Первый вариант — это подключить Spark Streaming в системе Apache. Все продукты Apache живут в HDFS, безопасной файловой системе с репликами файлов. Spark Streaming — это удобный в работе инструмент, который обрабатывает потоковые данные и хорошо масштабируется. Однако, может быть тяжеловат в поддержании.
Другой вариант — собрать собственный обработчик ивентов. Для этого нужно, например, написать питоновское приложение, сбилдить его в докере и подписаться на очереди Кафки. Когда на обработчиков в докере будут приходить триггеры, будет запускаться обработка. При таком методе нужно держать постоянно запущенные приложения.
Предположим, что мы выбрали один из описанных выше вариантов и перейдем к самой обработке. Обработчики должны начать с проверки валидности данных, фильтровать мусор и «сломанные» ивенты. Для валидации мы обычно используем Cerberus. После этого можно сделать маппинг данных: данные с разных источников нормализуются и стандартизируются, чтобы быть добавленными в общую табличку.
Третий шаг — сохранить нормализованные ивенты. При работе с готовой аналитической системой нам придется часто к ним обращаться, поэтому важно подобрать удобную базу данных.
Если данные хорошо ложаться на фиксированную схему, можно выбрать Clickhouse или какую-нибудь другую колоночную базу данных. Так агрегации будут работать очень быстро. Минус в том, что схема жестко фиксирована и потому складывать произвольные объекты без доработки не получится (например, когда произойдет нестандартный ивент). Зато считать можно действительно очень быстро.
Для неструктурированных данных можно взять NoSQL, например, Apache Cassandra. Она работает на HDFS, хорошо реплицируется, можно поднять много инстансов, отказоустойчива.
Можно поднять и что-то попроще, например, MongoDB. Она довольно медленная и для небольших объемов. Но плюс в том, что она очень простая и потому подходит для старта.
Аккуратно сохранив все ивенты, мы хотим из батча, который пришел, собрать всю важную информацию и обновить БД. Глобально, мы хотим получить релевантные дашборды и метрики. Например, из ивентов собрать профиль пользователя и каким-то образом измерить поведение. Ивенты агрегируются, собираются, и снова сохраняются (уже в пользовательские таблицы). При этом можно построить систему так, чтобы к агрегатору-координатору подключать еще и фильтр: собирать пользователей только из определенного вида ивентов.
После этого, если кому-то в команде нужна только высокоуровневая аналитика, можно подключить внешние системы аналитики. Можно снова взять Mixpanel. но так как она довольно дорогая, отправлять туда уже не все пользовательские ивенты, а только то, что нужно. Для этого нужно создать координатор, который будет передавать некоторые сырые ивенты или что-то, что мы сами агрегировали ранее, во внешние системы, АПИ или рекламные платформы.
К созданной системе нужно подключить фронтенд. Хороший пример — сервис redash, это GUI для баз данных, который помогает строить панели. Как устроено взаимодействие:
Визуализации в сервисе автообновляемые, можно настраивать и отслеживать свои мониторинги. Redash бесплатен, в случае self-hosted, а как SaaS будет стоить 50 долларов в месяц.
Выполнив все шаги выше, вы создадите свою серверную аналитику. Обратите внимание, что это не такой простой путь, как просто подключить клиентскую аналитику, потому что все нужно настраивать самостоятельно. Поэтому прежде, чем создавать свою систему, стоить сопоставить необходимость в серьезной системе аналитики с ресурсами, которые вы готовы на нее выделить.
Если вы все посчитали и получили, что расходы слишком высоки, в следующей части я расскажу о том, как сделать более дешевую версию серверной аналитики.
Спасибо за прочтение! Буду рад вопросам в комментариях.
Сегодня уже не вызывает сомнений, что аккуратная обработка данных и интерпретация результатов могут помочь практически любому виду бизнеса. В связи с этим аналитические системы становятся все более нагруженными параметрами, растет количество триггеров и пользовательских ивентов в приложениях.
Из-за этого компании отдают своим аналитикам все больше и больше «сырой» информации для анализа и превращения ее в правильные решения. Важность системы аналитики для компании не должна быть недооцененной, а сама система должна быть надежной и устойчивой.
Клиентские аналитики
Клиентская аналитика — это сервис, который компания подключает для своего веб-сайта или приложения через официальное SDK, интегрирует в собственную кодбазу и выбирает ивенты-триггеры. У такого подхода есть очевидный недостаток: все собранные данные не могут быть обработаны в полной мере так, как вы хотели бы, из-за ограничений любого выбранного сервиса. Например, в одной системе будет нелегко запустить MapReduce задачи, в другой вы не сможете запустить свою модель. Еще одним минусом будет регулярный (внушительный) счет за услуги.
На рынке представлено много решений клиентской аналитики, но, рано или поздно аналитики сталкиваются с тем, что нет одного универсального сервиса, подходящего для любой задачи (тогда как цены на все эти сервисы все время растут). В такой ситуации компании нередко решают создать свою собственную систему аналитики со всеми нужными кастомными настройками и возможностями.
Серверные аналитики
Серверная аналитика — это сервис, который может быть развернут внутри компании на ее собственных серверах и (обычно) своими усилиями. В такой модели все пользовательские ивенты хранятся на внутренних серверах, позволяя разработчикам попробовать разные базы данных для хранения и выбрать самую удобную архитектуру. И даже если вы все еще хотите использовать сторонние клиентские аналитики для некоторых задач, это все еще будет возможно.
Серверную аналитику можно развернуть двумя способами. Первый: выбрать какие-то опенсорс утилиты, развернуть на своих машинах и разработать бизнес-логику.
| Плюсы | Минусы |
| Можно настраивать все, что угодно | Часто это очень сложно и нужны отдельные разработчики |
Второй: взять сервисные услуги SaaS (Amazon, Google, Azure) вместо того, чтобы развертывать самому. Про SaaS более подробно расскажем в третьей части.
| Плюсы | Минусы |
| Может быть дешевле на средних объемах, но при большом росте все равно станет слишком дорого | Не получится контролировать все параметры |
| Администрирование целиком перекладывается на плечи провайдера услуг | Не всегда известно, что внутри сервиса (может и не понадобиться) |
Как собрать серверную аналитику
Если мы хотим уйти от использования клиентских аналитик и собрать свою, прежде всего нужно продумать архитектуру новой системы. Ниже я пошагово расскажу, что нужно учесть, зачем нужен каждый из шагов и какие инструменты можно использовать.
1. Получение данных
Так же, как в случае клиентской аналитики, в первую очередь аналитики компании выбирают виды ивентов, которые хотят изучать в дальнейшем и собирают их в список. Обычно, эти ивенты происходят в определенном порядке, который называется «схемой ивентов».
Дальше, представим, что у мобильного приложения (веб-сайта) есть постоянные пользователи (устройства) и много серверов. Для безопасной передачи ивентов с устройств на серверы нужен промежуточный слой. В зависимости от архитектуры может возникать несколько разных очередей ивентов.
Apache Kafka — это pub/sub queue, которую используют как очередь для сбора ивентов.
Согласно посту на Кворе в 2014, создатель Apache Kafka решил назвать ПО в честь Франца Кафки потому, что “это система, оптимизированная для записи”, и потому что любил произведения Кафки. — Википедия
В нашем примере есть множество производителей данных и их потребителей (устройства и серверы), и Кафка помогает соединить их друг с другом. Потребители будут описаны подробнее на следующих шагах, где они будут главными субъектами. Сейчас рассмотрим только производителей данных (ивентов).
Кафка инкапсулирует понятия очереди и партиции, более конкретно об этом лучше почитать в другом месте (например, в документации). Не погружаясь в детали, представим, что мобильное приложение запущено для двух разных ОС. Тогда каждая версия создает свой отдельный поток ивентов. Продюсеры отправляют ивенты в Кафку, они записываются в подходящую очередь.
(картинка отсюда)
В то же время, Кафка позволяет считывать кусками и обрабатывать поток ивентов мини-батчами. Кафка очень удобный инструмент, который хорошо масштабируется с ростом потребностей (например, по геолокации ивентов).
Обычно одного шарда достаточно, но дела становятся сложнее в связи при масштабировании (как и всегда). Вероятно, никто не захочет использовать лишь один физический шард в продакшне, так как архитектура должна быть отказоустойчивой. Помимо Кафки есть еще одно известное решение — RabbitMQ. Мы не использовали его в продакшне как очередь для аналитики ивентов (если у вас есть такой опыт, расскажите о нем в комментариях!). Однако, использовали AWS Kinesis.
Прежде, чем перейти к следующему шагу, нужно упомянуть еще один дополнительный слой системы — хранилище сырых логов. Это не обязательный слой, но он будет полезен в случае, если что-то пойдет не так, и очереди ивентов в Кафке обнулятся. Хранение сырых логов не требует сложного и дорогого решения, можно просто записывать их куда-либо в правильном порядке (хоть на жесткий диск).
2. Обработка потоков ивентов
После того, как мы подготовили все ивенты и поместили их в подходящие очереди, переходим к шагу обработки. Здесь расскажу о двух наиболее частых вариантах обработки.
Первый вариант — это подключить Spark Streaming в системе Apache. Все продукты Apache живут в HDFS, безопасной файловой системе с репликами файлов. Spark Streaming — это удобный в работе инструмент, который обрабатывает потоковые данные и хорошо масштабируется. Однако, может быть тяжеловат в поддержании.
Другой вариант — собрать собственный обработчик ивентов. Для этого нужно, например, написать питоновское приложение, сбилдить его в докере и подписаться на очереди Кафки. Когда на обработчиков в докере будут приходить триггеры, будет запускаться обработка. При таком методе нужно держать постоянно запущенные приложения.
Предположим, что мы выбрали один из описанных выше вариантов и перейдем к самой обработке. Обработчики должны начать с проверки валидности данных, фильтровать мусор и «сломанные» ивенты. Для валидации мы обычно используем Cerberus. После этого можно сделать маппинг данных: данные с разных источников нормализуются и стандартизируются, чтобы быть добавленными в общую табличку.
3. База данных
Третий шаг — сохранить нормализованные ивенты. При работе с готовой аналитической системой нам придется часто к ним обращаться, поэтому важно подобрать удобную базу данных.
Если данные хорошо ложаться на фиксированную схему, можно выбрать Clickhouse или какую-нибудь другую колоночную базу данных. Так агрегации будут работать очень быстро. Минус в том, что схема жестко фиксирована и потому складывать произвольные объекты без доработки не получится (например, когда произойдет нестандартный ивент). Зато считать можно действительно очень быстро.
Для неструктурированных данных можно взять NoSQL, например, Apache Cassandra. Она работает на HDFS, хорошо реплицируется, можно поднять много инстансов, отказоустойчива.
Можно поднять и что-то попроще, например, MongoDB. Она довольно медленная и для небольших объемов. Но плюс в том, что она очень простая и потому подходит для старта.
4. Агрегации
Аккуратно сохранив все ивенты, мы хотим из батча, который пришел, собрать всю важную информацию и обновить БД. Глобально, мы хотим получить релевантные дашборды и метрики. Например, из ивентов собрать профиль пользователя и каким-то образом измерить поведение. Ивенты агрегируются, собираются, и снова сохраняются (уже в пользовательские таблицы). При этом можно построить систему так, чтобы к агрегатору-координатору подключать еще и фильтр: собирать пользователей только из определенного вида ивентов.
После этого, если кому-то в команде нужна только высокоуровневая аналитика, можно подключить внешние системы аналитики. Можно снова взять Mixpanel. но так как она довольно дорогая, отправлять туда уже не все пользовательские ивенты, а только то, что нужно. Для этого нужно создать координатор, который будет передавать некоторые сырые ивенты или что-то, что мы сами агрегировали ранее, во внешние системы, АПИ или рекламные платформы.
5. Фронтенд
К созданной системе нужно подключить фронтенд. Хороший пример — сервис redash, это GUI для баз данных, который помогает строить панели. Как устроено взаимодействие:
- Пользователь делает SQL запрос.
- В ответ получает табличку.
- Для нее создает ‘new visualization’ и получает красивый график, который уже можно сохранить себе.
Визуализации в сервисе автообновляемые, можно настраивать и отслеживать свои мониторинги. Redash бесплатен, в случае self-hosted, а как SaaS будет стоить 50 долларов в месяц.
Заключение
Выполнив все шаги выше, вы создадите свою серверную аналитику. Обратите внимание, что это не такой простой путь, как просто подключить клиентскую аналитику, потому что все нужно настраивать самостоятельно. Поэтому прежде, чем создавать свою систему, стоить сопоставить необходимость в серьезной системе аналитики с ресурсами, которые вы готовы на нее выделить.
Если вы все посчитали и получили, что расходы слишком высоки, в следующей части я расскажу о том, как сделать более дешевую версию серверной аналитики.
Спасибо за прочтение! Буду рад вопросам в комментариях.
