how to build API to hide the accelerator complexity

[yaqi-zhao]

The PR #6176 is to integrate IAA accelerator to do decompression in prefetch and asynchronous mode. The current realization has less ducplicated code but
invades the current logic.
Is there any method to hide the accelerator details from codebase?

[yaqi-zhao]

Solution overview

// Step-I: Preparation
// Async decompression preparation abstraction and hiding IAA accelerator-specific logic
int GzipIAADecompressor::decompress(
const char* src,
uint64_t srcLength,
char* dest,
uint64_t destLength) {
...
}

// gzip decompress job completion check
bool GzipIAADecompressor::waitResult(int job_id) {
...
}

// IAA accelerator initiate
// Allocate and initiate qpl job for IAA accelerator usage
void QplJobHWPool::allocateQPLJob() {
{
...
}

// IAA accelerator deinitiate
QplJobHWPool::~QplJobHWPool{
{
...
}

// Step-II: parquet reader call stack analysis
The main logic of this solution si to submit IAA decompression job before really using the data page
There are two places to submit data page decompression job to IAA asynchronously:
1 Decompression of the first data page of a row group is submitted to IAA when load row group in parquet reader.
Here is the call stack:
ParquetReader::scheduleRowGroups -> loadRowGroup
-> preDecompRowGroup -> SelectiveStructColumnReader::preDecompRowGroup->ParquetData::preDecompRowGroup->PageReader::preDecompressPage

2. For multi-pages in one rowgroup, the decompression of second and subsequent pages is submitter after the prevous page is read completed.
   The implementation in code is after PageReader::seekToPage, the PageReader::prefetchNextPage is called.

// Step-III: Data retrieval & SW fallback mechanism to secure the system's robust
if have pre-decompressed page
if pre-decompressed page is success
read page
else
decompress page with software path
read page
else
decompress page with software path

// Step-IV: Implementation Options pros and cons
Options-1: least code duplication (current PR implementation)
Add IAA processiong branch in PageReader, ParquetData, ParquetReader, ColumnReader

Option-2: least code invasion (it may introduce code redundancy to some degree)
1）Add a new file named HwCompression.cpp，this file will include the GzipCompression class implementation. This class is used to interact with IAA. And there will no invasion to the current Compression.cpp
2）ParquetReader.cpp, ParquetData.cpp, (**)ColumnReader.cpp, PageReader.cpp have code invasion，amon which PageReader has the most，and the involved functions in PageReader are:
seekToPage，decompressData， prepareDataPageV1， prepareDictionary， skip， skipNullsOnly， readNullsOnly， rowsForPage

Take PageReader as example，If we want to reduce code invasion, there are two initial thoughts:
2.1）Add a new IAAPageReader. But if we don't change PageReader there will be >80% cdoe duplication
2.2 Extract the duplicated code in IAAPageReader and PageReader to an abstract class, re-implement PageReader and IAAPageReade, then modify functions/class that call PageReader
Other files involving invasion are similar to PageReader transformation ideas. They cannot be completely non-invasive, just reduce some code duplication

[george-gu-2021]

Hi @pedroerp , @Yuhta, @mbasmanova , @FelixYBW, would you help share your insights on the above implementation options of the parquet reader acceleration w/ IAA accelerator? Appreciate!

[george-gu-2021]

Here is a brief diagram illustrating the difference between accelerator-assist async mode decompress and SW-based sync mode decompression.

Here is a diagram illustrating why not just replace the sw decompression function in an apple-to-apple style.

Typically existing software-based decompression just implements sync mode interfaces, so the async mode decompression is a brand-new interface in order to achieve good performance.

[FelixYBW]

@george-gu-2021 @yaqi-zhao Let's split the issue into two parts,
Firstly let's add the abstraction of codec API. Rong summarized the current status in #7471
Then let's talk about the optimization of async parquet scan and prefetch

[george-gu-2021]

It makes sense.

[Yuhta]

I would put my vote for option 2.2 . An async interface (using SemiFuture) for the decompressor also would be nice.

Also when is it going to be possible to remove the 4KB window size restriction? That is somewhat limiting factor to put this into real world usage.

[yaqi-zhao]

Thanks @Yuhta The PR(#6176) is currently an implementation of option 2.2.
As for your concern about 4KB window size restriction, Arrow 14.0.0 has exposed its interfaces to customize the window size and users can set that per their preference.

[Yuhta]

The 4KB window size only works if we have full control over the files written and there are no old files to read. In reality we are often forced to use the default 32KB window size.