Support hyper log log plus plus(HLL++)

[res-life]

closes #10652

• Group HLL
• Test: Group HLL
• Compact plain sketch to Spark compatible
• Test: Compact plain sketch to Spark compatible
• Merge HLL
• Test Merge HLL
• Reduction

HLL++ description

First get a 64 bits hash code, and generate a interger pair: register index -> register value. The register index is in [0, 512) if precision is 9.
Second, merge in the same group:
For each register index, find the max register value.
So HLL++ is actually like a process of doing max aggregation 512 times on 512 interger columns.

e.g., below is 2 sketches in a group.

register index 0	register index 1	...	register index 511
1	22	...	44
11	2	...	4
Aggregation result is:

register index 0	register index 1	...	register index 511
11	22	...	44

reduce_by_key memory issue

thrust::reduce_by_key will allocates n sketch values (n is the num_rows) which are large, typically each sketch is 512 integers(512 * 4 = 2K bytes). If there are 1G rows, it means reduce_by_key will use 2k * 1G = 2T intermidate memory.

link

    // scan the values by flag
    thrust::detail::temporary_array<ValueType,ExecutionPolicy> scanned_values(exec, n);

thrust::reduce_by_key is not suitable for merge HLL sketches.
This PR uses a new way to do aggregate.

aggregation steps this PR

Step1:
Partial merge:
Because group labels is sorted, so the group labels in each segment is also sorted.
Split rows into small segments with each segment contains 256 items.
One thread handles one segement.
In each segment, produces a cache recording the max values. It only uses N/256 caches which is relatively small memory. When scaning the items in a segment, when meets a new group, outputs the result for the previous group.

Step 2:
Merge the cache and the result to get the final result.

For more details, please refer to the comments in the code.

Description

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[vyasr]

Please link to #10652 as appropriate.

[ttnghia]

Suggested change

	HLLPP, ///< approximating the number of distinct items by using hyper log log plus plus (HLLPP)
	HLLPP, ///< approximating the number of distinct items using HyperLogLogPlusPlus

[res-life]

done.

[ttnghia]

This seems to be moved from the source file, which was added in #13612. However, I'm confused with the other XXHash_64 added in NVIDIA/spark-rapids-jni#1248. What is the difference between them? Is this XXHash_64 enough for addressing Spark's behavior in HLLPP?

[ttnghia]

Suggested change

	int const precision =
	dynamic_cast<cudf::detail::merge_hyper_log_log_aggregation const&>(agg).precision;
	int const precision =
	dynamic_cast<cudf::detail::merge_hyper_log_log_aggregation const&>(agg).precision;

[mythrocks]

Sorry, my eyes aren't able to pick up the difference suggested here. What's the change?

[wence-]

I suspect removal of the blank line, but github has a bug that doesn't show it.

[res-life]

/ok to test

[res-life]

Ready to review except test cases.