Autor | Wang Zhanxiong
Fuente | Tencent Kandian Technology (ID: TKD-Tech)
Introducción: cuando el negocio se desarrolla a cierta escala, el almacenamiento de datos en tiempo real es un servicio básico necesario. Desde una perspectiva basada en datos, la importancia de un sistema de análisis de datos multidimensional en tiempo real es evidente. Pero cuando la cantidad de datos es enorme, tomando el punto de vista de Tencent, por ejemplo, la cantidad de datos reportados en un día alcanza una escala de un billón, y es técnicamente desafiante lograr cálculos en tiempo real de latencia extremadamente baja y consultas en tiempo real multidimensionales inferiores a un segundo. Este artículo presentará la arquitectura técnica del almacén de datos en tiempo real de Tencent y el sistema de análisis de datos multidimensional en tiempo real bajo el escenario de flujo de información.
Puntos de dolor resueltos
Primero, echemos un vistazo a los puntos débiles que puede resolver el sistema de análisis de datos multidimensional en tiempo real. como:
Los estudiantes que recomendaron usaron una estrategia de recomendación hace 10 minutos y quieren saber qué tan efectiva es la recomendación en diferentes grupos de personas.
Los estudiantes de operación quieren saber cuáles son los contenidos regionales de Guangdong más populares entre los usuarios de la provincia de Guangdong, por lo que es conveniente hacer Push regional.
Los estudiantes de revisión quieren saber, en los últimos 5 minutos, ¿qué contenido y cuentas se han reportado más en los juegos?
El jefe puede querer saber cuántos usuarios han consumido el contenido en los últimos 10 minutos y tener una comprensión macro del grupo de consumidores.
Investigación
Hicimos estas investigaciones antes de continuar con el desarrollo.
1. Si la plataforma de análisis de datos fuera de línea puede satisfacer estas necesidades, la conclusión es que no se pueden satisfacer. Las razones del fracaso de la plataforma de análisis de datos fuera de línea son las siguientes.
Los datos en el lado C se informan a través del cálculo fuera de línea de múltiples capas de Spark, y el resultado final se exporta a Mysql o ES para la consulta de la plataforma de análisis fuera de línea. La demora de este proceso es de al menos 3-6 horas. En la actualidad, es más común proporcionar consultas al día siguiente, por lo que muchos escenarios comerciales con altos requisitos de tiempo real no se pueden satisfacer.
Otro problema es que el volumen de datos de Tencent es demasiado grande y la inestabilidad que genera es relativamente grande y, a menudo, se producen retrasos inesperados. Por lo tanto, las plataformas de análisis fuera de línea no pueden satisfacer muchas necesidades.
2. Para la plataforma de análisis de datos en tiempo real, el grupo empresarial ofrece la función de consulta de datos cuasi en tiempo real. La tecnología subyacente utiliza Kudu + Impala. Aunque Impala es un motor de computación de macrodatos con arquitectura MPP, también accede a Kudu, que almacena datos en columnas. Sin embargo, para escenarios de análisis de datos en tiempo real, la velocidad de respuesta de la consulta y la latencia de los datos siguen siendo relativamente altas. Una consulta de DAU en tiempo real tarda al menos unos minutos en devolver los resultados, lo que no puede proporcionar una buena experiencia interactiva para el usuario. Por lo tanto, la ventaja de velocidad de (Kudu + Impala) este marco general de procesamiento de big data es mayor que la de (Spark + Hdfs) este marco de análisis fuera de línea. Para nuestro escenario con mayores requisitos de tiempo real, no se puede satisfacer. de.
antecedentes del proyecto
Después de la introducción de hace un momento, veamos los antecedentes de nuestro proyecto.
El contenido de la publicación del autor lo introduce el centro de contenido y se activa o elimina después del enlace de revisión de contenido. El contenido activado se entrega al sistema de recomendación y al sistema operativo, y luego el sistema de recomendación y el sistema operativo distribuyen el contenido en el lado C. Una vez que el contenido se distribuye a los usuarios del lado C, los usuarios tendrán varios comportamientos, como exposición, clics, informes, etc., y acceso a la cola de mensajes en tiempo real a través del informe de puntos enterrados.
Luego hicimos dos partes del trabajo, las dos partes con colores en la imagen.
La primera parte construye un almacén de datos en tiempo real de Tencent Kandian.
La segunda parte consiste en desarrollar un sistema de análisis de datos multidimensional en tiempo real basado en el motor de almacenamiento OLAP.
¿Por qué necesitamos construir un almacén de datos en tiempo real? Debido a que el volumen de datos reportados originalmente es muy grande, hay billones de datos reportados en un día. Y el formato de los informes es confuso. Falta de información sobre la dimensión del contenido, información del perfil del usuario y ningún uso directo posterior. El almacén de datos en tiempo real que proporcionamos se basa en los escenarios comerciales del flujo de información de Tencent y lleva a cabo la correlación de las dimensiones del contenido, la correlación de los retratos de los usuarios y la agregación de varias granularidades. El downstream puede usar datos en tiempo real de manera muy conveniente.
Selección de esquema
Luego, eche un vistazo a la selección de nuestro sistema de análisis de datos en tiempo real multidimensional. Para la selección, comparamos las soluciones líderes en la industria y elegimos la solución más adecuada para nuestros escenarios comerciales.
La primera pieza es la selección del almacén de datos en tiempo real. Elegimos la arquitectura Lambda relativamente madura en la industria. Sus ventajas son alta flexibilidad, alta tolerancia a fallas, alta madurez y bajo costo de migración; la desventaja es que utiliza datos tanto en tiempo real como fuera de línea. El conjunto de códigos puede tener un problema de que se ha modificado un calibre y no se ha modificado el otro. Hacemos conciliación de datos todos los días, y si hay alguna anomalía, daremos una alerta.
La segunda parte es la selección de motores de cómputo en tiempo real, porque Flink fue diseñado originalmente para procesamiento de flujo, SparkStreaming es estrictamente un procesamiento de micro lotes y Strom no se usa mucho. En cuanto a la precisión Exactamente una vez de Flink, el mecanismo ligero de tolerancia a fallas de Checkpoint, la baja latencia, el alto rendimiento y la gran facilidad de uso, elegimos Flink como el motor informático en tiempo real.
El tercer bloque es un motor de almacenamiento en tiempo real. Nuestros requisitos son tener índices dimensionales, admitir consultas OLAP multidimensionales de alta concurrencia, pre-agregación y alto rendimiento en tiempo real. Se puede ver que Hbase, Tdsql y ES no pueden cumplir con los requisitos. Druid tiene un defecto. Divide los segmentos según la secuencia de tiempo. El mismo contenido no se puede almacenar en el mismo segmento. El cálculo del TopN global solo puede ser un valor aproximado, por lo que elegimos El motor de base de datos MPP ClickHouse, que ha sido popular en los últimos dos años.
Objetivos de diseño y dificultades de diseño
Nuestro sistema de análisis de datos multidimensional en tiempo real se divide en tres módulos
Motor de cálculo en tiempo real
Motor de almacenamiento en tiempo real
Capa de aplicación
La dificultad radica principalmente en los dos primeros módulos: motor de cálculo en tiempo real y motor de almacenamiento en tiempo real.
Cómo acceder a datos masivos de decenas de millones / s en tiempo real y realizar una asociación de tablas de dimensiones de muy baja latencia.
Es más difícil cómo el motor de almacenamiento en tiempo real admite escrituras simultáneas elevadas, consultas de índice distribuidas de alta disponibilidad y de alto rendimiento.
Para la implementación específica de estos módulos, observe el diseño de la arquitectura de nuestro sistema.
Diseño arquitectónico
El front-end usa el componente de código abierto Ant Design, usa el servidor Nginx para implementar páginas estáticas y las solicitudes del navegador proxy inverso al servidor back-end.
El servicio de back-end está escrito en base al marco de servicio de back-end RPC de desarrollo propio de Tencent, y se realizarán algunas cachés secundarias.
La parte del almacén de datos en tiempo real se divide en la capa de acceso, la capa de computación en tiempo real y la capa de almacenamiento del almacén de datos en tiempo real.
La capa de acceso es principalmente para dividir microcolas de diferentes datos de comportamiento de la cola de mensajes original de decenas de millones / s. Tome el video del punto de observación, después de la división, los datos son solo un millón / s;
La capa de computación en tiempo real es principalmente responsable de la conversión de fila a columna de múltiples filas de datos de comportamiento y de la correlación en tiempo real de los datos del retrato del usuario y los datos de la dimensión del contenido;
La capa de almacenamiento del almacén de datos en tiempo real es principalmente para diseñar una cola de mensajes en tiempo real adecuada para el negocio de interés y fácil de usar en sentido descendente. Proporcionamos temporalmente dos colas de mensajes como las dos capas del almacén de datos en tiempo real. Una capa de la capa DWM es la agregación de la granularidad de ID de contenido-ID de usuario, es decir, un fragmento de datos contiene ID de contenido-ID de usuario, datos de contenido en el lado B, datos de usuario en el lado C y datos de retrato de usuario; la otra capa es la capa DWS, que es la granularidad de ID de contenido En conjunto, un dato contiene ID de contenido, datos del lado B y datos del lado C. Puede verse que el tráfico de la cola de mensajes de la granularidad de ID de contenido-ID de usuario se reduce aún más a cien mil niveles, y la granularidad de ID de contenido es incluso de diez mil niveles, y el formato es más claro y la información dimensional es más rica.
La parte de almacenamiento en tiempo real se divide en capa de escritura en tiempo real, capa de almacenamiento OLAP y capa de interfaz de fondo.
La capa de escritura en tiempo real es principalmente responsable de escribir datos en el enrutamiento Hash;
La capa de almacenamiento OLAP utiliza el motor de almacenamiento MPP para diseñar índices y vistas materializadas que satisfacen el negocio y almacenan de manera eficiente cantidades masivas de datos;
La capa de interfaz de fondo proporciona una interfaz de consulta en tiempo real multidimensional eficiente.
Cálculo en tiempo real
Las dos partes más complicadas de este sistema son la computación en tiempo real y el almacenamiento en tiempo real.
Primero introduzca la parte de cálculo en tiempo real: dividida en asociación en tiempo real y almacén de datos en tiempo real.
7.1 Asociación de tablas de dimensiones de alto rendimiento en tiempo real
La dificultad de la asociación de tablas de dimensiones en tiempo real radica en. Para un flujo de datos en tiempo real de millones / s, si asocia directamente HBase con 1 minuto de datos, se necesitan horas para asociar HBase, lo que provocará un retraso importante en los datos.
Hemos propuesto varias soluciones:
La primera es que en el cálculo en tiempo real de Flink, la agregación de la ventana se realiza en 1 minuto y los datos de comportamiento de varias filas en la ventana se convierten en un formato de datos de filas y columnas. Después de este paso, el tiempo de asociación de nivel de hora original se redujo a diez. Unos minutos, pero aún no lo suficiente.
El segundo es configurar una capa de caché de Redis antes de acceder al contenido de HBase. Debido a que 1000 piezas de datos acceden a HBase en segundos y acceden a Redis en milisegundos, la velocidad de acceso a Redis es básicamente 1000 veces mayor que la de HBase. Para evitar que los datos caducados desperdicien la caché, el tiempo de caducidad de la caché se establece en 24 horas y, al mismo tiempo, la coherencia de la caché se garantiza mediante la supervisión y la escritura de HBase Proxy. Esto cambió el tiempo de acceso de diez minutos a segundos.
La tercera es que durante el proceso de generación de informes se informarán muchos ID de contenido no convencionales, que no se almacenan en el contenido HBase, lo que provocará el problema de penetración de la caché. Por lo tanto, en el cálculo en tiempo real, filtramos directamente estos ID de contenido para evitar la penetración de la caché y reducir el tiempo.
El cuarto es que debido a que la caché de tiempo está configurada, se presentará un problema de avalancha de caché. Para evitar avalanchas, hemos realizado operaciones de reducción de picos y llenado de valles en cálculos en tiempo real, escalonando el tiempo de amortiguación de configuración.
Se puede ver que antes y después de la optimización, la cantidad de datos se ha reducido de decenas de miles de millones a miles de millones, y el consumo de tiempo se ha reducido de horas a decenas de segundos, una reducción del 99%.
7.2 Prestación de servicios en sentido descendente
La dificultad del almacén de datos en tiempo real es que se encuentra en un campo relativamente nuevo, y la brecha entre los negocios de cada empresa es relativamente grande, ¿cómo puede ser difícil diseñar un almacén de datos en tiempo real que sea conveniente, fácil de usar y que se ajuste al escenario comercial del destacado?
Echemos un vistazo a lo que hace el almacén de datos en tiempo real. El almacén de datos en tiempo real está conectado externamente a varias colas de mensajes. Las diferentes colas de mensajes almacenan datos en tiempo real con diferentes granularidades de agregación, incluido el ID de contenido, el ID de usuario, los datos de comportamiento del lado C y el contenido del lado B. Datos dimensionales y datos de perfil de usuario, etc.
¿Cómo construimos un almacén de datos en tiempo real? La salida del motor informático en tiempo real descrito anteriormente se almacena en la cola de mensajes y se puede proporcionar a varios usuarios posteriores para su reutilización.
Podemos ver la diferencia entre desarrollar una aplicación en tiempo real antes y después de construir un almacén de datos en tiempo real. Cuando no hay un almacén de datos, necesitamos consumir la cola original de decenas de millones / s, realizar una limpieza de datos compleja y luego realizar una correlación de retrato de usuario y una correlación de dimensión de contenido para obtener datos en tiempo real que cumplan con los costos de formato, desarrollo y expansión requeridos. Será relativamente alto, si desea desarrollar una nueva aplicación, debe pasar por este proceso nuevamente. Después de tener el almacén de datos, si desea desarrollar aplicaciones en tiempo real con granularidad de ID de contenido, puede solicitar directamente la cola de mensajes de la capa DWS de TPS 10,000 / s. El costo de desarrollo es mucho menor, el consumo de recursos es mucho menor y la escalabilidad es mucho mayor.
Mirando un ejemplo práctico, el desarrollo de la pantalla grande de datos en tiempo real de nuestro sistema originalmente requirió todas las operaciones anteriores para obtener los datos. Ahora solo necesita consumir la cola de mensajes de la capa DWS y escribir un Flink SQL, que solo consume 2 núcleos de CPU y 1G de memoria.
Se puede ver que tomando como ejemplo a 50 consumidores, antes y después del establecimiento de un almacén de datos en tiempo real, el desarrollo posterior de una aplicación en tiempo real puede reducir el consumo de recursos en un 98%. Incluidos los recursos informáticos, los recursos de almacenamiento, los costes laborales y los costes de acceso al aprendizaje del desarrollador, etc. Y cuantos más consumidores, más ahorros. Tomemos el almacenamiento de Redis como ejemplo, puede ahorrar millones de RMB al mes.
Almacenamiento en tiempo real
Después de presentar la informática en tiempo real, introduzcamos el almacenamiento en tiempo real.
Esta sección se divide en tres partes para presentar:
El primero es la alta disponibilidad distribuida
El segundo es la escritura masiva de datos
El tercero es la consulta de alto rendimiento
8.1 Distribuida de alta disponibilidad
Lo que escuchamos aquí es la sugerencia oficial de Clickhouse, con la ayuda de ZK para lograr una solución de alta disponibilidad. Los datos se escriben en un fragmento, solo se escribe una copia y luego se escribe ZK. ZK le dice a otras copias del mismo fragmento, y otras copias vienen a extraer datos para garantizar la coherencia de los datos.
La cola de mensajes no se utiliza aquí para la sincronización de datos porque ZK es más ligero. Y al escribir, se escribe cualquier copia y las otras copias pueden obtener datos consistentes a través de ZK. E incluso si otros nodos no logran obtener datos por primera vez, siempre que encuentren que no son coherentes con los datos registrados en ZK, intentarán obtener los datos nuevamente para garantizar la coherencia.
8.2 Escritura masiva de datos
El primer problema que se encuentra en la escritura de datos es que si se escriben datos masivos directamente en Clickhouse, el QPS de ZK será demasiado alto. La solución es utilizar la escritura por lotes en su lugar. ¿Qué tan grande es la configuración del lote? Si el lote es demasiado pequeño, la presión de ZK no se aliviará y el lote no debería ser demasiado grande; de lo contrario, la presión de la memoria ascendente será demasiado grande. Mediante experimentos, finalmente elegimos un lote de cientos de miles de tamaños.
El segundo problema es que a medida que aumenta la cantidad de datos, el contenido de video de un solo reloj QQ puede escribir decenas de miles de millones de datos cada día. La solución predeterminada es escribir una tabla distribuida, lo que hará que aparezca una sola máquina en el disco. El cuello de botella, especialmente la capa inferior de Clickhouse utiliza Mergetree, el principio es similar a la capa inferior LSM-Tree de HBase y RocketsDb. En el proceso de fusión, habrá problemas de amplificación de escritura, lo que aumentará la presión del disco. El valor máximo es decenas de millones de datos por minuto y tarda decenas de segundos en terminar de escribir. Si está haciendo Fusionar, la solicitud de escritura se bloqueará y la consulta será muy lenta. Hicimos dos esquemas de optimización: uno es Raid en el disco para aumentar la IO del disco; el otro es dividir la tabla antes de escribir y escribir directamente en diferentes fragmentos, y la presión del disco se convierte directamente en 1 / N.
El tercer problema es que aunque nuestra escritura está dividida en fragmentos, aquí se introduce un problema común en los sistemas distribuidos, es decir, el problema de que el Top local no es el Top global. Por ejemplo, si los datos del mismo ID de contenido se encuentran en diferentes fragmentos, se calcula el ID de contenido leído por el Top100 global. Hay un ID de contenido que es Top100 en el fragmento 1, pero no Top100 en otros fragmentos, que se perderá cuando se agregue Parte de los datos afecta el resultado final. La optimización que hicimos es agregar una capa de enrutamiento antes de escribir para enrutar todos los registros del mismo ID de contenido al mismo fragmento, lo que resuelve el problema.
Después de presentar la escritura, el siguiente paso es presentar el almacenamiento y la consulta de alto rendimiento de Clickhouse.
8.3 Consulta de almacenamiento de alto rendimiento
Un punto clave de la consulta de alto rendimiento de Clickhouse es el índice escaso. El diseño de índice disperso es muy particular: un buen diseño puede acelerar la consulta, pero un mal diseño afectará la eficiencia de la consulta. De acuerdo con nuestro escenario empresarial, la mayoría de nuestras consultas están relacionadas con el tiempo y la identificación de contenido. Por ejemplo, ¿cómo se comportó un determinado contenido en varios grupos en los últimos N minutos? Creé un índice escaso basado en la fecha, el tiempo de granularidad de los minutos y la identificación del contenido. Para una determinada consulta de contenido, después de establecer un índice escaso, el escaneo de archivos se puede reducir en un 99%.
Otro problema es que tenemos demasiados datos y demasiadas dimensiones. Tomemos el contenido de video de QQ Watch como ejemplo, hay decenas de miles de millones de videos al día y algunas dimensiones tienen cientos de categorías. Si todas las dimensiones se agregan previamente a la vez, la cantidad de datos se expandirá exponencialmente, la consulta se ralentizará y ocupará mucho espacio en la memoria. Nuestra optimización consiste en establecer vistas preagregadas correspondientes para diferentes dimensiones y utilizar espacio para el tiempo, lo que puede acortar el tiempo de consulta.
La consulta de la tabla distribuida también tiene un problema. Para consultar la información de un solo ID de contenido, la tabla distribuida emitirá la consulta a todos los fragmentos y luego devolverá los resultados de la consulta para un resumen. De hecho, debido al enrutamiento, un ID de contenido solo existe en un fragmento y los fragmentos restantes se ejecutan vacíos. Para este tipo de consulta, nuestra optimización es realizar el enrutamiento en segundo plano de acuerdo con las mismas reglas y consultar directamente los fragmentos de destino, lo que reduce la carga de N-1 / N y puede acortar en gran medida el tiempo de consulta. Y debido a que proporcionamos consultas OLAP, los datos pueden cumplir con la consistencia final y el rendimiento se puede mejorar aún más mediante la separación de lectura y escritura de las copias maestra y esclava.
También hicimos una caché de datos de 1 minuto en segundo plano, y la consulta para las mismas condiciones se devolvió directamente en segundo plano.
8.4 Expansión
Aquí presentaremos nuestro plan de expansión e investigaremos algunos planes comunes en la industria.
Por ejemplo, en HBase, los datos originales se almacenan en HDFS y la expansión es solo la expansión del servidor de región y no implica la migración de los datos originales. Sin embargo, cada fragmento de datos de Clickhouse es local, que es un motor de almacenamiento de nivel relativamente bajo y no se puede expandir fácilmente como HBase.
Redis es una ranura de hash similar al hash consistente y es una solución de caché distribuida más clásica. Aunque hay una breve indisponibilidad de lectura de solicitud en la ranura de Redis durante el proceso de Rehash, la migración es más conveniente en general, desde la h [0] original a la h [1], y finalmente se elimina h [0]. Pero la mayor parte de Clickhouse es una consulta por lotes OLAP, no una verificación de puntos, y debido al almacenamiento en columnas, no admite la función de eliminación, el esquema de hash consistente no es muy adecuado.
El plan de expansión actual es consumir otro dato y escribirlo en el nuevo clúster de Clickhouse. Los dos clústeres se ejecutarán juntos durante un período de tiempo, ya que los datos en tiempo real se guardan durante 3 días. Después de 3 días, el servicio en segundo plano accede directamente al nuevo clúster.
Resultados
Almacén de datos en tiempo real de Tencent Watch Point: capa DWM y capa DWS, retraso de datos de 1 minuto.
Sistema de análisis de datos en tiempo real multidimensional de prospectiva: respuesta en menos de un segundo a solicitudes de consultas condicionales multidimensionales, en el caso de fallas de caché, el 99% de las consultas en los últimos 30 minutos tomaron 1 segundo; consultas en las últimas 24 horas, 90% de las solicitudes Tardaron menos de 5 segundos y el 99% de las solicitudes tardaron menos de 10 segundos.
更多精彩推荐
☞谷歌软件工程师薪资百万，大厂薪资有多高？
☞这都是啥软件？你能猜到吗？| 每日趣闻
☞杜甫在线演唱《奇迹再现》、兵马俑真人还原……用AI技术打破次元壁的大谷来参加腾讯全球数字生态大会啦！
☞开放源码，华为鸿蒙HarmonyOS 2.0来了
☞20张图，带你搞懂高并发中的线程与线程池！
☞跨链，该怎么跨？
点分享点点赞点在看