You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2019/09/04 17:58:00 UTC

[jira] [Commented] (IMPALA-8058) HBase scan cardinality division-by-zero leads to bogus cardinality

    [ https://issues.apache.org/jira/browse/IMPALA-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16922713#comment-16922713 ] 

ASF subversion and git services commented on IMPALA-8058:
---------------------------------------------------------

Commit f36ea767c8eac608d37dfc954e426a7da2a07251 in impala's branch refs/heads/master from stiga-huang
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=f36ea76 ]

IMPALA-8913: Add query option to disable hbase row estimation

IMPALA-8058 added a flag, disable_hbase_row_est, in the QueryCtx for
tests to bypass the codes of estimating HBase row stats from HBase RPCs
and fall back to HMS row count stats. This patch exposes it as a query
option.

Tests:
 - Replace the usage of disable_hbase_row_est in QueryCtx by the new
 query option in tests. Verified relative tests pass as before.

Change-Id: I768ea1f560c5faab74d8772bc8aa9ddefdcf2e10
Reviewed-on: http://gerrit.cloudera.org:8080/14169
Reviewed-by: Quanlong Huang <hu...@gmail.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>


> HBase scan cardinality division-by-zero leads to bogus cardinality
> ------------------------------------------------------------------
>
>                 Key: IMPALA-8058
>                 URL: https://issues.apache.org/jira/browse/IMPALA-8058
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Frontend
>    Affects Versions: Impala 3.1.0
>            Reporter: Paul Rogers
>            Assignee: Paul Rogers
>            Priority: Major
>             Fix For: Impala 3.2.0
>
>
> A particular HBase query has highly selective key filters and runs into code bugs that produce a bogus, huge cardinality value.
> {{HbaseScanNode.computeStats()}} attempts to compute table cardinality by calling {{HBaseTable.getEstimatedRowStats()}}. This then calls into (in the latest versions) {{FeHBaseTable.getEstimatedRowStats()}}.
> This code tries to estimate cardinality by:
> * Scanning a set of regions.
> * For each getting the size.
> * Averaging a bunch of rows to estimate row width.
> Once we know the size of the regions we need to scan, and the average row width, we can compute the scan cardinality.
> The problem in this particular query is that the predicates are so selective that no regions match. As a result, the average row width is zero. We divide (as a double) the region size by 0 and get INF. We cast that to a long and get Long.MAX_VALUE. We then use that as our (highly bogus) cardinality estimate.
> The code must:
> * Detect the division-by-zero (now sample rows) case.
> * Use an alternative estimate (such as multiplying total table row count from HMS by the filter selectivity.)



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org