[ https://issues.apache.org/jira/browse/HIVE-24833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Mollitor updated HIVE-24833: ---------------------------------- Description: I believe that a Hive query with an HBase Storage Handler is incorrectly applies a predicate pushdown into the storage handler. I observed a FETCH optimization that took a long time to complete because it was performing a table scan across the entire HBase table. The only case in which a predicate should be pushed down the storage layer is for {code:sql} SELECT * FROM TABLE my_hbase_table WHERE row_key=? {code} This would be appropriate (EQ on the row key). Anything else will involve a scan of the table and there is no way to easily calculate how small a scan it will require and therefore should always be passed to the compute engine (Tez). {code:none} beeline> CREATE EXTERNAL TABLE t_hbase(key STRING, tinyint_col TINYINT, smallint_col SMALLINT, int_col INT, bigint_col BIGINT, float_col FLOAT, double_col DOUBLE, boolean_col BOOLEAN) STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler' WITH SERDEPROPERTIES ("hbase.columns.mapping" = "cf:binarykey#-,cf:binarybyte#-,cf:binaryshort#-,:key#-,cf:binarylong#-,cf:binaryfloat#-,cf:binarydouble#-,cf:binaryboolean#-") TBLPROPERTIES ("hbase.table.name" = "t_hive", "hbase.table.default.storage.type" = "binary", "external.table.purge" = "true") beeline> insert into table t_hbase values ('user1', 1, 11, 10, 1, 1.0, 1.0, true); beeline> explain select * from t_hbase where int_col=10; Explain Plan optimized by CBO. Stage-0 Fetch Operator limit:-1 Select Operator [SEL_2] Output:["_col0","_col1","_col2","_col3","_col4","_col5","_col6","_col7"] TableScan [TS_0] Output: ["key","tinyint_col","smallint_col","bigint_col","float_col","double_col","boolean_col"] {code} You can see for this trivial example that this is an {{external}} table, Hive has no idea what's in it, but it is doing a Fetch + TableScan was: I believe that a Hive query with an HBase Storage Handler is incorrectly applies a predicate pushdown into the storage handler. I observed a FETCH optimization that took a long time to complete because it was performing a table scan across the entire HBase table. The only case in which a predicate should be pushed down the storage layer is for {code:sql} SELECT * FROM TABLE my_hbase_table WHERE row_key=? {code} This would be appropriate (EQ on the row key). Anything else will involve a scan of the table and there is no way to easily calculate how small a scan it will require and therefore should always be passed to the compute engine (Tez). {code:none} beeline> CREATE EXTERNAL TABLE t_hbase(key STRING, tinyint_col TINYINT, smallint_col SMALLINT, int_col INT, bigint_col BIGINT, float_col FLOAT, double_col DOUBLE, boolean_col BOOLEAN) STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler' WITH SERDEPROPERTIES ("hbase.columns.mapping" = "cf:binarykey#-,cf:binarybyte#-,cf:binaryshort#-,:key#-,cf:binarylong#-,cf:binaryfloat#-,cf:binarydouble#-,cf:binaryboolean#-") TBLPROPERTIES ("hbase.table.name" = "t_hive", "hbase.table.default.storage.type" = "binary", "external.table.purge" = "true") beeline> insert into table t_hbase values ('user1', 1, 11, 10, 1, 1.0, 1.0, true); beeline> explain select * from t_hbase where int_col=1; Explain Plan optimized by CBO. Stage-0 Fetch Operator limit:-1 Select Operator [SEL_2] Output:["_col0","_col1","_col2","_col3","_col4","_col5","_col6","_col7"] TableScan [TS_0] Output: ["key","tinyint_col","smallint_col","bigint_col","float_col","double_col","boolean_col"] {code} > Hive Should Only Pushdown EQ Predicate on HBaseStorageHandler Fetch Task > ------------------------------------------------------------------------ > > Key: HIVE-24833 > URL: https://issues.apache.org/jira/browse/HIVE-24833 > Project: Hive > Issue Type: Improvement > Components: HBase Handler > Reporter: David Mollitor > Priority: Major > > I believe that a Hive query with an HBase Storage Handler is incorrectly > applies a predicate pushdown into the storage handler. > I observed a FETCH optimization that took a long time to complete because it > was performing a table scan across the entire HBase table. > The only case in which a predicate should be pushed down the storage layer is > for > {code:sql} > SELECT * FROM TABLE my_hbase_table WHERE row_key=? > {code} > This would be appropriate (EQ on the row key). Anything else will involve a > scan of the table and there is no way to easily calculate how small a scan it > will require and therefore should always be passed to the compute engine > (Tez). > {code:none} > beeline> CREATE EXTERNAL TABLE t_hbase(key STRING, > tinyint_col TINYINT, > smallint_col SMALLINT, > int_col INT, > bigint_col BIGINT, > float_col FLOAT, > double_col DOUBLE, > boolean_col BOOLEAN) > STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler' > WITH SERDEPROPERTIES ("hbase.columns.mapping" = > "cf:binarykey#-,cf:binarybyte#-,cf:binaryshort#-,:key#-,cf:binarylong#-,cf:binaryfloat#-,cf:binarydouble#-,cf:binaryboolean#-") > TBLPROPERTIES ("hbase.table.name" = "t_hive", > "hbase.table.default.storage.type" = "binary", > "external.table.purge" = "true") > > > > beeline> insert into table t_hbase values ('user1', 1, 11, 10, 1, 1.0, 1.0, > true); > beeline> explain select * from t_hbase where int_col=10; > Explain > Plan optimized by CBO. > Stage-0 > Fetch Operator > limit:-1 > Select Operator [SEL_2] > Output:["_col0","_col1","_col2","_col3","_col4","_col5","_col6","_col7"] > TableScan [TS_0] > Output: > > ["key","tinyint_col","smallint_col","bigint_col","float_col","double_col","boolean_col"] > {code} > You can see for this trivial example that this is an {{external}} table, Hive > has no idea what's in it, but it is doing a Fetch + TableScan -- This message was sent by Atlassian Jira (v8.3.4#803005)