Member since
09-29-2015
94
Posts
117
Kudos Received
35
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
2476 | 08-04-2017 06:13 PM | |
5471 | 03-21-2017 08:00 PM | |
2515 | 11-30-2016 07:38 PM | |
1286 | 11-03-2016 05:56 PM | |
2680 | 10-11-2016 06:44 PM |
02-22-2016
11:43 PM
3 Kudos
It seems to be failing due to this: java.net.UnknownHostException: sandbox.hortoworks.com You can make sure that the hostname resolution is correct.
... View more
02-22-2016
07:37 PM
2 Kudos
Yes, HBase does not have a "use namespace" equivalent. I doubt that we will ever add one, since in most of the cases, the default namespace is the special namespace "default". However, changing an application to use a table in a namespace should be pretty trivial. Make sure that you are using TableName.valueOf() methods properly.
... View more
02-09-2016
07:26 PM
No worries! Keep on HBase'ing.
... View more
02-09-2016
07:08 PM
1 Kudo
Yes, HBase's Bytes.toXXX utility methods are not designed to be used for negative values unfortunately. You can still use those for storing negative values as cell values. If you use it for storing primary key or column names for example, the byte[] sort orders will not be correct (negative values will be sorted AFTER the positive values). If you want to interoperate HBase and Phoenix, you can use PXXX classes in Phoenix (PFloat, PInteger) etc in your Java code instead of using Bytes.toBytes().
... View more
02-08-2016
10:32 PM
1 Kudo
The above still applies. HBase's float -> byte[] serialization is different than Phoenix's FLOAT -> byte[] serialization. HBase's one does not sort correctly for negative values in the byte[] serialized format. That is why if you want to interoperate between HBase and Phoenix, you should use "compatible" types. If you are doing serialization from HBase, you should declare the type as UNSIGNED_FLOAT in Phoenix. Check out the documentation: https://phoenix.apache.org/language/datatypes.html#unsigned_float_type:
... View more
02-08-2016
08:01 PM
2 Kudos
HBase and Phoenix encode floats and some other data types differently. This is from https://phoenix.apache.org/ The other caveat is that the way the bytes were serialized in HBase must match the way the bytes are expected to be serialized by Phoenix. For VARCHAR,CHAR, and UNSIGNED_* types, Phoenix uses the HBase Bytes utility methods to perform serialization. The CHAR type expects only single-byte characters and the UNSIGNED types expect values greater than or equal to zero. Our composite row keys are formed by simply concatenating the values together, with a zero byte character used as a separator after a variable length type. For more information on our type system, see the Data Type.
... View more
02-05-2016
11:56 PM
2 Kudos
This is not usually a standard way of using TTLs. That is why it may need some custom solution. How would you decide what rows to keep and how to mark things to keep? A couple of ways that you can evaluate: 1. TTL with MIN_VERSIONS=1. If you set MIN_VERSIONS=1 and set TTL, affectively, HBase will make sure that there is at least 1 version of the cells kept around even after TTL expired. However, there won't be a way to mark something for deletion or not. 2. Don't use HBase TTLs, do client side deletion and expiry. In this case, running a custom scanner periodically (every day or so) and deleting data old data, but making sure that you do not delete "rows that have to be kept around". 3. [EXPERIMENTAL] Use per-cell TTLs. Per-cell TTLs are a relatively new feature that you can evaluate whether it is useful in your use case. The TTL for table should be larger than the TTL you set per-cell. Cells that have expired TTLs will be automatically deleted by the compaction. However, you should make sure to set the correct TTL at the time of the writes. This feature is also "experimental" and may not be fully supported in HDP. 4. [ADVANCED] Write your own compaction policy. This way, you can implement exactly what you want with high flexibility.
... View more
02-04-2016
08:02 PM
You should aim for having at most 10-20GB regions. Anything above that would cause compactions to increase the write-amplification and have <1000 regions per server. I suggest looking into your data model and make necessary adjustments to make sure that you are not doing the anti-pattern of incremental writes. See https://hbase.apache.org/book.html#table_schema_rules_of_thumb.
... View more
02-03-2016
10:25 PM
1 Kudo
There is a new feature called "region normalizer" that runs inside master and can do the merges automatically. it is available (but turned off by default) in HDP-2.3+. However, it is a very new feature, so it is still in tech preview mode I would say.
... View more
02-03-2016
07:51 PM
2 Kudos
Instead of specifying the config options, you should ALWAYS copy the /etc/hbase/conf folder and add that to your application classpath so that hbase-site.xml gets picked up from the classpath. See https://community.hortonworks.com/articles/4091/hbase-client-application-best-practices.html. The other thing is that you should open up other ports, 16000, 16030, 16010, 16020, 2181. See http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0-Win/bk_HDP_Install_Win/content/ref-79239257-778e-42a9-9059-d982d0c08885.1.html.
... View more