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

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

快手經歷了10年的高速發展，存儲了大量的視頻數據，存儲成本非常高，需要對對象數據進行治理，在保障跨IDC容災的前提下，降低50%存儲成本。本文主要從三個層面，介紹整個項目的設計與落地過程：快手對象存儲架構；快手對象存儲跨IDC EC架構設計階段；快手對象存儲跨IDC EC架構落地階段。

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

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

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

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

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

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

先來看下，在架構設計階段，我們需要做哪些抉擇。

1.EC算法選擇

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

2.LRC算法參數確定

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

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

3.EC塊布局方式選擇

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

4.EC Warm架構層面跨IDC容災能力

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

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

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

1.數據EC流程

首先我們需要一套智能的數據“熱 -> 溫”轉換流程，如圖所示，在整個流程中，有幾點相對比較重要：將LRC算法調度到文件所在Hot集群上，可以避免讀取Source時產生跨IDC流量；添加統一跨IDC流量控制模塊，嚴格控制數據轉換流程中對跨IDC帶寬的影響；LRC算法同時輸出Source和Parity，嚴格保障一個Stripe 12個Block的塊放置策略；Global Parity 和 Local Parity按照固定次序，存放在同一個Parity文件中，并且通過文件前綴與Source文件進行匹配，簡化索引信息。同時，我們調整了一個Stripe 12個Block的布局方式，為了在滿足跨IDC容災的前提下，盡可能均衡IDC間的流量，如圖所示：

2.數據Fixer流程

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

3.數據塊放置策略

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

4.數據正確性保障

接下來，我們再來看一個問題：如何保障轉換前后，數據正確性問題？在數據轉換過程中，可能存在諸如：磁盤故障、內存故障、網絡異常、程序BUG、未知異常等各種異常，導致數據轉換后，數據異常。所以保障數據轉換前后正確性，是至關重要的。

為了保障數據正確性，我們做了以下幾件事情。數據EC階段：LRC算法EC時，將產出的中間臨時數據，并發的寫到HDFS上；LRC算法完成后，通過HDFS Concat操作，將HDFS 臨時文件合并成最終的Source文件和Parity文件；按照Block粒度，計算Source文件和Parity文件的對應Block的CRC，并記錄到HBase中，供Fixer數據重構時使用。為了保障數據EC后，HBase內Block對應CRC的正確性，尤其是Parity Block CRC的正確性，在EC完成后，又添加了完備的Checker流程，通過模擬局部修復、全局修復流程，強保障Local Parity和Global Parity的正確性，從而保障HBase內Block對應CRC的正確性。數據Fixer階段：LRC算法進行數據重構時，中間臨時數據直接寫到HDFS上；通過類Transfer的流程，將HDFS中文件數據，端到端的寫到對應DN；Transfer最后階段，完成CRC校驗后，再Finalize Block。通過以上各階段的工作，從而保障變更前后，數據的正確性。

5.索引一致性

由于EC Warn集群中，Parity文件和Source文件，通過文件前綴的方式進行索引匹配的，所以就有可能存在兩個文件信息一致性問題，比如：高級用戶誤刪除Parity文件、用戶僅改變Source文件屬性等。為了解決Parity文件和Source文件索引一致性問題，我們做了以下幾件事情：回收Parity文件的目錄權限為admin權限；NN端捆綁Source文件和Parity文件操作，比如：rename、delete、settime等；Source文件append時，自動提升Source副本數，并刪除對應Parity文件；除了上面各個階段保障：數據高容錯性、數據變更前后正確性、索引一致性等，還需要一個兜底服務，定期的掃描全量EC文件，確保各個狀態的正確性，以便能夠及時發現、并解決任何導致數據丟失的隱患，嚴格保障數據的可靠性。

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

最后，整個對象存儲架構，引入了EC Warm低成本存儲層，通過數據“熱 -> 溫”動態流轉，實現保持跨AZ/IDC 容災的前提下，降低50%存儲成本的效果。在取得明顯受益后，我們再從業務的視角看下，整個架構的變更，對業務側的影響：數據“熱 -> 溫”轉換后，更新HBase中文件的索引信息，對業務透明；業務讀取時，自動從warm集群讀取數據；讀取Warm集群數據時，如果出現數據丟失異常，不僅會實時同步修復，還會異步周知數據重構服務，進行異步修復。

六、結尾

目前整個架構已經上線大半年時間，取得幾百PB數據空間節省的收益，同時，未出現任何數據可靠性問題。當然，整個架構還需要承載更多的數據，還需要進一步擴大，現在不代表未來，我們團隊會不忘初心，懷著敬畏之心，繼續匠心前行。

在快手投放廣告，能在短時間內聚集人氣，實現商品流量變現，提升品牌認可度，形成一個完整的營銷閉環，想投放快手廣告為您推薦巨宣網絡，我們有豐富的推廣運營的和推廣實戰經驗，有需要的廣告主請咨詢在線客服哦！！

公司優勢

開戶流程

注意事項