Expansión optimizada de Tencent basada en Flink

1. Antecedentes y situación actual

 

1. Análisis de los tres modos 

 

 

Actualmente hay tres formas de crear trabajos de Flink: modo JAR, modo lienzo y modo SQL. Las diferentes formas de enviar tareas se dirigen a diferentes grupos de personas.

■ Modo jar

El modo Jar se desarrolla en base a la API DataStream / DataSet y está dirigido principalmente a los desarrolladores subyacentes.

• ventaja:

• Las funciones son flexibles y modificables, porque la API DataStream / DataSet subyacente es la API nativa de Flink, y puede usarlas para desarrollar cualquier función de operador o gráfico DAG que desee;

• La optimización del rendimiento es conveniente y el rendimiento de cada operador se puede optimizar de manera específica.

 

• Desventajas:

 

• Las actualizaciones dependientes son engorrosas Independientemente de la lógica de operación extendida o la actualización de la versión de Flink, el código de operación y la versión dependiente deben actualizarse;

• El umbral de aprendizaje es alto.

 

■ Modo lienzo

El llamado modo lienzo generalmente proporciona una interfaz visual de arrastrar y soltar, lo que permite a los usuarios realizar operaciones de arrastrar y soltar en una forma basada en la interfaz para completar la edición de trabajos de Flink. Está dirigido a algunos usuarios novatos.

• ventaja:

• La operación es conveniente y los diversos operadores incluidos en el trabajo de Flink se pueden definir fácilmente en el lienzo;

• La función es relativamente completa, se basa en el desarrollo de Table API, la cobertura de la función es relativamente completa;

• Fácil de entender, el diagrama DAG es relativamente intuitivo, los usuarios pueden comprender fácilmente el proceso de ejecución de todo el trabajo.

• Desventajas:

• Configuración compleja: cada operador debe configurarse uno a uno, si todo el gráfico DAG es muy complicado, el trabajo de configuración correspondiente será muy grande;

• Dificultad en la reutilización de la lógica: si hay muchos trabajos, es muy difícil compartir la lógica del DAG entre diferentes trabajos.

■ modo SQL

El lenguaje SQL existe desde hace mucho tiempo y tiene su propio conjunto de estándares, principalmente para analistas de datos. Siempre que sigan los estándares SQL existentes, los analistas de datos pueden cambiar entre diferentes plataformas y motores informáticos.

• ventaja:

• Claro y conciso, fácil de entender y leer;

• Al desacoplarse del motor de cálculo, SQL se desacopla del motor de cálculo y su versión La migración de la lógica empresarial entre diferentes motores de cálculo no requiere o rara vez necesita cambiar todo el SQL. Al mismo tiempo, si desea actualizar la versión de Flink, no necesita cambiar el SQL;

• La reutilización de la lógica es conveniente y nuestra lógica SQL se puede reutilizar creando una vista.

• Desventajas:

• La gramática no es uniforme, como la combinación de tabla de flujo y dimensión.Antes de Flink 1.9, se usaba la gramática de unión de tabla lateral, pero después de 1.9, se cambió a la gramática PERIOD FOR SYSTEM_TIME. Esta gramática sigue el estándar SQL ANSI 2011. Los cambios en la gramática hacen que los usuarios tengan un cierto costo de aprendizaje;

• Cobertura de funciones incompleta: el módulo Flink SQL no existe desde hace mucho tiempo, lo que resulta en una cobertura incompleta de sus funciones.

• El ajuste del rendimiento es difícil: la eficiencia de ejecución de una parte de SQL está determinada principalmente por varias partes, una es la lógica de negocios expresada por el propio SQL; la otra parte es una optimización del plan de ejecución generado por la traducción SQL; la tercera parte es lo más Después del plan de ejecución lógica óptima, al traducir el código nativo al código local, el plan también determina la eficiencia de ejecución de SQL; para los usuarios, el contenido que pueden optimizar puede estar limitado a la lógica de negocios expresada por SQL.

• Dificultad para localizar el problema: SQL es un proceso de ejecución completo, si encontramos que algunos datos son incorrectos, es más difícil averiguar qué operador tiene el problema de manera específica. En términos generales, si queremos localizar el problema de Flink SQL, solo podemos continuar optimizando toda nuestra lógica SQL, y luego continuar intentando generar resultados, este costo es muy alto. La plataforma informática en tiempo real de Tencent abordará más adelante este problema agregando registros de seguimiento e información de métricas, y la salida al lado del producto para ayudar a los usuarios a localizar problemas en el uso de Flink SQL.

2. Trabajo actual de la plataforma informática en tiempo real de Tencent

■ Sintaxis ampliada

La gramática de la función con valores de tabla de ventana se define para ayudar a los usuarios a implementar operaciones de combinación e intersección y combinación de flujo basadas en ventanas. Además, implementa su propia gramática Join de tabla de flujo y dimensión.

■ Nuevas funciones

Algunas características nuevas incluyen dos nuevos tipos de ventana, ventana incremental y ventana de caída mejorada. Realizó el desacoplamiento de Eventtime Field y Table Source. En muchos casos, Eventtime Field no puede ser definido por el campo Table Source. Por ejemplo, Table Source es una subconsulta o un cierto campo de tiempo es convertido por una función, y usted quiere usar estos generaciones intermedias. El campo de tiempo no está actualmente disponible como un campo de tiempo de evento. Nuestra solución actual es permitir al usuario seleccionar cualquier campo de tiempo en la tabla física para definir el atributo de tiempo de la ventana y generar el WaterMark.

■ Ajuste del rendimiento

• Optimización del flujo de inconvenientes;

• UDF en línea, si la misma UDF aparece tanto en LogicalProject como en la condición Where, se llamará a la UDF varias veces. Extraiga la UDF que se llama repetidamente en el plan de ejecución lógica y almacene en caché el resultado de la ejecución de la UDF para evitar múltiples llamadas;

■ Unión de grupo

 

Hay un problema de inicio en frío de datos en la tabla de dimensiones de la tabla de flujo Unir. Si la tarea Flink carga una gran cantidad de datos externos cuando se inicia, es fácil causar contrapresión. Puede utilizar la API del procesador de estado y otros medios para precargar todos los datos en la memoria al inicio. Sin embargo, existe un problema con esta solución: cargar los datos de la tabla de dimensiones en todas las subtareas provocará un gran consumo de memoria. Por lo tanto, nuestra solución es especificar la información de un depósito en la definición de la tabla de dimensiones. Cuando se unen el flujo y la tabla de dimensiones, los datos del fragmento correspondiente en la tabla de dimensiones se cargarán según la información del depósito y el flujo La tabla se traducirá durante el plan de ejecución. Obtenga la información del depósito para asegurarse de que los datos de las tablas de flujo y dimensión se unirán en función de la misma información del depósito. Este método puede reducir en gran medida el problema de consumo de memoria causado por la precarga de los datos de la tabla de dimensiones completas.

 

2. Ampliación de la función de ventana

La plataforma informática en tiempo real de Tencent se basa en la gramática Flink SQL existente para algunas extensiones y también define dos nuevos tipos de ventanas.

1. Operación de nueva ventana

Los requisitos existentes son los siguientes: Es necesario realizar una operación de combinación o una operación de combinación durante una determinada ventana de tiempo en las dos secuencias.

Utilice Flink SQL para realizar uniones de flujo dual basado en una determinada ventana. Hay dos soluciones existentes: la primera solución es unir primero y luego agrupar por, y la segunda es unir por intervalos. Primero, analicemos si la primera opción puede satisfacer la demanda.

■ 1.1 Únase primero y luego abra la ventana

 

 

La lógica de Unir primero y luego la apertura de la ventana se muestra en la figura anterior. De acuerdo con el plan de ejecución lógico, puede ver que el nodo Unir está debajo del nodo de Agregado de ventana, por lo que el flujo y el flujo de unión se realizarán primero, y luego el agregado de ventana se realizará después de que se complete la unión.

Como se puede ver en el diagrama de flujo en el lado derecho de la figura, primero los dos flujos harán una conexión y luego realizarán la operación Keyby basada en la clave de unión para asegurarse de que los datos con la misma clave de unión en los dos flujos puedan ser barajado a la misma tarea. La secuencia de la izquierda almacenará los datos en su propio estado y, al mismo tiempo, pasará al estado de la secuencia de la derecha para la coincidencia. Si puede coincidir, generará el resultado coincidente en la secuencia descendente. Hay dos problemas con este esquema:

1. El estado no se puede limpiar : debido a que Join no tiene información de la ventana en Join antes de que se abra la ventana, incluso si la ventana descendente se activa y completa el cálculo, el estado de Join de los dos flujos ascendentes no se puede limpiar. Como máximo, puede Solo use Way basado en TTL para limpiar.

2. La semántica no puede satisfacer la demanda : la demanda original es dividir los datos en las dos secuencias en función de la misma ventana de tiempo y luego unir, pero la solución actual no puede satisfacer esta demanda porque hace la combinación primero y usa los datos después de la combinación luego abra la ventana, este método no puede garantizar que los datos que participan en la combinación en las dos secuencias se basen en la misma ventana.

■ 1.2 Unión de intervalo

 

En comparación con el método de escritura anterior, la ventaja de Interval Join es que no hay problema de que el estado no se pueda limpiar, porque los datos de las transmisiones izquierda y derecha se pueden escanear en función de una determinada ventana. el estado se puede limpiar.

Sin embargo, en comparación con la primera solución, esta solución puede tener una precisión de datos peor, porque la división de ventanas no se basa en una ventana determinada, sino que está impulsada por los datos, es decir, los datos actuales pueden ser otro flujo de Join. El rango de los datos anteriores se basa en el Eventtime transportado por los datos actuales. Todavía existe una cierta brecha entre la semántica de esta división de ventanas y nuestras necesidades.

Imagine dos flujos existentes con tasas inconsistentes. Los dos límites, el inferior y el superior, se utilizan para limitar el rango de datos del flujo izquierdo y del derecho que se pueden unir. Bajo restricciones de rango tan rígidas, siempre habrá algunos datos válidos en el corriente derecha que cae en el tiempo Fuera de la ventana [izquierda + baja, izquierda + superior], el cálculo no es lo suficientemente preciso. Por lo tanto, es mejor dividir la ventana de tiempo de acuerdo con el método de alineación de la ventana, de modo que los datos con el mismo Eventtime en las dos secuencias caigan en la misma ventana de tiempo.

■ 1.3 Función de ventana con valores de tabla

Tencent ha ampliado la gramática de la función con valores de tabla de ventana, que puede cumplir con los requisitos de "Operación de combinación o operación de combinación durante una determinada ventana de tiempo en dos secuencias". Hay una descripción de esta gramática en el estándar SQL 2016, y la gramática ya existe en Calcite1.23.

 

La fuente en la sintaxis de la función con valores de tabla de ventana puede describir claramente su semántica completa.La cláusula From contiene toda la información necesaria para la definición de la ventana, incluida la fuente de la tabla, el campo de tiempo de evento, el tamaño de la ventana, etc.

Como puede verse en el plan lógico en la figura anterior, esta gramática agrega un nodo llamado LogicalTableFunctionScan a LogicalTableScan. Además, el nodo LogicalProject (nodo de salida) tiene dos campos más llamados WindowStart y WindowEnd. Según estos dos campos, los datos se pueden resumir en una determinada ventana. Según los principios anteriores, la sintaxis de la función con valores de tabla de ventana puede hacer las siguientes cosas

 

• En una sola transmisión , una ventana de tiempo se puede dividir como la sintaxis de la ventana de grupo existente. El método de escritura es como se muestra en la figura anterior, y toda la información de la ventana se coloca en la cláusula From, y luego se realiza Agrupar por. Esta forma de escribir debería estar más en línea con la comprensión del público de las ventanas de tiempo y es un poco más intuitiva que la forma actual de escribir Group Window en Flink SQL. Hicimos un truco al traducir la gramática de la función con valores de tabla de ventana en el flujo único, es decir, al implementar la traducción física de este SQL, no lo traducimos a una API de DataStream específica, sino que transformamos directamente su plan de ejecución lógica a The El plan de ejecución lógica de la ventana de grupo actual, es decir, el código que comparte el plan de ejecución físico subyacente, es solo un equivalente de un plan de ejecución lógico.

  Además, puede hacer alguna salida de clasificación o TopN para los datos en la ventana, porque la sintaxis de la función con valores de tabla de ventana ha dividido los datos en ciertas ventanas de antemano. Como se muestra en la figura anterior, primero divida la ventana en la cláusula From, y luego Order By y Limit los siguen inmediatamente, expresando directamente la ordenación y la semántica de TopN.

 

• En transmisiones duales , puede cumplir con los requisitos originales de "Operación de unión o operación de combinación cruzada en dos transmisiones durante un período de tiempo determinado". La sintaxis es como se muestra en la figura anterior. Primero, construya la tabla de ventanas de las dos ventanas, y luego use la palabra clave Join para realizar la operación Join; la operación de intersección y fusión es la misma, que es la misma que la intersección y Diferencia de funcionamiento de la base de datos tradicional SQL.

■ 1.4 Detalles de implementación

A continuación se presentan brevemente algunos detalles de nuestra implementación de la sintaxis de función con valores de tabla de ventana.

• 1.4.1 Propagación de ventanas

El método de traducción del plan lógico original se basa en LogicalTableScan, luego se traduce a la función de valor de tabla de ventana y finalmente se traduce a la cláusula OrderBy Limit. Todo el proceso almacenará el estado muchas veces, lo que supondrá un consumo relativamente grande en términos de rendimiento. Por lo tanto, se han realizado las siguientes optimizaciones para fusionar varios Logical Relnodes para la traducción, lo que puede reducir la generación de códigos de enlace intermedios y mejorar el rendimiento. .

• 1.4.2 Campo de atributo de hora

Puede ver la sintaxis de la función con valores de tabla de ventana:

SELECT * FROM TABLE(TUMBLE(TABLE <data>, DESCRIPTOR(<timecol>), <size> [, <offset>]))

 

table <data>  puede ser no solo una tabla, sino también una subconsulta. Por lo tanto, si vincula el atributo de tiempo al origen de la tabla al definir el campo Eventtime, y el origen de la tabla resulta ser una subconsulta, no satisfará nuestras necesidades en este momento. Entonces, cuando implementamos la gramática, desacoplamos el campo de atributo de tiempo del origen de la tabla. Por el contrario, el usuario usa cualquier campo de tiempo en la tabla física como el atributo de tiempo para generar una marca de agua.

• 1.4.3 Marca de agua de tiempo

La lógica de usar Marca de agua es la misma que en otras gramáticas. La marca de agua de tiempo mínimo de todas las tareas de entrada de las dos secuencias determina la marca de agua de tiempo de la ventana para activar el cálculo de la ventana.

• 1.4.4 Restricciones de uso

Actualmente existen algunas restricciones sobre el uso de la función de valor de tabla de ventana. En primer lugar, los tipos de ventana de los dos flujos deben ser los mismos y el tamaño de la ventana también es el mismo. Sin embargo, las funciones relacionadas con la ventana de sesión aún no se han implementado.

2. Nuevo tipo de ventana

La siguiente introducción se expande a dos nuevos tipos de ventanas.

■ 2.1 Ventana incremental

Existen los siguientes requisitos. Los usuarios quieren poder dibujar una curva pv / uv dentro de un día, es decir, generar varios resultados en un día o en una ventana grande, en lugar de esperar al final de la ventana para generar de manera uniforme el resultados una vez. En respuesta a esta demanda, hemos ampliado la Ventana incremental.

• 2.1.1 Múltiples disparadores

Basado en Tumble Window, disparador incremental personalizado. Este desencadenante garantiza que el cálculo de la ventana no solo se desencadena después del final de Windows, sino que cada período de intervalo definido en SQL desencadena un cálculo de la ventana.

 

Como en el caso de SQL en la figura anterior, el tamaño total de la ventana es de un segundo y se activa cada 0,2 segundos, por lo que se activarán 5 cálculos de ventana dentro de la ventana. Y el siguiente resultado de salida se calcula en función del resultado anterior.

• 2.1.2 Disparador perezoso

Hizo una optimización llamada Lazy Trigger para Incremental Window. En el proceso de producción real, el mismo valor clave de una ventana generará el mismo resultado después de activar el cálculo de la ventana varias veces. Para el flujo descendente, no es necesario recibir este tipo de datos repetidamente. Por lo tanto, si se configura Lazy Trigger, y bajo la misma clave en la misma ventana, el siguiente valor de salida será exactamente el mismo que el anterior, y el downstream no recibirá estos datos de actualización, reduciendo así la presión de almacenamiento downstream y la presión concurrente. .

■ 2.2 Ventana de caída mejorada

 

Existen los siguientes requisitos: El usuario espera que después de que se active la ventana de caída, los datos tardíos no se descarten, pero el cálculo de la ventana se activará nuevamente. Si usa la API de DataStream, puede usar SideOutput para completar los requisitos. Pero para SQL, actualmente no hay forma de hacerlo. Por lo tanto, la Ventana de caída existente se expande y también se recopilan los datos tardíos. Al mismo tiempo, los datos tardíos no vuelven a activar el cálculo de la ventana y la salida en sentido descendente cada vez que se reciben, sino que redefine un Activador y el intervalo de tiempo del Trigger. El tamaño de ventana definido en SQL para reducir la frecuencia de envío de datos en sentido descendente.

Al mismo tiempo, el flujo de salida lateral también utilizará la lógica de Windows para realizar otra agregación al acumular datos. Cabe señalar aquí que si el flujo descendente es una fuente de datos similar a HBase, para la misma ventana y la misma clave, los datos anteriores que normalmente se activaron por la ventana se sobrescribirán con los datos tardíos. En teoría, la importancia de los datos tardíos es la misma que la de los datos activados por la ventana normal y no se pueden cubrir entre sí. Finalmente, el downstream realizará una segunda agregación de datos normales y datos retrasados ​​bajo la misma clave en la misma ventana.

Tres, optimización del flujo de retroceso

A continuación, presentaré algunas optimizaciones realizadas en el flujo de retroceso.

1. Ambigüedad de la tabla de flujo

Revise algunos conceptos sobre los flujos de retroceso en Flink SQL.

En primer lugar, permítanme presentarles la consulta continua. En comparación con las características del procesamiento por lotes y la salida de un resultado a la vez, la agregación del flujo es una parte de los datos del flujo ascendente y el flujo descendente recibirá un elemento de datos actualizado, es decir , el resultado se actualiza constantemente mediante los datos ascendentes. Por lo tanto, el flujo descendente de la misma clave puede recibir varios resultados de actualización.

2. Flujo de retroceso

 

Tome el SQL de la figura anterior como ejemplo, cuando el segundo Java alcance el operador de agregación, actualizará el estado generado por el primer Java y enviará el resultado al flujo descendente. Si el downstream no procesa los resultados de múltiples actualizaciones, producirá resultados incorrectos. En respuesta a este escenario, Flink SQL introdujo el concepto de flujo de retroceso.

El llamado flujo de retroceso consiste en agregar una bandera delante de los datos originales e identificarlos con Verdadero / Falso. Si el indicador es Falso, significa que se trata de un mensaje de retroceso e informa al downstream que elimine los datos; si el indicador es True, el downstream realizará directamente la operación Insertar.

■ 2.1 ¿Cuándo ocurrirá el flujo de retroceso?

En la actualidad, existen cuatro escenarios para el flujo de retroceso generado en Flink SQL:

• Agregado sin ventana (escena agregada sin ventana)

• Rango

• Sobre la ventana

• Unión externa izquierda / derecha / completa

Explique por qué Outer Join producirá un retroceso. Tome Left Outer Join como ejemplo, y suponga que los datos del flujo izquierdo llegan antes que los datos del flujo derecho, los datos del flujo izquierdo escanearán el estado de los datos del flujo derecho. Si no hay datos que se puede unir, el flujo de la izquierda no conoce el flujo de la derecha. ¿Existe realmente este dato en el medio, o los datos correspondientes en el flujo de la derecha están retrasados? Para cumplir con la semántica de Outer join, los datos de la secuencia izquierda todavía generarán datos de Join y los enviarán en sentido descendente, similar a MySQL Left Join, los campos de la secuencia de la izquierda se rellenan con valores de campo de tabla normales y los campos correspondientes de el flujo de la derecha se rellena con Null y luego se envía al flujo descendente, como se muestra en la siguiente figura:

(La imagen proviene de la Comunidad Yunqi)

Posteriormente, si llegan los datos correspondientes del flujo de la derecha, escaneará el estado del flujo de la izquierda y volverá a realizar Join. En este momento, para asegurar la exactitud de la semántica, los datos especiales que se han enviado previamente al El flujo descendente debe retirarse y, al mismo tiempo, los datos de la última unión se envían al flujo descendente. Tenga en cuenta que para la misma clave, si se produce un retroceso, no se producirá el segundo retroceso, porque si los datos de la clave llegan más tarde, se pueden unir los datos correspondientes en otro flujo.

■ 2.2 Cómo lidiar con los mensajes de retroceso

 

A continuación se presenta la lógica del procesamiento de mensajes de retroceso en Flink.

En el caso de los nodos de computación intermedios, está controlado por las 4 banderas de la figura anterior, que indican si el nodo actual genera información de actualización o retractación, y si el nodo actual consumirá esta información de retracción. Estas 4 banderas pueden determinar toda la lógica de la generación y procesamiento de Retract. 

Para los nodos receptores, actualmente hay tres tipos de receptores en Flink, AppendStreamTableSink, RetractStreamTableSink y UpsertStreamTableSink. Si los datos ascendentes recibidos por AppendStreamTableSink son un mensaje Retract, informará un error directamente, porque solo puede describir la semántica de Append-Only; RetractStreamTableSink puede procesar la información Retract. Si el operador upstream envía un mensaje Retract, eliminará el mensaje. Si el operador ascendente envía información de actualización normal, realizará una operación de inserción en el mensaje; UpsertStreamTableSink puede entenderse como algunas optimizaciones de rendimiento para RetractStreamTableSink. Si la fuente de datos del Sink admite operaciones idempotentes o admite operaciones de actualización basadas en una clave determinada, UpsertStreamTableSink pasará la clave Upsert upstream al Table Sink durante la traducción de SQL y luego realizará la operación de actualización según la clave.

■ 2.3 Optimización relacionada

 

Realizamos las siguientes optimizaciones en función del flujo de reducción.

• 2.3.1 Optimización de nodos intermedios

 

Una de las razones más fundamentales para generar información de reducción es enviar continuamente los resultados de la actualización varias veces. Por lo tanto, para reducir la frecuencia de las actualizaciones y reducir la simultaneidad, puede acumular una parte de los resultados de la actualización antes de enviarlos. Como se muestra en la FIG:

• El primer escenario es un escenario AGG anidado (por ejemplo, dos operaciones de recuento). Cuando la primera capa Group By intenta enviar el resultado de la actualización al downstream, se creará un caché primero, reduciendo así la frecuencia de envío de datos al downstream . Cuando se alcanza la condición de activación de la caché, el resultado de la actualización se envía al flujo descendente.

• El segundo escenario es Outer Join. Como se mencionó anteriormente, Outer Join genera un mensaje de retroceso porque las velocidades de datos de la izquierda y la derecha no coinciden. Tome Left Outer Join como ejemplo, puede almacenar en caché los datos de la transmisión izquierda. Cuando lleguen los datos del flujo izquierdo, buscará en el estado del flujo derecho. Si puede encontrar los datos que se pueden unir con él, no se almacenarán en caché; si no se pueden encontrar los datos correspondientes, los datos de esta clave serán primero en caché, y cuando alcance ciertos desencadenantes Cuando se cumplan las condiciones, búsquelo en el estado de flujo correcto nuevamente. Si aún no se encuentran los datos correspondientes, envíe un fragmento de datos de unión que contenga un valor nulo en sentido descendente. Después de la derecha Si llegan los datos correspondientes, la caché correspondiente a la clave en la caché se vaciará y se enviará un mensaje de retroceso en sentido descendente.

Esto reducirá la frecuencia de envío de mensajes de retroceso en sentido descendente.

• 2.3.2 Optimización del nodo del sumidero

 

Se han realizado algunas optimizaciones para el nodo Sink y se ha creado una caché entre el nodo AGG y el nodo Sink para reducir la presión sobre el nodo Sink. Cuando los mensajes de retroceso se agregan en la caché, y cuando se alcanza la condición de activación de la caché, los datos actualizados se envían uniformemente al nodo receptor. Tome el SQL de la siguiente figura como ejemplo:

 

Consulte los resultados de salida antes y después de la optimización, puede ver que después de la optimización, la cantidad de datos recibidos en sentido descendente se reduce. Por ejemplo, el usuario Sam, cuando se intenta enviar un mensaje de devolución de llamada al flujo descendente, se crea una capa de caché. utilizado primero, y la cantidad de datos recibidos en sentido descendente se puede reducir mucho.

Cuatro, planificación futura

 

Presentamos el plan de trabajo de seguimiento de nuestro equipo:

• Optimización basada en costos : la optimización del plan de ejecución lógica de Flink SQL todavía se basa en RBO (optimización basada en reglas). Nuestro equipo quiere hacer algo basado en la CBO y la tarea principal es recopilar información estadística. La información estadística no solo proviene del propio Flink SQL, sino que también puede provenir de otros productos de la empresa, como metadatos, distribución de datos correspondientes a diferentes claves u otros resultados de análisis de datos. Al trabajar con otros productos de la empresa, podemos obtener los datos estadísticos más precisos y generar el mejor plan de ejecución.

• Más características nuevas (sintaxis CEP, etc.) : defina alguna gramática CEP basada en Flink SQL para satisfacer las necesidades de algunos usuarios con respecto a CEP.

• Optimización continua del rendimiento (unirse al operador, etc.) : nuestro equipo no solo está optimizando la capa del plan de ejecución, sino también una optimización detallada del operador de unión o la mezcla de datos.

• Más fácil de depurar : Finalmente, se trata de depurar y posicionar las tareas de Flink SQL. En la actualidad, Flink SQL carece relativamente de este aspecto, especialmente el problema de desalineación de datos en línea, que es muy difícil de solucionar. Nuestra idea actual es configurar SQL para escupir información de seguimiento o información de métricas durante la ejecución y luego enviarla a otras plataformas. A través de esta información de seguimiento e información métrica, ayude a los usuarios a localizar al operador del problema.