采集時(shí)序數(shù)據(jù)的另一個(gè)好處，就是能夠通過編程使你的應(yīng)用生成測量數(shù)據(jù)，從而可以建立安全、精密的反饋循環(huán)，這方面有很多有用的例子。

在云計(jì)算中，啟用新的實(shí)例只需要給提供者發(fā)一條簡單的API調(diào)用即可，但要想知道什么時(shí)候應(yīng)該啟動(dòng)更多的實(shí)例或撤銷正在運(yùn)行的實(shí)例，就會(huì)很麻煩。如果基于采集的資源使用情況來判斷啟用撤銷的話，就會(huì)容易得多，這是測量數(shù)據(jù)用做反饋機(jī)制的一種通例。

我在 Flickr，有一個(gè)大型項(xiàng)目，使用了這種反饋機(jī)制，事實(shí)證明，非常有用。



2007年，Yahoo!決定關(guān)掉 Yahoo!! Photos計(jì)劃很簡單:通知 Yahoo! Photos的用戶，這個(gè)服務(wù)將被關(guān)閉，用戶可以自己選擇，將自己的照片連同元數(shù)據(jù)一起轉(zhuǎn)移到其他的服務(wù)，包括非Yahoo!!的服務(wù)，像Shutterfly和 Kodak Gallery， Flickr也是選項(xiàng)之一。
 
為這個(gè)項(xiàng)目做出容量評估將是一件苦差事。盡管有一些測量數(shù)器據(jù)，用上載頻度、片大小及其他因素指述了Yahoo! Photos的典型用戶，但有多少用戶會(huì)選擇Flickr，即使選擇了Flickr，用戶的使用模式又會(huì)如何變化，我們心里仍然沒底。我們談?wù)摰氖且豁?xiàng)已經(jīng)超過10年的照片存儲(chǔ)服務(wù)，將會(huì)有巨量的數(shù)括，而且這么大的空同會(huì)在很短的時(shí)間內(nèi)消耗掉。不用講得太精確，我告訴你，2009年后期，F(xiàn)ick每天用掉大約12TB的存儲(chǔ)客量。從Yahoo! Photos到Flickr的遷移，在2007年持續(xù)了一段不長的時(shí)間，每天消耗的存空間是這個(gè)數(shù)的兩倍還多。

在在備遷移的過程中，基于對遷移的評估以及現(xiàn)有的 Yahoo! Photos數(shù)器，我們對存需求做了最好的估計(jì)，并給出了一個(gè)寬松的安全系統(tǒng)，確保遷移結(jié)束之前，不會(huì)出現(xiàn)存空間不夠的情況。我們能想到的每件事情，都有測量數(shù)據(jù):

● 遷移的賬戶
 
● 遷移的照片
 
● 處理的照片
 
● 遷移隊(duì)列大小
 
● 磁盤空間消耗量

對選擇遷移到Flickr的用戶，開始遷移過程，并進(jìn)行觀察

我直接聯(lián)到有意思的部分來說吧:即使微了如此謹(jǐn)慎的估計(jì)，我們還是錯(cuò)了，錯(cuò)大了。雖然做了研究，對存豬容量做了精心的評估，想遷近移到Fick來的人還是超出了我們的預(yù)期。要把想遷移到Flickr來的人的Yhoo! Photos數(shù)據(jù)都近移過來的話，我們部看的存豬空間都會(huì)用完。要么增加存豬，要么Flickr停止上載片。

調(diào)天地，由于測量數(shù)據(jù)能夠追蹤磁を請耗，我們很快意識到了這點(diǎn)，但卻受限于采購時(shí)間表。重要的是盡快購買、安裝、配置、部署更多存造，以免用完現(xiàn)有存。部著更多空間與遷移進(jìn)程之間展開了一場競賽，

為了解釋我們是如何通過測量數(shù)據(jù)反轉(zhuǎn)危為安的，要先介紹一下遷移過程是如何進(jìn)行的:

1.告知用戶，將關(guān)閉 Yahoo! Photos服務(wù)，用戶可以從列表中選擇遷移到哪里。假如選擇Flickr的話，該用戶賬號就進(jìn)人遷移隊(duì)列。
 
2.一旦用戶的遷移任務(wù)進(jìn)入隊(duì)列，則則鎖定該用戶的 Yahoo! Photos賬號，防止用戶進(jìn)行修改?，F(xiàn)在 Yahoo! Photos和 Flickr之間進(jìn)行API對API的通信，以獲取要遷移的照片數(shù)據(jù)。

3.Flickr獲取并處理 Yahoo! Photos賬號的照片及其元數(shù)據(jù)。
 
4.將Yahoo!Photos賬號寫人 Flickr存儲(chǔ)和數(shù)據(jù)庫。

遷移完成后，開放 Flickr這邊的賬號，通知用戶可以使用遷移過來的 Flickr新賬號了。單個(gè)用戶的遷移并不需要很長時(shí)間，但用戶量很大，所以還是花了不少時(shí)間。遷移過程基本上就是一個(gè)大規(guī)模的異步過程，每個(gè)異步過程包括創(chuàng)建Flickr新賬號和批量上載照片。

由于知道遷移要消耗多少存儲(chǔ)、“有機(jī)”(非遷移)增長要消耗多少存儲(chǔ)，即使估計(jì)不足的話，也可以預(yù)測出還能夠支持的天數(shù)。我們下了一個(gè)龐大的訂單，來購買存儲(chǔ)，并開始計(jì)時(shí)。確認(rèn)了發(fā)貨和安裝日期，這樣我們就知道這些存儲(chǔ)什么時(shí)候能夠在數(shù)據(jù)中心上架以及需要多久才能投入使用。

因?yàn)槭褂?nbsp;Ganglia采集數(shù)據(jù)，3行腳本代碼就可以計(jì)算出存儲(chǔ)的消耗率，然后將這個(gè)數(shù)字傳給負(fù)責(zé)遷移的API進(jìn)程。照片是存儲(chǔ)在分布于美國各地的若干個(gè)數(shù)據(jù)中心的，要確保API進(jìn)程能夠遠(yuǎn)程獲得這個(gè)值，并檢查正在遷移數(shù)據(jù)的所有數(shù)據(jù)中心。我們修改了API的處理過程，以便觀察存儲(chǔ)消耗的速率。如果在過去的一小時(shí)存儲(chǔ)的消耗率大于維持到新存儲(chǔ)上線那天的消耗率，則降低對排隊(duì)等待遷移的賬號的處理速度，反之，則加快處理速度。前面列出的步驟中，我們在步驟2和步驟3之間插入了一個(gè)檢查當(dāng)前存儲(chǔ)消耗率的步驟。

因?yàn)槲覀儠?huì)根據(jù)存儲(chǔ)的消耗率調(diào)整遷移的速度，進(jìn)入隊(duì)列的賬號可能會(huì)等待更長的時(shí)間。減慢處理過程也是一個(gè)不得已的折中，既要保證遷移的順利進(jìn)行，又要不影響 Flickr的當(dāng)前業(yè)務(wù)。

最終，遷移順利完成，沒有發(fā)生存儲(chǔ)空間用光的情況。事后看來，我們的估計(jì)是有偏差的，但并沒有當(dāng)初想的那么大。遷移開始時(shí)的高峰使我們擔(dān)心存儲(chǔ)會(huì)用光，所以馬上部署了更多的存儲(chǔ)。但隨著漸漸接近原來的存儲(chǔ)極限，進(jìn)入遷移隊(duì)列的用戶也慢慢減少了

這個(gè)故事說明，將分布在全國多個(gè)地點(diǎn)的網(wǎng)站建設(shè)測量數(shù)據(jù)采集系統(tǒng)納入反饋循環(huán)，能夠?qū)B級照片數(shù)據(jù)從 Yahoo! Photos安全地遷移到 Flickr，同日時(shí)基本不影響兩者的正常使用。