Adding an External Stream Source

The Streaming Data Source option lets you select a source that you know is streaming, including the file system, network sockets, AMQP, Amazon Kinesis, and Kafka. All data is sent as a string in CSV, XML, JSON, or AVRO format.

For more details on these specific sources, see Configuring External Stream Sources below.

To add a Streaming Data source:

  1. On the Sources page, drag a Streaming Data source from the left column into the center area.
  2. Click the new Streaming Data source.
  3. Select File System, Socket, AMQP, Kafka, Kinesis, WebSocket, or HTTP.
  4. Enter connection information for the input source. For example, to access a File source, you need to enter directory and filename pattern information for the file. By default, StreamLab uses the project schema for the new source. If you wish to use a different schema, click the dropdown menu to the right of Schema.Stream. You can also choose a different name for the stream by clicking the dropdown menu that reads "data_1".

  5. Click the Discover Format button. This feature examines the file to determine its file format. Currently, the Discovery parser can identify CSV, XML, JSON, and Avro files. StreamLab can also work with ProtoBuf files, but you need to add these as their own source. Avro files may require additional configuration to work.

    The Discover Format dialog box opens. You can select an amount for the Discover Format feature to read in bytes and a timeout for the feature. See Troubleshooting Discovery below. In most cases, defaults should device.

  6. Click Start. The Discover Format feature runs. The left section of the dialog box should display a format--either CSV, JSON, XML, or Binary.

  7. Click Accept. The indicated format should be automatically selected under Format. You can also choose the Line format, which lets you access files line-by-line.

  8. Next, fill in the list of columns and their SQL types. You can use the Clipboard to copy column names and types from another form.

  9. Test the source by clicking the Sample 5 Rows from Source button.

  10. Click the Go Up arrow to exit the Edit Source page.

Troubleshooting Discovery

The Sample Bytes field determines how many bytes Discovery reads before analyzing the input. This number can greatly affect Discovery's performance. If you set it too high and your data is coming in too slowly, you won't see any response from Discovery until it has read these bytes. If you set it too low and it's smaller than the size of a record in your input, Discovery will have difficulty determining your file's format. A good rule of thumb is to set Sample Bytes to about 5X the size of a record in your input, so that Discovery sees multiple records and can make a better guess as to the data types of the columns it finds. For example, if each record is 80 bytes, it would make sense to set Sample Bytes at 4096.

Configuring Avro

If you know or suspect that your streaming data source is Apache Avro, you may need to take additional steps to configure this source.

Before running Discover Format, select Binary for the Format option.

Under Binary Format, select AVRO.

If you know your Avro payload has a schema, check the This Payload Has a Schema String as a Prefix box and enter the location of the schema for the AVRO Schema Location option. AVRO_SCHEMA_FILE has been changed to AVRO_SCHEMA_LOCATION. This option can either be a http URL to fetch the schema or it can be a path to a file on the server host machine or VM.

Note: If you do not select Binary as format, discovery may either recommend "UNKNOWN" or return a CSV with a single column.

Configuring External Stream Sources

Streaming Data sources make use of s-Server's Extensible Common Data framework. This framework allows you to read and write rows of data in a range of forms over a range of input/output formats, including the file system, network sockets, AMQP, Amazon Kinesis, and Kafka. All data is sent as a string in CSV, XML, JSON, or AVRO format

Using the File System as a Streaming Data Source

To read streaming data over the file system, you need two pieces of information:

  • The directory in which the file resides.
  • A pattern for the file's name. Here, you enter part of the file's name, such as output, csv, or log. No quotation marks are necessary.

Foreign Stream Options for Reading from the File System

Option Description
DIRECTORY Directory in which file resides or to which you are writing.
FILENAME_PATTERN Input only. Java regular expression defining which files to read.

See https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html for more information on Java regular expressions.
STATIC_FILES Defaults to false. When you set this to true, you indicate that no files will be added or changed after the file reader is started. File reader will exit after the last file is read. This lets you use the file reader as a foreign table, which is finite (as opposed to a foreign stream, which is infinite, and handles files that are continually written to).
REPEAT Defaults to 0, meaning do not repeat. Can be a positive whole number, a negative number, or 'FOREVER'.

For positive numbers, after processing all files that match FILENAME_PATTERN, start over again. Repeat for the specified number.

If negative or 'FOREVER', keep reprocessing all files that match FILENAME_PATTERN forever. You must set STATIC_FILES to true in order to use this option.

Using a Network Socket as a Streaming Data Source

To read from a line, CSV, XML, or JSON file over a network socket, you need to configure the socket connection. You may want to consult with whoever has set up the application with which StreamLab will connect over the socket.

Network sockets initiate a connection over TCP or UDP. Connections can be initiated by remote applications or by StreamLab itself. To tell StreamLab listen to a remote host, use the Remote Host and Remote Port fields. Connections can optionally be made using IPV6.

Name Description
Remote Host Hostname to send rows to or receive rows from. You can override this to 'LOCALHOST' to listen to only local connections, or a specific ip address, such as <168.212.226.204>.
Socket uses TCP? Whether the socket uses TCP (True) or UDP (False). Default is false (UDP).
Skip Header True or false; defaults to false. Specifies if the parser should skip the first row of input files. Usually, you would do this if the first row of data contains column headers.

Using AMQP as a Streaming Data Source

To read from a streaming data source over AMQP, you need to configure the AMQP connection. AMQP stands for Advanced Message Queuing Protocol, and is an Open Standard for Messaging Middleware. For more information, see http://www.amqp.org/about/what. You may want to consult with whoever has set up AMQP in your environment.

AMQP 0.9.1 vs 1.0

There are distinct differences between the way AMQP up to 0.9.1 works and the way AMQP 1.0 works. Roughly, AMQP 1.0 only provides network wire-level protocol for the exchange of messages, while up to 0.9.1, AMQP employed a system of exchanges, queues and bindings to exchange messages. As a result of this change, you configure StreamLab for AMQP differently for 1.0 than for up to 0.9.1

Foreign Stream Options for Reading from AMQP

AMQP 0.9.1 vs 1.0

There are distinct differences between the way AMQP up to 0.9.1 works and the way AMQP 1.0 works. Roughly, AMQP 1.0 only provides network wire-level protocol for the exchange of messages, while up to 0.9.1, AMQP employed a system of exchanges, queues and bindings to exchange messages. As a result of this change, you configure the connection URL for AMQP differently for 1.0 than for up to 0.9.1

Option Description
CONNECTION_URL Required. Connection URL for AMQP legacy server. This includes the servers hostname, user, password, port and so on. This will differ depending on whether you are using AMQP 1.0 or a legacy version.
DESTINATION This can be in the form {PARITITION}.
PARTITION_EXPRESSION You should only use this if DESTINATION includes "{PARTITION}". This should be a dk.brics regular expression, such as <0-3>.
PARSER_QUEUE_SIZE Queue size for parser. Reading only. Defaults to 2. In most cases, you will not want to change this number.
ACKNOWLEDGE_MODE Optional. Acknowledgment mode that ECDA communicates to the AMQP 1.0 server. Options are AUTO, MANUAL, or NONE; defaults to AUTO. Details on these modes are available at http://docs.spring.io/spring-integration/reference/html/amqp.html#amqp-inbound-ack.

Roughly, AUTO asks the container on the AMQP server to acknowledge once message is completely delivered. MANUAL means that delivery tags and channels are provided in message headers, and NONE means no acknowledgments.

AMQP_LEGACY (AMQP protocol Version 0.9, e.g., RabbitMQ)

Format:

amqp://<username>:<password>@<clientid>/<profile>?brokerlist='tcp://<hostname>:<portNumber>'&[ <optionsList> ]`

Example:

amqp://guest:guest@clientid/default?brokerlist='tcp://localhost:5672'

AMQP10 (AMQP protocol Version 1.0) - connectionfactory.localhost:

Format:

amqp://<username>:<password>@<hostname>:<portNumber>?<optionsList>'

Example:

amqp://guest:guest@localhost:5672?clientid=test-client&remote-host=default

Single quotes must be doubled for SQL formatting. You may need to do additional URL escaping depending on your AMQP implementation.Single quotes must be doubled for SQL formatting. You may need to do additional URL escaping depending on your AMQP implementation. The site https://azure.microsoft.com/en-us/documentation/articles/service-bus-java-how-to-use-jms-api-amqp/ offers an example of formatting a connection URL.

Using Amazon Kinesis as a Streaming Data Source

To read from a streaming data source over Amazon Kinesis, you need to configure the Amazon Kinesis connection.

You need to have an AWS profile set up, and a configuration file stored on your system, in order to read from or write to Kinesis. See Setting Up an AWS Profile Path in the SQLstream Integration Guide .

Option Description
AWS Profile Name Optional. Profile name to use within credentials file. Defaults to default.
Initial Position LATEST for latest or TRIM_HORIZON for earliest. Defaults to LATEST.
Socket Timeout (defaults to -1) if set will override Kinesis socket timeout

Using Kafka as a Streaming Data Source

To read data from Kafka, you need to configure the connection to Kafka. Kafka is an open-source, real-time publish-subscribe messaging framework. See http://kafka.apache.org/ for more details. You may want to consult with whoever has set up the Kafka messaging system in your environment.

You can configure the Kafka source to distribute data across multiple native streams for load balancing. See Using the Distributed Source Option below for more details.

To connect with Kafka, you need two pieces of information:

  • The name and port of the Kafka broker (this defaults to localhost:9092, but the source will not work if a Kafka broker is not working at this location).
  • The Kafka topic name from which you are reading.

The other configuration details below help manage the starting point for reading Kafka topics as well as the amount of data fed to StreamLab.

Foreign Stream Options for Reading from Kafka

Option Description
TOPIC Required. Kafka Topic. You can use a regular expression as a "topic wild card." (This is not supported by legacy versions of the adapter.)
STARTING_TIME Either EARLIER, LATEST, or a timestamp in the format 'yyyy-MM-dd HH:mm:ss.SSS', such as '2018-02-01 22:23:45:892'.

When STARTING_TIME is a timestamp, the Kafka adapter "seeks" to offsets within all topic partitions where the message timestamp for all subsequent messages is greater than or equal to the specified STARTING_TIME. Requires Kafka v0.10.2 or later.

For the legacy Kafka adapter, options are EARLIEST or LATEST.
INDEX_TOPIC_NAME This option specifies the name of the index topic to be used for mapping message offsets to timestamps. For more details, refer to Building and Using an Index in the Reading from Kafka topic of the s-Server Integration Guide. Index topic may be created on a separate Kafka cluster.
STARTING_OFFSET When to start reading from (default is -1) as a long int representing a timestamp (milliseconds since epoch)
SEED_BROKERS A comma separated list of broker identifiers in the format _<broker_hostname>:<port>. For legacy adapter, this is a comma separated list of broker hosts. Defaults to "localhost".
PARTITION Partition number to read from. If reading from a kafka topic with multiple partitions and PARTITION is omitted or blank all partitions will be read from. You can specify a single partition with PARTITION or a range with PARTITION -(Range needs two partitions - eg 1-3 - and is inclusive.) Note: Partition numbers are 0 based.
PORT Deprecated for Kafka10 adapter. For legacy adapter, port for Kafka seed broker
MAX_POLL_RECORDS Maximum number of records to be polled (fetched) through the new KafkaConsumer.poll() API call. For best throughput during replay, this needs to be set such that you get a "page" full (1MB is the deafult) of kafka messages from each partition of the topic(s). It can be roughly calculated as: (numPartitions * 1 MB) / typicalMessageSize
PARTITION_OFFSET_QUERY This is a SQL query text that fetches starting offsets for all partitions of the topic. For example, SELECT "TOPIC", "PARTITION", "OFFSET" FROM stored_offsets;'PARTITION should be of type INTEGER.OFFSET should be of type BIGINT. Any partition for which the query does not return anything will either use STARTING_OFFSET or STARTING_TIME to determine where to start.
FETCH_SIZE Fetch size. Defaults to 1000000.
CLIENT_ID For the Kafka10 adapter, it is vital to understand that this is the consumer group id (so is used to set consumer group property group.id)Client key for Yammer metrics. CLIENT_ID defaults to client{TOPIC} or CLIENT{TOPIC}{PARTITION} if PARTITION is specified. CLIENT_ID and METRICS_PER_PARTITION affect Kafka Yammer metrics reporting. CLIENT_ID does not apply unless METRICS_PER_PARTITION is set to true. See http://docs.confluent.io/1.0/kafka/monitoring.html for more information on Kafka Yammer metrics.
METRICS_PER_PARTITION True or False. If METRICS_PER_PARTITION is false, then CLIENT_ID will be used as the client key for all yammer metrics reporting for that adapter. If METRICS_PER_PARTITION is true, then the actual partition number will be appended to each to each client_id (and finer grained metrics will be reported).
OPTIONS_QUERY Lets you query a table to update adapter options at runtime. You can use this, for example, to set the STARTING_OFFSET option from a table that contains the last offset, as inselect lastOffset as STARTING_OFFSET from TEST.committedOffset');
kafka.consumer.config Lets you specify the name of a properties file that contains a set of Kafka consumer configurations. For example, you could use such a file to set all the properties needed for a SSL/SASL connection that the consumer will invoke. Kafka offers a wide range of config properties. For details, see Kafka documentation at https://kafka.apache.org/0100/documentation.html#newconsumerconfigs Note: In some cases, you can use these property files to override Foreign Stream options. For example, the setting for bootstrap.servers will override the Foreign Stream option "SEED_BROKERS". This can be helpful in dynamic environments (AWS, Docker, Kubernetes and so on) where you do not know the specific locations of the Kafka brokers until runtime.
isolation.level Lets you specify whether s-Server should read all Kafka messages or only committed messages. Options are read_uncommitted, or read_committed This option lets you account for transactions, a Kafka 0.11.0 feature whereby applications can write to multiple topics and partitions atomically. To use atomic commitments, you need to configure the Kafka adapter to only read committed data--this is, read_committed.

Using the Distributed Source Option

StreamLab reads data from Kafka using a Kafka consumer. Kafka consumers subscribe to Kafka topics, receiving messages from these topics. Kafka consumers balance loads among partitions in the topic.

By default, StreamLab routes all data read from a Kafka source into one native stream. While behind the scenes, StreamLab invokes multiple Kafka consumers, all of these consumers are rolled into one native stream. This means that all data from the Kafka topic ends up in one s-Server stream, which StreamLab then uses as a source for a pipeline.

In many cases, this default option may work fine with your StreamLab application. In some cases, though, you may want to have multiple, duplicate pipelines running on one Kafka foreign stream. This option is called Distributed.

Once you distribute the Kafka topic across multiple native streams, you can choose to use duplicate pipelines. These run in parallel. You do not need to configure the additional pipelines; these are simply exact duplicates of the first. If you set up a sink for the pipeline, both pipelines will be routed to the same sink.

In a Pipeline Guide that uses a distributed Kafka source, an option to increase the number of duplicate pipelines will appear to the left of the Change Guide Name or Source button in the upper right-hand corner of the Guide window:

Note on Stateful Properties and Distributed Sources

The distributed pipelines option is intended for advanced SQL developers who know how to run stateful aggregations in a distributed manner. A stateful distributed pipeline can use Streamlab templates that involve stateful operations (such as aggregation) as long as the application developer takes the responsibility to ensure the proper distribution of the aggregation state. You can achieve better performance and throughput by carefully distributing, for example, an aggregation state across duplicated pipelines.

The distributed option works seamlessly for stateless operations, such as CAST or Rename. If you are doing aggregations or other operations that involve making calculations across data from the entire Kafka topic, you will need to either:

  1. Route results of dulicated pipelines to a native stream sink and then create a new pipeline using this sink as a source. You can then perform aggregations in the new pipeline.
  2. Perform partial aggregations through distributed pipelines and route partially aggregated results into a native stream and add roll-up aggregation steps in a new pipeline.

Using MQTT as a Streaming Data Source

To read data from or write data to MQTT, you need to configure the connection to MQTT. StreamLab uses this information to implement an MQTT client that reads data into the foreign stream. Minimum options required are TOPIC and CONNECTION_URL.

Foreign Stream Options for Reading from MQTT

Option Description
CONNECTION_URL 'tcp://127.0.0.1:1883',
TOPIC MQTT topic. UTF-8 string that the MQTT broker uses to filter messages for each connected client.
QOS Defines the guarantee of delivery for a specific message. Either at most once (0), at least once (1), exactly once (2). Defaults to 1. For more information on QOS, see https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/
CLIENT_ID s-Server implements an MQTT client to connect to the MQTT server. This setting provides a MQTT ClientID for this client. The MQTT broker uses the ClientID to identify the client and its current state. As a result, if used, you should use a distinct CLIENT_ID for each foreign stream defined for MQTT. Defaults to randomly generated.
USERNAME Optional. User name for MQTT connection. Note: s-Server sends user names and passwords as plain text.
PASSWORD Optional. Password for MQTT connection. Note: s-Server sends user names and passwords as plain text.
KEEP_ALIVE_INTERVAL Optional. Interval in seconds sent to MQTT broker when s-Server establishes a connection. Specifies the longest time period of time that broker and client persist without sending a message. Defaults to 60.
CONNECTION_TIMEOUT Optional. Defaults to 30.