snowflakedb / snowflakedb/snowflake-connector-python

SNOW-590041: Support a Distributed Write API (inverse of distributed fetch)

Open
#1,139 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

feature status-triage_done triaged
Dominant language
Python
Stars
730
Forks
574
Avg merge
5h 45m
Merged PRs (30d)
16

Description

What is the current behavior?

When you have data that is located on multiple different machine in memory, writing this data to Snowflake requires intermediate steps to perform the write in a single transaction. The crucial limiting factor (as I see it) is that each connection is assigned a unique ID for transactions, so if you want to group a set of writing into the same transaction, the request must be sent by a single connection. Here are the options that I currently see available:

Write to intermediate storage

One option is that you could write to disk "somewhere". For example, you could write the data into cloud storage with S3 and then stage those files into Snowflake. This may work well if you already have s3 setup, but it add an intermediate step to configure and may impact performance.

Gather the data onto 1 node

Another option without going to disk would be to gather all of the data onto a single node and then do the write from a single connection. However, engines that use distributed data often do so because the amount of data being processed may exceed the memory available on a single machine. To get around this you would need to do some form of pipelining, which would likely be very slow.

Do multiple transactions

The third option I see if a system could separate tasks into separate transactions and just do one connection per node/task. In addition to not satisfying many user's expectations, this would also likely impact performance as now each transaction may need rollbacks to order the transactions.

If I am missing any other options to do a proper distributed write please let me know, especially if you have any suggestions on the best way to do this right now.

What is the desired behavior?

I would like the Snowflake connector to be able to perform a true distributed write, whereby a series of connections could do inserts that all function as part of the same transaction. To do this, I would like to see the following behavior:

  • Multiple connections can participate as part of the same transaction.
  • A single commit is used to write all of the data in the distributed write transaction.
  • Rolling back the transaction rolls back the writes from all connections in this transaction.
  • Writes from different sources should be truly parallel so long as they are purely appends. Some work would still be expected to match sort/clustering requirements
  • No need for users to gather data onto a single machine or storage

I think there are various ways that this can be implemented into a user friendly solution.

How would this improve snowflake-connector-python?

I think this would improve the performance capabilities of writing back to Snowflake from distributed compute engines. In addition, I think this would improve user experience as it may simplify the amount of resources needed to successfully write to Snowflake. This would be essential for the performance of compute engines like Bodo and Snowflake.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named. Start by reviewing the connector's transaction and connection handling alongside the existing distributed fetch API; define how multiple connections share one transaction, commit or roll back atomically, and preserve parallel appends. Done means distributed writes support one shared commit and rollback without gathering data on one machine or using intermediate storage.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend-api-design, databases, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.