Streaming Analytics met Flink: Real-Time Pipelines

Wat is Apache Flink en waarom is het in 2026 relevanter dan ooit?

De wereld draait niet langer op batch-rapporten die elke nacht worden gegenereerd. Fraudedetectie, gepersonaliseerde aanbevelingen, IoT-monitoring, supply-chain optimalisatie — al deze use cases vereisen inzicht in milliseconden, niet in uren. Apache Flink is het open-source framework dat deze verschuiving mogelijk maakt: een gedistribueerd stream-processing systeem dat continue datastroom verwerkt met lage latency, hoge throughput en sterke garanties rondom correctheid.

In 2026 zijn er meerdere redenen waarom Flink prominent op de radar staat van iedere serieuze data engineer:

Hoe werkt Apache Flink van binnen?

Flink's architectuur is opgebouwd rond een aantal kernconcepten die samen zorgen voor schaalbare en betrouwbare stream-verwerking. Voordat we code schrijven, is het essentieel deze concepten te begrijpen.

De kernarchitectuur in vogelvlucht

Tijdconcepten vergeleken

Praktische codevoorbeelden: een end-to-end pipeline

We bouwen een realistische use case: een real-time fraudedetectie pipeline voor een betaalplatform. Events stromen binnen via Kafka; we detecteren verdachte patronen (meerdere transacties binnen 60 seconden boven €500) en schrijven alerts weg naar een Postgres-tabel.

Stap 1: Project setup (Maven / PyFlink)

Voeg de volgende dependencies toe aan je pom.xml:

<dependencies>
  <!-- Flink core -->
  <dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-streaming-java</artifactId>
    <version>1.19.0</version>
  </dependency>

  <!-- Kafka connector -->
  <dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-connector-kafka</artifactId>
    <version>3.1.0-1.19</version>
  </dependency>

  <!-- JDBC connector voor PostgreSQL -->
  <dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-connector-jdbc</artifactId>
    <version>3.1.2-1.19</version>
  </dependency>
</dependencies>

Stap 2: DataStream API — fraudedetectie job

import org.apache.flink.api.common.eventtime.*;
import org.apache.flink.api.common.functions.MapFunction;
import org.apache.flink.connector.kafka.source.KafkaSource;
import org.apache.flink.connector.kafka.source.enumerator.initializer.OffsetsInitializer;
import org.apache.flink.streaming.api.datastream.DataStream;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.streaming.api.windowing.assigners.TumblingEventTimeWindows;
import org.apache.flink.streaming.api.windowing.time.Time;

public class FraudeDetectiePipeline {

    public static void main(String[] args) throws Exception {

        // 1. Execution environment aanmaken
        StreamExecutionEnvironment env = StreamExecutionEnvironment
            .getExecutionEnvironment();

        // Checkpointing elke 10 seconden (exactly-once)
        env.enableCheckpointing(10_000);
        env.getCheckpointConfig()
           .setCheckpointStorage("s3://mijn-bucket/flink-checkpoints");

        // 2. Kafka Source configureren
        KafkaSource<String> kafkaSource = KafkaSource.<String>builder()
            .setBootstrapServers("kafka-broker:9092")
            .setTopics("betalingen")
            .setGroupId("fraude-detector-v1")
            .setStartingOffsets(OffsetsInitializer.latest())
            .setValueOnlyDeserializer(new SimpleStringSchema())
            .build();

        // 3. Stream inlezen met watermark-strategie
        //    Bounded out-of-orderness: events mogen max 5 seconden laat zijn
        WatermarkStrategy<TransactieEvent> watermarkStrategy =
            WatermarkStrategy
                .<TransactieEvent>forBoundedOutOfOrderness(Duration.ofSeconds(5))
                .withTimestampAssigner(
                    (event, ts) -> event.getEventTimestamp()
                );

        DataStream<TransactieEvent> transacties = env
            .fromSource(kafkaSource,
                        WatermarkStrategy.noWatermarks(),
                        "Kafka Betalingen")
            .map(new JsonNaarTransactieMapper())   // JSON deserialisatie
            .assignTimestampsAndWatermarks(watermarkStrategy);

        // 4. Filteren op hoge bedragen en groeperen per gebruiker
        DataStream<FraudeAlert> alerts = transacties
            .filter(t -> t.getBedrag() > 500.0)
            .keyBy(TransactieEvent::getGebruikerId)
            // Tumbeling venster van 60 seconden (event-time)
            .window(TumblingEventTimeWindows.of(Time.seconds(60)))
            .aggregate(new TransactieAggregator())    // telt & somt bedragen
            .filter(agg -> agg.getAantalTransacties() >= 3)  // >= 3 = verdacht
            .map(agg -> new FraudeAlert(
                agg.getGebruikerId(),
                agg.getTotaalBedrag(),
                agg.getVensterEinde(),
                "HOOG_VOLUME_HOOG_BEDRAG"
            ));

        // 5. Wegschrijven naar PostgreSQL (JDBC Sink)
        alerts.addSink(
            JdbcSink.sink(
                "INSERT INTO fraude_alerts " +
                "(gebruiker_id, totaal_bedrag, venster_einde, reden) " +
                "VALUES (?, ?, ?, ?)",
                (stmt, alert) -> {
                    stmt.setString(1, alert.getGebruikerId());
                    stmt.setDouble(2, alert.getTotaalBedrag());
                    stmt.setTimestamp(3, Timestamp.from(alert.getVensterEinde()));
                    stmt.setString(4, alert.getReden());
                },
                JdbcExecutionOptions.builder()
                    .withBatchSize(200)
                    .withBatchIntervalMs(500)
                    .build(),
                new JdbcConnectionOptions.JdbcConnectionOptionsBuilder()
                    .withUrl("jdbc:postgresql://db:5432/analytics")
                    .withDriverName("org.postgresql.Driver")
                    .withUsername("flink_user")
                    .withPassword(System.getenv("DB_PASSWORD"))
                    .build()
            )
        );

        // 6. Job starten
        env.execute("Real-Time Fraude Detectie Pipeline");
    }
}

Stap 3: Dezelfde logica in Flink SQL

Flink SQL laat je hetzelfde in een handvol regels uitdrukken. Ideaal als je team sterker is in SQL dan Java/Python:

-- Kafka source tabel
CREATE TABLE betalingen (
    transactie_id   STRING,
    gebruiker_id    STRING,
    bedrag          DOUBLE,
    valuta          STRING,
    event_time      TIMESTAMP(3),
    WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND
) WITH (
    'connector'                     = 'kafka',
    'topic'                         = 'betalingen',
    'properties.bootstrap.servers'  = 'kafka-broker:9092',
    'properties.group.id'           = 'flink-sql-fraude',
    'scan.startup.mode'             = 'latest-offset',
    'format'                        = 'json'
);

-- PostgreSQL sink tabel
CREATE TABLE fraude_alerts (
    gebruiker_id    STRING,
    totaal_bedrag   DOUBLE,
    aantal          BIGINT,
    venster_start   TIMESTAMP(3),
    venster_einde   TIMESTAMP(3),
    PRIMARY KEY (gebruiker_id, venster_start) NOT ENFORCED
) WITH (
    'connector' = 'jdbc',
    'url'       = 'jdbc:postgresql://db:5432/analytics',
    'table-name'= 'fraude_alerts',
    'username'  = 'flink_user',
    'password'  = '${DB_PASSWORD}'
);

-- Fraude-detectie query met tumbeling venster
INSERT INTO fraude_alerts
SELECT
    gebruiker_id,
    SUM(bedrag)   AS totaal_bedrag,
    COUNT(*)      AS aantal,
    TUMBLE_START(event_time, INTERVAL '60' SECOND) AS venster_start,
    TUMBLE_END  (event_time, INTERVAL '60' SECOND) AS venster_einde
FROM betalingen
WHERE bedrag > 500.0
GROUP BY
    gebruiker_id,
    TUMBLE(event_time, INTERVAL '60' SECOND)
HAVING COUNT(*) >= 3;

Flink vs. de alternatieven

Flink is niet het enige stream-processing framework. Afhankelijk van je use case, teamkennis en infrastructuur kunnen alternatieven een betere keuze zijn. Hier een eerlijke vergelijking:

Best practices voor productie-deployments

Een Flink-job lokaal laten draaien is één ding; hem stabiel, schaalbaar en onderhoudbaar in productie houden is een ander verhaal. Hier zijn de lessen die data engineers leren (soms op de harde manier):

1. State Backend: kies bewust

// RocksDB: geschikt voor grote state (GBs per TaskManager)
env.setStateBackend(new EmbeddedRocksDBStateBackend(true));
// 'true' = incrementele checkpoints (sneller, minder I/O)

// Heap: geschikt voor kleine state, laagste latency
env.setStateBackend(new HashMapStateBackend());

2. Watermark-strategie afstemmen op databronnen

// Stel maximale out-of-orderness in op basis van gemeten vertraging
WatermarkStrategy
    .<MyEvent>forBoundedOutOfOrderness(Duration.ofSeconds(10))
    // Idle partities detecteren (bij lage-volume bronnen essentieel!)
    .withIdleness(Duration.ofMinutes(1));

Vergeet withIdleness() niet bij topics met ongelijkmatig volume. Zonder deze instelling blokkeer je de watermark-voortgang als één Kafka-partitie even stilligt.

3. Backpressure monitoren

Flink's Web UI toont backpressure per operator. Zodra een operator de input niet snel genoeg verwerkt, propageer je druk terug naar de source — wat Kafka-consumer-lag vergroot. Volg altijd:

• Checkpoint-duur: stijgende tijd duidt op te zware state of I/O-bottleneck
• Kafka consumer-lag (per partition): vroegtijdig signaal van ondercapaciteit
• GC-pauzes per TaskManager: verhoog heap of schakel over naar RocksDB
• Restart rate: frequente restarts duiden op data-kwaliteitsproblemen of OOM

4. Stateful upgrades zonder downtime

# Maak een savepoint voor het stoppen van de job
flink savepoint <job-id> s3://mijn-bucket/savepoints/

# Start nieuwe versie vanuit savepoint
flink run \
  -s s3://mijn-bucket/savepoints/savepoint-abc123 \
  -c com.bedrijf.NieuwePipeline \
  pipeline-v2.jar

Savepoints zijn user-triggered snapshots die je kunt gebruiken voor upgrades, A/B-tests en disaster recovery. Verschil met checkpoints: savepoints zijn permanent bewaard en versie-onafhankelijk (zolang operator UID's niet veranderen).

5. Operator UID's altijd expliciet instellen

DataStream<TransactieEvent> gefilterd = transacties
    .filter(t -> t.getBedrag() > 500.0)
    .uid("filter-hoog-bedrag")          // ← VERPLICHT voor savepoint-compatibiliteit
    .name("Filter: bedrag > €500");

DataStream<FraudeAlert> alerts = gefilterd
    .keyBy(TransactieEvent::getGebruikerId)
    .window(TumblingEventTimeWindows.of(Time.seconds(60)))
    .aggregate(new TransactieAggregator())
    .uid("aggregate-per-gebruiker-60s") // ← VERPLICHT
    .name("Aggregeer per gebruiker (60s venster)");

Productie-checklist

Conclusie: wanneer wel en wanneer niet kiezen voor Flink?

Apache Flink is een van de krachtigste tools in het data-engineering arsenaal, maar — zoals elk stuk infrastructuur — past het niet in iedere situatie. Laten we eerlijk zijn over de trade-offs.