HBase的跳過區域服務器直接從HFILE

Question

• 在嘗試超過10十億條記錄轉儲到HBase的，這將 平均增長在10萬左右一天，然後試圖在記錄的全表掃描 讀取行。我知道全面掃描hdfs將 比hbase更快。
• Hbase正在用於對hdfs上的不同數據 進行排序。該應用程序正在使用spark構建。
• 數據被批量加載到hbase上。由於各種2G限制，3G的初始測試將區域大小降至1.2G（仍需要進一步詳細調查）。
• 掃描緩存爲1000，緩存塊關閉
• 總的hbase大小在6TB範圍內，產生跨5個區域服務器（節點）的數千個區域。 （建議低數百）。
• Spark工作基本上是在每一行上運行，然後根據某個範圍內的列計算某些內容。
• 使用內部使用TableInputFormat的spark-on-hbase，作業在大約7.5小時內運行。
• 爲了繞過區域服務器，創建了一個快照並改爲使用TableSnapshotInputFormat。這項工作在abt 5.5小時完成。

問題

1. 從HBase的成火花讀取時，區域似乎支配 火花分區並且因此2G限制。 Hence problems with caching這是否意味着區域大小需要較小？

2. 繞過區域西弗斯和 從快照直接讀取，還創建它分裂各地區 所以仍將落入區域大小問題以上TableSnapshotInputFormat。 可能直接從hfiles中讀取鍵值，在這種情況下， 拆分大小由hdfs塊大小決定。是否有一個 實現掃描儀或其他可以直接從hfile讀取一行 的實用程序（特定於快照引用的hfile）？

3. 是否有任何其他指示可以幫助提升性能的配置說明？例如hdfs塊大小等？主要用例大部分是全表掃描。

Answer 1

事實證明這其實很快。性能分析表明，問題出在一個IP地址的對象表示之一，即InetAddress花費了大量的時間來解析一個IP地址。我們決定使用原始字節來提取我們需要的任何東西。這本身使這項工作在大約2.5小時內完成。 將上述問題作爲Map Reduce問題進行建模並在MR2上運行，結果與上述相同，表明它可以在1小時20分鐘內完成。 迭代本質和更小的內存佔用有助於MR2實現更多的並行性，因此速度更快。