diff --git a/docs/website/docs/dlt-ecosystem/destinations/destination.md b/docs/website/docs/dlt-ecosystem/destinations/destination.md index c2d0c4f0a9..4e6452b425 100644 --- a/docs/website/docs/dlt-ecosystem/destinations/destination.md +++ b/docs/website/docs/dlt-ecosystem/destinations/destination.md @@ -6,15 +6,11 @@ keywords: [reverse etl, sink, function, decorator, destination, custom destinati # Custom destination: Reverse ETL -The `dlt` destination decorator allows you to receive all data passing through your pipeline in a simple function. This can be extremely useful for -reverse ETL, where you are pushing data back to an API. +The `dlt` destination decorator allows you to receive all data passing through your pipeline in a simple function. This can be extremely useful for reverse ETL, where you are pushing data back to an API. -You can also use this for sending data to a queue or a simple database destination that is not -yet supported by `dlt`, be aware that you will have to manually handle your own migrations in this case. +You can also use this for sending data to a queue or a simple database destination that is not yet supported by `dlt`, although be aware that you will have to manually handle your own migrations in this case. -It will also allow you to simply get a path -to the files of your normalized data, so if you need direct access to parquet or jsonl files to copy them somewhere or push them to a database, -you can do this here too. +It will also allow you to simply get a path to the files of your normalized data. So, if you need direct access to parquet or jsonl files to copy them somewhere or push them to a database, you can do this here too. ## Install `dlt` for reverse ETL @@ -25,8 +21,7 @@ pip install dlt ## Set up a destination function for your pipeline -The custom destination decorator differs from other destinations in that you do not need to provide connection credentials, but rather you provide a function which gets called for all items loaded during a pipeline run or load operation. -With the `@dlt.destination` you can convert any function that takes two arguments into a `dlt` destination. +The custom destination decorator differs from other destinations in that you do not need to provide connection credentials, but rather you provide a function which gets called for all items loaded during a pipeline run or load operation. With the `@dlt.destination`, you can convert any function that takes two arguments into a `dlt` destination. A very simple dlt pipeline that pushes a list of items into a destination function might look like this: @@ -45,11 +40,11 @@ pipeline.run([1, 2, 3], table_name="items") ``` :::tip -1. You can also remove the typing information (`TDataItems` and `TTableSchema`) from this example, typing generally are useful to know the shape of the incoming objects though. +1. You can also remove the typing information (`TDataItems` and `TTableSchema`) from this example. Typing is generally useful to know the shape of the incoming objects, though. 2. There are a few other ways for declaring custom destination functions for your pipeline described below. ::: -## `@dlt.destination`, custom destination function and signature +## `@dlt.destination`, custom destination function, and signature The full signature of the destination decorator plus its function is the following: @@ -67,27 +62,23 @@ def my_destination(items: TDataItems, table: TTableSchema) -> None: ``` ### Decorator -* The `batch_size` parameter on the destination decorator defines how many items per function call are batched together and sent as an array. If you set a batch-size of `0`, -instead of passing in actual dataitems, you will receive one call per load job with the path of the file as the items argument. You can then open and process that file -in any way you like. -* The `loader_file_format` parameter on the destination decorator defines in which format files are stored in the load package before being sent to the destination function, -this can be `jsonl` or `parquet`. -* The `name` parameter on the destination decorator defines the name of the destination that get's created by the destination decorator. -* The `naming_convention` parameter on the destination decorator defines the name of the destination that gets created by the destination decorator. This controls how table and column names are normalized. The default is `direct` which will keep all names the same. +* The `batch_size` parameter on the destination decorator defines how many items per function call are batched together and sent as an array. If you set a batch-size of `0`, instead of passing in actual data items, you will receive one call per load job with the path of the file as the items argument. You can then open and process that file in any way you like. +* The `loader_file_format` parameter on the destination decorator defines in which format files are stored in the load package before being sent to the destination function. This can be `jsonl` or `parquet`. +* The `name` parameter on the destination decorator defines the name of the destination that gets created by the destination decorator. +* The `naming_convention` parameter on the destination decorator defines the name of the destination that gets created by the destination decorator. This controls how table and column names are normalized. The default is `direct`, which will keep all names the same. * The `max_nesting_level` parameter on the destination decorator defines how deep the normalizer will go to normalize complex fields on your data to create subtables. This overwrites any settings on your `source` and is set to zero to not create any nested tables by default. -* The `skip_dlt_columns_and_tables` parameter on the destination decorator defines wether internal tables and columns will be fed into the custom destination function. This is set to `True` by default. +* The `skip_dlt_columns_and_tables` parameter on the destination decorator defines whether internal tables and columns will be fed into the custom destination function. This is set to `True` by default. :::note * The custom destination sets the `max_nesting_level` to 0 by default, which means no subtables will be generated during the normalization phase. -* The custom destination also skips all internal tables and columns by default, if you need these, set `skip_dlt_columns_and_tables` to False. +* The custom destination also skips all internal tables and columns by default. If you need these, set `skip_dlt_columns_and_tables` to False. ::: ### Custom destination function * The `items` parameter on the custom destination function contains the items being sent into the destination function. -* The `table` parameter contains the schema table the current call belongs to including all table hints and columns. For example, the table name can be accessed with `table["name"]`. +* The `table` parameter contains the schema table the current call belongs to, including all table hints and columns. For example, the table name can be accessed with `table["name"]`. * You can also add config values and secrets to the function arguments, see below! - ## Adding config variables and secrets The destination decorator supports settings and secrets variables. If you, for example, plan to connect to a service that requires an API secret or a login, you can do the following: @@ -106,15 +97,11 @@ api_key="" ## Destination state -The destination keeps a local record of how many `DataItems` were processed, so if you, for example, use the custom destination to push `DataItems` to a remote API, and this -API becomes unavailable during the load resulting in a failed `dlt` pipeline run, you can repeat the run of your pipeline at a later stage and the destination will continue -where it left of. For this reason, it makes sense to choose a batch size that you can process in one transaction (say one API request or one database transaction) so that if this -request or transaction fails repeatedly, you can repeat it at the next run without pushing duplicate data to your remote location. +The destination keeps a local record of how many `DataItems` were processed. So, if you, for example, use the custom destination to push `DataItems` to a remote API, and this API becomes unavailable during the load resulting in a failed `dlt` pipeline run, you can repeat the run of your pipeline at a later stage, and the destination will continue where it left off. For this reason, it makes sense to choose a batch size that you can process in one transaction (say one API request or one database transaction) so that if this request or transaction fails repeatedly, you can repeat it at the next run without pushing duplicate data to your remote location. ## Concurrency -Calls to the destination function by default will be executed on multiple threads, so you need to make sure you are not using any non-thread-safe nonlocal or global variables from outside -your destination function. If you need to have all calls be executed from the same thread, you can set the `workers` config variable of the load step to 1. +Calls to the destination function by default will be executed on multiple threads, so you need to make sure you are not using any non-thread-safe nonlocal or global variables from outside your destination function. If you need to have all calls be executed from the same thread, you can set the `workers` config variable of the load step to 1. :::tip For performance reasons, we recommend keeping the multithreaded approach and making sure that you, for example, are using threadsafe connection pools to a remote database or queue. @@ -133,13 +120,13 @@ There are multiple ways to reference the custom destination function you want to # reference function directly p = dlt.pipeline("my_pipe", destination=local_destination_func) ``` -- Directly via destination reference. In this case, don't use decorator for the destination function. +- Directly via destination reference. In this case, don't use the decorator for the destination function. ```py # file my_destination.py from dlt.common.destination import Destination - # don't use decorator + # don't use the decorator def local_destination_func(items: TDataItems, table: TTableSchema) -> None: ... @@ -151,7 +138,7 @@ There are multiple ways to reference the custom destination function you want to ) ) ``` -- Via fully qualified string to function location (can be used from `config.toml` or ENV vars). Destination function should be located in another file. +- Via a fully qualified string to function location (can be used from `config.toml` or ENV vars). The destination function should be located in another file. ```py # file my_pipeline.py @@ -166,7 +153,6 @@ There are multiple ways to reference the custom destination function you want to ) ``` - ## Write disposition `@dlt.destination` will forward all normalized `DataItems` encountered during a pipeline run to the custom destination function, so there is no notion of "write dispositions". @@ -178,4 +164,4 @@ There are multiple ways to reference the custom destination function you want to ## What's next * Check out our [Custom BigQuery Destination](../../examples/custom_destination_bigquery/) example. -* Need a help with building a custom destination? Ask your questions in our [Slack Community](https://dlthub.com/community) technical help channel. +* Need help with building a custom destination? Ask your questions in our [Slack Community](https://dlthub.com/community) technical help channel. \ No newline at end of file diff --git a/docs/website/docs/intro.md b/docs/website/docs/intro.md index 747dbdabdd..d6d823ad47 100644 --- a/docs/website/docs/intro.md +++ b/docs/website/docs/intro.md @@ -19,7 +19,7 @@ pip install dlt ``` Unlike other solutions, with dlt, there's no need to use any backends or containers. Simply import `dlt` in a Python file or a Jupyter Notebook cell, and create a pipeline to load data into any of the [supported destinations](dlt-ecosystem/destinations/). You can load data from any source that produces Python data structures, including APIs, files, databases, and more. `dlt` also supports building a [custom destination](dlt-ecosystem/destinations/destination.md), which you can use as reverse ETL. -The library will create or update tables, infer data types and handle nested data automatically. Here are a few example pipelines: +The library will create or update tables, infer data types, and handle nested data automatically. Here are a few example pipelines: