[Improvement]: Solve High Memory Usage in Planning Phase Caused by Massive Deleted Files

Abierto
  • ¿Algo no está bien?
#4,255 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java
Área
data-engineering, performance

Línea de trabajo

Comienza localizando el índice de planificación y su asociación DeleteFile-to-DataFile; después, sigue cómo la fase de planificación construye y conserva esas relaciones. Se considera terminado cuando la asociación utiliza la representación comprimida propuesta, mientras la planificación sigue siendo correcta y se reduce el consumo excesivo de memoria para tablas con muchos archivos pequeños eliminados.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

type:improvement
Search before asking
  • I have searched in the issues and found no similar issues.
What would you like to be improved?

Currently, the planning phase suffers from excessive memory consumption when dealing with tables containing massive deleted small files. The root cause lies in the inefficient storage of file relationships: a single DeleteFile is often associated with multiple DataFiles.
In the current implementation, these associations are likely stored as explicit lists or object references. When a table has a large volume of data files referencing the same delete files, the memory overhead for maintaining these references grows unboundedly. This redundancy causes the planning index to consume significantly more heap memory than necessary, leading to potential Out-Of-Memory (OOM) errors and degraded performance during query planning.

How should we improve?

I propose optimizing the memory layout of the planning index by introducing RoaringBitmap to compress the association between DeleteFile and DataFile. Instead of storing explicit lists of file IDs or object references, we can use RoaringBitmaps to represent the set of DataFile IDs associated with each DeleteFile. RoaringBitmap provides highly efficient compression for integer sets (file IDs), significantly reducing the memory footprint required to store these many-to-many relationships.

Are you willing to submit PR?
  • Yes I am willing to submit a PR!
Subtasks

No response

Code of Conduct
Lenguaje dominante
Java
Estrellas
1.2k
Forks
399
Merge medio
4 d 8 h
PR fusionados (30 d)
24

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/amoro

Todos los issues de apache/amoro

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.