Як ми побудували аналітику з близько 100 in-house базами даних. Основні проблеми та рішення

Всім привіт! Мене звати Оксана і я Head of General Analytics у продуктовій українській компанії Jooble. Я працюю в аналітиці вже 7 років і завжди намагалась обирати для себе цікаві проєкти з викликом.

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

Чому побудова аналітики справді була викликом, особливо з технічної сторони

Для початку додам трохи контексту. Наразі у нас працює 11 data-спеціалістів, і ми плануємо розширюватись, а сама компанія має зараз 69 доменів у 69 різних країнах всюдисвітно. Фокус — це країни Європи та Північної Америки, але маємо також аудиторію в країнах Південної Америки та Азії. З урахування того, що є близько 40 млн активних користувачів на місяць, сміливо констатуємо — в нас дуже-дуже-дуже багато різних даних.

Також мали іншу проблему — інфраструктурну: кожен домен є окремою базою даних, а ці всі 69 баз розміщені на різних серверах.Таке технічне рішення давало можливість продукту краще та швидше функціонувати, але для аналітика це був жах, адже додати BI-систему було майже неможливо і зовсім недоцільно.

Водночас під час аналізу наявних даних виявилось, що raw-data зберігається лише за останні два місяці, а агреговану інформацію можна було знайти лише в кількох розрізах. Усю іншу історичну інформацію ми зберігаємо в json-архівах, і працюємо з ними лише в крайніх випадках. Бо це досить затратно по часу.

Тут варто також додати, що 69 баз — це лише продуктова частина + статистика, де зберігалась інформація, необхідна для роботи сайту, та івенти, які генерував юзер у продукті.

До того ж ми мали на окремих in-house серверах ще дані:

• SEO-команди з їх аналітичних інструментів;
• CRM-дані;
• маркетингові дані (facebook, adwords, affiliate тощо);
• рекламні дані;
• Google analytics;
• курси валют з різних джерел;
• Link Building інформація тощо.

У нас навіть СУБД зустрічалися різні: Postgres, MySQL, MS Server. Також деякі команди збирали однакову інформацію на свої сервери та дублювали роботу один одного.

Хмарні технології не використовували, бо для таких об’ємів це було б досить дорого, а сам перехід від in-house серверів до хмарних був би дуже довгим та проблемним.

Основні технічні проблеми, які маємо з самого початку:

• дуже багато інформації;
• різні місця зберігання цієї інформації;
• raw-data зберігалась лише два місяці;
• відсутність однієї узгодженої логіки в підрахунку різних метрик;
• наявна аналітична технічна інфраструктура була не готова до цього проєкту.

Які бізнес-проблеми повинен вирішити аналітик

Я, як аналітик, мала задачу вирішити такі основні запити:

• кожна команда рахувала дані за власною логікою, тому від департаменту до департаменту одні й ті ж показники могли не сходитися;
• багато даних було просто в Google Sheets, кожен вносив потрібну йому інформацію раз у певний період на основі результуючих наборів SQL-запитів;
• всі зміни в кількох основних скриптах робили через команди розробки, тому це сповільнювало процес;
• відсутність візуалізації даних, а з нею інформація читалась би легше та швидше;
• великий запит на аналітику, дослідження, доступні дані, адже компанія data-driven і всі важливі рішення мають базуватися на даних, які їх підкріплюють. І на той момент кожен, кому потрібна була інформація, витрачав багато часу на її пошук, або і взагалі не міг отримати, бо не було людей з потрібними компетенціями, які б тут могли допомогти;
• запит на актуальну і доступну аналітику, на покриття основних метрик та бізнес-показників оновлюваним репортингом у вебрішенні.

Хто замовляв мені аналітику

Також відзначу замовників аналітики з бізнесу на початку:

• СЕО-компанії з запитом на відстеження бізнес-показників;
• Customer Success команда з запитом на аналіз клієнтів B2B;
• Sales-команда з запитом на аналіз воронок продажів;
• Paid Aquisition команда з запитом на аналіз PPC-метрик;
• SEO-команда — запит на аналіз органічного трафіку та побудову звітів для цього напрямку.

Далі до цього списку доєдналися:

• Affiliate команда — запит на пророблення інфраструктури для запису даних та їх подальшої візуалізації;
• Product команда — запит на валідування продуктових гіпотез та проведення АБ тестування;
• PR команда — запит на аналіз трендів у Job-ніші для актуальних публікацій в ЗМІ.

Хух, здається, що стан справ на початок проєкту з побудови аналітики я змогла розгорнуто пояснити. Також окреслила проблематику і запит від бізнесу.

Перші ідеї та з чого почали імплементацію аналітики

Відразу була ідея — нам потрібно аналітичне сховище даних, куди ми будемо зберігати потрібну інформацію, там її поєднувати, обробляти та вже звідти брати в BI-систему для візуалізації.

Всі ці великі зміни ми почали з Data Engineer. Компанія мала сховище на Postgres, яке використовували здебільшого для бізнес-напрямку, представленого в Україні (ua.jooble.org). Ця частина бізнесу на той час активно розвивалась і потребувала аналітики. Тому DWH уже функціонувало для України.

Логіка була така:

• переносились дані з однієї з 69 баз даних саме для українського домену;
• у DWH вони агрегуватися, оброблялися та доповнювалися;
• у BI-систему потрапляли вже в потрібному вигляді.

Для однієї країни ця система працювала нормально. Тому ми відразу вирішили її масштабувати й на інші домени. Ідея здавалася досить простою:

1. кожного дня переносимо Raw-дані з усіх доменів у DWH;
2. далі за розкладом запускаємо процедури з необхідними розрахунками, групуємо та доповнюємо дані, без цього б агрегації за великий проміжок часу просто не виконувалися, адже даних було дуже багато;
3. і потім беремо їх в Tableau уже в доступному для цієї BI-системи об’ємі (ми планували не брати до Tableau понад 100 млн рядків).

Як все пішло не за планом

Але все пішло не за планом уже на першому етапі. Даних було так багато, що забрати їх з серверів за адекватний період часу просто не виходило. Інколи ми думали, що все пройшло ок, але якісь дані були втрачені. А це означає, що використовувати неконсистентну інформацію ми просто не могли. Тому перший час ми постійно робили звірки кількості даних у DWH з тими, що маємо на оригінальних серверах.

Наші спроби зайняли кілька місяців, але результат був абсолютно не стабільний. А немає нічого гіршого, ніж постійно сумніватися в аналітиці, якщо ти не впевнений в якості її збору.

Тому наступним нашим кроком стали снепшоти потрібних агрегацій вранці кожного дня за попередній. Ми виконували скрипт, який з Raw-даних робив потрібні групування і записували результат у DWH. Скрипти за один день виконуються досить швидко, результат займає уже не сотні мільйонів записів, а тисячі, тому запис в сховище також проходило без проблем.

Я з іншими аналітиками написали потрібні нам скрипти, в яких дані агрегуються. Ми намагались робити скрипти максимально універсальними, щоб їх була оптимальна кількість. Кожен такий код міг покривати 5-10 різних репортів в Tableau.

Результатами скрипту були таблиці з ключами без заздалегідь поєднаних словників для мінімізації пам’яті, яка потрібна для їх зберігання. Таким чином вранці ми отримуємо актуальні дані за вчора -> оновлюємо автоматично дешборди -> отримуємо аналітику. Ці снепшоти були на такому рівні агрегації, що ми могли їх потім у DWH поєднувати з іншими джерелами даних з інших серверів.

Наприклад, дані про наш дохід у різних країнах ми могли збагатити даними по Google analytics метриках, або ж в наші SEO АБ тести ми могли додати дані з продуктових серверів і так далі.

Система працювала вже краще, але інколи деякі сервери могли відмовити під час ETL процесу і в таких випадках виникали ситуації, коли кілька доменів просто не потрапляли в звіт, а ми про це навіть не знали. Або ж потрапляли, але частково, тому що дані почали записуватися, але далі виникла якась технічна помилка.

Тому я вирішила зробити розумний моніторинг консистентності та повноти даних.

Як він виглядає? Ми реалізували в Tableau алерти різних типів, які нам сповіщають на пошту або в Slack (інтеграція зі Slack з’явилась в цій BI-системі не так давно) такі ситуації:

• у важливі таблиці не потрапив снепшот у DWH;
• є розходження в однакових метриках, але з різних таблиць. Наприклад, дохід, який ми рахуємо кількома способами, в тоталі завжди повинен сходитись, якщо з’являється розбіжність — сповіщення на пошту;
• аномалії в даних: ми порівнюємо ключові метрики з середнім показником за попередні 7 днів, або з середнім показником за кілька попередніх таких самих днів тижня (дані за понеділок порівнюємо з середнім показником за 4 попередніх понеділки);
• сповіщення також допомагають нам знайти проблеми, коли не відпрацювали якісь процедури на проді, або ж на кінець місяця дані на проді чомусь змінилися і відрізняються від того, що ми зберегли за цей час.

Дата-інженери також зробили кілька сповіщень в Slack (наш корпоративний месенджер) для відстеження найважливіших таблиць:

Наразі проблеми з даними можуть відбуватися через різні причини, які від нас не залежать:

• проблеми з доступом до серверів (сервери перевантажені, немає доступу, переїзд);
• дані не з’явилися на оригінальному сервері (наприклад, змінилося API або доступи, що ми використовували, більше вже не актуальні);
• проблеми з вільним місцем на оригінальному сервері тощо.

В середньому на місяць такі ситуації трапляються від двох до п’яти разів, і завжди ми можемо це відловити та виправити.

Яка в нас зараз вийшла система

Якщо підсумувати:

1. За допомогою ETL-сервісу Pentaho (ver 9.2) збираємо дані зі всіх серверів в аналітичне сховище. Потужності сервера DWH — 4 диски по 2 Тб (8 Тб), 64 ядра CPU, 376 Гб оперативної пам’яті. До переїзду на ці сервери у нас був період, коли в пікові моменти ми мали навантаження на сервер критичне, були залучені всі ресурси, на цю мить загальне навантаження в нас 20-35%, і це ми ще додатково приросли в загальній кількості трансформацій.
2. У DWH ми маємо дані, далі пишемо view, щоб отримати всю необхідну інформацію з таблиць, різних джерел, словників, додаємо логіку розрахунку метрик і так далі.
3. Після цього створюємо джерело даних у Tableau, яке має назву цього view (щоб завжди легше було знайти код) та посилання на gitlab.
4. На основі джерела даних у Tableau будуємо необхідні дешборди. Дешборди підтримуємо в актуальному стані, якщо ми бачимо, що репортом уже не користуються, ми зупиняємо його оновлення і переносимо в архів. Раз в якийсь період архів зберігається локально і видаляється з сервера.
5. Намагаємось робити максимально наповнені даними джерела для Tableau, щоб легко можна було додавати в різні репорти потрібні показники. В Tableau ми маємо наразі 47 основних джерел даних, на основі яких будуються дешборди.
6. За консистентністю даних стежимо через систему алертів. Маємо відповідальну людину, яка моніторить, щоб проблеми з алертів були усунуті.
7. Зміни в SQL-скриптах проводимо через merge request в gitlab, щоб мати актуальні та доступні запити, які можна прикріпити в Tableau як посилання для кращого розуміння логіки підрахунку. Таким чином дешборд або view можуть постійно змінювати та доповнювати різні спеціалісти, вони доступні, відкриті та зрозумілі.
8. Маємо аналітичний беклог в jira, де наші замовники можуть створювати завдання. Рутинних завдань майже немає, тому що ми намагаємось автоматизувати все, що можливо. Тому аналітичні будні у мене дуже цікаві, аналітики постійно є учасниками нових проєктів та ініціатив.
9. Також проводили навчання з Tableau, якщо у співробітників є прагнення в побудові власних дешбордів або в кастомізації наявних під свої потреби, ми даємо відповідну ліцензію в BI-систему. І таким чином наш колега в спеціальному user-edit-space може робити будь-які зміни власноруч.

З некритичних помилок, які ми допустили й ще не виправили, — забули з самого початку обрати один шаблон і кольорову гаму для репортів у Tableau. Наразі перероблювати всі вітрини затратно по часу, але якщо у вас ще є шанс — з самого початку розробіть шаблон звіту: послідовність фільтрів, опис, назви та підказки, одну палітру в корпоративних кольорах компанії та один шрифт.

Це надасть вашим вітринам зрозумілішого вигляду, користувач системи відразу буде знати, де які елементи. Наша тека зі звітами має дещо строкатий вигляд:

Наступні кроки

Зараз маємо наступну мету — оновлювати дані вже погодинно, і дати доступ до raw-даних спеціалістам, які цього потребують та мають ціль вивчити нескладні ази SQL.

Вже почали робити репліку продуктових даних, де зашифрували особисту інформацію користувача (імена, пошти, телефони тощо). Ця інформація не потрібна для аналізу, і за GDPR-політикою має бути недоступна, тому в нашій репліці ми її зашифрували або взагалі не враховуємо під час копіювання.

У наших планах — зберігати дані в репліці не 2 місяці, як не на прод-серверах, а 6, щоб мати змогу зробити будь-які постаналізи, мати змогу обернутися на пів року назад.

Також репліка дозволить нам робити необхідні агрегації не раз на день, а, наприклад, кожної години. Для деяких департаментів погодинне оновлення вже стає актуальним, і ми хочемо задовольнити цей запит.

Ми відкриті до зміни BI-системи з Tableau на інструмент, який швидше працює з великими об’ємами даних, але поки не знайшли краще рішення, хоча тестували різні варіанти. Більшість рішень є дуже негнучкими і може з’явитися залежність від менеджера продукту. Тому, якщо у вас є якісь поради — буду рада почитати їх в коментарях!

Інша проблема, що обмежує нас у виборі, — це in-house DWH, з хмарними технологіями вибір був би більшим.

Тепер переді мною як керівником аналітичного відділу стоять уже не тільки технічні проблеми, а також аналітичні та менеджерські:

• пошук точок росту бізнесу в даних;
• відстеження аномалій та швидка реакція на них;
• розвиток команди аналітики та створення прозорої системи компетенцій;
• пошук нових інструментів та підходів в аналітиці;
• участь в генерації продуктових ідей та в покращенні наявних процесів.

Підсумую: чому такі зміни стали можливими

Основні зміни відбулися десь за рік. За цей час ми перейшли від статистики в Google Sheets до консистентного, актуального і повного репортинга в BI-системі.

Все це було б неможливо без людей в команді і підтримки. По-перше, керівництво сприяло data-driven підходу. СЕО мого бізнес-напрямку максимально підтримував розвиток аналітичної інфраструктури, допомагав з пошуком технічних рішень та сприяв популяризації аналітики в самій компанії.

По друге, є сильна DWH-команда, інженери дійсно класно підтримують всі ETL-процеси, швидко реагують на проблеми, займаються технічною стороною питання — апрувлять нові й нові сервери та диски для зберігання нашої інформації, роблять оптимізацію сховища, пишуть нескінченні API-інтеграції і дизайнять архітектуру DWH.

І, по-третє, — команда аналітики. Аналітики в бізнесі є носіями знань з різних сфер, наприклад, вони можуть підказати продуктовій команді, як певні зміни повпливають на платний трафік, або розповісти Customer Success команді, як буде рахуватися нова модель монетизації.

Мені б дуже хотілося наголосити, що сьогодні вже майже всі розуміють важливість інформації, але ще не всі вміють з нею працювати. Тому не бійтеся занурюватися у світ цифр. Аналітичне мислення та вміння оперувати метриками й показниками — must have компетенції сьогодення. Базуючись на коректній та своєчасній інформації, можна допомагати мінімізувати втрати та шукати точки росту вашого бізнесу.

Дякую за увагу! Сподіваюсь, мій досвід може бути корисним для вас, буду рада почути також поради та запитання в коментарях!