Zpět na domů

Flink real-time JOIN: tabulky 4+2 TB

Článek popisuje implementaci real-time INNER JOIN mezi terabajtovými tabulkami users a domains na Apache Flink. Používá se Table API pro čtení CDC z Kafka a KeyedCoProcessFunction s MapState pro one-to-many spojení. Zajišťuje se O(1) aktualizace výsledku.

Real-time JOIN 6 TB tabulek na Flink: kompletní implementace
Advertisement 728x90

Implementace real-time JOIN pro velké tabulky na Apache Flink: základní přístup

Je nutné zajistit aktualizaci výsledku INNER JOIN mezi tabulkou users (4 TB) a domains (2 TB) v reálném čase. Dotaz vrací user_id, firstname, lastname a domain_name. Tradiční view zatěžují zdroj dat (SI), zatímco jednoduchá materializace přes CDC do DWH nenabízí požadovanou rychlost.

Příklad dat:

users:

Google AdInline article slot

| id | firstname | lastname |

|----|-----------|----------|

| 1 | Egor | Myasnik |

Google AdInline article slot

| 2 | Pavel | Hvastun |

| 3 | Mitya | Volk |

domains:

Google AdInline article slot

| id | user_id | domain_name |

|----|---------|-------------|

| 1 | 1 | Approval |

| 2 | 1 | Rejection |

| 3 | 1 | Stoppage |

| 4 | 3 | Cancellation|

Analýza alternativ

  • Přímý view na SI — nepřijatelné kvůli zatížení OLTP systému.
  • CDC → Kafka → DWH — odlehčuje SI, ale rychlost čtení z DWH je podobná původní. Přidává dvě vrstvy: Kafka a vitrinu.

Oba přístupy nezaručují real-time aktualizace výsledku JOIN.

Architektura na Flink

Řešení: CDC toky do Kafka → Flink Table API → stateful JOIN → sink (konzole pro MVP).

Závislosti Maven

<dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-connector-kafka</artifactId>
    <version>3.2.0-1.19</version>
</dependency>
<dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-sql-client</artifactId>
    <version>1.19</version>
</dependency>
<dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-java</artifactId>
    <version>${flink.version}</version>
</dependency>
<dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-table-planner-loader</artifactId>
    <version>${flink.version}</version>
</dependency>

Modely dat

public class User implements Serializable {
    public Integer id;
    public String firstname;
    public String lastname;
    // getters/setters
    public static User fromRow(Row row) { /* mapper */ }
}

public class Domain implements Serializable {
    public Integer id;
    public Integer user_id;
    public String domain_name;
    // getters/setters
    public static Domain fromRow(Row row) { /* mapper */ }
}

Vytvoření tabulek Kafka

tableEnv.executeSql("CREATE TABLE users (" +
    "`before` ROW<id: INT, firstname: STRING, lastname: STRING>," +
    "`op` STRING," +
    "`after` ROW<id: INT, firstname: STRING, lastname: STRING>," +
    ") WITH (" +
    "'connector' = 'kafka'," +
    "'topic' = 'users_topic'," +
    "'properties.bootstrap.servers' = 'kafka-brokers'," +
    "'properties.group.id' = 'users_consumer_group'," +
    "'scan.startup.mode' = 'earliest'");

DataStream<User> users = tableEnv.toDataStream(tableEnv.from("users")).map(User::fromRow);

// Similarly for domains
tableEnv.executeSql("CREATE TABLE domains (...)");
DataStream<Domain> domains = tableEnv.toDataStream(tableEnv.from("domains")).map(Domain::fromRow);

Implementace stateful JOIN

Spojení toků podle klíče user_id == domain.user_id s použitím KeyedCoProcessFunction:

users
    .connect(domains)
    .keyBy(
        user -> user.id,
        domain -> domain.user_id
    )
    .process(new Join1())
    .print();

KeyedCoProcessFunction

public class Join1 extends KeyedCoProcessFunction<Integer, User, Domain, Output> {
    private MapState<Integer, Domain> domainsState;
    private ValueState<User> usersState;

    @Override
    public void processElement1(User user, Context ctx, Collector<Output> out) throws Exception {
        usersState.update(user);
        for (Domain domain : domainsState.values()) {
            out.collect(new Output(user.id, user.firstname, user.lastname, domain.domain_name));
        }
    }

    @Override
    public void processElement2(Domain domain, Context ctx, Collector<Output> out) throws Exception {
        domainsState.put(domain.id, domain);
        User user = usersState.value();
        if (user != null) {
            out.collect(new Output(user.id, user.firstname, user.lastname, domain.domain_name));
        }
    }

    @Override
    public void open(OpenContext openContext) throws Exception {
        usersState = getRuntimeContext().getState(new ValueStateDescriptor<>("users", User.class));
        domainsState = getRuntimeContext().getMapState(
            new MapStateDescriptor<>("domains", Integer.class, Domain.class));
    }

    public static class Output implements Serializable {
        public Integer user_id;
        public String firstname, lastname, domain_name;
        // constructors/getters/setters
    }
}

MapState zvolen pro domains kvůli one-to-many relaci. Operace se stavem — O(1).

Co je důležité

  • Real-time aktualizace: výsledek JOIN je aktuální při příchodu CDC událostí.
  • Stateful processing: ValueState pro users (1:1), MapState pro domains (1:N).
  • Škálovatelnost: testováno na terabajtových objemech s OLAP sink.
  • Výkon: O(1) přístup ke stavu, nízká latence.
  • Další kroky: zpracování DELETE/UPDATE, RocksDB, vyrovnávání skew.

Doporučení pro produkci

  • Používejte OLAP sink (ClickHouse, Pinot) místo konzole.
  • Zpracovávejte op-flagy z CDC pro správné UPDATE/DELETE.
  • Implementujte RocksDB pro state backend u velkých objemů.
  • Monitorujte key skew a distribuujte partitiony.
  • Testujte škálování na clusteru.

— Editorial Team

Advertisement 728x90

Číst dál