Це друга частина циклу статей про аналітичні системи ().
Сьогодні вже не викликає сумнівів, що акуратна обробка даних та інтерпретація результатів можуть допомогти практично будь-якому виду бізнесу. У зв'язку з цим аналітичні системи стають все більш навантаженими параметрами, зростає кількість тригерів і івентів користувача в додатках.
Через це компанії віддають своїм аналітикам дедалі більше «сирої» інформації для аналізу та перетворення її на правильні рішення. Важливість системи аналітики для компанії не повинна бути недооціненою, а сама система має бути надійною та стійкою.
Клієнтські аналітики
Клієнтська аналітика - це сервіс, який компанія підключає для свого веб-сайту або програми через офіційне SDK, інтегрує у власну кодбазу та вибирає івенти-тригери. Такий підхід має очевидний недолік: всі зібрані дані не можуть бути оброблені повною мірою так, як ви хотіли б, через обмеження будь-якого обраного сервісу. Наприклад, в одній системі нелегко буде запустити MapReduce завдання, в іншій ви не зможете запустити свою модель. Ще одним мінусом буде регулярний (значний) рахунок за послуги.
На ринку представлено багато рішень клієнтської аналітики, але, рано чи пізно аналітики стикаються з тим, що немає одного універсального сервісу, що підходить для будь-якого завдання (тоді як ціни на всі ці сервіси постійно зростають). У такій ситуації компанії нерідко вирішують створити свою власну систему аналітики з усіма потрібними кастомними налаштуваннями та можливостями.
Серверні аналітики
Серверна аналітика - це сервіс, який може бути розгорнутий всередині компанії на її власних серверах і (зазвичай) своїми зусиллями. У такій моделі всі івенти користувача зберігаються на внутрішніх серверах, дозволяючи розробникам спробувати різні бази даних для зберігання і вибрати найзручнішу архітектуру. І навіть якщо ви все ще хочете використовувати сторонні клієнтські аналітики для деяких завдань, це все ще буде можливим.
Серверну аналітику можна розгорнути двома способами. Перший: вибрати якісь опенсорс утиліти, розгорнути на своїх машинах та розробити бізнес-логіку.
Плюси
Мінуси
Можна настроювати все, що завгодно
Часто це дуже складно і потрібні окремі розробники
Друге: взяти сервісні послуги SaaS (Amazon, Google, Azure) замість того, щоб розгортати самому. Про SaaS детальніше розповімо в третій частині.
Плюси
Мінуси
Можливо дешевше на середніх обсягах, але при великому зростанні все одно стане занадто дорого
Не вдасться контролювати всі параметри
Адміністрація повністю перекладається на плечі провайдера послуг
Не завжди відомо, що всередині сервісу (може й не знадобитися)
Як зібрати серверну аналітику
Якщо ми хочемо уникнути використання клієнтських аналітик і зібрати свою, перш за все потрібно продумати архітектуру нової системи. Нижче я крок за кроком розповім, що потрібно врахувати, навіщо потрібен кожен з кроків і які інструменти можна використовувати.
1. Отримання даних
Так само, як у випадку клієнтської аналітики, насамперед аналітики компанії обирають види івентів, які хочуть вивчати надалі та збирають їх до списку. Зазвичай, ці івенти відбуваються у порядку, який називається «схемою івентів».
Далі, уявимо, що мобільний додаток (веб-сайт) має постійні користувачі (пристрої) і багато серверів. Для безпечної передачі івентів із пристроїв на сервери потрібен проміжний шар. Залежно від архітектури може бути кілька різних черг івентів.
- це , яку використовують як черга для збирання івентів.
Згідно з 2014 року, творець Apache Kafka вирішив назвати ПЗ на честь Франца Кафки тому, що “це система, оптимізована для запису”, і тому що любив твори Кафки. -
У нашому прикладі є безліч виробників даних та їх споживачів (пристрою та сервери), і Кафка допомагає з'єднати їх один з одним. Споживачі буде описано докладніше на наступних кроках, де вони будуть головними суб'єктами. Зараз розглянемо лише виробників даних (івентів).
Кафка інкапсулює поняття черги та партиції, більш конкретно про це краще почитати в іншому місці (наприклад, в ). Не поринаючи в деталі, уявимо, що мобільний додаток запущено для двох різних ОС. Тоді кожна версія створює окремий потік івентів. Продюсери відправляють івенти до Кафки, вони записуються у відповідну чергу.
(картинка )
У той же час Кафка дозволяє зчитувати шматками і обробляти потік івентів міні-батчами. Кафка дуже зручний інструмент, який добре масштабується зі зростанням потреб (наприклад, геолокації івентів).
Зазвичай одного шарда достатньо, але справи стають складнішими у зв'язку з масштабуванням (як і завжди). Ймовірно, ніхто не захоче використовувати лише один фізичний шард у продакшні, оскільки архітектура має бути стійкою до відмови. Крім Кафки є ще одне відоме рішення – RabbitMQ. Ми не використовували його у продакшні як чергу для аналітики івентів (якщо у вас є такий досвід, розкажіть про нього у коментарях!). Однак використовували AWS Kinesis.
Перш ніж перейти до наступного кроку, слід згадати ще один додатковий шар системи — сховище сирих ліг. Це не обов'язковий шар, але він буде корисним у разі, якщо щось піде не так, і черги івентів у Кафці обнуляться. Зберігання сирих логів не вимагає складного і дорогого рішення, можна просто записувати їх у правильному порядку (хоча на жорсткий диск).
2. Обробка потоків івентів
Після того, як ми підготували всі івенти та помістили їх у відповідні черги, переходимо до кроку обробки. Тут розповім про два найчастіші варіанти обробки.
Перший варіант – це підключити Spark Streaming у системі Apache. Всі продукти Apache живуть у HDFS, безпечній файловій системі з репліками файлів. Spark Streaming – це зручний у роботі інструмент, який обробляє потокові дані та добре масштабується. Однак, може бути важким у підтримці.
Інший варіант - зібрати власний обробник івентів. Для цього потрібно, наприклад, написати пітонівську програму, збилдить її в докері і підписатися на черзі Кафки. Коли на обробників у докері приходитимуть тригери, запускатиметься обробка. За такого методу потрібно тримати постійно запущені програми.
Припустимо, що ми вибрали один з описаних вище варіантів і перейдемо до обробки. Обробники повинні почати з перевірки валідності даних, фільтрувати сміття та «зламані» івенти. Для валідації ми зазвичай використовуємо . Після цього можна зробити мапінг даних: дані з різних джерел нормалізуються та стандартизуються, щоб бути доданими до загальної таблички.
3. База даних
Третій крок – зберегти нормалізовані івенти. При роботі з готовою аналітичною системою нам доведеться часто до них звертатися, тому важливо підібрати зручну базу даних.
Якщо дані добре лягатимуть на фіксовану схему, можна вибрати або якусь іншу колонкову базу даних. Так агрегації працюватимуть дуже швидко. Мінус у тому, що схема жорстко фіксована, і тому складати довільні об'єкти без доопрацювання не вийде (наприклад, коли станеться нестандартний івент). Зате вважати можна справді дуже швидко.
Для неструктурованих даних можна взяти NoSQL, наприклад, . Вона працює на HDFS, добре реплікується, можна підняти багато інстансів, стійка до відмови.
Можна підняти і щось простіше, наприклад, . Вона є досить повільною і для невеликих обсягів. Але плюс у тому, що вона дуже проста і тому підходить для старту.
4. Агрегації
Акуратно зберігши всі івенти, ми хочемо з батча, який прийшов, зібрати всю важливу інформацію та оновити БД. Глобально, ми хочемо отримати релевантні дашборди та метрики. Наприклад, з івентів зібрати профіль користувача та якимось чином виміряти поведінку. Івенти агрегуються, збираються, і знову зберігаються (вже в таблиці користувача). При цьому можна побудувати систему так, щоб до агрегатора-координатора підключати ще й фільтр: збирати користувачів тільки з певного виду івентів.
Після цього якщо комусь у команді потрібна тільки високорівнева аналітика, можна підключити зовнішні системи аналітики. Можна знову взяти Mixpanel. але оскільки вона досить дорога, відправляти туди вже не всі івенти користувача, а тільки те, що потрібно. Для цього потрібно створити координатор, який передаватиме деякі сирі івенти або щось, що ми самі агрегували раніше, до зовнішніх систем, АПІ або рекламних платформ.
5. Фронтенд
До створеної системи необхідно підключити фронтенд. Хороший приклад - сервіс Це GUI для баз даних, який допомагає будувати панелі. Як влаштована взаємодія:
- Користувач робить запит SQL.
- У відповідь отримує табличку.
- Для неї створює 'new visualization' і отримує гарний графік, який можна зберегти собі.
Візуалізації в сервісі автооновлювані, можна налаштовувати та відстежувати свої моніторинги. Redash безкоштовний, у випадку self-hosted, а як SaaS буде коштувати 50 доларів на місяць.
Висновок
Виконавши всі кроки вище, ви створите серверну аналітику. Зауважте, що це не такий простий шлях, як просто підключити клієнтську аналітику, тому що все потрібно налаштовувати самостійно. Тому перш, ніж створювати свою систему, варто зіставити необхідність у серйозній системі аналітики з ресурсами, які ви готові на неї виділити.
Якщо ви всі порахували і отримали, що витрати надто високі, в наступній частині я розповім про те, як зробити дешевшу версію серверної аналітики.
Дякую за прочитання! Буду радий питанням у коментарях.
Джерело: habr.com