HBase使用HashTable/SyncTable工具同步集群数据-低调大师

HBase使用HashTable/SyncTable工具同步集群数据

2020-10-30 599

复制（在上一篇博客文章中介绍）已经发布了一段时间，并且是Apache HBase最常用的功能之一。使集群与不同的对等方复制数据是非常常见的部署，无论是作为DR策略还是简单地作为在生产/临时/开发环境之间复制数据的无缝方式。尽管这是使不同的HBase数据库在亚秒级延迟内保持同步的有效方法，但是复制仅对启用该功能后所摄取的数据进行操作。这意味着复制部署中涉及的所有集群上的所有现有数据仍将需要以其他某种方式在同级之间进行复制。有很多工具可用于同步不同对等集群上的现有数据。Snapshots、BulkLoad、CopyTable是此类工具的知名示例，以前的Cloudera博客文章中都提到了这些示例。HashTable/SyncTable，详细介绍了它的一些内部实现逻辑，使用它的利弊以及如何与上述其他数据复制技术进行比较。

HashTable/SyncTable简介

HashTable/SyncTable是一种工具，实现为两个作为单独步骤执行的map-reduce作业。它看起来类似于CopyTable工具，该工具可以执行部分或全部表数据复制。与CopyTable不同，它仅在目标集群之间复制分散的数据，从而在复制过程中节省了网络和计算资源。

该过程中要执行的第一步是HashTable Map-Reduce作业。这应在其数据应复制到远程对等方（通常是源集群）的集群上运行。下面显示了如何运行它的快速示例，本文稍后将给出每个必需参数的详细说明：

hbase org.apache.hadoop.hbase.mapreduce.HashTable --families=cf my-table /hashes/test-tbl…20/04/28 05:05:48 INFO mapreduce.Job:  map 100% reduce 100%20/04/28 05:05:49 INFO mapreduce.Job: Job job_1587986840019_0001 completed successfully20/04/28 05:05:49 INFO mapreduce.Job: Counters: 68…File Input Format CountersBytes Read=0File Output Format CountersBytes Written=6811788

一旦HashTable的上述命令作业执行完成，已经在源HDFS已经产生了一些输出hdfs 的/hashes/my-table 的表目录：

hdfs dfs -ls -R /hashes/test-tbldrwxr-xr-x   - root supergroup          0 2020-04-28 05:05 /hashes/test-tbl/hashes-rw-r--r--   2 root supergroup          0 2020-04-28 05:05 /hashes/test-tbl/hashes/_SUCCESSdrwxr-xr-x   - root supergroup          0 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000-rw-r--r--   2 root supergroup    6790909 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/data-rw-r--r--   2 root supergroup      20879 2020-04-28 05:05 /hashes/test-tbl/hashes/part-r-00000/index-rw-r--r--   2 root supergroup         99 2020-04-28 05:04 /hashes/test-tbl/manifest-rw-r--r--   2 root supergroup        153 2020-04-28 05:04 /hashes/test-tbl/partitions

需要这些作为SyncTable运行的输入。SyncTable必须在目标对等方启动。下面的命令为上一个示例中的HashTable的输出运行SyncTable 。它使用本文稍后说明的dryrun选项：

hbase org.apache.hadoop.hbase.mapreduce.SyncTable --dryrun --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://source-cluster-active-nn/hashes/test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97146HASHES_NOT_MATCHED=2MATCHINGCELLS=17MATCHINGROWS=2RANGESNOTMATCHED=2ROWSWITHDIFFS=2SOURCEMISSINGCELLS=1TARGETMISSINGCELLS=1

作为快速参考，您可以仅将两个示例中的给定参数替换为实际环境值。本文的其余部分将更深入地介绍实现细节。

为什么要两个不同的步骤？

该工具的主要目标是仅识别和复制两个集群之间丢失的数据。HashTable充当分片/索引工作，分析表数据的批处理，并为每个批处理生成哈希索引。这些是作为作业参数之一传递的hdfs 的/hashes/my-table目录下文件中写入的输出。如前所述，SyncTable作业需要此输出。SyncTable以与HashTable使用的批处理大小相同的本地大小在本地扫描目标表，并使用HashTable使用的相同函数为这些批处理计算哈希值。然后比较本地批处理哈希HashTable输出中的值之一。如果哈希值相等，则意味着在两个集群中整个批次是相同的，并且不需要在该段上复制任何内容。否则，它将对源集群中的批次打开扫描，检查目标集群中是否已存在每个单元，仅复制那些有差异的单元。在稀疏，略有不同的数据集上，这将导致在两个集群之间复制的数据少得多。它还将仅需要在源中扫描少量的单元以检查不匹配。

必要参数

HashTable仅需要两个参数：表名称和将在其中写入相关哈希和其他元信息文件的输出路径。SyncTable使用HashTable输出目录作为输入，并分别使用源集群和目标集群中的表名称。由于我们使用HashTable/SyncTable在远程集群之间移动数据，因此必须为SyncTable定义sourcezkcluster选项。这应该是源集群的Zookeeper仲裁地址。在本文的示例中，我们还直接引用了源集群活动namenode地址，以便SyncTable将直接从源集群读取哈希输出文件。或者，可以将HashTable输出手动从源集群复制到远程集群（例如，使用distcp）。

注意：仅从CDH 6.2.1起才支持在不同kerberos领域下使用远程集群。

高级选项

这两个哈希表和SyncTable提供可调节以获得最佳效果额外的可选选项。

HashTable允许分别通过行键和修改时间（分别具有startrow/starttime，stoprow/stoptime属性）来过滤数据。数据集范围也可以受版本和列簇属性限制。所述BATCHSIZE属性定义了将被散列各部分的尺寸。这直接影响同步性能。在不匹配的情况很少的情况下，将较大的批处理值设置为更高的性能可能会导致数据集的较大部分被忽略，而无需通过SyncTable进行扫描。

SyncTable提供了dryrun选项，该选项允许预览要在目标中应用的更改。

SyncTable的默认行为是在目标端镜像源数据，因此目标中存在但源中不存在的任何其他单元最终都会在目标端被删除。在Active-Active复制设置下同步集群时，这可能是不希望的，在这种情况下，可以将doDeletes选项设置为false，从而跳过目标上删除的复制。对于不应将其他单元插入目标集群的情况，也有一个类似的doPuts标志。

输出分析

HashTable输出一些带有SyncTable的元信息的文件，但是这些文件不可读。它不会对现有数据执行任何更改，因此相关信息对于用户上下文几乎没有兴趣。

SyncTable是真正将修改应用到目标上的步骤，在实际更改目标集群数据之前，请先查看其摘要，这一点很重要（请参见上述dryrun选项）。它在映射的末尾发布一些相关的计数器以Reduce执行。查看上例中的值，我们可以看到有哈希的97148个分区（由BATCHES计数器报告），SyncTable仅检测到其中两个分区的差异（根据HASHES_MATCHED和HASHES_NOT_MACTHED计数器）。另外，内两个分区具有不同的散列， 17个单元在2行中是匹配的（分别由MATCHING_CELLS和MATCHING_ROWS报告），但是在这两个分区上也有2行是分歧的（根据RANGESNOTMATCHED和ROWSWITHDIFFS）。最后，SOURCEMISSINGCELLS和TARGETMISSINGCELLS会详细告诉我们单元仅存在于源集群还是目标集群上。在此示例中，源集群具有不在目标上的一个单元，但是目标也具有不在源上的单元。由于SyncTable是在未指定dryrun选项并将doDeletes选项设置为false的情况下运行的，作业已删除目标集群中的多余单元，并将源中找到的多余单元添加到了目标集群。假设在两个集群上均未发生写操作，则随后在目标集群中运行完全相同的SyncTable命令将不会显示任何差异：

hbase org.apache.hadoop.hbase.mapreduce.SyncTable --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://nn:9000/hashes/test-tbl test-tbl test-tbl…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148…

适用场景

数据同步

乍一看，HashTable/SyncTable似乎与CopyTable工具重叠，但是在某些特定情况下，这两种工具都更适合。作为第一个比较示例，使用HashTable/SyncTable初始化包含100,004行且总数据大小为5.17GB的表的初始加载仅需几分钟即可完成SyncTable ：

...20/04/29 03:48:00 INFO mapreduce.Job: Running job: job_1587985272792_001120/04/29 03:48:09 INFO mapreduce.Job: Job job_1587985272792_0011 running in uber mode : false20/04/29 03:48:09 INFO mapreduce.Job:  map 0% reduce 0%20/04/29 03:54:08 INFO mapreduce.Job:  map 100% reduce 0%20/04/29 03:54:09 INFO mapreduce.Job: Job job_1587985272792_0011 completed successfully…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148EMPTY_BATCHES=97148HASHES_NOT_MATCHED=97148RANGESNOTMATCHED=97148ROWSWITHDIFFS=100004TARGETMISSINGCELLS=749589TARGETMISSINGROWS=100004

即使在如此小的数据集上，CopyTable的执行速度也更快（大约3分钟，而SyncTable则需要6分钟才能复制整个数据集）：

...20/04/29 05:12:07 INFO mapreduce.Job: Running job: job_1587986840019_000520/04/29 05:12:24 INFO mapreduce.Job: Job job_1587986840019_0005 running in uber mode : false20/04/29 05:12:24 INFO mapreduce.Job:  map 0% reduce 0%20/04/29 05:13:16 INFO mapreduce.Job:  map 25% reduce 0%20/04/29 05:13:49 INFO mapreduce.Job:  map 50% reduce 0%20/04/29 05:14:37 INFO mapreduce.Job:  map 75% reduce 0%20/04/29 05:15:14 INFO mapreduce.Job:  map 100% reduce 0%20/04/29 05:15:14 INFO mapreduce.Job: Job job_1587986840019_0005 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2787236791BYTES_IN_RESULTS=5549784428MILLIS_BETWEEN_NEXTS=130808NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1334REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100004RPC_CALLS=2657RPC_RETRIES=0

现在，让我们再次使用这两种工具来处理数据集上的稀疏差异。所有这些示例上使用的test-tbl表在源集群中具有四个区域。在上一示例中将所有原始数据集复制到目标集群之后，我们仅在源端添加了四行，每个现有区域都添加了一行，然后再次运行HashTable/SyncTable以同步两个集群：

20/04/29 05:29:23 INFO mapreduce.Job: Running job: job_1587985272792_001320/04/29 05:29:39 INFO mapreduce.Job: Job job_1587985272792_0013 running in uber mode : false20/04/29 05:29:39 INFO mapreduce.Job:  map 0% reduce 0%20/04/29 05:29:53 INFO mapreduce.Job:  map 50% reduce 0%20/04/29 05:30:42 INFO mapreduce.Job:  map 100% reduce 0%20/04/29 05:30:42 INFO mapreduce.Job: Job job_1587985272792_0013 completed successfully…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97144HASHES_NOT_MATCHED=4MATCHINGCELLS=42MATCHINGROWS=5RANGESNOTMATCHED=4ROWSWITHDIFFS=4TARGETMISSINGCELLS=4TARGETMISSINGROWS=4

我们可以看到，只有四个分区不匹配，SyncTable的速度要快得多（大约需要一分钟才能完成）。使用CopyTable执行相同的同步显示以下结果：

20/04/29 08:32:38 INFO mapreduce.Job: Running job: job_1587986840019_000820/04/29 08:32:52 INFO mapreduce.Job: Job job_1587986840019_0008 running in uber mode : false20/04/29 08:32:52 INFO mapreduce.Job:  map 0% reduce 0%20/04/29 08:33:38 INFO mapreduce.Job:  map 25% reduce 0%20/04/29 08:34:15 INFO mapreduce.Job:  map 50% reduce 0%20/04/29 08:34:48 INFO mapreduce.Job:  map 75% reduce 0%20/04/29 08:35:31 INFO mapreduce.Job:  map 100% reduce 0%20/04/29 08:35:32 INFO mapreduce.Job: Job job_1587986840019_0008 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2762547723BYTES_IN_RESULTS=5549784600MILLIS_BETWEEN_NEXTS=340672NOT_SERVING_REGION_EXCEPTION=0NUM_SCANNER_RESTARTS=0NUM_SCAN_RESULTS_STALE=0REGIONS_SCANNED=4REMOTE_RPC_CALLS=1323REMOTE_RPC_RETRIES=0ROWS_FILTERED=0ROWS_SCANNED=100008RPC_CALLS=2657RPC_RETRIES=0

即使只复制四个单元格，CopyTable花费的时间与复制整个数据集所花费的时间相同。对于这个非常小的数据集和一个空闲的集群，这仍然可以实现，但是在具有较大数据集的生产用例下，并且许多向其写入数据的客户端应用程序也可能使用目标集群，与SyncTable相比，CopyTable的性能下降会更高。

值得一提的是，还有其他工具/功能可以结合使用以用于目标集群的初始加载（目标根本没有数据），例如快照导出，批量加载，甚至是原始副本的直接副本。源集群中的表目录。对于要复制大量数据的初始负载，先制作表快照，然后再使用ExportSnapshot工具，将胜过SyncTable或CopyTable等在线复制工具。

检查复制完整性

当对可能的复制问题进行故障排除时，HashTable/SyncTable的另一个常见用途是监视集群之间的复制状态。在这种情况下，它可以用作VerifyReplication工具的替代方法。通常，在检查两个集群之间的状态时，要么根本没有不匹配，要么是暂时的临时问题导致较大数据集的一小部分不同步。在前面的示例中，我们一直在测试环境中使用两个簇上应有100,008行具有匹配值的行。使用dryrun选项在目标集群上运行SyncTable将使我们确定所有差异：

20/05/04 10:47:25 INFO mapreduce.Job: Running job: job_1588611199158_0004…20/05/04 10:48:48 INFO mapreduce.Job:  map 100% reduce 0%20/05/04 10:48:48 INFO mapreduce.Job: Job job_1588611199158_0004 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=3753476784BYTES_IN_RESULTS=5549784600ROWS_SCANNED=100008…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_MATCHED=97148...

Unlike SyncTable we must run the VerifyReplication tool on the source cluster. We pass the peer id as one of its parameters so that it can find the remote cluster to scan for comparison:20/05/04 11:01:58 INFO mapreduce.Job: Running job: job_1588611196128_0001…20/05/04 11:04:39 INFO mapreduce.Job:  map 100% reduce 0%20/05/04 11:04:39 INFO mapreduce.Job: Job job_1588611196128_0001 completed successfully…HBase CountersBYTES_IN_REMOTE_RESULTS=2761955495BYTES_IN_RESULTS=5549784600…

org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$CountersGOODROWS=100008...

SyncTable毫无区别地查找源分区和目标分区之间的所有哈希匹配，因此避免了再次扫描远程源集群的需要。对两个集群中的每个单元，VerifyReplication都会进行一个一对一的比较，即使处理如此小的数据集，这也可能已经带来了很高的网络成本。

在源集群中添加另一行，然后再次执行检查。使用VerifyReplication：

20/05/05 11:14:05 INFO mapreduce.Job: Running job: job_1588611196128_0004…20/05/05 11:16:32 INFO mapreduce.Job:  map 100% reduce 0%20/05/05 11:16:32 INFO mapreduce.Job: Job job_1588611196128_0004 completed successfully…org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication$Verifier$CountersBADROWS=1GOODROWS=100008ONLY_IN_SOURCE_TABLE_ROWS=1…

在使用SyncTable之前，我们必须再次使用HashTable在源上重新生成哈希，因为现在有了一个新的单元格：

20/05/04 11:31:48 INFO mapreduce.Job: Running job: job_1588611196128_0003…20/05/04 11:33:15 INFO mapreduce.Job: Job job_1588611196128_0003 completed successfully...现在是SyncTable：20/05/07 05:47:51 INFO mapreduce.Job: Running job: job_1588611199158_0014…

20/05/07 05:49:20 INFO mapreduce.Job: Job job_1588611199158_0014 completed successfully…org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_NOT_MATCHED=97148MATCHINGCELLS=749593MATCHINGROWS=100008RANGESMATCHED=97147RANGESNOTMATCHED=1ROWSWITHDIFFS=1TARGETMISSINGCELLS=1TARGETMISSINGROWS=1

我们可以看到，由于两个远程集群之间进行了额外的扫描和单元比较，因此执行时间增加了。同时，VerifyReplication的执行时间几乎没有变化。

结论

当处理两个集群数据集之间的稀疏不匹配项时，HashTable/SyncTable是用于移动数据的有价值的工具。它利用数据分区和散列来有效地检测两个数据集之间的距离差异，从而在比较两个集群中的数据时减少了要扫描的单元数，同时还避免了不必要地放入目标集群中已经存在的值。但是，这并不是灵丹妙药，如上面的一些示例所示，尽管它在功能上似乎与CopyTable工具重叠，但在处理更大范围的顺序不匹配单元格时，后者可以提供更好的性能。从这个意义上讲，HashTable/SyncTable最适用于两个集群都已有数据的情况，或现有复制设置因对等方之一暂时不可用而中断的情况。

https://blog.cloudera.com/apache-hbase-replication-overview/

https://blog.cloudera.com/approaches-to-backup-and-disaster-recovery-in-hbase/

https://blog.cloudera.com/online-apache-hbase-backups-with-copytable/

https://blog.cloudera.com/introduction-to-apache-hbase-snapshots/

原文作者：Wellington Chevreuil

原文链接：https://blog.cloudera.com/hbase-clusters-data-synchronization-with-hashtable-synctable-tool/

本文分享自微信公众号 - 大数据杂货铺（bigdataGrocery）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

微信关注我们

原文链接：https://my.oschina.net/bigdatagrocery/blog/4696127

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

mongodb内核源码实现、性能调优、最佳运维实践系列-数百万行mongodb内核源码阅读经验分享

关于作者前滴滴出行技术专家，现任OPPO文档数据库mongodb负责人，负责oppo千万级峰值TPS/十万亿级数据量文档数据库mongodb研发和运维工作，一直专注于分布式缓存、高性能服务端、数据库、中间件等相关研发。后续持续分享《MongoDB内核源码设计、性能优化、最佳运维实践》，Github账号地址:https://github.com/y123456yz 序言 Mongodb内核源码由第三方库third_party和mongodb服务层源码组成，其中mongodb服务层代码在不同模块实现中依赖不同的third_party库，第三方库是mongodb服务层代码实现的基础(例如:网络底层IO实现依赖asio-master库,底层存储依赖wiredtiger存储引擎库)，其中第三方库也会依赖部分其他库(例如：wiredtiger库依赖snappy算法库，asio-master依赖boost库)。虽然Mongodb内核源码数百万行，工程量巨大，但是mongodb服务层代码实现层次非常清晰，代码目录结构、类命名、函数命名、文件名命名都非常一目了然，充分体现了10ge...

2020-10-30

448

Serverless 对研发效能的变革和创新

作者 |杨皓然（不瞋）对企业而言，Serverless 架构有着巨大的应用潜力。随着云产品的完善，产品的集成和被集成能力的加强，软件交付流程自动化能力的提高，我们相信在 Serverless 架构下，企业的敏捷性有 10 倍提升的潜力。本次分享我主要分为以下四个方面：一、DevOps 的挑战以及如何降低 DevOps 实施代价？二、为什么 Serverless 是云发展的必然结果？三、Serverless + DevOps =？四、实战案例分享 DevOps 的挑战 1. DevOps 的挑战对于应用交付的整个流程而言，通常会涉及三个环节，即开发、测试和运维，而在传统的组织架构中，他们对应的也往往是三个不同的团队。这三个环节各自有自己的侧重点，但是在实际上，想要让整个应用交付过程变得顺滑高效，并且让应用在上线后保持高可用的状态，往往需要三个团队将相互之间存在的墙打破掉。这里的墙不只是组织架构隔阂所带来的障碍，还包括三个领域关注点的不同。比如开发需要关注可测试性和可运维性，这些东西将会深刻地影响应用的架构设计和开发实现，如果开发同学没有充分考虑到代码的可测试性，那么交给测试...

2020-10-30

455

发表评论

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。