hbase cell storage different bewteen bulk load and direct api

2018-04-18 Thread Lew Jackman 
Under Phoenix 4.11 we are seeing some storage discrepancies in hbase between a 
load via psql and a bulk load.

To illustrate in a simple case we have modified the example table from the load 
reference https://phoenix.apache.org/bulk_dataload.html

CREATE TABLE example (
my_pk bigint not null,
m.first_name varchar(50),
m.last_name varchar(50) 
CONSTRAINT pk PRIMARY KEY (my_pk))
IMMUTABLE_ROWS=true,
IMMUTABLE_STORAGE_SCHEME = SINGLE_CELL_ARRAY_WITH_OFFSETS,
COLUMN_ENCODED_BYTES = 1;

Hbase Rows when Loading via PSQL

 \\x80\\x00\\x00\\x00\\x00\\x0009 column=M:\\x00\\x00\\x00\\x00, 
timestamp=1524109827690, value=x  
 \\x80\\x00\\x00\\x00\\x00\\x0009 column=M:1, timestamp=1524109827690, 
value=xJohnDoe\\x00\\x00\\x00\\x01\\x00\\x05\\x00\\x00\\x00\\x08\\x00\\x00\\x00\\x03\\x02
  
 \\x80\\x00\\x00\\x00\\x00\\x01\\x092  column=M:\\x00\\x00\\x00\\x00, 
timestamp=1524109827690, value=x  
 \\x80\\x00\\x00\\x00\\x00\\x01\\x092  column=M:1, timestamp=1524109827690, 
value=xMaryPoppins\\x00\\x00\\x00\\x01\\x00\\x05\\x00\\x00\\x00\\x0C\\x00\\x00\\x00\\x03\\x02
  

Hbase Rows when Loading via MapReduce using CsvBulkLoadTool 

 \\x80\\x00\\x00\\x00\\x00\\x0009 column=M:1, timestamp=1524110486638, 
value=xJohnDoe\\x00\\x00\\x00\\x01\\x00\\x05\\x00\\x00\\x00\\x08\\x00\\x00\\x00\\x03\\x02
  
 \\x80\\x00\\x00\\x00\\x00\\x01\\x092  column=M:1, timestamp=1524110486638, 
value=xMaryPoppins\\x00\\x00\\x00\\x01\\x00\\x05\\x00\\x00\\x00\\x0C\\x00\\x00\\x00\\x03\\x02
  


So, the bulk loaded tables have 4 cells for the two rows loaded via psql 
whereas a bulk load is missing two cells since it lacks the cells with col 
qualifier :\\x00\\x00\\x00\\x00 Is this behavior correct?  Thanks much for any 
insight. 

How To "Remove" Dark Spots
Gundry MD
http://thirdpartyoffers.netzero.net/TGL3231/5ad818ce6211c18ce6b13st04vuc

phoenix query server java.lang.ClassCastException for BIGINT ARRAY column

2018-04-18 Thread Lu Wei 
Hi there,

I have a phoenix table containing an BIGINT ARRAY column. But when querying 
query server (through sqlline-thin.py), there is an exception:

java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long

BTW, when query through sqlline.py, everything works fine. And data in HBase 
table are of Long type, so why does the Integer to Long cast happen?



## Table schema:

create table if not exists gis_tracking3(tracking_object_id bigint not null, 
lat double, lon double, speed double, bearing double, time timestamp not null, 
events bigint array constraint pk primary key (tracking_object_id, time))


## when query events[1], it works fine:

0: jdbc:phoenix:thin:url=http://10.10.13.87:8> select  events[1]+1 from 
gis_tracking3;
+--+
| (ARRAY_ELEM(EVENTS, 1) + 1)  |
+--+
| 11   |
| 2223 |
| null |
| null |
| 10001|
+--+



## when querying events, it throws exception:

0: jdbc:phoenix:thin:url=http://10.10.13.87:8> select  events from 
gis_tracking3;
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
  at 
org.apache.phoenix.shaded.org.apache.calcite.avatica.util.AbstractCursor$LongAccessor.getLong(AbstractCursor.java:550)
  at 
org.apache.phoenix.shaded.org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1310)
  at 
org.apache.phoenix.shaded.org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1289)
  at 
org.apache.phoenix.shaded.org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1342)
  at 
org.apache.phoenix.shaded.org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1354)
  at 
org.apache.phoenix.shaded.org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:257)
  at sqlline.Rows$Row.(Rows.java:183)
  at sqlline.BufferedRows.(BufferedRows.java:38)
  at sqlline.SqlLine.print(SqlLine.java:1660)
  at sqlline.Commands.execute(Commands.java:833)
  at sqlline.Commands.sql(Commands.java:732)
  at sqlline.SqlLine.dispatch(SqlLine.java:813)
  at sqlline.SqlLine.begin(SqlLine.java:686)
  at sqlline.SqlLine.start(SqlLine.java:398)
  at sqlline.SqlLine.main(SqlLine.java:291)
  at 
org.apache.phoenix.queryserver.client.SqllineWrapper.main(SqllineWrapper.java:93)



I guess there is some issue in query sever, but can't figure out why.

Any suggestions?



Thanks,

Wei

Split and distribute regions of SYSTEM.STATS table

2018-04-18 Thread Batyrshin Alexander 
 Hello,
I've discovered that SYSTEM.STATS has only 1 region with size 3.25 GB. Is it ok 
to split it and distribute over different region servers?