A streaming query applies SQL continuously to arriving events. Unlike a conventional database query that returns an answer when requested, it produces an ongoing stream of changes, potentially without end. This makes it useful for monitoring a changing product catalog, such as prices arriving through a Kafka topic. section 12.3
Flink SQL connects tables to Kafka topics rather than creating empty, locally stored tables. SQL remains a concise declarative way to filter, count, and aggregate events, while the underlying stream processor maintains state when operations require it. Tables can represent the latest state for querying, whereas streams represent continuous data. section 12.3 section 12.7
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' );
Define a Kafka-backed product-price table in Flink SQL before querying it. section 12.3
Once the source table exists, familiar SQL patterns operate continuously:
- Filter current events with WHERE, such as selecting products whose price exceeds 100. section 12.3
- Group events by product and use COUNT(*) to track the number of price changes. section 12.3
- Store aggregation results as table state when a current result is needed, while emitting changes as new data arrives. section 12.3 section 12.7
Streaming queries are not limited to filters and counts. They can support joins between streams and tables, or between streams using time windows. Production deployments commonly run predefined queries continuously in headless mode and write results to Kafka or another database. section 12.7
