Используя PageIndex, почему паркет не пропускает ненужные страницы?

Question

С помощью parquet-mr@1.11.0У меня есть такая схема:

schema message page {
  required binary url (STRING);
  optional binary content (STRING);
}

• Я делаю поиск по одной строке url чтобы получить связанный content
• Ряды упорядочены url,

Файл был создан с помощью:

• parquet.block.size: 256 МБ
• parquet.page.size: 10 МБ

С помощью parquet-tools Я смог убедиться, что у меня действительно есть индекс столбца и / или смещения для моих столбцов:

column index for column url:
Boudary order: ASCENDING
                      null count  min                                       max
page-0                         0  http://materiais.(...)delos-de-curriculo  https://api.quero(...)954874/toogle_like
page-1                         0  https://api.quero(...)880/toogle_dislike  https://api.quero(...)ior-online/encceja
page-2                         0  https://api.quero(...)erior-online/todos  https://api.quero(...)nte-em-saude/todos

offset index for column url:
                          offset   compressed size       first row index
page-0                         4            224274                     0
page-1                    224278            100168                 20000
page-2                    324446             67778                 40000


column index for column content:
NONE
offset index for column content:
                          offset   compressed size       first row index
page-0                    392224            504412                     0
page-1                    896636            784246                   125
page-2                   1680882            641212                   200
page-3                   2322094            684826                   275
[... truncated ...]
page-596               256651848            183162                 53100

Использование считывателя, настроенного как:

   AvroParquetReader
      .<GenericRecord>builder(HadoopInputFile.fromPath(path, conf))
      .withFilter(FilterCompat.get(
        FilterApi.eq(
          FilterApi.binaryColumn(urlKey),
          Binary.fromString(url)
        )
      ))
      .withConf(conf)
      .build();

Благодаря column-index а также column-offsets Я ожидал, что читатель прочитает только 2 страницы:

• Тот, который содержит url согласование min/max используя индекс столбца.
• затем тот, который содержит соответствующий индекс строки для content используя индекс смещения.

Но я вижу, что читатель читает и декодирует сотни страниц (~250 МБ) для content В колонке, я что-то упускаю из-за того, как PageIndex должен работать в parquet-mr?

Просматривая строки журнала "загрузка страницы" и "пропуск записи", вы пытаетесь построить всю запись перед применением фильтра к url которые, по моему мнению, побеждают цель PageIndex.

Я попытался посмотреть в Интернете и погрузиться в работу читателя, но ничего не смог найти.

редактировать

Я нашел открытый PR с 2015 года на parquet-column намекнув на то, что текущий читатель (по крайней мере, на тот момент) действительно строит всю запись со всеми необходимыми столбцами перед применением предиката:

https://github.com/apache/parquet-mr/pull/288

Но я не вижу в этом контексте цели column offsets,

Answer 1

Выяснилось, что хотя это и не то, что я ожидал, читая спецификации, оно работает так, как задумано.

Из этого номера я цитирую:

URL колонки имеет 3 страницы. Ваш фильтр обнаруживает, что страница 0 соответствует. На основе индекса смещения он переводится в диапазон строк [0..19999]. Поэтому нам нужно загрузить страницу 0 для URL-адреса столбца, и все страницы находятся в диапазоне строк [0..19999] для содержимого столбца.