Dlaczego wydajność zapytania różni się w kolumnach zagnieżdżonych w Spark SQL?

Question

piszę niektóre dane w formacie parkietu przy użyciu Spark SQL gdzie powstały schemat wygląda tak:

root 
|-- stateLevel: struct (nullable = true) 
| |-- count1: integer (nullable = false) 
| |-- count2: integer (nullable = false) 
| |-- count3: integer (nullable = false) 
| |-- count4: integer (nullable = false) 
| |-- count5: integer (nullable = false) 
|-- countryLevel: struct (nullable = true) 
| |-- count1: integer (nullable = false) 
| |-- count2: integer (nullable = false) 
| |-- count3: integer (nullable = false) 
| |-- count4: integer (nullable = false) 
| |-- count5: integer (nullable = false) 
|-- global: struct (nullable = true) 
| |-- count1: integer (nullable = false) 
| |-- count2: integer (nullable = false) 
| |-- count3: integer (nullable = false) 
| |-- count4: integer (nullable = false) 
| |-- count5: integer (nullable = false) 

Mogę również przekształcić te same dane w bardziej płaskiej schematu, który wygląda tak:

root 
|-- stateLevelCount1: integer (nullable = false) 
|-- stateLevelCount2: integer (nullable = false) 
|-- stateLevelCount3: integer (nullable = false) 
|-- stateLevelCount4: integer (nullable = false) 
|-- stateLevelCount5: integer (nullable = false) 
|-- countryLevelCount1: integer (nullable = false) 
|-- countryLevelCount2: integer (nullable = false) 
|-- countryLevelCount3: integer (nullable = false) 
|-- countryLevelCount4: integer (nullable = false) 
|-- countryLevelCount5: integer (nullable = false) 
|-- globalCount1: integer (nullable = false) 
|-- globalCount2: integer (nullable = false) 
|-- globalCount3: integer (nullable = false) 
|-- globalCount4: integer (nullable = false) 
|-- globalCount5: integer (nullable = false) 

Teraz, gdy uruchamiam kwerendę na pierwszym zestawie danych w kolumnie takiej jak global.count1, zajmuje ona znacznie więcej czasu niż zapytanie globalCount1 w drugim zestawie danych. I odwrotnie, zapisanie pierwszego zestawu danych w Parkiecie zajmuje dużo mniej czasu niż napisanie drugiego zestawu danych. Wiem, że moje dane są przechowywane w kolumnach ze względu na Parquet, ale myślałem, że wszystkie zagnieżdżone kolumny będą przechowywane razem. Na przykład w pierwszym zestawie danych wydaje się, że cała kolumna "globalna" jest przechowywana razem, a nie wartości "global.count1", "global.count2" itd. Są przechowywane razem. Czy to oczekiwane zachowanie?

Answer 1

Interesujące. "to zajmuje dużo więcej czasu niż wysyłanie zapytań .." czy możesz dzielić się tym, jak długo? dzięki.

Patrząc na kod https://github.com/Parquet/parquet-mr/blob/master/parquet-column/src/main/java/parquet/io/RecordReaderImplementation.java#L248 wydaje się, że czytanie ze struktur może mieć trochę narzut. Nie powinno to być "o wiele dłużej", chociaż wystarczy spojrzeć na kod Parquet.

Myślę, że większy problem polega na tym, że Spark może w takich przypadkach obniżyć liczbę predykatów. Na przykład w takich przypadkach może nie być możliwe stosowanie filtrów bloom. Czy możesz udostępnić sposób kwerendy danych w obu przypadkach i czasy. Jakie wersje Spark, Parquet, Hadoop itp?

Parkiet-1.5 miał numer https://issues.apache.org/jira/browse/PARQUET-61, co w niektórych przypadkach może spowodować spowolnienie 4-5x.