EMC中國研究院 楊子夜
本文對重複數據刪除(data de-duplication )技術作簡要的介紹。由於筆者非此方面的專家，故有些方面的闡述難免以偏概全，望各位讀者海涵。此外，文中所述僅表明個人觀點，而不代表公司觀點。
正文
什麼是data De-duplication？
維基百科上這麼解釋重複數據刪除(簡稱DEDUPE)[1]：一種可粗粒度去除冗餘數據的特殊數據壓縮技術。開宗名義的解釋了DEDUPE和數據壓縮之間的聯繫。通俗的講，數據壓縮[2]一般通過字符串(string) 或者比特(Bit)級的一些操作來去除冗餘數據，常用的無損數據壓縮算法有lempel_Ziv [3], Huffman coding[4], rangeencoding[5]等。例如Gzip[6]使用的DEFLATE[7]算法就基於lempel和huffman算法。然而DEDUPE判斷數據冗餘的粒度較大，一般是文件級別，或者塊(block)級別的匹配，希望達到性能和去重複比例的一個平衡。
我們爲何需要DEDUPE？根據Gartner[8]提供的報告，對大企業來講，數據快速增長是數據中心最大的挑戰。顯而易見，爆炸式的數據增長會消耗巨大的存儲空間，迫使數據提供商去購買更多的存儲，然而卻未必能趕上數據的增長速度。這裏有幾個相關問題值得考慮： 產生的數據是不是都被生產系統循環使用？如果不是，是不是可以把這些數據放到廉價的存儲系統中？怎麼讓數據備份消耗的存儲更低？ 怎麼讓備份的時間更快？數據備份後，能保存的時間有多久(物理介質原因)？備份後的數據的能不能正常取出？
在現實情況中，和生產系統連接的備份系統一般每隔一段時間會對生產系統做一次主備份，意即備份生產系統中的所有內容。然後在兩次主備份之間有很多增量式(minor)備份。生產系統和備份系統的工作時間是一般來講是互斥的。當然如果生產系統需要持續運行，那麼備份系統則需要工作在生產系統相對閒的時間。 也就是說，備份系統的工作時間是有限制的，一般這個時間被稱爲備份窗口。需要被備份的數據必須在這個時間全部被遷移到備份系統，這就對備份系統的吞吐率(Throughput)有需求。那麼怎麼提高吞吐率呢？純粹更換硬件是一種方法。例如，在10年前，主流的備份系統用的是磁帶(tape)。對於磁帶來講，侷限在於吞吐率不夠以及只支持順序讀寫。於是現在的備份系統的後端存儲開始採用磁盤，以提高吞吐率方面的需求。此外我們是不是可以從數據來源或者從軟件的角度考慮問題？用於備份的數據，或者多次備份過來的數據可能是相似的，如果我們不是機械化地去備份那些數據，而是有意識地識別其中冗餘的數據，然後對相同的數據，只備份一份或者少數幾份(出於數據可靠性方面的考慮)。那麼這樣的方法不僅僅減少了備份系統所需要的容量，甚至可以減少備份時候對帶寬的使用。舉個現實的例子，郵件系統中有很多羣發郵件，內容相同，特別是附件。試問郵件備份系統中需要對用戶的相同附件都保存一份嗎？答案顯然是沒必要。從郵件系統的例子中，我們可以看出DEDUPE的作用，不過郵件系統所用的DEDUPE比較簡單，主要針對相同的文件。
聰明的看官一定會發現文件級別的DEDUPE，也就是單實例存儲(Single instance store)，有很大的侷限性。最淺顯的問題就是： 如果文件內容略微有些不同，那怎麼怎樣進行數據去重複呢？換句話說文件級別的粒度太大；而粒度太小就變成了常用數據壓縮技術，也不太合適。所以我們需要的是塊級別的，比如大小平均在8K左右（經驗值）。這樣的數據去重複，兼顧空間（數據去重複比率）和時間（備份性能）達到一個最佳的平衡點。
綜上所述，DEDUPE一般用於備份系統中（或者二級存儲，對於其他系統先不作討論）。所以衡量一個應用DEDUPE的備份系統是不是優秀，有以下幾個特徵(可能有遺漏，請各位指正)：
數據去重複比。數據去重複比例越大，就會減少備份系統存儲方面的壓力。同時在二次或者多次數據備份的時候，減少網絡帶寬的使用。吞吐率。使用了相關數據去重複技術後，備份時間是否顯著縮短。根據前面所說的，對於諸多生產系統來講，備份窗口時間有限。如果數據吞吐率不高，即使再高的數據壓縮比，也很難被採用。數據的可靠性。這個是指經過DEDUPE處理後的數據，在進行災難恢復時，數據能否被正常恢復，因爲除重後的數據已經不是原來的數據。這一點往往被外行人所忽略，但是一個好的數據備份廠商，一定會重視這個問題。試想如果通過去重複後，數據在某些情況下，不能被正常恢復，那又何必應用DEDUPE做數據備份。備份過程的安全性。 這一點現在被考慮的比較少，如果對於企業內部或者私有云，基本上默認在數據備份過程中不會出現一些安全方面的問題，例如數據竊取。但是一旦DEDUPE技術作爲一個由三方提供的服務，則這個問題需要被重視。
DEDUPE的分類
上一部分簡單介紹了DEDUPE技術，這一部分我們稍微談一下DEDUPE的主流分類，使得讀者能夠更好的理解DEDUPE。
分類一
第一種根據應用DEDUPE的位置：源端(Source)或者目標端(target)。源端指備份數據的來源；目標端是指備份系統。在這裏，我們稍微提一下怎麼判斷一塊數據是否被備份系統存儲。一般來講，每一塊數據都會保留一個“指紋”(fingerprint),爲了保證指紋的唯一性，可以使用一些比較好的Hash算法[9]。所謂源端去重複，是指判斷數據重複的工作在源端進行。比如，用戶在上傳某數據的時候，可以進行以下的步驟：
(a) 使用單向函數(某些hash算法)生成需要上傳的數據的指紋。
(b) 把指紋發送到備份系統，等待確認。
(c) 位於目標端的備份系統，判斷是否存在相似的數據。給源端返回數據是否存在的信息。
(d) 源端接收到信息後，決定是否上傳數據。
源端數據去重複的好處顯而易見，如果數據已經被備份過了，則不需要數據再傳送給備份系統。當然源端數據去重複，性能未必一定高，在確認數據交換的時候，需要傳送大量的指紋，也是不小的開銷。此外如果源端是不可信的，可能將引起某些安全問題。弊病的原因在於用戶能感知某些文件在備份系統中的存在性，這樣可進行某種安全攻擊。試想以下應用場景：假設一個備份系統中存有很多用戶的工資信息，每個用戶都有一個工資單，工資單的模板都是一樣。那麼某些用戶可以去探測其他人的工資信息。假設工資單中只含有以下信息<用戶姓名，工號，工資>。如果一個用戶A知道用戶B的姓名，工號，要猜測對方的工資，可以在源端生成相關文件，然後上傳給備份系統，一旦發現生成的文件沒有被上傳，就可以確定B的工資。當然這種攻擊是非常耗時的，但是在理論上完全存在這種可能性。
和源端應用DEDUPE相對應的是在目標端應用DEDUPE，在這種情況下，源端只要上傳把數據上傳給位於目標端的備份系統即可，源端甚至感受不到DEDUPE技術的存在。所有的數據都會通過網絡或者其他傳輸機制交給備份系統。備份系統對接收到的數據做統一地應用DEDUPE。相比源端DEDUPE，雖然傳輸數據的網絡帶寬佔據較大，但是也有很多好處：(a) 客戶端完全透明，去除了安全方面的隱患，也不用對客戶端做維護工作，例如版本升級(b)去重複數據都在目標端，使得管理集中，可進行全局的去重複，可稱爲一個相對獨立的系統。
分類二
第二種分類基於數據在備份系統中進行DEDUPE的時間發生點，有離線(post-process) 和在線(inline)兩種。 離線(後續)DEDUPE是這樣的，在用戶數據上傳的過程中，數據去重複並不會發生，而是直接寫到存儲設備上。當用戶數據上傳完全結束後，再進行相關的數據去重複。這樣的方式，可以理解成某些有很多胃的食草動物（例如牛），先把食物吃到胃中，然後在某個時間點再進行“反芻”，以完全消化食物。在食草動物的例子中，可以看到有反芻能力的動物一般具備很多胃。對應到備份系統中，就是至少需要有兩個存儲設備。試想如下的場景：用戶的備份數據是1PB， 那麼備份系統需要的存儲至少要大於1PB。其中第一個存儲設備大小爲1PB 用於存儲用戶上傳的數據，另外一個存儲設備大小爲X（X是指應用DEDUPE後的數據大小，在0和1PB之間）。這樣的去重複手段，讀者一定會看出其中的問題：爲了確保DEDUPE能正常進行，最差的情況下有100%的額外存儲資源消耗。
爲了解決這個問題，在線DEDUPE技術應運而生。所謂在線，就是在用戶數據通過網絡上傳到備份系統的時候，數據去重複就會發生。用戶的數據，會被DEDUPE子系統分成不同的部分，每個部分視爲一個chunk（塊或者切片），每個chunk會被計算一個相應的指紋，然後通過指紋去查找相關chunk存在的可能性，一旦存在，這個chunk就不會被寫入真實的存儲設備。在這一過程中，對CPU和內存的消耗是非常高的。雖然存儲某個數據，需要先查找塊是否存在，但是如果能找到，則避免了大量外部存儲寫操作，避免了過多的存儲(磁盤I/O)的操作時間，反而提高了備份的速度。另外由於多次備份的內容存在很大的相似性，則帶來的好處是非常可觀的，這樣看來，在線DEDUPE同時壓榨CPU，內存，網絡，存儲I/O等模塊，使得整個系統的資源能被更好的利用，和離線DEDUPE相比是一個不小的進步。
當然DEDUPE還有很多其他分類，例如根據目標端的備份系統可分爲：單機或者分佈式模式。在這裏，將不一一贅述。
深入瞭解DEDUPE
在這一部分，我們將略微深入地討論一下DEDUPE，以幫助讀者瞭解DEDUPE 是怎麼應用到備份系統中的，使得備份吞吐率，去重複比率，數據的完整和安全性都能得到滿足。
數據切片算法
開始的時候，我們就談到DEDUPE只是一種“塊”(chunk)級別的特殊數據壓縮技術。一般來講，數據切成chunk有兩種分類： 定長(fixedsize) 和變長(variable size)。 所謂定長就是把一個接收到的數據流或者文件按照相同的大小切分，每個chunk都有一個獨立的“指紋”。從實現角度來講，定長文件的切片實現和管理比較簡單，但是數據去重複的比率比較低。這個也是容易理解的，因爲每個chunk在文件中都有固定的便宜。但是在最壞情況下，如果一個文件在文件開始新增加或者減少一個字符，將導致所有chunk的“指紋”發生變化。最差結果是：
備份兩個僅差一個字符的文件，導致重複數據刪除率等於零。這個顯然是不可接受的。爲此變長chunk技術應運而生，不是簡單地根據文件偏移來劃分chunk，而是根據“anchor”(某個標記)來對數據分片。由於找的是特殊的標記，而不是數據的偏移，則能完美的解決定長chunk中由於數據偏移略有變化而導致的低數據去重複比率。例如圖1(來自[10]，PPT第22頁)生動的給出了同一文件修改了小部分內容，定長和變長分片算法的優劣。其中Venti[11] 系統採用的定長數據分片，插入新數據後，影響後面所有的chunk。LBFS[12]
和datadomain的DDFS[13]使用的是變長數據劃分，由於劃分chunk的依據是“Anchor”，即使插入了某些數據，也不影響後面大多數的chunk。
Figure 1 定長和變長數據切片比較
談到這邊，讀者要問變長切片中的“Anchor”究竟是怎麼確定的？一般使用基於內容的分片(content defined chunking，簡稱CDC)算法，使用滑動窗口技術(Sliding window algorithm)，窗口的大小一般是12-48個字節[12,14,15]。根據經驗值，分片大小在8K bytes對數據去重複是比較有效的。最常用的數據切片算法是利用rabin hash[15] 計算滑動窗口的指紋進行切片。如果活得的指紋滿足預先設定的條件，則這個窗口的位置是一個切分點，兩個切分點之間的數據被認爲是一個切片。Rabinhash有很多開源實現，比較早的rabin hash的應用在MITPdos研究組的Pastwatch[16] project中,有相應的源碼下載 。這裏附上一般CDC算法的僞代碼，如圖2 [17]所示。舉個實際的例子，假設滑動窗口的大小是48bytes，預先定義好的magic_value 是0x12，chunk_mask的值是0x1fff。當窗口每移動一個字節的時候，把rabinhash應用在大小48bytes的窗口後，得到一個值，然後取最低13位(實際是和chunk_mask做&操作)。如果得到的值是預先一定好的magic_value(0x12), 就說明我們找到了一個切分點。隨着窗口在整個文件中滑動，我們能找到所有的切分點，這樣所有的切片就被確定了。在給出的例子中，根據概率的期望值， 切片大小應該是8192 bytes。
Figure 2 常用CDC算法[17]
當然rabin hash也是有侷限性的，理想情況下， 使用rabin hash產生的切片大小（按照數學期望）是比較均勻，但是現實往往不是這樣。所以會導致以下的問題：(1)很多小切片，導致管理數據分片的代價變大 (一般使用樹狀索引)。(2) 數據切片太大，影響數據去重複的效果。爲了解決這兩個問題，很多研究人員提出了一些改進的方法，例如在NEC的一篇文章[14]中, 作者提出了雙峯算法，其主要思想是:進行二次切片。對於一些大的數據切片，可能採取一些繼續分片操作(Breaking-apart),對於大的切片可能採取切片合併操作(chunk amalgamation)。此外HP 實驗室也提供了一個框架來分析一些常用的CDC算法，並且提出了一個新的CDC算法： TTTD[18](TwoThresholds, Two Divisors Algorithm)。 所謂Two Thresholds： 就是規定切片的大小只能在上下界限之間， 所謂Two divisors： 是指使用rabin hash 來確定分界的時候，有兩個值可選，一個值稱爲主divisor，另外一個作爲backup divisor。當使用主divisor時，如果找不到分界點， 則backupdivisor的條件能不能被滿足。具體的僞代碼請見HP所寫技術報告的附錄。此外在NEC美國實驗室發表的文章[17]中還提出了一種fingerdiff的新切片算法，大家如有興趣可閱讀原文。
高效重複數據刪除
數據切片算法是DEDUPE技術中比較重要的一部分，但只依賴於數據切片算法是遠遠不夠的。前面我們提到衡量一個數據去重複有兩個重要指標：數據去重複率和吞吐率。很多研究表明[13,19,20,21,22]數據切片如果越小，去重複率越大，但是會導致低吞吐率；反之，數據切片越大，去重複率降低，但是吞吐率會提高，如圖3所示。爲此要求應用DEDUPE的系統必須選擇合適的切片大小，以在去重複率和吞吐率之間達到一個動態平衡。
Figure 3 chunk大小對數據去重複比率和吞吐率的影響[23]
在線 DEDUPE中，怎樣在數據切片後，根據數據切片的指紋高效率地在數據切片管理系統中查詢或者建立新的數據切片索引是提高吞吐率的關鍵所在。一般來講，數據是從網絡過來的，然後指紋的計算會利用大量的CPU， 指紋的查詢會利用大量的內存和進行過多的磁盤操作。爲此整個在線去重複系統就是高效利用網絡，CPU，內存和磁盤這4個組件。
例如DDFS[13] 採用了以下技術來提高數據的吞吐率:(1) Summary vector：對於分片的指紋查詢使用引入Bloom Filter[24]技術，Bloom Filter的好處在於沒有falsenegative. 凡是在bloom Filter中找不到的，就直接就說明這個指紋不存在。(2)SISL(streaming informed segment layout)：這個假設的前提對於一些數據流，有可能備份過一次後，會出現一些非常相似的數據流。 那麼對於某個數據流，應該作爲一個整體來考慮，和一個數據流相關的分片和相關的指紋，應該儘量集中放置在某幾個容器(container)中。在DDFS中，每個container大小定長，存儲了數據切片和相關的指紋(metadata)。(3) LPC(locality preserved cache)： 把數據切片的指紋和container維護一個mapping關係。這樣的好處在於，如果備份的數據流是有空間局部性的，那麼把一個數據指紋加載到內存（segmentcache）中的時候，和這個數據指紋位於同一個container中的指紋會一起被load到內存中，那麼後續數據切片的指紋就能直接在內存中找到，避免了不必要的外部I/O操作。此外segment cache使用LRU算法管理container。總的來說在DDFS中，切片(segment)的查找使用以下的步驟：
首先在segment cache中檢測segment是否已經存在。如果能找到，說明相關索引已經存在。如果不存在，則跳到2.在summary vector中使用Bloom Filter檢測segment是否存在。如果不存在，說明是一個new segment，就把這個segment寫入當前的container中。如果存在, 則跳到3.在segment的索引中，查找segment所對應的container ID。 如果在index中能知道，說明是一個重複的segment。這個時候，我們需要把這個container中的segment相關的信息加載到segment cache中。當然如果這個時候segment cache已經滿了，需要使用LRU 算法把某些container 從cache中去除，並且同步到外部存儲；如果在找不到，說明這是一個新的segment，需要把這個segment相關的信息寫入當然的container中。客觀來講，DDFS所使用的策略，是非常有效的，使得整個數據重複刪除的效率非常高，爲此在工業界，datadomain的產品在目前來講領先於其他同類產品，佔據了很大的市場份額。當然這不是說DDFS的技術已然是無可挑剔，從學術的角度來講，還是有很多優化的事情可做。例如，在2011年的ATC會議上，有篇文章[22]對切片指紋的查找提出了進一步的優化，此篇論文中提到DDFS這樣的系統只從locality方面來考慮高效的切片指紋查找，但是僅僅依靠locality是不夠。對於全備份(full backup )來講，所備份的數據流是具有很高的locality。但是對於那些增量式備份(incremental backup)的數據流，locality則比較差，爲此必須考慮另外一個因素similarity(“相似性”)。所用的策略是比較簡單。就是把很多緊密相關的小文件分爲一組，放入一個切片(segment)中，或者把一些大文件劃分成更多獨立的小切片(segment)來挖掘相似性。同時利用locality和similarity，作者提出了一個新的系統SiLo，能夠更好的去重複，並且在佔據內存較小的情況下，達到比較高的吞吐率，而其他系統會消耗更多的內存。
當然除了在軟件上優化指紋的查找，很多研究人員也在硬件方面考慮問題。我們知道，計算指紋(一般使用hash函數，比如Sha1)需要消耗大量的CPU。爲此引入其他物理器件(比如GPU)[25,26]，使得CPU的計算能力能被釋放，做更有意義的工作。
數據可靠性
在過多目光放在DEDUPE的去重複率和吞吐率方面的時候，我們需要考慮備份數據的可恢復性以及完整性。也就說，希望備份數據的invulnerability不能被破壞。那麼到底從哪些方面保證數據的可靠性？筆者認爲，對一個去重複系統而言來講，當數據從客戶端通過傳輸介質進入數據去重複系統後，必須考慮系統中的每一個模塊。也就是說在設計整個DEDUPE系統的時候，必須考慮任何一個部件在運行過程存在錯誤的可能。
首當其衝需要考慮的是外部存儲的可靠性。現在備份的數據最終會放到磁盤(取代了以前的磁帶)。所以一個簡單的問題，就是在備份過程中磁盤設備壞了，該如何處理？爲了解決這個問題，RAID[27]技術中被引入。一般常在數據去重複系統中的應用有RAID0，RAID5或者RAID 6。當然RAID技術也有軟件和硬件之分。硬件RAID部署起來雖然比較容易，但是也不是百分之百能保證數據不出錯。磁盤也一樣，寫入磁盤的數據未必一定正確，當然發生的概率非常低。爲此就需要去重複系統，通過軟件的方法去驗證一些數據的完整性。例如對於一些數據結構，採用內嵌的checksum(校驗值)來保證數據的完整性。
第二個可能需要考慮的是內存的可靠性，在服務器上，我們知道所帶的內存比較高級一些，都攜帶ECC(Error correcting code)功能。對於deduplication系統而言，如果內存有這樣的機制，就可以去監控這些內存條。如果在同一個區域ECC 錯誤的出現頻率變高了，超過了某個閾值，似乎就可以判斷這塊內存條在一定時間內有損壞的可能，需要及時進行替換。再發散一下，就是對系統中任何的硬件，都需要有監控，以防止意外發生，例如CPU和風扇的溫度等。
第三個問題，可能比較難解決了。假設在進行去重複的過程中，整個系統崩潰了，還能保證數據的完整性嗎？對於那些還在CPU或者內存中的數據，但是並沒有被刷入外部存儲的數據，我們能不能進行相關的track。發生這樣的事情，最完美的結局是：系統能恢復正常，還沒刷入外部存儲的數據（已經經過了指紋處理），能被正常的寫入外部存儲。直觀的想，這似乎是不可能的，但是細想一下，似乎還有一定的解決方案。先把思維發散到數據庫中。我們知道支持OLTP的數據庫，對事物的支持有很強的要求，比如那些沒被正常commit的事務(transaction)需要被回滾。在數據庫中爲了滿足這一需求，引入了WAL(write ahead log)機制。也就任何寫磁盤操作，必須先寫log。那麼在數據去重複系統中，是不是也可以引入WAL 機制呢？的確可以，但是純粹使用引入WAL機制，似乎不能滿足數據去重複系統高吞吐率的要求，那麼怎麼辦？爲此數據去重複系統向一些高端的存儲系統學習，引入了NVRAM[29]，那麼log可以先寫入NVRAM。於是當系統崩潰的時候，一些數據就可以從NVRAM中恢復出來，這在一定程度上緩解了系統崩潰所導致的數據丟失問題。但是NVRAM也不是萬能的，系統依然在某些情況下，會處於一個不能完全恢復數據的狀態，當然這樣的概率是比較低的。
從數據invulnerability的角度來講，開發一個好的數據去重複系統還是比較難的。總的來講，必須把數據可失性的問題在軟件和硬件等方面進行全面考慮，才能儘可能的避免數據在去重複或者恢復過程中的丟失。
自由討論(open discussion)
DEDUPE技術的萌芽到興起時間不長，但是隨着大數據的增長，需求也是爆炸式增長。前面我們所講的是當前DEDUPE技術在數據備份系統中的應用，市場上銷售的DEDUPE系統基本都是一體化的。所謂一體化系統，是指數據去重複系統以容量大小進行銷售，也就是說用戶會購買一個BOX(包含了所有軟硬件)。但是大家不禁要問，隨着容量的增長，單個BOX是否還能滿足要求？
就筆者而言，答案是否定的。數據去重複系統的可擴展性(scalability)在以後會成爲一個比較熱門的話題，只是現在處於探索階段。目前我們可以進一步壓榨多核(many/multi core)或者GPU的能力，但是總有一天，優化的效果會變得越來越不顯著。爲此我們必須轉向分佈式系統，或者把數據去重複和雲聯繫起來。例如昆騰公司最近發佈了一款虛擬插件產品DXi V1000[30]，開始把數據重複刪除和虛擬化以及雲相結合。此外在2011年的FAST會議上，EMC 發表了一篇分佈式數據去重複的文章[31]，具體內容大家可以閱讀原文。DEDUPE在數據備份相關中的應用，還有很長的路要走，在這裏筆者只是拋磚引玉：
如上文所言，構建分佈式的數據去重複系統。和雲結合，有很多種玩法：對雲存儲服務商而言，可以在雲存儲背後使用DEDUPE 技術，來降低自己的成本。雲服務代理商，可以結合DEDUPE技術和一些廉價的雲存儲服務，來提供更加可靠的存儲服務。在這裏，DEDUPE技術也是爲了降低成本。DEDUPE供應廠商，不再單純的賣B OX給用戶，而是提供更加一體化的服務。當前用戶的BOX容量滿了，需要替換，購買容量更大的BOX，對於一些小企業來講，持續的替換是一個比較大的IT開銷。爲此如果數據去重複廠商，提供額外的雲服務，允許在用戶BOX容量滿的情況下，把去重複後的數據放到遠端，當然這個從性能而言會有下降，但是確實滿足了小型企業的一個需求。比如，如果用戶買了1T的去重複系統，附加一個10T的雲數據去除系統，會不會有相應的市場呢？DEDUPE除了在數據備份系統(主要指secondarystorage)中的應用，在其他方面，例如主存儲(primary storage)，文件系統，虛擬化甚至內存中。在這裏我們可以稍微簡單介紹一下：
主存儲中的數據去重複。在2012年的FAST會議上，NetApp公司發了一篇文章[32]，希望DEDUPE在主存儲上的應用能同時在存儲空間節省和I/O延遲之間做一個平衡。另外在2010年ACM TOS 的雜誌上也發表了一篇在主存儲上進行I/O deduplication的文章[33]。文件系統的數據去重複。比如ZFS[34], liveDFS [35], SDFS[36],DEDE[37],。 其中ZFS在文件系統管理中支持了數據去重複功能； liveDFS也差不多，可在虛擬機內進行DEDUPE；SDFS可在一些文件系統之下進行DEDUPE，不過它是一個用戶級數據去重複文件系統；DEDE工作在VMware的VMFS層可以在線的對用戶虛擬機磁盤進行重複數據刪除。內存中的去重複(數據共享)。這個大家應該不會陌生，一般都是在page(頁)級別進行內存共享。例如在操作系統中進程之間貢獻內存，而使用的copy-on-write 機制，以及同一個host中的不同虛擬機之間通過copy-on-write 機制共享內存。另外還有一些更復雜內存數據去重複機制，例如[38,39]。總結
本文首先對數據重複刪除技術(DEDUPE) 做了簡要的介紹，接着探討了DEDUPE在數據備份中的一些核心技術，最後筆者還列出了DEDUPE在其他方面的一些應用。
原帖地址：http://qing.blog.sina.com.cn/2294942122/88ca09aa33000uyo.html