雲原生or本地？一家全球6大數據中心企業的大數據架構選型

當咱們討論一家企業的大數據技術架構選型時，一般會涉及幾大指標：可用性、可靠性、性能和成本。近幾年，隨着雲計算的發展，咱們也會加上雲原生服務。其中，有些指標是與業務場景緊密相關的，好比可用性和可靠性；有些指標則與企業決策相關，好比成本和性能之間的平衡。FreeWheel是一家跨全球有六大數據中心的高端視頻廣告管理技術和服務提供商，這樣一家面對跨區域、高可用、高容災業務場景的企業，其大數據架構選型的前、中、後期是如何進行的呢？

 

（FreeWheel）

 

FreeWheel公司總部位於美國硅谷，在紐約、舊金山、芝加哥、倫敦、巴黎、北京等地分別設有分支機構。其中，FreeWheel北京分公司做爲全球研發中心，負責公司核心產品研發。從最初的C++、手寫ETL流程到如今大數據平臺、容器化和雲服務，FreeWheel架構師張磊揭示了選型先後的心路歷程。

 

 

（FreeWheel架構師張磊）

 

 

選型前——架構和成本的評估

 

關於技術選型，FreeWheel一直但願在可用性、成本（包括學習成本，運營成本和維護成本）和性能之間尋求平衡。而即便已經完成了技術選型，在遷移現有平臺至AWS這類雲服務時一樣要從新考慮這些因素。其緣由一是自建機房的那一套解決方案可能並不適合原樣照搬到雲平臺上；二是雲服務提供商自己提供了不少託管的解決方案，孰優孰劣還須要從新評估。

 

對企業而言，一個好的架構首先要能知足當前的業務需求，其次是可以根據業務和技術的發展，具備可持續改造和升級的能力。技術選型時，架構師須要評估接下來一段時間內的業務發展規模及需求，根據團隊的技術積累和技術方向，學習調研各類可能的解決方案是否可以並適合解決當前面臨的問題。同時，再好的架構也不可能一蹴而就，一勞永逸。因此在平常工做中還須要不斷探尋是否存在更有效的方案，從而對架構進行升級。

 

對於具體的技術實現，以開源技術組件爲例，架構師須要考慮的方面包括組件的成熟度是否合適，社區是否活躍，同時須要考慮新技術的學習成本、遷移成本和運營成本是否能夠承擔等等。而對於雲服務遷移來講，還面臨着雲服務生態等更多須要考慮的因素。畢竟一家企業在選定某個雲服務平臺之後，再更換的成本將是很是巨大的。

 

搭建中——成本or性能？

 

一旦前期技術選型基本肯定，中期的主要工做就是具體實施，但在實施的過程當中每每仍是會遇到一些現實的問題。

 

以FreeWheel的大數據平臺爲例，雖然FreeWheel目前幾乎全部的數據處理均在AWS上完成，可是在設計伊始，考慮到在一段時間內整個平臺還會是自建機房和AWS上共存的局面，以及一些關鍵的性能評估，咱們在AWS上選用了與自建機房相似的基於Hadoop, HBase，Kafka和Presto的解決方案。

 

即使是這種看似無縫的遷移，在實際構建過程當中，仍是遇到了不少棘手的問題。以高可用的設計爲例，AWS由於涉及到自身就高可用服務、可用區、區域這些概念，加上跨可用區/跨區域收費這樣的額外成本，在其中的高可用設計和在自建機房可能會有區別。這就須要在具體實施中根據業務的特色設計出儘量平衡可用性，成本和性能的解決方案。

 

 

（FreeWheel大數據平臺架構簡圖）

 

首先，咱們會盡可能利用AWS高可用的原生服務，這是最簡單也是十分有效的手段。例如使用EBS做爲Kafka的存儲介質。這樣即便Kafka Broker所在的物理機出現故障，其數據仍是能夠恢復的。

 

而對於Zookeeper、Kafka Broker、HBase等服務，須要根據其自身不一樣特性作分別處理。其中，由於Zookeeper的體量和數據交換都比較小，能夠直接採用相似三可用區五副本的方案解決。

   

Kafka Broker相對來講會複雜一些。若是單純爲了高可用將Kafka都部署成三可用區五副本固然是能夠的。須要考慮的是AWS的跨可用區數據傳輸是收費的。這個收費看起來可能不貴，但考慮到寫內容時Kafka內部要作副本的數據同步，而客戶端讀取內容的時候也是無差異的跨可用區讀取，對於處理海量消息來講，數據傳輸成本就會成爲不得不考慮的因素了。

 

基於此，FreeWheel對Kafka上處理的業務進行了分級處理，保證像花費反饋這類關鍵任務徹底的高可用，而對數據量較大或對可靠性要求能夠適度放寬的業務（好比一些離線業務），作了主從更改。默認狀況下，應用和leader會在同一可用區，而且只從這個可用區讀取數據，在節省傳輸開銷的同時提高性能。而一旦某個或某些leader發生故障，系統能夠自動切換至另外一可用區，保證服務繼續。

 

在HBase層面，咱們在一開始也準備效仿Kafka的實現方式。但通過反覆試驗，仔細權衡了傳輸開銷和運營維護成本以後，決定對HBase使用兩個可用區的無差異化處理的解決方案。

 

遷移上雲後——雲原生or本地？

 

現在，國內外可提供雲平臺的廠商不在少數，企業勢必會面臨一個選擇——究竟是選用雲服務廠商已經構建好的服務仍是選擇在雲上自行搭建？基於FreeWheel在AWS上經驗，張磊認爲，對於沒有歷史包袱的企業，或者說對於數據量不是很大，業務不是很複雜的企業，能夠考慮直接上雲並根據業務特色和數據量儘量地使用原生服務，由於這樣能夠提升效率而且下降運維成本。而對於已有技術棧和技術積累的企業而言，若是肯定要往雲端遷移，須要綜合考慮雲上解決方案，爭取最大化雲服務的價值。

 

選型後——總結調整

 

當平臺已經搭建完成，架構師還須要作的工做就是總結調整，適時迭代。FreeWheel在接下來一段時間傾向於持續性改進和局部優化。例如，咱們仍是會堅持以Presto爲核心組件的查詢引擎，可是會不斷調研實踐，以改進其性能。

   

綜上，FreeWheel在集成了全球90多個服務器端，6大數據中心，日均10億日誌的場景下，保障了業務的高效運行。

 

  文章轉載自 IT168