01- 大資料運營的挑戰 & 升級思考
大資料運營面臨的挑戰
中國電信大資料叢集每日資料量龐大，單個業務單日量級可達到 PB 級別，且存在大量過期資料（冷資料）、冗餘資料，儲存壓力大；每個省公司都有自己的叢集，以及多個收集全國各省級業務資訊的集團大資料叢集，導致資料分散冗餘，省叢集與集團叢集資料無法共享，跨地域任務延遲高。
電信早在 2012 年就開始建立各種叢集，內部叢集由各個廠商或其他內部團隊部署，承載的業務由各個廠商運營，運維團隊也是由各個廠商提供，因此叢集涉及的版本非常多，包括 Apache、CDH、HDP 等多個版本。隨著叢集規模的不斷膨脹，運維壓力越來越大，定位和修復問題都需要依靠廠商，這並不是一種可持續發展的道路。
為解決現網痛點，強化叢集安全，聚焦降本增效，滿足內外部支撐需求，2021 年，中國電信組建了 PaaS 自研團隊。在兩年中，PaaS 團隊針對現有的叢集進行了最佳化，保證上萬臺機器的現有叢集平穩執行。
在 2022 年初，PaaS 團隊開始自主研發 TDP（TelecomDataPlatform）大資料平臺，逐步替換現有叢集，推進產品化。2022 年上半年，透過 Hadoop 2 版本的 TDP 底座部署了兩大新叢集，開始用於生產業務。2022 年下半年研發了 Hadoop 3 版本的 TDP 底座，開始面對如何使用自研底座升級現網大量的 Hadoop 2 叢集的問題。
叢集升級思考
在升級叢集的過程中，希望新的叢集設計可以解決現有痛點，具備業界先進的特性，並且為後續的技術迭代做好前置準備。
以下是我們在叢集升級的過程中希望可以解決的問題：
拆分為小叢集
我們計劃將大叢集拆分為小叢集，原因如下：
從機器資源層面來說，無法同時使用幾千臺機器進行原有業務的遷移。此外，針對部分非常重要、對 SLA 的保證要求很高的業務，無法在生產環境直接從 Hadoop 2 原地升級到 Hadoop 3。
每個叢集中都有許多不同的業務，將大叢集拆分為小叢集后可以按照業務進行劃分，儘量減少它們之間的影響，降低業務遷移的壓力和風險。拆分成小叢集后也可以改善一些任務可能引起的整個叢集不穩定的問題，更好地控制穩定性。
舉個例子：有些機器學習的任務，並沒有使用 Sark、Machine Learning 這樣的方式去編寫，而是直接在自己的程式中呼叫 Python 庫。這個操作沒有限制執行緒的使用。這樣即使任務只申請了 2 核 10G 的記憶體，實際上也可能把這臺機器的負載打到 100 以上。因此，拆分成小叢集后，可以減少任務之間的互相影響，尤其是當平臺上需要執行非常重要的任務時，在小節點的情況下，運維工作會相對容易。
此外，拆分叢集還可以避免 Namenode 和 Hive 後設資料的膨脹，降低整體的運維壓力。因此，在業務允許的情況下，計劃採用大叢集拆分成小叢集的方式進行升級。
升級過程儘量平滑
拆分小叢集的過程中涉及到資料和計算兩個維度，資料的遷移需要大量時間，如果業務複雜，計算也可能需要花費很長時間。因此，需要想辦法將資料和計算的遷移分開，儘量擴大這兩個叢集之間的並行時間。
多叢集之間的資料互訪問題
當大叢集拆分成小叢集之後，需要考慮多個叢集之間如何做資料互訪。同時，在內部系統中有上萬臺機器和海量的資料，一直面臨著不同型別的資料搬遷、冗餘以及冷熱資料的問題。
大資料、AI 結合需求
我們的 PaaS 平臺正在逐步承接各種 AI 需求，其中最大的需求之一是非結構化資料的儲存。將這部分需求與現有的結構化和半結構化資料儲存整合在一起，這也是業界的一個前沿方向。
降本增效
將大叢集拆分成小叢集后，資源實際上會更緊張，由於不同叢集的使用情況不同，某些叢集可能只在假期、週末或進行日批次計算時才會被使用，因此需要確保閒置資源得到充分利用。
我們現有的所有機器都是高效能機器，擁有非常高的儲存、記憶體和 CPU 效能。在未來的採購中，是否所有業務都需要採購這種高效能的機器呢？例如，對於小叢集，是否可以快速搭建叢集並省去部分儲存和計算資源的成本？此外，在整個 Hadoop 2 升級到 Hadoop 3 的過程中，EC 技術可以省去 50% 的儲存資源，希望能夠將整體儲存費用降到更低。
基於上述思考，總結出以下四個策略：
• 存算分離：將儲存和計算分離。
• 物件儲存：使用物件儲存來解決結構化、非結構化和半結構化資料的儲存問題。
• 彈性計算：採用彈性計算技術來解決拆分小叢集后叢集資源不充分利用的問題。
• 容器化：採用容器化技術來解決深度學習計算任務和資源管理的問題，從而實現更高效地降本增效。
02- 存算分離架構設計& 及建設歷程
存算分離－元件選型
早期大資料架構是基於 Hadoop 2.0 的儲存計算一體化叢集，計算和儲存均使用高效能機器。而現在的架構則是儲存計算分離，將更多的磁碟用於物件儲存，建立了一個物件儲存池，以及相應的後設資料加速層，所有的HDFS訪問都會透過後設資料加速層訪問底層的物件儲存層。
存算分離技術選型
物件儲存
在考慮不同的物件儲存方案時，主要對比了 Minio、Ceph 和 Curve，而云上的物件儲存並不在的考慮範圍之內。在這三種選擇中，最終選擇了業界使用最廣泛、支援各種 K8S 容器、S3 以及底層塊儲存的 Ceph。
對接 HDFS
存算分離的主要目標是將物件儲存與 HDFS 打通。在自研的 Hadoop 2 和 Hadoop 3 中都涉及了這項工作，最初是採用亞馬遜提交的 S3 程式碼，國內的阿里雲、騰訊雲和華為雲也分別推出了自己的實現並提交到 Hadoop 社群中，但這些方案缺乏對後設資料的加速支援。
近年來，後設資料加速和資料快取技術逐漸成熟。這些技術旨在解決存算分離後，Yarn 底層資料無法與本地資料進行親和的問題。在這次打通中，不僅希望將物件儲存與 HDFS 直接打通，還希望達到業界領先的效能水平。
物件儲存可以透過多種方式與 HDFS 對接，例如使用 Hadoop 原生介面、Ceph 的 CephFileSystem 或 JuiceFS 等開源產品。雲廠商也提供了類似的解決方案，例如阿里雲的 Jindo 和騰訊雲的 GooseFS。這些產品都提供了後設資料加速和快取功能。
雖然雲廠商的產品具有成熟性和規模優勢，但無法獲取它們的原始碼，並且它們需要與雲廠商提供的雲上資源繫結。因此，我們選擇了開源的 JuiceFS。JuiceFS 目前是最成熟的開源解決方案，社群活躍度很高。能夠適配 Hadoop 商業版本如 CDH 和 HDP。最終，決定了 Hadoop 3+JuiceFS+TiKV+Ceph 的組合作為我們的存算分離方案。
存算分離架構帶來的價值
-
單個叢集儲存的資料變少，後設資料壓力變小
經過計算儲存解耦，儲存和計算可以獨立進行彈性擴縮容，並實現資料的統一儲存和跨計算叢集共享。這種方式可以顯著降低單個叢集內的儲存資料量，減輕整體後設資料的壓力。 -
解決後設資料瓶頸以及單點效能問題
後設資料可水平擴充套件，無單點效能瓶頸：後設資料的壓力反而會在後設資料加速層這一層來承擔，並且可以做到水平的擴充套件，解決了原來的後設資料的瓶頸和單點的效能的問題。 -
解決 Ceph 層聯邦不均衡問題
Ceph 層之前叢集裡出現了很多的聯邦不均衡的問題，比如某一個業務在使用了 namespace3（ns3），會使它的資料都存在 ns3 上面，導致 ns3 和其他的聯邦整體資料、壓力不均衡。 -
解決整體擴容時的瓶頸問題
在新的叢集裡透過糾刪碼去降低儲存成本，然後透過物件儲存的水平擴充套件，讓叢集的擴充套件的能力變得更好。
存算分離專案實踐：流量軌跡專案遷移
流量軌跡的資料主要是 DPI 資料，它是使用者上網的各種各樣的流量資料，包括 3G、4G 和 5G 資料。電信客服可以透過一個展示頁面查到使用者在歷史的一段時間裡流量消耗是否跟費用扣款一致。
隨著 5G 使用者的增多，現有的叢集需要不斷填充 5G 流量資料，導致儲存壓力不斷增加。所有的資料都是透過採集系統從 31 個省採集而來，現在的資料量已經達到 PB 級別，並且整體規模還在不斷增長，每天處理的資料量約為 800-900TB。這是一個比較簡單的業務場景，但是挑戰在於面臨的資料量級太大了。
之所以選擇這個業務場景進行遷移，是因為這個的場景的 SLA 要並不是那麼高，它本身是小時級的，如果當機一個小時，影響相對較小。
由於面臨的資料量太大，選擇了執行小時級別的批處理任務。透過耗費大量的資源來處理整體的計算量，以便統計使用者每小時的流量消耗及其分佈情況，並將這些資料儲存到 HBase 和 Hive 中。
基於現有采集系統的資料，將所有資料上傳到 Hadoop2 叢集中。遷移需要打通 Hadoop2 叢集和物件儲存之間的連線，JuiceFS 在這個過程中發揮了關鍵作用。有了 JuiceFS，無需重啟 Yarn 和 HDFS 等核心元件服務，就可以將物件儲存掛載上去。當新的資料進來時，當天的採集系統就可以將其寫入物件儲存中。計算任務則可以直接從物件儲存中讀取資料，對於原有任務來說，只需修改路徑，其他事項均不需要變化。
專案遷移實踐
在存算分離的上線過程中，迭代速度非常快，僅用了兩個月時間就完成了整個專案的落地。JuiceFS 的易用性，是能夠讓我們在巨大壓力下按時保量解決問題的重要前提。同時，在實踐中，JuiceFS 在解決一些關鍵問題方面也發揮了非常重要的作用。
第一：PB 級的支撐能力
- 解決後設資料儲存和連線壓力
在之前的 JuiceFS 測試中，選擇使用 Redis 作為後設資料引擎，資料儲存在 Redis 中，整體效能非常好。但是，隨著搭建了幾百臺機器，每個節點啟動 Yarn 任務時，每個容器都會訪問後設資料，導致 Redis 崩潰。因此，將其替換為 TiKV。
- 時間戳寫競爭壓力
在眾多叢集中，即使時間視窗是保持一致的，由於機器規模非常龐大，仍然可能出現時間衝突和競爭的問題。為了解決這個問題，新增了一些補丁來最佳化時間和競爭，放寬了相應的一些引數配置。
- 垃圾清理速度瓶頸
我們發現 Ceph 儲存的資料量越來越高，並沒有完全釋放下去，主要是因為 DPI 的業務資料量非常大，只會去存幾天的資料，所以每天都會去寫入 PB 級資料，然後消費 PB 級資料，以及刪除PB級資料。
- 回收站清理執行緒洩露問題
在部署監控後發現，有些特定時間點會出現 TiKV 和 Ceph的穩定性問題。經過排查，發現問題出現在客戶端回收站執行緒洩露上。
第二：在高負載下提升效能
流量軌跡專案試點時，為了滿足 32TB 計算和 10PB 儲存的需求 ，選擇了一部分效能較好的機器。然而，在評估 Ceph 的時候，沒有考慮到 Ceph 所使用的記憶體和 CPU 資源，導致每臺機器的吞吐量、網路頻寬和磁碟頻寬基本上都已經打滿了，處於類似於壓力測試一樣的環境。在這種高負載的環境下，不得不對 Ceph 進行調整以解決記憶體溢位導致的當機問題，並最佳化適配 JuiceFS 以加速 Ceph 的資料刪除和寫入效能。
專案規劃
計劃在 2023 年的 Hadoop 3 升級中實現以下規劃：
在底層，將完全依賴 JuiceFS 來儲存和加速後設資料，並根據不同業務將物件儲存拆分成不同池或叢集。
在計算資源層，每個叢集都會有自己的計算資源池，但我們將新增一個彈性資源池，用於多個資源池之間的排程。
在統一訪問層，將提供一套統一的管理工具，任務的提交都將透過任務閘道器，並透過後設資料打通多個叢集。還將把叢集劃分為不同的 Pod 或叢集，例如 DPI 叢集、位置叢集和紋理叢集等，某些叢集也可以將熱資料儲存到自己的 HDFS 中，並透過資料庫和 MPP 來提高效能。
另外，還將提供一套統一的叢集管理工具，包括儲存畫像、任務畫像、叢集日誌採集和日誌大盤等，以便更好地監控和管理叢集。
總之，希望透過按小叢集劃分、存算分離等方式來提高效能，透過 JuiceFS 加速後設資料並彈性排程計算資源，最終透過統一的管理工具來簡化運維流程。
03- 運維經驗分享
如何使用高效能機器進行混合部署
原則上在叢集規劃時不要有異構機型，儘可能選擇同種型別的機器。這樣可以保證 vcore 和 mem 保持恆定的配比。但由於公司內部對於機器的申請非常謹慎，因此流量軌跡專案實際上只拿到了 180 臺左右的舊的高效能機器進行替換，這些機器雖然效能高，但並不適合作為大量計算或儲存的機器。為了充分利用這些資源，使用存量機器混合部署，解決了規劃方面的問題。
共提供 10PB 儲存，8100（45C180）Vcore、 32TB（180G180）計算資源，其中，Ceph 使用了48G（4G*12）的計算資源，其他的都屬於 Yarn。
機器 CPU 記憶體規劃不合理
在規劃時期 Ceph 佔用的 CPU、記憶體沒有考慮，導致機器記憶體耗盡、機器負載持續偏高造成伺服器當機，引發任務失敗。Ceph 節點與 Hadoop 叢集共用一塊網路卡，節點當機觸發 OSD 資料遷移，計算任務 Shuffle 與資料遷移打滿網路卡，經過實踐最佳化配置：
• 所有節點：需兩塊 SSD Raid1 方式做根盤，以此來提高穩定性。
• 計算節點：建議 CPU 執行緒數：記憶體 為 1:4 | 1:5 左右，混合部署預留出 Ceph 佔用資源
• 儲存節點：單個 OSD（單塊盤）建議分配 6GB 記憶體，高效能伺服器建議使用雙網路平面；如果條件允許，建議將內外網分開，將 Ceph 內部的資料同步和外部的訪問分開，這是一種更加理想的狀態
• 後設資料節點：建議高效能 NVME 磁碟 這是與 PingCAP 做了多次溝通後得出的結論，磁碟的負載包括 TiKV 在當前 180 臺計算高頻的使用下，壓力很大，到 70%~80% 的情況。
• Ceph節點作業系統：CentOS-Stream-8
• 其他節點作業系統：CentOS-7.6+、CentOS-Stream-8
NodeManager 本地目錄不合理
在高負載、PB 級別的情況下，任務需要大量的磁碟空間，因此將幾乎所有的磁碟空間都分配給了 Ceph，而 HDFS 只有一塊機械硬碟。然而，在任務高峰期，由於中間資料需要寫入到這塊機械硬碟中，導致磁碟 IO 延遲過高，最終成為了任務執行的瓶頸。
經過最佳化，在機器的受限的條件下，把 Yarn 本地目錄配置到根盤（SSD)，資料盤全部分配給 OSD，解決磁碟帶來的效能問題。
JuiceFS 上報指標關閉
為了減輕 JuiceFS 的負載，關閉了 Pushgateway 所有的監控指標。因為監控指標需要透過容器持續上報，如果 Pushgateway 響應時間過長，就會導致 HDFS 的回撥一直卡住，從而無法結束任務。雖然這樣做無法檢視一些基礎的統計指標，但希望後續能夠透過其他方式來展示 JuiceFS 的監控指標。
Redis 連線數限制問題
使用 Redis 作為後設資料引擎時，連線數與 Yarn 容器的數量成正相關。當資料量過大，任務過多時，Redis的最大連線數上限（4K）瞬間就被打滿。因此，在處理冷資料時使用 Redis 或關係型資料庫，在高效能運算方面則建議使用 TiKV（資料盤使用 NVMe）。目前正使用 TiKV，它能夠支援大約 10 萬個並行連線數。
Tikv 6 小時週期性繁忙
之前曾遇到一個困擾很久的問題，使用 TiKV 時會出現 6 小時的週期性 Busy。透過日誌分析，發現 JuiceFS 開啟了大量的日誌清除執行緒。首先試圖關閉 TiKV 的上報機制來解決，但是發現這個問題仍然存在。
透過研究發現，JuiceFS 存在一個執行緒溢位 bug，導致每個 nodemanager 開啟了上萬個日誌清除執行緒。每個執行緒在呼叫檔案系統時都會觸發一個清除操作。每到 8 點整點，這些執行緒同時執行清除操作，壓垮了 TiKV，導致高峰期出現非常高的尖峰。
因此，在選擇儲存垃圾回收機制時，需要取捨 HDFS 和 JuiceFS 兩種機制。儘管兩種機制都可選，但更傾向於關閉 HDFS 的垃圾回收機制，讓 JuiceFS 獨自負責整體的垃圾回收。
JuiceFS 刪除慢
JuiceFS 的垃圾回收功能需要進行檔案刪除操作。在最初使用 JuiceFS 時，發現即使調整了 Ceph 的相應引數，將刪除和寫入權重調整到了最高，每天也無法刪完 PB 級的資料。
刪除效能很低，需要使用多執行緒的方式來進行刪除，但 JuiceFS 的每次刪除操作都需要客戶端上報指標，然後客戶端檢測回收站中哪些檔案需要刪除。如果刪除的數量很大，無法使用客戶端進行處理。最終，JuiceFS 社群提供了一個解決方案和相應的補丁，可以修復多執行緒問題並滿足 PB 級別的刪除需求。將其掛載到了固定的幾臺伺服器上進行刪除，並將執行緒數調整到了最高。目前，這個補丁還沒有被合併到正式版中，但預計它將在未來被合併。
JuiceFS 寫衝突
JuiceFS 存在寫衝突的問題，已透過調大父資料夾更新修改時間的時間間隔，降低頻繁的檔案屬性改寫來進進行緩解，但是還沒有根本的解決。目前團隊在積極地和 JuiceFS 團隊一起探討這個問題，計劃在JuiceFS 的 1.0.4 版本修復這個問題。
04- 後續計劃
• 部署更大規模存算分離叢集
• 探索不同叢集與物件儲存池之間的打通
• 探索單叢集訪問多物件儲存叢集
• 探索存算分離和資料湖的結合
• 構建結構化非結構化統一儲存池
長期來看，希望存算分離產品能夠在內部的上萬臺機器的升級過程中發揮更好的作用，並在各種場景下得到驗證；解決 Ceph 擴容帶來的叢集穩定性問題、支援 Kerberos、Range 提升安全性，提升超大規模效能，繼續提高產品的穩定性、安全性和易用性；也會進一步探索雲原生的發展。
最後，中國電信期望與 JuiceFS 社群和各位專家持續交流和解決問題，非常希望社群的各位專家可以加入電信，一起來構建 TDP 產品。也歡迎大家試用 TDP 產品。
如有幫助的話歡迎關注我們專案 Juicedata/JuiceFS 喲！ (0ᴗ0✿)