Flink Series 2 Descripción general del procesamiento de transmisión con estado de Flink

Este artículo es el segundo artículo de la serie Flink. El primer artículo es sobre preparación ambiental. Los estudiantes que lo necesiten pueden leer: https://blog.csdn.net/lly576403061/article/details/130358449?spm=1001.2014.3001.5501. Espero poder consolidar mis conocimientos en esta área y enriquecer mi árbol de habilidades a través del aprendizaje sistemático. Sin más preámbulos, comencemos.

1. Arquitectura tradicional de procesamiento de datos

Los datos y el procesamiento de datos son omnipresentes en nuestra vida diaria. Con la creciente cantidad de recopilación y uso de datos, se han diseñado y construido varias arquitecturas para administrar datos. Las arquitecturas de procesamiento de datos tradicionales se dividen en dos categorías: arquitectura de procesamiento transaccional y arquitectura de procesamiento analítico.

1.1, arquitectura de procesamiento transaccional

Todo tipo de aplicaciones que desarrollamos en tiempos normales pertenecen a la arquitectura de procesamiento transaccional. Por ejemplo: sistema de gestión de clientes (CRM), sistema de tareas (ZEUS), sistema de pedidos (SHUTTLE-ORDER) y todas las aplicaciones basadas en web.
La figura anterior es un diseño de una aplicación transaccional tradicional que almacena datos en una base de datos relacional remota. Las organizaciones transaccionales tradicionales tienen varias características.

1. El usuario real al que conectarse o un servicio externo.
2. Acepte continuamente solicitudes del exterior (usuario o sistema) y procese los datos devueltos en tiempo real Durante el procesamiento de cada solicitud, CRUD se realiza básicamente mediante la ejecución de transacciones de bases de datos remotas.
3. En muchos casos, se comparte la misma base de datos y la misma tabla.
   Una desventaja del diseño del sistema anterior es que causará algunos problemas cuando sea necesario actualizarlo o expandirlo. Por lo tanto, aparecen microservicios. Al optimizar servicios complejos, grandes y estrechamente acoplados, se diferencian muchas aplicaciones independientes, micro e independientes. Cada servicio se comunica a través de interfaces estandarizadas.

1.2 Arquitectura de procesamiento analítico

Los datos almacenados en diferentes bases de datos pueden preparar datos para nuestro análisis comercial, pero dado que las bases de datos transaccionales están aisladas entre sí, no consultaremos datos en bases de datos transaccionales, por lo que queremos convertir estos datos. Lo que debe hacer el análisis unificado es convertir los datos de diferentes bases de datos en alguna forma común. Aquí es donde entra en juego la arquitectura de procesamiento de datos analíticos (almacén de datos).
Para llenar los datos dispersos en el almacén de datos, necesitamos copiar los datos en la base de datos transaccional.Este proceso se divide en tres pasos: extraer-transformar-cargar (ETL). Todo el proceso es complejo y desafiante para el rendimiento. Para garantizar la sincronización de datos, se requiere una sincronización periódica de datos.

La figura anterior es una arquitectura de almacenamiento de datos analíticos, y el almacenamiento de datos analíticos puede proporcionar dos tipos de consultas.

1. Consulta de informes regulares: realice análisis y cálculos periódicos de datos comerciales, cuente indicadores importantes y proporcione una base de evaluación para el estado de salud de la empresa. (ingresos, producción, crecimiento de usuarios, volumen de pedidos, etc.)
2. Consulta instantánea: proporcione una base de datos en tiempo relativamente real para ayudar en las decisiones comerciales clave. (Inversión publicitaria, adquisición de clientes, conversión, etc.) En la actualidad, la formación ecológica de Apache HaDoop nos ha proporcionado un potente y rico motor de consultas de almacenamiento.Nuestros archivos de registro masivos, redes sociales, clics, etc., los datos ya no utilizan datos relacionales tradicionales. bases de datos En cambio, el almacenamiento utiliza HaDoop Distributed File System (HDFS), S3, Apache Hbase y otros sistemas de almacenamiento de gran capacidad, y también proporcionan una gran cantidad de motores SQL basados ​​en Hadoop (Apache Hive, Apache Dirll) para consultas y procesamiento.

2. Arquitectura de procesamiento de flujo con estado

Todos sabemos que los datos en la vida real se generan continuamente. En el proceso de procesamiento de flujos de eventos, necesitamos respaldar la conversión de múltiples registros y poder almacenar y acceder a resultados intermedios y, a veces, necesidades comerciales al realizar análisis de datos. Es más práctico es el resultado del análisis En el procesamiento de eventos masivos, la arquitectura tradicional de datos transaccionales y la arquitectura ETL son difíciles de soportar. En base a los aspectos anteriores, se ha diseñado una arquitectura de procesamiento de flujo con estado. La arquitectura de procesamiento de flujo con estado (Flink) puede recibir una gran cantidad de solicitudes y, naturalmente, admite la computación paralela, con alto rendimiento y baja latencia, y almacena los resultados intermedios del cálculo localmente o en almacenamiento remoto.Flink también realiza puntos de control regulares (CheckPoint) se escribe en el almacenamiento persistente y la recuperación se realiza de acuerdo con el punto de control durante la recuperación de fallas.

3. Las principales características de Flink

3.1, impulsado por eventos

La gestión de eventos en realidad se toma prestada de la arquitectura transaccional tradicional para recibir solicitudes de eventos (que pueden ser operaciones desencadenadas en tiempo real o medios de almacenamiento de registro de eventos como Kafka, redis, etc.) y almacenar estados intermedios en almacenamiento local o remoto, y finalmente, devuelva los resultados del cálculo para iniciar la operación o escriba en el medio de almacenamiento correspondiente (Mysql, Redis, Kafka, etc.) para que los use el consumidor.

3.2 Visión del mundo basada en el flujo

En el mundo de Flink, existen todos los flujos, que se dividen en flujos limitados y flujos ilimitados. Flujo ilimitado: el comienzo está definido, pero el punto final no está definido, por lo que no hay forma de obtener todos los eventos, lo que requiere que los flujos ilimitados se procesen en tiempo real. para obtener resultados precisos (como la hora del evento). Un flujo ilimitado es un flujo con un punto de inicio y final definido, porque todos los eventos se pueden obtener, por lo que no es necesario definir un orden específico.

3.3 API en capas

Flink proporciona tres capas de API. Cada API ofrece un compromiso diferente entre concisión y expresividad. Cuanto más alto sea el nivel superior, más abstracto, más conciso el significado de la expresión y más cómodo de usar. Cuanto más bajo es el nivel, más específico, más rica la capacidad expresiva y más flexible el uso.

Aquí usamos la API de DataStream para el aprendizaje sistemático A continuación, se incluye una breve introducción al marco de ejecución de Flink
1. Define el entorno de ejecución de Flink.
2. Obtenga datos de la fuente de datos.
3. Realice cálculos de conversión.
4. Salida a la consola.

import org.apache.flink.api.common.functions.FlatMapFunction;
import org.apache.flink.api.java.tuple.Tuple2;
import org.apache.flink.streaming.api.datastream.DataStreamSource;
import org.apache.flink.streaming.api.datastream.SingleOutputStreamOperator;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.util.Collector;

public class SocketTextStreamWordCount {
    public static void main(String[] args) throws Exception {
        //参数检查
        if (args.length != 2) {
            System.err.println("USAGE:\nSocketTextStreamWordCount <hostname> <port>");
            return;
        }

        String hostname = args[0];
        Integer port = Integer.parseInt(args[1]);


        // set up the streaming execution environment
        final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

        //获取数据
        DataStreamSource<String> stream = env.socketTextStream(hostname, port);

        //计数
        SingleOutputStreamOperator<Tuple2<String, Integer>> sum = stream.flatMap(new LineSplitter())
                .keyBy(0)
                .sum(1);

        sum.print();

        env.execute("Java WordCount from SocketTextStream Example");
    }

    public static final class LineSplitter implements FlatMapFunction<String, Tuple2<String, Integer>> {
        @Override
        public void flatMap(String s, Collector<Tuple2<String, Integer>> collector) {
            String[] tokens = s.toLowerCase().split("\\W+");

            for (String token : tokens) {
                if (token.length() > 0) {
                    collector.collect(new Tuple2<String, Integer>(token, 1));
                }
            }
        }
    }
}

3.4, semántica del tiempo

Flink admite las siguientes tres semánticas de tiempo y utiliza el tiempo de procesamiento de forma predeterminada.

@PublicEvolving
public enum TimeCharacteristic {
   ProcessingTime,
   
   IngestionTime,

   EventTime
}

1. Hora del evento: procese los datos de transmisión de acuerdo con la marca de tiempo del evento. La hora del evento y la marca de agua pueden proporcionar resultados de cálculo consistentes y precisos para eventos no ordenados.
2. Tiempo de procesamiento: el tiempo de procesamiento es el momento en que un operador específico recibe un evento y la aplicación que utiliza el tiempo de procesamiento debe requerir un flujo de datos de latencia relativamente baja.
3. Tiempo de ingestión: el tiempo de ingestión es el momento en que el tiempo ingresa a Flink, que generalmente no se usa para el cálculo.

3.5 Procesamiento puntual preciso

Garantías de estado exactamente una vez: los algoritmos de puntos de control y recuperación de Flink garantizan la coherencia del estado de la aplicación en caso de falla.
Por lo tanto, las fallas se manejan de manera transparente y no afectan la corrección de la aplicación.

3.6 Muchas conexiones del sistema de almacenamiento

Flink puede conectarse a muchos medios de almacenamiento. Las fuentes y sumideros comunes incluyen: Apache Kafka, Mysql, Redis, ES, S3, HDFS, etc.

3.7 Otras características

1. Admite configuración de alta disponibilidad: implementación de clústeres de K8s, Yarn, etc.
2. Baja latencia, capaz de manejar millones de eventos por segundo con latencia de milisegundos.
3. Los colegas también admiten el procesamiento por lotes y tienen una API madura (DataSet API).
4. Es compatible con la operación de ventana y proporciona un mecanismo informático maduro para el procesamiento de flujo de datos ilimitado.

Resumir

Apache Flink es un motor de procesamiento de flujo distribuido que proporciona una API intuitiva y expresiva para implementar aplicaciones de procesamiento de flujo con estado y admite el funcionamiento eficiente y a gran escala de dichas aplicaciones bajo la premisa de la tolerancia a fallas. En este artículo, a través de la introducción de varios conceptos del procesamiento de flujo con estado de Flink, tiene una comprensión general de los conceptos y características relevantes. En el próximo artículo, practicaremos y veremos el mecanismo operativo de Flink desde la operación real. Estén atentos. !