一、背景介紹

首先對知乎做一個簡要介紹。

1. 高質量的在線問答社區

用戶可以在知乎上進行提問、回答、點贊和評論，獲取有特色且高質量的內容。

2. 混合云架構

使用了多個云廠商的服務，包括 LaaS、SaaS、PaaS 平臺等，這也提高了降本的難度。

3. FinOps

知乎內部 2022 年開始建設一套經濟化計費體系——FinOps，以此系統為抓手推動公司內部降本實踐。FinOps 的運用強調了降本增效不僅是研發側的問題，更多的是與組織相關的，是需要團隊之間共同合作才能達成的目標。

二、FinOps 驅動降本

1. 企業內降本的挑戰

（1）供應商眾多：需要多個云廠商，會采購不同的資源，比如物理機、虛擬機等一些基礎資源，同時也會采購 SaaS 服務使用的資源，資源種類和供應商眾多都為管理成本帶來了困擾。

（2）組織架構：為不斷提高組織效率，公司組織架構會在一定周期內進行調整。但是在統計計費成本時，計費對象通常就是一些團隊和組織，若企業組織架構發生調整，計費對象就可能消失了。此時，我們需要一種妥善的手段去應對組織架構調整，保證計費體系的連續性。

（3）難以持續：降本增效雖然在過去已經有無數人進行了實踐，但是對于運動式的降本增效，雖然在半年或三個月有了收益，但是一段時間后，組織結構成本又逐漸提高。也就是說，整個降本增效并不是一個可持續的過程，根據 Gartner 的統計，只有 11% 的企業能夠在三年的時間粒度上實現持續的成本降低。我們在執行降本增效的過程中不僅要考慮如何通過運動式的降本增效把成本降低，還要考慮細水長流，實現可持續的降本。

2. FinOps

FinOps 是通過財務來驅動研發，兩個部門進行協同，共同實現組織降本增效的一種文化。它提出了六個原則：團隊協作、成本節省人人有責、中心化團隊驅動 FinOps、實時報表助力決策、業務價值驅動決策、靈活利用云上成本模型。這些原則可以濃縮成三個重要的方面：

• 第一方面需要真實且透明地度量成本，其中強調真實，難點在于真實刻畫業務活動中的開銷，比如我們平臺團隊在向業務提供服務時并不是直接采購一個硬件給業務方使用，而是在上面架構一個平臺，平臺再提供業務能力，讓業務去用而產生成本，真實的開銷不好計算，因為常常存在多個業務共享一個平臺。另外還要具有可比性，公司內部提供的服務和公司外部提供的服務應該是一樣的，我們需要具備相對的競爭力，如果我們提供一個數據庫的成本遠高于在云上購買一個數據庫，那么就更應該去云上購買這個服務而不是由組織內部建設，所以我們的成本應該是可以和業內的主流成本去對標，不應該有特別大的差別。透明是指我們需要讓成本越精細越好，需要看到每一項資源的準確開銷，同時團隊間也能看到對方的成本，從而驅動業務進行降本。以上均為成本度量的問題。
• 第二方面是中心化團隊的支持，我們在實施降本的過程中，必須要有一個專門的全職團隊來負責整個計費和整個 FinOps 的建設，這個團隊需要得到老板的授權，通過技術管理運營的手段去驅動降本的步伐往前走。因為降本是整個公司的目標而不是某個人某個團隊的目標，需要專門的團隊進行協調溝通。這將影響到最終的降本成果。
• 第三方面是需要對降本的結果進行階段性總結，包括績效考評，比如在降本前需指定降本目標，在一個周期完成之后，回顧這個目標，誰做的好，誰做的不好，好的原因是什么，不好是出現了什么問題。我們將好的實踐推廣出去，不好的團隊也需要有懲罰措施，獎懲分明，使降本動作是可持續的。

3. 成本分攤體系

從費用來源來看，有兩種分攤方式：直接計費和二次分攤。直接計費，例如業務需要存儲圖片，在云上買了一個對象存儲，這個對象存儲只有一個業務方在用，所以我們可以將這個云上存儲的賬單直接分給業務，這種方式為直接計費。這種方式在公司內部并不多，更多的時候服務是由平臺團隊間接提供的。比如容器團隊購買一批虛擬機或物理機，在這上面去搭建 PBS 服務，業務使用的其實是 PBS 上的這些容器，并沒有直接去使用這個機器。同時為了保證業務的擴容縮容等特殊需求，平臺需要進行池化策略，比如一些業務會共享資源池，而且這個資源池可能會有 buffer，這些冗余也會提高成本。這時就不能采用直接計費的方式，而是需要通過一些計費形式來額外地和業務方去核算。

在上圖右側圖中可以看到，最上面是最原始的一些成本來源，比如機器、SaaS 服務，或者從第三方供應商采購的軟件或硬件；中間是平臺層，包括數據團隊、技術架構團隊，容器、DB 和緩存，甚至 MQ 等都是屬于 PaaS 層，PaaS 也就是平臺團隊采購這些機器，包裝成服務提供給業務使用，這時就需要進行成本的二次分攤；最下層就是業務團隊，又分為很多級，每一級有自己的分攤邏輯。

從計費方式上來看，分成固定單價模型和百分比分攤模型。固定單價模型顧名思義，以 HDFS 存儲為例，根據用戶用的 GB 或 PB，用每臺的單價乘存儲數量即為成本。百分比分攤模型的含義是，比如兩個業務一起購買了一個向量數據庫服務，但是因為用量較小，約定這個數據庫的成本一人一半，這樣就是各自 50% 的分攤。在實際中需要根據資源的特點選擇合適的計費方式，在設計時可能會忽略的一個問題——激勵相容問題，指業務的降本動作和它的計費模型應該是匹配的，計費模型應該為業務的降本動作提供動機。以百分比分攤為例，比如兩個業務約定各 50% 的分攤比例，但是有業務把它的存儲和使用做了很好的優化，但是因為計費模式還是 50%，因此團隊的成本并沒有降低，此時我們給了業務一個負反饋，雖然降低了成本提高了效率，但在賬單上沒有任何的體現。如果采用固定單價模型的話就會有所體現，比如按照存儲量來計費，當存儲量降低的時候，這個降本的收益會體現在團隊的成果上面，這時業務人員就會更有動力進行降本的動作。這也是在做計費體系的時候需要考慮的問題。

第三個是使用按 Usage/ Capacity 付費的問題，兩種計費方式，第一種是按 Usage 計費，跟云上很相似，付費與用量成正比；第二種是按 Capacity 計費，即按照資源包付費，比如買一個 RDS 實例，用的時候即便磁盤沒有用完，但仍需要支付一個實例的費用。在我們公司，計費系統通常采用容量計費的方式設計。如果按使用量計費，由于每個服務會根據實際需求動態擴縮容，每個容器的規格和數量都在不斷變化，為了準確計算資源消耗，需要對每個容器的使用時間和消耗量進行積分計算，這種按量付費的模式會增加計算負擔，并且由于變化太快不利于平臺團隊進行容量規劃。因此，大多數情況下，我們采用容量付費模式。

在這種模式下，業務團隊需要預先申請資源配額，比如團隊的項目一共需要多少內存和存儲空間。我們的計費方式是按照申請的存儲容量乘以單價進行收費，無論資源是否被完全利用，費用都是相同的。這樣，業務可以根據實際需求調整配額，并通過設置使用上限來控制成本。由于調整配額的成本較高，業務通常會減少調整頻率，使得成本在一定時期內保持穩定。對于平臺方來說，這種容量計費方式有助于更好地規劃資源，可以提前采購或歸還機器，從而實現更高效的資源管理。

4. 運營體系

在建立了完善的計費體系后，我們應能夠準確計算每個業務和項目的實際開銷。然而，要真正實現降本的效果，還需要一套完善的運營體系。這套體系包括成本預警、異動歸因和定期會議三部分。

成本預警指的是當成本出現較大波動，特別是在成本突然上升并超出業務預算時，系統應發出警報，提醒業務團隊及時干預并解決問題。

異動歸因是指當業務團隊發現成本變化時，最需要的是了解成本波動的原因。成本的變化可能超出預期，甚至可能是由某個特定功能引起的額外成本。在這一方面，FinOps 平臺能夠通過豐富的計費項目幫助業務快速分析成本變化的原因，避免手動歸因帶來的巨大人力消耗。類似的，我們在 HDFS 上也采用了一套基于歸因算法的體系。例如，某項目組在一周內的 HDFS 存儲成本下降了 1.85%，而其中一個項目的存儲減少了 29%，對整體成本下降貢獻了 164%。通過對各項貢獻度的排序，我們可以迅速找出導致成本變化的原因。

定期會議也是成本運營的重要環節。通過這些會議，我們可以定期回顧每個業務團隊的降本措施，分析其成效和變化。此外，管理層的支持至關重要，尤其是在績效考評和激勵機制上，為這些降本措施提供支持和動力。通過這樣的運營體系，我們能夠更加有效地驅動成本管理，助力業務的可持續發展。

三、技術驅動降本

在大數據領域，從 2022 年到 2024 年，我們采取了多項措施，逐步降低了整體成本，主要分為存儲優化和計算優化兩大部分。其中，有四項措施在成本收益比方面表現尤為突出，存儲優化方面包括 EC(Erasure Coding)，Zstd 壓縮。計算優化方面包括 Spark 自動調參，Remote Shuffle Service。下面對這些優化做詳細介紹。

1. EC(Erasure Coding)

EC（Erasure Coding）技術起源于舟山，最早應用于通信行業。當信息在傳輸過程中，信道可能會受到干擾，導致數據的損壞或丟失。為了確保數據的可靠傳輸，舟山碼策略問世，用于在數據傳輸時添加適量的冗余，從而提高數據的可靠性。EC 正是基于這一原理的算法，其常見實現方式之一是 RS（Reed-Solomon）編碼。

EC 的基本原理是將數據分成多個塊，并通過矩陣運算為每個數據塊生成相應的校驗塊。如上圖所示，數據塊包括 d0、d1、d2、d3，經過 EC 的計算后生成了兩個校驗塊 c0 和 c1，最終形成六個數據塊。這意味著，原來的數據冗余了 0.5 倍，但系統可以容忍任意一個數據塊的丟失，并可以通過矩陣運算將數據還原回來。

在大數據存儲領域，EC 的降本效果顯著。傳統的分布式存儲通常為了保證數據的可靠性，采用三副本冗余策略，也就是說，寫入 1GB 的數據時，底層會存儲 3GB 的數據量。而通過 EC 算法，僅需 1.5 倍的冗余即可提供相同的可靠性，這不僅大幅減少了存儲需求，還降低了存儲成本，特別是在大規模數據存儲環境中效果尤為突出。

然而，使用 EC（Erasure Coding）技術也存在一定的代價。首先，EC 的計算需要額外的 CPU 資源，因此對特別高頻訪問的數據（即“熱數據”）并不適合進行 EC 轉碼。為了有效利用 EC，必須對數據進行評估，判斷哪些數據適合進行 EC 轉碼，哪些不適合。比如，剛寫入的數據和頻繁讀取的數據由于可能帶來額外的 CPU 消耗，通常不適合立即進行 EC 轉碼。因此，EC 主要適用于“溫數據”和“冷數據”。

在實際應用中，我們對 EC 的性能進行了測試，使用了 DFSIO 讀寫工具來模擬操作。測試結果如右圖所示，藍色線代表傳統的 HDFS，橙色線代表使用 EC 的 HDFS。我們采用了 RS-6-3 算法，將一個數據分成九塊，其中六塊為數據塊，三塊為校驗塊，這意味著即使有兩個塊（或兩塊磁盤或兩臺機器）發生故障，數據仍能恢復。隨著客戶端讀寫并發性的增加，EC 的讀寫性能出現了延遲，這是因為在更高的并發度下，需要更多的機器參與讀寫操作。相比之下，傳統 HDFS 可能只需一兩臺機器來完成讀寫，但 EC 能夠將 I/O 負載均攤到更多節點上。

對于新寫入的數據或即將過期的數據，不建議使用 EC，因為 EC 編碼需要消耗大量算力，而這些數據的轉碼并不劃算。另外，EC 轉碼還可能導致小文件問題，因塊數量的增加（如從六塊增加到九塊）而給 NameNode 增加壓力。因此，優先選擇相對較大的文件進行 EC 轉碼，以減少對系統的負擔和資源消耗。

在引入 EC 方法后，為了有效管理和執行 EC 轉碼任務，必須構建一個專門的 EC 服務來自動化完成這項復雜的工作。由于數據量龐大且數據狀態不斷變化，僅依靠人工是無法完成的，尤其是在新數據不斷生成和舊數據逐漸過期的動態環境下。因此，全自動服務是必不可少的。

整個 EC 服務體系分為兩個主要部分：首先是元數據倉庫，它負責為整個 Hive 表建立詳細的元數據畫像。這個畫像包含了諸如 Hive 表的分區大小、文件數、平均文件大小、訪問熱度，以及分區是否已經過 EC 處理等關鍵信息。通過這些維度的綜合評估，系統可以篩選出最適合進行 EC 轉碼的分區。篩選出來的分區隨后會被交由 EC Worker 服務進行處理。EC Worker 是一個自研的專門執行 EC 轉碼的服務。這個服務的設計考慮了數據的可靠性，確保數據在轉碼過程中不會丟失，并具備嚴格的事務性保障。這意味著對一個目錄進行轉碼時，要么所有數據成功轉碼，要么如果出現問題則整個任務回滾，以避免中間狀態或數據丟失的情況。

此外，EC Worker 服務還需要具備冪等性，即在文件已經過一次 EC 轉碼后，系統需要能夠判斷并跳過已處理過的目錄，避免重復轉碼。特別是在目錄內容因底層重寫而發生變化的情況下，系統必須能夠準確識別這種變化，并根據當前狀態決定是否再次執行 EC 轉碼。

總之，EC 服務的成功運行依賴于其自動化、事務性和冪等性的特性。這些關鍵因素確保了整個 EC 過程的可靠性和高效性，使得大規模數據環境下的 EC 轉碼任務得以順利完成。

整體收益來看，EC 方法顯著優化了存儲資源的使用效率。通過將三副本降低為 1.5 副本的方式，在確保數據可靠性的前提下，沒有因 EC 而產生任何數據損失。在 2023 年初，該項目已節省了 25PB 的存儲容量，并將在未來繼續產生效益。然而，在實踐過程中也遇到了一些挑戰。例如，使用的 Hadoop 3.1.x 版本存在一個 bug，具體表現為在 EC 塊丟失并重建時，可能會導致重建的塊出現臟數據或亂碼，而帶來數據丟失的風險。

2. ZSTD 壓縮

ZSTD 是 Meta 開源的一種壓縮算法，相較于傳統的壓縮算法如 Snappy 和 LZ4，它在壓縮率和壓縮速度方面取得了很好的平衡。如上圖中的官方性能測試結果所示，ZSTD 的壓縮率比 Snappy 提升了 30%，而壓縮性能保持不變。常用的壓縮方法是 ZSTD 1.5.6 版本中的 ‘fast=3’ 的參數設置。在知乎的數據處理中，主要采用 Parquet 的存儲格式。然而，由于部分早期的表未在 Parquet 格式上進行壓縮，而較新的表則使用了 Snappy 壓縮算法。經過測試，將這些表從 Snappy 壓縮算法轉換為 ZSTD 壓縮后，整體存儲將減少約 30%；如果原來的 Parquet 表未進行壓縮，整體存儲將減少 50%~60%，收益是非常可觀的。

在對表的新產生數據更換壓縮算法時，需要考慮 ZSTD 的兼容性問題。因為此壓縮算法較新，許多早期版本的 Hive 和 Spark 可能并不支持，因此需要將一些支持的補丁回移到 Spark 2 和 Hive 2.1 版本中，確保表可以被下游消費和讀取。

此外，對于歷史數據的壓縮算法處理，有兩種方案可以考慮。方案一是對表進行一次 ETL 處理，通過 INSERT OVERWRITE 對表進行重寫。然而，這種方法存在處理速度慢的問題，因為它需要將所有數據讀取出來，進行反序列化和計算，然后再重新序列化回去。這個過程還存在一定的風險，例如在業務演化過程中表的 schema 可能發生變化，重寫可能改變底層的數據結構，導致預期之外的風險；除此之外，重新 ETL 可能會改變數據的分布，導致壓縮率下降。

因此，更為理想的方案是采用一種能夠繞過 SQL 對文件直接進行處理的算法。Parquet 文件的存儲結構本質上是一種行列混存的格式，具體來說，對于一個大的表格，先按行進行切分（例如每一萬行切一塊），每個塊稱為一個行組。每個行組內部包含多個列，這些列數據按照列存的方式進行組織和存儲。因此，一個 Parquet 文件可能包含多個 row group，每個 row group 是按行組織的數據組，而每列數據在具體存儲時是通過 page 的方式進行壓縮。壓縮操作發生在 page 層次上，而非對整個 Parquet 文件進行壓縮。我們希望將舊的 page 讀取出來，用老壓縮算法解壓縮后，再用新的壓縮算法重新壓縮，這在官方的 Parquet 實現中是可行的，并且官方提供了名為 parquet-tools 的工具，其中定義了一部分對底層 page 進行操作的 API，我們基于這些 API 開發了 ZSTD 轉化工具，該工具能夠非常高效地對底層文件進行重寫，而不涉及到 schema 的變更，也無需對數據進行任何反序列化，只是單純地將數據取出并重新壓縮。

這種方式顯著提高了處理效率，能夠在較短時間內完成對歷史數據的處理，同時還可以在轉碼過程中對一些小文件進行合并。根據整體估算，ZSTD 每分鐘可以處理 30GB 的數據，在一個月中節省了 10PB 的存儲，新的作業已默認采用 ZSTD 壓縮算法。同時，ZSTD 和 EC 是可以并存的，它們在不同層次上進行存儲，收益是可以乘算的。

3. Spark 自動調參

Spark 自動調參是許多公司面臨的一個難題，主要難點在于如何合理定義 Spark 作業所需的資源。對于業務數據人員，自動調參可以幫助他們將大數據調參過程自動化。該系統基于作業的歷史執行數據，包括真實的內存和 CPU 消耗，來計算出最適合作業的參數配置。

整個自動調參系統分為兩部分，作業畫像系統和自動調參服務。作業畫像系統負責收集并保存每個作業運行的各項指標數據；自動調參服務基于這些歷史指標數據和預先設定的調參規則，來決定每個作業的提交參數。

作業畫像系統的關鍵指標采集包括 CPU 和內存使用率、GC 耗時、Shuffle 數據量、HDFS 讀寫統計值。系統采用了 jvm-profile 和 sparklens 開源組件，分別從 JVM 和 Spark 端采集數據，這些數據匯總后為自動調參提供基礎支持。在提交 Spark 作業時，通常會過多申請內存資源，實際使用的峰值可能低于預期。通過這種自動化的采集與分析，系統能根據歷史數據自動調整內存分配，避免資源浪費，提高資源利用率。

作業調參系統通過對 Spark 作業的 spark-launcher 進行劫持，在提交作業前先請求調參服務。調參服務會根據作業歷史的執行數據，推測最佳的 CPU 與內存比以及執行器數量，并將優化后的參數返回給長字符。整個過程采用啟發式算法，逐步逼近最佳內存配置。例如，作業最初申請了 30GB 內存，但實際峰值僅為 16GB，系統會先將內存下調至 24GB，觀察執行耗時和 GC 情況，如果沒有顯著變化，則繼續調整，直到找到最優參數。這個漸進式的調優過程能夠逐步優化資源配置，提升作業效率。

在公司實踐中，經過 3 個月的優化，整體作業資源節省了約 30%。上圖中右側圖中紅色和藍色曲線分別顯示了 CPU 和內存的優化量，以核時和 GB 時為統計單位。這種調參服務現已覆蓋所有 Spark 作業，顯著提升了資源利用效率。

4. Remote Shuffle Service

在 Spark 中，Shuffle 是數據處理的重要環節。默認情況下，Spark 提供了三種 Shuffle 方式，其中的 Start Shuffle 在實際使用中較少被采用，因為一旦出現故障重啟，Shuffle 數據會丟失，必須重新計算。一般情況下，External Shuffle Service (ESS)是更常用的方式。

ESS 的工作原理是：在 NodeManager 上啟動一個 Shuffle 服務，Spark 的 Executor 將 Shuffle 數據寫入本地磁盤，然后下一個計算任務的 Reducer 通過 NodeManager 讀取這些數據。

ESS 的優勢在于，即使 Executor 關閉，數據仍然保存在磁盤上，不需要重新計算，只需恢復數據，極大地提升了穩定性。

然而，ESS 也存在一些問題。比如 Spark Shuffle 可能涉及大量分區，每個分區在 Shuffle 時都會生成一個文件。HDFS 磁盤在使用時，IOPS（磁盤每秒讀取/寫入操作數）較低，讀寫性能不佳。而 ESS 會導致大量數據的讀寫，大量的磁盤 IO 資源浪費在 Shuffle 過程的等待時間上，而不是用于真正的 CPU 密集型計算。

如圖所示，這個任務的 Shuffle Read 數據量為 9.5MB，但生成了 1.8 萬個文件，總共產出 11 分鐘，這是典型的磁盤處理性能。但其實應該只需要幾秒鐘，這就是 RSS 引入的背景。

RSS（Remote Shuffle Service）實質上為 push based shuffle，和 ESS 不同，它是由 executor 主動將數據推送到下一個 Reducer 所需的存儲位置，也就是說數據寫入的時候會按照讀的要求做一定的合并和整理。

在眾多的開源 RSS 中我們選擇了阿里的 Apache Celeborn，經過一系列的測試，Celeborn 的穩定性和性能都是比較好的。Celeborn 的一個重要收益是將 shuffle 過程中大量的隨機讀寫操作轉化為順序讀寫操作。寫入的時候會按照需求對 partition 做合并，數據已經被按照順序整理好，可以進行直接讀取。這樣減少了隨機讀寫操作，提高了磁盤吞吐量。此外，Celeborn 還支持 PartitionSplit 的功能，當發現 partition 太大的時候可以進行主動的分裂，避免一個 worker 處理過多的數據。Partition 分裂這一功能在平滑升級中非常有用，例如當某個節點需要維護或下線時，Celeborn 可以將該節點正在處理的 Partition 分裂并轉移到其他 worker，從而避免新數據經過該節點。這使得在不中斷業務的情況下，可以平滑地處理節點下線或進行滾動升級，確保集群的穩定運行，對業務不產生任何負面影響。

統計結果表明，Spark 作業的 shuffle read 耗時經過逐步將作業接入到 Celeborn worker 之后有了明顯的下降，具體來說，整體的 shuffle read P99（即 99% 作業的最大耗時）平均損耗降低了 30%。

四、總結與展望

整體來看，我們主要通過兩大手段保證了降本增效的效果，即 FinOps 系統建設和運營，以及技術優化，實現了可持續的降本。

未來規劃，首先會推動 Hive 引擎逐步向 Spark 引擎遷移；其次利用主流方法，如 gluten+velox 進一步提升計算效率；同時探索通過彈性EMR 和固定資源池混合的方式提高資源利用效率。