-
Notifications
You must be signed in to change notification settings - Fork 3.4k
[Spec] Add Iceberg Materialized View Spec #10280
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,55 @@ | ||||||
| <!-- | ||||||
| - 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. | ||||||
| --> | ||||||
|
|
||||||
| # Iceberg Materialized View Spec | ||||||
|
|
||||||
| ## Background and Motivation | ||||||
| Iceberg views are a powerful tool to abstract complex queries and share them among different engines. | ||||||
| However, such views are not materialized by default, which means that they are re-computed every time they are queried. | ||||||
| This can be inefficient for complex queries that are computed frequently. | ||||||
| Iceberg Materialized views are a way to store the results of an Iceberg view to reuse the computation in subsequent queries. | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. minor suggestion
|
||||||
|
|
||||||
| ## Goals | ||||||
| The goal of this spec is to define the metadata associated with materialized views in Iceberg. | ||||||
| Such metadata allows creating and querying Iceberg materialized views across different engines. | ||||||
|
|
||||||
| ## Specification | ||||||
| A materialized view is an Iceberg view with a respective Iceberg table that stores the results of the view query. | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean, an 'associated Iceberg table'? |
||||||
| An Iceberg view is considered a materialized view if it has the `iceberg.materialized.view` property set to `true`. | ||||||
| A materialized view must also reference the storage table identifier in its `iceberg.materialized.view.storage.table` property. | ||||||
|
|
||||||
| The specification for the materialized view properties on the view is as follows: | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. regarding property name iceberg.materialized.view, it is redundant to have iceberg there. metadata field name uses hyphen
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have removed the
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 for Steven's suggestion, which is what I also wrote in the comment below. Take
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ack. I have removed |
||||||
| | Property name | Description | | ||||||
| |--------------------------------------------|-------------------------------------------------------------------------| | ||||||
| | `iceberg.materialized.view` | This property is used to mark whether a view is a materialized view. If set to `true`, the view is treated as a materialized view.| | ||||||
| | `iceberg.materialized.view.storage.table` | This property specifies the identifier of the storage table associated with the materialized view.| | ||||||
|
|
||||||
| In addition to the properties on the view, the storage table associated with the materialized view has the following properties: | ||||||
|
|
||||||
| | Property name | Description | | ||||||
| |--------------------------------------|-------------------------------------------------------------------------------| | ||||||
| | `iceberg.base.snapshot.[UUID]` | These properties store the snapshot IDs of the base tables at the time the materialized view's data was last updated. Each property is prefixed with `iceberg.base.snapshot.` followed by the UUID of the base table.| | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, isn't the current snapshot id enough? (asking because we have mentioned as And If the stored snapshot id is expired from the base table, we can't incrementally refresh MV? because we can't map that snapshot? In this case MV does a full refresh (expensive)? Should expire snapshots should be made MV aware so that it gives warning while expiring the referenced snapshots?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. UUID suffix in the property name weren't quite readable. I wondering if we should have a consolidated property for base tables, like The reason is that all base tables tracking should be updated in one shot anyway. They are also always validated together. With JSON, we can also store additional metadata in the future. |
||||||
| | `iceberg.view.version` | This property stores the version of the view that this storage table is associated with at the time of materialization| | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
| | `iceberg.child.view.version.[UUID]` | These properties store the version of the child views that the top level view is associated with at the time of materialization. Each property is prefixed with `iceberg.child.view.version.` followed by the UUID of the child view.| | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just by reading this line, I couldn't understand what are these child views? how it is created? and why it is required? maybe adding an example at Appendix section can be helpful.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have updated the text description to this:
Please let me know if this clarifies it. I have added examples too. This is explained in Example 3.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks. I understood it now. But the fact that
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I do not view it form the creation time point of view (which does not constitute a hierarchical relationship either), but rather from a view graph point of view. This graph will form a tree, where the inner views are children.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. shouldn't the lineage to child views be defined in the view metadata (not storage table metadata)? child views refer to the parent MV by view name (not storage table name).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure if we mean the same thing when referring to |
||||||
|
|
||||||
| A storage table is considered fresh if all the following conditions are true: | ||||||
| * For each table `T` with `UUID` in `iceberg.base.snapshot.[UUID]`, the current snapshot ID of `T` is equal to the value stored in `iceberg.base.snapshot.[UUID]`. | ||||||
| * The version of the view using the table as the storage table is equal to the value stored in `iceberg.view.version`. | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
| * For each child view `V` with `UUID` in `iceberg.child.view.version.[UUID]`, the version of `V` is equal to the value stored in `iceberg.child.view.version.[UUID]`. | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. why does child views' version matter for the parent view/storage table?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have added an |
||||||
|
|
||||||
| Implementations may elect to leverage the storage table with more relaxed freshness conditions, such as allowing base table stored snapshots to be different from current snapshots, as long as the respective snapshot timestamp difference is within a given time range. | ||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: remove however.
However, such views->Such logical views