⚠️ Discontinuation of project
This project is no longer actively maintained by Astronomer, but we’d love to see it live on in the community. While Astronomer has paused development and is not accepting new contributions, bug fixes or releases, the code is still here for you to explore, fork and adapt under the terms of its license. Please note that it may not work with the latest dependencies or platforms, and it could contain security vulnerabilities. Astronomer can’t offer guarantees or warranties for its use. If you’re interested in adopting or stewarding this project, we’d be happy to chat, reach us at oss@astronomer.io. Thanks for being part of the open-source journey and helping keep great ideas alive!
Universal Transfer Operator
transfers made easy
The UniversalTransferOperator simplifies how users transfer data from a source to a destination using Apache Airflow. It offers a consistent agnostic interface, improving the users' experience so they do not need to use explicitly specific providers or operators.
At the moment, it supports transferring data between file locations and databases (in both directions) and cross-database transfers.
This project is maintained by Astronomer.
Prerequisites
- Apache Airflow >= 2.4.0.
Install
The apache-airflow-provider-transfers is available at PyPI. Use the standard Python installation tools.
To install a cloud-agnostic version of the apache-airflow-provider-transfers, run:
pip install apache-airflow-provider-transfers
You can also install dependencies for using the UniversalTransferOperator with popular cloud providers:
pip install apache-airflow-provider-transfers[amazon,google,snowflake]
Quickstart
Users can get started quickly with following two approaches:
- Spinning up a local Airflow infrastructure using the open-source Astro CLI and Docker
- Using vanilla Airflow and Python
Run UniversalTransferOperator using astro
-
Create an Astro project.
-
Open your terminal or IDE
-
Install docker and astro-cli using this documentation.
-
Create a new directory for your Astro project:
mkdir <your-astro-project-name> -
Open the directory:
cd <your-astro-project-name>
-
Run the following Astro CLI command to initialize an Astro project in the directory:
astro dev init
-
This command generates the following files in the directory:
. ├── .env # Local environment variables ├── dags # Where your DAGs go │ ├── example-dag-basic.py # Example DAG that showcases a simple ETL data pipeline │ └── example-dag-advanced.py # Example DAG that showcases more advanced Airflow features, such as the TaskFlow API ├── Dockerfile # For the Astro Runtime Docker image, environment variables, and overrides ├── include # For any other files you'd like to include ├── plugins # For any custom or community Airflow plugins │ └── example-plugin.py ├── tests # For any DAG unit test files to be run with pytest │ └── test_dag_integrity.py # Test that checks for basic errors in your DAGs ├── airflow_settings.yaml # For your Airflow connections, variables and pools (local only) ├── packages.txt # For OS-level packages └── requirements.txt # For Python packages (add apache-airflow-provider-transfers here) -
Add the following in requirements.txt
apache-airflow-provider-transfers[all]
-
Copy file named example_transfer_and_return_files.py and example_snowflake_transfers.py and add it to the
dagsdirectory of your Airflow project:
Alternatively, you can download
example_transfer_and_return_files.pyandexample_snowflake_transfers.py.curl -O https://github.com/astronomer/apache-airflow-provider-transfers/blob/main/example_dags/example_transfer_and_return_files.py curl -O https://github.com/astronomer/apache-airflow-provider-transfers/blob/main/example_dags/example_snowflake_transfers.py
-
Create the environment variable for AWS bucket, Snowflake and google cloud bucket for the transfer as per the following:
-
To start running the example DAGs in a local Airflow environment, run the following command from your project directory:
astro dev start
-
After your project builds successfully, open the Airflow UI in your web browser at https://localhost:8080/. Find your DAGs in the dags directory in the Airflow UI.
-
Create airflow connection for snowflake, google, SFTP and amazon using airflow UI and run the DAGs.
-
Create airflow connection for snowflake, google and amazon using airflow UI as per documentation below.
Cloud Provider Connection name Documentation link Amazon aws_default aws connection Google google_cloud_default google cloud connection Snowflake snowflake_conn snowflake connection -
Trigger the DAGs and validate the transfers.
-
Run UniversalTransferOperator using vanilla airflow and python
-
Install airflow and setup project following this documentation.
-
Ensure that your Airflow environment is set up correctly by running the following commands:
export AIRFLOW_HOME=`pwd` airflow db init
-
Add the following in requirements.txt
apache-airflow-provider-transfers[all]
-
Copy file named example_transfer_and_return_files.py and example_snowflake_transfers.py and add it to the
dagsdirectory of your Airflow project:
Alternatively, you can download example_transfer_and_return_files.py and example_snowflake_transfers.py.
curl -O https://github.com/astronomer/apache-airflow-provider-transfers/blob/main/example_dags/example_transfer_and_return_files.py
curl -O https://github.com/astronomer/apache-airflow-provider-transfers/blob/main/example_dags/example_snowflake_transfers.py
-
Create the environment variable for AWS bucket, Snowflake and google cloud bucket for the transfer as per the following:
-
Run your project in a local Airflow environment.
-
After your project builds successfully, open the Airflow UI in your web browser at https://localhost:8080/. Find your DAGs in the dags directory in the Airflow UI.
-
Create airflow connection for snowflake, google and amazon using airflow UI as per documentation below.
Cloud Provider Connection name Documentation link Amazon aws_default aws connection Google google_cloud_default google cloud connection Snowflake snowflake_conn snowflake connection -
Trigger the DAGs and validate the transfers.
Example DAGs
Checkout the example_dags folder for examples of how the UniversalTransferOperator can be used.
How Universal Transfer Operator Works
With UniversalTransferOperator, users can perform data transfers using the following transfer modes:
- Non-native
- Native
- Third-party
Non-native transfer
Non-native transfers rely on transferring the data through the Airflow worker node. Chunking is applied where possible. This method can be suitable for datasets smaller than 2GB, depending on the source and target. The performance of this method is highly dependent upon the worker's memory, disk, processor and network configuration.
Internally, the steps involved are:
- Retrieve the dataset data in chunks from dataset storage to the worker node.
- Send data to the cloud dataset from the worker node.
Following is an example of non-native transfers between Google cloud storage and Sqlite:
Improving bottlenecks by using native transfer
An alternative to using the Non-native transfer method is the native method. The native transfers rely on mechanisms and tools offered by the data source or data target providers. In the case of moving from object storage to a Snowflake database, for instance, a native transfer consists in using the built-in COPY INTO command. When loading data from S3 to BigQuery, the Universal Transfer Operator uses the GCP Storage Transfer Service.
The benefit of native transfers is that they will likely perform better for larger datasets (2 GB) and do not rely on the Airflow worker node hardware configuration. With this approach, the Airflow worker nodes are used as orchestrators and do not perform the transfer. The speed depends exclusively on the service being used and the bandwidth between the source and destination.
Steps:
- Request destination dataset to ingest data from the source dataset.
- Destination dataset requests source dataset for data.
NOTE: The Native method implementation is in progress and will be available in future releases.
Transfer using a third-party tool
The UniversalTransferOperator can also offer an interface to generic third-party services that transfer data, similar to Fivetran.
Here is an example of how to use Fivetran for transfers:
Supported technologies
-
Databases supported:
-
File store supported:
Documentation
The documentation is a work in progress -- we aim to follow the Diátaxis system.
-
Reference guide: Commands, modules, classes and methods
-
Getting Started Tutorial: A hands-on introduction to the Universal Transfer Operator
Changelog
The Universal Transfer Operator follows semantic versioning for releases. Check the changelog for the latest changes.
Release management
See Managing Releases to learn more about our release philosophy and steps.
Contribution guidelines
All contributions, bug reports, bug fixes, documentation improvements, enhancements, and ideas are welcome.
Read the Contribution Guideline for a detailed overview of how to contribute.
Contributors and maintainers should abide by the Contributor Code of Conduct.
License
Metadata
Release files for apache-airflow-provider-transfers 0.1.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| apache_airflow_provider_transfers-0.1.2.tar.gz | 62.3 kB | Without provenance | Details for apache_airflow_provider_transfers-0.1.2.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| apache_airflow_provider_transfers-0.1.2-py3-none-any.whl | Python 3 | none | any | Details for apache_airflow_provider_transfers-0.1.2-py3-none-any.whl |
Total release size: 151.1 kB
Release files / apache_airflow_provider_transfers-0.1.2.tar.gz
| Download URL | apache_airflow_provider_transfers-0.1.2.tar.gz |
|---|---|
| Size | 62.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
718ccf00bd809e18f33a22d48dcb83f06302de746138aae2b001cf22dc9a0e56
|
|
BLAKE2b-256 checksum How to use checksums |
9007a1ab906b0928616bc2eea61bcaf1d6b301cf61e7499425dc1396deadd07e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.1.0 CPython/3.8.18
|
Release files / apache_airflow_provider_transfers-0.1.2-py3-none-any.whl
| Download URL | apache_airflow_provider_transfers-0.1.2-py3-none-any.whl |
|---|---|
| Size | 88.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
e454a1078fb66d68891d759f7c13b017f5d4eae49a281cb5785b82c6db474a06
|
|
BLAKE2b-256 checksum How to use checksums |
dbeb571fc10d541a1f4b25528d5e3ce39419efbf4828c839bdfcb606c6411d7d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.1.0 CPython/3.8.18
|
Security for apache-airflow-provider-transfers 0.1.2
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.