Серверски аналитички системи

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

Денес веќе нема никакво сомневање дека внимателната обработка на податоците и толкувањето на резултатите може да помогне во речиси секој тип на бизнис. Во овој поглед, аналитичките системи стануваат сè пооптоварени со параметри, а бројот на предизвикувачи и кориснички настани во апликациите расте.
Поради ова, компаниите им даваат на своите аналитичари сè повеќе необработени информации за да ги анализираат и да ги претворат во здрави одлуки. Важноста на аналитичкиот систем за една компанија не треба да се потценува, а самиот систем мора да биде сигурен и стабилен.

Клиенти аналитичари

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

Серверски аналитичари

Анализата од страна на серверот е услуга што може да се распореди во рамките на компанијата на сопствените сервери и (обично) со сопствени напори. Во овој модел, сите кориснички настани се складираат на внатрешни сервери, овозможувајќи им на програмерите да пробаат различни бази на податоци за складирање и да ја изберат најзгодната архитектура. И дури и ако сè уште сакате да користите аналитика на клиенти од трета страна за некои задачи, тоа сепак ќе биде можно.
Анализата од страна на серверот може да се распореди на два начина. Прво: изберете некои алатки со отворен код, распоредете ги на вашите машини и развијте деловна логика.

Добрите
Конс

Можете да прилагодите сè што сакате
Ова е често многу тешко и бара посебни програмери

Второ: земете ги услугите на SaaS (Amazon, Google, Azure) наместо сами да ги распоредите. За SaaS ќе зборуваме подетално во третиот дел.

Добрите
Конс

Можеби е поевтин при средни количини, но со голем раст сепак ќе стане прескап
Нема да биде можно да се контролираат сите параметри

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

Како да соберете аналитика на серверот

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

1. Примање податоци

Исто како и во случајот со аналитиката на клиентите, пред сè, аналитичарите на компаниите ги избираат видовите настани што сакаат да ги проучуваат во иднина и ги собираат во список. Вообичаено, овие настани се случуваат по одреден редослед, наречен „шема на настани“.
Следно, замислете дека мобилната апликација (веб-страница) има редовни корисници (уреди) и многу сервери. За безбедно пренесување настани од уреди на сервери, потребен е среден слој. Во зависност од архитектурата, може да има неколку различни редици за настани.
Апачи Кафка - Дали паб/под редица, кој се користи како редица за собирање настани.

Според објава на Quora во 2014 година, креаторот на Апачи Кафка одлучил да го именува софтверот по Франц Кафка бидејќи „тоа е систем оптимизиран за пишување“ и затоа што ги сакал делата на Кафка. - Википедија

Во нашиот пример, има многу производители на податоци и корисници на податоци (уреди и сервери), а Кафка помага да се поврзат едни со други. Потрошувачите ќе бидат подетално опишани во следните чекори, каде што тие ќе бидат главни субјекти. Сега ќе ги разгледаме само производителите на податоци (настани).
Кафка ги опфаќа концептите на ред и поделба; подобро е да прочитате поконкретно за ова на друго место (на пример, во документација). Без да навлегуваме во детали, да замислиме дека е лансирана мобилна апликација за два различни ОС. Потоа секоја верзија создава свој посебен тек на настани. Продуцентите испраќаат настани до Кафка, тие се снимаат во соодветна редица.

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

Во исто време, Кафка ви овозможува да читате во парчиња и да обработувате тек на настани во мини серии. Кафка е многу удобна алатка која добро се размерува со растечките потреби (на пример, со геолокација на настаните).
Обично еден фрагмент е доволен, но работите стануваат покомплицирани при скалирање (како и секогаш). Веројатно никој нема да сака да користи само еден физички фрагмент во производството, бидејќи архитектурата мора да биде толерантна за грешки. Покрај Кафка, постои уште едно добро познато решение - RabbitMQ. Не го користевме во производството како редица за аналитика на настани (ако имате такво искуство, кажете ни за тоа во коментарите!). Сепак, користевме AWS Kinesis.

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

2. Обработка на текови на настани

Откако ќе ги подготвиме сите настани и ќе ги поставиме во соодветните редици, преминуваме на чекорот за обработка. Овде ќе ви кажам за двете најчести опции за обработка.
Првата опција е да се овозможи Spark Streaming во системот Apache. Сите производи на Apache живеат на HDFS, безбеден датотечен систем со реплики на датотеки. Spark Streaming е лесна за употреба алатка која добро се справува со стриминг податоци и скали. Сепак, може да биде тешко да се одржи.
Друга опција е да изградите сопствен управувач за настани. За да го направите ова, треба, на пример, да напишете апликација за Python, да ја изградите во Docker и да се претплатите на редот на Kafka. Кога предизвикувачите ќе пристигнат кај ракувачите на докер, ќе започне обработката. Со овој метод, треба да ги одржувате апликациите постојано да работат.
Да претпоставиме дека избравме една од опциите опишани погоре и да преминеме на самата обработка. Процесорите треба да започнат со проверка на валидноста на податоците, филтрирање ѓубре и „скршени“ настани. За валидација обично користиме Серберус. По ова, можете да направите мапирање на податоци: податоците од различни извори се нормализираат и стандардизираат за да се додадат во заедничка табела.

3. База на податоци

Третиот чекор е одржување на нормализирани настани. Кога работиме со готов аналитички систем, ќе мораме често да им пристапуваме, па затоа е важно да избереме погодна база на податоци.
Ако податоците добро се вклопуваат во фиксна шема, можете да изберете кликхаус или некоја друга колонообразна база на податоци. На овој начин агрегациите ќе работат многу брзо. Негативната страна е што шемата е строго фиксирана и затоа нема да биде можно да се додаваат произволни објекти без измена (на пример, кога ќе се појави нестандарден настан). Но, можете да броите навистина многу брзо.
За неструктурирани податоци, можете да земете NoSQL, на пример, Апачи касандра. Работи на HDFS, добро се реплицира, може да покренете многу примери и е толерантен на грешки.
Можете исто така да подигнете нешто поедноставно, на пример, MongoDB. Тоа е прилично бавно и за мали волумени. Но, плус е тоа што е многу едноставен и затоа е погоден за стартување.

4. Агрегации

Откако внимателно ги зачувавме сите настани, сакаме да ги собереме сите важни информации од серијата што пристигна и да ја ажурираме базата на податоци. На глобално ниво, сакаме да добиеме релевантни контролни табли и метрика. На пример, соберете кориснички профил од настани и некако измерете го однесувањето. Настаните се собираат, собираат и повторно се зачувуваат (во корисничките табели). Во исто време, можете да изградите систем за да можете да поврзете и филтер со агрегаторот-координатор: собирајте корисници само од одреден тип на настани.
После тоа, ако на некој од тимот му треба само аналитика на високо ниво, може да се поврзат надворешни аналитички системи. Можете повторно да земете Mixpanel. но бидејќи е прилично скап, таму не се испраќаат сите кориснички настани, туку само она што е потребно. За да го направите ова, треба да создадеме координатор кој ќе пренесе некои необработени настани или нешто што ние самите претходно го собравме на надворешни системи, API или платформи за рекламирање.

5. Преден дел

Треба да го поврзете предниот дел со креираниот систем. Добар пример е услугата црвенило, е GUI на базата на податоци што помага во изградбата на контролни табли. Како функционира интеракцијата:

1. Корисникот прави SQL барање.
2. Како одговор добива знак.
3. Создава „нова визуелизација“ за него и добива прекрасен график што можете да го зачувате за себе.

Визуелизациите во услугата се ажурираат автоматски, можете да го приспособите и следите вашиот мониторинг. Редаш е бесплатен ако е домаќин, но како SaaS ќе чини 50 долари месечно.

Заклучок

Откако ќе ги завршите сите чекори погоре, ќе креирате аналитика на вашиот сервер. Ве молиме имајте предвид дека ова не е толку едноставно како само поврзување на аналитиката на клиентите, бидејќи сè треба сами да се конфигурира. Затоа, пред да креирате сопствен систем, вреди да се спореди потребата од сериозен аналитички систем со ресурсите што сте спремни да му ги распределите.
Ако сте направиле математика и сте откриле дека трошоците се превисоки, во следниот дел ќе зборувам за тоа како да направите поевтина верзија на аналитика од страна на серверот.

Ви благодариме за читањето! Ќе ми биде драго да поставувам прашања во коментарите.

Извор: www.habr.com