Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document Full Refresh Overwrite Deduped #43413

Merged
merged 4 commits into from
Aug 8, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions docs/using-airbyte/core-concepts/sync-modes/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,13 +12,16 @@ A sync mode governs how Airbyte reads from a source and writes to a destination.
- Method 2: Using change data capture. Only supported by some sources. See [CDC](../../../understanding-airbyte/cdc.md) for more info.
2. Full Refresh: Read everything in the source.
2. The second part of the sync mode name denotes how the destination connector writes data. This is not affected by how the source connector produced the data:
1. Overwrite: Overwrite by first deleting existing data in the destination.
1. Overwrite: Overwrite by replacing pre-existing data in the destination.
2. Append: Write by adding data to existing tables in the destination.
3. Deduped History: Write by first adding data to existing tables in the destination to keep a history of changes. The final table is produced by de-duplicating the intermediate ones using a primary key.
3. Append Deduped: Write by first adding data to existing tables in the destination to keep a history of changes. The final table is
produced by de-duplicating the intermediate ones using a primary key.
4. Overwrite Deduped: Overwrite by replacing pre-existing data in the destination and deduplicate the final data using a primary key.

A sync mode is a combination of a source and destination mode together. The UI exposes the following options, whenever both source and destination connectors are capable to support it for the corresponding stream:

- [Incremental Append](./incremental-append.md): Sync new records from stream and append data in destination.
- [Incremental Append + Deduped](./incremental-append-deduped.md): Sync new records from stream and append data in destination, also provides a de-duplicated view mirroring the state of the stream in the source.
- [Full Refresh Overwrite](./full-refresh-overwrite.md): Sync the whole stream and replace data in destination by overwriting it.
- [Full Refresh Append](./full-refresh-append.md): Sync the whole stream and append data in destination.
- [Incremental Append](./incremental-append.md): Sync new records from stream and append data in destination.
- [Full Refresh Overwrite](./full-refresh-overwrite.md): Sync the whole stream and replace data in destination by overwriting it.
- [Full Refresh Overwrite + Deduped](./full-refresh-overwrite-deduped.md): Sync the whole stream and replace data in destination by overwriting it, also de-duplicate the data.
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
---
products: all
---

# Full Refresh - Overwrite + Deduped

## Overview

The **Full Refresh** modes are the simplest methods that Airbyte uses to sync data, as they always retrieve all available information requested from the source, regardless of whether it has been synced before. This contrasts with [**Incremental sync**](./incremental-append.md), which does not sync data that has already been synced before.

In the **Overwrite + Deduped** variant, new syncs will replace all data in the existing destination table and then pull the new data in. Therefore, data that has been removed from the source after an old sync will be deleted in the destination table. The **deduped** variant also means that the data in the final table will be unique per primary key \(unlike [Full Refresh Overwrite](./full-refresh-overwrite.md)\). This is determined by sorting the data using the cursor field and keeping only the latest de-duplicated data row.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a quick sentence here about "As Full Refresh syncs are Resumable as much as possible, we recommend Full Refresh Overwrite Dedup if avoiding duplicates is a strong requirement. Bear in mind this incurs additional warehouse costs.', and linking the Resumable doc page in there.

Something like this!

## Example Behavior

On the nth sync of a full refresh connection:

## _Replace_ existing data with new data. The connection does not create any new tables.

data in the destination _before_ the sync:

| Languages |
| :-------- |
| Python |
| Java |
| Bash |

new data in the source:

| Languages |
| :-------- |
| Python |
| Java |
| Ruby |

data in the destination _after_ the sync (note how the old value of "bash" is no longer present):

| Languages |
| :-------- |
| Python |
| Java |
| Ruby |

## Destination-specific mechanism for full refresh

The mechanism by which a destination connector acomplishes the full refresh will vary wildly from destination to destinaton. For our certified database and data warehouse destinations, we will be recreating the final table each sync. This allows us leave the previous sync's data viewable by writing to a "final-table-tmp" location as the sync is running, and at the end dropping the olf "final" table, and renaming the new one into place. That said, this may not possible for all destinations, and we may need to erase the existing data at the start of each full-refresh sync.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The mechanism by which a destination connector acomplishes the full refresh will vary wildly from destination to destinaton. For our certified database and data warehouse destinations, we will be recreating the final table each sync. This allows us leave the previous sync's data viewable by writing to a "final-table-tmp" location as the sync is running, and at the end dropping the olf "final" table, and renaming the new one into place. That said, this may not possible for all destinations, and we may need to erase the existing data at the start of each full-refresh sync.
The mechanism by which a destination connector acomplishes the full refresh will vary wildly from destination to destinaton. For our certified database and data warehouse destinations, we will be recreating the final table each sync. This allows us leave the previous sync's data viewable by writing to a "final-table-tmp" location as the sync is running, and at the end dropping the old "final" table, and renaming the new one into place. That said, this may not possible for all destinations, and we may need to erase the existing data at the start of each full-refresh sync.


## Related information

- [An overview of Airbyte’s replication modes](https://airbyte.com/blog/understanding-data-replication-modes).
- [Explore Airbyte's full refresh data synchronization](https://airbyte.com/tutorials/full-data-synchronization).
Loading