Skip to main content
A data sink is reference object for a data target that is generally external to the database. It consists of the location & connection information to that target. A data sink can make use of a credential object for storing remote authentication information. A data sink name must adhere to the standard naming criteria. Each data sink exists within a schema and follows the standard name resolution rules for tables. The following data sink types are supported:
  • Azure (Microsoft blob storage)
  • GCS (Google Cloud Storage)
  • HDFS (Apache Hadoop Distributed File System)
  • JDBC (Java Database Connectivity, using a user-supplied driver or one of the drivers on the supported list)
  • Kafka (Apache Kafka streaming feed)
  • Local (Table within the same Kinetica instance)
  • S3 (Amazon S3 Bucket)
  • Webhook (HTTP/HTTPS)
The following default hosts are used for Azure, GCS, & S3, but can be overridden in the destination parameter:
  • Azure: <service_account_name>.blob.core.windows.net
  • GCS: storage.googleapis.com
  • S3: <region>.amazonaws.com
Data sinks perform no function by themselves, but act as proxies for transmitting data when referenced as a destination in the creation of a table monitor (see also the CREATE STREAM command in SQL), or when referenced as the target of an /export/records/totable call (see also the Exporting Data command in SQL).
Kafka data sinks will be validated upon creation, by default, and will fail to be created if an authorized connection cannot be established.

Managing Data Sinks

A data sink can be managed using the following API endpoint calls. For managing data sinks in SQL, see CREATE DATA SINK.

Creating a Data Sink

To create a data sink, kin_dsink, that targets Apache Kafka:
To create a data sink that targets a local database table:

Consumer-Specific Syntax

Several authentication schemes across multiple providers are supported.

Azure

GCS

HDFS

Credential

JDBC

Kafka

Local (Kinetica)

User Auth

S3

Webhook