Member since
07-17-2019
738
Posts
433
Kudos Received
111
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 3473 | 08-06-2019 07:09 PM | |
| 3672 | 07-19-2019 01:57 PM | |
| 5201 | 02-25-2019 04:47 PM | |
| 4668 | 10-11-2018 02:47 PM | |
| 1771 | 09-26-2018 02:49 PM |
12-16-2016
05:28 PM
1 Kudo
As long as "hbase.online.schema.update.enable" is not set to false in hbase-site.xml, this will be done without disabling the table.
... View more
12-16-2016
03:44 PM
Your concern is very valid, Steen. Often times, this root problem is latency in the cluster recovering from a partially failed state. The system can often recover this on its own as you have noticed. Deleting the HBase data should *only* ever be used when the state is in an "empty state". It is not an acceptable answer for "real" systems.
... View more
12-15-2016
05:23 PM
He would not be seeing a SocketTimeoutException if the socket was unable to make a connection on that host+port. The SocketTimeoutException implies that the socket is connected.
... View more
12-15-2016
05:22 PM
Ok, last check would be to verify that all of your RegionServers also have that configuration value. The easiest way is to venture to the HBase UI for each RegionServer (via the Master UI is the easiest) and verify that the value is set after clicking on "HBase Configuration" at the top of the page.
... View more
12-15-2016
04:40 PM
Make sure that /etc/hbase/conf is included on your client's classpath.
... View more
12-15-2016
04:33 PM
1 Kudo
When you increase your time range, you have to read more data. HBase defines the maximum length of any RPC by the hbase.rpc.timeout property in hbase-site.xml. This defaults to 60s, and this limit is what you're hitting. If you want to run a query that will scan over more data or generally take a long time (such as server-side filtering), you will have to increase hbase.rpc.timeout commensurately.
... View more
12-15-2016
04:28 PM
1 Kudo
Beware that S3 presently does not support the level of "sync durability" that is required by HBase write-ahead log files. This means that there would likely be data loss if you tried to run HBase fully on S3.
... View more
12-14-2016
04:16 AM
No, because HDFS is a filesystem and HBase is a key-value store ("database"). But, you can archive HBase tables easily. Please see the HBase snapshot feature: http://hbase.apache.org/book.html#ops.snapshots. Using this feature, you can take a point-in-time view of a table, and copy all of the referenced files to some location in HDFS or elsewhere.
... View more
12-13-2016
03:37 PM
4 Kudos
"I read that accumulo supports cell level security, and hbase doesn't. Is this true?" Both systems support cell-level security; however, I would say that Accumulo's is a more "battle-hardened" implementation. I'm not aware of any case studies behind comparing the two implementations. "and secondly accumulo supports multiple data sources ingestion better
and hbase one source such as one web site. is it true? in what ways?" No, I don't know in what way this would be possible. Both systems can ingest data from a variety of sources. This sounds like something was taken out of context. "can someone share any accumulo case studies?" http://accumulo.apache.org/papers/ has some content, http://www.pdl.cmu.edu/SDI/2013/slides/big_graph_nsa_rd_2013_56002v1.pdf, https://arxiv.org/abs/1406.4923, and http://accumulo.apache.org/papers/accumulo-benchmarking-2.1.pdf are each interesting. This talk from PHEMI by Russ Weeks is also particularly nice http://accumulosummit.com/program/talks/preventing-bugs-how-phemi-put-accumulo-to-work-in-the-field/ "Can accumulo be used with full support and rest of hadoop ecosystem?" In short, "yes", but this is subjective due to what you consider the "rest of hadoop ecosystem" and what degree of integration you're expecting. The same goes for HBase. As for HDP, yes, both HBase and Accumulo are fully supported as Tim pointed out already. I would suggest you ask more pointed questions if you have specific concerns.
... View more