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:
| id | firstname | lastname |
|----|-----------|----------|
| 1 | Egor | Myasnik |
| 2 | Pavel | Hvastun |
| 3 | Mitya | Volk |
domains:
| 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
Zatím žádné komentáře.