大數據公司 LiveRamp 上雲記(二):哪些功能可以直接遷移,哪些需要重新設計?

踏上征途

在上一篇文章中我們討論了遷移到雲也就是GCP(谷歌雲計算平臺)的原因。一旦確定了遷移,我們就開始問自己三個問題:

  1. 我們的雲架構在第一天會是什麼樣子?雲平臺的確可以讓我們做很多令人興奮的事情,但我們究竟希望自己的MVP看起來如何呢?
  2. 我們該如何實現?構建一個全新的雲環境很容易,但是要把一個現有的基礎設施平穩遷移到雲上就沒有那麼容易了。
  3. 我們的環境在一年後又會是什麼樣子?我們知道自己的基礎設施不會在第一天就很完美,這沒關係,但我們希望會在接下來成功。

我會在這裏詳細討論第一個問題。

MVP架構

單單要求開發團隊遷移到雲上已經很困難了,而在遷移過程中又不斷要求他們重新設計原有的應用程序,這就給整個過程帶來了很大的不確定性。所以當我們不能在GCP中找到適合我們基礎設施的替代品時,我們會盡量避免重新設計原有架構。

即便這樣,GCP上的很多功能已經很棒了,也爲我們的基礎設施提供了一些足夠直接的轉換方式,我們也覺得在遷移時進行這些切換是非常適合的。

首先,我們保留的部分:

  • 我們的本地環境有一個單邏輯內部網絡。內部服務通過私有IP進行通信,大部分通過Hashicorp Consul進行協調。我們認爲保留這一點對應用程序團隊至關重要,至少在遷移期間是這樣的。通過使用專用互連共享VPC網絡,我們爲開發人員提供了一個就像本地數據中心擴展一樣的雲。
  • Liveramp的大數據處理核心ETL和連接管道都運行在Cloudera Hapdoop平臺上。這一點不會改變,至少目前不會。
  • 儘管本文的重點不是我們的安全和數據隱私決策,但它們與我們做的每一件事都息息相關。我們的運營團隊保留了對數據權限和網絡規則的控制權。雲平臺讓開發人員更加強大,但也使他們更容易做出非常愚蠢的決定。只有當你知道你不能意外泄露客戶數據時,你才能更容易進行安全快速的開發。

那我們又需要改變那些部分呢?有很多,但這裏將重點關注下面的三種技術:

在本地數據中心,我們很自然地選擇Hadoop HDFS來保存持久數據。雖然我們的HDFS集羣在遷移時仍然運行良好,但無停機或無中斷的維護和升級要求讓我們倍感壓力。隨着公司的發展,我們能夠跟產品團隊協調的停機時間也越來越短,直到再也無法在規定停機時間內完成升級。我們知道我們想使用GCS(谷歌雲存儲),只有這樣纔可以保持作爲開發團隊的靈活性。

在本地數據中心,我們使用Chef管理所有的虛擬機。我們在Chef中嵌入了很多邏輯,也嘗試在雲平臺中使用Chef管理虛擬機,但是效果不佳。再加上Docker和Kubernetes爲我們提供了非常好的使用體驗,我們最終在新環境裏完全放棄了Chef。

最後一點,我們認爲Google的BigTable可以很好地替代我們自主研發的鍵值數據存儲。放棄一個已經使用了這麼久的工具的確令人難過,但只有這樣才能讓我們專注於那些新的令人興奮的挑戰。

雲上Hadoop

接下來,我將着重介紹一下我們的Hadoop基礎設施,包括過去和現在。我會簡要介紹一下我們的基礎設施,以及我們在GCP上的構建。

下面是我們本地Hadoop集羣的一個高度簡化視圖:

爲保持簡潔,該圖省略了Journal Nodes、ZooKeeper和Cloudera管理角色。值得一提的是,該生產環境集羣能夠:

  • 在不同開發團隊之間共享;
  • 在不隨負載擴展的物理節點上運行;
  • 從網關虛擬機啓動作業;
  • 將所有數據存儲在一個HDFS聯邦中(4個HA NameNode對);
  • 自2009年以來持續運行(除了某些系統升級的時段)。

毫無疑問,HDFS是最具可伸縮性的本地文件系統,但與雲原生的對象存儲(S3,GCS)相比仍有一些缺點。例如,數據會隨着實例的銷燬而丟失(除非你還保留了持久磁盤記錄)。在設計雲集羣時,我們知道有以下需求:

  • 能夠長期運行的臨時集羣(有問題?結束當前集羣重啓一個開始就好);
  • GCS中所有重要的數據;
  • 按應用程序團隊隔離集羣;
  • 快速自動伸縮;
  • 從GKE(谷歌Kubernetes引擎)發起工作任務。

所以,我們得到了如下所示的設計:

上圖包含了很多內容,讓我們逐個分析:

  • 不同的集羣按應用程序團隊運行在不同的子網中;
  • 工作任務從GKE發起而不是從虛擬機發起。每個pod中只包含一個應用程序,不再需要手動將應用程序打包到虛擬機上;
  • HDFS仍然存在,但只有很少的一部分:YARN使用HDFS保存JobConf、分佈式Cache和應用程序日誌。但所有的應用程序數據都存儲在GCS上;
  • 因爲幾乎不怎麼使用HDFS,所以我們只需要幾個數據節點。大多數worker節點只是節點管理器。它們可以根據應用程序負載快速伸縮。

我會在另一篇文章中更詳細地討論這個問題,但重點是,臨時的去數據化基礎設施讓我們在配置和機器類型上迭代的速度比在物理機器上快了1000倍。

這些決定爲我們的遷移提供了一個起點。在下一篇文章中,我將討論遷移的實現細節問題,重點討論如何在吞吐量有限的情況下處理數據複製。

原文鏈接:

https://liveramp.com/engineering/migrating-a-big-data-environment-to-the-cloud-part-2/

相關閱讀:

大數據公司 LiveRamp 上雲記(一):爲什麼選擇 GCP?

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章