Hbase compact入门

模糊概念区分
StoreFile是HFile的外观。在压缩方面，StoreFile的使用似乎在过去很盛行。

Store与ColumnFamily是同一件事。 StoreFiles与Store或ColumnFamily相关。

当MemStore达到给定大小（hbase.hregion.memstore.flush.size）时，它将其内容刷新到StoreFile。存储中的StoreFiles数量随时间增加。压缩是一种通过合并存储来减少存储中StoreFile数量的操作，以提高读取操作的性能。压缩可能会占用大量资源，并且取决于许多因素，压缩可能会助长或阻碍性能。

Compact分为两类：次要和主要。次要和主要压实在以下方面有所不同。

minor compact通常会选择少量的较小的相邻StoreFile，然后将它们重写为单个StoreFile。由于潜在的副作用，较小的压缩不会丢弃（过滤掉）删除或过期的版本。有关如何处理与压缩有关的删除和版本的信息，请参见压缩和删除以及压缩和版本。较小压缩的最终结果是给定Store的StoreFiles更少，更大。

Major Compact的最终结果是每个商店只有一个StoreFile。Major Compact还处理删除标记和最大版本。有关如何处理与压缩有关的删除和版本的信息，请参见压缩和删除以及压缩和版本。

Compaction and Deletions
在HBase中发生显式删除时，实际上不会删除数据。而是写一个墓碑标记。逻辑删除标记可防止查询返回数据。在大型压缩期间，实际上会删除数据，并从StoreFile中删除逻辑删除标记。如果由于TTL过期而导致删除，则不会创建逻辑删除。相反，过期的数据将被过滤掉，并且不会写回到压缩的StoreFile中。

压缩和版本
创建Column Family时，可以通过指定ColumnFamilyDescriptorBuilder.setMaxVersions（int版本）来指定要保留的最大版本数。缺省值为1。如果存在的版本数量超过指定的最大值，则多余的版本将被滤除，并且不会写回到压缩的StoreFile中。

Major Compact可能会影响查询结果
在某些情况下，如果明确删除较新的版本，则可能会无意中恢复较旧的版本。有关更深入的说明，请参阅主要压缩更改查询结果。这种情况只有在压实完成之前才有可能。

从理论上讲，Major Compact可以提高性能。但是，在高负载的系统上，Major Compact可能需要不适当数量的资源，并对性能产生不利影响。在默认配置中，Major Compact将自动计划为每7天运行一次。有时这不适用于生产中的系统。您可以手动管理主要压缩。请参阅托管压缩。

压缩不执行区域合并。有关区域合并的更多信息，请参见合并。

Compact开关
我们可以在区域服务器上打开和关闭compactions。关闭compactions还会中断任何当前正在进行的压缩。可以使用hbase shell中的“ compaction_switch”命令动态地完成此操作。如果从命令行完成，则此设置将在服务器重新启动时丢失。要持久保存跨区域服务器的更改，请修改hbase-site.xml中的配置hbase.regionserver .compaction.enabled并重新启动HBase。

Cimpaction policy-HBase 0.96.x和更高版本
compact大型StoreFiles或一次压缩太多StoreFiles可能导致群集无法处理的IO负载，而不会引起性能问题。 HBase选择要包含在压缩中的StoreFiles（以及压缩是次要压缩还是次要压缩）的方法称为压缩策略。

在HBase 0.96.x之前，只有一种压缩策略。该原始压缩策略仍然可以作为RatioBasedCompactionPolicy使用。新的压缩默认策略ExploringCompactionPolicy随后又移植到HBase 0.94和HBase 0.95，并且是HBase 0.96和更高版本中的默认策略。它在HBASE-7842中实现。简而言之，ExploringCompactionPolicy尝试选择最佳的StoreFiles集以最少的工作量进行压缩，而RatioBasedCompactionPolicy选择符合条件的第一组。

无论使用哪种压缩策略，文件选择都由几个可配置的参数控制，并且以多步方式进行。这些参数将在上下文中进行解释，然后在一个表中给出，该表显示了它们的描述，默认值以及更改它们的含义。

Stuck
当MemStore太大时，它需要将其内容刷新到StoreFile。但是，存储库配置有数量限制，即StoreFiles，hbase.hstore.blockingStoreFiles的数量，并且如果数量过多，则MemStore刷新必须等待，直到StoreFile计数减少一次或多次压缩。如果MemStore太大而StoreFiles的数量也太多，则该算法被称为“卡住”。默认情况下，我们将等待压缩到hbase.hstore.blockingWaitTime毫秒。如果这段时间到期，即使我们超出了hbase.hstore.blockingStoreFiles计数，我们仍然会进行刷新。

增大hbase.hstore.blockingStoreFiles计数将允许刷新发生，但是包含许多StoreFiles的商店可能具有更高的读取延迟。尝试弄清楚为什么紧缩没有跟上。是导致这种情况的写入突增，还是定期发生，并且群集的写入量配置不足？

ExploringCompactionPolicy算法在选择压缩最有利的位置之前，先考虑每个可能的相邻StoreFile组。

ExploringCompactionPolicy效果特别好的一种情况是，当您批量加载数据并且批量加载创建的StoreFiles比StoreFiles更大时，StoreFiles保存的数据早于批量加载的数据。每次需要压缩时，这都会“欺骗” HBase选择执行大型压缩，并导致大量额外开销。借助ExploringCompactionPolicy，大型压缩的发生频率要低得多，因为小型压缩更为有效。

通常，ExploringCompactionPolicy是大多数情况的正确选择，因此是默认的压缩策略。您还可以将ExploringCompactionPolicy与实验：条带压缩一起使用。

可以在hbase-server / src / main / java / org / apache / hadoop / hbase / regionserver / compactions / ExploringCompactionPolicy.java中检查此策略的逻辑。以下是ExploringCompactionPolicy的逻辑的逐步介绍。

列出商店中所有现有的StoreFiles。该算法的其余部分将过滤该列表，以提供将被选择进行压缩的HFiles子集。

如果这是用户请求的压缩，请尝试执行请求的压缩类型，而不管通常选择哪种压缩类型。注意，即使用户请求进行大压缩，也可能无法进行大压缩。这可能是因为并非列族中的所有StoreFile都可以压缩，或者是因为列族中的存储太多。

一些StoreFiles会自动排除在考虑范围之外。这些包括：

大于hbase.hstore.compaction.max.size的StoreFiles

由批量加载操作（明确排除压缩）创建的StoreFiles。您可以决定从压缩中排除由批量加载产生的StoreFiles。为此，请在批量加载操作期间指定hbase.mapreduce.hfileoutputformat.compaction.exclude参数。

遍历第1步中的列表，并列出所有可能的StoreFiles集以压缩在一起。可能的集合是列表中hbase.hstore.compaction.min连续StoreFiles的分组。对于每个集合，执行一些健全性检查，并确定这是否是可以完成的最佳压缩：

如果此集合中的StoreFiles数量（不是StoreFiles的大小）小于hbase.hstore.compaction.min或大于hbase.hstore.compaction.max，请不要考虑它。

将这组StoreFiles的大小与到目前为止在列表中找到的最小压缩的大小进行比较。如果这组StoreFiles的大小表示可以完成的最小压缩，则在算法“卡住”的情况下存储它以用作备用，否则将不选择任何StoreFiles。见被卡住。

对这组StoreFiles中的每个StoreFile进行基于大小的完整性检查。

如果此StoreFile的大小大于hbase.hstore.compaction.max.size，请不要考虑它。

如果大小大于或等于hbase.hstore.compaction.min.size，请根据基于文件的比率对其进行完整性检查，以查看它是否太大而无法考虑。

在以下情况下，完整性检查成功：

此集合中只有一个StoreFile，或者

对于每个StoreFile，其大小乘以hbase.hstore.compaction.ratio（或hbase.hstore.compaction.ratio.offpeak（如果已配置非高峰时间且处于非高峰时间），则乘以小于该大小的总和集合中其他HFile的集合。

如果仍在考虑这组StoreFiles，请将其与先前选择的最佳压缩方式进行比较。如果更好，请用此替代以前选择的最佳压实。

处理完所有可能的压实列表后，执行发现的最佳压实。如果没有选择要压缩的StoreFiles，但是有多个StoreFiles，则假定算法被卡住（请参阅被卡住），如果是，则执行在步骤3中找到的最小压缩。

几个参数

hbase.hregion.memstore.flush.size

描述
如果内存区的大小超过此字节数，则内存区将刷新到磁盘。 值由运行每个hbase.server.thread.wakefrequency的线程检查。

默认
134217728 就是大概128M

hbase.hregion.majorcompaction
描述
两次major compact之间的时间，以毫秒为单位。 设置为0以禁用基于时间的自动major compaction。 用户请求的基于大小的major compact仍将运行。 将该值乘以hbase.hregion.majorcompaction.jitter会导致压缩在给定的时间范围内在某个随机时间开始。 默认值为7天，以毫秒为单位。 如果major compact在您的环境中造成破坏，则可以将其配置为在部署的非高峰时间运行，或者通过将此参数设置为0来禁用基于时间的大型压缩，并在cron作业或其他作业中运行major compact外部机制。

默认
604800000 就是7天

hbase.hstore.compactionThreshold

就是每当有3个storeFile就会进行一次压缩.

描述
如果在任何一个Store中都存在超过此数目的StoreFile（每次刷新MemStore都会写入一个StoreFile），则会运行压缩以将所有StoreFile重写为一个StoreFile。 较大的值会延迟压缩，但是当确实发生压缩时，则需要更长的时间才能完成。

默认
3

hbase.regionserver.compaction.enabled

描述
通过设置true / false启用/禁用压缩。 我们可以使用compaction_switch shell命令进一步动态地切换压缩。

默认
true

hbase.hstore.flusher.count

描述
刷新线程数。 如果线程较少，则将对MemStore刷新进行排队。 如果线程更多，则刷新将并行执行，从而增加了HDFS的负载，并可能导致更多的压缩。

默认
2

hbase.hstore.blockingStoreFiles

就是说StoreFile超过这个数字,16时,这个region就用不了啦,就是不能对外提供服务.
描述
如果在任何一个Store中都存在超过此数目的StoreFile（每次刷新MemStore都写入一个StoreFile），则将阻止对此region进行更新，直到压缩完成或超过hbase.hstore.blockingWaitTime。

默认
16

hbase.hstore.blockingWaitTime

描述
达到hbase.hstore.blockingStoreFiles定义的StoreFile限制后，区域将阻止更新的时间。 经过这段时间后，即使压缩尚未完成，该区域也将停止阻止更新。

默认
90000

hbase.hstore.compaction.min

描述
运行压缩之前必须符合压缩条件的最小StoreFiles数。 调整hbase.hstore.compaction.min的目标是避免最终产生太多无法压缩的微小StoreFiles。 每次在存储中有两个StoreFiles时，将此值设置为2都会导致较小的压缩，这可能不合适。 如果将此值设置得太高，则所有其他值都需要相应地进行调整。 对于大多数情况，默认值是适当的（此处为空值，根据代码逻辑，结果为3）。 在以前的HBase版本中，参数hbase.hstore.compaction.min被命名为hbase.hstore.compactionThreshold。

默认
没有

hbase.hstore.compaction.max

描述
无论合格的StoreFiles数量如何，一次较小的压缩将选择的StoreFiles的最大数量。 实际上，hbase.hstore.compaction.max的值控制完成一次压缩的时间长度。 将其设置为更大意味着压缩中将包含更多StoreFiles。 在大多数情况下，默认值为适当。

默认
10