Skip to content
This repository has been archived by the owner on Feb 6, 2024. It is now read-only.

Commit

Permalink
Published versioned 1.4.1 docs
Browse files Browse the repository at this point in the history
  • Loading branch information
Fokko committed Oct 23, 2023
1 parent 1a8c288 commit 0989dd8
Show file tree
Hide file tree
Showing 34 changed files with 826 additions and 374 deletions.
121 changes: 46 additions & 75 deletions docs/content/aws.md

Large diffs are not rendered by default.

25 changes: 13 additions & 12 deletions docs/content/branching-and-tagging.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@ aliases:
menu:
main:
parent: Tables
identifier: tables_branching
weight: 0
---

Expand All @@ -30,9 +31,9 @@ menu:

## Overview

Iceberg table metadata maintains a log of snapshots which represent the changes applied to a table.
Iceberg table metadata maintains a snapshot log, which represents the changes applied to a table.
Snapshots are fundamental in Iceberg as they are the basis for reader isolation and time travel queries.
For controlling metadata size and storage costs, Iceberg provides snapshot lifecycle management procedures such as [`expire_snapshots`](../../spark/spark-procedures/#expire-snapshots) for removing unused snapshots and no longer neccessary data files based on table snapshot retention properties.
For controlling metadata size and storage costs, Iceberg provides snapshot lifecycle management procedures such as [`expire_snapshots`](../spark-procedures/#expire-snapshots) for removing unused snapshots and no longer necessary data files based on table snapshot retention properties.

**For more sophisticated snapshot lifecycle management, Iceberg supports branches and tags which are named references to snapshots with their own independent lifecycles. This lifecycle is controlled by branch and tag level retention policies.**
Branches are independent lineages of snapshots and point to the head of the lineage.
Expand All @@ -53,32 +54,32 @@ Tags can be used for retaining important historical snapshots for auditing purpo

![Historical Tags](../img/historical-snapshot-tag.png)

The above diagram demonstrates retaininig important historical snapshot with the following retention policy, defined
The above diagram demonstrates retaining important historical snapshot with the following retention policy, defined
via Spark SQL.

1. Retain 1 snapshot per week for 1 month. This can be achieved by tagging the weekly snapshot and setting the tag retention to be a month.
snapshots will be kept, and the branch reference itself will be retained for 1 week.
```sql
-- Create a tag for the first end of week snapshot. Retain the snapshot for a week
ALTER TABLE prod.db.table CREATE TAG 'EOW-01' AS OF VERSION 7 RETAIN 7 DAYS
ALTER TABLE prod.db.table CREATE TAG `EOW-01` AS OF VERSION 7 RETAIN 7 DAYS
```

2. Retain 1 snapshot per month for 6 months. This can be achieved by tagging the monthly snapshot and setting the tag retention to be 6 months.
```sql
-- Create a tag for the first end of month snapshot. Retain the snapshot for 6 months
ALTER TABLE prod.db.table CREATE TAG 'EOM-01' AS OF VERSION 30 RETAIN 180 DAYS
ALTER TABLE prod.db.table CREATE TAG `EOM-01` AS OF VERSION 30 RETAIN 180 DAYS
```

3. Retain 1 snapshot per year forever. This can be achieved by tagging the annual snapshot. The default retention for branches and tags is forever.
```sql
-- Create a tag for the end of the year and retain it forever.
ALTER TABLE prod.db.table CREATE TAG 'EOY-2023' AS OF VERSION 365
ALTER TABLE prod.db.table CREATE TAG `EOY-2023` AS OF VERSION 365
```

4. Create a temporary "test-branch" which is retained for 7 days and the latest 2 snapshots on the branch are retained.
```sql
-- Create a branch "test-branch" which will be retained for 7 days along with the latest 2 snapshots
ALTER TABLE prod.db.table CREATE BRANCH test-branch RETAIN 7 DAYS WITH RETENTION 2 SNAPSHOTS
ALTER TABLE prod.db.table CREATE BRANCH `test-branch` RETAIN 7 DAYS WITH SNAPSHOT RETENTION 2 SNAPSHOTS
```

### Audit Branch
Expand All @@ -90,7 +91,7 @@ The above diagram shows an example of using an audit branch for validating a wri
1. First ensure `write.wap.enabled` is set.
```sql
ALTER TABLE db.table SET TBLPROPERTIES (
'write.wap.enabled''true'
'write.wap.enabled'='true'
)
```
2. Create `audit-branch` starting from snapshot 3, which will be written to and retained for 1 week.
Expand All @@ -100,21 +101,21 @@ ALTER TABLE db.table CREATE BRANCH `audit-branch` AS OF VERSION 3 RETAIN 7 DAYS
3. Writes are performed on a separate `audit-branch` independent from the main table history.
```sql
-- WAP Branch write
SET spark.wap.branch = 'audit-branch'
SET spark.wap.branch = audit-branch
INSERT INTO prod.db.table VALUES (3, 'c')
```
4. A validation workflow can validate (e.g. data quality) the state of `audit-branch`.
5. After validation, the main branch can be `fastForward` to the head of `audit-branch` to update the main table state.
```java
table.manageSnapshots().fastForward("main", "audit-branch").commit()
```sql
CALL catalog_name.system.fast_forward('prod.db.table', 'main', 'audit-branch')
```
6. The branch reference will be removed when `expireSnapshots` is run 1 week later.

## Usage

Creating, querying and writing to branches and tags are supported in the Iceberg Java library, and in Spark and Flink engine integrations.

- [Iceberg Java Library](../../java-api-quickstart/#branching-and-tagging)
- [Iceberg Java Library](../java-api-quickstart/#branching-and-tagging)
- [Spark DDLs](../spark-ddl/#branching-and-tagging-ddl)
- [Spark Reads](../spark-queries/#time-travel)
- [Spark Branch Writes](../spark-writes/#writing-to-branches)
Expand Down
Loading

0 comments on commit 0989dd8

Please sign in to comment.