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

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

Днес няма съмнение, че точната обработка на данни и интерпретацията на резултатите може да помогне на почти всеки тип бизнес. В тази връзка аналитичните системи стават все по-натоварени с параметри, броят на тригерите и потребителските събития в приложенията нараства.
Поради това компаниите дават на своите анализатори все повече и повече "сурова" информация, за да я анализират и превърнат в правилните решения. Значението на една аналитична система за една компания не трябва да се подценява, а самата система трябва да бъде надеждна и устойчива.

Клиентски анализатори

Клиентският анализ е услуга, която една компания свързва за своя уебсайт или приложение чрез официалния SDK, интегрира го в собствената си кодова база и избира тригери за събития. Този подход има очевиден недостатък: всички събрани данни не могат да бъдат напълно обработени, както бихте искали, поради ограниченията на всяка избрана услуга. Например, на една система няма да е лесно да стартирате задачи на MapReduce, на друга няма да можете да стартирате своя модел. Друг недостатък ще бъде редовната (впечатляваща) сметка за услуги.
На пазара има много решения за клиентски анализ, но рано или късно анализаторите се сблъскват с факта, че няма една универсална услуга, подходяща за всяка задача (докато цените на всички тези услуги непрекъснато растат). В такава ситуация компаниите често решават да създадат своя собствена система за анализ с всички необходими персонализирани настройки и функции.

Сървърни анализатори

Анализът от страна на сървъра е услуга, която може да бъде внедрена вътрешно на собствените сървъри на компанията и (обикновено) вътрешно. В този модел всички потребителски събития се съхраняват на вътрешни сървъри, което позволява на разработчиците да изпробват различни бази данни за съхранение и да изберат най-удобната архитектура. И дори ако все още искате да използвате анализи от страна на клиента на трети страни за някои задачи, пак ще бъде възможно.
Анализите от страна на сървъра могат да бъдат внедрени по два начина. Първо: изберете някои помощни програми с отворен код, разположете ги на вашите машини и разработете бизнес логика.

Професионалисти
Против

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

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

Професионалисти
Против

Може да бъде по-евтино при средни обеми, но при голямо увеличение пак ще стане твърде скъпо
Не може да контролира всички параметри

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

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

Ако искаме да избягаме от използването на клиентски анализи и да изградим собствени, първо трябва да помислим върху архитектурата на новата система. По-долу ще ви кажа стъпка по стъпка какво трябва да имате предвид, защо е необходима всяка от стъпките и какви инструменти можете да използвате.

1. Събиране на данни

Точно както в случая с клиентските анализи, първо анализаторите на компанията избират типовете събития, които искат да проучат допълнително, и ги събират в списък. Обикновено тези събития се случват в определен ред, който се нарича "схема на събитията".
Освен това, нека си представим, че едно мобилно приложение (уебсайт) има редовни потребители (устройства) и много сървъри. За сигурно прехвърляне на събития от устройства към сървъри е необходим междинен слой. В зависимост от архитектурата могат да възникнат няколко различни опашки от събития.
Апачи Кафка - pub/sub опашка, който се използва като опашка за събиране на събития.

Според публикувайте в Quora през 2014 г. създателят на Apache Kafka реши да кръсти софтуера на Франц Кафка, защото „това е система, оптимизирана за писане“ и защото обичаше писанията на Кафка. — Wikipedia

В нашия пример има много производители на данни и техните потребители (устройства и сървъри), а Kafka помага да ги свърже един с друг. Потребителите ще бъдат описани по-подробно в следващите стъпки, където те ще бъдат главните действащи лица. Сега ще разгледаме само производителите на данни (събития).
Кафка капсулира концепциите за опашка и дял, по-конкретно за това е по-добре да прочетете другаде (например в документация). Без да навлизаме в подробности, нека си представим, че се стартира мобилно приложение за две различни операционни системи. След това всяка версия създава свой собствен отделен поток от събития. Продуцентите изпращат събития на Кафка, те се записват в подходяща опашка.

(снимка следователно)

В същото време Kafka ви позволява да четете на парчета и да обработвате потока от събития в мини-партиди. Kafka е много удобен инструмент, който се мащабира добре с нарастващи нужди (например чрез геолокация на събития).
Обикновено един шард е достатъчен, но нещата стават по-сложни с комуникацията при мащабиране (както винаги). Вероятно никой не иска да използва само един физически шард в производството, тъй като архитектурата трябва да е устойчива на грешки. В допълнение към Kafka има още едно добре познато решение - RabbitMQ. Не го използвахме в производството като опашка за анализ на събития (ако имате такъв опит, разкажете ни за него в коментарите!). Въпреки това беше използван AWS Kinesis.

Преди да преминете към следващата стъпка, трябва да споменем още един допълнителен слой на системата - съхранението на необработени регистрационни файлове. Това не е задължителен слой, но ще бъде полезно в случай, че нещо се обърка и опашките за събития в Kafka се нулират. Съхраняването на необработени регистрационни файлове не изисква сложно и скъпо решение, можете просто да ги запишете някъде в правилния ред (дори на твърд диск).

2. Обработка на потоци от събития

След като сме подготвили всички събития и сме ги поставили в съответните опашки, преминаваме към стъпката на обработка. Тук ще говоря за двете най-често срещани опции за обработка.
Първата опция е да активирате Spark Streaming на система Apache. Всички продукти на Apache живеят на HDFS, защитена реплика на файлова система. Spark Streaming е лесен за използване инструмент, който обработва поточни данни и се мащабира добре. Въпреки това може да бъде трудно да се поддържа.
Друг вариант е да създадете свой собствен манипулатор на събития. За да направите това, например, трябва да напишете приложение на Python, да го изградите в докер и да се абонирате за опашките на Kafka. Когато тригерите стигнат до манипулатори в докера, обработката ще започне. С този метод трябва да поддържате постоянно работещи приложения.
Да приемем, че сме избрали една от гореописаните опции и да преминем към самата обработка. Процесорите трябва да започнат с проверка на валидността на данните, филтриране на боклука и „счупени“ събития. За валидиране обикновено използваме Cerberus. След това може да се направи картографиране на данни: данните от различни източници се нормализират и стандартизират, за да бъдат добавени към обща таблица.

3. База данни

Третата стъпка е да запазите нормализирани събития. Когато работим с готова аналитична система, често ще се налага да имаме достъп до тях, затова е важно да изберем удобна база данни.
Ако данните пасват добре на фиксирана схема, можете да изберете clickhouse или някаква друга колонна база данни. Така агрегатите ще работят много бързо. Недостатъкът е, че схемата е твърдо фиксирана и следователно няма да работи за добавяне на произволни обекти без усъвършенстване (например, когато възникне нестандартно събитие). Но може да се направи много бързо.
За неструктурирани данни можете да вземете NoSQL, например, Апачи Касандра. Той работи на HDFS, репликира се добре, можете да повдигнете много екземпляри и е толерантен към грешки.
Можете да повдигнете нещо по-просто, напр. MongoDB. Доста е бавен дори за малки обеми. Но плюсът е, че е много прост и следователно подходящ за стартиране.

4. Агрегации

След като внимателно запазихме всички събития, искаме да съберем цялата важна информация от пристигналата партида и да актуализираме базата данни. В световен мащаб искаме подходящи табла за управление и показатели. Например от събития за събиране на потребителски профил и по някакъв начин измерване на поведението. Събитията се обобщават, събират и записват отново (вече в потребителските таблици). В същото време е възможно да се изгради система по такъв начин, че филтърът да бъде свързан и с координиращия агрегатор: да събира потребители само от определен тип събития.
След това, ако някой в ​​екипа се нуждае само от анализи на високо ниво, можете да свържете външни системи за анализ. Можете да вземете Mixpanel отново. но тъй като е доста скъпо, не всички потребителски събития се изпращат там, а само това, което е необходимо. За да направим това, трябва да създадем координатор, който ще прехвърли някои необработени събития или нещо, което ние сами сме събрали по-рано, към външни системи, API или рекламни платформи.

5. Преден край

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

1. Потребителят прави SQL заявка.
2. В отговор той получава знак.
3. Създава „нова визуализация“ за него и получава красива графика, която вече можете да запазите.

Визуализациите в услугата се актуализират автоматично, можете да конфигурирате и проследявате наблюдението си. Redash е безплатен в случай на самостоятелно хостване, но като SaaS ще струва $50 на месец.

Заключение

След като изпълните всички стъпки по-горе, ще създадете своя анализ от страна на сървъра. Моля, имайте предвид, че това не е толкова лесно, колкото просто свързване на клиентски анализи, защото всичко трябва да се конфигурира самостоятелно. Ето защо, преди да създадете своя собствена система, си струва да сравните необходимостта от сериозна система за анализ с ресурсите, които сте готови да отделите за нея.
Ако сте направили цялата математика и сте установили, че разходите са твърде високи, в следващата част ще говоря за това как да направите по-евтина версия на back-end analytics.

Благодаря за четенето! Ще се радвам на въпроси в коментарите.

Източник: www.habr.com