0 Prefacio
DTS es Data Transfer Platform (abreviatura de Data Transfer Platform)
Con el aumento del tráfico de usuarios de la aplicación Dewu, las bases de datos seleccionadas para los negocios se vuelven cada vez más diversas, y la demanda de sincronización de datos entre fuentes de datos heterogéneas también aumenta gradualmente. Para controlar los costos y apoyar mejor el desarrollo comercial, decidimos construir nuestra propia plataforma DTS. Este artículo comparte principalmente la experiencia adquirida durante la actualización de la plataforma DTS desde las perspectivas de selección de tecnología, soporte de capacidades y evolución, y proporciona algunas referencias.
1 Selección de tecnología
El objetivo principal de DTS es admitir la interacción de datos entre diferentes tipos de fuentes de datos, incluidas bases de datos relacionales (RDBMS), bases de datos NoSQL, OLAP, etc., al tiempo que integra la gestión de configuración de bases de datos, suscripción de datos, sincronización de datos, migración de datos y DRC activo. -Active Múltiples módulos como soporte de sincronización de datos, inspección de datos, monitoreo y alarmas, y autoridad unificada se utilizan para construir una plataforma de arquitectura de datos segura, escalable y de alta disponibilidad.
1.1 Comparación de habilidades
1.2 DTS 1.0 - usando canal/otter/datax como motor de ejecución
1.3 ¿Por qué cambiar a Flink?
Para admitir múltiples fuentes de datos del lado de lectura y fuentes de datos del lado de escritura, se necesita un marco de procesamiento de datos unificado para reducir los componentes duplicados y mejorar la eficiencia del desarrollo. Al mismo tiempo, la dificultad de mantenimiento y la complejidad de los tipos y componentes de fuentes de datos aumentan linealmente, y los componentes existentes deben mantenerse en un proyecto.
Los componentes como Canal y Otter tienen poca actividad comunitaria y no se han mantenido ni actualizado durante mucho tiempo. Por lo tanto, se debe seleccionar un nuevo marco activo. Además, los componentes existentes no pueden admitir de manera efectiva operaciones integradas completas + incrementales.
Por lo tanto, es necesario utilizar un marco de procesamiento de datos unificado que pueda admitir simultáneamente múltiples fuentes de datos de lectura y escritura, así como funciones de integración completas e incrementales. Esto puede reducir la dificultad y la complejidad del mantenimiento de los componentes y mejorar la eficiencia del desarrollo.
A través de DTS 2.0, esperamos convertir canal/otter/datax en un marco de ejecución de tareas + plataforma de gestión, que puede acelerar las iteraciones posteriores de una gran cantidad de fuentes de datos.
1.4 DTS 2.0 utiliza Flink como motor de ejecución
Proceso de desarrollo existente:
- Marco de ejecución de tareas unificado, integrando flink e introduciendo conectores para ensamblar tareas DTS específicas según la configuración
- Mantener y desarrollar nuevos conectores.
Cuando necesitemos admitir una nueva fuente de datos, primero mantenga los complementos relacionados con la fuente de datos en el conector y luego introduzca los componentes necesarios en el marco de ejecución, que contiene una gran cantidad de funciones reutilizables, de modo que el conector y funcional los componentes se pueden reutilizar Efecto.
2 capacidades existentes de DTS
3 ¿Qué hicimos?
Marco de conectores DTS 3.1: aceleración de la compatibilidad con fuentes de datos
El marco de sincronización de tareas completo/incremental implementado sobre la base de Flink CDC, la arquitectura básica es la siguiente
Entre ellas, las funciones SourceFunction y SinkFunction proporcionadas por Flink se implementan respectivamente en el conector, que son respectivamente responsables de leer datos desde el extremo de lectura y escribir datos en el extremo de escritura. Por lo tanto, un conector puede existir aguas arriba o aguas abajo al mismo tiempo. .
El proceso de inicio de la tarea:
a. La función principal de la tarea es la siguiente, y el flujo de datos correspondiente se construye de acuerdo con SourceFactory o SinkFactory cargado en el conector correspondiente mediante el siguiente archivo Json.
DataStream es una clase de operación de flujo de datos proporcionada en Flink
public class Main { public static void main(String[] args) throws Exception {
// 解析参数 ParameterTool parametrTool = ParameterTool.fromArgs(args); String[] parsedArgs = parseArgs(parameterTool);
Opciones opciones = new OptionParser(parsedArgs).getOptions(); opciones.setJobName(opciones.getJobName());
// 执行任务 StreamExecutionEnvironment entorno = EnvFactory.createStreamExecutionEnvironment(opciones); exeJob(entorno, opciones); }
Configuración de la tarea Json:
{ "trabajo":{ "contenido":{ "lector":{ "nombre":"binlogreader", "parámetro":{ "accessKey":"", "binlogOssApiUrl":"", "delayBetweenRestartAttempts":2000, " fetchSize":1, "instanceId":"", "rdsPlatform":"", "restartAttempts":5, "secretKey":"", "serverTimezone":"", "splitSize":1024, "startupMode":" LATEST_OFFSET" } }, "escritor":{ "nombre":"jdbcwriter", "parámetro":{ "tamaño del lote":10000,"concurrentWrite":true, ], "dryRun":false, "dumpCommitData":false, "errorRecord":0, "flushIntervalMills":30000, "poolSize":10, "reintentos":3, "smallBatchSize":200 } } },
}}
b. Proporcionamos dos clases de fábrica abstractas, SourceFactory y SinkFactory, entre las cuales createSource y createSink son los métodos que las subfactorías necesitan implementar. Diferentes fuentes de datos tienen diferentes implementaciones.
public abstract class SourceFactory<T> { public abstract DataStream<T> createSource();}public abstract class SinkFactory<T> { public abstract void createSink(DataStream<T> rowData) throws Exception;}
c. A continuación, solo necesitamos implementar el método de sub-fábrica correspondiente
clase pública BinlogSourceFactory extiende AbstractJdbcSourceFactory { @Override public DataStream<TableRowData> createSource() {
List<String> tablas = this.binlogSourceConf.getConnection().getTable(); Set<String> databaseList = new HashSet<>(2);
// 使用对应的Connector构建DataStream }}
d. Funciones de capacidad general: RateLimitFunction, BinlogPositionFunction, que implementan las capacidades de tarea correspondientes, como limitación de corriente, almacenamiento de posición de tarea, etc.
clase pública RateLimiterMapFunction<T> extiende RichMapFunction<T, T> {
privado transitorio FlinkConnectorRateLimiter rateLimiter;
@Override public T map(T value) arroja una excepción { if (rateLimiterEnabled) { rateLimiter.acquire(1); } valor de retorno; }
Cuando se crean las funciones requeridas por la tarea, la tarea realmente comienza a ejecutarse.
ingreso:
3.2 Adquisición de registros RDS
DTS proporciona funciones de sincronización de datos para empresas al proporcionar capacidades de sincronización incremental y completa, pero se pueden encontrar algunas situaciones anormales durante la ejecución de tareas de sincronización/suscripción incremental. Entre ellos, las siguientes tres situaciones requieren un manejo especial:
- Disponibilidad de bitácora
El binlog local de la instancia de la base de datos del proveedor de la nube es válido durante 8 horas y OSS realiza una copia de seguridad de la parte caducada. Durante el período pico de los cambios comerciales o DDL de MySQL, se genera una gran cantidad de binlogs y la tarea DTS no puede obtener datos caducados, por lo que la tarea se interrumpe. Por lo tanto, DTS admite la adquisición y el cambio de binlog local + binlog de respaldo OSS para garantizar la disponibilidad del registro.
- Conmutador maestro-esclavo de instancia de base de datos
RDS a menudo cambia entre nodos activos y en espera, y los datos no deben perderse durante el proceso de cambio. Dado que los archivos Binlog de las dos instancias de la base de datos antes y después del cambio generalmente son inconsistentes, el método de registro de la posición de la tarea es el modo BinlogPosition en este momento, y la tarea debe realizar automáticamente la operación de alineación del Binlog después del cambio para garantizar la integridad de los datos. Simplemente avance la marca de tiempo de la consulta de ubicación en la nueva instancia de datos de 1 a 2 minutos.
- Soporte de suscripción de instancia de lectura
Demasiadas conexiones de volcado binlog en la tarea DTS ejercen presión sobre la biblioteca principal y afectan los cambios de DDL, por lo que es necesario admitir la lectura de suscripciones de biblioteca. La biblioteca de lectura del proveedor de la nube no proporciona respaldo y necesita cambiar a la biblioteca principal para leer cuando el registro de lectura caduca.
3.3 Función de integración incremental completa
La integración completa e incremental se refiere a sincronizar primero los datos de stock y luego comenzar a sincronizar los datos incrementales después de que se agote el stock. También incluye la adquisición de registros de respaldo de OSS en la fase incremental. Sin embargo, todavía hay algunos problemas en la etapa de stock, que necesitan una mayor mejora y optimización.
3.4 Acceso a la fuente de datos: starrocks, postgres, etc.
Admite la sincronización de mysql a starrocks y postgres.Sobre la base del marco de ejecución de tareas, solo es necesario desarrollar el conector starrocks, el conector postgres admite la fuente de datos correspondiente. Otras capacidades, como la sincronización de varias tablas, la subtabla de la subbase de datos y otros escenarios, pueden lograr el efecto de la multiplexación.
3.5 Transformación de escritura JBDC
Expansión de secuencias de comandos y enrutamiento dinámico de nombres de tablas:
Fusión de datos y escritura de subprocesos múltiples:
3.6 Monitoreo y alarma
Las tareas de DTS deben recopilar indicadores de tareas de Flink, que incluyen principalmente el retraso de la tarea, la tasa de escritura de cada etapa del operador, la presión del operador y la tasa de uso, etc. Entre ellos, el retraso de la tarea requiere acceso al servicio de alarma, por lo que decidimos introducir redis para almacenar en caché el tiempo de retraso de la tarea y luego informarlo al servicio de alarma para completar el mensaje de Feishu y la alarma del teléfono.
4 mejores prácticas
4.1 Problema con la marca de tiempo 0000-00-00 00:00:00
Se permite que la marca de tiempo de MySQL sea 0000-00-00 00:00:00, que generalmente se convierte en nulo en las tareas de Flink, lo que resulta en una falla al escribir en las fuentes de datos posteriores, por lo que se requiere una marca especial para diferentes conversiones para diferentes fuentes de datos Garantizado filas tangentes escritas.
4.2 Unicidad de la tarea serverId de Flink CDC
La fuente Flink CDC pretenderá ser un nodo esclavo de MySQL Para garantizar la precisión de los datos, cada esclavo debe tener un ID de servidor único para marcar la unicidad del esclavo. Por lo tanto, en la tarea de flink cdc, asignamos un intervalo de ID de servidor único a cada tarea (el intervalo de rango es compatible con varios grados de paralelismo).
4.3 Cuello de botella de serialización de datos de tareas de Flink
Cuando se usa la API DataStream en la tarea flink y se usa una estructura de datos más compleja para la transmisión, el costo de serialización entre operadores es relativamente alto. Hay dos direcciones, una es establecer una estructura de datos más eficiente para la transmisión y la otra es habilite el uso complejo de objetos flink y minimice las transferencias de datos entre diferentes grados de paralelismo.
5 Evolución futura
La función principal de DTS como plataforma de sincronización de datos es proporcionar una función de sincronización de fuente de datos lo más eficiente posible para ayudar a cambiar los escenarios comerciales.
5.1 Gestión de tareas ETL basada en Flink SQL
Además de la API DataStream existente, el procesamiento de transmisión de datos también existe en forma de SQL.Como lenguaje de propósito general, SQL reduce en gran medida el costo de aprendizaje para los estudiantes de negocios relacionados con los datos. El procesamiento de datos de transmisión ETL que se puede realizar a través de Flink SQL también puede resolver la lógica de procesamiento de algunos escenarios comerciales complejos y transformar la lógica comercial en un gráfico de procesamiento de transmisión DAG, que también se puede usar fácilmente arrastrando y soltando. FLINK SQL Directions puede complementar la API Flink DataStream existente.
Escenarios de aplicación: las poderosas capacidades de procesamiento y conversión de datos de transmisión de ETL mejoran en gran medida la eficiencia de integración de datos, y también pueden crear un sistema de informes en tiempo real para mejorar la eficiencia del análisis, y también se pueden aplicar a algunos escenarios de pantalla grande en tiempo real.
5.2 Pila de tecnología unificada
Migrar todas las capacidades DTS existentes a la plataforma Flink y mantener una pila de tecnología unificada puede reducir en gran medida los costos de mantenimiento. La sincronización bidireccional heredada existente, la comparación de datos y otras capacidades deben transformarse y migrarse aún más, en línea con la tendencia de convergencia tecnológica general.
6 Resumen
Este artículo comparte principalmente los siguientes aspectos: los beneficios que trae Flink en comparación con la pila de tecnología existente, la dirección iterativa después de cambiar a Flink y los cambios en las funciones arquitectónicas, cómo resolver nuevos problemas y algunas direcciones iterativas futuras, espero que todos puedan ganar algo
*Texto/Fengzi
Este artículo es un artículo original de Dewu Technology. Para obtener más artículos interesantes, consulte: Sitio web oficial de Dewu Technology
¡Está estrictamente prohibido reimprimir sin el permiso de Dewu Technology, de lo contrario, se investigará la responsabilidad legal de acuerdo con la ley!