Skip to content
Closed
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
55 changes: 55 additions & 0 deletions format/materialized-view-spec.md
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.

Copy link
Copy Markdown
Contributor

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

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
Iceberg Materialized views are a way to store the results of an Iceberg view to reuse the computation in subsequent queries.
Iceberg materialized views are a way to store the results of an Iceberg view to reuse the computation in subsequent queries.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

minor suggestion

Iceberg materialized view stores the precomputed results of an Iceberg view, which can be reused in subsequent queries to avoid recomputation.


## 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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The 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:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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 -. so maybe like view-materialized and view-storage-table.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I have removed the iceberg prefix. Not quite sure if there is a rule about about hyphen vs dot. For example, there is a table property: schema.name-mapping.default in the table spec.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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 schema.name-mapping.default as an example, there might be other schema related properties in the future, thus the schema. prefix. In general . is used for grouping purpose.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Ack. I have removed iceberg. already. I am thinking of introducing mv. now for the grouping purpose.

| 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.|

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

is iceberg.base.table.snapshot.[UUID] is the better name for this property? which is also inline with the iceberg.child.view.version.[UUID]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The 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 IDs).
Maybe we can update it as "These properties store the current snapshot ID of the base tables ..."

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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 base-tables-snapshots. the value could be a JSON string like

{ "table1" : {"uuid": "xxx", "snapshot-id": 1} , "table2" : {"uuid": "xxx", "snapshot-id": 2} }

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|

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
| `iceberg.view.version` | This property stores the version of the view that this storage table is associated with at the time of materialization|
| `iceberg.view.version` | This property stores the version ID of the view that this storage table is associated with at the time of materialization.|

| `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.|

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The 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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I have updated the text description to this:

If the top level materialized view is nested on top of other views, 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 'child.view.version.' followed by the UUID of the child view.

Please let me know if this clarifies it. I have added examples too. This is explained in Example 3.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks. I understood it now. But the fact that event_type_count and event_type_count has to be created before the event_analysis, makes them parent instead of child view here? Do we need to change the property name?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The 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.

@ajantha-bhat ajantha-bhat May 8, 2024

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

OK

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The 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.|
| `iceberg.child.view.version.[UUID]` | These properties store the version ID 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.|

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The 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 child views here. Could you review this thread and let me know if it changes the perspective here?


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`.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
* The version of the view using the table as the storage table is equal to the value stored in `iceberg.view.version`.
* The current version ID of the view using the table as the storage table is equal to the value stored in `iceberg.view.version`.

* 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]`.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The 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]`.
* For each child view `V` with `UUID` in `iceberg.child.view.version.[UUID]`, the current version ID of `V` is equal to the value stored in `iceberg.child.view.version.[UUID]`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

why does child views' version matter for the parent view/storage table?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I have added an Examples section. Could you check Example 3?


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.