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

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

1 голос
/ 17 июня 2019

Используя 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.

1 Ответ

1 голос
/ 18 июня 2019

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

С эта проблема Цитирую:

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

...