Aquesta és la segona part d'una sèrie d'articles sobre sistemes analítics ().
Avui dia ja no hi ha cap dubte que el tractament acurat de les dades i la interpretació dels resultats pot ajudar a gairebé qualsevol tipus de negoci. En aquest sentit, els sistemes analítics estan cada cop més carregats de paràmetres i el nombre de disparadors i esdeveniments d'usuari a les aplicacions està creixent.
Per això, les empreses donen als seus analistes cada cop més informació bruta per analitzar-la i convertir-la en decisions encertades. No s'ha de subestimar la importància d'un sistema d'anàlisi per a una empresa, i el propi sistema ha de ser fiable i estable.
Analistes de clients
L'anàlisi de clients és un servei que una empresa connecta al seu lloc web o aplicació mitjançant l'SDK oficial, s'integra a la seva pròpia base de codi i selecciona activadors d'esdeveniments. Hi ha un inconvenient evident d'aquest enfocament: és possible que totes les dades recollides no es processin exactament com voldríeu a causa de les limitacions de qualsevol servei que trieu. Per exemple, en un sistema no serà fàcil executar tasques de MapReduce, en un altre no podreu executar el vostre model. Un altre desavantatge serà la factura regular (impressionant) dels serveis.
Hi ha moltes solucions d'anàlisi de clients al mercat, però tard o d'hora els analistes s'enfronten al fet que no hi ha un servei universal adequat per a cada tasca (mentre els preus de tots aquests serveis augmenten constantment). En aquesta situació, les empreses sovint decideixen crear el seu propi sistema d'anàlisi amb totes les opcions i capacitats personalitzades necessàries.
Analistes de servidors
L'anàlisi del costat del servidor és un servei que es pot desplegar dins d'una empresa als seus propis servidors i (normalment) amb els seus propis esforços. En aquest model, tots els esdeveniments d'usuari s'emmagatzemen en servidors interns, cosa que permet als desenvolupadors provar diferents bases de dades d'emmagatzematge i triar l'arquitectura més convenient. I fins i tot si encara voleu utilitzar analítiques de clients de tercers per a algunes tasques, encara serà possible.
L'anàlisi del servidor es pot desplegar de dues maneres. Primer: trieu algunes utilitats de codi obert, implementeu-les a les vostres màquines i desenvolupeu la lògica empresarial.
Pros
Contres
Podeu personalitzar el que vulgueu
Això sovint és molt difícil i requereix desenvolupadors separats
Segon: preneu els serveis SaaS (Amazon, Google, Azure) en lloc d'implementar-los vosaltres mateixos. Parlarem de SaaS amb més detall a la tercera part.
Pros
Contres
Pot ser més barat a volums mitjans, però amb un gran creixement encara serà massa car
No serà possible controlar tots els paràmetres
L'administració es transfereix íntegrament a les espatlles del proveïdor de serveis
No sempre se sap què hi ha dins del servei (pot ser que no sigui necessari)
Com recopilar l'anàlisi del servidor
Si volem allunyar-nos de l'ús de l'anàlisi de clients i construir-ne el nostre, primer de tot hem de pensar en l'arquitectura del nou sistema. A continuació us explicaré pas a pas què heu de tenir en compte, per què cal cada pas i quines eines podeu utilitzar.
1. Recepció de dades
Igual que en el cas de l'anàlisi de clients, en primer lloc, els analistes de l'empresa seleccionen els tipus d'esdeveniments que volen estudiar en el futur i els recullen en una llista. Normalment, aquests esdeveniments ocorren en un ordre específic, anomenat "patró d'esdeveniment".
A continuació, imagineu que una aplicació mòbil (lloc web) té usuaris habituals (dispositius) i molts servidors. Per transferir de manera segura els esdeveniments dels dispositius als servidors, cal una capa intermèdia. Depenent de l'arquitectura, pot haver-hi diverses cues d'esdeveniments diferents.
- És , que s'utilitza com a cua per recollir esdeveniments.
Segons el 2014, el creador d'Apache Kafka va decidir batejar el programari amb el nom de Franz Kafka perquè "és un sistema optimitzat per escriure" i perquè li encantaven les obres de Kafka. —
En el nostre exemple, hi ha molts productors de dades i consumidors de dades (dispositius i servidors), i Kafka ajuda a connectar-los entre ells. Els consumidors es descriuran amb més detall en els passos següents, on ells seran els principals subjectes. Ara considerarem només els productors de dades (esdeveniments).
Kafka encapsula els conceptes de cua i partició; és millor llegir-ne més específicament en un altre lloc (per exemple, a ). Sense entrar en detalls, imaginem que es llança una aplicació mòbil per a dos sistemes operatius diferents. A continuació, cada versió crea el seu propi flux d'esdeveniments independent. Els productors envien esdeveniments a Kafka, es registren en una cua adequada.
(imatge )
Al mateix temps, Kafka us permet llegir en trossos i processar un flux d'esdeveniments en mini-lots. Kafka és una eina molt convenient que s'adapta bé a les necessitats creixents (per exemple, mitjançant la geolocalització d'esdeveniments).
Normalment n'hi ha prou amb un fragment, però les coses es compliquen més en escalar (com sempre ho fan). Probablement ningú voldrà utilitzar només un fragment físic en producció, ja que l'arquitectura ha de ser tolerant a errors. A més de Kafka, hi ha una altra solució coneguda: RabbitMQ. No el vam utilitzar en producció com a cua per a l'anàlisi d'esdeveniments (si teniu aquesta experiència, digueu-nos-ho als comentaris!). Tanmateix, hem utilitzat AWS Kinesis.
Abans de passar al següent pas, hem d'esmentar una capa addicional més del sistema: l'emmagatzematge de registres en brut. Aquesta no és una capa necessària, però serà útil si alguna cosa va malament i es restableixen les cues d'esdeveniments a Kafka. L'emmagatzematge de registres en brut no requereix una solució complexa i costosa; simplement podeu escriure'ls en algun lloc en l'ordre correcte (fins i tot en un disc dur).
2. Processament de fluxos d'esdeveniments
Després d'haver preparat tots els esdeveniments i col·locats a les cues adequades, passem al pas de processament. Aquí us explicaré les dues opcions de processament més habituals.
La primera opció és habilitar Spark Streaming al sistema Apache. Tots els productes Apache viuen a HDFS, un sistema de fitxers segur amb rèpliques de fitxers. Spark Streaming és una eina fàcil d'utilitzar que gestiona dades de transmissió i s'escala bé. Tanmateix, pot ser difícil de mantenir.
Una altra opció és crear el vostre propi gestor d'esdeveniments. Per fer-ho, necessiteu, per exemple, escriure una aplicació Python, crear-la a Docker i subscriure-us a la cua de Kafka. Quan els activadors arribin als controladors de docker, s'iniciarà el processament. Amb aquest mètode, heu de mantenir les aplicacions en funcionament en tot moment.
Suposem que hem escollit una de les opcions descrites anteriorment i passem al processament en si. Els processadors haurien de començar per comprovar la validesa de les dades, filtrant les escombraries i els esdeveniments "trencats". Per a la validació normalment fem servir . Després d'això, podeu fer mapes de dades: les dades de diferents fonts es normalitzen i s'estandarditzen per afegir-les a una taula comuna.
3. Base de dades
El tercer pas és mantenir els esdeveniments normalitzats. Quan es treballa amb un sistema analític preparat, haurem d'accedir-hi sovint, per la qual cosa és important escollir una base de dades convenient.
Si les dades encaixen bé en un esquema fix, podeu triar o alguna altra base de dades columnar. D'aquesta manera les agregacions funcionaran molt ràpidament. L'inconvenient és que l'esquema està rígidament fixat i, per tant, no serà possible afegir objectes arbitraris sense modificacions (per exemple, quan es produeix un esdeveniment no estàndard). Però pots comptar molt ràpidament.
Per a dades no estructurades, podeu prendre NoSQL, per exemple, . S'executa amb HDFS, es replica bé, podeu plantejar moltes instàncies i és tolerant a errors.
També podeu plantejar alguna cosa més senzilla, per exemple, . És bastant lent i per a volums petits. Però l'avantatge és que és molt senzill i, per tant, apte per començar.
4. Agregacions
Després d'haver desat amb cura tots els esdeveniments, volem recollir tota la informació important del lot que va arribar i actualitzar la base de dades. A nivell mundial, volem obtenir taulers i mètriques rellevants. Per exemple, recopilar un perfil d'usuari a partir d'esdeveniments i mesurar d'alguna manera el comportament. Els esdeveniments s'agreguen, es recullen i es tornen a guardar (a les taules d'usuari). Al mateix temps, podeu construir un sistema perquè també pugueu connectar un filtre a l'agregador-coordinador: recollir usuaris només d'un determinat tipus d'esdeveniment.
Després d'això, si algú de l'equip només necessita analítiques d'alt nivell, es poden connectar sistemes d'anàlisi externs. Podeu tornar a prendre Mixpanel. però com que és bastant car, no s'hi envien tots els esdeveniments d'usuari, sinó només els que es necessiten. Per fer-ho, hem de crear un coordinador que transferirà alguns esdeveniments en brut o quelcom que nosaltres mateixos hem agregat abans a sistemes externs, API o plataformes publicitàries.
5. Frontend
Heu de connectar la interfície al sistema creat. Un bon exemple és el servei , és una GUI de base de dades que ajuda a crear taulers de control. Com funciona la interacció:
- L'usuari fa una consulta SQL.
- En resposta rep un senyal.
- En crea una "nova visualització" i obté un gràfic preciós que podeu desar per vosaltres mateixos.
Les visualitzacions del servei s'actualitzen automàticament, podeu personalitzar i fer un seguiment del vostre seguiment. Redash és gratuït si està allotjat personalment, però com a SaaS costarà 50 dòlars al mes.
Conclusió
Després de completar tots els passos anteriors, creareu l'anàlisi del vostre servidor. Tingueu en compte que això no és tan senzill com connectar l'anàlisi de clients, perquè tot s'ha de configurar vosaltres mateixos. Per tant, abans de crear el vostre propi sistema, val la pena comparar la necessitat d'un sistema d'anàlisi seriós amb els recursos que esteu disposats a destinar-hi.
Si heu fet les matemàtiques i heu trobat que els costos són massa alts, a la següent part parlaré de com fer una versió més barata de l'anàlisi del costat del servidor.
Gràcies per llegir! Estaré encantat de fer preguntes als comentaris.
Font: www.habr.com