Sobre el autor: ingeniero de desarrollo senior de la plataforma de datos Ma Yangyang Dada Group, responsable del mantenimiento y desarrollo del motor informático del grupo Dada
Este artículo presenta principalmente la experiencia práctica de Dada Group en el proceso de SQLización de tareas informáticas en tiempo real utilizando Dada Flink SQL desarrollado por el código abierto Flink Stream SQL
01
Antecedentes
En 2018, con los esfuerzos conjuntos de la plataforma de datos y el equipo de datos, ya tenemos un proceso completo de cálculo fuera de línea, un modelo perfecto de depósito de datos fuera de línea, y también lanzamos muchos productos de datos y una gran cantidad de informes de datos. Con el desarrollo de los negocios, nos enfrentamos gradualmente a más y más necesidades informáticas en tiempo real. Con la popularidad gradual de Flink en China, la informática en tiempo real también está entrando cada vez más en nuestro campo de visión. En ese momento, la función SQL de Flink no era perfecta, y las funciones requeridas para el desarrollo de datos a gran escala no podían expresarse en SQL. Por lo tanto, nuestra elección es similar a la elección de muchas compañías. Al encapsular el marco y la API de Flink, es difícil para nuestros desarrolladores de datos desarrollar tareas en tiempo real. En respuesta a estas necesidades, planeamos adoptar algunos empaques, para que los estudiantes de desarrollo de datos no necesiten desarrollar código Java o Scala, centrándose en el desarrollo de la lógica de negocios. Debido a los recursos de desarrollo limitados, tendemos a realizar esta tarea mediante la introducción de algunos marcos de código abierto y la realización de un desarrollo personalizado. A través de algunas investigaciones, bloqueamos Flink Stream SQL (en adelante, FSL) de Kangaroo Cloud y AthenaX de Uber. Después de la comparación, los complementos de FSL, la actividad de desarrollo y el soporte relativamente completo son más atractivos para nosotros. Por lo tanto, presentamos FSL para Kangaroo Cloud y desarrollamos el motor SQL Dada Flink SQL (en lo sucesivo denominado DFL) basado en FSL, y lo utilizamos para SQLizar tareas informáticas en tiempo real.
02
Arquitectura
Primero introduce la arquitectura de DFL. Los componentes principales de DFL son lanzador, núcleo, plug-in de fuente, plug-in de sumidero, plug-in de Flink Siddhi y plug-in lateral. Entre ellos, Flink Siddhi es un motor de reglas basado en Siddhi al que accedemos según el Flink Siddhi de código abierto. Contenido relacionado con Flink Siddhi y el empaque que hicimos. El iniciador es responsable de cargar los complementos necesarios de fuente / lado / sumidero y enviar el programa Flink al clúster Flink, admitiendo el modo de clúster de sesión y el modo de trabajo único. El módulo principal es responsable de analizar las instrucciones SQL, generar SQLTree y cargar los complementos correspondientes basados en la fuente analizada, el receptor, Flink Siddhi y el contenido lateral, generar los componentes necesarios y registrarse en Flink TableEnvironment. Después de eso, dependiendo de si SQL usa la función JOIN de la tabla de dimensiones, elegirá llamar directamente a TableEnvironment.sqlUpdate () o procesar la tabla de dimensiones JOIN. Además de la tabla de dimensiones JOIN, de acuerdo con las necesidades de nuestros estudiantes de desarrollo de datos, también nos unimos al apoyo de INTERVAL JOIN. Usando la representación del proceso, el flujo general de DFL se muestra en la figura a continuación.
2.1 Analizador
DFL utiliza Parser para analizar las instrucciones SQL, analizarlas en las estructuras de datos correspondientes y ponerlas en SqlTree para su administración para su uso posterior. El analizador define una buena interfaz, y es fácil agregar soporte para la nueva sintaxis SQL agregando nuevas clases de implementación. La interfaz de Parser se define de la siguiente manera:
Entre ellos, la coincidencia se usa para juzgar si una implementación específica del analizador puede analizar una instrucción SQL dada. VerifySyntax es una función de interfaz recientemente agregada para que verifiquemos si la sintaxis de un SQL determinado es correcta y colocamos información de error relacionada. En errorInfo para que use la persona que llama, parserSql para lograr un análisis de sintaxis SQL específico. Agregamos muchas implementaciones para IParser para lograr nuevas funciones, como agregar soporte para Flink Siddhi.
2.2 Tabla de dimensiones JOIN
Hay dos formas de realizar JOIN en el DFL: ALL y SIDE. El método ALL leerá y almacenará en caché los datos que necesitan JOIN en la memoria de la tarea al mismo tiempo, y puede configurar el caché para que se actualice regularmente; el método SIDE lee los datos correspondientes de la fuente de datos correspondiente cuando se necesita JOIN, y de acuerdo con la configuración Decida si desea almacenar en caché los datos leídos en la memoria. Las clases abstractas correspondientes de los modos ALL y SIDE se definen como AllReqRow y AsyncReqRow respectivamente. Todos implementan la interfaz común ISideReqRow. ISideReqRow define un método para UNIR los datos de la tabla de hechos y los datos leídos por la tabla de dimensiones. Row fillData ( Entrada de fila, Entrada lateral de objeto). Las definiciones de AllReqRow y AsyncReqRow son las siguientes:
Puede ver el patrón de diseño en el que se utiliza el método de plantilla.
AsyncSideReqRow proporciona principalmente el método de procesamiento predeterminado al inicializar la memoria caché LRU, obtener datos de la memoria caché LRU y no puede encontrar los datos que requieren UNIRSE desde la fuente de datos o la memoria caché LRU.
03
Funciones y mejoras añadidas
En el proceso de desarrollo de DFL, basado en algunas necesidades relacionadas con el negocio y las necesidades de los desarrolladores de datos simplificados para usar DFL, hemos realizado muchas mejoras y expansiones sobre la base de FSL nativo. Aquí están algunos de los trabajos que hacemos en DFL.
3.1 En el modo Flink HA, el envío de tareas en modo SESIÓN ha excedido el tiempo de espera
Para tener una mejor tolerancia a fallas de las tareas de Flink, configuramos HA basada en ZooKeper para clusters de Flink. Para fines de mantenimiento y administración de tareas, algunas de nuestras tareas de Flink utilizan el modo de sesión. Después de migrar estas tareas al DFL, informaremos un error de tiempo de espera al enviar las tareas. Al revisar la documentación oficial de Flink tampoco se encontraron pistas. Después de nuestra exploración posterior, se descubrió que en el modo de sesión YARN, cuando se configura HA, se debe especificar la alta disponibilidad.cluster-id para el envío de tareas. Después de agregar el siguiente código, la tarea se puede enviar normalmente en modo SESIÓN.
3.2 Kafka admite el uso de palabras clave SQL como nombres de campo JSON
Cuando la palabra clave SQL se usa como el nombre del campo en Flink, incluso si el nombre del campo está envuelto con comillas invertidas, se informará el siguiente error:
Este es un error de Flink, que se ha corregido en 1.10.1, consulte este problema para obtener más detalles: https://issues.apache.org/jira/browse/FLINK-16526. La versión que utilizamos es Flink 1.6.2 y esta solución no se puede utilizar. Nuestro enfoque es admitir el desacoplamiento del nombre del campo JSON en Kafka y el nombre de la columna que hace referencia a este campo JSON, es decir, Flink SQL usa el nombre de columna especificado para referirse al campo JSON, y el nombre del campo JSON original se usa para el análisis JSON. Específicamente, en el sistema de metadatos, admitimos registrar un sourceName opcional para tablas de tipo Kafka. Si sourceName está registrado, Flink Stream SQL usará sourceName para analizar el campo correspondiente en JSON.
3.3 Integración de metadatos
Después de que el DFL se puso en línea, al agregar las funciones necesarias, el uso del desarrollo SQL puro ha satisfecho muchas de nuestras necesidades de desarrollo de tareas en tiempo real. Sin embargo, después de ejecutar el DFL durante un período de tiempo, notamos los problemas causados por la administración de información almacenada en sentido ascendente y descendente a nuestros desarrolladores de datos. Los sistemas de almacenamiento que utilizamos en línea incluyen Kafka, HBase, ElasticSearch, Redis y MySQL (ClickHouse fue presentado más adelante). Estas fuentes de datos son básicamente heterogéneas, con diferentes conexiones e información del usuario, y la misma fuente de datos se utiliza en diferentes tareas. Cada vez que necesite usar la sintaxis CREATE TABLE <table_name> () WITH () para convertir la información de campo y Repita la información de conexión. En respuesta a este problema, inspirado en los metadatos de Hive, decidimos desarrollar nuestro propio sistema de administración de metadatos en tiempo real para administrar estas fuentes de datos en tiempo real. La arquitectura de nuestro sistema de gestión de metadatos se muestra a continuación.
Después de que se completó el desarrollo del sistema de gestión de metadatos, integramos profundamente Flink Stream SQL y el sistema de gestión de metadatos. Al introducir la sintaxis de USE TABLE <> AS <> WITH (), nuestros desarrolladores de datos solo necesitan registrar la fuente de datos en el sistema de gestión de metadatos y luego hacer referencia a la tabla registrada en Flink Stream SQL sin completar más Información de conexión, y si necesita referirse a todos los campos, no necesita completar la información del campo. Si no desea citar todas las subsecciones, hay dos formas de hacerlo. El primer método es usar columnas para expresar los campos que deben referenciarse en USE TABLE WITH. El segundo método es registrar una tabla en el sistema de metadatos que contenga solo los campos a los que se hará referencia.
3.4 Soporte de tipo de datos Redis hash / set
FSL tiene soporte incorporado para Redis como una tabla de sumidero y una mesa auxiliar, pero FSL solo admite datos de Redis String, y nuestra escena utilizará Redis hash y establecerá datos, por lo que debemos agregar Redis Soporte para varios tipos de datos. Primero introduzca el método de mapear los datos en Redis a la tabla en Flink. Nuestra clave Redis contiene dos partes (separadas por ":"), las dos partes son keyPrefix fijo y una a más El valor de este campo usa ":" primaryKey empalmado, donde keyPrefix simula el concepto de una tabla y también facilita la gestión del contenido almacenado en Redis. Para los datos de cadena, la clave Redis se unirá con el nombre del campo (usando ":" como delimitador) en función de la clave introducida anteriormente, y el valor del campo se escribirá en Redis con el valor correspondiente a la clave; para Hash Para el tipo de datos, la clave completa de Redis es la clave descrita anteriormente. La clave hash está compuesta por el valor del campo especificado por el usuario usando ":". De manera similar, el valor de hash está cosido por el valor del campo especificado por el usuario En. Además del soporte de Redis hash y establecer tipos de datos, también hemos agregado las funciones setnx y hsetnx y TTL a Redis.
3.5 Soporte de sumidero ClickHouse
FSL tiene soporte incorporado para fuentes de datos como Kafka, MySQL, Redis, Elasticsearch y HBbase como tablas de destino, pero también encontramos algunas fuentes de datos nuevas como final de escritura de destino durante el proceso de uso Sumidero para soportar esta demanda. Los complementos de sumidero que desarrollamos y mantenemos incluyen ClickHouse y HdfsFile. Tomemos como ejemplo el sumidero de ClickHouse para presentar parte del trabajo que hemos realizado a este respecto.
Para ClickHouse, hemos desarrollado ClickhouseSink que implementa RichSinkFunction y CheckitatedFunction. Al implementar CheckposedFunction y actualizar los datos a ClickHouse en el método snapshotState () para garantizar que no se pierdan los datos. Para tratar con diferentes tipos de datos de entrada, proporcionamos la interfaz ClickhouseMapper para asignar datos de entrada a datos de tipo org.apache.flink.types.Row. ClickhouseMapper se define de la siguiente manera.
A diferencia de la forma habitual para que los usuarios proporcionen el esquema de la tabla de sumidero, implementamos DESC
La forma de obtener el esquema de tabla de ClickHouse. Para tratar los tipos de datos especiales en ClickHouse, como nullable (String), Int32, etc., utilizamos expresiones regulares para extraer el tipo real para escribir, el código relevante es el siguiente.Para escribir datos sin bloquear el flujo normal de procesamiento de datos, utilizamos el método de poner las tareas de escritura de datos en el grupo de subprocesos. Al mismo tiempo, para evitar la pérdida de datos cuando falla la tarea de Flink, espere a que la tarea en el grupo de subprocesos se complete en el método snapshotState ().
3.6 Simplificación de la expresión BINLOG
Para procesar la actualización de datos en línea, adoptamos el Canal de código abierto de Alibaba para recopilar el binlog MySQL y enviarlo a Kafka. Debido a la forma especial de organización de datos de binlog, se necesita mucho trabajo complicado para procesar los datos de binlog, como usar udf para extraer los campos reales agregados o actualizados de los campos columnValues o updatedValues de binlog. Debido a que vinculamos Flink Stream SQL con el sistema de metadatos, podemos obtener la información del esquema de las tablas MySQL, por lo que podemos proporcionar encapsulación de sintaxis para ayudar a los desarrolladores de datos a reducir esta expresión repetitiva de SQL. Para este fin, presentamos una nueva sintaxis SQL: USE BINLOG TABLE, el formato de esta sintaxis es el siguiente.
我们会将这种语法展开为如下的内容。
04
Solicitud
Después de que el DFL se pone en línea, ya que puede desarrollarse utilizando SQL puro, que está en línea con los hábitos de desarrollo de los estudiantes de desarrollo de datos, y proporcionamos una gran cantidad de encapsulación de sintaxis, más la conveniencia que brinda la gestión de metadatos, los estudiantes de desarrollo de datos migran gradualmente algunas tareas informáticas en tiempo real Cuando se trataba del DFL, esto trajo una gran mejora en la eficiencia del departamento. Hasta ahora, DFL se ha aplicado a varios sistemas de aplicación de datos de Dada Group. Las tareas de cálculo en tiempo real que se ejecutan en el sistema han alcanzado más de 70, cubriendo varios módulos comerciales y de tráfico de Dada Express y JD Daojia, y tareas de cálculo en tiempo real El número y la proporción de SQLización siguen aumentando constantemente. Con la apertura de la infraestructura informática del departamento de big data, nuestras capacidades informáticas en tiempo real se están utilizando cada vez más en otros grupos del grupo.
05
Planificación futura
La versión actual de la comunidad de Flink se ha desarrollado a 1.10. Flink Table / SQL ya es compatible con la mayoría de las funciones proporcionadas por DFL. Para reducir la complejidad del mantenimiento de componentes, planeamos introducir Flink 1.10 en el futuro y promover gradualmente el uso de Flink 1.10 para Finalmente, todas las tareas se migran a la última versión de Flink.
La compañía está promoviendo gradualmente el uso de nubes privadas. Teniendo en cuenta el progreso de la comunidad en Flink en K8, intentaremos implementarlo en la nube privada de la compañía cuando presentemos una nueva versión de Flink.
Recomendación de servicio
