Esta é a segunda parte dunha serie de artigos sobre sistemas analíticos ().
Hoxe xa non cabe dúbida de que un coidadoso tratamento dos datos e a interpretación dos resultados pode axudar a case calquera tipo de negocio. Neste sentido, os sistemas analíticos están cada vez máis cargados de parámetros, e o número de disparadores e eventos de usuario nas aplicacións é cada vez maior.
Por iso, as empresas están a dar aos seus analistas cada vez máis información bruta para analizala e converter en decisións acertadas. Non se debe subestimar a importancia dun sistema de análise para unha empresa, e o propio sistema debe ser fiable e estable.
Analistas de clientes
A analítica de clientes é un servizo que unha empresa se conecta ao seu sitio web ou aplicación a través do SDK oficial, integra na súa propia base de código e selecciona activadores de eventos. Hai unha desvantaxe obvia deste enfoque: todos os datos recollidos poden non ser procesados exactamente como desexa debido ás limitacións de calquera servizo que elixa. Por exemplo, nun sistema non será fácil executar tarefas de MapReduce, noutro non poderá executar o seu modelo. Outra desvantaxe será a factura regular (impresionante) dos servizos.
Hai moitas solucións de análise de clientes no mercado, pero tarde ou cedo os analistas enfróntanse ao feito de que non hai un servizo universal axeitado para cada tarefa (mentres os prezos de todos estes servizos están a subir todo o tempo). Nesta situación, as empresas adoitan decidir crear o seu propio sistema de análise con todas as opcións e capacidades personalizadas necesarias.
Analistas de servidores
A análise do lado do servidor é un servizo que se pode implementar dentro dunha empresa nos seus propios servidores e (normalmente) cos seus propios esforzos. Neste modelo, todos os eventos do usuario almacénanse en servidores internos, o que permite aos desenvolvedores probar diferentes bases de datos de almacenamento e escoller a arquitectura máis conveniente. E aínda que aínda queira usar análises de clientes de terceiros para algunhas tarefas, aínda será posible.
A análise do servidor pódese implementar de dúas formas. Primeiro: elixe algunhas utilidades de código aberto, implantaas nas túas máquinas e desenvolve a lóxica empresarial.
Pros
Contra
Podes personalizar o que queiras
Isto adoita ser moi difícil e require desenvolvedores separados
Segundo: toma os servizos SaaS (Amazon, Google, Azure) en lugar de implementalos ti mesmo. Falaremos de SaaS con máis detalle na terceira parte.
Pros
Contra
Pode ser máis barato en volumes medios, pero cun gran crecemento aínda será demasiado caro
Non será posible controlar todos os parámetros
A administración transfírese enteiramente aos ombreiros do provedor de servizos
Non sempre se sabe o que hai dentro do servizo (pode que non sexa necesario)
Como recoller análises do servidor
Se queremos afastarnos do uso de analíticas de clientes e construír a nosa propia, antes de nada debemos pensar na arquitectura do novo sistema. A continuación vouche dicir paso a paso o que debes ter en conta, por que é necesario cada paso e que ferramentas podes utilizar.
1. Recepción de datos
Do mesmo xeito que no caso da analítica de clientes, en primeiro lugar, os analistas das empresas seleccionan os tipos de eventos que queren estudar no futuro e recóllenos nunha lista. Normalmente, estes eventos ocorren nunha orde específica, chamada "patrón de eventos".
A continuación, imaxina que unha aplicación móbil (sitio web) ten usuarios habituais (dispositivos) e moitos servidores. Para transferir eventos de forma segura dos dispositivos aos servidores, é necesaria unha capa intermedia. Dependendo da arquitectura, pode haber varias colas de eventos diferentes.
- É , que se usa como cola para recoller eventos.
Conforme en 2014, o creador de Apache Kafka decidiu poñerlle o nome de Franz Kafka ao software porque "é un sistema optimizado para escribir" e porque lle encantaban as obras de Kafka. —
No noso exemplo, hai moitos produtores de datos e consumidores de datos (dispositivos e servidores), e Kafka axuda a conectalos entre si. Os consumidores serán descritos con máis detalle nos seguintes pasos, onde serán os temas principais. Agora consideraremos só os produtores de datos (eventos).
Kafka encapsula os conceptos de cola e partición; é mellor ler máis específicamente sobre isto noutro lugar (por exemplo, en ). Sen entrar en detalles, imaxinemos que se lanza unha aplicación móbil para dous SO diferentes. A continuación, cada versión crea o seu propio fluxo de eventos separado. Os produtores envían eventos a Kafka, grávanse nunha cola adecuada.
(imaxe )
Ao mesmo tempo, Kafka permítelle ler en anacos e procesar un fluxo de eventos en mini-lotes. Kafka é unha ferramenta moi cómoda que se adapta ben ás necesidades crecentes (por exemplo, mediante a xeolocalización de eventos).
Normalmente un fragmento é suficiente, pero as cousas complícanse máis ao escalar (como sempre fan). Probablemente ninguén queira usar só un fragmento físico na produción, xa que a arquitectura debe ser tolerante a fallos. Ademais de Kafka, hai outra solución coñecida: RabbitMQ. Non o usamos na produción como cola para a análise de eventos (se tes esa experiencia, cóntanos nos comentarios!). Non obstante, usamos AWS Kinesis.
Antes de pasar ao seguinte paso, necesitamos mencionar unha capa adicional do sistema: o almacenamento de rexistros en bruto. Esta non é unha capa obrigatoria, pero será útil se algo sae mal e se restablecen as filas de eventos en Kafka. O almacenamento de rexistros en bruto non require unha solución complexa e custosa; simplemente podes escribilos nalgún lugar na orde correcta (mesmo nun disco duro).
2. Procesamento de fluxos de eventos
Despois de ter preparado todos os eventos e colocados nas filas axeitadas, pasamos ao paso de procesamento. Aquí falarei sobre as dúas opcións de procesamento máis comúns.
A primeira opción é activar Spark Streaming no sistema Apache. Todos os produtos de Apache viven en HDFS, un sistema de ficheiros seguro con réplicas de ficheiros. Spark Streaming é unha ferramenta fácil de usar que xestiona datos de transmisión e escala ben. Non obstante, pode ser difícil de manter.
Outra opción é crear o teu propio controlador de eventos. Para iso, necesitas, por exemplo, escribir unha aplicación Python, creala en Docker e subscribirte á cola de Kafka. Cando os disparadores cheguen aos controladores do docker, comezará o procesamento. Con este método, cómpre manter as aplicacións en execución en todo momento.
Supoñamos que escollemos unha das opcións descritas anteriormente e pasamos ao procesamento en si. Os procesadores deberían comezar comprobando a validez dos datos, filtrando o lixo e os eventos "rotos". Para validación adoitamos usar . Despois disto, podes facer un mapeo de datos: os datos de diferentes fontes normalízanse e normalízanse para engadirse a unha táboa común.
3. Base de datos
O terceiro paso é manter os eventos normalizados. Cando se traballe cun sistema analítico preparado, teremos que acceder a eles con frecuencia, polo que é importante escoller unha base de datos conveniente.
Se os datos encaixan ben nun esquema fixo, podes escoller ou algunha outra base de datos columnar. Deste xeito, as agregacións funcionarán moi rapidamente. A desvantaxe é que o esquema está rixidamente fixado e, polo tanto, non será posible engadir obxectos arbitrarios sen modificación (por exemplo, cando se produce un evento non estándar). Pero podes contar moi rápido.
Para datos non estruturados, pode tomar NoSQL, por exemplo, . Funciona en HDFS, réplica ben, pode crear moitas instancias e é tolerante a fallos.
Tamén podes plantexar algo máis sinxelo, por exemplo, . É bastante lento e para pequenos volumes. Pero a vantaxe é que é moi sinxelo e, polo tanto, axeitado para comezar.
4. Agregacións
Tras gardar coidadosamente todos os eventos, queremos recoller toda a información importante do lote que chegou e actualizar a base de datos. A nivel mundial, queremos obter paneis e métricas relevantes. Por exemplo, recompila un perfil de usuario a partir de eventos e mide o comportamento dalgún xeito. Os eventos agréganse, recóllense e gárdanse de novo (nas táboas de usuarios). Ao mesmo tempo, podes construír un sistema para que tamén poidas conectar un filtro ao coordinador-agregador: recolle usuarios só dun determinado tipo de evento.
Despois diso, se alguén do equipo só necesita análise de alto nivel, pódense conectar sistemas de análise externos. Podes tomar Mixpanel de novo. pero como é bastante caro, non todos os eventos de usuario se envían alí, senón só os que se necesitan. Para iso, necesitamos crear un coordinador que trasladará algúns eventos en bruto ou algo que nós mesmos agregamos anteriormente a sistemas externos, API ou plataformas publicitarias.
5. Frontend
Debe conectar o frontend ao sistema creado. Un bo exemplo é o servizo , é unha GUI de base de datos que axuda a crear paneis de control. Como funciona a interacción:
- O usuario fai unha consulta SQL.
- En resposta recibe un sinal.
- Crea unha "nova visualización" para el e obtén un fermoso gráfico que podes gardar para ti.
As visualizacións do servizo actualízanse automaticamente, podes personalizar e rastrexar o teu seguimento. Redash é gratuíto se está autoaloxado, pero como SaaS custará 50 dólares ao mes.
Conclusión
Despois de completar todos os pasos anteriores, creará as análises do servidor. Teña en conta que isto non é tan sinxelo como só conectar as análises de clientes, porque todo debe ser configurado vostede mesmo. Polo tanto, antes de crear o teu propio sistema, paga a pena comparar a necesidade dun sistema de análise serio cos recursos que estás disposto a destinarlle.
Se fixeches os cálculos e descubriches que os custos son demasiado altos, na seguinte parte falarei sobre como facer unha versión máis barata da analítica do servidor.
Grazas por ler! Estarei encantado de facer preguntas nos comentarios.
Fonte: www.habr.com