91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

HBase如何使用HashTable/SyncTable工具同步集群數據

發布時間:2021-12-08 14:20:44 來源:億速云 閱讀:344 作者:小新 欄目:大數據

這篇文章主要為大家展示了“HBase如何使用HashTable/SyncTable工具同步集群數據”,內容簡而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領大家一起研究并學習一下“HBase如何使用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_MATCHEDHASHES_NOT_MACTHED計數器)。另外,內兩個分區具有不同的散列,  17個單元2行中是匹配的(分別由MATCHING_CELLSMATCHING_ROWS報告),但是在這兩個分區上也有2行是分歧的(根據RANGESNOTMATCHEDROWSWITHDIFFS)。最后,SOURCEMISSINGCELLSTARGETMISSINGCELLS會詳細告訴我們單元僅存在于源集群還是目標集群上。在此示例中,源集群具有不在目標上的一個單元,但是目標也具有不在源上的單元。由于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工具,將勝過SyncTableCopyTable等在線復制工具

檢查復制完整性

當對可能的復制問題進行故障排除時,HashTable/SyncTable的另一個常見用途是監視集群之間的復制狀態。在這種情況下,它可以用作VerifyReplication工具的替代方法。通常,在檢查兩個集群之間的狀態時,要么根本沒有不匹配,要么是暫時的臨時問題導致較大數據集的一小部分不同步。在前面的示例中,我們一直在測試環境中使用兩個簇上應有100,008行具有匹配值的行。使用dryrun選項在目標集群上運行SyncTable將使我們確定所有差異:

20/05/04 10:47:25 INFO mapreduce.Job: Running job: job_1588611199158_000420/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 successfullyHBase CountersBYTES_IN_REMOTE_RESULTS=3753476784BYTES_IN_RESULTS=5549784600ROWS_SCANNED=100008org.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_000120/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 successfullyHBase 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_000320/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 successfullyorg.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper$CounterBATCHES=97148HASHES_NOT_MATCHED=97148MATCHINGCELLS=749593MATCHINGROWS=100008RANGESMATCHED=97147RANGESNOTMATCHED=1ROWSWITHDIFFS=1TARGETMISSINGCELLS=1TARGETMISSINGROWS=1

我們可以看到,由于兩個遠程集群之間進行了額外的掃描和單元比較,因此執行時間增加了。同時,VerifyReplication的執行時間幾乎沒有變化。

以上是“HBase如何使用HashTable/SyncTable工具同步集群數據”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

资溪县| 武邑县| 永城市| 黑山县| 社会| 车险| 神池县| 鸡泽县| 潼关县| 腾冲县| 南充市| 东海县| 丰原市| 蒙自县| 文登市| 行唐县| 卫辉市| 晋州市| 郯城县| 红河县| 敖汉旗| 闽侯县| 江北区| 赫章县| 台中市| 寿阳县| 分宜县| 普宁市| 北碚区| 湘乡市| 江油市| 合川市| 凌云县| 内江市| 临桂县| 新昌县| 胶州市| 东港市| 甘肃省| 大厂| 南丰县|