Data Connectors

To train models, you need to connect a data source first. Once connected, Kumo can train and retrain models as your data is refreshed. For identity-backed sources, an administrator must first create an identity and assign it to the Group that owns your Project.

Set up Connector

1. Go to Connectors from the side menu and select Add Connector.

2. Select your data source.

3. Select a compatible identity already assigned to your Project’s Group.

4. Enter the following:

   Field	Requirement
   Connector name	Required.
   Description	Optional.

5. Provide the target fields for that source.

6. Select Add to create the connector.

Supported Data Sources

Kumo currently supports the following data source types:

Amazon S3

Select an Amazon S3 identity, then enter the following:

Choose a connector mode:

The root directory can contain files or second-level table directories:

• When it contains files, Kumo ignores subdirectories and ingests files as tables.
• When it contains directories, each is one table; files within it must have the same format and schema, and it cannot contain further nested directories.

Do not use dots in the S3 bucket name.

|-- Root directory
  |-- Table 1
    |-- File 1 (CSV or Parquet)
    |-- File 2 (CSV or Parquet)
  |-- Table 2
    |-- File 1 (CSV or Parquet)
    |-- File 2 (CSV or Parquet)

Use the following file-format guidance:

• Cast columns to their proper data types.
• Do not use Hive-partitioned tables.

Limits:

• Each Parquet partition must not exceed 512 MB.
• CSV tables can have up to 128 partitions and up to 10 GB total.

BigQuery

Select a BigQuery identity, then enter the following:

To verify the connection:

1. Select the connector from the list on the Connectors page.
2. Review its details in the right panel.

Snowflake

Select a compatible Snowflake identity, then enter the following:

The selected identity’s service account must have access to the database, schema, and warehouse through the connector’s Role (optional) when you provide one, or through its default role when you leave the field blank.

For a database customer_db, schema customer_schema, warehouse customer_warehouse, and role user_role, grant the minimum privileges below.

CREATE TABLE and DROP TABLE are needed only when Kumo writes predictions back.

-- Replace user_role with the connector role, or with the service account's DEFAULT_ROLE when no connector role is set.
-- Run DESCRIBE USER <username> to identify the DEFAULT_ROLE when needed.
-- Grant usage privilege on the database.
GRANT USAGE ON DATABASE customer_db TO ROLE user_role;
-- Grant usage and monitoring on the schema, plus view-creation privileges.
GRANT USAGE, MONITOR, CREATE VIEW, CREATE MATERIALIZED VIEW ON SCHEMA customer_db.customer_schema TO ROLE user_role;
-- REFERENCES lets Kumo query information-schema metadata.
GRANT SELECT, REFERENCES ON ALL TABLES IN SCHEMA customer_db.customer_schema TO ROLE user_role;
-- Optional: allow read access to future tables in the schema.
GRANT SELECT, REFERENCES ON FUTURE TABLES IN SCHEMA customer_db.customer_schema TO ROLE user_role;
-- Allow predictions to be written back to the schema.
GRANT CREATE TABLE ON SCHEMA customer_db.customer_schema TO ROLE user_role;
GRANT DROP TABLE ON SCHEMA customer_db.customer_schema TO ROLE user_role;
-- Allow Kumo to use the warehouse.
GRANT USAGE ON WAREHOUSE customer_warehouse TO ROLE user_role;

If the instance is VPN-protected, add the Kumo Cloud Network gateway to its allowlist as described in Snowflake’s network-policies documentation.

Recommended SaaS warehouse sizes:

Snowflake Secure Data Sharing legacy path

To set up Secure Data Sharing:

1. Enable Provider Sharing in Snowflake.
2. Share within the same cloud and region when possible.
3. Create a share, grant it access to the required database objects, then add the matching Kumo account:

Constraints:

• If regions differ, data replication is required, but Kumo does not recommend it.
• Secure Sharing is available in Standard, Enterprise, Business Critical, and VPS editions, although Business Critical accounts cannot share with lower editions.

CREATE SHARE KUMO_SHARE;
GRANT USAGE ON DATABASE my_database TO SHARE kumo_share;
GRANT USAGE ON SCHEMA my_database.myschema TO SHARE kumo_share;
GRANT SELECT ON TABLE my_database.myschema.shared_table TO SHARE kumo_share;
ALTER SHARE KUMO_SHARE ADD ACCOUNTS=<OrgName>.<Account Name>;

Sharing constraints:

• The creating role needs CREATE SHARE and access to the shared objects.
• Shares may include tables, external tables, secure views, and secure materialized views, but only secure views can be shared as views.
• Avoid SELECT(*) in views because source-table changes can break it.
• Kumo incurs the compute cost of querying shared data, so you do not incur extra storage costs for the share.

Use the Kumo account that matches your cloud and region:

Security considerations:

1. Kumo creates a database from the received share for EDA and proof-of-value operations.
2. Kumo creates a unique role in that database to control access.
3. Access is provided only to Kumo’s designated point of contact.

Use SHARE_USAGE, QUERY_HISTORY, and LOGIN_HISTORY to audit use, and regularly review the assigned role and share permissions.

Databricks

Select a compatible Databricks identity, then enter the following:

Azure Data Lake Storage

Before connecting, create the following:

• An Azure Storage account with hierarchical namespace enabled (ADLS Gen2).
• A container (filesystem) in that account.

Select an Azure Data Lake Storage identity, then enter the following:

abfss://<filesystem>@<storage-account>.<endpoint-suffix>/<prefix>

Name requirements:

• The filesystem name must use lowercase alphanumeric characters and hyphens and be 3-63 characters long.
• The storage-account name must use lowercase alphanumeric characters and be 3-24 characters long.

Choose a connector mode:

The base location can contain files or immediate table directories.

Limits:

• Each directory must contain only CSV or Parquet files of one format and schema, with no nested directories.
• Parquet partitions must not exceed 512 MB.
• CSV tables can have 128 partitions and up to 10 GB total.

The endpoint suffix must match the identity’s Azure cloud:

Google Cloud Storage

Select a compatible Google Cloud Storage identity, then enter the following:

Choose a connector mode:

Local Upload

Local Upload is available in the current release and does not require an identity or connector.

1. On Tables, select Add table.
2. Choose Local Upload from Source.
3. Drag in or browse to a CSV or Parquet file.
4. Select Upload.
5. Review columns and preprocessing options.
6. Select Add table.

Upload limits:

• Files uploaded through the UI can be up to 100 GiB.
• CSV files must contain more than one column.

Managing Connectors

To edit or delete a connector:

1. Select it.
2. Click the ︙ options button.
3. Choose Edit or Delete.

Editing changes only the connector name and description. The referenced identity and target configuration are immutable.

Next steps

After connecting a data source, create a table to make its data available for graph creation.