huaxingao commented on code in PR #16961:
URL: https://github.com/apache/iceberg/pull/16961#discussion_r3486524548


##########
format/index.md:
##########
@@ -0,0 +1,322 @@
+---
+title: "Index Spec"
+---
+<!--
+ - 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 Index Specification
+
+## Background and Motivation
+
+Indexes enable query engines to locate relevant rows without scanning entire 
datasets.
+They can accelerate point lookups, range predicates, and other retrieval 
patterns
+while preserving Iceberg's table format, snapshot isolation, and 
interoperability.
+
+This specification defines:
+
+- A portable metadata format for indexes
+- A catalog-managed index object independent from table metadata
+- A common storage architecture for index data
+- A framework for defining new index types and transform functions
+
+Indexes are optional. Engines may choose to create, maintain, consume, or 
ignore them.
+
+## Goals
+
+- Define a common metadata format for indexes
+- Allow indexes to evolve independently from table metadata
+- Enable index sharing across engines
+- Provide a foundation for future index types
+
+## Definitions
+
+### Index Type
+
+The index type defines the logical category of an index and the class of 
queries it is designed to accelerate.
+
+The following index type is defined in this specification:
+
+| Type   |
+|--------|
+| SCALAR |
+
+The following index types are reserved for future specifications:
+
+| Type   |
+|--------|
+| VECTOR |
+| TERM   |
+
+The index type communicates the capabilities of an index to query engines and 
helps determine whether an index is
+applicable to a particular query.
+
+### Index Transform Function
+
+The index transform function defines how the index organization key is derived 
from source table columns when rows are
+stored in the index.
+
+The transform function determines the physical organization of the indexed 
data and therefore influences which query
+patterns can efficiently leverage the index.
+
+The following index types are reserved for future specifications:
+
+| Transform |
+|-----------|
+| IDENTITY  |
+| HASH      |
+| HILBERT   |
+
+The following transform functions are reserved for future specifications:
+
+| Transform |
+|-----------|
+| IVF       |
+
+Index Instances may share the same index type while using different transform 
functions.
+
+### Index Instance
+
+An index instance is a concrete realization of an index type and function 
applied to a specific table.
+
+Users create index instances by specifying:
+
+- The source table
+- The index type
+- The transform function
+- The indexed columns
+- The included columns
+- Index properties
+
+Multiple instances of the same index type may exist for a table.
+
+### Index Snapshot
+
+An index snapshot is an immutable version of the index data generated from a 
specific table snapshot.
+
+Each index snapshot references a complete set of index files and contains all 
data from the referenced table snapshot.
+
+## Overview
+
+Indexes are stored as independent catalog objects.
+
+Like Iceberg tables, views, and functions:
+
+- Metadata and data files are immutable
+- Updates create new metadata files
+- Catalogs perform atomic metadata swaps
+
+Index data is stored separately from metadata.
+
+Each index snapshot references a tracking file which describes the leaf files 
belonging to the snapshot.
+
+```text
+Index Metadata
+    |
+    +-- Index Snapshot
+            |
+            +-- Tracking File
+                    |
+                    +-- Leaf Data Files
+```
+
+Transform functions derive a transform value from the key columns and 
determine how index entries are organized within
+the leaf files.
+- The transform value space is divided into non-overlapping ranges.
+- Each leaf file stores entries for a single range.
+- The tracking file stores range bounds for each leaf file.
+
+This structure enables efficient planning while keeping the data layout 
flexible for different index implementations.
+
+## Index Metadata
+
+The index metadata file stores the index definition and snapshot history.
+
+### Index Metadata File
+
+| Requirement | Field               | Type                     | Description   
                                  |
+|-------------|---------------------|--------------------------|-------------------------------------------------|
+| required    | format-version      | int                      | Index 
specification version                     |
+| required    | uuid                | string                   | Stable UUID 
assigned at creation                |
+| required    | table-uuid          | string                   | UUID of the 
indexed table                       |
+| required    | location            | string                   | Index root 
location                             |
+| required    | type                | string                   | Logical index 
type                              |
+| required    | transform-function  | string                   | Physical 
organization transform                 |
+| required    | key-column-ids      | list<int>                | Indexed 
columns                                 |
+| optional    | included-column-ids | list<int>                | Included 
columns                                |
+| required    | file-format         | string                   | Leaf file 
format                                |
+| optional    | properties          | map<string,string>       | Index 
properties applicable for every snapshot  |
+| required    | snapshots           | list<index-snapshot>     | Known index 
snapshots                           |
+
+## Index Snapshot
+
+Each index snapshot corresponds to one version of the index data.
+
+| Requirement | Field                    | Type               | Description    
                                                     |
+|-------------|--------------------------|--------------------|---------------------------------------------------------------------|
+| required    | snapshot-id              | long               | Index snapshot 
identifier                                           |
+| required    | source-table-snapshot-id | long               | Source table 
snapshot                                               |
+| required    | timestamp-ms             | long               | Snapshot 
creation timestamp                                         |
+| required    | tracking-file            | string             | Tracking file 
location                                              |
+| optional    | properties               | map<string,string> | Snapshot 
properties specific to this snapshot                       |
+| optional    | key_metadata             | binary             | 
Implementation-specific key metadata, for tracking file encryption. |
+
+## Tracking File
+
+Each index snapshot references exactly one tracking file.
+
+It contains summary metadata about all leaf files belonging to the index 
snapshot and enables efficient planning
+without scanning every leaf file.
+
+The tracking file may be stored using any supported metadata file format.
+
+### Tracking File Entry
+
+Each entry describes a single leaf file.
+
+### Tracking File Entry
+
+Each tracking file contains a collection of tracking file entries. A tracking 
file entry describes a single leaf file
+tracked by an index snapshot. The fields are the subset of the V4 manifest 
entry fields that are relevant to planning
+queries against the index.
+Entries contain aggregated statistics for all referenced leaf files, enabling 
engines to perform pruning and planning
+without opening every leaf file.
+
+| Field ID | Name               | Type    | Requirement  | Description         
                                                                                
         |
+|----------|--------------------|---------|--------------|--------------------------------------------------------------------------------------------------------------|
+| 100      | location           | string  | required     | Location of the 
referenced file.                                                                
             |
+| 101      | file_format        | string  | required     | File format name, 
such as parquet, avro, or orc.                                                  
           |
+| 103      | record_count       | long    | required     | Number of records 
contained in the referenced file or aggregated under the referenced tracking 
file.         |
+| 104      | file_size_in_bytes | long    | required     | Total file size in 
bytes.                                                                          
          |
+| 146      | content_stats      | struct  | optional     | Statistics used for 
planning and pruning, including transform-key statistics and optional column 
statistics. |
+| 131      | key_metadata       | binary  | optional     | 
Implementation-specific key metadata, used for leaf file encryption.            
                             |

Review Comment:
   `key_metadata` -> `key-metadata`?



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

Reply via email to