Системи за анализу сервера

Ово је други део серије чланака о аналитичким системима (линк до 1. дела).

Данас нема сумње да тачна обрада података и интерпретација резултата могу помоћи готово свакој врсти пословања. С тим у вези, аналитички системи постају све оптерећенији параметрима, расте број окидача и корисничких догађаја у апликацијама.
Због тога компаније својим аналитичарима дају све више „сирових“ информација да их анализирају и претворе у праве одлуке. Не треба потцењивати значај аналитичког система за компанију, а сам систем треба да буде поуздан и одржив.

Клијентски аналитичари

Клијентска аналитика је услуга коју компанија повезује за своју веб локацију или апликацију преко званичног СДК-а, интегрише га у сопствену базу кода и бира покретаче догађаја. Овај приступ има очигледан недостатак: сви прикупљени подаци не могу се у потпуности обрадити како бисте желели, због ограничења било које одабране услуге. На пример, на једном систему неће бити лако покренути МапРедуце задатке, на другом нећете моћи да покренете свој модел. Још један недостатак ће бити редован (импресиван) рачун за услуге.
На тржишту постоји много решења за аналитику клијената, али се пре или касније аналитичари сусрећу са чињеницом да не постоји универзална услуга која би одговарала било ком задатку (док цене за све ове услуге стално расту). У таквој ситуацији, компаније се често одлучују да креирају сопствени систем анализе са свим потребним прилагођеним подешавањима и функцијама.

Аналитичари сервера

Аналитика на страни сервера је услуга која се може применити интерно на сопственим серверима компаније и (обично) интерно. У овом моделу, сви кориснички догађаји се чувају на интерним серверима, омогућавајући програмерима да испробају различите базе података за складиштење и одаберу најпогоднију архитектуру. Чак и ако и даље желите да користите аналитику на страни клијента треће стране за неке задатке, то ће и даље бити могуће.
Аналитика на страни сервера може се применити на два начина. Прво: изаберите неке услужне програме отвореног кода, примените их на својим машинама и развијте пословну логику.

Прозодија
Против

Можете прилагодити било шта
Често је то веома тешко и потребни су засебни програмери

Друго: узмите СааС услуге (Амазон, Гоогле, Азуре) уместо да их сами примењујете. О СааС-у ћемо детаљније говорити у трећем делу.

Прозодија
Против

Може бити јефтиније на средњим количинама, али са великим повећањем ће и даље постати прескупо
Није могуће контролисати све параметре

Администрација је у потпуности пребачена на рамена пружаоца услуга
Није увек познато шта се налази унутар услуге (можда није потребно)

Како прикупити серверску аналитику

Ако желимо да побегнемо од коришћења клијентске аналитике и да изградимо сопствену, пре свега морамо да размислимо о архитектури новог система. У наставку ћу вам рећи корак по корак шта треба да узмете у обзир, зашто је сваки од корака потребан и које алате можете да користите.

1. Прикупљање података

Као иу случају аналитике клијената, пре свега, аналитичари компаније бирају типове догађаја које желе даље да проучавају и прикупљају их у листу. Обично се ови догађаји дешавају одређеним редоследом, који се назива "шема догађаја".
Даље, замислимо да мобилна апликација (веб сајт) има редовне кориснике (уређаје) и много сервера. За сигуран пренос догађаја са уређаја на сервере, потребан је средњи слој. У зависности од архитектуре, може се појавити неколико различитих редова догађаја.
Апацхе Кафка - Је пуб/под ред, који се користи као ред за прикупљање догађаја.

Према објавите на Куора 2014. творац Апацхе Кафке одлучио је да софтвер назове по Францу Кафки јер је „то систем оптимизован за писање“ и зато што је волео Кафкине списе. — Википедиа

У нашем примеру, постоји много произвођача података и њихових потрошача (уређаја и сервера), а Кафка помаже да се међусобно повежу. Потрошачи ће бити детаљније описани у наредним корацима, где ће они бити главни актери. Сада ћемо размотрити само произвођаче података (догађаје).
Кафка обухвата концепте реда и партиције, тачније о томе је боље прочитати на другом месту (на пример, у документација). Не улазећи у детаље, замислимо да је покренута мобилна апликација за два различита оперативна система. Затим свака верзија креира свој посебан ток догађаја. Произвођачи шаљу догађаје Кафки, они се снимају у одговарајућем реду.

(слика стога)

У исто време, Кафка вам омогућава да читате у деловима и обрађујете ток догађаја у мини серијама. Кафка је веома згодан алат који се добро прилагођава растућим потребама (на пример, геолокацијом догађаја).
Обично је довољна једна крхотина, али ствари постају компликованије са комуникацијом приликом скалирања (као и увек). Вероватно нико не жели да користи само један физички део у производњи, пошто архитектура мора бити толерантна на грешке. Поред Кафке, постоји још једно познато решење - РаббитМК. Нисмо га користили у продукцији као ред за анализу догађаја (ако имате такво искуство, реците нам о томе у коментарима!). Међутим, коришћен је АВС Кинесис.

Пре него што пређемо на следећи корак, потребно је поменути још један додатни слој система - складиштење сирових трупаца. Ово није обавезан слој, али ће бити користан у случају да нешто крене наопако и да се редови догађаја у Кафки ресетују на нулу. Чување необрађених дневника не захтева сложено и скупо решење, можете их једноставно записати негде у исправном редоследу (чак и на чврсти диск).

2. Руковање токовима догађаја

Након што смо припремили све догађаје и поставили их у одговарајуће редове, прелазимо на корак обраде. Овде ћу говорити о две најчешће опције обраде.
Прва опција је да омогућите Спарк Стреаминг на Апацхе систему. Сви Апацхе производи живе на ХДФС, безбедном систему реплика датотека. Спарк Стреаминг је алатка која се лако користи и која добро обрађује стримовање података и скалира. Међутим, може бити тешко одржавати.
Друга опција је да направите сопствени обрађивач догађаја. Да бисте то урадили, на пример, морате да напишете Питхон апликацију, да је направите у Доцкер-у и да се претплатите на Кафкине редове. Када окидачи дођу до руковалаца у докеру, обрада ће почети. Са овом методом, потребно је да стално покрећете апликације.
Претпоставимо да смо изабрали једну од горе описаних опција и пређимо на саму обраду. Процесори би требало да почну провером валидности података, филтрирањем смећа и „покварених“ догађаја. За валидацију обично користимо Церберус. Након тога се може урадити мапирање података: подаци из различитих извора се нормализују и стандардизују како би се додали у заједничку табелу.

3. База података

Трећи корак је да сачувате нормализоване догађаје. Када радимо са готовим аналитичким системом, често ћемо морати да им приступимо, па је важно одабрати погодну базу података.
Ако се подаци добро уклапају у фиксну шему, можете изабрати цлицкхоусе или неке друге базе података колона. Дакле, агрегације ће радити веома брзо. Недостатак је што је шема ригидно фиксирана и стога неће радити да се додају произвољни објекти без прецизирања (на пример, када дође до нестандардног догађаја). Али то се може урадити веома брзо.
За неструктуриране податке можете узети НоСКЛ, на пример, Апацхе цассандра. Ради на ХДФС-у, добро се реплицира, можете покренути многе инстанце и отпоран је на грешке.
Можете подићи нешто једноставније, нпр. МонгоДБ. Прилично је спор чак и за мале количине. Али плус је што је веома једноставан и стога погодан за почетак.

4. Агрегације

Пошто смо пажљиво сачували све догађаје, желимо да прикупимо све важне информације из серије која је стигла и ажурирамо базу података. Глобално, желимо релевантне контролне табле и метрике. На пример, од догађаја за прикупљање корисничког профила и на неки начин мерење понашања. Догађаји се агрегирају, прикупљају и поново чувају (већ у корисничким табелама). Истовремено, могуће је изградити систем на начин да је филтер повезан и са координационим агрегатором: да прикупља кориснике само из одређене врсте догађаја.
Након тога, ако је некоме у тиму потребна само аналитика високог нивоа, можете повезати екстерне системе за анализу. Можете поново узети Микпанел. али пошто је то прилично скупо, тамо се не шаљу сви кориснички догађаји, већ само оно што је потребно. Да бисмо то урадили, потребно је да креирамо координатора који ће пренети неке необрађене догађаје или нешто што смо сами раније агрегирали на спољне системе, АПИ-је или платформе за оглашавање.

5. Фронтенд

Потребно је да повежете фронтенд са креираним системом. Добар пример је услуга. редасх, је ГУИ базе података који помаже у изградњи панела. Како функционише интеракција:

1. Корисник прави СКЛ упит.
2. Као одговор, добија знак.
3. Креира 'нову визуелизацију' за њега и добија прелеп графикон који већ можете сами да сачувате.

Визуелизације у сервису се аутоматски ажурирају, можете да конфигуришете и пратите свој надзор. Редасх је бесплатан, у случају самосталног хостовања, али као СааС коштаће 50 долара месечно.

Закључак

Након што завршите све горе наведене кораке, креираћете своју аналитику на страни сервера. Имајте на уму да ово није тако једноставно као једноставно повезивање аналитике клијента, јер све треба сами да конфигуришете. Стога, пре него што креирате сопствени систем, вреди упоредити потребу за озбиљним аналитичким системом са ресурсима које сте спремни да му доделите.
Ако сте све израчунали и открили да су трошкови превисоки, у следећем делу ћу говорити о томе како да направите јефтинију верзију позадинске аналитике.

Хвала за читање! Биће ми драго за питања у коментарима.

Извор: ввв.хабр.цом