文章來源：加米谷大數(shù)據(jù)

假如L 是一家大數(shù)據(jù)公司。下面我們的文章將圍繞L展開分析。

很多公司擁有大數(shù)據(jù)。每天早餐之前，健壯的日志框架就已經(jīng)生成了 PB 級別的日志，并以防萬一將這些數(shù)據(jù)長期保存在了亞馬遜的 S3 上。

還有一些公司會使用他們自己的大數(shù)據(jù)。他們擁有自己的產(chǎn)品，他們會通過 Hadoop 和 Spark 來做一些機器學習，從而生成針對客戶的產(chǎn)品推薦。

但是像 L 這樣的大數(shù)據(jù)公司就很少了。我們從客戶那里賺取的每一分錢都來自于我們的 Hadoop 處理流水線。L 的產(chǎn)品線很廣，但這些產(chǎn)品都經(jīng)由了相同的生產(chǎn)流程，即提取、轉換、加載、加入 Hadoop 處理管道。如果說今天我們關閉了 Hadoop 基礎設施，那公司也就可以直接關門停業(yè)了。

到去年為止，L 所有的大數(shù)據(jù)計算都是在本地數(shù)據(jù)中心完成的。我們的數(shù)據(jù)中心部署了一個超過 2500 節(jié)點的 Cloudera Hadoop 集群。而從今年開始，我們逐步把它們遷移到了 GCP(谷歌云計算平臺)。

Sasha Kipervarg，Patrick Raymond 和我在 Google Next 大會上展示了這次遷移之旅，包括我們從中學到的經(jīng)驗教訓，以及接下來的計劃等。在本系列博客文章中，我將從技術角度更深入地探討這次遷移，重點有：

• 在 2018 年及其以前，我們是如何在本地運營 L 大數(shù)據(jù)基礎設施的？
• 我們?yōu)槭裁匆獩Q定遷移？
• 我們希望 L 基礎設施在 GCP 上是什么樣子？
• 我們是如何實現(xiàn)的？
• 我們下一步該如何發(fā)展？

盡管這是一項巨大的工程，但我們?nèi)匀粚ζ涓械脚d奮，因為它將改變 L 的開發(fā)體驗，讓我們可以用前所未有的速度將可擴展的、可靠的產(chǎn)品推向市場。

L 一覽

L 有很多產(chǎn)品，但它們都是本著匹配客戶 CRM(客戶關系管理)以及匹配數(shù)據(jù)集的原則在不同生態(tài)系統(tǒng)之間轉移數(shù)據(jù)。我們通過批文件傳輸管道和實時的像素服務器這兩種方式將這些轉換后的數(shù)據(jù)傳輸?shù)綌?shù)字廣告生態(tài)系統(tǒng)中去。

Hadoop 生態(tài)系統(tǒng)尤其適合執(zhí)行大規(guī)模數(shù)據(jù)連接，這也是我們所使用的。我們的絕大多數(shù)硬件都用在了 Cloudera Hadoop 集群。本地集群的最大規(guī)模可達到為：

• 2500 個工作節(jié)點
• 90000 個 CPU
• 300TB 的內(nèi)存
• 100PB 的存儲

我們的基礎設施非常繁忙，每天有超過 10 萬個 YARN 應用在運行，讀寫量超過 13 個 PB/ 天，以及超過 80% 的系統(tǒng)利用率：

任何擁有 150 名工程師并且在不斷增長的公司都會面對大量的服務以及與之對應的支持基礎設施。截至 2018 年，我們使用了 500 多個由 Chef 統(tǒng)一配置管理的 VMWare 虛擬機(一個相對小一些的基于 CoreOS Tectonic 版本的 Kubernetes 集群。我們的實時鍵值服務平臺則由內(nèi)部的一個開源項目實現(xiàn)。

我們需要每天從合作伙伴處獲取文件和日志，然后將處理后的文件送還，平均數(shù)據(jù)量約為 8TB 每天，像素服務器的平均訪問量也達到了 20 萬 QPS。

盡管我們在 AWS 運行了一些與國際團隊和像素服務器相關的服務，但如此大的工作任務仍然用盡了本地數(shù)據(jù)中心的硬件資源。

上云

雖然我們對自己的基礎設施有諸多不滿，但是本著“正常工作”優(yōu)先的原則，我們一直沒有對它進行改變。但到了 2017 年中旬，我們開始意識到本地數(shù)據(jù)中心的規(guī)模已經(jīng)無法滿足我們的國際化需求。于是我們具備了所有遷移到云的一般動機：

• 規(guī)模擴展：我們需要能夠更快地擴展我們的基礎設施，而不再受限于數(shù)據(jù)中心物理設備的搭建，例如 2 個月的硬件購買時間以及更多的空間放置需求等。
• 災難恢復：我們并不滿意自己的災難恢復系統(tǒng)。我們希望在數(shù)小時內(nèi)就可以從災難性的停機狀態(tài)中恢復過來，而不是花費幾個星期從冷備份開始恢復。
• 招聘：工程師們希望能夠接觸到更重要和實用的技能，而在 2019 年，這就是著云計算。
• 開發(fā)速度：假如我們有 30% 的開發(fā)人員可以從基礎設施維護中解放出來，這意味著他們可以重新轉向產(chǎn)品開發(fā)，從而將產(chǎn)品推向市場的速度提高 30%。

因此，到 2017 年底，我們開始認真地評估云服務供應商，并開始把 L 想象成一家云原生技術公司。

為什么選擇 GCP？

我們喜歡 GCP，但我們知道它并不是默認選項。我們之所以選擇 GCP 主要有兩個驅(qū)動因素：

• 技術
• 人

技術評估并不適合放在本篇文章中，但我要強調(diào)的一點是 GKE(谷歌 Kubernetes 引擎)是一個非常關鍵的因素。本次遷移有一個很明確的方向，那就是要把所有的應用程序和服務遷移到 Kubernetes 平臺。可以粗略地講，GKE 就是 Kubernetes 領域事實上的領頭羊。

雖然我們可以選擇任意一家云供應商并最終完成遷移，但一個很大的區(qū)別就是云供應商背后的技術支持人員。GCP 把我們同那些想回答我們問題并提供解決方案的工程師很好地聯(lián)系了起來。

我們對 GCP 的技術支持合約也非常滿意。我們總是能夠與專業(yè)工程師及時取得聯(lián)系并迅速得到解決措施。這也給了我們信心，通過與 GCP 合作，我們相信可以解決任何問題，這一點都現(xiàn)在也沒有改變。

在下一篇文章中，我將討論一些大數(shù)據(jù)基礎設施遷移到 GCP 的細節(jié)，哪些方面可以直接轉換到 GCP，而哪些方面又需要重新設計。敬請期待！

總結

以上是生活随笔為你收集整理的部署到gcp_剖析大数据公司为什么选择 GCP？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。