Гэта другая частка цыклу артыкулаў аб аналітычных сістэмах ().
Сёння ўжо не выклікае сумневаў, што акуратная апрацоўка дадзеных і інтэрпрэтацыя вынікаў могуць дапамагчы практычна любому ўвазе бізнэсу. У сувязі з гэтым аналітычныя сістэмы становяцца ўсё больш нагружанымі параметрамі, расце колькасць трыгераў і карыстацкіх івэнтаў у дадатках.
З-за гэтага кампаніі аддаюць сваім аналітыкам усё больш і больш "волкай" інфармацыі для аналізу і ператварэння яе ў правільныя рашэнні. Важнасць сістэмы аналітыкі для кампаніі не павінна быць недаацэненай, а сама сістэма павінна быць надзейнай і ўстойлівай.
Кліенцкія аналітыкі
Кліенцкая аналітыка - гэта сэрвіс, які кампанія падлучае для свайго вэб-сайта або дадатку праз афіцыйнае 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