Flink SQL defines continuously evaluated queries over streaming data. Instead of returning one final answer, a query produces an ongoing stream of changes. Tables provide a convenient relational view of state, while connected Kafka topics supply the underlying events. section 12.3
A typical Flink SQL workflow connects event topics to tables and then composes relational operations:
- Create a table whose schema describes the event fields and whose connector configuration identifies the Kafka topic, bootstrap server, and JSON format. section 12.3
- Filter records, such as selecting products whose price exceeds 100. section 12.3
- Aggregate changes by key, such as counting price changes for each product. section 12.3
- Split larger flows into views, then join notification events with each user's currently active devices. section 12.4.4
Routing notifications to active devices
An active-device view groups device records by user and collects active device details. A second query joins notifications with that view, producing notification records enriched with the recipient's current device list. The resulting stream can be written to another Kafka topic. section 12.4.4
CREATE TABLE productprices ( product_id INT, product_name STRING, price FLOAT, oldPrice FLOAT ) WITH ( 'connector' = 'kafka', 'topic' = 'products.prices.changelog', 'properties.bootstrap.servers' = 'localhost:9092', 'format' = 'json', 'key.format' = 'json', 'key.fields' = 'product_id', 'value.fields-include' = 'EXCEPT_KEY' );
Use the table definition to inspect how a Kafka topic becomes a typed Flink SQL table, including keys, connector settings, and JSON serialization. section 12.3
