Aceleramos el procesamiento de eventos a 1.6 millones por segundo

Cuando los participantes de HighLoad ++ llegaron al informe de Alexander Krasheninnikov , esperaban escuchar sobre el procesamiento de 1,600,000 eventos por segundo. Las expectativas no se hicieron realidad ... Debido a que durante la preparación para el rendimiento, esta cifra aumentó a 1.800.000 , por lo que, en HighLoad ++, la realidad supera las expectativas.

Hace 3 a√Īos, Alexander cont√≥ c√≥mo construyeron un sistema de procesamiento de eventos escalable casi en tiempo real en Badoo. Desde entonces, ha evolucionado, los vol√ļmenes han crecido en el proceso, fue necesario resolver los problemas de escala y tolerancia a fallas, y en alg√ļn momento se requirieron medidas radicales: un cambio en la pila tecnol√≥gica .



A partir del descifrado, aprenderá cómo en Badoo reemplazó el paquete Spark + Hadoop con ClickHouse, guardó el hardware 3 veces y aumentó la carga 6 veces , por qué y por qué medios recopilar estadísticas en el proyecto, y luego qué hacer con estos datos.



Sobre el orador: Alexander Krasheninnikov ( alexkrash ) - Jefe de Ingeniería de Datos en Badoo. Está involucrado en la infraestructura de BI, escalando las cargas de trabajo y administra los equipos que construyen la infraestructura de procesamiento de datos. Le encanta todo lo distribuido: Hadoop, Spark, ClickHouse. Estoy seguro de que se pueden preparar sistemas distribuidos geniales desde OpenSource.

Colección de estadísticas


Si no tenemos datos, estamos ciegos y no podemos administrar nuestro proyecto. Es por eso que necesitamos estadísticas, para monitorear la viabilidad del proyecto. Nosotros, como ingenieros, deberíamos esforzarnos por mejorar nuestros productos y, si lo desea, medirlo. Este es mi lema en el trabajo. En primer lugar, nuestro objetivo son los beneficios comerciales. Las estadísticas proporcionan respuestas a preguntas comerciales . Las métricas técnicas son métricas técnicas, pero la empresa también está interesada en los indicadores, y también deben tenerse en cuenta.

Estadísticas del ciclo de vida


Defino el ciclo de vida de las estadísticas por 4 puntos, cada uno de los cuales discutiremos por separado.



Definir Fase - Formalización


En la aplicaci√≥n, recopilamos varias m√©tricas. En primer lugar, estas son m√©tricas comerciales . Si tiene un servicio de fotograf√≠a, por ejemplo, se pregunta cu√°ntas fotos se cargan por d√≠a, por hora, por segundo. Las siguientes m√©tricas son "semi-t√©cnicas" : capacidad de respuesta de una aplicaci√≥n m√≥vil o sitio, trabajo de API, qu√© tan r√°pido interact√ļa un usuario con un sitio, instalaci√≥n de la aplicaci√≥n, UX. El seguimiento del comportamiento del usuario es la tercera m√©trica importante. Estos son sistemas como Google Analytics y Yandex.Metrics. Tenemos nuestro propio sistema de seguimiento, en el que invertimos mucho.

En el proceso de trabajar con estadísticas, muchos usuarios están involucrados, estos son desarrolladores y análisis de negocios. Es importante que todos hablen el mismo idioma, por lo que debe estar de acuerdo.

Es posible negociar verbalmente, pero es mucho mejor cuando esto ocurre formalmente, en una estructura clara de eventos.

La formalizaci√≥n de la estructura de los eventos comerciales es cuando el desarrollador dice cu√°ntos registros tenemos, el analista entiende que se le proporcion√≥ informaci√≥n no solo sobre el n√ļmero total de registros, sino tambi√©n por pa√≠s, g√©nero y otros par√°metros. Y toda esta informaci√≥n est√° formalizada y es de dominio p√ļblico para todos los usuarios de la empresa . El evento tiene una estructura mecanografiada y una descripci√≥n formal. Por ejemplo, almacenamos esta informaci√≥n en formato Protocol Buffers .

Descripción del evento "Registro":

enum Gender { FEMALE = 1; MALE = 2; } message Registration { required int32 userid =1; required Gender usergender = 2; required int32 time =3; required int32 countryid =4; } 

El evento de registro contiene información sobre el usuario, el campo, la hora del evento y el país de registro del usuario. Esta información está disponible para los analistas y, en el futuro, la empresa comprende lo que recopilamos.

¬ŅPor qu√© necesito una descripci√≥n formal?


Una descripción formal es la uniformidad para los desarrolladores, analistas y el departamento de productos. Entonces esta información impregna la descripción de la lógica empresarial de la aplicación. Por ejemplo, tenemos un sistema interno para describir los procesos comerciales y en él hay una pantalla con una nueva función.



En el documento de requisitos del producto hay una secci√≥n con las instrucciones de que cuando el usuario interact√ļa con la aplicaci√≥n de esta manera, debemos enviar un evento con exactamente los mismos par√°metros. Posteriormente, podremos validar qu√© tan bien funcionan nuestras caracter√≠sticas y que las medimos correctamente. Una descripci√≥n formal nos permite comprender mejor c√≥mo guardar estos datos en una base de datos: NoSQL, SQL u otros. Tenemos un esquema de datos , y eso es genial.

En algunos sistemas anal√≠ticos que se proporcionan como un servicio, solo hay 10-15 eventos en el almacenamiento secreto. En nuestro pa√≠s, este n√ļmero ha crecido m√°s de 1000 y no va a detenerse; es imposible vivir sin un solo registro .

Definir resumen de fase


Decidimos que las estadísticas, esto es importante y describimos un área temática determinada , es bueno, puedes seguir viviendo.

Fase de recopilación: recopilación de datos


Decidimos construir el sistema para que cuando ocurra un evento comercial (registro, envío de un mensaje, como) al mismo tiempo que guardamos esta información, enviemos por separado un determinado evento estadístico.

En el código, las estadísticas se envían simultáneamente con el evento comercial.

Se procesa de manera completamente independiente de los almacenes de datos en los que se ejecuta la aplicación, porque el flujo de datos pasa a través de una tubería de procesamiento separada.

Descripción a través de EDL:

 enum Gender { FEMALE = 1; MALE = 2; } message Registration { required int32 user_id =1; required Gender user_gender = 2; required int32 time =3; required int32 country_id =4; } 

Tenemos una descripción del evento de registro. Se genera automáticamente una API, accesible para los desarrolladores desde el código, que en 4 líneas le permite enviar estadísticas.

API basada en EDL:

 \EDL\Event\Regist ration::create() ->setUserId(100500) ->setGender(Gender: :MALE) ->setTime(time()) ->send(); 

Entrega de eventos


Este es nuestro sistema externo. Hacemos esto porque tenemos servicios increíbles que proporcionan una API para trabajar con datos de fotos, sobre otra cosa. Todos almacenan datos en bases de datos novedosas, como Aerospike y CockroachDB.

Cuando necesita crear alg√ļn tipo de informe, no tiene que ir y luchar: "Chicos, ¬Ņcu√°nto de esto tienen y cu√°nto?" - Todos los datos se env√≠an en un flujo separado. Transportador de procesamiento - sistema externo. Desde el contexto de la aplicaci√≥n, desatamos todos los datos del repositorio de l√≥gica de negocios y los enviamos a una tuber√≠a separada.

La fase de recopilación supone la disponibilidad de servidores de aplicaciones. Tenemos este PHP.



Transporte


Este es un subsistema que nos permite enviar a otra tuber√≠a lo que hicimos desde el contexto de la aplicaci√≥n. El transporte se selecciona √ļnicamente seg√ļn sus requisitos, seg√ļn la situaci√≥n del proyecto.

El transporte tiene características, y el primero son las garantías de entrega. Características del transporte: al menos una vez, exactamente una vez, elige estadísticas para tus tareas, en función de la importancia de estos datos. Por ejemplo, para los sistemas de facturación es inaceptable que las estadísticas muestren más transacciones de las que hay; esto es dinero, no es posible.

El segundo parámetro son los enlaces para lenguajes de programación. De alguna manera debemos interactuar con el transporte, por lo que se selecciona de acuerdo con el idioma en el que se escribe el proyecto.

El tercer parámetro es la escalabilidad. Como estamos hablando de millones de eventos por segundo, sería bueno tener en cuenta la escalabilidad futura.

Hay muchas opciones de transporte: aplicaciones RDBMS, Flume, Kafka o LSD. Usamos LSD , esta es nuestra forma especial.

Transmisión en vivo del demonio


El LSD no tiene nada que ver con sustancias prohibidas. Este es un demonio de transmisi√≥n animado y muy r√°pido que no proporciona ning√ļn agente para escribirle. Podemos ajustarlo, tenemos integraci√≥n con otros sistemas : HDFS, Kafka, podemos reorganizar los datos enviados. El LSD no tiene una llamada de red en INSERT, y puede controlar la topolog√≠a de la red.

Lo más importante, este es OpenSource de Badoo, no hay razón para no confiar en este software.

Si fuera un demonio perfecto, entonces, en lugar de Kafka, hablaríamos de LSD en cada conferencia, pero cada LSD tiene una mosca en la pomada. Tenemos nuestras propias limitaciones con las que nos sentimos cómodos: no tenemos soporte de replicación en LSD y tiene al menos una garantía de entrega. Además, para las transacciones de dinero, este no es el transporte más adecuado, pero generalmente necesita comunicarse con dinero exclusivamente a través de bases de datos "ácidas", que admiten ACID .

Recopilar resumen de fase


Con base en los resultados de la serie anterior, recibimos una descripción formal de los datos, generamos una API excelente y conveniente para los despachadores de eventos de ellos, y descubrimos cómo transferir estos datos desde el contexto de la aplicación a una tubería separada . Ya no está mal, y nos estamos acercando a la siguiente fase.

Proceso de fase: procesamiento de datos


Recopilamos datos de registros, subimos fotos, encuestas. ¬ŅQu√© hacer con todo esto? De estos datos queremos obtener gr√°ficos con una larga historia y datos sin procesar . Los gr√°ficos entienden todo: no es necesario ser un desarrollador para comprender desde la curva que los ingresos de la compa√Ī√≠a est√°n creciendo. Utilizamos datos en bruto para informes en l√≠nea y ad-hoc. Para casos m√°s complejos, nuestros analistas desean realizar consultas anal√≠ticas sobre estos datos. Tanto eso como esa funcionalidad son necesarios para nosotros.

Gr√°ficos


Los gr√°ficos vienen en muchas formas.



O, por ejemplo, un gr√°fico con un historial que muestra datos de 10 a√Īos.



Los gráficos son incluso así.



Este es el resultado de una prueba AB, y es sorprendentemente similar al edificio Chrysler en Nueva York.

Hay dos formas de dibujar un gráfico: una consulta de datos en bruto y una serie de tiempo . Ambos enfoques tienen desventajas y ventajas, que no analizaremos en detalle. Utilizamos un enfoque híbrido : mantenemos una breve cola de datos sin procesar para informes operativos y series de tiempo para almacenamiento a largo plazo. El segundo se calcula a partir del primero.

Cómo hemos crecido a 1.8 millones de eventos por segundo


Es una larga historia: millones de RPS no suceden en un día. Badoo es una empresa con una década de historia, y podemos decir que el sistema de procesamiento de datos creció con la empresa.



Al principio no teníamos nada. Comenzamos a recopilar datos: resultaron 5.000 eventos por segundo. ¡Un host MySQL y nada más! Cualquier DBMS relacional hará frente a esta tarea, y se sentirá cómodo con ella: tendrá transaccionalidad, ingresará los datos, recibirá solicitudes, todo funciona bien y bien. Entonces vivimos por un tiempo.

En alg√ļn momento, ocurri√≥ el fragmentaci√≥n funcional: datos de registro, aqu√≠, y sobre fotos, all√≠. As√≠ que vivimos hasta 200,000 eventos por segundo y comenzamos a usar varios enfoques combinados: para almacenar datos no brutos, sino agregados , pero hasta ahora dentro de la base de datos relacional. Almacenamos contadores, pero la esencia de la mayor√≠a de las bases de datos relacionales es tal que ser√° imposible ejecutar una consulta DISTINCT sobre estos datos: el modelo algebraico de contadores no permite calcular DISTINCT.

En Badoo tenemos el lema "Fuerza imparable" . No íbamos a parar y crecimos más. En el momento en que cruzamos el umbral de 200,000 eventos por segundo , decidimos crear una descripción formal, de la que hablé anteriormente. Antes de eso, hubo un poco de caos, y ahora tenemos un registro estructurado de eventos: comenzamos a escalar el sistema, conectamos Hadoop , todos los datos fueron a las tablas de Hive.

Hadoop es un gran paquete de software, sistema de archivos. Para la informática distribuida, Hadoop dice: "Ponga los datos aquí, le dejaré realizar consultas analíticas sobre ellos". Así lo hicimos, escribimos un cálculo regular de todos los gráficos , resultó bien. Pero los gráficos son valiosos cuando se actualizan rápidamente: una vez al día, ver una actualización del gráfico no es tan divertido. Si lanzamos algo que conduce a un error fatal en la producción, nos gustaría ver que el gráfico caiga de inmediato, y no cada dos días. Por lo tanto, todo el sistema comenzó a degradarse después de un tiempo. Sin embargo, nos dimos cuenta de que en esta etapa, puede apegarse a la pila de tecnología seleccionada.

Para nosotros, Java era nuevo, nos gustó y entendimos lo que se podía hacer de manera diferente.

En la etapa de 400,000 a 800,000 eventos por segundo , reemplazamos a Hadoop en su forma m√°s pura y Hive, como ejecutor de consultas anal√≠ticas, con Spark Streaming , escribi√≥ un mapa gen√©rico / reducci√≥n y c√°lculo incremental de m√©tricas. Hace 3 a√Īos dije c√≥mo lo hicimos. Entonces nos pareci√≥ que Spark vivir√≠a para siempre, pero la vida decret√≥ lo contrario: nos encontramos con las limitaciones de Hadoop. Quiz√°s si tuvi√©ramos otras condiciones, seguir√≠amos viviendo con Hadoop.

Otro problema, además de calcular gráficos en Hadoop, fueron las increíbles consultas SQL de cuatro pisos que fueron conducidas por analistas, y los gráficos no se actualizaron rápidamente. El hecho es que hay un trabajo bastante complicado con el procesamiento de datos operativos, por lo que es en tiempo real, rápido y genial.

Badoo es atendido por dos centros de datos ubicados en dos lados del Océano Atlántico, en Europa y América del Norte. Para crear un informe unificado, debe enviar datos de América a Europa. Es en el centro de datos europeo donde guardamos todas las estadísticas estadísticas, porque hay más poder de cómputo. Un recorrido de ida y vuelta entre centros de datos de aproximadamente 200 ms (la red es bastante delicada) no es lo mismo hacer una solicitud a otro DC que ir al siguiente rack.

Cuando comenzamos a formalizar eventos y desarrolladores, y los gerentes de producto se involucraron, a todos les gust√≥ todo, solo hubo un crecimiento explosivo de eventos . En este momento, era hora de comprar hierro en el cl√ļster, pero realmente no quer√≠amos hacer esto.

Cuando superamos el pico de 800,000 eventos por segundo , descubrimos lo que Yandex hab√≠a subido a OpenSource ClickHouse , y decidimos probarlo. Llenaron un tren de conos mientras intentaban hacer algo, y como resultado, cuando todo funcion√≥, hicieron una peque√Īa recepci√≥n en el buffet sobre el primer mill√≥n de eventos. Probablemente, ClickHouse podr√≠a haber terminado el informe.

Solo toma ClickHouse y vive con él.

Pero esto no es interesante, por lo que continuaremos hablando sobre el procesamiento de datos.

Clickhouse


ClickHouse es una exageraci√≥n de los √ļltimos dos a√Īos y no necesita ser presentado: solo en HighLoad ++ en 2018 recuerdo unos cinco informes al respecto, as√≠ como seminarios y reuniones.

Esta herramienta est√° dise√Īada para resolver exactamente las tareas que establecemos para nosotros mismos. Hay actualizaciones y chips en tiempo real que recibimos de Hadoop: replicaci√≥n, fragmentaci√≥n. No hab√≠a raz√≥n para no probar ClickHouse, porque entendieron que con la implementaci√≥n en Hadoop ya hab√≠amos roto el fondo. La herramienta es genial, y la documentaci√≥n generalmente es buena: escrib√≠ all√≠ yo mismo, realmente me gusta todo, y todo es genial. Pero tuvimos que resolver una serie de problemas.

¬ŅC√≥mo cambiar todo el flujo de eventos en ClickHouse? ¬ŅC√≥mo combinar datos de dos centros de datos? Por el hecho de que acudimos a los administradores y les dijimos: "Chicos, vamos a instalar ClickHouse", no har√°n que la red sea dos veces m√°s gruesa, y el retraso es la mitad. No, la red sigue siendo tan delgada y peque√Īa como el primer salario.

¬ŅC√≥mo almacenar los resultados ? En Hadoop, entendimos c√≥mo dibujar gr√°ficos, pero ¬Ņc√≥mo hacerlo en el m√°gico ClickHouse? La varita m√°gica no est√° incluida. ¬ŅC√≥mo entregar resultados al almacenamiento de series temporales?

Como dijo mi profesor en el instituto, considere 3 esquemas de datos: estratégico, lógico y físico.

Esquema de almacenamiento estratégico


Tenemos 2 centros de datos . Aprendimos que ClickHouse no sabe nada sobre los DC, y acabamos de abrir el cl√ļster en cada DC. Ahora los datos no se mueven a trav√©s del cable cruzado del Atl√°ntico : todos los datos que ocurrieron en el DC se almacenan localmente en su cl√ļster. Cuando deseamos realizar una solicitud sobre los datos combinados, por ejemplo, para averiguar cu√°ntos registros hay en ambos DC, ClickHouse nos brinda esta oportunidad. Baja latencia y disponibilidad para la solicitud, ¬°solo una obra maestra!



Esquema de almacenamiento físico


Nuevamente, preguntas: ¬Ņc√≥mo caer√°n nuestros datos en el modelo relacional ClickHouse, qu√© se debe hacer para no perder replicaci√≥n y fragmentaci√≥n? Todo se describe ampliamente en la documentaci√≥n de ClickHouse , y si tiene m√°s de un servidor, se encontrar√° con este art√≠culo. Por lo tanto, no profundizaremos en lo que est√° en el manual: replicaciones, fragmentos y consultas a todos los datos en fragmentos.

Lógica de almacenamiento


El diagrama l√≥gico es el m√°s interesante. En una tuber√≠a procesamos eventos heterog√©neos. Esto significa que tenemos una secuencia de eventos heterog√©neos : registro, voz, carga de fotos, m√©tricas t√©cnicas, seguimiento del comportamiento del usuario: todos estos eventos tienen atributos completamente diferentes . Por ejemplo, mir√© la pantalla en un tel√©fono m√≥vil: necesito una identificaci√≥n de pantalla, vot√© por alguien, debes entender si el voto fue a favor o en contra. Todos estos eventos tienen diferentes atributos, se dibujan diferentes gr√°ficos en ellos, pero todo esto debe procesarse en una sola tuber√≠a. ¬ŅC√≥mo ponerlo en el modelo ClickHouse?

Enfoque n. ¬į 1: por tabla de eventos. Este primer enfoque, extrapolamos de la experiencia adquirida con MySQL: creamos una tableta para cada evento en ClickHouse. Suena bastante l√≥gico, pero nos encontramos con una serie de dificultades.

No tenemos restricciones de que el evento cambie su estructura cuando se publique la compilaci√≥n de hoy. Este parche puede ser realizado por cualquier desarrollador. El esquema generalmente es mutable en todas las direcciones. El √ļnico campo requerido es el evento de marca de tiempo y cu√°l fue el evento. Todo lo dem√°s cambia sobre la marcha y, en consecuencia, estas placas deben modificarse. ClickHouse tiene la capacidad de realizar ALTER en un cl√ļster , pero este es un procedimiento delicado y delicado que es dif√≠cil de automatizar para que funcione sin problemas. Por lo tanto, esto es un menos.

Tenemos más de mil eventos diferentes, lo que nos da una alta tasa de INSERTAR por máquina : registramos constantemente todos los datos en mil tablas. Para ClickHouse, este es un antipatrón. Si Pepsi tiene el eslogan: "Vive en grandes sorbos", entonces ClickHouse: "Vive en grandes lotes" . Si esto no se hace, entonces la replicación se ahoga, ClickHouse se niega a aceptar nuevas inserciones, un esquema desagradable.

Enfoque n. ¬į 2: una mesa amplia . Los hombres siberianos intentaron deslizar la motosierra en el riel y aplicar un modelo de datos diferente. Hacemos una tabla con mil columnas , donde cada evento tiene columnas reservadas para sus datos. Obtenemos una gran tabla dispersa ; afortunadamente, esto no fue m√°s all√° del entorno de desarrollo, porque desde los primeros insertos qued√≥ claro que el esquema es absolutamente malo, y no lo haremos.

Pero a√ļn as√≠ quiero usar un producto de software tan genial, un poco m√°s para terminar, y ser√° lo que necesita.

Enfoque n. ¬į 3: tabla gen√©rica. Tenemos una gran tabla en la que almacenamos datos en matrices, porque ClickHouse admite tipos de datos no escalares . Es decir, comenzamos una columna en la que se almacenan los nombres de los atributos, y una columna separada con una matriz en la que se almacenan los valores de los atributos.



ClickHouse aquí realiza su tarea muy bien. Si solo tuviéramos que insertar datos, probablemente exprimiríamos 10 veces más en la instalación actual.

Sin embargo, la mosca en la pomada es que también es un antipatrón para ClickHouse, para almacenar matrices de cadenas . Esto es malo porque las matrices de filas ocupan más espacio en disco : se reducen peor que las columnas simples y son más difíciles de procesar . Pero para nuestra tarea, cerramos los ojos a esto, ya que las ventajas son mayores.

¬ŅC√≥mo hacer SELECCIONAR de tal tabla? Nuestra tarea es contar los registros agrupados por g√©nero. Primero necesita encontrar en una matriz qu√© posici√≥n corresponde a la columna de g√©nero, luego subir a otra columna con este √≠ndice y obtener los datos.



Cómo dibujar gráficos en estos datos


Como se describen todos los eventos, tienen una estructura estricta, formamos una consulta SQL de cuatro pisos para cada tipo de evento, la ejecutamos y guardamos los resultados en otra tabla.

El problema es que para dibujar dos puntos adyacentes en el gr√°fico, debe escanear toda la tabla . Ejemplo: nos fijamos en el registro por d√≠a. Este evento es desde la l√≠nea superior hasta la pen√ļltima. Escaneado una vez, excelente. Despu√©s de 5 minutos, queremos dibujar un nuevo punto en el gr√°fico; nuevamente, escaneamos el rango de datos que se cruza con el escaneo anterior, y as√≠ sucesivamente para cada evento. Suena l√≥gico, pero no se ve muy bien.

Además, cuando tomamos algunas líneas, también necesitamos leer los resultados bajo agregación . Por ejemplo, hay un hecho de que el siervo de Dios estaba registrado en Escandinavia y era un hombre, y necesitamos calcular las estadísticas resumidas: cuántos registros, cuántos hombres, cuántos de ellos son personas y cuántos son de Noruega. Esto se llama en términos de las bases de datos analíticas ROLLUP, CUBE y GROUPING SETS : convierte una línea en varias.

Como tratar


Afortunadamente, ClickHouse tiene una herramienta para resolver este problema, a saber, el estado serializado de las funciones agregadas . Esto significa que puede escanear un dato una vez y guardar estos resultados. Esta es una caracter√≠stica asesina . Hace 3 a√Īos hicimos exactamente esto en Spark y Hadoop, y es genial que en paralelo con nosotros, las mejores mentes de Yandex implementaron un an√°logo en ClickHouse.

Solicitud lenta


Tenemos una solicitud lenta: contar usuarios √ļnicos para hoy y ayer.

 SELECT uniq(user_id) FROM table WHERE dt IN (today(), yesterday()) 

En el plano f√≠sico, podemos hacer SELECCIONAR para el estado de ayer, obtener su representaci√≥n binaria, guardarla en alg√ļn lugar.

 SELECT uniq(user_id), 'xxx' AS ts, uniqState(user id) AS state FROM table WHERE dt IN (today(), yesterday()) 

Por hoy, solo cambiamos la condici√≥n de que ser√° hoy: 'yyy' AS ts y WHERE dt = today() y marca de tiempo llamaremos ‚Äúxxx‚ÄĚ y ‚Äúaaa‚ÄĚ. , , 2 .

 SELECT uniqMerge(state) FROM ageagate_table WHERE ts IN ('xxx', 'yyy') 


:

  • , ;
  • ;
  • .

, - . . , , , , ClickHouse, : ¬ę, ! , !¬Ľ


, , . , . . ‚ÄĒ SQL-, . , , .



, - time series. : , , , time series.

time series : , , timestamp . , , . . , , , ‚ÄĒ , . , , ClickHouse -, , .

, , ClickHouse:

‚ÄĒ ¬ę ¬Ľ, ‚ÄĒ .

time series 2 , 20 20-80 . . ClickHouse GraphiteMergeTree , time series, .


8 ClickHouse , 6 - , 2 : 2 ‚ÄĒ , . 1.8 . , 500 . , 1,8 , 500 ! .

Hadoop


2 . . 3 , CPU ‚ÄĒ 4 . , .

Process


, , , . , , ClickHouse 3 000 . , , , overkill.

, , . ClickHouse, . , , , . , 8 3‚Äď4 . ‚ÄĒ .

Present ‚ÄĒ


, ? time series, time series , , , .



Drop Detect ‚ÄĒ SQL : SQL- , , .



Anomaly Detection ‚ÄĒ . , , 2% , ‚ÄĒ 40, , , , .

‚ÄĒ , , - , Anomaly Detection.

Anomaly Detection


, time series . : , , . time series . , , . , drop detection ‚ÄĒ , .

UI.



. - , ‚ÄĒ . -, .

Present


, , . , : 1000 ‚ÄĒ alarm, 0 ‚ÄĒ alarm. .

Anomaly Detection , . Anomaly Detection Exasol , ClickHouse. Anomaly Detection 2 , .


, , 4 .

, , , . , , . , .

HighLoad++ , HighLoad++ - . , , :)

, PHP Russia , , . , , , 1,8 /, , 1 .

Source: https://habr.com/ru/post/442616/


All Articles