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

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

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

還有一些公司會(huì)使用他們自己的大數(shù)據(jù)。他們擁有自己的產(chǎn)品，他們會(huì)通過(guò) Hadoop 和 Spark 來(lái)做一些機(jī)器學(xué)習(xí)，從而生成針對(duì)客戶的產(chǎn)品推薦。

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

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

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

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

盡管這是一項(xiàng)巨大的工程，但我們?nèi)匀粚?duì)其感到興奮，因?yàn)樗鼘⒏淖?L 的開(kāi)發(fā)體驗(yàn)，讓我們可以用前所未有的速度將可擴(kuò)展的、可靠的產(chǎn)品推向市場(chǎng)。

L 一覽

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

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

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

我們的基礎(chǔ)設(shè)施非常繁忙，每天有超過(guò) 10 萬(wàn)個(gè) YARN 應(yīng)用在運(yùn)行，讀寫(xiě)量超過(guò) 13 個(gè) PB/ 天，以及超過(guò) 80% 的系統(tǒng)利用率：

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

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

盡管我們?cè)?AWS 運(yùn)行了一些與國(guó)際團(tuán)隊(duì)和像素服務(wù)器相關(guān)的服務(wù)，但如此大的工作任務(wù)仍然用盡了本地?cái)?shù)據(jù)中心的硬件資源。

上云

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

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

因此，到 2017 年底，我們開(kāi)始認(rèn)真地評(píng)估云服務(wù)供應(yīng)商，并開(kāi)始把 L 想象成一家云原生技術(shù)公司。

為什么選擇 GCP？

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

• 技術(shù)
• 人

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

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

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

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

總結(jié)

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

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