HDFS資料遷移解決方案之DistCp工具的巧妙使用分析
前言
在當今每日資訊量巨大的社會中,源源不斷的資料需要被安全的儲存.等到資料的規模越來越大的時候,也許瓶頸就來了,沒有儲存空間了.這時候怎麼辦,你也許會說,加機器解決,顯然這是一個很簡單直接但是又顯得有些欠缺思考的辦法.無謂的加機器只會帶來無限上升的成本消耗,更好的辦法應該是做到更加精細化的資料儲存與管理,比如說非常典型的冷熱資料的儲存.對於巨大的長期無用的冷資料而言,應該用效能偏弱,但是磁碟空間富餘的機器存,熱資料則反之.資料的分類儲存一定會帶來資料的同步問題,假若我有2套叢集,1個是線上的正在使用的叢集,另外1個則是冷資料叢集,我如何做定期的資料同步並且同時對業務方的使用影響完全透明呢?本文就給大家闡述一下本人的一個解決方案,供大家參考.
資料遷移使用場景
上小節中說到的冷熱資料的同步只是資料遷移的一個表現場景,那麼資料遷移還有其他哪些使用場景呢,如下:
冷熱叢集資料分類儲存,詳見上述描述. 叢集資料整體搬遷.當公司的業務迅速的發展,導致當前的伺服器數量資源出現臨時緊張的時候,為了更高效的利用資源,會將原A機房資料整體遷移到B機房的,原因可能是B機房機器多,而且B機房本身開銷較A機房成本低些等. 資料的準實時同步.資料的準實時同步與上一點的不同在於第二點可以一次性操作解決,而準實時同步需要定期同步,而且要做到週期內資料基本完全一致.資料準實時同步的目的在於資料的雙備份可用,比如某天A叢集突然宣告不允許再使用了,此時可以將線上使用叢集直接切向B的同步叢集,因為B叢集實時同步A叢集資料,擁有完全一致的真實資料和元資料資訊,所以對於業務方使用而言是不會受到任何影響的.上述3個使用場景中,其中第一點相比較於第二,三點來說可能稍微容易一些,但是想要完全做好也不簡單.第三點資料的實時同步想比較第二點來說更加實際一些.因為如果公司要準備叢集資料遷移了,一般都會提前通知,然後做逐步遷移,而且也肯定不會讓原叢集停止服務,所以採用資料慢慢同步的方式,等到資料徹底同步完了,才最終實現切換,達到最終的遷移目標
資料遷移要素考量
當要做大規模的資料遷移的時候,需要做很多的前期準備工作,而且需要對很多因素,指標進行考量.以下是幾個主要指標:
1.Bandwidth-頻寬
在做大規模資料量的同步過程中,如何控制同步資料過程中所佔用的網路頻寬就顯得非常的重要.頻寬用的多了,會影響到線上業務的任務執行,頻寬用的少了又會導致資料同步過慢的問題.所以這裡會引發出另外一個問題,對於頻寬的限流.也就是說,我要保證我的資料同步程式能保證限定在指定的網路傳輸速率下,如果你不做任何處理的話,那結果基本上就是網路有多少頻寬我就用多少頻寬的局面.
2.Performance-效能
效能問題同樣也是一個很關鍵的問題,是採用簡單的單機程式?還是多執行緒的效能更佳的分散式程式?顯然後者是我們更想要的.
3.Data-Increment-增量同步
當TB,PB級別的資料需要同步的時候,如果每次以全量的方式去同步資料,結果一定是非常糟糕.增量方式的同步會是不錯的選擇,那麼哪些情況下會導致資料發生增量變動呢
原始資料檔案進行了Append追加寫原始資料檔案被delete刪除或rename重新命名可能會有人好奇這裡為什麼沒有對原始資料進行改動的情況,這種case也會造成資料的變動啊,因為一般在海量資料儲存系統中,例如HDFS,一般不會在原檔案內容上做修改,要麼繼續追加寫,要麼刪除檔案,不會有類似RandomAccessFile的隨機寫的功能,所以做增量資料同步,只要考慮上述2個條件即可.上述條件中的第二點是非常容易判斷出的,通過定期的快照檔案或元資訊檔案一比就出來了,但是對於檔案是否被進行了追加寫或是其他的外界主動的修改操作的時候,我們如何進行判斷呢,下面給出2個步驟:
第一步: 先比較檔案大小,如果2個階段檔案大小發生改變,擷取對應原始長度部分進行checksum比較,如果此checksum不變,則此檔案必定發生過改變. 第二步: 如果檔案大小一致,則計算相應的checksum,然後比較2者的checksum.這種方式算得上是最保險的.
4.Syncable-資料遷移的同步性
資料遷移的過程中需要保證週期內資料是一定能夠同步完的,不能差距太大.比如A叢集7天內的增量資料,我只要花半天就可以完全同步到B叢集,然後我又可以等到下週再次進行同步.最可怕的事情在於A叢集的7天內的資料,我的程式花了7天還同步不完,然後下一個週期又來了,這樣就無法做到準實時的一致性.其實7天還是一個比較大的時間,最好是能達到按天同步.
HDFS資料遷移解決方案: DistCp的使用
上面分析了很多資料遷移中的很多使用場景和可能出現的問題.但是從這裡開始,是一個分水嶺了,下部分的文章主要闡述HDFS中的資料遷移解決方案,面對上文中提到的諸多問題,HDFS中到底應該如何解決.如果你不是HDFS,Hadoop的專家,可能問題看起來有點棘手,但是沒有關係,Hadoop內部專門開發了相應的工具,DistCp.在DistCp工具在HDFS中的定位就是來幹這件事情的,從source filesystem到target filesystem的資料拷貝.DistCp在hadoop-tools工程下,作為獨立子工程存在.在官方註釋中,對於DistCp的解釋如下:
?| 1 2 3 4 5 6 7 |
<code
class="hljs
applescript">
DistCp is the main driver-class
for
DistCpV2.
For
command-line use, DistCp::main() orchestrates the parsing of command-line
parameters
and the launch of the DistCp job.
For
programmatic use, a DistCp object can be constructed by specifying
options
(in a DistCpOptions object), and DistCp::execute() may be used to
launch
the copy-job. DistCp may alternatively be sub-classed to fine-tune
behaviour.
</code>
|
大意是通過命令列附帶引數的形式,構造出DistCp的job,然後執行此Job.所以從這裡可以知道,拷貝任務本身是一個MR的Job,已經把Hadoop本身的分散式執行的特性用上了.
DistCp優勢特性
鑑於DistCp的特殊使用場景,程式設計者在此工具程式碼中添加了很多的獨到的設計.下面針對上文提到的一些要素進行相應的闡述:
1.頻寬限流
DistCp是支援頻寬限流的,使用者可以通過命令引數bandwidth來為程式進行限流,原理類似於HDFS中資料Balance程式的限流.但是個人感覺做的比Balance稍微簡化了一些.DistCp中相關類是ThrottledInputStream,在每次讀操作的時候,做一些限流判斷:
?| 1 2 3 4 5 6 7 8 9 10 |
<code
class="hljs
java">
/**
{@inheritDoc} */
@Override
public
int
read() throws
IOException {
throttle();
int
data = rawStream.read();
if
(data != -1)
{
bytesRead++;
}
return
data;
}</code>
|
然後在throttle的方法中進行當前傳輸速率的判斷,如果過快會進行一段時間的睡眠來降低總平均速率
?
相關推薦HDFS資料遷移解決方案之DistCp工具的巧妙使用分析前言 在當今每日資訊量巨大的社會中,源源不斷的資料需要被安全的儲存.等到資料的規模越來越大的時候,也許瓶頸就來了,沒有儲存空間了.這時候怎麼辦,你也許會說,加機器解決,顯然這是一個很簡單直接但是又顯得有些欠缺思考的辦法.無謂的加機器只會帶來無限上升的成本消耗,更好的辦法應該是做到更加精細化的資料 Spark專案實戰-資料傾斜解決方案之原理以及現象分析一、資料傾斜的原理 在執行shuffle操作的時候，大家都知道是按照key來進行values的資料的輸出、拉取和聚合的。同一個key的values，一定是分配到一個reduce task進行處理的。假設多個key對應的values，總共是90萬。但是問題是可能某個key對應 資料傾斜解決方案之原理以及現象分析資料傾斜 在任何大資料類的專案中，都是最棘手的效能問題，最能體現人的技術能力，最能體現RD（Research Developer，研發工程師）的技術水平。 資料傾斜 = 效能殺手 如果沒有豐富的經驗，或者沒有受過專業的技術培訓，是很難解決資料傾斜問題的 在執行shuff Spark專案實戰-資料傾斜解決方案之將reduce join轉換為map join一、reduce端join操作原理 二、map端join操作原理 三、適用場景 如果兩個RDD要進行join，其中一個RDD是比較小的。一個RDD是100萬資料，一個RDD是1萬資料。（一個RDD是1億資料，一個RDD是100萬資料） 其中一個RDD必須是比較 Mybatis 只返回一條資料的解決方案 之association、collection:[StudentC{sid=14, sname='null', sage=null, saddress='null', classS=ClassS{id=345345345, className='二班', studentId=null, students=null}}, StudentC{sid=15, spark 大型專案實戰(五十八):資料傾斜解決方案之sample取樣傾斜key進行兩次join當採用隨機數和擴容表進行join解決資料傾斜的時候，就代表著，你的之前的資料傾斜的解決方案，都沒法使用。 這個方案是沒辦法徹底解決資料傾斜的，更多的，是一種對資料傾斜的緩解。 原理，其實在上一講，已經帶出來了。 步驟： 1、選擇一個RDD，要用flatM MongoDB分片環境下整體資料遷移解決方案背景：這周請了幾天假，25號早上來了，就開始搞MongoDB資料庫分片叢集環境的整體遷移，起初以為很容易，但是在遷移的過程中，遇到了各種問題。還好經過兩天的研究，現在終於搞定！匆忙之中，整理了一下文件，由於網上關於MongoDB資料庫遷移的文章較少，顧發表 IOS 資料庫升級資料遷移解決方案前言 很久以前就遇到過資料庫版本升級的引用場景，當時的做法是簡單的刪除舊的資料庫檔案，重建資料庫和表結構，這種暴力升級的方式會導致舊的資料的丟失，現在看來這並不不是一個優雅的解決方案，現在一個新的專案中又使用到了資料庫，我不得不重新考慮這個問題，我希望用一種比較優雅的 資料傾斜解決方案之使用隨機key實現雙重聚合使用隨機key實現雙重聚合 1、原理 2、使用場景 （1）groupByKey （2）reduceByKey 比較適合使用這種方式；join，咱們通常不會這樣來做，後面會講三種，針對不同的join造成的資料傾斜的問題的解決方案。 第一輪聚合的時候，對key進行打散，將 XTTS系列之一：U2L遷移解決方案之XTTS的使用本系列的定位是對XTTS及相關技術進行深入的學習研究。作為本系列的開篇，本著實用性的原則，我先把一次實際生產環境U2L的遷移實戰實施方案進行提煉簡化，旨在能清楚說明該如何使用XTTS這種解決方案來進行U2L遷移，先達到可以跟著做下來的初級目標，如果有興趣再去深入研究相關細節。 1.XTTS概述 2.遷移準備 企業產業升級解決方案之BI大數據分析系統搭建處的 減少 新的 重要 客戶 大數據分析 用戶體驗 大數 優勢 面對這個大數據時代，傳統企業轉型數字化已經迫在眉睫。眾所周知我們現在所處的時代是一個數字和創新的時代。在企業運行的過程中，分分鐘會產生龐大的數據，如何利用好這些數據實現數字和創新也是管理者們必須掌握的技能。因此 解決方案之網站大資料高併發大資料處理 1、資料庫 垂直拆分：根據業務把表放到不同的資料庫，解決表之間的IO競爭 水平拆分：根據某種規則把單表資料分成多張表儲存，解決單表資料量大的問題 索引：根據業務場景建立合理的索引，如果資料量很小建議使用索引（300條以內） 索引使用場景： 動作描述 spark解決方案系列--------1.spark-streaming實時Join儲存在HDFS大量資料的解決方案spark-streaming實時接收資料並處理。一個非常廣泛的需求是spark-streaming實時接收的資料需要跟儲存在HDFS上的大量資料進行Join。要實現這個需求保證實時性需要解決以下幾個問題： 1.spark-streaming的資料接收間隔往往很小， 企業產業升級解決方案之BI大資料分析系統搭建面對這個大資料時代，傳統企業轉型數字化已經迫在眉睫。眾所周知我們現在所處的時代是一個數字和創新的時代。在企業執行的過程中，分分鐘會產生龐大的資料，如何利用好這些資料實現數字和創新也是管理者們必須掌握的技能。因此BI大資料分析系統便出現在更多人的視野。 BI大資料分析系統它是早在1958年就已經有了商業雛形， redis系列之資料庫與快取資料一致性解決方案資料庫與快取讀寫模式策略 寫完資料庫後是否需要馬上更新快取還是直接刪除快取？ （1）、如果寫資料庫的值與更新到快取值是一樣的，不需要經過任何的計算，可以馬上更新快取，但是如果對於那種寫資料頻繁而讀資料少的場景並不合適這種解決方案，因為也許還沒有查詢就被刪除 關係型資料庫大資料效能優化解決方案之：分表(當前表歷史表)、表分割槽、資料清理原則原因和目的由於交易量大或者日積月累造成資料庫的資料量越來越大。會導致系統性能大幅下降，所以要對部分業務的表資料作備份和清理減少資料量，來提升請求響應的速度，提升使用者體驗資料是否需要清理的閥值判斷通常當表的磁碟大小超過 5GB，或對於 OLTP 系統(聯機事務處理)，表的記錄 Unity資源解決方案之AssetBundle保留 裝包 方法 bundle 以及 pipe 用法 遊戲 cnblogs 1、什麽是AssetBundle AssetBundle是Unity pro提供的一種用來存儲資源的文件格式，它可以存儲任意一種Unity引擎能夠識別的資源，如Scene、Mesh、Material angularjs解決方案之 遞歸模板遞歸模板手風琴模式的菜單： 在項目中我們會遇到不知層級的json數據，需要前端人員去遍歷生成View視圖，這種情況下我們就會用到遞歸方法。 angularjs中的dom結構也是可以用遞歸的方式去循環遍歷數據。<ul side-navigation class="nav metismenu" 前端多層回調問題解決方案之$.Deferredfail -s 使用 defer 解決方法 == 默認 don blog javascript引擎是單線程的，但是通過異步回調可以實現IO操作並行執行能力，當業務邏輯復雜的時候我們就進入回調地獄。 本文講得ajax是在jquery1.5以前的版本，目的旨在讓我們理解延遲對象 ES6 異步編程解決方案 之 Promise 對象詳解 on() 基本 ack 地獄 down 場景 fill success 一、Promise 概述 Promise 對象是 ES6 提供的原生的內置對象 Promise 是異步編程的一種解決方案（異步代碼同步化），比傳統的解決方案——回調函數和事件——更合理和更強大 |