amogh-jahagirdar commented on code in PR #6723: URL: https://github.com/apache/iceberg/pull/6723#discussion_r1155213330
########## docs/branching-and-tagging.md: ########## @@ -0,0 +1,98 @@ +--- +title: "Branching and Tagging" +url: branching +aliases: + - "tables/branching" +menu: + main: + parent: Tables + weight: 0 +--- + +<!-- + - Licensed to the Apache Software Foundation (ASF) under one or more + - contributor license agreements. See the NOTICE file distributed with + - this work for additional information regarding copyright ownership. + - The ASF licenses this file to You under the Apache License, Version 2.0 + - (the "License"); you may not use this file except in compliance with + - the License. You may obtain a copy of the License at + - + - http://www.apache.org/licenses/LICENSE-2.0 + - + - Unless required by applicable law or agreed to in writing, software + - distributed under the License is distributed on an "AS IS" BASIS, + - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + - See the License for the specific language governing permissions and + - limitations under the License. + --> + +# Branching and Tagging + +## Overview + +Iceberg table metadata maintains a log of snapshots which represent 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 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. +Branches and tags have a maximum reference age property which control when the reference to the snapshot itself should be expired. +Branches have retention properties which define the minimum number of snapshots to retain on a branch as well as the maximum age of individual snapshots to retain on the branch. +These properties are used when the expireSnapshots procedure is run. +For details on the algorithm for expireSnapshots, refer to the [spec](../../../spec#snapshot-retention-policy). + +## Use Cases + +Branching and tagging can be used for handling GDPR requirements and retaining important historical snapshots for auditing. +For example, branching and tagging can be used to faciliate the following audit use case which requires different levels of retention. + +1. Retain the latest 5 days of snapshots for 1 week. This can be achieved by setting a branch retention policy where 5 days worth of snapshots will be kept, and the branch reference itself will be retained for 1 week. +2. 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. +3. 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. +4. Retain 1 snapshot per year forever. This can be achieved by tagging the annual snapshot. The default retention for branches and tags is forever. + +Branches can also be used as part of data engineering workflows, for enabling experimental branches for testing and validating new jobs. +See below for some examples of how branching and tagging can facilitate these use cases. + +### Historical Tags + + + +The above diagram shows an example of using tag to retain historical snapshots. +In this case a end of year tag is created for the final snapshot in the year, and the tagged snapshot has a retention of 5 years for compliance reasons. +The tags can be created with the following Spark DDLs + +```sql +-- Specify the snapshot ID 3 and 5 for EOY-2022 and EOY-2023 respectively. Retain for 1825 days (5 years) +ALTER TABLE prod.db.table CREATE TAG 'EOY-2022' AS OF VERSION 3 RETAIN 1825 DAYS +ALTER TABLE prod.db.table CREATE TAG 'EOY-2023' AS OF VERSION 5 RETAIN 1825 DAYS +``` + +### Audit Branch + + + +The above diagram shows an example of using an audit branch for validating a write workflow. + +1. Writes are performed on a separate `audit-branch` independent from the main table history. +```scala +-- WAP Branch write +spark.conf().set(SparkSQLProperties.WAP_BRANCH, "audit"); +spark.sql("INSERT INTO prod.db.table VALUES (3, 'c')"); +``` +2. A validation workflow can validate (e.g. data quality) the state of `audit-branch`. +3. 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() Review Comment: I like the idea of showing retention policy here as well so I'm putting that. In my mind retention is not just powerful for just GDPR use cases or historical snapshots, but can be used as a generic cleanup mechanism. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
