在互聯網降本增效的氛圍背景之下，我也接手了一個降本增效的大活: 對大數據集群進行“瘦身”，并把公有云上部署的集群遷移到公司機房，即從云上遷移到云下

從最終效果來看確實很明顯，大數據集群基本遷移到云下，成本一年節省了40多萬

好像又可以寫一篇爽文了（我為什么要說又），但是不管是對我還是對一些用戶來說，更想看到的應該還是遷移是怎么做的，每個組件具體怎么遷的，中間是不是要注意什么細節，如果我一個不知道大數據怎么用的人又應該怎么了解遷移這件事

于是就有了這篇繁忙之中寫下的文章

遷移背景

云上大數據集群的成本都來自于機器。20多個節點一年成本70多萬

其實對于大數據集群來說，這個成本一點不算夸張，只是從19年運行至今，基本只擴容而沒有縮容過的集群，實在是有太多可以優化的空間了: 一年前無用的歷史副本可以清理、部分節點使用率非常低可以縮容、部分存儲類大數據組件功能類似可以合并等

當然，對于降本這個目標來說，最有效的方案還是四個字: 遷移，下云！

既然云上的成本這么高，我們就把集群搬到自己的機房，直接“買斷”所有成本

在運維同學的積極配合下，很快就在公司機房弄好了三臺高性能機器

開始我們的遷移重頭大戲吧

遷移前后架構圖

遷移前

遷移后

除了組件升級，以及部署環境從云上遷移到了云下，整體部署架構保持不變，依然是分為實時和離線數倉兩部分，除了實時數據依然需要從 MySQL 抽取之外，所有的離線任務和數據都是從云下抽取、在云下計算、最后存入云下HDFS

遷移方案制定

大數據遷移，究竟是在遷什么，大的粒度可以分成服務和數據兩部分，但這兩個粒度重合的部分還是很大：服務遷移的第一步一般是遷移數據，而數據的遷移又是通過執行各種組件指令來操作的

所以我們還是從大數據服務出發，盡量從使用者的角度，了解具體的遷移步驟

再細看每個服務要怎么遷移，又可以分為以下緯度：

• 類型: 按功能大體可分為存儲類、計算類、交互界面類和調度服務類

• 需要雙跑/處理方式: 我們遵循不影響云上服務的原則，遷移期間，服務在云上繼續運行，云下重新部署，一些服務借著遷移的機會進行升級或者下線

• 遷移準備和遷移過程: 組件的遷移一般可以分成兩個階段，前期的遷移方案準備、數據提前同步，以及正式遷移當天的配置和域名切換等

• 遷移后: 一般遷移后容易忽略的就是監控、數據清理和備份等完善工作，這些工作也應該提前有所規劃

有了這個遷移方法框架，我們就可以列出詳細每個組件的遷移方案了

組件	類型	需要雙跑/處理方式	遷移準備	遷移過程	遷移后
Ambari	集群管理	需要	部署云下服務、配置遷移	直接切換域名
Hadoop	離線數倉	需要	部署云下集群、配置遷移	全量數據遷移+增量數據遷移
Hue	數據查詢門戶	需要+升級	最新版本編譯、部署云下服務	直接切換域名
Impala&Kudu	實時數倉	下線
Ranger	權限管理	需要+升級	部署云下服務、權限手動遷移	直接切換域名	驗證權限配置是否有效
Clickhouse	離線數倉（查詢加速）	需要	全量數據遷移	增量數據遷移	下線
Presto	查詢引擎	需要	部署云下服務、配置遷移	直接切換
Starrocks	實時數倉	直接遷移+升級	云下服務啟動	逐步下線云上節點，并添加云下節點到集群

主要組件遷移方式

Ambari

先稍微花點時間介紹一下 Hadoop 和 Cloudera。Hadoop 是在 Apache 基金會下的分布式文件存儲和計算框架。當然對于企業來說，使用社區版可能需要做很多穩定性優化和適配。Cloudera 是最早的一批使用和優化 Hadoop 的公司，由它優化的 Hadoop 社區版簡稱為 CDH（Cloudera's Distribution Including Apache Hadoop），也是使用范圍最廣泛的 Hadoop 版本。不過后面 CDH 也轉向商業化了，6.3.2 是最后一個開源版本

我們公司使用的大數據集群基于 CDH 5.15 版本，大數據團隊主要在快速部署、新組件集成、組件bug修復等方面做了二次開發。新組件集成就是在 Ambari 上面完成的了。它是所有大數據組件的管理平臺，對大數據組件的安裝、服務狀態展示和配置提供可視化頁面

在機器申請好之后，第一件事就是來安裝 Ambari，基本過程如下:

• /etc/yum.repos.d 目錄添加 cdh5.repo

• 域名映射: 在 /etc/hosts 配置類似 10.10.10.1 -> router1.bigdata.com 的映射
  注意云下的 hosts 文件中不要添加云上節點的域名，避免相互影響

• Ambari 集群配置遷移，這里官方提供 blueprint 的方案，但在后續的集群初始化步驟一直卡住，索性直接把云上的 Ambari 數據庫遷移下來，啟動之后再修改配置

• 安裝完成后，仔細檢查所有服務和 域名 、 hostName 相關的配置，比如 HDFS 配置的 ZK 地址，這些配置全部從云上替換成云下的節點地址

• 按照 Zookeeper -> HDFS -> Yarn -> Hive -> Hue 等組件的順序，安裝 Hadoop 集群

HDFS

HDFS 是 Hadoop 生態的對象存儲服務，是所有其他大數據組件的基礎

HDFS 的遷移參考了兩種方案: 單個集群配置雙機架同步，以及跨集群遷移的方式

第一個方案，云上云下共用一套集群，云下的 DataNode 配置成另一個機架，利用HDFS的寫入副本機制，讓所有數據的第二塊副本寫到云下，最后逐步下線云上的 DataNode ，完成遷移

后者則需要部署一套完全獨立的 Hadoop 集群，并將HDFS數據、Azkaban任務同步到云下，相當于模擬一套和云上完全一樣的集群。獨立雙跑一段時間后，將用戶任務逐步遷移到云下集群，最后下線云上集群

第一種方案明顯技術復雜度更高，新寫入的數據需要跨云傳輸第二塊副本，在跨云傳輸帶寬受限于運營商的情況下，遷移過程很難做到對業務完全無感知。第二種方式則更安全，云上集群理論上不會有任何變更操作，對業務影響也最小

和業務開會討論后，我們選擇了第二種方案

方案這里參考了有贊的這篇離線集群遷移實戰，寫得很詳細

確定要遷移的目錄

按使用場景和方式，HDFS 數據主要分為以下幾種:

• hive 分區表數據

• hive 非分區表數據（少數）

• 用戶目錄: 這里可能包括用戶直接上傳的 jar 包，可能有一些 spark 任務依賴，因此需要同步

distcp

distcp 是 HDFS 自帶的數據同步指令，它支持限速、文件校驗、設置并發度等，建議使用之前先了解它的參數

以下是建議設置的參數:

• -m: 設置遷移的并發度，全量同步時可以適當調大，默認為 20

• -bandwidth: 設置帶寬限制，全量同步時可以適當調大。不過注意 bandwidth 是針對每個子任務的限制，因此 -m 設置足夠大的話一般就能跑滿帶寬了，不需要設置

• -Ddistcp.liststatus.threads: 啟動distcp任務時，需要先掃描所有需要同步的目錄數

• -i: 是否忽略錯誤，這里注意 distcp 在同步大目錄時，目錄下有子文件變更就很容易報錯，所以同步全量數據時我是忽略了報錯，后續增量同步時去掉

• -puga: 設置遷移后的文件所屬用戶、用戶組和權限保持不變

• -update: 只同步有更新過的文件。在同步一些用戶自己上傳 jar 包的目錄、臨時表目錄的時候比較有用

不建議設置的參數:

• -delete: 此選項會完全替換目標HDFS原本的目錄，一般和 -overwrite 參數一起使用，比如完全覆蓋掉之前HDFS內的臟數據
  但是我們在云下部署的是新集群，需要進行的是完整的同步，因此不需要這種同步模式

• -skipcrccheck: 默認開啟的文件 checksum 校驗必然會增加同步時的開銷，但為了保證數據一致性還是打開更好

數據同步

HDFS 數據同步過程大概分為兩個階段: 一周的全量數據同步，以及持續整個任務遷移階段的增量數據同步

• 全量數據同步: 在運營商提供了 30M/s 的跨云帶寬基礎上，開足馬力，帶寬和并發盡量拉大，一周完成了50T全量數據同步

• 增量 Hive 分區表同步: 為了同步同一張 Hive 表的新增分區目錄，我們可以加上 -update 參數，讓 distcp 自己判斷哪些新增目錄需要同步。當然也可以在腳本中提前生成需要同步的日期，只同步新增的 Hive 分區目錄

• Hive 非分區表目錄和用戶目錄: 通過 -update 參數同步

Hue

整個 Hadoop 生態相關的組件非常多，有負責存儲、計算、任務編排、任務調度等，怎么和這些組件交互呢？

Cloudera 開源的 Hue 閃亮登場，它封裝了大數據組件的 api ，并為用戶提供了操作界面，我們可以通過它速覽 HDFS 上的文件、通過 SQL 查詢 Hive、Starrocks 數據等

Hue 之前我們一直用的是 CDH 原生集成的 3.9 版本，基于 Python 2.7 版本編譯，界面如下

3.9 還是2015年的版本，非常久遠，而且因為 Python 版本不能安裝最新的 starrocks 連接器，使用 mysql 的適配器會有各種問題。于是決定順帶把 Hue 升級了

編譯過程不是一帆風順，問題大多數和 pip 依賴版本、django 配置有關，這里我把修復代碼提交到了 smiecj/hue/branch-4.11.0，有需要可以拉取后執行 make install 安裝

Hue 的元數據中需要遷移的只有用戶執行過和保存的SQL，都在 desktop_document2 表中，升級后注意把這張表數據遷移即可

Jupyter

Jupyter 是訪問大數據的另一個窗口，它作為交互式IDE，使用起來比 Hue 更靈活：可以在線編輯和運行 Python 代碼，即時看到運行結果（包括通過 matplotlib 生成圖片），并能夠保存最近執行結果

我們提供的是 JupyterHub + JupyterLab + 集成常用的擴展插件的版本

Jupyter 需要遷移的主要是 Python 環境（包括 Jupyter 自己的環境和擴展的 Python 環境），以及所有用戶目錄。需要注意的是用戶目錄還包括一些隱藏目錄的文件，這里有各個用戶通過界面自定義的配置，還有手動安裝的依賴

這里我們用 rsync 進行遷移，注意權限需要保持一致，示例:

rsync -apvhW -e 'ssh -p ssh_port' /opt/miniconda/envs/jupyter root@云下ip:/opt/miniconda/envs

Clickhouse

Clickhouse 的使用場景是為部分 Hive 寬表提供查詢加速功能，并由 Superset 對接 Clickhouse 表提供視圖展示。由于大部分表是分區表，因此遷移也分為全量和增量同步兩部分工作。全量同步大概3天時間完成，后續的增量同步在一天內完成

數據遷移使用的是官方的遷移工具 Clickhouse copier，但是它只做數據傳輸這一件事，增量分區的篩選條件需要自己判斷，寫到配置文件，目標集群的 CK 表也需要自己先建好

因此即使我們的遷移不涉及比較復雜的 ReplicatedMergeTree 等類型，一張張表手動遷移肯定是不現實的，需要把遷移步驟封裝好

最后我在 copy-cluster.sh 腳本中，實現了完整的遷移邏輯，可一鍵遷移所有表，使用方式:

# 集群遷移示例
# clickhouse_copier_zookeeper_nodes: copier 寫入配置的 zookeeper 地址
# clickhouse_copier_source_server_nodes: 源 clickhouse ip 列表
# clickhouse_copier_target_server_nodes: 目標 clickhouse ip 列表
# clickhouse_copier_source_cluster_name: 源 clickhouse 集群名，需要和 server.xml 中的配置對應
# clickhouse_copier_target_cluster_name: 目標 clickhouse 集群名，需要和 server.xml 中的配置對應
# 增量同步參數: clickhouse_copier_enabled_partitions: 指定需要同步的分區名稱，逗號分隔，如 20240714,20240715
clickhouse_copier_zookeeper_nodes=common1:2181 clickhouse_copier_source_server_nodes=core1,core2,core3 clickhouse_copier_target_server_nodes=newcore1,newcore2,newcore3 clickhouse_copier_source_cluster_name=source_cluster clickhouse_copier_target_cluster_name=target_cluster make clickhouse-copy-cluster

Starrocks

大數據實時數倉最初是基于 Impala + Kudu + Datalink（神州租車開源的數據同步框架），它在早期確實滿足了我們公司的實時報表需求，但隨著來自業務的實時報表需求越來越多，視圖首次查詢速度慢、不支持表結構變更、新增同步表需要大量人工操作等問題，就接踵而至。基于這套架構的二次改造也不太現實

于是從去年開始，我們將實時數倉體系逐漸往 Flink CDC + Starrocks 的框架遷移，Flink CDC 提供從 MySQL（和其他數據源） 實時同步數據的能力，Starrocks 提供存儲和物化視圖查詢加速功能。基于這套框架，解決了上面的三個問題，目前為業務提供超過130個實時視圖

Starrocks 的遷移也有新部署集群和原有集群遷移的兩種方式。前者需要先部署新集群，然后把底表和物化視圖等用戶基本數據遷移過來（官方提供了跨集群遷移的工具 starrocks cluster sync 不過未開源 ），最后切換域名

后者則全程在同一個集群操作，先在云下部署相同的版本和配置，再依次將云下的fe和be上線，云下的fe和be下線，等待集群自動完成數據同步后，徹底停止云上服務

考慮到 Starrocks 數據基本來自 MySQL，即使遷移過程發現數據有缺失，完全可以從 MySQL 或者 TIDB 幾分鐘內就重新同步，所以這里采用了原有集群直接遷移的方式

相關指令如下:

# 添加 fe
ALTER SYSTEM ADD FOLLOWER "new_fe_host:9010";

# 添加 be
ALTER SYSTEM ADD BACKEND "new_be_host:9050";

# 刪除原來的 fe
ALTER SYSTEM DROP FOLLOWER "old_fe_host:9010";

# 刪除原來的 be
ALTER SYSTEM DROP BACKEND "old_be_host:9050";

# 檢查所有 fe 和 be 狀態，直到舊集群節點看不到了，表示下線完成
SHOW FRONTENDS;
SHOW BACKENDS;

除了遷移，我們還將集群版本升級到了 3.3，徹底解決了舊版SR的性能問題

3.3 之前的版本在數據寫入和物化視圖刷新的時候，都用到了庫級別鎖，一旦同個庫在同時間有多張表并發寫入，很容易就出現視圖刷新超時和數據寫入超時的報錯，比如 "get database write lock timeout"。3.3 實現了更細粒度的元數據鎖，解決了這個問題

和元數據鎖的相關配置:

# 是否開啟 lock manager
lock_manager_enabled = true

# 是否將元數據鎖的粒度從庫級別細化為表級別
lock_manager_enable_using_fine_granularity_lock = true

# 是否讓 lock manager 自己解決可能出現的死鎖情況，主動喚醒正在排隊的鎖
lock_manager_enable_resolve_deadlock = true

Azkaban

遷移 Azkaban 的具體任務，就是遷移700多個大數據離線任務。這些離線任務的作用是生成所有業務的離線報表，它們的重要性和實時報表類似，上層直接對接業務系統，對可用性和準確性要求很高。因此任務遷移是大數據遷移中最關鍵的一步，也是最后一步

任務遷移

Azkaban 服務本身的遷移很簡單，主要是遷移數據庫，但其背后的一個個任務遷移就沒這么簡單了

首先云下的機器是全新部署的，云下跑相同的任務，難免遇到因環境問題報錯（最后主要是解決網絡問題、缺少的中間件客戶端、調優mapreduce參數等）

其次是遷移期間，業務仍在使用云上集群，可能會繼續更新項目代碼，如何讓云下代碼同步更新，避免手動更新也很關鍵

綜上，Azkaban 的遷移分三個階段:

兩個月: 在云下部署相同的離線任務，替換可能影響云上報表的配置，進行雙跑

一個月: 所有業務任務遷移

一個月: 云下任務執行結果觀察、問題修復和云上任務下線

任務同步

接著前面提到的問題，如何讓云上的任務代碼和云下保持一致呢？

之前我們有一個 gitlab webhook 服務，負責將 gitlab 代碼同步到 Azkaban，同個業務部門的數據開發都更新這一個 gitlab 倉庫，即可同步更新 Azkaban 服務內存儲的任務代碼，避免多人上傳代碼到Azkaban時誤操作相互覆蓋

在這套服務基礎上，我繼續實現了支持同步兩套環境的 webhook 的邏輯

相比之前多了執行 sed_項目名.sh 替換項目代碼中的一些配置的操作，這是因為任務代碼也包括了訪問服務地址的配置文件，云上和云下的 Hive、Presto 等服務地址當然不同，只是為了配置文件搞兩套代碼又沒必要，于是在云下代碼上傳前，加了配置替換特殊邏輯，保證任務代碼還是同一套

至于云上和云下的調度（時間）要保持一致，這里用到了 azkaban-tools 腳本工具定期同步

正式遷移

謹慎起見，正式遷移我們選擇在周末，留足時間遷移和驗證

• 再次確認云上的調度時間和云下保持一致

• 驗證所有云下任務是否正常運行

• 逐步停止云上的調度

• 確保后續任務正常運行

結尾

到這里終于可以宣布“完結撒花”了。整體來看還是比較順利的遷移，離不開業務團隊的配合和運維團隊的支持

看著從原來在云上20幾個節點跑的集群，到現在平穩跑在公司內部機房的集群，有些許成就感，當然還想感嘆“大數據不僅是組件多，很多細節更是遠比自己想象的要多”

也感嘆負責其他項目的跨云遷移的同學，不是所有遷移都能大體順利，他們可能會遇到更復雜的問題，也需要付出更多精力去定位和解決。對所有默默辛苦負責基建的同學表達 respect

最后的最后，今晚去吃什么呢？好像心中已經有了答案（