快手廣告如何在保障跨IDC容災能力的前提下，還能降低50%存儲成本？

如何在保障跨IDC容災能力的前提下，還能降低50%存儲成本？

快手經歷了10年的(de)高速發展，存儲了大(da)量(liang)的(de)視(shi)頻數(shu)據，存儲成本(ben)非常高，需要對對象(xiang)數(shu)據進(jin)行治理，在保障跨(kua)IDC容災的(de)前(qian)提下，降低50%存儲成本(ben)。本(ben)文(wen)主要從三個層面，介紹整個項目(mu)的(de)設計與落(luo)地(di)過(guo)程：快手對象(xiang)存儲架(jia)構(gou)；快手對象(xiang)存儲跨(kua)IDC EC架(jia)構(gou)設計階段(duan)；快手對象(xiang)存儲跨(kua)IDC EC架(jia)構(gou)落(luo)地(di)階段(duan)。

一、快手廣告推廣對象存儲架構

如圖(tu)所示，整個(ge)架構的(de)(de)核(he)心思想是：通過(guo)HBase存(cun)(cun)(cun)(cun)放對象(xiang)索引，多個(ge)對象(xiang)數(shu)據(ju)合并(bing)后，以大文件的(de)(de)形式存(cun)(cun)(cun)(cun)放在(zai)HDFS上，同(tong)時使用MemoryCache作(zuo)為緩存(cun)(cun)(cun)(cun)層(ceng)，緩存(cun)(cun)(cun)(cun)熱點(dian)對象(xiang)數(shu)據(ju)，避免直接(jie)對底層(ceng)存(cun)(cun)(cun)(cun)儲(chu)的(de)(de)沖擊(ji)。除此之外，整個(ge)架構是通過(guo)雙(shuang)AZ四副本的(de)(de)形式，實現跨AZ容災；讀取(qu)時，通過(guo)AZ親和性(xing)策(ce)略，優先選擇(ze)本AZ集群進(jin)行數(shu)據(ju)讀取(qu)，Miss或者(zhe)失(shi)敗后，再(zai)回落(luo)到遠端AZ集群讀取(qu)。快手(shou)經歷了(le)10年高(gao)速發展，目前已經擁有幾(ji)EB存(cun)(cun)(cun)(cun)量數(shu)據(ju)，幾(ji)PB日增量數(shu)據(ju)，對象(xiang)存(cun)(cun)(cun)(cun)儲(chu)的(de)(de)成本非常高(gao)，需要對對象(xiang)存(cun)(cun)(cun)(cun)儲(chu)進(jin)行數(shu)據(ju)治理，在(zai)保(bao)障跨IDC容災的(de)(de)能力下，降(jiang)低50%存(cun)(cun)(cun)(cun)儲(chu)成本。接(jie)下來的(de)(de)篇(pian)幅，重點(dian)介紹下，為了(le)實現這個(ge)目標，我們都做了(le)哪些(xie)事情(qing)。

二、快手廣告投放整體方案選擇

降低(di)(di)存(cun)儲(chu)(chu)成本(ben)的方法有很多，綜(zong)合考慮后，以下三大類方法比較match場景：刪除(chu)無用(yong)對象(xiang)數(shu)(shu)(shu)據(ju)(ju)；降低(di)(di)對象(xiang)數(shu)(shu)(shu)據(ju)(ju)副本(ben)冗余(yu)度；采(cai)用(yong)低(di)(di)成本(ben)存(cun)儲(chu)(chu)介(jie)質存(cun)放對象(xiang)數(shu)(shu)(shu)據(ju)(ju)。由于目前(qian)整個(ge)(ge)架構是通過雙AZ四(si)副本(ben)實現的跨AZ容災(zai)，所以準備采(cai)用(yong)數(shu)(shu)(shu)據(ju)(ju)EC處理，來(lai)降低(di)(di)對象(xiang)數(shu)(shu)(shu)據(ju)(ju)副本(ben)冗余(yu)度。也就是，我(wo)們準備采(cai)用(yong)數(shu)(shu)(shu)據(ju)(ju)EC技(ji)術和(he)歸檔(dang)存(cun)儲(chu)(chu)的方式，在(zai)Hot存(cun)儲(chu)(chu)層的基礎上(shang)，引入低(di)(di)成本(ben)存(cun)儲(chu)(chu)層，進一步完(wan)善整個(ge)(ge)對象(xiang)存(cun)儲(chu)(chu)架構。通過數(shu)(shu)(shu)據(ju)(ju)“熱 -> 溫(wen) -> 冷(leng)”的逐級流轉，實現降低(di)(di)對象(xiang)存(cun)儲(chu)(chu)成本(ben)的效果。

經過對(dui)數(shu)(shu)(shu)據的(de)(de)熱度分析后，發現(xian)：數(shu)(shu)(shu)據冷(leng)熱周期分明；歷史(shi)數(shu)(shu)(shu)據存(cun)在(zai)被隨機訪問的(de)(de)場景；歷史(shi)數(shu)(shu)(shu)據訪問時延有一定(ding)要(yao)求。所以我們決定(ding)第一階段的(de)(de)主要(yao)工作，集中在(zai)：實現(xian)一套(tao)功能完備的(de)(de)EC Warm低成本存(cun)儲層。通過數(shu)(shu)(shu)據“熱 -> 溫(wen)”的(de)(de)自動流(liu)轉(zhuan)，實現(xian)保持跨AZ/IDC容災的(de)(de)前提(ti)下(xia)降低50%存(cun)儲成本的(de)(de)大目(mu)標。

三、快手對象存儲 跨IDC EC架構設計階段

先來看下，在(zai)架構設計階段，我們需(xu)要(yao)做哪些(xie)抉擇(ze)。

1.EC算法選擇

在算法選(xuan)擇時，由于是對(dui)象存儲，對(dui)數據重構(gou)代價要求(qiu)比較高；同時又需要具備跨AZ/IDC容(rong)災能力(li)(li)，對(dui)容(rong)災能力(li)(li)要求(qiu)也比較高。綜合考(kao)慮后，我們(men)決定采用LRC算法，作為(wei)整個EC Warm架構(gou)的主算法。但是LRC算法的參數應該如何設置呢？

2.LRC算法參數確定(ding)

LRC算法的容災能(neng)力和RS算法一樣，所以我們主要(yao)通過RS(n + m)來推(tui)到下LRC算法的具體參數(shu)(shu)：假設：最少有 X 個(ge)(ge)IDC實現容災；每(mei)個(ge)(ge)IDC內(nei)均勻散列Block。要(yao)求：任何一個(ge)(ge)IDC故障(zhang)，數(shu)(shu)據都可修復；RS數(shu)(shu)據重構(gou)成本盡(jin)可能(neng)低；任意一個(ge)(ge)IDC故障(zhang)后，還可以容忍其余(yu)IDC各自壞掉一個(ge)(ge)Block；副本冗余(yu)度 <= 200%。中間推(tui)導：每(mei)個(ge)(ge)IDC內(nei)存放 (n + m)/x 個(ge)(ge)Block；每(mei)個(ge)(ge)IDC最多存放m個(ge)(ge)Block。

經過推(tui)導后，我們發現(xian)(xian)，下面兩種算(suan)法，比較(jiao)滿(man)足(zu)場景要求。LRC(6 + 3 + 3)；LRC(6 + 2 + 4)。通過局部(bu)修復(fu)數(shu)據壓測(ce)，以及結合目前(qian)IDC個(ge)數(shu)現(xian)(xian)狀，所以，我們準(zhun)備(bei)采用(yong)LRC(6 + 3 + 3)算(suan)法，即：6個(ge)source block，產生3個(ge)全局校(xiao)驗(yan)(yan)(Global Parity)塊和3個(ge)局部(bu)校(xiao)驗(yan)(yan)塊(Local Parity)，支(zhi)持跨IDC容災，且能降(jiang)低(di)50%副本冗余度。

3.EC塊布(bu)局方式選擇

數據(ju)(ju)(ju)EC塊(kuai)(kuai)布局方式(shi)選擇，直接影響整(zheng)個項(xiang)目(mu)落(luo)地的風險(xian)和難(nan)度，所以(yi)也是至關重(zhong)要(yao)的。結合現狀：溫數據(ju)(ju)(ju) + HDFS大(da)文件 + IOPS要(yao)求偏高 + CDH HDFS版(ban)本，所以(yi)我們(men)決定(ding)采用(yong)連續(xu)塊(kuai)(kuai)布局方式(shi)。也就是整(zheng)個的EC Warm架(jia)構，采用(yong)LRC(6 + 3 + 3)算法(fa)，在(zai)穩定(ding)的HDFS內核版(ban)本基礎之上，封裝一層功能完備的數據(ju)(ju)(ju)EC和數據(ju)(ju)(ju)重(zhong)構流程，在(zai)實現大(da)目(mu)標的同時，盡(jin)可能的降低風險(xian)。

4.EC Warm架構(gou)層(ceng)面跨IDC容(rong)災能力

通過(guo)上面EC算法和塊(kuai)布(bu)局(ju)方式(shi)的抉擇后，我們只需(xu)要將ZK、Journal、DN、Active NN、Standby NN散(san)列在(zai)不同的IDC內，就可以(yi)實現EC Warm架(jia)構層面的跨IDC容災能(neng)力，在(zai)某個(ge)IDC故障后，整個(ge)架(jia)構可以(yi)自愈。除此之外(wai)，整個(ge)架(jia)構：通過(guo)Router + ObserverNN組合，提(ti)升架(jia)構主(zhu)節點讀吞吐功能(neng)。

四、快手對象存儲 跨IDC EC架構落地階段

確(que)定大方向后，我們(men)再來(lai)看(kan)下，為了實現一套功能完備的(de)EC Warm低成本(ben)存儲層，我們(men)還(huan)需(xu)要解決哪些問題。

1.數據EC流程

首先(xian)我們需要一套智能(neng)的數據(ju)“熱 -> 溫”轉換(huan)流(liu)程，如(ru)圖所(suo)示，在整(zheng)個(ge)流(liu)程中(zhong)，有(you)幾點(dian)相對(dui)比較重(zhong)要：將LRC算法調度到文(wen)(wen)件(jian)所(suo)在Hot集群上，可以避免讀取Source時(shi)產生跨(kua)IDC流(liu)量(liang)；添加統一跨(kua)IDC流(liu)量(liang)控制模(mo)塊(kuai)，嚴格控制數據(ju)轉換(huan)流(liu)程中(zhong)對(dui)跨(kua)IDC帶寬的影響；LRC算法同(tong)時(shi)輸出Source和(he)Parity，嚴格保障(zhang)一個(ge)Stripe 12個(ge)Block的塊(kuai)放(fang)置策(ce)略；Global Parity 和(he) Local Parity按照固定次序(xu)，存(cun)放(fang)在同(tong)一個(ge)Parity文(wen)(wen)件(jian)中(zhong)，并且通過(guo)文(wen)(wen)件(jian)前(qian)綴與Source文(wen)(wen)件(jian)進行匹(pi)配，簡化索引信息。同(tong)時(shi)，我們調整(zheng)了一個(ge)Stripe 12個(ge)Block的布局方(fang)式，為了在滿足跨(kua)IDC容災(zai)的前(qian)提(ti)下(xia)，盡可能(neng)均衡IDC間(jian)的流(liu)量(liang)，如(ru)圖所(suo)示：

2.數據Fixer流程

其(qi)次，我(wo)們還需要(yao)一(yi)套智能的(de)數(shu)(shu)據(ju)重(zhong)構流程，重(zhong)點介紹下(xia)LRC算法的(de)重(zhong)構實現(xian)。LRC(6 + 3 + 3)算法在(zai)進(jin)行數(shu)(shu)據(ju)重(zhong)構時，按(an)照先局(ju)(ju)部、再(zai)全局(ju)(ju)、再(zai)局(ju)(ju)部的(de)思想，將12個(ge)塊分成(cheng)(cheng)7層(ceng)。優先使用局(ju)(ju)部修(xiu)(xiu)復(fu)；局(ju)(ju)部無法修(xiu)(xiu)復(fu)時，再(zai)進(jin)行全局(ju)(ju)修(xiu)(xiu)復(fu)；當全局(ju)(ju)修(xiu)(xiu)復(fu)完(wan)成(cheng)(cheng)后，再(zai)進(jin)行一(yi)輪局(ju)(ju)部修(xiu)(xiu)復(fu)。為了最小化LRC數(shu)(shu)據(ju)重(zhong)構成(cheng)(cheng)本，Stripe數(shu)(shu)據(ju)重(zhong)構時，最好能在(zai)第一(yi)輪局(ju)(ju)部修(xiu)(xiu)復(fu)就完(wan)成(cheng)(cheng)。所以，期(qi)望在(zai)IDC內，任何一(yi)層(ceng)設備出現(xian)故(gu)障時，只出現(xian)一(yi)個(ge)塊丟(diu)失，從而(er)保障局(ju)(ju)部可修(xiu)(xiu)復(fu)。

3.數據塊放置策略

一(yi)(yi)個(ge)Stripe 12個(ge)Block除了跨IDC散(san)列(lie)之外，IDC內(nei)部四(si)個(ge)Block也要(yao)散(san)列(lie)到(dao)不同的(de)Domain、Tor、Rack、DN、Disk上(shang)，從而實現IDC內(nei)任何一(yi)(yi)層設備出現故障時(shi)，只(zhi)出現一(yi)(yi)個(ge)MissingBlock，都可局(ju)部修復。為(wei)了嚴格(ge)保障這樣的(de)塊放置(zhi)策略，需(xu)要(yao)完成以(yi)下幾個(ge)功能：NN需(xu)要(yao)支(zhi)持邏輯(ji)UpgradeDomain概念(nian)，從而加速(su)Decommission和Balance速(su)度；NN需(xu)要(yao)支(zhi)持LRC BlockPlacement Policy，將12個(ge)塊按照(zhao)四(si)個(ge)為(wei)一(yi)(yi)組(zu)分(fen)成4組(zu)。分(fen)配DN時(shi)，組(zu)間(jian)跨IDC、組(zu)內(nei)散(san)列(lie)在不同的(de)Domain；數(shu)(shu)據(ju)(ju)EC時(shi)，一(yi)(yi)次性向NN申(shen)請一(yi)(yi)個(ge)Stripe 的(de) Block，然(ran)后(hou)按照(zhao)對應(ying)關系，將EC后(hou)數(shu)(shu)據(ju)(ju)，寫到(dao)對應(ying)的(de)DN上(shang)；數(shu)(shu)據(ju)(ju)Fixer時(shi)，按照(zhao)當前DN的(de)情(qing)況，向NN申(shen)請滿足放置(zhi)條件(jian)的(de)DN，將Fixer后(hou)的(de)數(shu)(shu)據(ju)(ju)，寫到(dao)對應(ying)的(de)DN上(shang)。通過(guo)每個(ge)數(shu)(shu)據(ju)(ju)變更環節，強保障Stripe塊的(de)放置(zhi)策略，從而可以(yi)最小(xiao)化(hua)Stripe 數(shu)(shu)據(ju)(ju)重構代價。

4.數據正確性保障

接下來，我們再來看(kan)一個問(wen)題：如何保障(zhang)轉換(huan)前后，數據(ju)(ju)正確性(xing)問(wen)題？在數據(ju)(ju)轉換(huan)過(guo)程中，可(ke)能存在諸如：磁盤(pan)故(gu)障(zhang)、內存故(gu)障(zhang)、網絡(luo)異(yi)常、程序(xu)BUG、未知異(yi)常等各種異(yi)常，導(dao)致(zhi)數據(ju)(ju)轉換(huan)后，數據(ju)(ju)異(yi)常。所以保障(zhang)數據(ju)(ju)轉換(huan)前后正確性(xing)，是至(zhi)關重要的。

為(wei)(wei)了(le)保(bao)障(zhang)數(shu)(shu)據(ju)(ju)正(zheng)確性(xing)，我們做了(le)以(yi)下幾件(jian)(jian)事(shi)情(qing)。數(shu)(shu)據(ju)(ju)EC階(jie)段：LRC算法EC時，將產出的(de)(de)(de)中(zhong)(zhong)間臨時數(shu)(shu)據(ju)(ju)，并發的(de)(de)(de)寫(xie)到(dao)HDFS上；LRC算法完(wan)成(cheng)后(hou)(hou)，通(tong)過(guo)HDFS Concat操作(zuo)，將HDFS 臨時文(wen)(wen)件(jian)(jian)合并成(cheng)最(zui)終的(de)(de)(de)Source文(wen)(wen)件(jian)(jian)和Parity文(wen)(wen)件(jian)(jian)；按照(zhao)Block粒(li)度，計算Source文(wen)(wen)件(jian)(jian)和Parity文(wen)(wen)件(jian)(jian)的(de)(de)(de)對(dui)(dui)應Block的(de)(de)(de)CRC，并記錄到(dao)HBase中(zhong)(zhong)，供Fixer數(shu)(shu)據(ju)(ju)重構時使用。為(wei)(wei)了(le)保(bao)障(zhang)數(shu)(shu)據(ju)(ju)EC后(hou)(hou)，HBase內(nei)Block對(dui)(dui)應CRC的(de)(de)(de)正(zheng)確性(xing)，尤(you)其是Parity Block CRC的(de)(de)(de)正(zheng)確性(xing)，在EC完(wan)成(cheng)后(hou)(hou)，又添加(jia)了(le)完(wan)備的(de)(de)(de)Checker流(liu)程，通(tong)過(guo)模擬局部修復(fu)、全局修復(fu)流(liu)程，強保(bao)障(zhang)Local Parity和Global Parity的(de)(de)(de)正(zheng)確性(xing)，從(cong)而保(bao)障(zhang)HBase內(nei)Block對(dui)(dui)應CRC的(de)(de)(de)正(zheng)確性(xing)。數(shu)(shu)據(ju)(ju)Fixer階(jie)段：LRC算法進行(xing)數(shu)(shu)據(ju)(ju)重構時，中(zhong)(zhong)間臨時數(shu)(shu)據(ju)(ju)直接寫(xie)到(dao)HDFS上；通(tong)過(guo)類Transfer的(de)(de)(de)流(liu)程，將HDFS中(zhong)(zhong)文(wen)(wen)件(jian)(jian)數(shu)(shu)據(ju)(ju)，端(duan)到(dao)端(duan)的(de)(de)(de)寫(xie)到(dao)對(dui)(dui)應DN；Transfer最(zui)后(hou)(hou)階(jie)段，完(wan)成(cheng)CRC校驗后(hou)(hou)，再Finalize Block。通(tong)過(guo)以(yi)上各階(jie)段的(de)(de)(de)工作(zuo)，從(cong)而保(bao)障(zhang)變更前(qian)后(hou)(hou)，數(shu)(shu)據(ju)(ju)的(de)(de)(de)正(zheng)確性(xing)。

5.索引一致性

由于EC Warn集(ji)群中，Parity文(wen)(wen)件(jian)(jian)(jian)和Source文(wen)(wen)件(jian)(jian)(jian)，通過文(wen)(wen)件(jian)(jian)(jian)前綴(zhui)的(de)(de)方式(shi)進行索引(yin)(yin)匹配的(de)(de)，所以就有(you)可(ke)能(neng)存在(zai)兩個(ge)文(wen)(wen)件(jian)(jian)(jian)信息一(yi)致(zhi)性(xing)問題，比(bi)如：高(gao)級(ji)用(yong)戶誤刪(shan)除(chu)Parity文(wen)(wen)件(jian)(jian)(jian)、用(yong)戶僅改變Source文(wen)(wen)件(jian)(jian)(jian)屬性(xing)等(deng)(deng)。為了(le)解(jie)決Parity文(wen)(wen)件(jian)(jian)(jian)和Source文(wen)(wen)件(jian)(jian)(jian)索引(yin)(yin)一(yi)致(zhi)性(xing)問題，我們做了(le)以下幾件(jian)(jian)(jian)事情：回收Parity文(wen)(wen)件(jian)(jian)(jian)的(de)(de)目(mu)錄權限為admin權限；NN端(duan)捆綁Source文(wen)(wen)件(jian)(jian)(jian)和Parity文(wen)(wen)件(jian)(jian)(jian)操(cao)作(zuo)，比(bi)如：rename、delete、settime等(deng)(deng)；Source文(wen)(wen)件(jian)(jian)(jian)append時(shi)，自動提升Source副本數(shu)，并刪(shan)除(chu)對應Parity文(wen)(wen)件(jian)(jian)(jian)；除(chu)了(le)上面各個(ge)階段保(bao)障：數(shu)據(ju)高(gao)容錯性(xing)、數(shu)據(ju)變更前后正確性(xing)、索引(yin)(yin)一(yi)致(zhi)性(xing)等(deng)(deng)，還(huan)需要一(yi)個(ge)兜(dou)底服務(wu)，定期的(de)(de)掃描全量EC文(wen)(wen)件(jian)(jian)(jian)，確保(bao)各個(ge)狀態的(de)(de)正確性(xing)，以便能(neng)夠(gou)及(ji)時(shi)發現、并解(jie)決任何導致(zhi)數(shu)據(ju)丟失的(de)(de)隱患，嚴(yan)格保(bao)障數(shu)據(ju)的(de)(de)可(ke)靠性(xing)。

五、快手信息流推廣業務IO流程變化

最后(hou)，整個對象(xiang)存儲架構(gou)，引入了EC Warm低成本(ben)存儲層，通(tong)過數(shu)據(ju)“熱 -> 溫”動(dong)態流(liu)轉，實(shi)現(xian)保持跨(kua)AZ/IDC 容災的前提下，降低50%存儲成本(ben)的效(xiao)果(guo)。在取得明顯受(shou)益后(hou)，我們(men)再(zai)從(cong)業(ye)務(wu)的視角看下，整個架構(gou)的變更，對業(ye)務(wu)側(ce)的影(ying)響：數(shu)據(ju)“熱 -> 溫”轉換(huan)后(hou)，更新HBase中文件的索引信息，對業(ye)務(wu)透明；業(ye)務(wu)讀取時，自動(dong)從(cong)warm集(ji)群讀取數(shu)據(ju)；讀取Warm集(ji)群數(shu)據(ju)時，如果(guo)出現(xian)數(shu)據(ju)丟失異常，不僅(jin)會實(shi)時同步(bu)(bu)修復(fu)，還會異步(bu)(bu)周知數(shu)據(ju)重構(gou)服務(wu)，進行異步(bu)(bu)修復(fu)。

六、結尾

目前(qian)整(zheng)個(ge)架(jia)構已經上線大(da)半(ban)年時間，取得(de)幾百PB數(shu)據(ju)空間節(jie)省的收益，同時，未(wei)出(chu)現(xian)任(ren)何數(shu)據(ju)可(ke)靠性問題。當然，整(zheng)個(ge)架(jia)構還需(xu)要(yao)承載更(geng)多的數(shu)據(ju)，還需(xu)要(yao)進一步(bu)擴大(da)，現(xian)在(zai)不(bu)代表未(wei)來(lai)，我們團(tuan)隊會(hui)不(bu)忘初(chu)心，懷著敬畏之心，繼續(xu)匠心前(qian)行。

在(zai)快手投放廣(guang)(guang)告(gao)，能在(zai)短時(shi)間(jian)內聚集人氣，實現(xian)商品(pin)流量變(bian)現(xian)，提升品(pin)牌(pai)認可(ke)度，形成一個(ge)完整的(de)(de)營(ying)銷閉環，想投放快手廣(guang)(guang)告(gao)為您推薦(jian)巨(ju)宣(xuan)網絡(luo)，我們(men)有豐富的(de)(de)推廣(guang)(guang)運營(ying)的(de)(de)和推廣(guang)(guang)實戰(zhan)經驗，有需要的(de)(de)廣(guang)(guang)告(gao)主請咨詢在(zai)線(xian)客服哦！！

公司優勢

開戶流程

注意事項