據(jù)統(tǒng)計，互聯(lián)網(wǎng)數(shù)據(jù)量正以每三年翻一番的速度膨脹，其中，95%以上都是非結(jié)構(gòu)化數(shù)據(jù)，且這個比例仍在不斷提升。如今，互聯(lián)網(wǎng)已全面覆蓋大家生活的方方面面，每個人的消費行為、娛樂行為和社交行為都將產(chǎn)生海量的圖片、音視頻、網(wǎng)絡日志等非結(jié)構(gòu)化數(shù)據(jù)。非結(jié)構(gòu)化數(shù)據(jù)的持續(xù)在線及數(shù)據(jù)種類的多樣對數(shù)據(jù)的處理提出了很高的要求。作為國內(nèi)最專業(yè)的數(shù)據(jù)管理平臺，七牛已覆蓋國內(nèi)50%以上的互聯(lián)網(wǎng)用戶。那么，七牛數(shù)據(jù)處理架構(gòu)都經(jīng)過了哪些演變呢？小編帶你一探究竟。
　　七牛云存儲的數(shù)據(jù)處理主要分為實時處理和異步處理，對于較小的文件（如圖片），一般推薦使用實時處理的方式。
　　對于實時處理，用戶可簡單通過URL對已有的文件進行實時處理。當用戶將文件上傳到七牛KODO對象存儲平臺，會得到相應的key，可通過URL訪問。例如http://xxx.com/key，當需要對該文件進行實時處理時，可以通過http://xxx.com/key？////…………進行處理。具體操作參數(shù)可以參考七牛官方文檔。參數(shù)過多過長時可以設(shè)置樣式，若涉及操作復雜多變可以采用管道技術(shù)。
　　異步請求可以通過Portal、命令行工具、SDK發(fā)起請求。一般適合處理較大文件，比如較大的音視頻，這種情況下實時響應的效果并不理想，則可以采用異步持久化處理方式，返回的結(jié)果是處理后的文件在七牛云存儲中的相關(guān)元信息（bucket、key等），用戶可以通過設(shè)置回調(diào)服務器地址，將結(jié)果Post到自己的接收服務器，也可以主動查詢數(shù)據(jù)處理狀態(tài)和結(jié)果信息。
　　
　　上圖描述了簡單的實時處理的基本架構(gòu)，用戶可以通過七牛云存儲的I/O入口發(fā)起請求，判斷出是合法的數(shù)據(jù)處理請求后，就會將其傳給數(shù)據(jù)處理調(diào)度服務，通過調(diào)度分發(fā)給計算處理集群。每個worker處理的流程為參數(shù)檢查-》下載數(shù)據(jù)-》結(jié)合原數(shù)據(jù)信息對參數(shù)進行檢查（若數(shù)據(jù)的相關(guān)信息不需要download下來就可以獲取，那么可以和前面的步驟對調(diào)）-》自己編寫算法實現(xiàn)或者調(diào)用工具對數(shù)據(jù)進行處理，比如轉(zhuǎn)碼、圖像縮略等操作-》結(jié)果返回（異步請求一般會持久化保存，通過對象存儲服務，將結(jié)果上傳，得到文件上傳后的相關(guān)信息，例如bucket、key等，返回的是文件的相關(guān)信息）。這里可以簡單的把數(shù)據(jù)處理調(diào)度看做負載均衡器，請求根據(jù)接口判斷，通過調(diào)度指向?qū)?，然后將結(jié)果原路返回給用戶。
　　上面的結(jié)構(gòu)簡單清晰，但同時面臨幾個問題：
　　1.數(shù)據(jù)處理調(diào)度這個服務相對比較重，它不僅僅需要實現(xiàn)負載均衡，還需要對所有處理終端服務進行管理，單臺計算型服務器上可能有多個服務worker（多個圖片處理、音視頻處理服務worker），隨著業(yè)務發(fā)展，管理的worker數(shù)量是非常多的。
　　2.內(nèi)部實現(xiàn)緩存機制，使得讀寫緩存的流量全部集中在數(shù)據(jù)處理調(diào)度這個服務
　　3.數(shù)據(jù)的處理離不開原數(shù)據(jù)，一般我們可以在worker中待前面的步驟順利通過后，調(diào)用七牛的對象存儲服務開始下載，那么每個worker都必須配置對象存儲服務的地址信息，然后才能download原數(shù)據(jù)，這套地址信息對所有worker都是共用的。前面提到1臺物理機器上可能有多個服務worker，每個worker自身有不同的屬性參數(shù)（最起碼端口號不同），而且可能機器上的服務worker有Image Worker也有Video Worker，共用一套配置顯然不能滿足，若每個worker都將這些普遍共用的信息寫入配置，那么維護起來非常不方便。因此，七牛的數(shù)據(jù)處理架構(gòu)有了一些演變，就有了如下的架構(gòu)。
　　
　　首先，將Data Cache獨立出來，理由非常簡單，在很多環(huán)節(jié)都需要緩存服務，并且根據(jù)緩存數(shù)據(jù)大小、熱度選擇是SSD或者HDD進行緩存，小文件且熱度高適合SSD，大文件且熱度較低適合HDD。
　　其次，為每臺服務器添加了Agent服務。一臺服務器可能有多個worker且可能是不同種的worker，數(shù)據(jù)處理調(diào)度服務只需要知道該請求的對應worker存在于哪些機器即可，剩下的判斷則交由agent處理。因為整個計算集群的服務器存在性能差異，采用權(quán)重輪詢調(diào)度，這時某個worker對應所在的機器一目了然，也不需要對worker整體標記序號，只需要知道某臺服務器有哪些worker。Agent可以承擔download原數(shù)據(jù)的責任，相當于提取各個worker的一些公共操作都可以都交給Agent，同時，Agent分擔了向Data Cache寫入數(shù)據(jù)的任務。
　　值得一提的是，對于返回失敗的數(shù)據(jù)也可以緩存。假如請求量巨大，每天100億條請求，確認是客戶端請求信息不當?shù)腻e誤約占5%，那么就有5億錯誤請求，即使服務迭代升級，也會保持原有接口功能不變。那么，若是同一個文件的同一個錯誤請求，基本上必然重現(xiàn)，這樣的請求實際上就可以被緩存，一來用戶那邊獲得快速響應，二來減少計算壓力而且減少拖取數(shù)據(jù)的流量。后來發(fā)現(xiàn)這個方案存在一個瑕疵，就是給Data Cache造成的壓力略微變大，且有部分錯誤請求響應并沒有加快，至少為了獲得緩存數(shù)據(jù)而讀盤會有時間消耗。先前worker的設(shè)計是檢查參數(shù)是否合法-》download數(shù)據(jù)-》結(jié)合原數(shù)據(jù)信息檢查參數(shù)是否合法。這里我們對錯誤請求做了細化，單獨屏蔽了download數(shù)據(jù)之前所產(chǎn)生的錯誤請求，因為這部分響應非?？?，本身也沒有多少計算，無需寫入緩存。
　　最后，通過Discover服務來監(jiān)控服務情況的變化，所有的Agent和Worker都需要向Discover上報心跳狀態(tài)，Load Balancer會從Discover讀取各個服務狀態(tài)、服務相關(guān)信息（地址、權(quán)重等），同時允許人工通過Discover修改各個服務的狀態(tài)。
　　異步請求的架構(gòu)，則是在整個實時處理架構(gòu)前面加上異步隊列服務、異步請求狀態(tài)服務等，每個worker的處理結(jié)果需要持久化，返回的是結(jié)果文件持久化保存后的相關(guān)信息。
　　現(xiàn)在的整個數(shù)據(jù)處理架構(gòu)，看上去中規(guī)中矩，同時也存在一些弊端，即使做到了可以對單條請求大致消耗資源的預估，經(jīng)過多次數(shù)據(jù)回滾壓力測試以及峰值比對確定一臺服務器應該部署多少個worker，實現(xiàn)較為合理的調(diào)度，但機器上的worker數(shù)量基本上是固定的，無法跨機器實現(xiàn)彈性的實時調(diào)度，服務器的資源仍然不能充分利用。例如，當實時處理服務的機器在非峰值階段，可以將異步請求的服務worker遷移到該機器上，分擔一部分任務，使得每臺機器的負載較為均衡；當實時請求到達峰值的時候，可以遷移部分worker到處理公有隊列異步請求的機器（付費的私有隊列用戶不受影響），分擔部分壓力

普通下載普通下載

相關(guān)電子資料下載