Add approx_distinct_count

[PointKernel]

Description

Closes #20774

This PR adds an approx_distinct_count class which uses Hyperloglog++ under the hood to provide approximate distinct count estimation.

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]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[ttnghia]

As discussed, should the class approx_distinct_count be a template class taking a Hasher template parameter so it allows the callers to override by their own hasher?

[PointKernel]

As discussed, should the class approx_distinct_count be a template class taking a Hasher template parameter so it allows the callers to override by their own hasher?

@ttnghia There is a design question to clarify. We generally do not expose public device APIs or templated APIs in libcudf. Making the API templated also means we can’t separate declarations and definitions, which effectively forces it into a .cuh header.

This PR was primarily motivated by the Velox use case. After checking with the team, cuDF operators are currently integrated into Velox via host-side APIs rather than device APIs. Given that approx_distinct_count is not Spark-compatible at the moment, would it make sense to address the Spark integration as a separate task?

[ttnghia]

How about only implement the detailed class approx_distinct_count as a template class, keeping the class declared in the public header intact? We (spark-rapids-jni) can pull in the detail header and use it directly.

namespace cudf {
namespace detail {

// This is for overriding by a customized hasher.
template<typename Hasher>
class approx_distinct_count_base {};

class approx_distinct_count: public approx_distinct_count_base {};

[ttnghia]

FYI I'm fine with defer further changes to the next PR merging into the next release. Just want to make clear about the direction that we need to move onto.

However, if the suggested changes only take a few lines of code then it would be great to have here 😄

[PointKernel]

How about only implement the detailed class approx_distinct_count as a template class, keeping the class declared in the public header intact? We (spark-rapids-jni) can pull in the detail header and use it directly.

namespace cudf {
namespace detail {

// This is for overriding by a customized hasher.
template<typename Hasher>
class approx_distinct_count_base {};

class approx_distinct_count: public approx_distinct_count_base {};

Sure, that’s what I wanted to propose as well. We’re already following the same pattern for hash_join.

[sleeepyjack]

This isn't fully correct. p=12 results in a 16KB sketch which is just a small fraction of the available shared memory. cuco's implementation uses dynamic shared memory, and can thus go beyond 200KB on B200 for example. p=13 (32KB) safely fits into static shared memory on older architectures that don't have extended dynamic shared memory capacity.

[PointKernel]

For reference: https://github.com/NVIDIA/spark-rapids-jni/blob/ed68339b01ead5d5f81163bf0431b542b786ec67/src/main/cpp/src/hyper_log_log_plus_plus.cu#L46-L51

My guess is that the tests were run on a the lowest-performance card needed by spark or they need to support multi-stream executions on a single card.

[sleeepyjack]

precision is a parameter specific to the HLL++ implementation. Ideally the interface is agnostic to the algorithm under the hood. We could replace it with some more general concept like standard deviation and then select the corresponding lower bound precision value for the implementation.

[PointKernel]

Agreed. See #20735 (comment)

[bdice]

Some small comments, but generally looks good.

[PointKernel]

/merge