Skip to content

ksqlDB Quick Start

This tutorial demonstrates a simple workflow using ksqlDB to write streaming queries against messages in Apache Kafka® in a Docker environment.

To get started, you must start a Kafka cluster, including ZooKeeper, and a Kafka broker. ksqlDB queries messages from this Kafka cluster.

Prerequisites:

  • Docker:
    • Docker version 1.11 or later is installed and running.
    • Docker Compose is installed. Docker Compose is installed by default with Docker for Mac.
    • Docker memory is allocated minimally at 8 GB. When using Docker Desktop for Mac, the default Docker memory allocation is 2 GB. You can change the default allocation to 8 GB in Docker > Preferences > Advanced.
  • Git.
  • Internet connectivity.
  • Ensure you are on an Operating System currently supported by Confluent Platform.
  • wget to get the connector configuration file.

Download the Tutorial and Start ksqlDB

1. Clone the ksqlDB repository.

1
2
git clone https://github.com/confluentinc/ksql.git
cd ksql

2. Switch to the correct branch

Switch to the correct ksqlDB release branch.

1
git checkout 5.5.0-post

3. Launch the tutorial in Docker

Navigate to the ksqlDB repository docs/tutorials/ directory and launch the tutorial in Docker. Depending on your network speed, this may take up to 5-10 minutes.

1
2
cd docs/tutorials/
docker-compose up -d

4. Run the data generator tool

From two separate terminal windows, run the data generator tool to simulate "user" and "pageview" data:

1
2
3
4
5
6
7
8
docker run --network tutorials_default --rm --name datagen-pageviews \
    confluentinc/ksqldb-examples:5.5.0 \
    ksql-datagen \
        bootstrap-server=kafka:39092 \
        quickstart=pageviews \
        format=delimited \
        topic=pageviews \
        msgRate=5 
1
2
3
4
5
6
7
8
docker run --network tutorials_default --rm --name datagen-users \
    confluentinc/ksqldb-examples:5.5.0 \
    ksql-datagen \
        bootstrap-server=kafka:39092 \
        quickstart=users \
        format=avro \
        topic=users \
        msgRate=1 

5. Start the ksqlDB CLI

From the host machine, start ksqlDB CLI:

1
2
3
docker run --network tutorials_default --rm --interactive --tty \
    confluentinc/ksqldb-cli:0.9.0 ksql \
    http://ksql-server:8088

Your output should resemble:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
                  ===========================================
                  =       _              _ ____  ____       =
                  =      | | _____  __ _| |  _ \| __ )      =
                  =      | |/ / __|/ _` | | | | |  _ \      =
                  =      |   <\__ \ (_| | | |_| | |_) |     =
                  =      |_|\_\___/\__, |_|____/|____/      =
                  =                   |_|                   =
                  =  Event Streaming Database purpose-built =
                  =        for stream processing apps       =
                  ===========================================

Copyright 2017-2020 Confluent Inc.

CLI v0.9.0, Server v0.9.0 located at http://ksql-server:8088

Having trouble? Type 'help' (case-insensitive) for a rundown of how things work!

ksql>

Inspect Kafka Topics By Using SHOW and PRINT Statements

ksqlDB enables inspecting Kafka topics and messages in real time.

  • Use the SHOW TOPICS statement to list the available topics in the Kafka cluster.
  • Use the PRINT statement to see a topic's messages as they arrive.

In the ksqlDB CLI, run the following statement:

1
SHOW TOPICS;

Your output should resemble:

1
2
3
4
5
6
 Kafka Topic                 | Partitions | Partition Replicas
--------------------------------------------------------------
 default_ksql_processing_log | 1          | 1
 pageviews                   | 1          | 1
 users                       | 1          | 1
--------------------------------------------------------------

By default, KSQL hides internal and system topics. Use the SHOW ALL TOPICS statement to see the full list of topics in the Kafka cluster:

1
SHOW ALL TOPICS;

Your output should resemble:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
 Kafka Topic                            | Partitions | Partition Replicas 
--------------------------------------------------------------------------
 __confluent.support.metrics            | 1          | 1                  
 _confluent-ksql-default__command_topic | 1          | 1                  
 _confluent-license                     | 1          | 1                  
 _confluent-metrics                     | 12         | 1                  
 default_ksql_processing_log            | 1          | 1                  
 pageviews                              | 1          | 1                  
 users                                  | 1          | 1                  
--------------------------------------------------------------------------

Inspect the users topic by using the PRINT statement:

1
PRINT users;

Note

The PRINT statement is one of the few case-sensitive commands in ksqlDB, even when the topic name is not quoted.

Your output should resemble:

1
2
3
4
5
6
7
    Key format: KAFKA_STRING
    Value format: AVRO
    rowtime: 10/30/18 10:15:51 PM GMT, key: User_1, value: {"registertime":1516754966866,"userid":"User_1","regionid":"Region_9","gender":"MALE"}
    rowtime: 10/30/18 10:15:51 PM GMT, key: User_3, value: {"registertime":1491558386780,"userid":"User_3","regionid":"Region_2","gender":"MALE"}
    rowtime: 10/30/18 10:15:53 PM GMT, key: User_7, value: {"registertime":1514374073235,"userid":"User_7","regionid":"Region_2","gender":"OTHER"}
    rowtime: 10/30/18 10:15:59 PM GMT, key: User_4, value: {"registertime":1510034151376,"userid":"User_4","regionid":"Region_8","gender":"FEMALE"}
    Topic printing ceased

Press Ctrl+C to stop printing messages.

Inspect the pageviews topic by using the PRINT statement:

1
PRINT pageviews;

Your output should resemble:

1
2
3
4
5
6
7
    Key format: KAFKA_BIGINT or KAFKA_DOUBLE
    Format: KAFKA_STRING
    rowtime: 10/23/18 12:24:03 AM PSD, key: 1540254243183, value: 1540254243183,User_9,Page_20
    rowtime: 10/23/18 12:24:03 AM PSD, key: 1540254243617, value: 1540254243617,User_7,Page_47
    rowtime: 10/23/18 12:24:03 AM PSD, key: 1540254243888, value: 1540254243888,User_4,Page_27
    ^Crowtime: 10/23/18 12:24:05 AM PSD, key: 1540254245161, value: 1540254245161,User_9,Page_62
    Topic printing ceased

Press Ctrl+C to stop printing messages.

Note

KsqlDB has determined that the key format is either KAFKA_BIGINT or KAFKA_DOUBLE. KsqlDB has not narrowed it further because it is not possible to rule out either format just by inspecting the key's serialized bytes. In this case we know the key is a BIGINT. For other cases you may know the key type or you may need to speak to the author of the data.

For more information, see ksqlDB Syntax Reference.

Create a Stream and Table

These examples query messages from Kafka topics called pageviews and users using the following schemas:

image

1. Create a ksqlDB stream

Create a stream, named pageviews_original, from the pageviews Kafka topic, specifying the value_format of DELIMITED.

1
2
CREATE STREAM pageviews_original (rowkey bigint key, viewtime bigint, userid varchar, pageid varchar)
  WITH (kafka_topic='pageviews', value_format='DELIMITED');

Your output should resemble:

1
2
3
4
 Message
---------------
 Stream created
---------------

Tip

You can run DESCRIBE pageviews_original; to see the schema for the stream.

2. Create a ksqlDB table

Create a table, named users_original, from the users topic, specifying the value_format of AVRO.

1
CREATE TABLE users_original WITH (kafka_topic='users', value_format='AVRO', key = 'userid');

Your output should resemble:

1
2
3
4
  Message
---------------
  Table created
---------------

Note

You may have noticed the CREATE TABLE did not define the set of columns like the CREATE STREAM statement did. This is because the value format is Avro, and the DataGen tool publishes the Avro schema to Schema Registry. ksqlDB retrieves the schema from Schema Registry and uses this to build the SQL schema for the table. You may still provide the schema if you wish. Until Github issue #4462 is complete, schema inference is only available for the value columns. By default, it is assumed the key schema is a single KAFKA formatted STRING column and is called ROWKEY. It is also possible to supply just the key column in the statement, allowing you to specify the key column type. For example: CREATE TABLE users_original (ROWKEY INT PRIMARY KEY) WITH (...);

Note

The data generated has the same value in the Kafka record's key as the userId field in the value. Specifying key='userId' in the WITH clause above lets ksqlDB know this. ksqlDB uses this information to allow joins against the table to use the more descriptive userId column name, rather than ROWKEY. Joining on either yields the same results. If your data doesn't contain a copy of the key in the value, you can join on ROWKEY.

Tip

You can run DESCRIBE users_original; to see the schema for the Table.

Optional: Show all streams and tables.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
ksql> SHOW STREAMS;

 Stream Name         | Kafka Topic                 | Format    
---------------------------------------------------------------
 KSQL_PROCESSING_LOG | default_ksql_processing_log | JSON      
 PAGEVIEWS_ORIGINAL  | pageviews                   | DELIMITED 
---------------------------------------------------------------

ksql> SHOW TABLES;

 Table Name     | Kafka Topic | Format | Windowed 
--------------------------------------------------
 USERS_ORIGINAL | users       | AVRO   | false    
--------------------------------------------------

Tip

Notice the KSQL_PROCESSING_LOG stream listed in the SHOW STREAMS output? ksqlDB appends messages that describe any issues it encountered while processing your data. If things aren't working as you expect, check the contents of this stream to see if ksqlDB is encountering data errors.

Viewing your data

1. Create a query that returns data from a table

Use SELECT to create a query that returns data from a table. This query includes the LIMIT keyword to limit the number of rows returned in the query result, and the EMIT CHANGES keywords to indicate you that want to stream results back. This is known as a push query. See the queries section for an explanation of the different query types. Note that exact data output may vary because of the randomness of the data generation.

1
SELECT ROWTIME, * from users_original emit changes limit 5;

Your output should resemble:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
+--------------------+--------------+--------------+---------+----------+-------------+
|ROWTIME             |ROWKEY        |REGISTERTIME  |GENDER   |REGIONID  |USERID       |
+--------------------+--------------+--------------+---------+----------+-------------+
|1581077558655       |User_9        |1513529638461 |OTHER    |Region_1  |User_9       |
|1581077561454       |User_7        |1489408314958 |OTHER    |Region_2  |User_7       |
|1581077561654       |User_3        |1511291005264 |MALE     |Region_2  |User_3       |
|1581077561857       |User_4        |1496797956753 |OTHER    |Region_1  |User_4       |
|1581077562858       |User_8        |1489169082491 |FEMALE   |Region_8  |User_8       |
Limit Reached
Query terminated

Note

Note the use of the pseudo column ROWTIME in the above query to access each rows timestamp. ROWTIME is not included by default when the * in the projection is expanded, but can be included explicitly when needed.

Note

Push queries on tables output the full history of the table that is stored in the Kafka changelog topic, which means that it outputs historic data, followed by the stream of updates to the table. So it's likely that rows with matching ROWKEY are output as existing rows in the table are updated.

2. Create a query that returns data from a stream

View the data in your pageviews_original stream by issuing the following push query:

1
SELECT viewtime, userid, pageid FROM pageviews_original emit changes LIMIT 3;

Your output should resemble:

1
2
3
4
5
6
7
8
+--------------+--------------+--------------+
|VIEWTIME      |USERID        |PAGEID        |
+--------------+--------------+--------------+
|1581078296791 |User_1        |Page_54       |
|1581078297792 |User_8        |Page_93       |
|1581078298792 |User_6        |Page_26       |
Limit Reached
Query terminated

Note

By default, push queries on streams only output changes that occur after the query is started, which means that historic data isn't included. Run set 'auto.offset.reset'='earliest'; to update your session properties if you want to see the historic data.

Write Queries

These examples write queries using ksqlDB.

1. Create a query that returns data from a ksqlDB stream

Create a query that enriches the pageviews data with the user's gender and regionid from the users table. The following query enriches the pageviews_original STREAM by doing a LEFT JOIN with the users_original TABLE on the userid column.

1
2
3
4
5
6
SELECT users_original.userid AS userid, pageid, regionid, gender
  FROM pageviews_original
  LEFT JOIN users_original
    ON pageviews_original.userid = users_original.userid
  EMIT CHANGES
  LIMIT 5;

Your output should resemble:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
+-------------------+-------------------+-------------------+-------------------+
|USERID             |PAGEID             |REGIONID           |GENDER             |
+-------------------+-------------------+-------------------+-------------------+
|User_7             |Page_23            |Region_2           |OTHER              |
|User_3             |Page_42            |Region_2           |MALE               |
|User_7             |Page_87            |Region_2           |OTHER              |
|User_2             |Page_57            |Region_5           |FEMALE             |
|User_9             |Page_59            |Region_1           |OTHER              |
Limit Reached
Query terminated

Note

The join to the users table is on the userid column, which was identified as an alias for the table's primary key, ROWKEY, in the CREATE TABLE statement. userId and ROWKEY can be used interchangeably as the join criteria for the table. However, the data in userid on the stream side does not match the stream's key. Hence, ksqlDB internally repartitions the stream by the userId column before performing the join.

2. Create a persistent query

Create a persistent query by using the CREATE STREAM keywords to precede the SELECT statement and removing the LIMIT clause. The results from this query are written to the PAGEVIEWS_ENRICHED Kafka topic.

1
2
3
4
5
6
CREATE STREAM pageviews_enriched AS
  SELECT users_original.userid AS userid, pageid, regionid, gender
  FROM pageviews_original
  LEFT JOIN users_original
    ON pageviews_original.userid = users_original.userid
  EMIT CHANGES;

Your output should resemble:

1
2
3
4
 Message                                                                                                  
----------------------------------------------------------------------------------------------------------
 Stream PAGEVIEWS_ENRICHED created and running. Created by query with query ID: CSAS_PAGEVIEWS_ENRICHED_0 
----------------------------------------------------------------------------------------------------------

Tip

You can run DESCRIBE pageviews_enriched; to describe the stream.

3. View query results

Use SELECT to view query results as they come in. To stop viewing the query results, press Ctrl-C. This stops printing to the console but it does not terminate the actual query. The query continues to run in the underlying ksqlDB application.

1
SELECT * FROM pageviews_enriched emit changes;

Your output should resemble:

1
2
3
4
5
6
7
8
+------------+------------+------------+------------+------------+
|ROWKEY      |USERID      |PAGEID      |REGIONID    |GENDER      |
+------------+------------+------------+------------+------------+
|User_5      |User_5      |Page_53     |Region_3    |FEMALE      |
|User_2      |User_2      |Page_86     |Region_5    |OTHER       |
|User_9      |User_9      |Page_75     |Region_1    |OTHER       |

^CQuery terminated

Use CTRL+C to terminate the query.

4. Create a filter query

Create a new persistent query where a condition limits the streams content, using WHERE. Results from this query are written to a Kafka topic called PAGEVIEWS_FEMALE.

1
2
3
4
CREATE STREAM pageviews_female AS
  SELECT * FROM pageviews_enriched
  WHERE gender = 'FEMALE'
  EMIT CHANGES;

Your output should resemble:

1
2
3
4
 Message                                                                                               
-------------------------------------------------------------------------------------------------------
 Stream PAGEVIEWS_FEMALE created and running. Created by query with query ID: CSAS_PAGEVIEWS_FEMALE_11 
-------------------------------------------------------------------------------------------------------

Tip

You can run DESCRIBE pageviews_female; to describe the stream.

5. Create a LIKE query

Create a new persistent query where another condition is met, using LIKE. Results from this query are written to the pageviews_enriched_r8_r9 Kafka topic.

1
2
3
4
5
CREATE STREAM pageviews_female_like_89
  WITH (kafka_topic='pageviews_enriched_r8_r9') AS
  SELECT * FROM pageviews_female
  WHERE regionid LIKE '%_8' OR regionid LIKE '%_9'
  EMIT CHANGES;

Your output should resemble:

1
2
3
4
 Message                                                                                                               
-----------------------------------------------------------------------------------------------------------------------
 Stream PAGEVIEWS_FEMALE_LIKE_89 created and running. Created by query with query ID: CSAS_PAGEVIEWS_FEMALE_LIKE_89_13 
-----------------------------------------------------------------------------------------------------------------------

6. Count and group pageview events

Create a new persistent query that counts the pageviews for each region and gender combination in a tumbling window of 30 seconds when the count is greater than one. Results from this query are written to the PAGEVIEWS_REGIONS Kafka topic in the Avro format. ksqlDB registers the Avro schema with the configured Schema Registry when it writes the first message to the PAGEVIEWS_REGIONS topic.

1
2
3
4
5
6
7
CREATE TABLE pageviews_regions
 WITH (VALUE_FORMAT='avro') AS
SELECT gender, regionid , COUNT(*) AS numusers
FROM pageviews_enriched
  WINDOW TUMBLING (size 30 second)
GROUP BY gender, regionid
EMIT CHANGES;

Your output should resemble:

1
2
3
4
 Message                                                                                                
--------------------------------------------------------------------------------------------------------
 Table PAGEVIEWS_REGIONS created and running. Created by query with query ID: CTAS_PAGEVIEWS_REGIONS_15 
--------------------------------------------------------------------------------------------------------

Tip

You can run DESCRIBE pageviews_regions; to describe the table.

7. View query results using a push query

View results from the previous queries by using the SELECT statement.

1
SELECT * FROM pageviews_regions EMIT CHANGES LIMIT 5;

Your output should resemble:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
+-----------------+---------------+---------------+---------------+---------------+---------------+
|ROWKEY           |WINDOWSTART    |WINDOWEND      |GENDER         |REGIONID       |NUMUSERS       |
+-----------------+---------------+---------------+---------------+---------------+---------------+
|OTHER|+|Region_9 |1581080490000  |1581080520000  |OTHER          |Region_9       |1              |
|OTHER|+|Region_5 |1581080490000  |1581080520000  |OTHER          |Region_5       |2              |
|MALE|+|Region_7  |1581080490000  |1581080520000  |MALE           |Region_7       |4              |
|FEMALE|+|Region_1|1581080490000  |1581080520000  |FEMALE         |Region_1       |2              |
|MALE|+|Region_2  |1581080490000  |1581080520000  |MALE           |Region_2       |3              |
Limit Reached
Query terminated

Note

Notice the addition of the WINDOWSTART and WINDOWEND columns. These are available because pageviews_regions is aggregating data per 30 second window. ksqlDB automatically adds these system columns for windowed results.

Note

The grouping columns gender and regionid are currently stored combined in a single key column. This will be rectified once multiple key columns are supported. Until then, these columns are combined and the resulting column is given a system-generated column name.

8. View query results using a pull query

When a CREATE TABLE statement contains a GROUP BY clause, ksqlDB builds an internal table containing the results of the aggregation. ksqlDB supports pull queries against such aggregation results.

Unlike the push query used in the previous step, which pushes a stream of results to you, pull queries pull a result set and automatically terminate.

Pull queries do not have the EMIT CHANGES clause.

View all of the windows and user counts that are available for a specific gender and region by using a pull query:

1
SELECT * FROM pageviews_regions WHERE ROWKEY='OTHER|+|Region_9';

Your output should resemble:

1
2
3
4
5
6
7
8
9
+------------------+------------------+------------------+------------------+------------------+------------------+
|ROWKEY            |WINDOWSTART       |WINDOWEND         |GENDER            |REGIONID          |NUMUSERS          |
+------------------+------------------+------------------+------------------+------------------+------------------+
|OTHER|+|Region_9  |1581080490000     |1581080520000     |OTHER             |Region_9          |1                 |
|OTHER|+|Region_9  |1581080550000     |1581080580000     |OTHER             |Region_9          |4                 |
|OTHER|+|Region_9  |1581080580000     |1581080610000     |OTHER             |Region_9          |4                 |
|OTHER|+|Region_9  |1581080610000     |1581080640000     |OTHER             |Region_9          |3                 |
|OTHER|+|Region_9  |1581080640000     |1581080670000     |OTHER             |Region_9          |6                 |
...

Pull queries on windowed tables such as pageviews_regions also support querying a single window's result:

1
SELECT NUMUSERS FROM pageviews_regions WHERE ROWKEY='OTHER|+|Region_9' AND WINDOWSTART=1581080550000;

Important

You must change the value of WINDOWSTART in the above SQL to match one of the window boundaries in your data. Otherwise no results will be returned.

Your output should resemble:

1
2
3
4
5
+----------+
|NUMUSERS  |
+----------+
|4         |
Query terminated

Or querying a range of windows:

1
SELECT WINDOWSTART, WINDOWEND, NUMUSERS FROM pageviews_regions WHERE ROWKEY='OTHER|+|Region_9' AND 1581080550000 <= WINDOWSTART AND WINDOWSTART <= 1581080610000;

Important

You must change the value of WINDOWSTART in the above SQL to match one of the window boundaries in your data. Otherwise no results will be returned.

Your output should resemble:

1
2
3
4
5
6
7
+----------------------------+----------------------------+----------------------------+
|WINDOWSTART                 |WINDOWEND                   |NUMUSERS                    |
+----------------------------+----------------------------+----------------------------+
|1581080550000               |1581080580000               |4                           |
|1581080580000               |1581080610000               |4                           |
|1581080610000               |1581080640000               |3                           |
Query terminated

9. View persistent queries

Show the running persistent queries:

1
SHOW QUERIES;

Your output should resemble:

1
2
3
4
5
6
7
8
 Query ID                         | Status  | Sink Name                | Sink Kafka Topic         | Query String                                                                                                                                                                                                                                                                                                                                                                                                 
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 CTAS_PAGEVIEWS_REGIONS_15        | RUNNING | PAGEVIEWS_REGIONS        | PAGEVIEWS_REGIONS        | CREATE TABLE PAGEVIEWS_REGIONS WITH (KAFKA_TOPIC='PAGEVIEWS_REGIONS', PARTITIONS=1, REPLICAS=1, VALUE_FORMAT='avro') AS SELECT  PAGEVIEWS_ENRICHED.GENDER GENDER,  PAGEVIEWS_ENRICHED.REGIONID REGIONID,  COUNT(*) NUMUSERSFROM PAGEVIEWS_ENRICHED PAGEVIEWS_ENRICHEDWINDOW TUMBLING ( SIZE 30 SECONDS ) GROUP BY PAGEVIEWS_ENRICHED.GENDER, PAGEVIEWS_ENRICHED.REGIONIDEMIT CHANGES;                        
 CSAS_PAGEVIEWS_FEMALE_LIKE_89_13 | RUNNING | PAGEVIEWS_FEMALE_LIKE_89 | pageviews_enriched_r8_r9 | CREATE STREAM PAGEVIEWS_FEMALE_LIKE_89 WITH (KAFKA_TOPIC='pageviews_enriched_r8_r9', PARTITIONS=1, REPLICAS=1) AS SELECT *FROM PAGEVIEWS_FEMALE PAGEVIEWS_FEMALEWHERE ((PAGEVIEWS_FEMALE.REGIONID LIKE '%_8') OR (PAGEVIEWS_FEMALE.REGIONID LIKE '%_9'))EMIT CHANGES;                                                                                                                                        
 CSAS_PAGEVIEWS_ENRICHED_0        | RUNNING | PAGEVIEWS_ENRICHED       | PAGEVIEWS_ENRICHED       | CREATE STREAM PAGEVIEWS_ENRICHED WITH (KAFKA_TOPIC='PAGEVIEWS_ENRICHED', PARTITIONS=1, REPLICAS=1) AS SELECT  USERS_ORIGINAL.USERID USERID,  PAGEVIEWS_ORIGINAL.PAGEID PAGEID,  USERS_ORIGINAL.REGIONID REGIONID,  USERS_ORIGINAL.GENDER GENDERFROM PAGEVIEWS_ORIGINAL PAGEVIEWS_ORIGINALLEFT OUTER JOIN USERS_ORIGINAL USERS_ORIGINAL ON ((PAGEVIEWS_ORIGINAL.USERID = USERS_ORIGINAL.USERID))EMIT CHANGES; 
 CSAS_PAGEVIEWS_FEMALE_11         | RUNNING | PAGEVIEWS_FEMALE         | PAGEVIEWS_FEMALE         | CREATE STREAM PAGEVIEWS_FEMALE WITH (KAFKA_TOPIC='PAGEVIEWS_FEMALE', PARTITIONS=1, REPLICAS=1) AS SELECT *FROM PAGEVIEWS_ENRICHED PAGEVIEWS_ENRICHEDWHERE (PAGEVIEWS_ENRICHED.GENDER = 'FEMALE')EMIT CHANGES;                                                                                              

For detailed information on a Query run: EXPLAIN <Query ID>;

10. Examine query run-time metrics and details

Observe that information including the target Kafka topic is available, as well as throughput figures for the messages being processed.

1
DESCRIBE EXTENDED PAGEVIEWS_REGIONS;

Your output should resemble:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Name                 : PAGEVIEWS_REGIONS
Type                 : TABLE
Key field            : 
Timestamp field      : Not set - using <ROWTIME>
Key format           : KAFKA
Value format         : AVRO
Kafka topic          : PAGEVIEWS_REGIONS (partitions: 1, replication: 1)
Statement            : CREATE TABLE PAGEVIEWS_REGIONS WITH (KAFKA_TOPIC='PAGEVIEWS_REGIONS', PARTITIONS=1, REPLICAS=1, VALUE_FORMAT='json') AS SELECT
  PAGEVIEWS_ENRICHED.GENDER GENDER,
  PAGEVIEWS_ENRICHED.REGIONID REGIONID,
  COUNT(*) NUMUSERS
FROM PAGEVIEWS_ENRICHED PAGEVIEWS_ENRICHED
WINDOW TUMBLING ( SIZE 30 SECONDS ) 
GROUP BY PAGEVIEWS_ENRICHED.GENDER, PAGEVIEWS_ENRICHED.REGIONID
EMIT CHANGES;

 Field    | Type                                              
--------------------------------------------------------------
 ROWKEY   | VARCHAR(STRING)  (key) (Window type: TUMBLING)
 GENDER   | VARCHAR(STRING)                                   
 REGIONID | VARCHAR(STRING)                                   
 NUMUSERS | BIGINT                                            
--------------------------------------------------------------

Queries that write from this TABLE
-----------------------------------
CTAS_PAGEVIEWS_REGIONS_15 (RUNNING) : CREATE TABLE PAGEVIEWS_REGIONS WITH (KAFKA_TOPIC='PAGEVIEWS_REGIONS', PARTITIONS=1, REPLICAS=1, VALUE_FORMAT='json') AS SELECT  PAGEVIEWS_ENRICHED.GENDER GENDER,  PAGEVIEWS_ENRICHED.REGIONID REGIONID,  COUNT(*) NUMUSERSFROM PAGEVIEWS_ENRICHED PAGEVIEWS_ENRICHEDWINDOW TUMBLING ( SIZE 30 SECONDS ) GROUP BY PAGEVIEWS_ENRICHED.GENDER, PAGEVIEWS_ENRICHED.REGIONIDEMIT CHANGES;

For query topology and execution plan please run: EXPLAIN <QueryId>

Local runtime statistics
------------------------
messages-per-sec:      0.90   total-messages:       498     last-message: 2020-02-07T13:10:32.033Z

Use Nested Schemas (STRUCT) in ksqlDB

Struct support enables the modeling and access of nested data in Kafka topics, from JSON, Avro, and Protobuf.

1. Generate data

In this section, you use the ksql-datagen tool to create some sample data that includes a nested address field. Run this in a new window, and leave it running.

1
2
3
4
5
6
7
8
docker run --network tutorials_default --rm  \
  confluentinc/ksqldb-examples:0.9.0 \
  ksql-datagen \
      quickstart=orders \
      format=json \
      topic=orders \
      msgRate=5 \
      bootstrap-server=kafka:39092

2. Register a stream

From the ksqlDB command prompt, register the a stream on the orders topic:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
CREATE STREAM ORDERS 
 (
   ROWKEY INT KEY, 
   ORDERTIME BIGINT, 
   ORDERID INT, 
   ITEMID STRING, 
   ORDERUNITS DOUBLE, 
   ADDRESS STRUCT<CITY STRING, STATE STRING, ZIPCODE BIGINT>
 )
   WITH (KAFKA_TOPIC='orders', VALUE_FORMAT='json', key='orderid');

Your output should resemble:

1
2
3
4
 Message
----------------
 Stream created
----------------

3. Observe the stream's schema

Use the DESCRIBE function to observe the schema, which includes a STRUCT:

1
DESCRIBE ORDERS;

Your output should resemble:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Name                 : ORDERS
 Field      | Type
----------------------------------------------------------------------------------
 ROWKEY     | INT              (key)
 ORDERTIME  | BIGINT
 ORDERID    | INTEGER
 ITEMID     | VARCHAR(STRING)
 ORDERUNITS | DOUBLE
 ADDRESS    | STRUCT<CITY VARCHAR(STRING), STATE VARCHAR(STRING), ZIPCODE BIGINT>
----------------------------------------------------------------------------------
For runtime statistics and query details run: DESCRIBE EXTENDED <Stream,Table>;
ksql>

4. Access the struct data

Query the data by using the -> notation to access the struct contents:

1
SELECT ORDERID, ADDRESS->CITY FROM ORDERS EMIT CHANGES LIMIT 5;

Your output should resemble:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
+-----------------------------------+-----------------------------------+
|ORDERID                            |ADDRESS__CITY                      |
+-----------------------------------+-----------------------------------+
|1188                               |City_95                            |
|1189                               |City_24                            |
|1190                               |City_57                            |
|1191                               |City_37                            |
|1192                               |City_82                            |
Limit Reached
Query terminated

Stream-Stream join

Using a stream-stream join, you can join two event streams on a common key. An example of this could be a stream of order events and a stream of shipment events. By joining these on the order key, you can see shipment information alongside the order.

1. Create two streams

In the ksqlDB CLI create two new streams. Both streams will store their order ID in ROWKEY:

1
2
3
4
5
CREATE STREAM NEW_ORDERS (ROWKEY INT KEY, TOTAL_AMOUNT DOUBLE, CUSTOMER_NAME VARCHAR)
WITH (KAFKA_TOPIC='new_orders', VALUE_FORMAT='JSON', PARTITIONS=2);

CREATE STREAM SHIPMENTS (ROWKEY INT KEY, SHIPMENT_ID INT, WAREHOUSE VARCHAR)
WITH (KAFKA_TOPIC='shipments', VALUE_FORMAT='JSON', PARTITIONS=2);

Note

ksqlDB creates the underlying topics in Kafka when it executes these statements. You can also specify the REPLICAS count.

After both CREATE STREAM statements, your output should resemble:

1
2
3
4
 Message
----------------
 Stream created
----------------

2. Populate two source topics

Populate the streams with some sample data by using the INSERT VALUES statement:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
-- Insert values in NEW_ORDERS:
-- insert supplying the list of columns to insert:
INSERT INTO NEW_ORDERS (ROWKEY, CUSTOMER_NAME, TOTAL_AMOUNT) 
  VALUES (1, 'Bob Smith', 10.50);

-- shorthand version can be used when inserting values for all columns, (except ROWTIME), in column order:
INSERT INTO NEW_ORDERS  VALUES (2, 3.32, 'Sarah Black');
INSERT INTO NEW_ORDERS  VALUES (3, 21.00, 'Emma Turner');

-- Insert values in SHIPMENTS:
INSERT INTO SHIPMENTS VALUES (1, 42, 'Nashville');
INSERT INTO SHIPMENTS VALUES (3, 43, 'Palo Alto');

3. Set the auto.offset.reset property

Run the following statement to tell ksqlDB to read from the beginning of all streams:

1
SET 'auto.offset.reset' = 'earliest';

Tip

You can skip this step if you've already run it within your current ksqlDB CLI session.

4. Examine streams for events

Query the streams to confirm that events are present in the topics.

For the NEW_ORDERS stream, run:

1
SELECT ROWTIME, * FROM NEW_ORDERS EMIT CHANGES LIMIT 3;

Your output should resemble:

1
2
3
4
5
6
7
8
+-------------------------+-------------------------+-------------------------+-------------------------+
|ROWTIME                  |ROWKEY                   |TOTAL_AMOUNT             |CUSTOMER_NAME            |
+-------------------------+-------------------------+-------------------------+-------------------------+
|1581083057609            |1                        |10.5                     |Bob Smith                |
|1581083178418            |2                        |3.32                     |Sarah Black              |
|1581083210494            |3                        |21.0                     |Emma Turner              |
Limit Reached
Query terminated

For the SHIPMENTS stream, run:

1
SELECT * FROM SHIPMENTS EMIT CHANGES LIMIT 2;

Your output should resemble:

1
2
3
4
5
6
7
+-------------------------+-------------------------+-------------------------+
|ROWKEY                   |SHIPMENT_ID              |WAREHOUSE                |
+-------------------------+-------------------------+-------------------------+
|1                        |42                       |Nashville                |
|3                        |43                       |Palo Alto                |
Limit Reached
Query terminated

5. Join the streams

Run the following query, which will show orders with associated shipments, based on a join window of 1 hour.

1
2
3
4
5
6
7
SELECT O.ROWKEY AS ORDER_ID, O.TOTAL_AMOUNT, O.CUSTOMER_NAME,
S.SHIPMENT_ID, S.WAREHOUSE
FROM NEW_ORDERS O
INNER JOIN SHIPMENTS S
  WITHIN 1 HOURS
  ON O.ROWKEY = S.ROWKEY
EMIT CHANGES;

Your output should resemble:

1
2
3
4
5
+--------------------------+--------------------------+--------------------------+--------------------------+--------------------------+
|ORDER_ID                  |TOTAL_AMOUNT              |CUSTOMER_NAME             |SHIPMENT_ID               |WAREHOUSE                 |
+--------------------------+--------------------------+--------------------------+--------------------------+--------------------------+
|1                         |10.5                      |Bob Smith                 |42                        |Nashville                 |
|3                         |21.0                      |Emma Turner               |43                        |Palo Alto                 |

Messages with ORDER_ID=2 have no corresponding SHIPMENT_ID or WAREHOUSE. This is because there's no corresponding row on the SHIPMENTS stream within the time window specified.

Start the ksqlDB CLI in a second window by running:

1
2
3
docker run --network tutorials_default --rm --interactive --tty \
    confluentinc/ksqldb-cli:0.9.0 ksql \
    http://ksql-server:8088

Enter the following INSERT VALUES statement to insert the shipment for order id 2:

1
INSERT INTO SHIPMENTS VALUES (2, 49, 'London');

Switching back to your primary ksqlDB CLI window, notice that a third row has now been output:

1
2
3
4
5
6
+--------------------------+--------------------------+--------------------------+--------------------------+--------------------------+
|ORDER_ID                  |TOTAL_AMOUNT              |CUSTOMER_NAME             |SHIPMENT_ID               |WAREHOUSE                 |
+--------------------------+--------------------------+--------------------------+--------------------------+--------------------------+
|1                         |10.5                      |Bob Smith                 |42                        |Nashville                 |
|3                         |21.0                      |Emma Turner               |43                        |Palo Alto                 |
|2                         |3.32                      |Sarah Black               |49                        |London                    |

Press Ctrl+C to cancel the SELECT query and return to the prompt.

Table-Table join

Using a table-table join, it's possible to join two tables of on a common key. ksqlDB tables provide the latest value for a given key. They can only be joined on the key, and one-to-many (1:N) joins are not supported in the current semantic model.

In this example, location data about a warehouse from one system is enriched with data about the size of the warehouse from another.

1. Register two tables

In the KSQL CLI, register both topics as KSQL tables. Note, in this example the warehouse id is stored both in the key and in the WAREHOUSE_ID field in the value:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
CREATE TABLE WAREHOUSE_LOCATION 
   (ROWKEY INT PRIMARY KEY, WAREHOUSE_ID INT, CITY VARCHAR, COUNTRY VARCHAR)
   WITH (KAFKA_TOPIC='warehouse_location',
      VALUE_FORMAT='JSON',
      KEY='WAREHOUSE_ID',
      PARTITIONS=2);

CREATE TABLE WAREHOUSE_SIZE 
   (ROWKEY INT PRIMARY KEY, WAREHOUSE_ID INT, SQUARE_FOOTAGE DOUBLE)
   WITH (KAFKA_TOPIC='warehouse_size',
      VALUE_FORMAT='JSON',
      KEY='WAREHOUSE_ID',
      PARTITIONS=2);

After both CREATE TABLE statements, your output should resemble:

1
2
3
4
 Message
---------------
 Table created
---------------

2. Populate two source topics

In the KSQL CLI, insert sample data into the tables:

1
2
3
4
5
6
7
8
-- note: ksqlDB will automatically populate ROWKEY with the same value as WAREHOUSE_ID:
INSERT INTO WAREHOUSE_LOCATION (WAREHOUSE_ID, CITY, COUNTRY) VALUES (1, 'Leeds', 'UK');
INSERT INTO WAREHOUSE_LOCATION (WAREHOUSE_ID, CITY, COUNTRY) VALUES (2, 'Sheffield', 'UK');
INSERT INTO WAREHOUSE_LOCATION (WAREHOUSE_ID, CITY, COUNTRY) VALUES (3, 'Berlin', 'Germany');

INSERT INTO WAREHOUSE_SIZE (WAREHOUSE_ID, SQUARE_FOOTAGE) VALUES (1, 16000);
INSERT INTO WAREHOUSE_SIZE (WAREHOUSE_ID, SQUARE_FOOTAGE) VALUES (2, 42000);
INSERT INTO WAREHOUSE_SIZE (WAREHOUSE_ID, SQUARE_FOOTAGE) VALUES (3, 94000);

3. Examine tables for keys

Check both tables that the message key (ROWKEY) matches the declared key (WAREHOUSE_ID). The output should show that they are equal. If they were not, the join won't succeed or behave as expected.

Inspect the WAREHOUSE_LOCATION table:

1
SELECT ROWKEY, WAREHOUSE_ID FROM WAREHOUSE_LOCATION EMIT CHANGES LIMIT 3;

Your output should resemble:

1
2
3
4
5
6
7
8
+---------------------------------------+---------------------------------------+
|ROWKEY                                 |WAREHOUSE_ID                           |
+---------------------------------------+---------------------------------------+
|2                                      |2                                      |
|1                                      |1                                      |
|3                                      |3                                      |
Limit Reached
Query terminated

Inspect the WAREHOUSE_SIZE table:

1
SELECT ROWKEY, WAREHOUSE_ID FROM WAREHOUSE_SIZE EMIT CHANGES LIMIT 3;

Your output should resemble:

1
2
3
4
5
6
7
8
+---------------------------------------+---------------------------------------+
|ROWKEY                                 |WAREHOUSE_ID                           |
+---------------------------------------+---------------------------------------+
|2                                      |2                                      |
|1                                      |1                                      |
|3                                      |3                                      |
Limit Reached
Query terminated

4. Join the tables

Now join the two tables:

1
2
3
4
5
6
SELECT WL.WAREHOUSE_ID, WL.CITY, WL.COUNTRY, WS.SQUARE_FOOTAGE
FROM WAREHOUSE_LOCATION WL
  LEFT JOIN WAREHOUSE_SIZE WS
    ON WL.WAREHOUSE_ID=WS.WAREHOUSE_ID
EMIT CHANGES
LIMIT 3;

Your output should resemble:

1
2
3
4
5
6
7
8
+------------------+------------------+------------------+------------------+
|WL_WAREHOUSE_ID   |CITY              |COUNTRY           |SQUARE_FOOTAGE    |
+------------------+------------------+------------------+------------------+
|1                 |Leeds             |UK                |16000.0           |
|1                 |Leeds             |UK                |16000.0           |
|2                 |Sheffield         |UK                |42000.0           |
Limit Reached
Query terminated

INSERT INTO

The INSERT INTO syntax can be used to merge the contents of multiple streams. An example of this could be where the same event type is coming from different sources.

1. Generate data

Run two datagen processes, each writing to a different topic, simulating order data arriving from a local installation vs from a third-party:

1
2
3
4
5
6
7
8
docker run --network tutorials_default --rm  --name datagen-orders-local \
  confluentinc/ksqldb-examples:0.9.0 \
  ksql-datagen \
      quickstart=orders \
      format=json \
      topic=orders_local \
      msgRate=2 \
      bootstrap-server=kafka:39092
1
2
3
4
5
6
7
8
docker run --network tutorials_default --rm --name datagen-orders_3rdparty \
  confluentinc/ksqldb-examples:0.9.0 \
  ksql-datagen \
      quickstart=orders \
      format=json \
      topic=orders_3rdparty \
      msgRate=2 \
      bootstrap-server=kafka:39092

2. Register streams

In ksqlDB, register the source topic for each:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
CREATE STREAM ORDERS_SRC_LOCAL
 (
   ROWKEY INT KEY, 
   ORDERTIME BIGINT, 
   ORDERID INT, 
   ITEMID STRING, 
   ORDERUNITS DOUBLE, 
   ADDRESS STRUCT<CITY STRING, STATE STRING, ZIPCODE BIGINT>
 )
  WITH (KAFKA_TOPIC='orders_local', VALUE_FORMAT='JSON');

CREATE STREAM ORDERS_SRC_3RDPARTY
 (
   ROWKEY INT KEY, 
   ORDERTIME BIGINT, 
   ORDERID INT, 
   ITEMID STRING, 
   ORDERUNITS DOUBLE, 
   ADDRESS STRUCT<CITY STRING, STATE STRING, ZIPCODE BIGINT>
 )
  WITH (KAFKA_TOPIC='orders_3rdparty', VALUE_FORMAT='JSON');

After each CREATE STREAM statement you should get the message:

1
2
3
4
 Message
----------------
 Stream created
----------------

3. Create a persistent query

Create the output stream, using the standard CREATE STREAM … AS syntax. Because multiple sources of data are being joined into a common target, it is useful to add in lineage information. This can be done by simply including it as part of the SELECT:

1
CREATE STREAM ALL_ORDERS AS SELECT 'LOCAL' AS SRC, * FROM ORDERS_SRC_LOCAL EMIT CHANGES;

Your output should resemble:

1
2
3
4
 Message                                                                                   
-------------------------------------------------------------------------------------------
 Stream ALL_ORDERS created and running. Created by query with query ID: CSAS_ALL_ORDERS_17 
-------------------------------------------------------------------------------------------

4. Examine the stream's schema

Use the DESCRIBE command to observe the schema of the target stream.

1
DESCRIBE ALL_ORDERS;

Your output should resemble:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Name                 : ALL_ORDERS
 Field      | Type                                                                
----------------------------------------------------------------------------------
 ROWKEY     | INTEGER          (key)
 SRC        | VARCHAR(STRING)                                                     
 ORDERTIME  | BIGINT                                                              
 ORDERID    | INTEGER                                                             
 ITEMID     | VARCHAR(STRING)                                                     
 ORDERUNITS | DOUBLE                                                              
 ADDRESS    | STRUCT<CITY VARCHAR(STRING), STATE VARCHAR(STRING), ZIPCODE BIGINT> 
----------------------------------------------------------------------------------
For runtime statistics and query details run: DESCRIBE EXTENDED <Stream,Table>;

5. Insert another stream

Add a stream of 3rd-party orders into the existing output stream:

1
INSERT INTO ALL_ORDERS SELECT '3RD PARTY' AS SRC, * FROM ORDERS_SRC_3RDPARTY EMIT CHANGES;

Your output should resemble:

1
2
3
4
 Message                                                    
------------------------------------------------------------
 Insert Into query is running with query ID: INSERTQUERY_43
------------------------------------------------------------

6. Query the output stream

Query the output stream to verify that data from each source is being written to it:

1
SELECT * FROM ALL_ORDERS EMIT CHANGES;

Your output should resemble:

1
2
3
4
5
6
7
+----------+-----------+--------------+----------+-------------+----------------------+---------------------------------------------+
|ROWKEY    |SRC        |ORDERTIME     |ORDERID   |ITEMID       |ORDERUNITS            |ADDRESS                                      |
+----------+-----------+--------------+----------+-------------+----------------------+---------------------------------------------+
|510       |3RD PARTY  |1503198352036 |510       |Item_643     |1.653210222047296     |{CITY=City_94, STATE=State_72, ZIPCODE=61274}|
|546       |LOCAL      |1498476865306 |546       |Item_234     |9.284691223615178     |{CITY=City_44, STATE=State_29, ZIPCODE=84678}|
|511       |3RD PARTY  |1489945722538 |511       |Item_264     |8.213163488516212     |{CITY=City_36, STATE=State_13, ZIPCODE=44821}|
…

Events from both source topics are present, denoted by LOCAL and 3RD PARTY respectively.

Press Ctrl+C to cancel the SELECT query and return to the ksqlDB prompt.

7. View the queries

You can view the two queries that are running using SHOW QUERIES:

1
SHOW QUERIES;

Your output should resemble:

1
2
3
4
5
 Query ID                         | Status  | Sink Name                | Sink Kafka Topic         | Query String                                                                                                                                                                                                                                                                                                                                                                                                 
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 INSERTQUERY_43                   | RUNNING | ALL_ORDERS               | ALL_ORDERS               | INSERT INTO ALL_ORDERS SELECT '3RD PARTY' AS SRC, * FROM ORDERS_SRC_3RDPARTY EMIT CHANGES;
 CSAS_ALL_ORDERS_17               | RUNNING | ALL_ORDERS               | ALL_ORDERS               | CREATE STREAM ALL_ORDERS WITH (KAFKA_TOPIC='ALL_ORDERS', PARTITIONS=1, REPLICAS=1) AS SELECT  'LOCAL' SRC,  *FROM ORDERS_SRC_LOCAL ORDERS_SRC_LOCALEMIT CHANGES;                                                                                                                                                                                                                                             
...

Terminate and Exit

ksqlDB

Important

Persisted queries run continuously as ksqlDB applications until they're terminated manually. Exiting the ksqlDB CLI doesn't terminate persistent queries.

From the output of SHOW QUERIES; identify a query ID you would like to terminate. For example, if you wish to terminate query ID CTAS_PAGEVIEWS_REGIONS_15:

1
TERMINATE CTAS_PAGEVIEWS_REGIONS_15;

Tip

The actual name of the query running may vary; refer to the output of SHOW QUERIES;.

Run the exit command to leave the ksqlDB CLI.

1
2
ksql> exit
Exiting ksqlDB.

Docker

To stop all data generator containers, run the following:

1
docker ps|grep ksql-datagen|awk '{print $1}'|xargs -Ifoo docker stop foo

If you're running Kafka using Docker Compose, you can stop it and remove the containers and their data with this command.

1
2
cd docs/tutorials/
docker-compose down

Produce extra topic data and verify your environment

The following instructions aren't required to run the quick start. They're optional steps to produce extra topic data and verify the environment.

Produce more topic data

The Compose file automatically runs a data generator that continuously produces data to two Kafka topics, pageviews and users. No further action is required if you want to use just the data available. You can return to the main ksqlDB quick start to start querying the data in these two topics.

However, if you want to produce additional data, you can use the following methods.

Produce Kafka data with the Kafka command line kafka-console-producer. The following example generates data with a value in DELIMITED format.

1
2
3
4
5
docker-compose exec kafka kafka-console-producer \
                            --topic t1 \
                            --broker-list kafka:39092  \
                            --property parse.key=true \
                            --property key.separator=:

Your data input should resemble:

1
2
3
4
key1:v1,v2,v3
key2:v4,v5,v6
key3:v7,v8,v9
key1:v10,v11,v12

Produce Kafka data with the Kafka command line kafka-console-producer. The following example generates data with a value in JSON format.

1
2
3
4
5
docker-compose exec kafka kafka-console-producer \
                            --topic t2 \
                            --broker-list kafka:39092  \
                            --property parse.key=true \
                            --property key.separator=:

Your data input should resemble:

1
2
3
4
key1:{"id":"key1","col1":"v1","col2":"v2","col3":"v3"}
key2:{"id":"key2","col1":"v4","col2":"v5","col3":"v6"}
key3:{"id":"key3","col1":"v7","col2":"v8","col3":"v9"}
key1:{"id":"key1","col1":"v10","col2":"v11","col3":"v12"}

You can also use the kafkacat command line tool:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
docker run --interactive --rm --network tutorials_default \
  confluentinc/cp-kafkacat \
  kafkacat -b kafka:39092 \
          -t warehouse_size \
          -K: \
          -P <<EOF
1:{"warehouse_id":1,"square_footage":16000}
2:{"warehouse_id":2,"square_footage":42000}
3:{"warehouse_id":3,"square_footage":94000}
EOF

You can also use INSERT VALUES SQL statements, as demonstrated in the previous examples.

Verify your environment

The following steps are optional verification steps to ensure your environment is properly setup.

Verify that six Docker containers were created.

1
docker-compose ps

Your output should resemble:

1
2
3
4
5
6
        Name                        Command            State                 Ports
----------------------------------------------------------------------------------------------------
tutorials_kafka_1             /etc/confluent/docker/run   Up      0.0.0.0:39092->39092/tcp, 9092/tcp
tutorials_ksql-server_1       /etc/confluent/docker/run   Up      8088/tcp
tutorials_schema-registry_1   /etc/confluent/docker/run   Up      8081/tcp
tutorials_zookeeper_1         /etc/confluent/docker/run   Up      2181/tcp, 2888/tcp, 3888/tcp

Take note of the Up state.

Earlier steps in this quickstart started two data generators that pre-populate two topics, named pageviews and users, with mock data. Verify that the data generator created these topics, including pageviews and users.

1
docker-compose exec kafka kafka-topics --bootstrap-server localhost:9092 --list

Your output should resemble this.

1
2
3
4
_confluent-metrics
_schemas
pageviews
users

Use the kafka-console-consumer to view a few messages from each topic. The topic pageviews has a key that is a mock time stamp and a value that is in DELIMITED format. The topic users has a key that is the user ID and a value that is in Json format.

1
2
3
4
5
6
docker-compose exec kafka kafka-console-consumer \
                            --topic pageviews \
                            --bootstrap-server kafka:39092 \
                            --from-beginning \
                            --max-messages 3 \
                            --property print.key=true

Your output should resemble:

1
2
3
1491040409254    1491040409254,User_5,Page_70
1488611895904    1488611895904,User_8,Page_76
1504052725192    1504052725192,User_8,Page_92
1
2
3
4
5
6
docker-compose exec kafka kafka-console-consumer \
                            --topic users \
                            --bootstrap-server kafka:39092 \
                            --from-beginning \
                            --max-messages 3 \
                            --property print.key=true

Your output should resemble:

1
2
3
User_2   {"registertime":1509789307038,"gender":"FEMALE","regionid":"Region_1","userid":"User_2"}
User_6   {"registertime":1498248577697,"gender":"OTHER","regionid":"Region_8","userid":"User_6"}
User_8   {"registertime":1494834474504,"gender":"MALE","regionid":"Region_5","userid":"User_8"}

Last update: 2020-05-29