Estos contenidos se han traducido de forma automática para su comodidad, pero Huawei Cloud no garantiza la exactitud de estos. Para consultar los contenidos originales, acceda a la versión en inglés.
Actualización más reciente 2023-04-14 GMT+08:00

Principios básicos de Flink

Descripción

Flink es un marco de computación unificado que soporta tanto el procesamiento por lotes como el procesamiento de flujo. Proporciona un motor de procesamiento de datos de flujo que admite la distribución de datos y la computación en paralelo. Flink cuenta con procesamiento de flujo y es un motor de procesamiento de flujo de código abierto superior en la industria.

Flink proporciona procesamiento de datos de canalización de alta concurrencia, latencia de nivel de milisegundos y alta confiabilidad, lo que lo hace extremadamente adecuado para el procesamiento de datos de baja latencia.

Figura 1 muestra la pila de tecnología de Flink.

Figura 1 Pila de tecnología de Flink

Flink proporciona las siguientes características en la versión actual:

  • DataStream
  • Checkpoint
  • Window
  • Job Pipeline
  • Configuration Table

Otras características son heredadas de la comunidad de código abierto y no son mejoradas. Para obtener más información, visite https://ci.apache.org/projects/flink/flink-docs-release-1.12/.

Arquitectura de Flink

Figura 2 muestra la arquitectura de Flink.

Figura 2 Arquitectura de Flink

Como se muestra en la figura anterior, todo el sistema de Flink consta de tres partes:

  • Client

    Flink client se utiliza para enviar trabajos (trabajos de streaming) a Flink.

  • TaskManager

    TaskManager es un nodo de ejecución de servicio de Flink. Ejecuta tareas específicas. Un sistema de Flink puede tener múltiples TaskManagers. Estos TaskManagers son equivalentes entre sí.

  • JobManager

    JobManager es un nodo de gestión de Flink. Gestiona todas las TaskManagers y programa las tareas enviadas por los usuarios a TaskManagers específicos. En el modo de alta disponibilidad (HA), se despliega múltiples JobManagers. Entre estos JobManagers se selecciona uno como el JobManager activo, y los otros están en espera.

Para obtener más información sobre la arquitectura de Flink, visite https://ci.apache.org/projects/flink/flink-docs-master/docs/concepts/flink-architecture/.

Principios de Flink

  • Stream & Transformation & Operator

    Un programa Flink consta de dos bloques de construcción: stream and transformation.

    1. Conceptualmente, un stream es un flujo (potencialmente interminable) de registros de datos, y transformation es una operación que toma uno o más streams como entrada, y produce uno o más streams de salida como resultado.
    2. Cuando se ejecuta un programa Flink, se asigna a un streaming dataflow. Un streaming dataflow consiste en un grupo de streams y transformation operator. Cada dataflow comienza con uno o más source operators y termina en uno o más sink operators. Un dataflow se asemeja a un gráfico acíclico dirigido (DAG).

      Figura 3 muestra el streaming dataflow al que se mapea un programa Flink.

      Figura 3 Ejemplo de Flink DataStream

      Como se muestra en el Figura 3, FlinkKafkaConsumer es un operador de origen; Map, KeyBy, TimeWindow y Apply son transformation operators; RollingSink es un sink operator.

  • Pipeline Dataflow

    Las aplicaciones en Flink pueden ejecutarse en modo paralelo o distribuido. Un stream puede dividirse en una o más particiones de stream, y un operator puede dividirse en múltiples operator subtasks.

    El ejecutor de streams y operators se optimiza automáticamente en función de la densidad de los operadores ascendentes y descendentes.

    • Los operadores con baja densidad no se pueden optimizar. Cada operator subtask se ejecuta por separado en diferentes subprocesos. El número de operator subtasks es el paralelismo de ese operador en particular. El paralelismo (el número total de particiones) de un stream es el de su operator productor. Diferentes operators del mismo programa pueden tener diferentes niveles de paralelismo, como se muestra en Figura 4.
      Figura 4 Operator
    • Los operadores con alta densidad pueden ser optimizados. Flink encadena operator subtasks en una tarea, es decir, un operator chain. Cada operator chain es ejecutada por un subproceso en TaskManager como se muestra en Figura 5.
      Figura 5 Operator chain
      • En la parte superior de Figura 5, los operadores de Source y Map condensados están encadenados en un Operator Chain, es decir, un operador más grande. El Operator Chain, el KeyBy y el Sink representan respectivamente a un operador y están conectados entre sí a través de streams. Cada operador corresponde a un task durante la ejecución. Es decir, hay tres tasks en la parte superior.
      • En la parte inferior de Figura 5 cada task, excepto Sink, es paralela en dos subtasks. El paralelismo del operador de Sink es uno.

Características clave

  • Procesamiento de flujos

    El motor de procesamiento de flujo en tiempo real cuenta con alto rendimiento, alto rendimiento y baja latencia, que puede proporcionar capacidad de procesamiento en milisegundos.

  • Diferentes gestión de estado
    La aplicación de procesamiento de flujo necesita almacenar los eventos recibidos o el resultado intermedio en un cierto período de tiempo para el acceso y procesamiento posteriores en un cierto punto de tiempo. Flink ofrece diversas funciones para la gestión de estado, que incluye:
    • Múltiples tipos de estado básicos: Flink proporciona varios estados para estructuras de datos, como ValueState, ListState y MapState. Los usuarios pueden seleccionar el tipo de estado más eficiente y adecuado basado en el modelo de servicio.
    • State Backend rico: State Backend gestiona el estado de las aplicaciones y realiza operaciones de Checkpoint según sea necesario. Flink proporciona diferentes State Backends. State se puede almacenar en la memoria o RocksDB, y soporta el mecanismo de Checkpoint asincrónico e incremental.
    • Consistencia de estado de una sola vez: Las capacidades de Checkpoint y recuperación de fallas de Flink garantizan que el estado de la aplicación de las tareas sea consistente antes y después de que se produzca un falla. Flink admite salida transaccional para algunos dispositivos de almacenamiento específicos. De esta manera, se puede garantizar una salida exactamente una vez incluso cuando se produce una falla.
  • Varias semánticas de tiempo

    El tiempo es una parte importante de las aplicaciones de procesamiento de flujo. Para aplicaciones de procesamiento de flujo en tiempo real, son muy comunes operaciones tales como agregación de ventanas, detección y emparejamiento basado en semántica de tiempo. Flink proporciona varias semánticas de tiempo.

    • Event-time: La marca de tiempo proporcionada por el evento se utiliza para el cálculo, facilitando el procesamiento de los eventos que llegan a una secuencia aleatoria o llegan tarde.
    • Watermark: Flink introduce el concepto de Watermark para medir el desarrollo del tiempo de eventos. Watermkark también proporciona una garantía flexible para balancear la latencia del procesamiento y la integridad de los datos. Cuando se procesan flujos de eventos con Watermark, Flink proporciona múltiples opciones de procesamiento si los datos llegan después del cálculo, por ejemplo, redirigir datos (salida lateral) o actualizar el resultado del cálculo.
    • Se admite Processing-time y Ingestion-time.
    • Ventana de streaming altamente flexible: Flink admite la ventana de tiempo, la ventana de conteo, la ventana de sesión y la ventana personalizada basada en datos. Puede personalizar las condiciones de activación para implementar el modo de cálculo de streaming complejo.
  • Mecanismo de tolerancia a fallas

    En un sistema distribuido, si una única tarea o nodo se descompone o está defectuoso, toda la tarea puede fallar. Flink proporciona un mecanismo de tolerancia a fallas a nivel de tarea, que garantiza que los datos del usuario no se pierdan cuando se produzca una excepción en una tarea y se pueda restaurar automáticamente.

    • Checkpoint: Flink implementa la tolerancia a fallas basada en checkpoint. Los usuarios pueden personalizar la política de checkpoint para toda la tarea. Cuando se produce un error en una tarea, la tarea se puede restaurar al estado del último checkpoint y los datos más recientes después de que la instantánea se reenvíe desde el origen de datos.
    • Savepoint: Un savepoint es una instantánea consistente del estado de la aplicación. El mecanismo de savepoint es similar al de checkpoint. Sin embargo, el mecanismo de savepoint necesita ser activado manualmente. El mecanismo de savepoint garantiza que la información de estado de la aplicación de flujo actual no se pierda durante la actualización o migración de tareas, lo que facilita la suspensión y recuperación de tareas en cualquier punto de tiempo.
  • Flink SQL

    Table APIs y SQL usan Apache Calcite para analizar, verificar y optimizar consultas. Table APIs y SQL se pueden integrar sin problemas con DataStream y DataSet APIs, y admiten funciones escalares definidas por el usuario, funciones de agregación y funciones de valor de tabla. La definición de aplicaciones tales como análisis de datos y ETL se simplifica. En el ejemplo de código siguiente se muestra cómo utilizar sentencias de Flink SQL para definir una aplicación de recuento que registra los tiempos de sesión.

    SELECT userId, COUNT(*) 
    FROM clicks 
    GROUP BY SESSION(clicktime, INTERVAL '30' MINUTE), userId

    Para obtener más información acerca de Flink SQL, consulte https://ci.apache.org/projects/flink/flink-docs-master/dev/table/sqlClient.html.

  • CEP en SQL

    Flink permite a los usuarios representar resultados de consultas de procesamiento de eventos complejos (CEP) en SQL para la coincidencia de patrones y evaluar flujos de eventos en Flink.

    CEP SQL se implementa a través de la sintaxis de SQL MATCH_RECOGNIZE. La cláusula MATCH_RECOGNIZE es compatible con Oracle SQL desde Oracle Database 12c y se utiliza para indicar la coincidencia de patrones de eventos en SQL. El siguiente es un ejemplo de CEP SQL:

    SELECT T.aid, T.bid, T.cid
    FROM MyTable
        MATCH_RECOGNIZE (
          PARTITION BY userid
          ORDER BY proctime
          MEASURES
            A.id AS aid,
            B.id AS bid,
            C.id AS cid
          PATTERN (A B C)
          DEFINE
            A AS name = 'a',
            B AS name = 'b',
            C AS name = 'c'
        ) AS T