Kafka corriente DSL: retardos de aplicación para la agregación de ventana

SA Manjunath:

Tenemos el siguiente caso de uso:

Leer de un tema (rendimiento esperado es un registro cada 2 segundos durante una clave), groupByKey y hacer una agregación de ventana para la ventana de 30 minutos con el periodo de salto de 1 minuto. La agregación es simplemente anexando de los registros recibidos.

cuando la aplicación se inicia todo funciona bien, pero en las etapas posteriores, cuando el tamaño de los incrementos de los brazos caídos de aplicación y los retrasos agregados

toplogy :

KStream<String, Foo> numericStream = builder.stream("topic", Consumed.with(Serdes.String(), FooSerde));
static Duration WINDOW_MS = Duration.ofMinutes(30);
static Duration ADVANCE_MS = Duration.ofMinutes(15);


KStream<Windowed<String>, Foo1> windowedStream = numericStream.peek((key, value) -> System.out.println(value.getDateTime()))
        .groupByKey()
        .windowedBy((TimeWindows.of(WINDOW_MS).advanceBy(ADVANCE_MS)).grace(Duration.ofMillis(30)))
        .aggregate(new Initializer<Foo1>() {
            @Override
            public  Foo1 apply() {
                return new Foo1();
            }},
                   (key, value, aggregate) -> {
                       aggregate.append(value);
                       return aggregate;
                   },
                   Materialized.<String, Foo1, WindowStore<Bytes,byte[]>>as("some_name").withValueSerde(Foo1Serde))
        .toStream()
        .peek((key, value) -> System.out.println(" Key: "+key+ " Start: "+getISTTime(key.window().start()) + " End: "+ getISTTime(key.window().end()) +" Count: " + value.getCount() ));

tamaño de cada registro es de alrededor de 20 KB. El tiempo de procesamiento para el registro va más allá de 2 segundos cuando el tamaño de agregado pasa por encima de 10 MB alrededor y por lo tanto el retraso.

El COMMIT_INTERVAL_MS_CONFIG se establece en 0 como el almacén de estado debe ser siempre la fecha hasta la última tienda de paquetes y el estado se consulta y diferentes intervalos.

1. ¿Cómo eliminamos el retraso de la aplicación, que es algo relacionado con la operación RocksDB E / S? como operación de conteo en lugar del agregado tiene sin retraso alguno

2. Hay 3 particiones por tema, sin embargo los registros con misma clave va a misma partición, también lo hará el roscado / varias instancias ayuda?

3. También estamos pensando en hacer esto sin de ventanas, no de ventanas crear este tipo de desfases de agregados más grandes?

Bruno Cadonna:

1. Dado que escribe y lee cada vez más grandes de datos que reciba RocksDB, puede reducir la velocidad de procesamiento.

2. Sí, utilizando tres hilos en una instancia o de partida de tres casos con un hilo cada posible que también ayuda en este caso. Con su topología y tres particiones, el procesamiento se distribuye en tres tareas. Si usted tiene sólo una instancia con un hilo, las tres tareas serán a cargo de la misma rosca. Se puede ampliar mediante la especificación de un caso con tres hilos o puede escalar iniciando tres casos con un hilo cada uno en diferentes nodos de computación. Ajustes en el medio como dos casos, uno con dos hilos y el otro con un hilo también funcionaría.

3. Sin windowing, los agregados nunca expira y nunca ser retirado de las tiendas estatales. Por lo tanto, los datos en los almacenes estatales crecerían indefinidamente y probablemente más lento el almacén de estado.

Si utiliza consultas interactivas para consultar el estado de su tienda, usted no necesita fijar COMMIT_INTERVAL_MS_CONFIG a 0, ya que las consultas interactivas también consultar la memoria caché en frente de la tienda de estado. En realidad, el establecimiento de COMMIT_INTERVAL_MS_CONFIG a cero también puede ralentizar el procesamiento, ya que aumenta el disco E / S ya que usted datos de forma continua escribir en el disco.