From 0f470d4e92c7c4722bba6c6e8164fed3ceac2a65 Mon Sep 17 00:00:00 2001 From: Jimmy Ma Date: Thu, 8 Aug 2024 14:29:54 -0700 Subject: [PATCH 1/4] Add FROD to doc --- .../core-concepts/sync-modes/README.md | 11 ++-- .../full-refresh-overwrite-deduped.md | 50 +++++++++++++++++++ 2 files changed, 57 insertions(+), 4 deletions(-) create mode 100644 docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md diff --git a/docs/using-airbyte/core-concepts/sync-modes/README.md b/docs/using-airbyte/core-concepts/sync-modes/README.md index be548d4d04d2..49ca9994ebb5 100644 --- a/docs/using-airbyte/core-concepts/sync-modes/README.md +++ b/docs/using-airbyte/core-concepts/sync-modes/README.md @@ -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. diff --git a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md new file mode 100644 index 000000000000..32528116ba9d --- /dev/null +++ b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md @@ -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. + +## 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. + +## 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). From 0c66ce65d94b74bb2b7f1e1eedc991322164bf7e Mon Sep 17 00:00:00 2001 From: Jimmy Ma Date: Thu, 8 Aug 2024 16:27:09 -0700 Subject: [PATCH 2/4] typo --- .../core-concepts/sync-modes/full-refresh-overwrite-deduped.md | 2 +- .../core-concepts/sync-modes/full-refresh-overwrite.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md index 32528116ba9d..69704634b392 100644 --- a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md +++ b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md @@ -42,7 +42,7 @@ data in the destination _after_ the sync (note how the old value of "bash" is no ## 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. +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 diff --git a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite.md b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite.md index f918cf622350..72347e692dcb 100644 --- a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite.md +++ b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite.md @@ -42,7 +42,7 @@ data in the destination _after_ the sync (note how the old value of "bash" is no ## 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. +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 From 594f572016dca1b1b10e4ed1315a11bc8ee7c390 Mon Sep 17 00:00:00 2001 From: Jimmy Ma Date: Thu, 8 Aug 2024 16:28:38 -0700 Subject: [PATCH 3/4] more typos --- .../core-concepts/sync-modes/full-refresh-overwrite-deduped.md | 2 +- .../core-concepts/sync-modes/full-refresh-overwrite.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md index 69704634b392..53bd07c5d636 100644 --- a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md +++ b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md @@ -42,7 +42,7 @@ data in the destination _after_ the sync (note how the old value of "bash" is no ## 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 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. +The mechanism by which a destination connector accomplishes the full refresh will vary wildly from destination to destination. 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 diff --git a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite.md b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite.md index 72347e692dcb..dfa60f8aa982 100644 --- a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite.md +++ b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite.md @@ -42,7 +42,7 @@ data in the destination _after_ the sync (note how the old value of "bash" is no ## 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 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. +The mechanism by which a destination connector accomplishes the full refresh will vary wildly from destination to destination. 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 From 35810f42449b90074e8d519857933f51d107b971 Mon Sep 17 00:00:00 2001 From: Jimmy Ma Date: Thu, 8 Aug 2024 16:38:41 -0700 Subject: [PATCH 4/4] link resumablity --- .../core-concepts/sync-modes/full-refresh-overwrite-deduped.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md index 53bd07c5d636..19138398c160 100644 --- a/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md +++ b/docs/using-airbyte/core-concepts/sync-modes/full-refresh-overwrite-deduped.md @@ -10,6 +10,8 @@ The **Full Refresh** modes are the simplest methods that Airbyte uses to sync da 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. +Full Refresh syncs may be [resumed](/understanding-airbyte/resumability) (to recover from transient errors for example), when this happens, duplicate may happen. If avoiding duplicate is a strong requirement, we recommend using **Overwrite + Deduped** over **Overwrite**. Bear in mind that deduplication incurs additional warehouse costs. + ## Example Behavior On the nth sync of a full refresh connection: