[Big Data] La arquitectura y la práctica de sincronizar los datos de Meituan DB con el almacén de datos

1. Antecedentes

En el modelado de almacenes de datos, los datos originales de la capa empresarial sin ningún procesamiento se denominan datos ODS( ). Operational Data StoreEn las empresas de Internet, los datos ODS comunes incluyen datos de registros comerciales ( Log) y datos de bases de datos comerciales ( DB). Para los datos de bases de datos comerciales, recopilar datos comerciales de bases de datos relacionales como MySQL y luego importarlos a Hive es un paso importante en la producción del almacén de datos.

¿Cómo sincronizar datos de MySQL con Hive de forma precisa y eficiente? Una solución comúnmente utilizada es recuperar datos en lotes y Load: conectarse directamente a MySQL para Selectrecuperar los datos en la tabla, luego almacenarlos en un archivo local como almacenamiento intermedio y finalmente almacenar el archivo Loaden la tabla de Hive. La ventaja de esta solución es que es sencilla de implementar, pero a medida que el negocio se desarrolla, sus deficiencias van quedando al descubierto:

• Cuello de botella en el rendimiento: a medida que crece la escala empresarial, Select From MySQL→→ Save to Localfileeste Load to Hiveflujo de datos lleva cada vez más tiempo y no puede cumplir con los requisitos de tiempo de la producción del almacén de datos posterior.
• SelectRecuperar una gran cantidad de datos directamente de MySQL tiene un gran impacto en MySQL, provocando fácilmente consultas lentas y afectando los servicios normales en la línea comercial.
• Dado que la propia sintaxis de Hive no admite primitivas SQL como actualizar y eliminar, no puede admitir bien los datos generados Update/ generados en MySQL.Delete

Para resolver completamente estos problemas, gradualmente recurrimos a la solución técnica CDC( Change Data Capture) + Merge, es decir, una solución de recopilación de Binlog en tiempo real + procesamiento fuera de línea de Binlog para restaurar datos comerciales. Binlog es el registro binario de MySQL, que registra todos los cambios de datos que ocurren en MySQL.La sincronización maestro-esclavo del clúster MySQL se basa en Binlog .

Este artículo presenta principalmente cómo lograr una entrada precisa y eficiente de datos de base de datos en el almacén de datos desde dos aspectos: recopilación de Binlog en tiempo real y procesamiento fuera de línea de Binlog para restaurar datos comerciales .

2. Arquitectura general

La arquitectura general se muestra en la figura anterior. En términos de recopilación de Binlog en tiempo real, adoptamos el proyecto de código abierto de Alibaba Canal, que es responsable de extraer Binlog de MySQL en tiempo real y completar el análisis apropiado. Después de la recopilación de Binlog, se almacenará temporalmente en Kafka para su consumo posterior. La parte general de recopilación en tiempo real se muestra con la flecha roja en la figura.

Para el procesamiento fuera de línea de Binlog, como lo muestra la flecha negra en la figura, restaure una tabla MySQL en Hive mediante los siguientes pasos:

• Un proyecto de código abierto que utiliza Linkedin Camus, responsable de extraer los datos de Binlog en Kafka a Hive cada hora.
• Para cada tabla ODS, primero debe tomar una instantánea ( Snapshot) a la vez y leer los datos existentes en MySQL en Hive. La capa inferior de este proceso utiliza una conexión directa a MySQL para seleccionar datos.
• Para cada tabla ODS, la combinación se realiza todos los días en función de los datos existentes y el Binlog se genera incrementalmente ese día para restaurar los datos comerciales.

Echemos un vistazo a los diversos problemas encontrados por la solución de carga y recuperación por lotes introducida en segundo plano ¿Por qué esta solución puede resolver los problemas anteriores?

• En primer lugar, Binlog se genera en forma de transmisión. A través de la recopilación de Binlog en tiempo real, parte de los requisitos de procesamiento de datos se asignan desde el procesamiento por lotes una vez al día hasta la transmisión en tiempo real. Tanto en términos de rendimiento como de presión de acceso a MySQL, habrá mejoras significativas.
• En segundo lugar, el propio Binlog registra el tipo de cambio de datos ( Insert/ Update/ Delete) y, mediante algún procesamiento semántico, puede lograr una restauración precisa de los datos.

3.Recolección de Binlog en tiempo real

La recopilación en tiempo real de Binlog incluye dos módulos principales:

• Primero CanalManager, es el principal responsable de la asignación de tareas de recopilación, monitoreo y alarmas, gestión de metadatos y acoplamiento con sistemas dependientes externos;
• El segundo es realizar realmente la Canaltarea de recolección CanalClient.

Cuando un usuario envía una solicitud de recopilación de Binlog para una determinada base de datos, CanalManager primero llamará a la interfaz relevante de la plataforma DBA para obtener información relevante sobre la instancia de MySQL donde se encuentra la base de datos, con el fin de seleccionar la máquina más adecuada para la recopilación de Binlog. Luego distribuya la instancia de colección ( Canal Instance) al servidor de Canal apropiado , es decir, CanalServeren. Al seleccionar un CanalServer específico, CanalManager considerará factores como el equilibrio de carga y la transmisión entre salas de máquinas, y dará prioridad a las máquinas con menores cargas y transmisión en la misma región.

Después de que CanalServer reciba la solicitud de recopilación, registrará la información de recopilación en ZooKeeper. El contenido del registro incluye:

• Un nodo permanente nombrado con el nombre de Instancia.
• ip:portRegistre un nodo temporal con su nombre en el nodo permanente .

Esto tiene dos propósitos:

• Alta disponibilidad : cuando CanalManager distribuye instancias, seleccionará dos CanalServers, uno como nodo en ejecución y el otro como nodo en espera. El nodo en espera monitoreará la instancia. Cuando el nodo en ejecución falla, el nodo temporal desaparece y luego el nodo en espera se adelanta. De esta forma se logra el propósito de la recuperación ante desastres.
• Interactuar con CanalClient : después de que CanalClient detecte el CanalServer en ejecución donde se encuentra la instancia de la que es responsable, se conectará para recibir los datos de Binlog enviados por CanalServer.

La suscripción a Binlog se basa en la base de datos de MySQL como granularidad, y un Binlog de base de datos corresponde a un tema de Kafka. En la implementación subyacente, todas las bases de datos suscritas en una instancia de MySQL son procesadas por la misma instancia de Canal. Esto se debe a que Binlog se genera en la granularidad de la instancia de MySQL. CanalServer descartará los datos de Binlog cancelados y luego CanalClient distribuirá el Binlog recibido a Kafka de acuerdo con la granularidad de la base de datos.

4. Restaurar datos de MySQL sin conexión

Después de completar la recopilación de Binlog, el siguiente paso es utilizar Binlog para restaurar los datos comerciales. El primer problema a resolver es sincronizar Binlog de Kafka a Hive.

5. Kafka2Hive

La gestión de toda la tarea de Kafka2Hive se lleva a cabo bajo el marco ETL de Meituan Data Platform, incluida la expresión de primitivas de tarea y el mecanismo de programación, que son similares a otros ETL. La capa inferior utiliza el proyecto de código abierto Camus de LinkedIn y lleva a cabo un desarrollo secundario específico para completar el trabajo real de transmisión de datos de Kafka2Hive.

6. Desarrollo secundario de Camus

El Binlog almacenado en Kafka no tiene un esquema, pero la tabla Hive debe tener un esquema, y ​​sus particiones, campos, etc. deben diseñarse para facilitar un consumo posterior eficiente. La primera modificación de Camus es analizar Binlog en Kafka en un formato que se ajuste al esquema de destino.

La segunda transformación de Camus estuvo determinada por el marco ETL de Meituan. En nuestro sistema de programación de tareas, actualmente solo se analizan las dependencias ascendentes y descendentes para las tareas en la misma cola de programación. No se pueden establecer dependencias entre colas de programación. En todo el proceso de MySQL2Hive, las tareas de Kafka2Hive deben ejecutarse una vez cada hora (cola por hora) y las tareas de fusión deben ejecutarse una vez al día (cola de día). El inicio de la tarea Merge debe depender estrictamente de la finalización de la tarea Kafka2Hive por horas.

Para resolver este problema, introdujimos Checkdonetareas. La tarea Checkdone es una tarea diaria, principalmente responsable de detectar si el Kafka2Hive del día anterior se completó con éxito. Si se completa con éxito, la tarea Checkdone se ejecuta con éxito, de modo que la tarea Merge posterior se puede iniciar correctamente.

7.Lógica de detección de verificación realizada

¿Cómo lo detecta Checkdone? Después de que cada tarea de Kafka2Hive completa con éxito la transmisión de datos, Camus es responsable de registrar el tiempo de inicio de la tarea en el directorio HDFS correspondiente. Checkdone escaneará todas las marcas de tiempo del día anterior. Si la marca de tiempo máxima excedió las 0 en punto, significa que las tareas de Kafka2Hive del día anterior se completaron con éxito y Checkdone completó la detección.

Además, dado que Camus solo completa el proceso de leer Kafka y luego escribir archivos HDFS, también debe completar la carga de la partición de Hive para permitir consultas posteriores. Por lo tanto, el último paso de toda la tarea de Kafka2Hive es cargar la partición de Hive. De esta forma, toda la tarea se ejecuta con éxito.

Cada tarea de Kafka2Hive se encarga de leer un Tema específico y escribir los datos de Binlog en original_binloguna tabla debajo de la base de datos, que es la de la figura anterior original_binlog.db, que almacena todos los Binlogs correspondientes a una BD MySQL.

La figura anterior ilustra la estructura de directorios de los archivos en HDFS después de que se completa Kafka2Hive. Si se llama a una base de datos MySQL user, el Binlog correspondiente se almacena en original_binlog.userla tabla. readyEn el directorio, las horas de inicio de todas las tareas de Kafka2Hive ejecutadas con éxito se almacenan por día para que Checkdone las utilice. El Binlog de cada tabla está organizado en una partición, por ejemplo, userinfoel Binlog de la tabla se almacena en table_name=userinfoesta partición. Debajo de cada table_namepartición primaria, dtlas particiones secundarias están organizadas por. xxx.lzoLos archivos y en la figura xxx.lzo.indexalmacenan lzodatos Binlog comprimidos.

8.Fusionar

Después de que Binlog se coloque exitosamente en el almacén, el siguiente paso es restaurar los datos de MySQL basados ​​en Binlog. El proceso de fusión hace dos cosas: primero, almacena los datos de Binlog generados ese día en la tabla Delta y luego realiza una fusión basada en clave primaria con los datos de stock existentes. Los datos de la tabla Delta son los últimos datos del día. Cuando un dato cambia varias veces en un día, solo los datos posteriores al último cambio se almacenan en la tabla Delta.

En el proceso de fusionar datos delta y datos de existencias, se requiere una clave única para determinar si son el mismo dato. Si el mismo dato aparece tanto en la tabla de inventario como en la tabla Delta, significa que este dato se ha actualizado y los datos de la tabla Delta se seleccionan como resultado final; de lo contrario, significa que no se han realizado cambios. ocurrió y los datos en la tabla de inventario original se conservan como Resultados finales. Los datos resultantes de Fusionar se insertarán y se sobrescribirán en la tabla original, que es la de la figura anterior origindb.table.

9.Ejemplo de proceso de fusión

A continuación se utiliza un ejemplo para ilustrar específicamente el proceso de fusión.

La tabla de datos tiene dos columnas en total, donde idestá la clave principal. Al extraer datos Delta, para múltiples actualizaciones del mismo dato, solo se selecciona la última actualización. Entonces, para los datos, el último valor actualizado se registra en la tabla Delta . Después de fusionar los datos delta y los datos existentes, en el resultado final, se inserta un nuevo dato ( ), se actualizan dos datos ( suma ) y un dato permanece sin cambios ( ).valueidid=1value=120id=4id=1id=2id=3

De forma predeterminada, utilizamos la clave principal de la tabla MySQL como clave única para este juicio. La empresa también puede configurar una clave única diferente de MySQL según la situación real.

Lo anterior presenta la arquitectura general de la recopilación de datos basada en Binlog y la restauración de datos ODS. A continuación se presentan principalmente los problemas comerciales reales que resolvemos desde dos aspectos.

10. Práctica 1: Soporte de subbase de datos y subtabla

Con la expansión de la escala empresarial, MySQL tiene cada vez más subbases de datos y tablas, y la cantidad de subtablas para muchas empresas es del orden de miles. Los estudiantes de desarrollo de datos generales deben agregar estos datos para su análisis. Si sincronizamos manualmente cada tabla y luego la agregamos en Hive, este costo nos resultará difícil de aceptar. Por lo tanto, necesitamos completar la agregación de subtablas en la capa ODS.

En primer lugar, durante la recopilación de Binlog en tiempo real, admitimos la escritura de Binlogs desde diferentes bases de datos en el mismo tema de Kafka. Los usuarios pueden verificar varias bases de datos físicas bajo la misma lógica de negocios al mismo tiempo cuando solicitan la recopilación de Binlog. Mediante la agregación en la capa de colección de Binlog, el Binlog de todas las subbases de datos se escribirá en la misma tabla de Hive, de modo que cuando se realice la fusión descendente, solo sea necesario leer una tabla de Hive.

En segundo lugar, la configuración de la tarea Fusionar admite coincidencias regulares. Al configurar expresiones regulares que cumplen con las reglas de nomenclatura de tablas de negocios, la tarea Merge puede comprender qué binlogs de tablas MySQL necesita agregar y luego seleccionar los datos de las particiones correspondientes para su ejecución.

De esta forma, a través de dos niveles de trabajo, se completa la fusión de subbases de datos y subtablas en la capa ODS.

Aquí hay una optimización técnica: al realizar Kafka2Hive, procesamos los nombres de las tablas de acuerdo con las reglas de partición de tablas comerciales y convertimos los nombres de las tablas físicas en nombres de tablas lógicas. Por ejemplo, userinfo123el nombre de esta tabla se convertirá en userinfodatos de Binlog almacenados en original_binlog.userla partición de la tabla table_name=userinfo. El propósito de esto es evitar la presión subyacente causada por demasiados archivos pequeños HDFS y particiones de Hive.

11. Práctica 2: Soporte para eliminar eventos

Las operaciones de eliminación son muy comunes en MySQL. Dado que Hive no admite Eliminar, si desea eliminar los datos eliminados en MySQL en Hive, debe utilizar un método "rotativo".

Para el proceso de fusión que necesita manejar el evento Eliminar, se utilizan los dos pasos siguientes:

• Primero, extraiga los datos donde ocurrió el evento Eliminar. Dado que el propio Binlog registra el tipo de evento, este paso es fácil de realizar. Haga una unión externa izquierda () en la clave principal entre los datos existentes (Tabla A) y los datos eliminados (Tabla B) Left outer join. Si puede obtener todos joinlos datos de ambos lados, significa que el dato se ha eliminado. Por lo tanto, los datos correspondientes a los registros NULL en la tabla B en el resultado de la selección son los datos que deben conservarse.
• Luego, realice una combinación regular de los datos retenidos obtenidos anteriormente de acuerdo con el proceso descrito anteriormente.

12. Resumen y perspectivas

Como base para la producción del almacén de datos, el servicio MySQL2Hive basado en Binlog proporcionado por Meituan Data Platform cubre básicamente todas las líneas de negocios dentro de Meituan. Actualmente, puede satisfacer las necesidades de sincronización de datos de la mayoría de las empresas y lograr una sincronización de datos de base de datos precisa y eficiente. depósito. En el desarrollo futuro, nos centraremos en resolver el problema de punto único de CanalManager y construiremos una arquitectura de recuperación ante desastres entre salas de máquinas para respaldar de manera más estable el desarrollo empresarial.

Este artículo presenta principalmente la arquitectura de este servicio desde dos aspectos: la recopilación de transmisión de Binlog y la restauración de datos ODS basada en Binlog, y presenta algunos problemas y soluciones típicos que encontramos en la práctica. Espero que pueda proporcionar algún valor de referencia a otros desarrolladores y todos pueden comunicarse con nosotros.

---

Este artículo se reproduce en:

• Autor: equipo técnico de Meituan
• Título: Arquitectura y práctica de sincronización de datos de Meituan DB con el almacén de datos
• Enlace: https://tech.meituan.com/2018/12/06/binlog-dw.html