[jira] [Updated] (HBASE-14355) Scan different TimeRange for each column family
[ https://issues.apache.org/jira/browse/HBASE-14355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-14355: Fix Version/s: (was: 0.98.17) > Scan different TimeRange for each column family > --- > > Key: HBASE-14355 > URL: https://issues.apache.org/jira/browse/HBASE-14355 > Project: HBase > Issue Type: New Feature > Components: Client, regionserver, Scanners >Reporter: Dave Latham >Assignee: churro morales >Priority: Major > Fix For: 1.2.0, 2.0.0 > > Attachments: HBASE-14355-addendum.patch, HBASE-14355-v1.patch, > HBASE-14355-v10.patch, HBASE-14355-v11.patch, HBASE-14355-v2.patch, > HBASE-14355-v3.patch, HBASE-14355-v4.patch, HBASE-14355-v5.patch, > HBASE-14355-v6.patch, HBASE-14355-v7.patch, HBASE-14355-v8.patch, > HBASE-14355-v9.patch, HBASE-14355.branch-1.patch, HBASE-14355.patch > > > At present the Scan API supports only table level time range. We have > specific use cases that will benefit from per column family time range. (See > background discussion at > https://mail-archives.apache.org/mod_mbox/hbase-user/201508.mbox/%3ccaa4mzom00ef5eoxstk0hetxeby8mqss61gbvgttgpaspmhq...@mail.gmail.com%3E) > There are a couple of choices that would be good to validate. First - how to > update the Scan API to support family and table level updates. One proposal > would be to add Scan.setTimeRange(byte family, long minTime, long maxTime), > then store it in a Map. When executing the scan, if a > family has a specified TimeRange, then use it, otherwise fall back to using > the table level TimeRange. Clients using the new API against old region > servers would not get the families correctly filterd. Old clients sending > scans to new region servers would work correctly. > The other question is how to get StoreFileScanner.shouldUseScanner to match > up the proper family and time range. It has the Scan available but doesn't > currently have available which family it is a part of. One option would be > to try to pass down the column family in each constructor path. Another > would be to instead alter shouldUseScanner to pass down the specific > TimeRange to use (similar to how it currently passes down the columns to use > which also appears to be a workaround for not having the family available). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20188) [TESTING] Performance
[ https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444172#comment-16444172 ] Dave Latham commented on HBASE-20188: - Bravo, [~ram_krish] and [~Apache9]! Fun to follow along with the sleuthing and see the answer. > [TESTING] Performance > - > > Key: HBASE-20188 > URL: https://issues.apache.org/jira/browse/HBASE-20188 > Project: HBase > Issue Type: Umbrella > Components: Performance >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh, > HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 > performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs > None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png, > ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png, > ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png, > ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png, > ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png, > YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png, > YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png, > flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml, > hbase-site.xml, hits.png, hits_with_fp_scheduler.png, > lock.127.workloadc.20180402T200918Z.svg, > lock.2.memsize2.c.20180403T160257Z.svg, perregion.png, run_ycsb.sh, > total.png, tree.txt, workloadx, workloadx > > > How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor > that it is much slower, that the problem is the asyncwal writing. Does > in-memory compaction slow us down or speed us up? What happens when you > enable offheaping? > Keep notes here in this umbrella issue. Need to be able to say something > about perf when 2.0.0 ships. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-18792) hbase-2 needs to defend against hbck operations
[ https://issues.apache.org/jira/browse/HBASE-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436391#comment-16436391 ] Dave Latham commented on HBASE-18792: - Are you saying it is not possible to have a bug where assignments get into an inconsistent state and need fixing any more? > hbase-2 needs to defend against hbck operations > --- > > Key: HBASE-18792 > URL: https://issues.apache.org/jira/browse/HBASE-18792 > Project: HBase > Issue Type: Task > Components: hbck >Reporter: stack >Assignee: Umesh Agashe >Priority: Blocker > Fix For: 2.0.0 > > Attachments: hbase-18792.master.001.patch > > > hbck needs updating to run against hbase2. Meantime, if an hbck from hbase1 > is run against hbck2, it may do damage. hbase2 should defend itself against > hbck1 ops. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-18792) hbase-2 needs to defend against hbck operations
[ https://issues.apache.org/jira/browse/HBASE-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436351#comment-16436351 ] Dave Latham commented on HBASE-18792: - As someone who has relied on some of these fix options in the past (especially fixAssigments and fixMeta), what should an operator do instead if a table gets into a bad state? > hbase-2 needs to defend against hbck operations > --- > > Key: HBASE-18792 > URL: https://issues.apache.org/jira/browse/HBASE-18792 > Project: HBase > Issue Type: Task > Components: hbck >Reporter: stack >Assignee: Umesh Agashe >Priority: Blocker > Fix For: 2.0.0 > > > hbck needs updating to run against hbase2. Meantime, if an hbck from hbase1 > is run against hbck2, it may do damage. hbase2 should defend itself against > hbck1 ops. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20305) Add option to SyncTable that skip deletes on target cluster
[ https://issues.apache.org/jira/browse/HBASE-20305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425900#comment-16425900 ] Dave Latham commented on HBASE-20305: - +1 assuming the hadoopcheck errors are worked out. > Add option to SyncTable that skip deletes on target cluster > --- > > Key: HBASE-20305 > URL: https://issues.apache.org/jira/browse/HBASE-20305 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 2.0.0-alpha-4 >Reporter: Wellington Chevreuil >Assignee: Wellington Chevreuil >Priority: Minor > Attachments: 0001-HBASE-20305.master.001.patch, > HBASE-20305.master.002.patch > > > We had a situation where two clusters with active-active replication got out > of sync, but both had data that should be kept. The tables in question never > have data deleted, but ingestion had happened on the two different clusters, > some rows had been even updated. > In this scenario, a cell that is present in one of the table clusters should > not be deleted, but replayed on the other. Also, for cells with same > identifier but different values, the most recent value should be kept. > Current version of SyncTable would not be applicable here, because it would > simply copy the whole state from source to target, then losing any additional > rows that might be only in target, as well as cell values that got most > recent update. This could be solved by adding an option to skip deletes for > SyncTable. This way, the additional cells not present on source would still > be kept. For cells with same identifier but different values, it would just > perform a Put for the cell version from source, but client scans would still > fetch the most recent timestamp. > I'm attaching a patch with this additional option shortly. Please share your > thoughts. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20305) Add option to SyncTable that skip deletes on target cluster
[ https://issues.apache.org/jira/browse/HBASE-20305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16420663#comment-16420663 ] Dave Latham commented on HBASE-20305: - Thanks for the patch, Wellington. Looks like it also fixes a nasty bug where dryRun doesn't actually appear to work. I hope that did not bite you in using the tool. I think I'd prefer calling the option something like doDeletes (default true) rather than insertsOnly (default false). Could also have a similar option for doPuts to allow people to do deletes but not puts if they preferred. +0.9 as is. I'm going to hit the Submit Patch button to try to get Hadoop QA to take a pass. > Add option to SyncTable that skip deletes on target cluster > --- > > Key: HBASE-20305 > URL: https://issues.apache.org/jira/browse/HBASE-20305 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 2.0.0-alpha-4 >Reporter: Wellington Chevreuil >Assignee: Wellington Chevreuil >Priority: Minor > Attachments: 0001-HBASE-20305.master.001.patch > > > We had a situation where two clusters with active-active replication got out > of sync, but both had data that should be kept. The tables in question never > have data deleted, but ingestion had happened on the two different clusters, > some rows had been even updated. > In this scenario, a cell that is present in one of the table clusters should > not be deleted, but replayed on the other. Also, for cells with same > identifier but different values, the most recent value should be kept. > Current version of SyncTable would not be applicable here, because it would > simply copy the whole state from source to target, then losing any additional > rows that might be only in target, as well as cell values that got most > recent update. This could be solved by adding an option to skip deletes for > SyncTable. This way, the additional cells not present on source would still > be kept. For cells with same identifier but different values, it would just > perform a Put for the cell version from source, but client scans would still > fetch the most recent timestamp. > I'm attaching a patch with this additional option shortly. Please share your > thoughts. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20305) Add option to SyncTable that skip deletes on target cluster
[ https://issues.apache.org/jira/browse/HBASE-20305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-20305: Status: Patch Available (was: Open) > Add option to SyncTable that skip deletes on target cluster > --- > > Key: HBASE-20305 > URL: https://issues.apache.org/jira/browse/HBASE-20305 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 2.0.0-alpha-4 >Reporter: Wellington Chevreuil >Assignee: Wellington Chevreuil >Priority: Minor > Attachments: 0001-HBASE-20305.master.001.patch > > > We had a situation where two clusters with active-active replication got out > of sync, but both had data that should be kept. The tables in question never > have data deleted, but ingestion had happened on the two different clusters, > some rows had been even updated. > In this scenario, a cell that is present in one of the table clusters should > not be deleted, but replayed on the other. Also, for cells with same > identifier but different values, the most recent value should be kept. > Current version of SyncTable would not be applicable here, because it would > simply copy the whole state from source to target, then losing any additional > rows that might be only in target, as well as cell values that got most > recent update. This could be solved by adding an option to skip deletes for > SyncTable. This way, the additional cells not present on source would still > be kept. For cells with same identifier but different values, it would just > perform a Put for the cell version from source, but client scans would still > fetch the most recent timestamp. > I'm attaching a patch with this additional option shortly. Please share your > thoughts. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20265) Host regions in other rsgroup when all region servers in a rsgroup are all down
[ https://issues.apache.org/jira/browse/HBASE-20265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411622#comment-16411622 ] Dave Latham commented on HBASE-20265: - If all region servers hosting the system tables go down, then the system tables become unavailable. For that reason, it would likely be good to choose servers for that group to get a high degree of availability. It's similar to how you may want to setup your zookeeper quorum, or configure your HDFS Namenodes. You could choose to have 2 or 3 nodes dedicated to running Master processes and Region Servers in a dedicated group for system tables. > Host regions in other rsgroup when all region servers in a rsgroup are all > down > --- > > Key: HBASE-20265 > URL: https://issues.apache.org/jira/browse/HBASE-20265 > Project: HBase > Issue Type: Improvement > Components: rsgroup >Reporter: Xiang Li >Priority: Critical > > We met the following scenario in our production system: > rsgroup A hosts user table 1 as well as system tables (let's say > hbase:rsgroup, or hbase:meta). Several heavy reads on user table 1 make all > region servers within rsgroup A crash. As a result, the system tables have no > host. > Under such scenario, we could manually move the system tables to another > rsgroup. > But what about: > We provide an affinity or last resort. When all region servers in rsgroup A > crash, rsgroup B, as rsgroup A's affinity, will take over all tables of > rsgroup A, or at least, some important tables. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20265) Host regions in other rsgroup when all region servers in a rsgroup are all down
[ https://issues.apache.org/jira/browse/HBASE-20265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411542#comment-16411542 ] Dave Latham commented on HBASE-20265: - The purpose in my mind of rs groups is to be able to enforce strong isolation. If something about user table 1 is taking down any region server that hosts it, the last thing we would want to do is move it into a new rs group and affect other tenants. It sounds like like the right answer here would be to keep the system tables in a separate rs group from the user tables. > Host regions in other rsgroup when all region servers in a rsgroup are all > down > --- > > Key: HBASE-20265 > URL: https://issues.apache.org/jira/browse/HBASE-20265 > Project: HBase > Issue Type: Improvement > Components: rsgroup >Reporter: Xiang Li >Priority: Critical > > We met the following scenario in our production system: > rsgroup A hosts user table 1 as well as system tables (let's say > hbase:rsgroup, or hbase:meta). Several heavy reads on user table 1 make all > region servers within rsgroup A crash. As a result, the system tables have no > host. > Under such scenario, we could manually move the system tables to another > rsgroup. > But what about: > We provide an affinity or last resort. When all region servers in rsgroup A > crash, rsgroup B, as rsgroup A's affinity, will take over all tables of > rsgroup A, or at least, some important tables. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-8770) deletes and puts with the same ts should be resolved according to mvcc/seqNum
[ https://issues.apache.org/jira/browse/HBASE-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388247#comment-16388247 ] Dave Latham commented on HBASE-8770: Is the performance penalty for this behavior due to having deleted versions count against max versions? Or just for this change? It really seems like this should become the default behavior for hbase at some major release, hopefully without any significant performance penalty, independent of the question of whether deleted versions count against max versions. > deletes and puts with the same ts should be resolved according to mvcc/seqNum > - > > Key: HBASE-8770 > URL: https://issues.apache.org/jira/browse/HBASE-8770 > Project: HBase > Issue Type: Brainstorming >Reporter: Sergey Shelukhin >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-8770.branch-2.001.patch, > HBASE-8770.branch-2.002.patch > > > This came up during HBASE-8721. Puts with the same ts are resolved by seqNum. > It's not clear why deletes with the same ts as a put should always mask the > put, rather than also being resolve by seqNum. > What do you think? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20101) HBase should provide a way to re-validate locality
[ https://issues.apache.org/jira/browse/HBASE-20101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388239#comment-16388239 ] Dave Latham commented on HBASE-20101: - Can you share more about moving blocks to restore locality? Now that's something that would be awesome to see inside HBase, so that it doesn't require a compaction. > HBase should provide a way to re-validate locality > -- > > Key: HBASE-20101 > URL: https://issues.apache.org/jira/browse/HBASE-20101 > Project: HBase > Issue Type: New Feature >Reporter: Jean-Marc Spaggiari >Assignee: huaxiang sun >Priority: Major > > HDFS blocks can move for many reasons. HDFS balancing, lost of a disk, of a > node, etc. However, today, locality seems to be calculated when the files are > opened for the first time. Even disabling and re-enabling the regions doesn't > trigger a re-calculation of the locality. > We should provide a way to let the user ask for this number to be > re-calculated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20000) Remove the quantum logic in FairQueue, always put high priority queue in front
[ https://issues.apache.org/jira/browse/HBASE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364285#comment-16364285 ] Dave Latham commented on HBASE-2: - The new HBASE 20,000! It slices and dices! > Remove the quantum logic in FairQueue, always put high priority queue in front > -- > > Key: HBASE-2 > URL: https://issues.apache.org/jira/browse/HBASE-2 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-2.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19528) Major Compaction Tool
[ https://issues.apache.org/jira/browse/HBASE-19528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345516#comment-16345516 ] Dave Latham commented on HBASE-19528: - +1 for v8 > Major Compaction Tool > -- > > Key: HBASE-19528 > URL: https://issues.apache.org/jira/browse/HBASE-19528 > Project: HBase > Issue Type: New Feature >Reporter: churro morales >Assignee: churro morales >Priority: Major > Fix For: 2.0.0, 3.0.0 > > Attachments: HBASE-19528.patch, HBASE-19528.v1.patch, > HBASE-19528.v8.patch > > > The basic overview of how this tool works is: > Parameters: > Table > Stores > ClusterConcurrency > Timestamp > So you input a table, desired concurrency and the list of stores you wish to > major compact. The tool first checks the filesystem to see which stores need > compaction based on the timestamp you provide (default is current time). It > takes that list of stores that require compaction and executes those requests > concurrently with at most N distinct RegionServers compacting at a given > time. Each thread waits for the compaction to complete before moving to the > next queue. If a region split, merge or move happens this tool ensures those > regions get major compacted as well. > This helps us in two ways, we can limit how much I/O bandwidth we are using > for major compaction cluster wide and we are guaranteed after the tool > completes that all requested compactions complete regardless of moves, merges > and splits. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19359) Revisit the default config of hbase client retries number
[ https://issues.apache.org/jira/browse/HBASE-19359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16306334#comment-16306334 ] Dave Latham commented on HBASE-19359: - As someone who has used these configs before, and reading this discussion again, it reminds me that the ways these configs are setup is not the simplest or most intuitive for a user. In particular, most users would probably prefer to configure some max timeout in milliseconds, rather than spend time deciphering the backoff schedule and working out how many retries that needs to be. > Revisit the default config of hbase client retries number > - > > Key: HBASE-19359 > URL: https://issues.apache.org/jira/browse/HBASE-19359 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19359.master.001.patch, > HBASE-19359.master.001.patch, HBASE-19359.master.001.patch > > > This should be sub-task of HBASE-19148. As the retries number effect too many > unit tests. So I open this issue to see the Hadoop QA result. > The default value of hbase.client.retries.number is 35. Plan to reduce this > to 10. > And for server side, the default hbase.client.serverside.retries.multiplier > is 10. So the server side retries number is 35 * 10 = 350. It is too big! > Plan to reduce hbase.client.serverside.retries.multiplier to 3. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19654) ReplicationLogCleaner should not delete MasterProcedureWALs
[
https://issues.apache.org/jira/browse/HBASE-19654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16305655#comment-16305655
]
Dave Latham commented on HBASE-19654:
-
I think that log message is misleading. I believe the model for the log
cleaners is that if any cleaner in the chain wants to hold on to a file, then
it will not be deleted. So even though the ReplicationLogCleaner is ok to
delete those files, they still won't be deleted if some other log cleaner (e.g.
TimeToLiveProcedureWALCleaner) wants to hold on to them. A better log message
might be {{"Didn't find this log in ZK, not retaining for replication: " +
hlog}}
> ReplicationLogCleaner should not delete MasterProcedureWALs
> ---
>
> Key: HBASE-19654
> URL: https://issues.apache.org/jira/browse/HBASE-19654
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0-beta-1
>Reporter: Peter Somogyi
>Assignee: Reid Chan
> Fix For: 2.0.0-beta-2
>
>
> The pv2 logs are deleted by ReplicationLogCleaner. It does not check if
> TimeToLiveProcedureWALCleaner needs to keep the files.
> {noformat}
> 2017-12-27 19:59:02,261 DEBUG [ForkJoinPool-1-worker-17]
> cleaner.CleanerChore: CleanerTask 391 starts cleaning dirs and files under
> hdfs://ve0524.halxg.cloudera.com:8020/hbase/oldWALs and itself.
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0001.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0002.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0003.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0004.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0005.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0006.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0007.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0008.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0009.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0010.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0011.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0012.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0013.log
> 2017-12-27 19:59:02,279 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0014.log
> 2017-12-27 19:59:02,280 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0015.log
> 2017-12-27 19:59:02,280 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0016.log
> 2017-12-27 19:59:02,280 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0017.log
> 2017-12-27 19:59:02,280 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0018.log
> 2017-12-27 19:59:02,280 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0019.log
> 2017-12-27 19:59:02,280 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0020.log
> 2017-12-27 19:59:02,280 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't find this log in ZK, deleting:
> pv2-0021.log
> 2017-12-27 19:59:02,280 DEBUG [ForkJoinPool-1-worker-17]
> master.ReplicationLogCleaner: Didn't
[jira] [Issue Comment Deleted] (HBASE-19148) Reevaluate default values of configurations
[ https://issues.apache.org/jira/browse/HBASE-19148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-19148: Comment: was deleted (was: An alternative to enabling balancePerTable would be to add a cost factor to the stochastic load balancer that reflects the imbalance of each table.) > Reevaluate default values of configurations > --- > > Key: HBASE-19148 > URL: https://issues.apache.org/jira/browse/HBASE-19148 > Project: HBase > Issue Type: Bug > Components: defaults >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: > 0002-HBASE-19148-Reevaluate-default-values-of-configurati.patch, > HBASE-19148.master.001.patch, HBASE-19148.master.002.patch > > > Remove cruft and mythologies. Make descriptions more digestible. Change > defaults given experience. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19148) Reevaluate default values of configurations
[ https://issues.apache.org/jira/browse/HBASE-19148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295878#comment-16295878 ] Dave Latham commented on HBASE-19148: - An alternative to enabling balancePerTable would be to add a cost factor to the stochastic load balancer that reflects the imbalance of each table. > Reevaluate default values of configurations > --- > > Key: HBASE-19148 > URL: https://issues.apache.org/jira/browse/HBASE-19148 > Project: HBase > Issue Type: Bug > Components: defaults >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: > 0002-HBASE-19148-Reevaluate-default-values-of-configurati.patch, > HBASE-19148.master.001.patch, HBASE-19148.master.002.patch > > > Remove cruft and mythologies. Make descriptions more digestible. Change > defaults given experience. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19528) Major Compaction Tool
[ https://issues.apache.org/jira/browse/HBASE-19528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295869#comment-16295869 ] Dave Latham commented on HBASE-19528: - For this column family, we have disabled scheduled major compactions. Other compactions on this and other tables still occur. > Major Compaction Tool > -- > > Key: HBASE-19528 > URL: https://issues.apache.org/jira/browse/HBASE-19528 > Project: HBase > Issue Type: New Feature >Reporter: churro morales >Assignee: churro morales > Fix For: 2.0.0, 3.0.0 > > > The basic overview of how this tool works is: > Parameters: > Table > Stores > ClusterConcurrency > Timestamp > So you input a table, desired concurrency and the list of stores you wish to > major compact. The tool first checks the filesystem to see which stores need > compaction based on the timestamp you provide (default is current time). It > takes that list of stores that require compaction and executes those requests > concurrently with at most N distinct RegionServers compacting at a given > time. Each thread waits for the compaction to complete before moving to the > next queue. If a region split, merge or move happens this tool ensures those > regions get major compacted as well. > This helps us in two ways, we can limit how much I/O bandwidth we are using > for major compaction cluster wide and we are guaranteed after the tool > completes that all requested compactions complete regardless of moves, merges > and splits. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19528) Major Compaction Tool
[ https://issues.apache.org/jira/browse/HBASE-19528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295511#comment-16295511 ] Dave Latham commented on HBASE-19528: - Adding a couple notes - we wanted to avoid filling up the large compactions queue with these requests, to allow other large compactions to proceed. We also wanted to limit the total number in process at once on the cluster to limit the cluster wide IO load (and storage impact on a close to full cluster with few large regions). And, as Rahul noted, wanted to be able to be sure that the job got done completely, even in the presence of regions moving, splitting, or merging. > Major Compaction Tool > -- > > Key: HBASE-19528 > URL: https://issues.apache.org/jira/browse/HBASE-19528 > Project: HBase > Issue Type: New Feature >Reporter: churro morales >Assignee: churro morales > Fix For: 2.0.0, 3.0.0 > > > The basic overview of how this tool works is: > Parameters: > Table > Stores > ClusterConcurrency > Timestamp > So you input a table, desired concurrency and the list of stores you wish to > major compact. The tool first checks the filesystem to see which stores need > compaction based on the timestamp you provide (default is current time). It > takes that list of stores that require compaction and executes those requests > concurrently with at most N distinct RegionServers compacting at a given > time. Each thread waits for the compaction to complete before moving to the > next queue. If a region split, merge or move happens this tool ensures those > regions get major compacted as well. > This helps us in two ways, we can limit how much I/O bandwidth we are using > for major compaction cluster wide and we are guaranteed after the tool > completes that all requested compactions complete regardless of moves, merges > and splits. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19148) Reevaluate default values of configurations
[ https://issues.apache.org/jira/browse/HBASE-19148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293974#comment-16293974 ] Dave Latham commented on HBASE-19148: - Thanks for taking a moment to consider, mighty [~stack]. bq. hbase.regionserver.fileSplitTimeout=3 in branch-2. This better? That's the existing default in what we were running too, but we found 30 seconds was not enough for some large regions under load. bq. I think 'hbase.master.loadbalance.bytable=true' makes sense as default on big cluster where tables are big, less so on small cluster (i think). I'm not convinced of that. I think if you have multiple tables with different workloads, it is often helpful to balance them out, even in a small cluster. It seems more likely for things to go significantly wrong when each table is not balanced and you wish they were than when each table is balanced but you don't really need it. bq. So, we'd run over the block size because 0.95 doesn't give us enough wiggly room within which to close the WAL? We could come down from 0.95. 0.5 seems way down. We'd make lots of files – a pain in itself. Set it at 0.8? Should we up the default block size? That's right, 0.95 didn't give enough wiggle room, and we frequently went over 1 block, sometimes by a little, sometimes by a lot. We found it better to just bump up the block size, and make this low enough to be sure we never exceeded the block. Then in all the files were no larger or more frequent, but less extra fractional blocks. Maybe we should just increase the block size for the WAL files along with turning down the logroll multiplier. In all, I don't think any of these are critical issues, and don't mind if none are changed, just thought it possible others may benefit. > Reevaluate default values of configurations > --- > > Key: HBASE-19148 > URL: https://issues.apache.org/jira/browse/HBASE-19148 > Project: HBase > Issue Type: Bug > Components: defaults >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: > 0002-HBASE-19148-Reevaluate-default-values-of-configurati.patch, > HBASE-19148.master.001.patch > > > Remove cruft and mythologies. Make descriptions more digestible. Change > defaults given experience. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19267) Eclipse project import issues on 2.0
[ https://issues.apache.org/jira/browse/HBASE-19267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291570#comment-16291570 ] Dave Latham commented on HBASE-19267: - Sweet, thanks, Josh! > Eclipse project import issues on 2.0 > > > Key: HBASE-19267 > URL: https://issues.apache.org/jira/browse/HBASE-19267 > Project: HBase > Issue Type: Task > Components: build >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 3.0.0, 2.0.0-beta-1 > > Attachments: HBASE-19267.001.branch-2.patch, > HBASE-19267.002.branch-2.patch, HBASE-19267.002.branch-2.patch, > HBASE-19267.002.patch > > > Trying to do a fresh import of branch-2 nets some errors.. > It seems like a previous change I made to clean up errors (HBASE-13236), > specifically adding the maven-compiler-plugin lifecycle mapping for > m2eclipse, is now causing Eclipse to not compile HBase as Java8. Removing the > lifecycle mapping fixes this. > I assume this only needs to happen for 2.0. > I keep having issues with the JavaNature being ignored. Not yet sure if this > is a result of something we're doing wrong (or just Eclipse being Eclipse). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19267) Eclipse project import issues on 2.0
[ https://issues.apache.org/jira/browse/HBASE-19267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291469#comment-16291469 ] Dave Latham commented on HBASE-19267: - Looks good - everything imports without errors, except hbase-spark and hbase-spark-it, which sounds like they are expected. Thanks, Josh. > Eclipse project import issues on 2.0 > > > Key: HBASE-19267 > URL: https://issues.apache.org/jira/browse/HBASE-19267 > Project: HBase > Issue Type: Task > Components: build >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19267.001.branch-2.patch, > HBASE-19267.002.branch-2.patch, HBASE-19267.002.branch-2.patch, > HBASE-19267.002.patch > > > Trying to do a fresh import of branch-2 nets some errors.. > It seems like a previous change I made to clean up errors (HBASE-13236), > specifically adding the maven-compiler-plugin lifecycle mapping for > m2eclipse, is now causing Eclipse to not compile HBase as Java8. Removing the > lifecycle mapping fixes this. > I assume this only needs to happen for 2.0. > I keep having issues with the JavaNature being ignored. Not yet sure if this > is a result of something we're doing wrong (or just Eclipse being Eclipse). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19267) Eclipse project import issues on 2.0
[ https://issues.apache.org/jira/browse/HBASE-19267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291243#comment-16291243 ] Dave Latham commented on HBASE-19267: - [~elserj], it looks like the patch you just uploaded is the same file as the one from a couple weeks ago - still for branch-2. > Eclipse project import issues on 2.0 > > > Key: HBASE-19267 > URL: https://issues.apache.org/jira/browse/HBASE-19267 > Project: HBase > Issue Type: Task > Components: build >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19267.001.branch-2.patch, > HBASE-19267.002.branch-2.patch, HBASE-19267.002.branch-2.patch > > > Trying to do a fresh import of branch-2 nets some errors.. > It seems like a previous change I made to clean up errors (HBASE-13236), > specifically adding the maven-compiler-plugin lifecycle mapping for > m2eclipse, is now causing Eclipse to not compile HBase as Java8. Removing the > lifecycle mapping fixes this. > I assume this only needs to happen for 2.0. > I keep having issues with the JavaNature being ignored. Not yet sure if this > is a result of something we're doing wrong (or just Eclipse being Eclipse). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19267) Eclipse project import issues on 2.0
[ https://issues.apache.org/jira/browse/HBASE-19267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286626#comment-16286626 ] Dave Latham commented on HBASE-19267: - Thanks, [~elserj]. Nice to see a clean import. Would love to see it hit master or any other branches. > Eclipse project import issues on 2.0 > > > Key: HBASE-19267 > URL: https://issues.apache.org/jira/browse/HBASE-19267 > Project: HBase > Issue Type: Task > Components: build >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19267.001.branch-2.patch, > HBASE-19267.002.branch-2.patch > > > Trying to do a fresh import of branch-2 nets some errors.. > It seems like a previous change I made to clean up errors (HBASE-13236), > specifically adding the maven-compiler-plugin lifecycle mapping for > m2eclipse, is now causing Eclipse to not compile HBase as Java8. Removing the > lifecycle mapping fixes this. > I assume this only needs to happen for 2.0. > I keep having issues with the JavaNature being ignored. Not yet sure if this > is a result of something we're doing wrong (or just Eclipse being Eclipse). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19148) Edit of default configuration
[ https://issues.apache.org/jira/browse/HBASE-19148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256181#comment-16256181 ] Dave Latham commented on HBASE-19148: - Will just mention a few of the configs that we run with where I wonder if the default should be reconsidered. Apologies if some of these have already been changed. - hbase.master.loadbalance.bytable=true - If running with tables with different workloads or profiles, it can be surprising to find a single table very unbalanced on the cluster. Seems like it might be less surprising to keep each table independently balanced. A tricky one I think. - hbase.regionserver.fileSplitTimeout=60 - Painful when the largest region splits are the ones that fail, and gets stuck in a cycle where they fail worse. - hbase.regionserver.logroll.multiplier=0.5 - With the default of 0.95, whenever write load was significant, we saw many log files that had a little bit more than 1 HDFS block worth of data. Seemed a waste. Don't feel strongly about any of them, but curious to see what other folks are thinking. > Edit of default configuration > - > > Key: HBASE-19148 > URL: https://issues.apache.org/jira/browse/HBASE-19148 > Project: HBase > Issue Type: Bug > Components: defaults >Reporter: stack >Priority: Blocker > Fix For: 2.0.0-beta-1 > > > Remove cruft and mythologies. Make descriptions more digestible. Change > defaults given experience. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15482) Provide an option to skip calculating block locations for SnapshotInputFormat
[ https://issues.apache.org/jira/browse/HBASE-15482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16242203#comment-16242203 ] Dave Latham commented on HBASE-15482: - No, that will only stop using the locations. Need to prevent spending the time to calculate them in the first place. See TableSnapshotInputFormatImpl.getSplits and getBestLocations. (Unless that has changed in trunk) > Provide an option to skip calculating block locations for SnapshotInputFormat > - > > Key: HBASE-15482 > URL: https://issues.apache.org/jira/browse/HBASE-15482 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Reporter: Liyin Tang >Assignee: Xiang Li >Priority: Minor > > When a MR job is reading from SnapshotInputFormat, it needs to calculate the > splits based on the block locations in order to get best locality. However, > this process may take a long time for large snapshots. > In some setup, the computing layer, Spark, Hive or Presto could run out side > of HBase cluster. In these scenarios, the block locality doesn't matter. > Therefore, it will be great to have an option to skip calculating the block > locations for every job. That will super useful for the Hive/Presto/Spark > connectors. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205424#comment-16205424
]
Dave Latham commented on HBASE-14247:
-
No, thank you.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff, HBASE-14247.master.001.patch,
> HBASE-14247.master.002.patch, HBASE-14247.master.003.patch,
> HBASE-14247.master.004.patch, HBASE-14247.master.005.patch
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16181154#comment-16181154
]
Dave Latham commented on HBASE-14247:
-
Thanks, [~zghaobac]. It looks like the latest patch would address the concern.
There's an implicit dependency between the clocks assigning the file
modification time and checking time checking the ZK queues. But the
TimeToLiveCleaner would seem to provide plenty of a safety margin for unsynced
clocks.
I didn't review the rest, aside from happening to notice a misspelling of
SEPERATE vs SEPARATE (just in case you care).
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247.master.001.patch,
> HBASE-14247.master.002.patch, HBASE-14247.master.003.patch,
> HBASE-14247-v001.diff, HBASE-14247-v002.diff, HBASE-14247-v003.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16177408#comment-16177408
]
Dave Latham commented on HBASE-14247:
-
That's exactly right. Checking ZK once for the batch of all sub region server
directories is exactly what I've been suggesting.
HBASE-9208 happened 4 years ago. I don't have records of how many logs were
necessary before it became a problem. We did have hundreds of region servers.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247.master.001.patch,
> HBASE-14247.master.002.patch, HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16177017#comment-16177017
]
Dave Latham commented on HBASE-14247:
-
Yes, that would address my concern, at least for our own clusters. I don't
think it's a great way to address the issue, though. People with large
clusters that use it would be the ones most likely to be hit by HBASE-9208. It
also doesn't seem great for HBase to need to support two different directory
layouts for WAL files. I still think it would be better to update the log
cleaner to handle multiple directories well, and then turn it on for everyone.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247.master.001.patch,
> HBASE-14247.master.002.patch, HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176577#comment-16176577
]
Dave Latham commented on HBASE-14247:
-
I still believe that committing this would have a significant risk of
introducing a regression of HBASE-9208. I would be (non-binding) -1 on doing
so until first improving the log cleaner or providing convincing evidence that
it would not happen.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247.master.001.patch,
> HBASE-14247.master.002.patch, HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-12081) Considering Java 9
[ https://issues.apache.org/jira/browse/HBASE-12081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175496#comment-16175496 ] Dave Latham commented on HBASE-12081: - Java 9 is now GA > Considering Java 9 > -- > > Key: HBASE-12081 > URL: https://issues.apache.org/jira/browse/HBASE-12081 > Project: HBase > Issue Type: Umbrella >Reporter: Andrew Purtell > > Java 9 will ship in 2016. This will be the first Java release that makes a > significant compatibility departure from earlier runtimes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18811) Introduce the limited private to filter
[ https://issues.apache.org/jira/browse/HBASE-18811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170259#comment-16170259 ] Dave Latham commented on HBASE-18811: - Thanks, [~chia7712]. Sorry I missed the thread. I understand there's a tradeoff, and if other folks think this is best changed, then I can understand. I see the mighty [~stack] thinks it oughta happen. I'll chime in on the dev list, but no need to resolve yet. > Introduce the limited private to filter > --- > > Key: HBASE-18811 > URL: https://issues.apache.org/jira/browse/HBASE-18811 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18811.v0.patch > > > We have many powerful callback functions to help user to build amazing > application/services. The most of functions are declared as IA.LimitedPrivate > excluding the filters. As i see it, the IA.LimitedPrivate will make the > improvement of filter more flexible. Also, we can introduce more server-side > components to filters. In conclusion, we should consider adding the limited > private level for filter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18811) Introduce the limited private to filter
[ https://issues.apache.org/jira/browse/HBASE-18811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170222#comment-16170222 ] Dave Latham commented on HBASE-18811: - The idea here is that Filters should no longer be part of the client API, but move to being internals, like coprocessors? As one HBase user, we'd be sorry to see this. We do have custom filters deployed, but have shied away from coprocessors due to the lesser degree of stability and higher degree of complexity. I think a discussion on the dev list would probably be good before making this change. > Introduce the limited private to filter > --- > > Key: HBASE-18811 > URL: https://issues.apache.org/jira/browse/HBASE-18811 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18811.v0.patch > > > We have many powerful callback functions to help user to build amazing > application/services. The most of functions are declared as IA.LimitedPrivate > excluding the filters. As i see it, the IA.LimitedPrivate will make the > improvement of filter more flexible. Also, we can introduce more server-side > components to filters. In conclusion, we should consider adding the limited > private level for filter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15400) Use DateTieredCompactor for Date Tiered Compaction
[ https://issues.apache.org/jira/browse/HBASE-15400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16168113#comment-16168113 ] Dave Latham commented on HBASE-15400: - I believe that HBASE-15181 alone would work, but it would not support maintaining a date tiered layout along with major compactions. Major compactions would result in a single file per store, but new flushes from that point on would begin date tiering of files again. We ran it in production for a short time before moving to the version with both HBASE-15389 and HBASE-15400. I would recommend including those two as well - I would expect the branch-1 patches to be pretty easy to port to 1.2. > Use DateTieredCompactor for Date Tiered Compaction > -- > > Key: HBASE-15400 > URL: https://issues.apache.org/jira/browse/HBASE-15400 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15400-0.98.patch, HBASE-15400-15389-v12.patch, > HBASE-15400-branch-1.patch, HBASE-15400.patch, HBASE-15400-v1.pa, > HBASE-15400-v3.patch, HBASE-15400-v3-v3.patch, HBASE-15400-v3-v4.patch, > HBASE-15400-v3-v5.patch, HBASE-15400-v6.patch, HBASE-15400-v7.patch > > > When we compact, we can output multiple files along the current window > boundaries. There are two use cases: > 1. Major compaction: We want to output date tiered store files with data > older than max age archived in trunks of the window size on the higher tier. > Once a window is old enough, we don't combine the windows to promote to the > next tier any further. So files in these windows retain the same timespan as > they were minor-compacted last time, which is the window size of the highest > tier. Major compaction will touch these files and we want to maintain the > same layout. This way, TTL and archiving will be simpler and more efficient. > 2. Bulk load files and the old file generated by major compaction before > upgrading to DTCP. > Pros: > 1. Restore locality, process versioning, updates and deletes while > maintaining the tiered layout. > 2. The best way to fix a skewed layout. > > This work is based on a prototype of DateTieredCompactor from HBASE-15389 and > focused on the part to meet needs for these two use cases while supporting > others. I have to call out a few design decisions: > 1. We only want to output the files along all windows for major compaction. > And we want to output multiple files older than max age in the trunks of the > maximum tier window size determined by base window size, windows per tier and > max age. > 2. For minor compaction, we don't want to output too many files, which will > remain around because of current restriction of contiguous compaction by seq > id. I will only output two files if all the files in the windows are being > combined, one for the data within window and the other for the out-of-window > tail. If there is any file in the window excluded from compaction, only one > file will be output from compaction. When the windows are promoted, the > situation of out of order data will gradually improve. For the incoming > window, we need to accommodate the case with user-specified future data. > 3. We have to pass the boundaries with the list of store file as a complete > time snapshot instead of two separate calls because window layout is > determined by the time the computation is called. So we will need new type of > compaction request. > 4. Since we will assign the same seq id for all output files, we need to sort > by maxTimestamp subsequently. Right now all compaction policy gets the files > sorted for StoreFileManager which sorts by seq id and other criteria. I will > use this order for DTCP only, to avoid impacting other compaction policies. > 5. We need some cleanup of current design of StoreEngine and CompactionPolicy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18642) Deprecate setting of timestamp in client for HLC
[ https://issues.apache.org/jira/browse/HBASE-18642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139354#comment-16139354 ] Dave Latham commented on HBASE-18642: - We use it in multiple ways. A couple use cases first jump to mind: - For analytics data, we have a table with date tiered compaction enabled. We set the cell timestamp to represent the timestamp of the data itself. Then when we run queries on recent data, we can pull only the HFiles with recent data on them, relying on date tiered compaction to maintain the layout with the specified cell timestamps. - For another case, we have certain columns where we want to maintain only the most recent (or oldest) version of a given cell, according to a timestamp of the data itself, including data that may arrive to our system late or out of order. Multiple writes may regularly update that cell, without reading it (or anything) first. We rely on HBase to surface only the copy with the most up to date timestamp (or oldest timestamp by inverting it via Long.MAX_VALUE - timestamp). > Deprecate setting of timestamp in client for HLC > > > Key: HBASE-18642 > URL: https://issues.apache.org/jira/browse/HBASE-18642 > Project: HBase > Issue Type: Brainstorming >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > > With using [HBASE-14070|https://issues.apache.org/jira/browse/HBASE-14070], > clients should no longer set the timestamp for mutations (i.e., put/delete) > because the server will do time stamping instead. Therefore we should look > into deprecating setTimestamp as well as other methods that allow clients to > set timestamps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18661) [HLC] Move clocks to a separate hbase-clocks module
[ https://issues.apache.org/jira/browse/HBASE-18661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139292#comment-16139292 ] Dave Latham commented on HBASE-18661: - Is there a concern about too many modules? What pieces of code deserve module-level isolation? > [HLC] Move clocks to a separate hbase-clocks module > --- > > Key: HBASE-18661 > URL: https://issues.apache.org/jira/browse/HBASE-18661 > Project: HBase > Issue Type: Sub-task >Reporter: Appy >Assignee: Amit Patel > Attachments: HBASE-18661.HBASE-14070.HLC.001.patch > > > I think we can move all clocks related code out of h-common and h-server into > a new package which only needs to depend on h-shaded-protocol. If it's > possible, I think it'll be much cleaner code layout and dependency structure. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18642) Deprecate setting of timestamp in client for HLC
[ https://issues.apache.org/jira/browse/HBASE-18642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139285#comment-16139285 ] Dave Latham commented on HBASE-18642: - Our application relies on this functionality of HBase and would be sad to see it removed. Are there no options considered for retaining this, like having HLC optional on non-system tables, or allowing a smart client to specify HLC compatible timestamps? > Deprecate setting of timestamp in client for HLC > > > Key: HBASE-18642 > URL: https://issues.apache.org/jira/browse/HBASE-18642 > Project: HBase > Issue Type: Brainstorming >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > > With using [HBASE-14070|https://issues.apache.org/jira/browse/HBASE-14070], > clients should no longer set the timestamp for mutations (i.e., put/delete) > because the server will do time stamping instead. Therefore we should look > into deprecating setTimestamp as well as other methods that allow clients to > set timestamps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-10566) cleanup rpcTimeout in the client
[ https://issues.apache.org/jira/browse/HBASE-10566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-10566: Release Note: 3 new settings are now available to configure the socket in the HBase client: - connect timeout: "hbase.ipc.client.socket.timeout.connect" (milliseconds, default: 10 seconds) - read timeout: "hbase.ipc.client.socket.timeout.read" (milliseconds, default: 20 seconds) - write timeout: "hbase.ipc.client.socket.timeout.write" (milliseconds, default: 60 seconds) ipc.socket.timeout is not used anymore. The per operation timeout is still controled by hbase.rpc.timeout was: 3 new settings are now available to configure the socket in the HBase client: - connect timeout: "hbase.ipc.client.socket.timeout.connect" (milliseconds, default: 10 seconds) - write timeout: "hbase.ipc.client.socket.timeout.read" (milliseconds, default: 20 seconds) - read timeout: "hbase.ipc.client.socket.timeout.write" (milliseconds, default: 60 seconds) ipc.socket.timeout is not used anymore. The per operation timeout is still controled by hbase.rpc.timeout > cleanup rpcTimeout in the client > > > Key: HBASE-10566 > URL: https://issues.apache.org/jira/browse/HBASE-10566 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.99.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 10566.sample.patch, 10566.v1.patch, 10566.v2.patch, > 10566.v3.patch > > > There are two issues: > 1) A confusion between the socket timeout and the call timeout > Socket timeouts should be minimal: a default like 20 seconds, that could be > lowered to single digits timeouts for some apps: if we can not write to the > socket in 10 second, we have an issue. This is different from the total > duration (send query + do query + receive query), that can be longer, as it > can include remotes calls on the server and so on. Today, we have a single > value, it does not allow us to have low socket read timeouts. > 2) The timeout can be different between the calls. Typically, if the total > time, retries included is 60 seconds but failed after 2 seconds, then the > remaining is 58s. HBase does this today, but by hacking with a thread local > storage variable. It's a hack (it should have been a parameter of the > methods, the TLS allowed to bypass all the layers. May be protobuf makes this > complicated, to be confirmed), but as well it does not really work, because > we can have multithreading issues (we use the updated rpc timeout of someone > else, or we create a new BlockingRpcChannelImplementation with a random > default timeout). > Ideally, we could send the call timeout to the server as well: it will be > able to dismiss alone the calls that it received but git stick in the request > queue or in the internal retries (on hdfs for example). > This will make the system more reactive to failure. > I think we can solve this now, especially after 10525. The main issue is to > something that fits well with protobuf... > Then it should be easy to have a pool of thread for writers and readers, w/o > a single thread per region server as today. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112051#comment-16112051
]
Dave Latham commented on HBASE-14247:
-
I'd be concerned about first introducing a regression with this issue, and only
then addressing it if there's anyone paying enough attention to do so. I think
it would be better to first ensure the log cleaner will handle multiple
directories in a single batch, then change the log layout to be multiple
directories.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111893#comment-16111893
]
Dave Latham commented on HBASE-14247:
-
I don't think that more threads is a great solution. It still means that, in a
cluster using replication, for every region server's log directory, a thread
will need to read all the replication queues (size also proportional to the
number of region servers) in ZK, instead of just happening once per chore.
This gives O(N^2) performance for N region servers, and is not just theoretical
but has actually caused problems in the past on large clusters (>1000 nodes).
With multiple threads, it likely still won't be fast enough and may end up
hammering ZK if the number of threads is ramped up too high to compensate.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18463) Replication sink frequently triggers HBASE-18023 warnings
[ https://issues.apache.org/jira/browse/HBASE-18463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103784#comment-16103784 ] Dave Latham commented on HBASE-18463: - Are we warning because these types of operations are harmful or dangerous? It seems like if they are, maybe we should change replication to avoid them, but if they are not, then we shouldn't be warning about them. > Replication sink frequently triggers HBASE-18023 warnings > - > > Key: HBASE-18463 > URL: https://issues.apache.org/jira/browse/HBASE-18463 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Andrew Purtell >Priority: Minor > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2 > > > After HBASE-18023 we warn if the number of operations in a multi operation > exceeds a threshold. This is meant to catch potential performance problems or > abusive clients. However while testing simple replication scenarios we have > observed frequent warnings issued as the sink applies received edit batches. > I think we want to either introduce a separate threshold for warning about > RPC submitted by the replication client or exclude ops submitted by the sinks > entirely. Not sure distinguishing the replication client from normal clients > is possible yet. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18391) List the stuffs which are using the patent grant license (PATENTS file) of Facebook; And then discuss and remove them.
[ https://issues.apache.org/jira/browse/HBASE-18391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089935#comment-16089935 ] Dave Latham commented on HBASE-18391: - A was request made for ZSTD at https://github.com/facebook/zstd/issues/335 > List the stuffs which are using the patent grant license (PATENTS file) of > Facebook; And then discuss and remove them. > -- > > Key: HBASE-18391 > URL: https://issues.apache.org/jira/browse/HBASE-18391 > Project: HBase > Issue Type: Task > Components: community, dependencies >Reporter: Chia-Ping Tsai >Priority: Blocker > Labels: incompatible > Fix For: 2.0.0-beta-1 > > > See ["Apache Foundation disallows use of the Facebook “BSD+Patent” > license"|https://news.ycombinator.com/item?id=14779881] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-8770) deletes and puts with the same ts should be resolved according to mvcc/seqNum
[ https://issues.apache.org/jira/browse/HBASE-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039224#comment-16039224 ] Dave Latham edited comment on HBASE-8770 at 6/6/17 4:42 PM: bq. We will remove mvcc in HFile in minor compaction (to save capacity) and delete/put will have same mvcc if they are in one same file. I think that would be OK so long as we first order by seq id, then order Put ahead of Delete for the same seq id. If we're compacting to an HFile, and the Put has higher seq id than the Delete, write them both, and the Put will stay visible. If the Delete has a higher seq id than the Put, then just drop the Put as it should never be visible. Would that work or am I missing something? However, if we do switch to always keeping the seq id around, then the point is moot. Except for the next case of an atomic RowMutation with Put and Delete having the same seq id. Then we have to make a call on the preferred semantic. I think it's more useful to favor the Put over the Delete (would solve HBASE-8626 also). was (Author: davelatham): > We will remove mvcc in HFile in minor compaction (to save capacity) and > delete/put will have same mvcc if they are in one same file. I think that would be OK so long as we first order by seq id, then order Put ahead of Delete for the same seq id. If we're compacting to an HFile, and the Put has higher seq id than the Delete, write them both, and the Put will stay visible. If the Delete has a higher seq id than the Put, then just drop the Put as it should never be visible. Would that work or am I missing something? However, if we do switch to always keeping the seq id around, then the point is moot. Except for the next case of an atomic RowMutation with Put and Delete having the same seq id. Then we have to make a call ont he semantic. I think it's more useful to favor the Put over the Delete (would solve HBASE-8626 also). > deletes and puts with the same ts should be resolved according to mvcc/seqNum > - > > Key: HBASE-8770 > URL: https://issues.apache.org/jira/browse/HBASE-8770 > Project: HBase > Issue Type: Brainstorming >Reporter: Sergey Shelukhin >Priority: Critical > > This came up during HBASE-8721. Puts with the same ts are resolved by seqNum. > It's not clear why deletes with the same ts as a put should always mask the > put, rather than also being resolve by seqNum. > What do you think? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-8770) deletes and puts with the same ts should be resolved according to mvcc/seqNum
[ https://issues.apache.org/jira/browse/HBASE-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039224#comment-16039224 ] Dave Latham commented on HBASE-8770: > We will remove mvcc in HFile in minor compaction (to save capacity) and > delete/put will have same mvcc if they are in one same file. I think that would be OK so long as we first order by seq id, then order Put ahead of Delete for the same seq id. If we're compacting to an HFile, and the Put has higher seq id than the Delete, write them both, and the Put will stay visible. If the Delete has a higher seq id than the Put, then just drop the Put as it should never be visible. Would that work or am I missing something? However, if we do switch to always keeping the seq id around, then the point is moot. Except for the next case of an atomic RowMutation with Put and Delete having the same seq id. Then we have to make a call ont he semantic. I think it's more useful to favor the Put over the Delete (would solve HBASE-8626 also). > deletes and puts with the same ts should be resolved according to mvcc/seqNum > - > > Key: HBASE-8770 > URL: https://issues.apache.org/jira/browse/HBASE-8770 > Project: HBase > Issue Type: Brainstorming >Reporter: Sergey Shelukhin >Priority: Critical > > This came up during HBASE-8721. Puts with the same ts are resolved by seqNum. > It's not clear why deletes with the same ts as a put should always mask the > put, rather than also being resolve by seqNum. > What do you think? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18165) Predicate based deletion during major compactions
[ https://issues.apache.org/jira/browse/HBASE-18165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037657#comment-16037657 ] Dave Latham commented on HBASE-18165: - [~apurtell], sounds great! Would that cover this predicate-based deletion also? > Predicate based deletion during major compactions > - > > Key: HBASE-18165 > URL: https://issues.apache.org/jira/browse/HBASE-18165 > Project: HBase > Issue Type: Brainstorming >Reporter: Lars Hofhansl > > In many cases it is expensive to place a delete per version, column, or > family. > HBase should have way to specify a predicate and remove all Cells matching > the predicate during the next compactions (major and minor). > Nothing more concrete. The tricky part would be to know when it is safe to > remove the predicate, i.e. when we can be sure that all Cells matching the > predicate actually have been removed. > Could potentially use HBASE-12859 for that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18165) Predicate based deletion during major compactions
[ https://issues.apache.org/jira/browse/HBASE-18165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037600#comment-16037600 ] Dave Latham commented on HBASE-18165: - Fascinating thought. We've long toyed with the idea of trying to push column custom logic into compaction via a coprocessor. However, a well defined but simpler interface, similar to Filter would make it much easier to do. An interface with methods called for the boundary of each row, and for each cell within the row, allowing filtering, altering, potentially even inserting (so long as sort order is maintained) would be awesome. > Predicate based deletion during major compactions > - > > Key: HBASE-18165 > URL: https://issues.apache.org/jira/browse/HBASE-18165 > Project: HBase > Issue Type: Brainstorming >Reporter: Lars Hofhansl > > In many cases it is expensive to place a delete per version, column, or > family. > HBase should have way to specify a predicate and remove all Cells matching > the predicate during the next compactions (major and minor). > Nothing more concrete. The tricky part would be to know when it is safe to > remove the predicate, i.e. when we can be sure that all Cells matching the > predicate actually have been removed. > Could potentially use HBASE-12859 for that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-8770) deletes and puts with the same ts should be resolved according to mvcc/seqNum
[ https://issues.apache.org/jira/browse/HBASE-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037227#comment-16037227 ] Dave Latham commented on HBASE-8770: Thanks, [~yangzhe1991]. Is there hope for HBASE-15968 to make it into 2.0? I don't see activity there for several months. If not, would simply changing the sort order to order by seq id before cell type for this issue be a possibility for 2.0? > deletes and puts with the same ts should be resolved according to mvcc/seqNum > - > > Key: HBASE-8770 > URL: https://issues.apache.org/jira/browse/HBASE-8770 > Project: HBase > Issue Type: Brainstorming >Reporter: Sergey Shelukhin >Priority: Critical > > This came up during HBASE-8721. Puts with the same ts are resolved by seqNum. > It's not clear why deletes with the same ts as a put should always mask the > put, rather than also being resolve by seqNum. > What do you think? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-8770) deletes and puts with the same ts should be resolved according to mvcc/seqNum
[ https://issues.apache.org/jira/browse/HBASE-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035443#comment-16035443 ] Dave Latham commented on HBASE-8770: for an app using client-set meaningful timestamps, sure wishing this was already in hbase. have anyone's thoughts changed on it. any chance it could land in 2.0? > deletes and puts with the same ts should be resolved according to mvcc/seqNum > - > > Key: HBASE-8770 > URL: https://issues.apache.org/jira/browse/HBASE-8770 > Project: HBase > Issue Type: Brainstorming >Reporter: Sergey Shelukhin >Priority: Critical > > This came up during HBASE-8721. Puts with the same ts are resolved by seqNum. > It's not clear why deletes with the same ts as a put should always mask the > put, rather than also being resolve by seqNum. > What do you think? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18144) Forward-port the old exclusive row lock; there are scenarios where it performs better
[ https://issues.apache.org/jira/browse/HBASE-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16033286#comment-16033286 ] Dave Latham commented on HBASE-18144: - Fascinating. Thanks, for sharing so much of the detail of the sleuthing story. Having exclusive locks as a config option sounds like it would this one application that is aware of what is going on, but how likely is it that other folks are going to know when to turn this on? Would sure be great if there was a solution that worked without configuration. > Forward-port the old exclusive row lock; there are scenarios where it > performs better > - > > Key: HBASE-18144 > URL: https://issues.apache.org/jira/browse/HBASE-18144 > Project: HBase > Issue Type: Bug > Components: Increment >Affects Versions: 1.2.5 >Reporter: stack >Assignee: stack > Fix For: 2.0.0, 1.3.2, 1.2.7 > > > Description to follow. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16015878#comment-16015878
]
Dave Latham commented on HBASE-14247:
-
Does the patch address the log cleaner performance concern?
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15989087#comment-15989087 ] Dave Latham commented on HBASE-15181: - [~tychang] it looks like there's now work going on to help opentsdb take advantage of this https://github.com/OpenTSDB/opentsdb/pull/971 > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15181-0.98-ADD.patch, HBASE-15181-0.98.patch, > HBASE-15181-0.98.v4.patch, HBASE-15181-98.patch, HBASE-15181-ADD.patch, > HBASE-15181-branch-1.patch, HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-master-v3.patch, > HBASE-15181-master-v4.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing > Results in our production is at > https://docs.google.com/document/d/1GqRtQZMMkTEWOijZc8UCTqhACNmdxBSjtAQSYIWsmGU/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17919) HBase 2.x over hadoop 3.x umrella
[ https://issues.apache.org/jira/browse/HBASE-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-17919: Description: We should try to get hbase 2.x branch working against the recently release hadoop 3.0.0 alphas. These data 3.0.0-alpha2 is the latest. HBASE-16733 and HBASE-17953 got the compile level checks in but we should progress to getting unit tests to pass and a build against hadoop3 up. This umbrella issue will capture issues around this project. was: We should try to get hadoop 2.x branch working against the recently release hadoop 3.0.0 alphas. These data 3.0.0-alpha2 is the latest. HBASE-16733 and HBASE-17953 got the compile level checks in but we should progress to getting unit tests to pass and a build against hadoop3 up. This umbrella issue will capture issues around this project. > HBase 2.x over hadoop 3.x umrella > -- > > Key: HBASE-17919 > URL: https://issues.apache.org/jira/browse/HBASE-17919 > Project: HBase > Issue Type: Umbrella > Components: hadoop3 >Affects Versions: 2.0.0 >Reporter: Jonathan Hsieh > > We should try to get hbase 2.x branch working against the recently release > hadoop 3.0.0 alphas. These data 3.0.0-alpha2 is the latest. > HBASE-16733 and HBASE-17953 got the compile level checks in but we should > progress to getting unit tests to pass and a build against hadoop3 up. > This umbrella issue will capture issues around this project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15712) Tool for retiring empty regions
[ https://issues.apache.org/jira/browse/HBASE-15712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937049#comment-15937049 ] Dave Latham commented on HBASE-15712: - Thanks, Nick. Do you know what versions of HBase it is compatible with? > Tool for retiring empty regions > --- > > Key: HBASE-15712 > URL: https://issues.apache.org/jira/browse/HBASE-15712 > Project: HBase > Issue Type: Task > Components: scripts >Reporter: Nick Dimiduk >Priority: Minor > > For folks with rowkey design that includes timestamp, in combination with the > TTL feature, empty regions will accumulate. This includes folks making use of > Phoenix's [Row timestamps|https://phoenix.apache.org/rowtimestamp.html]. > Provide some scripts for cleaning up these empty regions. > See conversation over on hbase-user: > http://mail-archives.apache.org/mod_mbox/hbase-user/201604.mbox/%3CCANZa=gtzgnpqeemvj5p8rjfv-x93vnragoymd1flyc1ahjz...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932909#comment-15932909 ] Dave Latham edited comment on HBASE-15181 at 3/20/17 4:02 PM: -- I don't know enough about the details of the data schema that opentsdb uses to say if it will benefit. was (Author: davelatham): I don't know enough about the details of the data schema that opentsdb to say if it will benefit. > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15181-0.98-ADD.patch, HBASE-15181-0.98.patch, > HBASE-15181-0.98.v4.patch, HBASE-15181-98.patch, HBASE-15181-ADD.patch, > HBASE-15181-branch-1.patch, HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-master-v3.patch, > HBASE-15181-master-v4.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing > Results in our production is at > https://docs.google.com/document/d/1GqRtQZMMkTEWOijZc8UCTqhACNmdxBSjtAQSYIWsmGU/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932909#comment-15932909 ] Dave Latham commented on HBASE-15181: - I don't know enough about the details of the data schema that opentsdb to say if it will benefit. > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15181-0.98-ADD.patch, HBASE-15181-0.98.patch, > HBASE-15181-0.98.v4.patch, HBASE-15181-98.patch, HBASE-15181-ADD.patch, > HBASE-15181-branch-1.patch, HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-master-v3.patch, > HBASE-15181-master-v4.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing > Results in our production is at > https://docs.google.com/document/d/1GqRtQZMMkTEWOijZc8UCTqhACNmdxBSjtAQSYIWsmGU/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15928898#comment-15928898 ] Dave Latham commented on HBASE-15181: - Indeed that's true (and we do the same), but the application needs to be intelligent enough to use it. > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15181-0.98-ADD.patch, HBASE-15181-0.98.patch, > HBASE-15181-0.98.v4.patch, HBASE-15181-98.patch, HBASE-15181-ADD.patch, > HBASE-15181-branch-1.patch, HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-master-v3.patch, > HBASE-15181-master-v4.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing > Results in our production is at > https://docs.google.com/document/d/1GqRtQZMMkTEWOijZc8UCTqhACNmdxBSjtAQSYIWsmGU/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927057#comment-15927057 ] Dave Latham commented on HBASE-15181: - It's been awhile since I looked at opentsdb's write/read patterns, but I do think date tiered compaction would be a great fit for time series data, especially if the engine is aware. To take good advantage of it, the queries would need to set the time range on the scan itself (as opposed to purely encoding time information directly in the row/column identifiers and relying on them for time bounding). I'm not sure if opentsdb does that. > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15181-0.98-ADD.patch, HBASE-15181-0.98.patch, > HBASE-15181-0.98.v4.patch, HBASE-15181-98.patch, HBASE-15181-ADD.patch, > HBASE-15181-branch-1.patch, HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-master-v3.patch, > HBASE-15181-master-v4.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing > Results in our production is at > https://docs.google.com/document/d/1GqRtQZMMkTEWOijZc8UCTqhACNmdxBSjtAQSYIWsmGU/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15454) Freeze date tiered store files older than max age
[ https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-15454: Summary: Freeze date tiered store files older than max age (was: Archive store files older than max age) > Freeze date tiered store files older than max age > - > > Key: HBASE-15454 > URL: https://issues.apache.org/jira/browse/HBASE-15454 > Project: HBase > Issue Type: New Feature > Components: Compaction >Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15454.patch, HBASE-15454-v1.patch, > HBASE-15454-v2.patch, HBASE-15454-v3.patch, HBASE-15454-v4.patch, > HBASE-15454-v5.patch, HBASE-15454-v6.patch, HBASE-15454-v7.patch > > > In date tiered compaction, the store files older than max age are never > touched by minor compactions. Here we introduce a 'freeze window' operation, > which does the follow things: > 1. Find all store files that contains cells whose timestamp are in the give > window. > 2. Compaction all these files and output one file for each window that these > files covered. > After the compaction, we will have only one in the give window, and all cells > whose timestamp are in the give window are in the only file. And if you do > not write new cells with an older timestamp in this window, the file will > never be changed. This makes it easier to do erasure coding on the freezed > file to reduce redundence. And also, it makes it possible to check > consistency between master and peer cluster incrementally. > And why use the word 'freeze'? > Because there is already an 'HFileArchiver' class. I want to use a different > word to prevent confusing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15368) Add pluggable window support
[
https://issues.apache.org/jira/browse/HBASE-15368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Latham updated HBASE-15368:
Fix Version/s: (was: 1.4.0)
> Add pluggable window support
>
>
> Key: HBASE-15368
> URL: https://issues.apache.org/jira/browse/HBASE-15368
> Project: HBase
> Issue Type: Sub-task
> Components: Compaction
>Affects Versions: 2.0.0, 1.3.0, 0.98.19, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.3.0, 0.98.19
>
> Attachments: HBASE-15368-0.98.patch, HBASE-15368-branch-1.patch,
> HBASE-15368.patch, HBASE-15368-v1.patch, HBASE-15368-v2.patch,
> HBASE-15368-v3.patch, HBASE-15368-v4.patch, HBASE-15368-v5.patch,
> HBASE-15368-v6.patch, HBASE-15368-v7.patch
>
>
> Abstract a {{CompactionWindow}} and a {{CompactionWindowFactory}}. Both are
> orthogonal to the implementation of DateTieredCompactionPolicy. Users can
> implement their own {{CompactionWindow}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-15339) Improve DateTieredCompactionPolicy
[ https://issues.apache.org/jira/browse/HBASE-15339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham resolved HBASE-15339. - Resolution: Fixed > Improve DateTieredCompactionPolicy > -- > > Key: HBASE-15339 > URL: https://issues.apache.org/jira/browse/HBASE-15339 > Project: HBase > Issue Type: Improvement > Components: Compaction >Reporter: Duo Zhang > Fix For: 2.0.0, 0.98.19, 1.3.0 > > > Add multi-output support. > Add archive old data support. > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15339) Improve DateTieredCompactionPolicy
[ https://issues.apache.org/jira/browse/HBASE-15339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-15339: Fix Version/s: 1.3.0 0.98.19 2.0.0 > Improve DateTieredCompactionPolicy > -- > > Key: HBASE-15339 > URL: https://issues.apache.org/jira/browse/HBASE-15339 > Project: HBase > Issue Type: Improvement > Components: Compaction >Reporter: Duo Zhang > Fix For: 2.0.0, 1.3.0, 0.98.19 > > > Add multi-output support. > Add archive old data support. > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15389) Write out multiple files when compaction
[
https://issues.apache.org/jira/browse/HBASE-15389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Latham updated HBASE-15389:
Fix Version/s: (was: 1.4.0)
> Write out multiple files when compaction
>
>
> Key: HBASE-15389
> URL: https://issues.apache.org/jira/browse/HBASE-15389
> Project: HBase
> Issue Type: Sub-task
> Components: Compaction
>Affects Versions: 2.0.0, 0.98.19, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.3.0, 0.98.19
>
> Attachments: HBASE-15389-0.98.patch, HBASE-15389-0.98.v1.patch,
> HBASE-15389-0.98.v2.patch, HBASE-15389-0.98.v3.patch,
> HBASE-15389-branch-1.patch, HBASE-15389-branch-1.v1.patch, HBASE-15389.patch,
> HBASE-15389-uc.patch, HBASE-15389-v10.patch, HBASE-15389-v11.patch,
> HBASE-15389-v12.patch, HBASE-15389-v13.patch, HBASE-15389-v14.patch,
> HBASE-15389-v1.patch, HBASE-15389-v2.patch, HBASE-15389-v3.patch,
> HBASE-15389-v4.patch, HBASE-15389-v5.patch, HBASE-15389-v6.patch,
> HBASE-15389-v7.patch, HBASE-15389-v8.patch, HBASE-15389-v9.patch
>
>
> Add {{DateTieredCompactor}} and {{DateTieredMultiFileWriter}} to support
> writing out multiple files based on timestamp windows when doing date tiered
> compactions.
> Abstract {{AbstractMultiOutputCompactor}} and {{AbstractMultiFileWriter}}
> which contain the general logic for multi output and can be used to implement
> new compaction policies that requires multi output in the future.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-15527) Refactor Compactor related classes
[ https://issues.apache.org/jira/browse/HBASE-15527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-15527: Fix Version/s: (was: 1.4.0) > Refactor Compactor related classes > -- > > Key: HBASE-15527 > URL: https://issues.apache.org/jira/browse/HBASE-15527 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15527-0.98.patch, HBASE-15527-branch-1.patch, > HBASE-15527-branch-1.v1.patch, HBASE-15527.patch, HBASE-15527-v1.patch > > > DefaultCompactor and MultiOutputCompactor still have a lot of duplicate code > now, need refactoring. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15665) Support using different StoreFileComparators for different CompactionPolicies
[ https://issues.apache.org/jira/browse/HBASE-15665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-15665: Fix Version/s: (was: 1.4.0) > Support using different StoreFileComparators for different CompactionPolicies > - > > Key: HBASE-15665 > URL: https://issues.apache.org/jira/browse/HBASE-15665 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Affects Versions: 2.0.0, 1.3.0, 0.98.19, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15665-0.98.patch, HBASE-15665-branch-1.patch, > HBASE-15665.patch > > > Now for DateTieredCompactionPolicy, if we output multiple files when > compaction, we will use the same max sequence id for all the output files(see > HBASE-15389 for more details). So we need to sort the store files by > timestamp if they have the same max sequence id which is different from the > original store file comparator. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15400) Use DateTieredCompactor for Date Tiered Compaction
[ https://issues.apache.org/jira/browse/HBASE-15400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-15400: Fix Version/s: (was: 1.4.0) > Use DateTieredCompactor for Date Tiered Compaction > -- > > Key: HBASE-15400 > URL: https://issues.apache.org/jira/browse/HBASE-15400 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15400-0.98.patch, HBASE-15400-15389-v12.patch, > HBASE-15400-branch-1.patch, HBASE-15400.patch, HBASE-15400-v1.pa, > HBASE-15400-v3.patch, HBASE-15400-v3-v3.patch, HBASE-15400-v3-v4.patch, > HBASE-15400-v3-v5.patch, HBASE-15400-v6.patch, HBASE-15400-v7.patch > > > When we compact, we can output multiple files along the current window > boundaries. There are two use cases: > 1. Major compaction: We want to output date tiered store files with data > older than max age archived in trunks of the window size on the higher tier. > Once a window is old enough, we don't combine the windows to promote to the > next tier any further. So files in these windows retain the same timespan as > they were minor-compacted last time, which is the window size of the highest > tier. Major compaction will touch these files and we want to maintain the > same layout. This way, TTL and archiving will be simpler and more efficient. > 2. Bulk load files and the old file generated by major compaction before > upgrading to DTCP. > Pros: > 1. Restore locality, process versioning, updates and deletes while > maintaining the tiered layout. > 2. The best way to fix a skewed layout. > > This work is based on a prototype of DateTieredCompactor from HBASE-15389 and > focused on the part to meet needs for these two use cases while supporting > others. I have to call out a few design decisions: > 1. We only want to output the files along all windows for major compaction. > And we want to output multiple files older than max age in the trunks of the > maximum tier window size determined by base window size, windows per tier and > max age. > 2. For minor compaction, we don't want to output too many files, which will > remain around because of current restriction of contiguous compaction by seq > id. I will only output two files if all the files in the windows are being > combined, one for the data within window and the other for the out-of-window > tail. If there is any file in the window excluded from compaction, only one > file will be output from compaction. When the windows are promoted, the > situation of out of order data will gradually improve. For the incoming > window, we need to accommodate the case with user-specified future data. > 3. We have to pass the boundaries with the list of store file as a complete > time snapshot instead of two separate calls because window layout is > determined by the time the computation is called. So we will need new type of > compaction request. > 4. Since we will assign the same seq id for all output files, we need to sort > by maxTimestamp subsequently. Right now all compaction policy gets the files > sorted for StoreFileManager which sorts by seq id and other criteria. I will > use this order for DTCP only, to avoid impacting other compaction policies. > 5. We need some cleanup of current design of StoreEngine and CompactionPolicy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15454) Archive store files older than max age
[ https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-15454: Issue Type: New Feature (was: Sub-task) Parent: (was: HBASE-15339) > Archive store files older than max age > -- > > Key: HBASE-15454 > URL: https://issues.apache.org/jira/browse/HBASE-15454 > Project: HBase > Issue Type: New Feature > Components: Compaction >Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15454.patch, HBASE-15454-v1.patch, > HBASE-15454-v2.patch, HBASE-15454-v3.patch, HBASE-15454-v4.patch, > HBASE-15454-v5.patch, HBASE-15454-v6.patch, HBASE-15454-v7.patch > > > In date tiered compaction, the store files older than max age are never > touched by minor compactions. Here we introduce a 'freeze window' operation, > which does the follow things: > 1. Find all store files that contains cells whose timestamp are in the give > window. > 2. Compaction all these files and output one file for each window that these > files covered. > After the compaction, we will have only one in the give window, and all cells > whose timestamp are in the give window are in the only file. And if you do > not write new cells with an older timestamp in this window, the file will > never be changed. This makes it easier to do erasure coding on the freezed > file to reduce redundence. And also, it makes it possible to check > consistency between master and peer cluster incrementally. > And why use the word 'freeze'? > Because there is already an 'HFileArchiver' class. I want to use a different > word to prevent confusing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15400) Use DateTieredCompactor for Date Tiered Compaction
[ https://issues.apache.org/jira/browse/HBASE-15400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925086#comment-15925086 ] Dave Latham commented on HBASE-15400: - Same answer as in HBASE-15181: "The branch-1 patch likely would have applied to 1.2 as well when it was developed, but since 1.2.x patch releases should only have bug fixes, not new features like this it wasn't applied there. I don't know if branch-1.2 has changed so that it would not apply." > Use DateTieredCompactor for Date Tiered Compaction > -- > > Key: HBASE-15400 > URL: https://issues.apache.org/jira/browse/HBASE-15400 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19, 1.4.0 > > Attachments: HBASE-15400-0.98.patch, HBASE-15400-15389-v12.patch, > HBASE-15400-branch-1.patch, HBASE-15400.patch, HBASE-15400-v1.pa, > HBASE-15400-v3.patch, HBASE-15400-v3-v3.patch, HBASE-15400-v3-v4.patch, > HBASE-15400-v3-v5.patch, HBASE-15400-v6.patch, HBASE-15400-v7.patch > > > When we compact, we can output multiple files along the current window > boundaries. There are two use cases: > 1. Major compaction: We want to output date tiered store files with data > older than max age archived in trunks of the window size on the higher tier. > Once a window is old enough, we don't combine the windows to promote to the > next tier any further. So files in these windows retain the same timespan as > they were minor-compacted last time, which is the window size of the highest > tier. Major compaction will touch these files and we want to maintain the > same layout. This way, TTL and archiving will be simpler and more efficient. > 2. Bulk load files and the old file generated by major compaction before > upgrading to DTCP. > Pros: > 1. Restore locality, process versioning, updates and deletes while > maintaining the tiered layout. > 2. The best way to fix a skewed layout. > > This work is based on a prototype of DateTieredCompactor from HBASE-15389 and > focused on the part to meet needs for these two use cases while supporting > others. I have to call out a few design decisions: > 1. We only want to output the files along all windows for major compaction. > And we want to output multiple files older than max age in the trunks of the > maximum tier window size determined by base window size, windows per tier and > max age. > 2. For minor compaction, we don't want to output too many files, which will > remain around because of current restriction of contiguous compaction by seq > id. I will only output two files if all the files in the windows are being > combined, one for the data within window and the other for the out-of-window > tail. If there is any file in the window excluded from compaction, only one > file will be output from compaction. When the windows are promoted, the > situation of out of order data will gradually improve. For the incoming > window, we need to accommodate the case with user-specified future data. > 3. We have to pass the boundaries with the list of store file as a complete > time snapshot instead of two separate calls because window layout is > determined by the time the computation is called. So we will need new type of > compaction request. > 4. Since we will assign the same seq id for all output files, we need to sort > by maxTimestamp subsequently. Right now all compaction policy gets the files > sorted for StoreFileManager which sorts by seq id and other criteria. I will > use this order for DTCP only, to avoid impacting other compaction policies. > 5. We need some cleanup of current design of StoreEngine and CompactionPolicy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15454) Archive store files older than max age
[ https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924913#comment-15924913 ] Dave Latham commented on HBASE-15454: - [~Apache9] Do you have any updates on this issue? Have you been using this patch? Do you want it to go in to HBase? Or think we should close this and the parent jiras now? > Archive store files older than max age > -- > > Key: HBASE-15454 > URL: https://issues.apache.org/jira/browse/HBASE-15454 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15454.patch, HBASE-15454-v1.patch, > HBASE-15454-v2.patch, HBASE-15454-v3.patch, HBASE-15454-v4.patch, > HBASE-15454-v5.patch, HBASE-15454-v6.patch, HBASE-15454-v7.patch > > > In date tiered compaction, the store files older than max age are never > touched by minor compactions. Here we introduce a 'freeze window' operation, > which does the follow things: > 1. Find all store files that contains cells whose timestamp are in the give > window. > 2. Compaction all these files and output one file for each window that these > files covered. > After the compaction, we will have only one in the give window, and all cells > whose timestamp are in the give window are in the only file. And if you do > not write new cells with an older timestamp in this window, the file will > never be changed. This makes it easier to do erasure coding on the freezed > file to reduce redundence. And also, it makes it possible to check > consistency between master and peer cluster incrementally. > And why use the word 'freeze'? > Because there is already an 'HFileArchiver' class. I want to use a different > word to prevent confusing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924910#comment-15924910 ] Dave Latham commented on HBASE-15181: - The branch-1 patch likely would have applied to 1.2 as well when it was developed, but since 1.2.x patch releases should only have bug fixes, not new features like this it wasn't applied there. I don't know if branch-1.2 has changed so that it would not apply. If you do try, I would recommend also picking up the follow on work in subtasks of HBASE-15339 > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15181-0.98-ADD.patch, HBASE-15181-0.98.patch, > HBASE-15181-0.98.v4.patch, HBASE-15181-98.patch, HBASE-15181-ADD.patch, > HBASE-15181-branch-1.patch, HBASE-15181-master-v1.patch, > HBASE-15181-master-v2.patch, HBASE-15181-master-v3.patch, > HBASE-15181-master-v4.patch, HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing > Results in our production is at > https://docs.google.com/document/d/1GqRtQZMMkTEWOijZc8UCTqhACNmdxBSjtAQSYIWsmGU/edit# -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17392) Load DefaultStoreEngine when user misconfigures 'hbase.hstore.engine.class'
[ https://issues.apache.org/jira/browse/HBASE-17392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15786139#comment-15786139 ] Dave Latham commented on HBASE-17392: - I use DateTieredStoreEngine from HBASE-15400. If I have a typo in the configuration, I'd prefer to fail fast and loud rather than fallback to the DefaultStoreEngine which may screw up the layout of my data. > Load DefaultStoreEngine when user misconfigures 'hbase.hstore.engine.class' > --- > > Key: HBASE-17392 > URL: https://issues.apache.org/jira/browse/HBASE-17392 > Project: HBase > Issue Type: Improvement >Reporter: huaxiang sun >Assignee: huaxiang sun >Priority: Minor > > When user misconfigures 'hbase.hstore.engine.class', region server complains > "Class not found" and gives up. In this case, we need to load the > DefaultStoreEngine to avoid that. Sanity check needs to be done to prevent > user from misconfiguration as well. > https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreEngine.java#L121 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17339) Scan-Memory-First Optimization for Get Operation
[ https://issues.apache.org/jira/browse/HBASE-17339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15780507#comment-15780507 ] Dave Latham commented on HBASE-17339: - Some previous discussion of restrictions on client provided timestamps occurred at HBASE-10247. In particular, replication support was deemed to be a blocker at the time. > Scan-Memory-First Optimization for Get Operation > > > Key: HBASE-17339 > URL: https://issues.apache.org/jira/browse/HBASE-17339 > Project: HBase > Issue Type: Improvement >Reporter: Eshcar Hillel > Attachments: HBASE-17339-V01.patch > > > The current implementation of a get operation (to retrieve values for a > specific key) scans through all relevant stores of the region; for each store > both memory components (memstores segments) and disk components (hfiles) are > scanned in parallel. > We suggest to apply an optimization that speculatively scans memory-only > components first and only if the result is incomplete scans both memory and > disk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17178) Add region balance throttling
[ https://issues.apache.org/jira/browse/HBASE-17178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15703856#comment-15703856 ] Dave Latham commented on HBASE-17178: - The goal of both, from what I can tell is to limit the unavailability of regions during balancing. I'm happy to see the issue picked up again, and hope an implementation makes it in this time. > Add region balance throttling > - > > Key: HBASE-17178 > URL: https://issues.apache.org/jira/browse/HBASE-17178 > Project: HBase > Issue Type: Improvement > Components: Balancer >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-17178-v1.patch > > > Our online cluster serves dozens of tables and different tables serve for > different services. If the balancer moves too many regions in the same time, > it will decrease the availability for some table or some services. So we add > region balance throttling on our online serve cluster. > We introduce a new config hbase.balancer.max.balancing.regions, which means > the max number of regions in transition when balancing. > If we config this to 1 and a table have 100 regions, then the table will have > 99 regions available at any time. It helps a lot for our use case and it has > been running a long time > our production cluster. > But for some use case, we need the balancer run faster. If a cluster has 100 > regionservers, then it add 50 new regionservers for peak requests. Then it > need balancer run as soon as > possible and let the cluster reach a balance state soon. Our idea is compute > max number of regions in transition by the max balancing time and the average > time of region in transition. > Then the balancer use the computed value to throttling. > Examples for understanding. > A cluster has 100 regionservers, each regionserver has 200 regions and the > average time of region in transition is 1 seconds, we config the max > balancing time is 10 * 60 seconds. > Case 1. One regionserver crash, the cluster at most need balance 200 regions. > Then 200 / (10 * 60s / 1s) < 1, it means the max number of regions in > transition is 1 when balancing. Then the balancer can move region one by one > and the cluster will have high availability when balancing. > Case 2. Add other 100 regionservers, the cluster at most need balance 1 > regions. Then 1 / (10 * 60s / 1s) = 16.7, it means the max number of > regions in transition is 17 when balancing. Then the cluster can reach a > balance state within the max balancing time. > Any suggestions are welcomed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12890) Provide a way to throttle the number of regions moved by the balancer
[ https://issues.apache.org/jira/browse/HBASE-12890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15702228#comment-15702228 ] Dave Latham commented on HBASE-12890: - Watchers may be interested in a new attempt at HBASE-17178 > Provide a way to throttle the number of regions moved by the balancer > - > > Key: HBASE-12890 > URL: https://issues.apache.org/jira/browse/HBASE-12890 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.98.10 >Reporter: churro morales >Assignee: churro morales > Attachments: HBASE-12890.patch > > > We have a very large cluster and we frequently add remove quite a few > regionservers from our cluster. Whenever we do this the balancer moves > thousands of regions at once. Instead we provide a configuration parameter: > hbase.balancer.max.regions. This limits the number of regions that are > balanced per iteration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17178) Add region balance throttling
[ https://issues.apache.org/jira/browse/HBASE-17178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15702225#comment-15702225 ] Dave Latham commented on HBASE-17178: - See HBASE-12890 for some related discussion / implementation ideas. > Add region balance throttling > - > > Key: HBASE-17178 > URL: https://issues.apache.org/jira/browse/HBASE-17178 > Project: HBase > Issue Type: Improvement > Components: Balancer >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-17178-v1.patch > > > Our online cluster serves dozens of tables and different tables serve for > different services. If the balancer moves too many regions in the same time, > it will decrease the availability for some table or some services. So we add > region balance throttling on our online serve cluster. > We introduce a new config hbase.balancer.max.balancing.regions, which means > the max number of regions in transition when balancing. > If we config this to 1 and a table have 100 regions, then the table will have > 99 regions available at any time. It helps a lot for our use case and it has > been running a long time > our production cluster. > But for some use case, we need the balancer run faster. If a cluster has 100 > regionservers, then it add 50 new regionservers for peak requests. Then it > need balancer run as soon as > possible and let the cluster reach a balance state soon. Our idea is compute > max number of regions in transition by the max balancing time and the average > time of region in transition. > Then the balancer use the computed value to throttling. > Examples for understanding. > A cluster has 100 regionservers, each regionserver has 200 regions and the > average time of region in transition is 1 seconds, we config the max > balancing time is 10 * 60 seconds. > Case 1. One regionserver crash, the cluster at most need balance 200 regions. > Then 200 / (10 * 60s / 1s) < 1, it means the max number of regions in > transition is 1 when balancing. Then the balancer can move region one by one > and the cluster will have high availability when balancing. > Case 2. Add other 100 regionservers, the cluster at most need balance 1 > regions. Then 1 / (10 * 60s / 1s) = 16.7, it means the max number of > regions in transition is 17 when balancing. Then the cluster can reach a > balance state within the max balancing time. > Any suggestions are welcomed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16894) Create more than 1 split per region, generalize HBASE-12590
[
https://issues.apache.org/jira/browse/HBASE-16894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15688128#comment-15688128
]
Dave Latham commented on HBASE-16894:
-
Deriving split points from the actual distribution of data as captured in
HFiles sounds great. However, as a user of a large cluster I'm worried that a
single threaded process doing HDFS operations for every region in a table with
10k, 100k, or more regions could take a great deal of time and/or bottleneck on
the NameNode. Since the region servers already likely have the index data
cached, taking advantage of it would be great if possible.
> Create more than 1 split per region, generalize HBASE-12590
> ---
>
> Key: HBASE-16894
> URL: https://issues.apache.org/jira/browse/HBASE-16894
> Project: HBase
> Issue Type: Improvement
>Reporter: Enis Soztutar
>Assignee: Yi Liang
> Labels: beginner, beginners
>
> A common request from users is to be able to better control how many map
> tasks are created per region. Right now, it is always 1 region = 1 input
> split = 1 map task. Same goes for Spark since it uses the TIF. With region
> sizes as large as 50 GBs, it is desirable to be able to create more than 1
> split per region.
> HBASE-12590 adds a config property for MR jobs to be able to handle skew in
> region sizes. The algorithm is roughly:
> {code}
> If (region size >= average size*ratio) : cut the region into two MR input
> splits
> If (average size <= region size < average size*ratio) : one region as one MR
> input split
> If (sum of several continuous regions size < average size * ratio): combine
> these regions into one MR input split.
> {code}
> Although we can set data skew ratio to be 0.5 or something to abuse
> HBASE-12590 into creating more than 1 split task per region, it is not ideal.
> But there is no way to create more with the patch as it is. For example we
> cannot create more than 2 tasks per region.
> If we want to fix this properly, we should extend the approach in
> HBASE-12590, and make it so that the client can specify the desired num of
> mappers, or desired split size, and the TIF generates the splits based on the
> current region sizes very similar to the algorithm in HBASE-12590, but a more
> generic way. This also would eliminate the hand tuning of data skew ratio.
> We also can think about the guidepost approach that Phoenix has in the stats
> table which is used for exactly this purpose. Right now, the region can be
> split into powers of two assuming uniform distribution within the region.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16710) Add ZStandard Codec to Compression.java
[
https://issues.apache.org/jira/browse/HBASE-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15526898#comment-15526898
]
Dave Latham commented on HBASE-16710:
-
Should it be {{ZSTD}} instead of {{ZSTANDARD}}?
> Add ZStandard Codec to Compression.java
> ---
>
> Key: HBASE-16710
> URL: https://issues.apache.org/jira/browse/HBASE-16710
> Project: HBase
> Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: churro morales
>Assignee: churro morales
>Priority: Minor
> Attachments: HBASE-16710-0.98.patch, HBASE-16710-1.2.patch,
> HBASE-16710.patch
>
>
> HADOOP-13578 is adding the ZStandardCodec to hadoop. This is a placeholder
> to ensure it gets added to hbase once this gets upstream.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-16632) Optimize HBase RPC Encryption Performance
[
https://issues.apache.org/jira/browse/HBASE-16632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Latham resolved HBASE-16632.
-
Resolution: Duplicate
> Optimize HBase RPC Encryption Performance
> -
>
> Key: HBASE-16632
> URL: https://issues.apache.org/jira/browse/HBASE-16632
> Project: HBase
> Issue Type: Bug
> Components: security
>Reporter: Robert Yokota
>
> Similar to HADOOP-10768, when HBase RPC encryption is enabled by setting
> {{hbase.rpc.protection}} to {{privacy}}, it does not use AES-NI acceleration
> by default.
> We have implemented a workaround for HBase to use accelerated encryption that
> can be shown to improve performance, see
> https://rayokota.wordpress.com/2016/09/13/adventures-in-hardening-hbase/. I
> will attach a patch of the changes for our workaround, which borrows heavily
> from the patch for HADOOP-10768, but I'll leave it to the HBase security
> experts as to what is the best approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16583) Staged Event-Driven Architecture
[ https://issues.apache.org/jira/browse/HBASE-16583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475486#comment-15475486 ] Dave Latham commented on HBASE-16583: - >From the last comment on CASSANDRA-8520, it looks like it was resolved simply >due to being superseded by CASSANDRA-10989 as the effort to move away from >SEDA. > Staged Event-Driven Architecture > > > Key: HBASE-16583 > URL: https://issues.apache.org/jira/browse/HBASE-16583 > Project: HBase > Issue Type: Umbrella >Reporter: Phil Yang > > Staged Event-Driven Architecture (SEDA) splits request-handling logic into > several stages, each stage is executed in a thread pool and they are > connected by queues. > Currently, in region server we use a thread pool to handle requests from > client. The number of handlers is configurable, reading and writing use > different pools. The current architecture has two limitations: > Performance: > Different part of the handling path has different bottleneck. For example, > accessing MemStore and cache mainly consumes CPU but accessing HDFS mainly > consumes network/disk IO. If we use SEDA and split them into two different > stages, we can use different numbers for two pools according to the > CPU/disk/network performance case by case. > Availability: > HBASE-16388 described a scene that if the client use a thread pool and use > blocking methods to access region servers, only one slow server may exhaust > most of threads of the client. For HBase, we are the client and HDFS > datanodes are the servers. A slow datanode may exhaust most of handlers. The > best way to resolve this issue is make HDFS requests non-blocking, which is > exactly what SEDA does. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-3489) .oldlogs not being cleaned out
[ https://issues.apache.org/jira/browse/HBASE-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham resolved HBASE-3489. Resolution: Fixed > .oldlogs not being cleaned out > -- > > Key: HBASE-3489 > URL: https://issues.apache.org/jira/browse/HBASE-3489 > Project: HBase > Issue Type: Bug >Affects Versions: 0.90.0 > Environment: 10 Nodes Write Heavy Cluster >Reporter: Wayne > Attachments: oldlog.txt > > > The .oldlogs folder is never being cleaned up. The > hbase.master.logcleaner.ttl has been set to clean up the old logs but the > clean up is never kicking in. The limit of 10 files is not the problem. After > running for 5 days not a single log file has ever been deleted and the > logcleaner is set to 2 days (from the default of 7 days). It is assumed that > the replication changes that want to be sure to keep these logs around if > needed have caused the cleanup to be blocked. There is no replication defined > (knowingly). > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15950) Fix memstore size estimates to be more tighter
[ https://issues.apache.org/jira/browse/HBASE-15950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15333893#comment-15333893 ] Dave Latham commented on HBASE-15950: - I share the concerns with Mikhail - I don't think we should risk breaking clusters that have been tuned on a minor version upgrade, whether it's 1.3 or 1.4. I think having "hbase.memorylayout.use.unsafe" false by default in the minor release would be safer and turn it on in a major release. > Fix memstore size estimates to be more tighter > -- > > Key: HBASE-15950 > URL: https://issues.apache.org/jira/browse/HBASE-15950 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.4.0 > > Attachments: Screen Shot 2016-06-02 at 8.48.27 PM.png, > hbase-15950-v0.patch, hbase-15950-v1.patch, hbase-15950-v2.branch-1.patch, > hbase-15950-v2.branch-1.patch, hbase-15950-v2.patch > > > While testing something else, I was loading a region with a lot of data. > Writing 30M cells in 1M rows, with 1 byte values. > The memstore size turned out to be estimated as 4.5GB, while with the JFR > profiling I can see that we are using 2.8GB for all the objects in the > memstore (KV + KV byte[] + CSLM.Node + CSLM.Index). > This obviously means that there is room in the write cache that we are not > effectively using. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15950) Fix memstore size estimates to be more tighter
[ https://issues.apache.org/jira/browse/HBASE-15950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15325136#comment-15325136 ] Dave Latham commented on HBASE-15950: - Release notes look good. Do we have upgrade notes that we can put a warning in? > Fix memstore size estimates to be more tighter > -- > > Key: HBASE-15950 > URL: https://issues.apache.org/jira/browse/HBASE-15950 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-06-02 at 8.48.27 PM.png, > hbase-15950-v0.patch, hbase-15950-v1.patch > > > While testing something else, I was loading a region with a lot of data. > Writing 30M cells in 1M rows, with 1 byte values. > The memstore size turned out to be estimated as 4.5GB, while with the JFR > profiling I can see that we are using 2.8GB for all the objects in the > memstore (KV + KV byte[] + CSLM.Node + CSLM.Index). > This obviously means that there is room in the write cache that we are not > effectively using. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15950) Fix memstore size estimates to be more tighter
[ https://issues.apache.org/jira/browse/HBASE-15950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15320566#comment-15320566 ] Dave Latham commented on HBASE-15950: - This is good to do, but I think the warning in the release note likely needs to be louder and that it should also go in upgrade notes for 2.0. Something like: The estimates of heap usage by the memstore have been made more accurate, resulting in them dropping by 10-50% in practice. As a result, the actual heap usage of the memstore before being flushed may increase by up to 100%. If configured memory limits for the region server had been tuned based on observed usage, this change could result in worse GC behavior or even OutOfMemory errors. Should we consider pairing this change with a reduction in the default memstore usage percent? > Fix memstore size estimates to be more tighter > -- > > Key: HBASE-15950 > URL: https://issues.apache.org/jira/browse/HBASE-15950 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-06-02 at 8.48.27 PM.png, > hbase-15950-v0.patch > > > While testing something else, I was loading a region with a lot of data. > Writing 30M cells in 1M rows, with 1 byte values. > The memstore size turned out to be estimated as 4.5GB, while with the JFR > profiling I can see that we are using 2.8GB for all the objects in the > memstore (KV + KV byte[] + CSLM.Node + CSLM.Index). > This obviously means that there is room in the write cache that we are not > effectively using. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15847) VerifyReplication prefix filtering
[ https://issues.apache.org/jira/browse/HBASE-15847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15287135#comment-15287135 ] Dave Latham commented on HBASE-15847: - Row or column prefixes or both? Would be better to be able to specify arbitrary Filters somehow? > VerifyReplication prefix filtering > -- > > Key: HBASE-15847 > URL: https://issues.apache.org/jira/browse/HBASE-15847 > Project: HBase > Issue Type: New Feature > Components: Replication >Reporter: Geoffrey Jacoby > > VerifyReplication currently lets a user verify data within a time range has > been replicated to a particular peer. It can be useful to verify only data > that starts with particular prefixes. (An example would be an unsalted > multi-tenant Phoenix table where you wish to only verify data for particular > tenants.) > Add a new option to the VerifyReplication job to allow for a list of prefixes > to be given. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13683) Doc HBase and G1GC
[ https://issues.apache.org/jira/browse/HBASE-13683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280476#comment-15280476 ] Dave Latham commented on HBASE-13683: - Hubspot's post: http://product.hubspot.com/blog/g1gc-tuning-your-hbase-cluster > Doc HBase and G1GC > -- > > Key: HBASE-13683 > URL: https://issues.apache.org/jira/browse/HBASE-13683 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: stack > > Add section to refguide on running G1GC with HBase. There is the intel talk > at hbasecon with nice pictures and healthy recommendations, there is our > [~esteban]'s recent experience running G1GC, and the mighty [~bbeaudreault] > dumped a bunch of helpful advice in the mailing list just now: > http://search-hadoop.com/m/YGbbupEDoKTrDo/%2522How+to+know+the+root+reason+to+cause+RegionServer+OOM%253F%2522=Re+How+to+know+the+root+reason+to+cause+RegionServer+OOM+ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15454) Archive store files older than max age
[
https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280418#comment-15280418
]
Dave Latham commented on HBASE-15454:
-
Sorry for the late responses - a minor update on reviewboard as well.
I haven't changed feelings about the above:
{quote}
I don't have good intuition for how such an archiving mechanism would effect
write amplification in practice, or how it performs under edge cases (e.g. once
in awhile another "old" cell shows up) or if it's likely to output several
small HFiles when it runs for example. Do you have any analysis, simulation, or
arguments about how this will behave and perform? It seems that using this
makes stronger assumptions about the use case and write behavior.
If going in this direction, I wonder if it's better to go all the way, from
having every minor compaction output perfectly partitioned HFiles
{quote}
I'm nervous about the extra complexity here and whether it's going to be used.
I wonder if it is better off being done differently or as an extended policy.
I'm not an HBase committer so am fine going along with the flow. If I were, I
guess I would be -0: makes me nervous but I wouldn't try to stop it going in if
other people think it's a good idea.
> Archive store files older than max age
> --
>
> Key: HBASE-15454
> URL: https://issues.apache.org/jira/browse/HBASE-15454
> Project: HBase
> Issue Type: Sub-task
> Components: Compaction
>Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.20
>
> Attachments: HBASE-15454-v1.patch, HBASE-15454-v2.patch,
> HBASE-15454-v3.patch, HBASE-15454-v4.patch, HBASE-15454-v5.patch,
> HBASE-15454-v6.patch, HBASE-15454-v7.patch, HBASE-15454.patch
>
>
> In date tiered compaction, the store files older than max age are never
> touched by minor compactions. Here we introduce a 'freeze window' operation,
> which does the follow things:
> 1. Find all store files that contains cells whose timestamp are in the give
> window.
> 2. Compaction all these files and output one file for each window that these
> files covered.
> After the compaction, we will have only one in the give window, and all cells
> whose timestamp are in the give window are in the only file. And if you do
> not write new cells with an older timestamp in this window, the file will
> never be changed. This makes it easier to do erasure coding on the freezed
> file to reduce redundence. And also, it makes it possible to check
> consistency between master and peer cluster incrementally.
> And why use the word 'freeze'?
> Because there is already an 'HFileArchiver' class. I want to use a different
> word to prevent confusing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15454) Archive store files older than max age
[ https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15258913#comment-15258913 ] Dave Latham commented on HBASE-15454: - Hi Duo, I posted a review up on reviewboard. I'm still a bit skeptical of this extension of DTCP, but I can see value for some cases. I'm worried about the level of complexity and wonder if there is a simpler way to get the desired outcome. I'm unsure about all the edge cases. > Archive store files older than max age > -- > > Key: HBASE-15454 > URL: https://issues.apache.org/jira/browse/HBASE-15454 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.20 > > Attachments: HBASE-15454-v1.patch, HBASE-15454-v2.patch, > HBASE-15454-v3.patch, HBASE-15454-v4.patch, HBASE-15454-v5.patch, > HBASE-15454-v6.patch, HBASE-15454.patch > > > In date tiered compaction, the store files older than max age are never > touched by minor compactions. Here we introduce a 'freeze window' operation, > which does the follow things: > 1. Find all store files that contains cells whose timestamp are in the give > window. > 2. Compaction all these files and output one file for each window that these > files covered. > After the compaction, we will have only one in the give window, and all cells > whose timestamp are in the give window are in the only file. And if you do > not write new cells with an older timestamp in this window, the file will > never be changed. This makes it easier to do erasure coding on the freezed > file to reduce redundence. And also, it makes it possible to check > consistency between master and peer cluster incrementally. > And why use the word 'freeze'? > Because there is already an 'HFileArchiver' class. I want to use a different > word to prevent confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15368) Add pluggable window support
[
https://issues.apache.org/jira/browse/HBASE-15368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15251178#comment-15251178
]
Dave Latham commented on HBASE-15368:
-
Looks good to me
> Add pluggable window support
>
>
> Key: HBASE-15368
> URL: https://issues.apache.org/jira/browse/HBASE-15368
> Project: HBase
> Issue Type: Sub-task
> Components: Compaction
>Affects Versions: 2.0.0, 1.3.0, 0.98.19, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.3.0, 0.98.19, 1.4.0
>
> Attachments: HBASE-15368-0.98.patch, HBASE-15368-branch-1.patch,
> HBASE-15368-v1.patch, HBASE-15368-v2.patch, HBASE-15368-v3.patch,
> HBASE-15368-v4.patch, HBASE-15368-v5.patch, HBASE-15368-v6.patch,
> HBASE-15368-v7.patch, HBASE-15368.patch
>
>
> Abstract a {{CompactionWindow}} and a {{CompactionWindowFactory}}. Both are
> orthogonal to the implementation of DateTieredCompactionPolicy. Users can
> implement their own {{CompactionWindow}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15368) Add pluggable window support
[
https://issues.apache.org/jira/browse/HBASE-15368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15250015#comment-15250015
]
Dave Latham commented on HBASE-15368:
-
What's the criteria for which configs should be in hbase-default.xml? This one
would be obscure for many people so I'd tend to think it shouldn't be there.
> Add pluggable window support
>
>
> Key: HBASE-15368
> URL: https://issues.apache.org/jira/browse/HBASE-15368
> Project: HBase
> Issue Type: Sub-task
> Components: Compaction
>Affects Versions: 2.0.0, 1.3.0, 0.98.19, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.3.0, 0.98.19, 1.4.0
>
> Attachments: HBASE-15368-0.98.patch, HBASE-15368-branch-1.patch,
> HBASE-15368-v1.patch, HBASE-15368-v2.patch, HBASE-15368-v3.patch,
> HBASE-15368-v4.patch, HBASE-15368-v5.patch, HBASE-15368-v6.patch,
> HBASE-15368-v7.patch, HBASE-15368.patch
>
>
> Abstract a {{CompactionWindow}} and a {{CompactionWindowFactory}}. Both are
> orthogonal to the implementation of DateTieredCompactionPolicy. Users can
> implement their own {{CompactionWindow}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15368) Add pluggable window support
[ https://issues.apache.org/jira/browse/HBASE-15368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15248108#comment-15248108 ] Dave Latham commented on HBASE-15368: - Looks good - just a couple mainly cosmetic things left. > Add pluggable window support > > > Key: HBASE-15368 > URL: https://issues.apache.org/jira/browse/HBASE-15368 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-15368-v1.patch, HBASE-15368-v2.patch, > HBASE-15368-v3.patch, HBASE-15368-v4.patch, HBASE-15368.patch > > > To better determine 'hot' data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15665) Support using different StoreFileComparators for different CompactionPolicies
[ https://issues.apache.org/jira/browse/HBASE-15665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246261#comment-15246261 ] Dave Latham commented on HBASE-15665: - Looks good to me. > Support using different StoreFileComparators for different CompactionPolicies > - > > Key: HBASE-15665 > URL: https://issues.apache.org/jira/browse/HBASE-15665 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-15665.patch > > > Now for DateTieredCompactionPolicy, if we output multiple files when > compaction, we will use the same max sequence id for all the output files(see > HBASE-15389 for more details). So we need to sort the store files by > timestamp if they have the same max sequence id which is different from the > original store file comparator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15368) Add pluggable window support
[ https://issues.apache.org/jira/browse/HBASE-15368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246236#comment-15246236 ] Dave Latham commented on HBASE-15368: - Thanks, [~Apache9]. I left some review comments - it's looking good. > Add pluggable window support > > > Key: HBASE-15368 > URL: https://issues.apache.org/jira/browse/HBASE-15368 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-15368-v1.patch, HBASE-15368-v2.patch, > HBASE-15368-v3.patch, HBASE-15368.patch > > > To better determine 'hot' data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15454) Archive store files older than max age
[ https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15243854#comment-15243854 ] Dave Latham commented on HBASE-15454: - Thanks, Duo, I think I finally understand the intent here: For old enough windows you want to compact whatever is necessary to produce exactly one file for that window containing exactly the cells timestamped in that window. This sounds reasonable if you can guarantee that zero new cells are being added to those windows. Now that I understand, a few thoughts: * Can we separate the JIRA issues and patches for pluggable window schedules vs "archival" compaction? * I think the archival time boundary should be a separate configuration from the exponential window schedule's max tier age. * I don't have good intuition for how such an archiving mechanism would effect write amplification in practice, or how it performs under edge cases (e.g. once in awhile another "old" cell shows up) or if it's likely to output several small HFiles when it runs for example. Do you have any analysis, simulation, or arguments about how this will behave and perform? It seems that using this makes stronger assumptions about the use case and write behavior. * If going in this direction, I wonder if it's better to go all the way, from having every minor compaction output perfectly partitioned HFiles to even doing so at flush time as well. Could certainly be done later. Thanks for your patience, Duo. > Archive store files older than max age > -- > > Key: HBASE-15454 > URL: https://issues.apache.org/jira/browse/HBASE-15454 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.3.0, 0.98.19, 1.4.0 > > Attachments: HBASE-15454-v1.patch, HBASE-15454-v2.patch, > HBASE-15454-v3.patch, HBASE-15454-v4.patch, HBASE-15454.patch > > > Sometimes the old data is rarely touched but we can not remove it. So archive > it to several big files(by year or something) and use EC to reduce the > redundancy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15454) Archive store files older than max age
[
https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239522#comment-15239522
]
Dave Latham commented on HBASE-15454:
-
Please forgive me - I still don't understand, and I want to. It would be
really helpful for me if you can try to answer these questions:
{quote}
* What does it actually mean to "archive" a store file? Is there a definition,
or set of properties or guarantees?
** Are archived files excluded from major compaction? Or minor compactions? Or
from region split size calculation?
** Are archived files guaranteed to have no timestamp overlap with other
HFiles? Or just other archived HFiles?
** Or does it just refer to any files with max timestamp older than maxAge?
{quote}
Without understanding how archived files are different from other HFiles I
don't see why it needs separate logic beyond purely having a pluggable window
factory (which is nice to see in the v2 patch).
{quote}
Currently we do have a config for store files that is no longer eligible for
minor compaction, which is max age
{quote}
Yikes. I thought max age was purely part of the exponential tiered windowing
schedule, which stopped the growth of tiers past a certain point. Under common
write patterns those files would then never need minor compactions again, but
if there were actually several files in such a window I wouldn't want to
explicitly prevent compaction of them.
> Archive store files older than max age
> --
>
> Key: HBASE-15454
> URL: https://issues.apache.org/jira/browse/HBASE-15454
> Project: HBase
> Issue Type: Sub-task
> Components: Compaction
>Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.3.0, 0.98.19, 1.4.0
>
> Attachments: HBASE-15454-v1.patch, HBASE-15454-v2.patch,
> HBASE-15454.patch
>
>
> Sometimes the old data is rarely touched but we can not remove it. So archive
> it to several big files(by year or something) and use EC to reduce the
> redundancy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15454) Archive store files older than max age
[
https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237401#comment-15237401
]
Dave Latham commented on HBASE-15454:
-
Sorry, I think I'm a bit behind Duo and Clara, but I'm still trying to get the
picture of this right in my head.
So it sounds like EC is independent of this work and can be noted purely as
motivation to have large, infrequently accessed files.
* What does it actually mean to "archive" a store file? Is there a definition,
or set of properties or guarantees?
** Are archived files excluded from major compaction? Or minor compactions?
Or from region split size calculation?
** Are archived files guaranteed to have no timestamp overlap with other
HFiles? Or just other archived HFiles?
** Or does it just refer to any files with max timestamp older than maxAge?
* Should archiving be a separate modality with a separate method or just happen
as part of compaction with the given window schedule?
{quote}I find the first and last files that overlapping with current archive
window, and then compact all files between them. These makes sure that all data
belongs to this window are contained in the output file.{quote}
Is that first and last file ordered by sequence id? With max timestamp in
current archive window? What if the seq id ordering and timestamp overlapping
don't match up?
I do suspect that it's most efficient to have all windows and tiers in
alignment - that if one desires calendar based files for the archive, that one
would be better off using calendar derived windows for all the data. For
example, if you want the highest tier to be calendar years, then lower tiers
could be 3-month quarters, months, weekOfMonth (some week windows would not be
full 7 days but that should be ok), days, 6-hour blocks.
Otherwise, the transition of files from one scheme to another seems likely to
require splitting existing data from a file into multiple windows. Maybe
that's OK.
Taking a quick look over Duo's github link there: I like how there is a
pluggable window factory. I think if we have that we should try to move the
window specific configuration out of the generic CompactionConfiguration into
the specific window factory. Also, I'm not sure if the intent is for
ExponentialThenCalendricalCompactionWindowFactory to be in the hbase code or
it's just there as an illustration of an alternate plugin - I tend to think it
should not be included by default.
As a side note, it seem unfortunate to add joda time as a full dependency when
most people probably won't use tiered compaction, let alone calendar based
windows / archives. Perhaps using JDK classes would suffice or even direct
basic logic in the code? Or if it's just included with a window factory plugin
then only people using that would need it.
> Archive store files older than max age
> --
>
> Key: HBASE-15454
> URL: https://issues.apache.org/jira/browse/HBASE-15454
> Project: HBase
> Issue Type: Sub-task
> Components: Compaction
>Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.3.0, 0.98.19, 1.4.0
>
> Attachments: HBASE-15454-v1.patch, HBASE-15454.patch
>
>
> Sometimes the old data is rarely touched but we can not remove it. So archive
> it to several big files(by year or something) and use EC to reduce the
> redundancy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15454) Archive store files older than max age
[ https://issues.apache.org/jira/browse/HBASE-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235958#comment-15235958 ] Dave Latham commented on HBASE-15454: - Clara's out for a few days. I read over the design doc and the patch and am still trying to understand how this all fits together, and if this is the best way to add a new set of logic. The design doc mentions 3 goals: 1. Use EC (to reduce the redundancy of old data) 2. No overlapping store files (to facilitate easier comparisons of data) 3. Calendar boundaries between windows (presumably for analysis, comparison, or operations on files to match expectations of people or other systems) Some questions and thoughts: * Does EC mean erasure coding? I don't see anything related in the patch, and am not familiar with any existing support within HBase to take advantage of it with HDFS. Does it actually relate to this work or are you just mentioning your intention to use this feature and EC at the same time. I'd love to hear your thoughts on how you'd do it if so. I also wonder if it's orthogonal and should be mostly independent of compaction policies. * I don’t see how this achieves no overlapping store files. Can you explain that part? * Treating the archive windows as separate concept feels unnecessary to me. Can we instead allow the windowing algorithm to be pluggable? The current implementation is exponential growing windows across tiers to some limit, but others could be entirely calendar based or fixed size windows. Then to achieve what’s here you could implement a custom one window schedule that starts with exponential and then transitions to calendar based. > Archive store files older than max age > -- > > Key: HBASE-15454 > URL: https://issues.apache.org/jira/browse/HBASE-15454 > Project: HBase > Issue Type: Sub-task > Components: Compaction >Affects Versions: 2.0.0, 1.3.0, 0.98.18, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.3.0, 0.98.19, 1.4.0 > > Attachments: HBASE-15454-v1.patch, HBASE-15454.patch > > > Sometimes the old data is rarely touched but we can not remove it. So archive > it to several big files(by year or something) and use EC to reduce the > redundancy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222658#comment-15222658 ] Dave Latham commented on HBASE-15585: - Andrew, I apologize for the poor attempt at humor. I've always given an incredulous laugh at the criticism of HBase coprocessors by some folks. For the record I think the way they are built makes a lot of sense and greatly appreciate all you've done for HBase. Poe's law strikes again. > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222542#comment-15222542 ] Dave Latham commented on HBASE-15585: - Coprocessors should never have run inside the same JVM. What happens if an untrusted version of this coprocessor should run? Please reimplement as a new framework in a separate process with a harness to communicate to the RS securely. > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15564) HashTable job supposedly succeeded but manifest.tmp remain
[ https://issues.apache.org/jira/browse/HBASE-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1500#comment-1500 ] Dave Latham commented on HBASE-15564: - Sure thing, [~mydiemho]. I was referring to the User List (u...@hbase.apache.org) at https://hbase.apache.org/mail-lists.html > HashTable job supposedly succeeded but manifest.tmp remain > -- > > Key: HBASE-15564 > URL: https://issues.apache.org/jira/browse/HBASE-15564 > Project: HBase > Issue Type: Bug > Components: mapreduce, Replication >Affects Versions: 1.2.0 > Environment: Ubuntu 12.04 >Reporter: My Ho > > I'm using org.apache.hadoop.hbase.mapreduce.HashTable to create hashes for > use in SyncTable. Occasionally, the job page in jobhistory will say the job > succeeded, but in my filesystem, I see "manifest.tmp" instead of the expected > "manifest". According to the code[1], the job must have failed, but I don't > see failure anywhere. > [1]https://github.com/apache/hbase/blob/ad3feaa44800f10d102255a240c38ccf23a82d49/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/HashTable.java#L739-L741 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13639) SyncTable - rsync for HBase tables
[ https://issues.apache.org/jira/browse/HBASE-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220812#comment-15220812 ] Dave Latham commented on HBASE-13639: - If you run SyncTable on the a cluster that is not local to the target table, it should work but the tasks will be scanning all the data remotely which defeats the intent of avoiding transferring all the data across clusters. In that case you may be better off simply exporting the source table and replacing the target table with it. If you want to discuss further, please email the mailing list and let's continue there. > SyncTable - rsync for HBase tables > -- > > Key: HBASE-13639 > URL: https://issues.apache.org/jira/browse/HBASE-13639 > Project: HBase > Issue Type: New Feature > Components: mapreduce, Operability, tooling >Reporter: Dave Latham >Assignee: Dave Latham > Labels: tooling > Fix For: 2.0.0, 0.98.14, 1.2.0 > > Attachments: HBASE-13639-0.98-addendum-hadoop-1.patch, > HBASE-13639-0.98.patch, HBASE-13639-v1.patch, HBASE-13639-v2.patch, > HBASE-13639-v3-0.98.patch, HBASE-13639-v3.patch, HBASE-13639.patch > > > Given HBase tables in remote clusters with similar but not identical data, > efficiently update a target table such that the data in question is identical > to a source table. Efficiency in this context means using far less network > traffic than would be required to ship all the data from one cluster to the > other. Takes inspiration from rsync. > Design doc: > https://docs.google.com/document/d/1-2c9kJEWNrXf5V4q_wBcoIXfdchN7Pxvxv1IO6PW0-U/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
