在王堅博士的《在線》一書中提到，單純談數據的“大”，意義是不大的。歐洲核子研究中心（CERN）進行一次原子對撞產生的數據大到驚人，而如何通過計算的方式去挖掘出這些數據背後的價值，纔是數據意義的本身。HPC高性能計算，就是完成這種價值轉換的重要手段。近年來，HPC的應用範圍已經從純學術擴展到資源勘探、氣象預測、流體力學分析、計算機輔助設計等更多場景。這些HPC應用程序會產生或依賴大量數據，並將其存儲在PB級別的共享的高性能文件系統中。然而，無論是HPC應用的用戶，還是高性能文件系統的開發人員，對這些文件的訪問模式瞭解都非常有限。
我們在Fast20中發現了一篇很有趣的論文《Uncovering Access, Reuse, and Sharing Characteristics of I/O-Intensive Files on Large-Scale Production HPC Systems》，這篇論文研究了超級計算機的生產環境上I/O密集型HPC應用對文件訪問模式。
據論文作者所知，這是第一篇對HPC系統中IO密集型文件的訪問、重複使用以及共享特性進行深入研究的論文。這篇論文第一次揭示了（1）HPC中的各個文件是讀密集型，還是寫密集型，或是讀寫密集型；（2）在多個任務中，反覆訪問同一個文件的時間間隔；（3）多個應用程序對同一個文件的共享行爲。更進一步地，這篇論文還基於文件的IO時序，分析了導致文件系統性能低下的主要原因，這些原因導致了在單次任務和多次任務間的IO的性能波動。
論文總結了十個發現，我們結合自己的理解，補充了很多背景知識，摘要了其中的要點，和大家做個分享（前方極其高能），大家可以細細品讀論文作者的研究思路和手段，也可以直接瀏覽論文歸納的十大發現。以下文章中未註明的圖表，均來自論文原文（圖表標號使用原文中的標號）。感興趣的同學可以閱讀論文原文，也歡迎大家和我們一起討論。
01 概述
在大規模高性能計算HPC集羣上，各個應用的數據讀寫通常都在幾十上百TB。過往對於IO特徵上的研究大多基於單個應用程序級別，針對特定應用提供底層存儲的優化建議。而大家對於HPC系統中不同應用程序對各種文件的IO特點，瞭解非常有限。因爲這需要在HPC生產環境中，跟蹤應用在大量任務執行過程中產生的IO信息，衆所周知，這種細粒度的跟蹤和分析，對系統的性能是會造成很大影響的，這也正是很難在HPC的生產環境中進行類似研究的原因。然而，這種研究還是極具價值的，它對於我們存儲研發人員更深入理解針對文件的IO、文件反覆讀寫的模式、IO性能上的波動、優化文件放置策略，都非常有意義。
論文的研究使用的是輕量級的IO監控工具Darshan（Darshan旨在以最小的開銷捕獲應用程序IO行爲的準確情況，包括文件的訪問模式等特徵。Darshan名稱取自梵語單詞“ sight”或“ vision”， https://www.mcs.anl.gov/research/projects/darshan/），論文作者團隊在Top500超級計算機集羣Cori的生產環境上，進行了長達四個月（累計近3600萬個節點小時）的跟蹤和分析。
02 研究的背景和分析方法
首先介紹一下Cori，超級計算機集羣Cori在最新的世界HPC Top500中排名第十三位（https://www.top500.org/list/2019/11/），Cori具備約27 Pflop / s的峯值計算性能，包含9,688個Intel Xeon Phi和2388個Intel Haswell處理器。Cori使用的是基於磁盤的Lustre文件系統，該文件系統由約10,000塊磁盤組成，這些磁盤被組織爲248個Lustre OST。每個OST都配置有GridRAID，並具有用於處理IO請求的相應的OSS。文件系統的總大小約爲30 PB，IO峯值帶寬爲744 GB / s。Cori是長這樣的：
IO數據監控和採集。論文作者使用Darshan這個監控工具對應用程序進行文件IO訪問模式等特徵的收集。在研究期間，Cori上所有用戶都默認啓用了Darshan V3.10。Darshan收集了包括用戶ID、作業ID、應用程序ID、開始時間戳、結束時間戳和進程數等關鍵信息。Darshan還針對代表性的IO接口類型 POSIX IO、MPI IO（Message Passing Interface，MPI是一種用於對並行計算機進行編程的通信協議，是一個用於進行消息傳遞的應用程序程序接口、協議和語義規範，MPI是當今高性能計算中被廣泛使用的IO編程模型，這種編程模型需要底層存儲的支持）、STD（Standard）IO的IO調用接口進行了監控和統計。統計的指標包括讀/寫數據量、讀/寫/元操作的總時間、執行IO的進程ID，以及不同應用程序進程中IO大小和IO時間的波動。最後，Darshan還收集了Lustre文件系統級別的一些指標，例如條帶寬度和對文件條帶化所涉及的OST ID。但是，Darshan沒有記錄各個文件的實際大小，而只記錄了文件被傳輸的數據的大小。在論文研究期間，作者團隊供收集了大約8400萬條日誌（每次任務執行對應一條日誌），這些日誌涵蓋在8489個應用程序的5200萬個日誌文件中，涉及651個用戶和12.8 PB的數據傳輸（其中6.9 PB讀取數據，5.9 PB寫入數據）。
在以下篇幅中，會使用到幾種圖表，包括：
- 熱度分佈圖，用於顯示兩個指標之間特定關係的關聯程度。熱度分佈圖顏色的強度表示顯示兩個座標指標上對應的文件數。
- CMF圖。CMF圖用於顯示橫軸指標的累積分佈。垂直的藍色虛線用於指示橫軸指標的平均值。
一些CMF圖顯示的是一個指標的CoV（變異波動係數（％），https://en.wikipedia.org/wiki/Coefficient_of_variation）的累計分佈（簡單來說，就是這個指標在多大範圍內波動的累計概率情況），以突出顯示這個指標的歸一化波動特性。 - Violin Plot，這些圖用於以垂直格式顯示指標不同值的密度（以文件數表示），水平的藍色實線用於指示密度分佈的平均值。
如何選擇IO密集型文件
前面提到過，Cori的Darshan日誌包含了約5200萬個文件。但是，分析表明，在研究期間，大多數日誌文件中執行的IO操作很少。圖2橫座標表示計算任務中一個文件的傳輸數據量（讀或寫），縱座標表示一個文件在多少個任務中被讀寫，不同色塊代表涉及的文件數量。從圖中可以看出，大多數文件的IO小於100 GB，並且整個計算過程中只被訪問一次。實際上，超過99％的文件傳輸數據少於1 GB。這並不意味着實際文件大小小於1 GB，只是文件的數據傳輸量小於1 GB。
因此，大多數的文件對建立與HPC應用程序的主要IO模型有關的特徵沒有幫助。這些文件包括用戶註釋、腳本、可執行文件、非IO密集型應用程序輸出以及錯誤日誌等。而論文的研究重點是 “IO密集型”文件，這些文件在研究期間至少完成了100 GB的數據傳輸，並且至少被2次任務訪問，作者通過研究這些IO密集型文件以捕獲最主要和最具代表性的IO模式。從這裏開始，將這些IO密集型文件簡稱爲“文件”。這些IO密集型文件的日誌跨越了約40萬次任務、791個應用程序、149個用戶、8500個文件和7.8 PB的數據傳輸（4.7 PB的讀取數據和3.1 PB的寫入數據），超過70％的用戶對2個以上的文件執行IO操作，每個用戶平均對57個文件執行IO。
文件分類
接下來，作者根據IO密集型文件執行的IO操作類型對這些文件進行分類，這有助於理解後續章節中針對不同類型文件訪問特點所得到的發現。圖3（a）顯示了每個文件讀取數據傳輸量與寫入數據傳輸量的熱力圖。文件可以分爲三個不同的種類，右下方的一組由22％的文件組成，這些文件在四個月內傳輸的大部分爲讀取數據，論文將這些文件稱爲讀密集型文件或RH（Read-Heavy）文件。左上方的一組由僅傳輸寫數據的文件（寫密集型文件或WH（Write-Heavy）文件）組成，佔IO密集型文件的7％。位於文件右上角的一組具有最大的佔比（佔71％），由讀寫密集型文件組成（稱爲RW（Read-Write）文件）。
發現1. HPC文件可分爲讀密集型（RH）、寫密集型（WH）或讀寫密集型（RW）。論文首次量化了文件中有很大一部分是讀密集型的文件（佔22％），小部分是寫密集型文件（佔7％），這7％的文件被不斷寫入，但未被讀取。有71％的HPC文件是RW文件（即讀寫密集型文件）。這種的文件分類可用於設置文件放置決策，包括Burst Buffer區在內的分層存儲放置策略，其中每個層分別適用於不同類型的IO操作。
讀寫任務分類
儘管可以將文件根據IO類型分爲三種，但它們可以被多個“應用程序的任務”訪問，各任務都可以執行讀取和寫入操作。任務是指在計算節點上運行的各種作業，由一個節點內的多個MPI進程以及可能的共享內存的線程組成。作者發現，絕大多數任務要麼執行讀密集型操作，要麼執行寫密集型。爲了證明這一點，作者使用以下公式計算每次任務的讀寫數據量之差：|數據讀取-寫入數據| /（數據讀取+寫入數據）。該公式的值範圍是0到1，1表示任務所處理的所有數據都是隻讀或只寫，0表示讀取和寫入數據傳輸量相等。圖3（b）顯示所有任務中，超過82％的值非常接近1，即它們是讀密集型或寫密集型的。在IO上下文中，作者將讀密集型任務簡稱爲“讀任務”，將寫密集型任務稱爲“寫任務”。作者發現其中69％是讀密集型任務，而31％是寫密集型任務。RH文件主要由讀密集型任務讀取，WH文件主要由寫密集型任務寫入，這兩類任務都會對RW文件進行操作。對任務的分類有助於在後續章節中建立任務之間的生產者-消費者關係模型。
發現2.令人驚訝的是，現代HPC應用程序在單次任務中主要傾向於僅執行一種類型的IO：要麼讀，要麼寫。這與普遍認爲HPC應用程序在一個任務期間，同時具有讀取和寫入IO階段的假設相反。這一發現表明，更科學的工作流逐步取代了傳統的單體化應用程序（將不同工作彙集到一個任務中）的設計。非單體化應用程序的存在，爲更好地調度大型工作流的不同組件提供了機會，從而避免了不同工作流之間的IO爭用。
03 結果討論和分析
接下來，論文分析了多任務重複訪問數據及多應用共享數據的特點，並研究了負載是否均衡，以及任務內和不同任務間IO波動的特徵。
文件複用的特點
在之前，作者將任務分爲了讀任務或寫任務，並且發現讀任務的總數約爲寫任務數量的2倍。接下來，爲了瞭解複用同一文件所花費的平均時間（任務到達時間定義如圖4所示），作者定義了不同任務的到達時間的概念。
圖5（a）顯示，同一個文件經歷的不同讀任務的平均到達時間間隔爲47小時，而寫任務的平均到達時間間隔爲55小時。但是，平均而言，80％的文件只有在50-55小時後纔會再次被讀取和寫入。作者注意到，平均到達間隔時間比Cori上作業的平均運行時間長得多（這些系統上> 80％的HPC作業在不到2小時內完成）。
發現3.對於80％的文件，讀寫任務具有相似的到達時間間隔，都超過2天。論文首次發現，大多數文件重新訪問時間間隔（>50小時）比作業的運行時間更長。這意味着HPC系統有時間對一些希望在一段時間內不活躍的數據進行壓縮，或者將一些接下來即將訪問到的數據通過預讀和緩存的方式加載到Burst Buffer層中。
具有相似到達間隔時間的讀寫任務促使調研團隊測試讀寫任務是否會背靠背執行，如果是這樣，這種的執行次序會持續多長時間。論文計算了每個文件的連續讀和寫任務的平均次數（如圖4所示），並將分佈情況繪製在圖5（b）中。
超過80％的文件經歷過2次或更多次連續讀任務，而超過65％的文件經歷2次或更多次連續寫任務。大多數文件經歷2次連續讀運行（65％）和2次連續寫運行（50％）。這表明文件是在多次讀任務和多次寫任務的交替中進行訪問的，這與前面觀察到RW文件佔總體的比例（71％）是一致的。但是，許多文件會經歷大量連續讀任務（由於RH文件）。事實上，一個文件經歷的平均連續讀任務的次數超過14，而平均連續寫任務的次數<4。讀任務的次數僅爲寫任務次數的2.2倍（讀寫任務分類小節中提到），但是平均連續讀任務次數爲連續寫任務次數的4.3倍。這表明對於大多數RW文件而言，數據僅生產了幾次，然後被消耗了很多次。該觀察結果表明，科學模擬計算通常會在某些任務期間生成數據，然後在隨後的幾次任務中將其用作驅動後續程序的輸入，以探索不同的潛在路徑或分析模擬現象。作者注意到，連續的寫任務並不意味着所有先前寫入的數據都被重寫或丟棄。一些科學工作流可能會在兩個連續的寫任務中追加數據，然後在後續任務中讀取該文件的一部分用作分析。
發現4. HPC文件平均經歷幾次連續的寫任務和一長串的連續讀任務。這個發現可以幫助利用MPI“hints”API來指導系統即將要執行的IO類型，以及對IO服務器進行分區，以分別提供RH文件（執行多次連續讀）和RW文件（用於讀取和寫入任務），減少IO競爭，從而提高IO性能。
多應用程序間的文件共享特徵。接下來的工作，爲了將生產者與消費者的關係更進一步，從而瞭解生產者和消費者是相同的應用程序還是不同的應用程序。作者注意到所有訪問同一個文件的應用程序均由同一用戶運行。因此，對於任何文件，生產者和使用者應用程序都屬於同一用戶。此外，由於權限問題，默認情況下，也不會將文件在多個用戶之間共享。圖6（a）顯示了訪問文件的應用程序數量的CMF，超過67％的文件被至少2個應用程序訪問共同訪問，表明文件經常被多個應用程序共享。
圖6（b）展示出了對文件執行IO的每個應用的到達間隔時間的CMF。每個應用程序的平均到達間隔時間爲31小時，比單個讀任務的平均到達間隔時間（> 50小時）要低得多。因此，對於大多數文件，有兩個或多個應用程序充當生產者和使用者，而不只是被單個應用程序訪問。這與作者的發現是一致的：被多個應用程序訪問的大多數文件（86％）是RW文件（這些共享文件中只有12％是RH文件，只有2％是WH文件）。
發現 5. HPC文件由多個應用程序共享，並且每個應用程序都會執行讀取和寫入操作，同時充當生產者和使用者。這些任務的到達間隔時間還表明，生產者和消費者在時間上顯着分開，從而限制了跨應用程序訪問時使用緩存的有效性。
IO數據訪問特點
在文件複用特點中，作者研究瞭如何在多次任務中使用相同的文件。接下來，論文將分析在多次任務中數據訪問特徵會發生什麼樣的變化。圖6（c）顯示了每次通過讀任務和寫任務傳輸的數據量的CMF。可以觀察到，平均而言，每次讀任務傳輸17 GB的數據，而每次寫任務傳輸25 GB的數據，50％的讀任務傳輸數據量少於1 GB。
發現6. 雖然讀任務比寫任務要多，且讀任務傳輸的數據總量大於寫任務，但是令人驚訝的是，單次寫任務所傳輸的數據量要單次讀任務要多。平均而言，每次寫任務運行的IO次數是讀任務的1.4倍。可以利用此發現來限制同時執行的寫任務數量，從而在系統級別更好地管理IO爭用問題。回想一下先前的發現，HPC應用在一次任務中會主要傾向於只執行一種類型的IO，因此，“寫任務”可以輕鬆地被檢測和分類，從而限制併發寫入的數量。
既然已經發現不同的任務會傳輸不同數量的數據，接下來要研究的問題是這種差異會如何影響後端OST。圖7顯示了在研究期間每個OST傳輸的標準化IO數據。
有意思的是，每個OST傳輸多少數據有很大的不同。最不活躍的OST僅是最活躍OST的13％。另一方面，當查看每個OST上的文件數，使用這些文件的應用程序數以及生成文件的用戶數時，作者發現分佈範圍要窄得多。
發現7. 對於在論文中研究的基於Lustre的系統，OST具有容量平衡的功能，以確保在文件創建時的利用率大致相等，但這並不能保證動態負載平衡。因此，在每個OST隨時間推移觀察到的負載（數據傳輸）方面存在很大的不均衡，這也體現出動態文件遷移（當前在Luster文件系統中並不支持），對只讀文件的副本及緩存（能讓IO負載得到分攤）的重要性。
接下來，作者研究變化的OST爭用將如何影響各個併發運行的進程的IO時間，這些進程可能並行訪問不同的OST。在此分析中，作者分別分析了Cori使用的三種不同的IO接口：POSIX 、MPI、和STD IO。首先，看一下使用每個接口傳輸的數據量。圖8（a）顯示POSIX是最常用的I / O接口，平均每次任務每個文件傳輸大約260 GB數據，MPI接口平均每次任務每個文件將傳輸約190 GB的數據。正如並行HPC應用程序所期望的那樣，STD是最不常用的接口。
圖8（b）顯示了每次任務的單個進程上每個文件執行IO傳輸數據量的標準差（標準差用於描述不同進程間數據傳輸的偏差）。平均而言，所有三個接口的標準差都非常小。例如，進程內POSIX IO執行的數據量傳輸的平均標準偏差小於1.5 GB，與使用POSIX傳輸的平均數據量（260 GB）相比可以忽略不計。
另一方面，圖8（c）顯示了每次任務中單個進程內每個文件執行IO時間的標準差（用於描述不同進程執行IO時間的波動情況）。對於使用POSIX接口執行的IO，此標準差特別高。這是因爲通常在使用POSIX接口時，每個進程對不同的文件執行IO，而在使用MPI IO接口時，所有進程對同一個共享文件執行IO。因爲Cori超級計算機上的默認條帶寬度爲1，所以超過99％的文件僅在1個OST上進行條帶化。因此，如果應用程序對多個文件並行執行IO，因爲文件可能映射到不同的OST上，則這些應用很有可能對多個OST並行執行IO。因此，當使用POSIX IO時，這些OST上不同的資源爭用級別會極大地影響各個進程的IO時間。
發現8. OST負載不平衡會導致同時執行IO的進程所消耗的IO時間波動較大，尤其是當進程對不同的OST執行IO時（例如POSIX IO）。這導致較快的進程必須等待較慢的進程完成，才能完成IO，然後才能繼續進行計算，從而浪費了HPC系統上寶貴的計算週期。
IO負載在不同時間上的波動。以前，研究人員們已經發現OST IO不平衡和爭用會導致單個任務的IO時間產生波動。下一步，論文探索的是IO負載在不同時間上的特性。圖9（a）顯示了一天中不同時間端傳輸的數據總量。可以觀察到，最密集的IO是由本地時間凌晨3點到凌晨5點之間開始的任務觸發的。
值得注意的是，Cori的用戶遍佈全球，因此特定的本地時間（即凌晨）不能指示本地用戶何時最活躍，下面的分析不一定在不同因素之間建立直接的因果關係，而是嘗試解釋觀察到的趨勢。在圖9（b）中，展示了各個任務在一天中不同時段的IO耗時趨勢。縱軸是各個任務在指定時間段，針對同一個文件執行IO所花費的時間與IO最長時間的比值（歸一化），從而方便在各個文件之間進行標準化比較。由於凌晨3點到5點這段時間IO最爲活躍，作者觀察到從凌晨3點到5點，以及凌晨5點之後的幾個小時，任務的IO耗時最長。儘管這個IO峯值時間段傳輸的數據最多，但相對來說，這段時間內任務的IO所花費的時間波動還是比較小的。
有意思的是，如圖9（c）顯示，儘管IO耗時的波動在全天所有時段內都非常高（> 20％），但在峯值IO期內開始的任務而言，IO耗時的波動反而最低。CoV（波動係數）是針對同一時刻開始的對同一文件的任務進行計算的。IO波動CoV趨勢（圖9（c））與IO耗時趨勢圖幾乎相反（圖9（b））。實際上，IO耗時和IO的CoV的相關指數爲-0.94，這表明兩者之間存在強烈的負相關性，也就是說，當IO活動最頻繁的時候，用戶可以預期的IO耗時變化反而會略低，即，如果用戶A每天在繁忙的IO活動期間開始相同的任務，與在IO活動不那麼頻繁的時間段啓動相同任務的用戶B相比，用戶A的任務IO耗時波動更小。當然，要權衡的是用戶A所花費的平均IO耗時要比用戶B長。這是因爲當IO活動頻繁時，OST競爭激烈，這可能會減慢所有IO，因此，IO耗時變化較小。但是，OST處於非競爭狀態，並且IO更快時，IO耗時的波動趨勢就更加明顯。
發現9.不同時段的IO負載不平衡會導致同一任務的IO耗時在一天中的不同時段有所不同。而且，IO耗時的波動偏差在一天中的時段分佈與IO耗時呈強烈的負相關性。這表明，HPC系統需要使用新的技術來降低各個任務中的IO耗時偏差（即同一應用程序的進程完成IO耗費時間偏差較大），因爲目前IO耗時的偏差在全天所有時段內仍然較大（> 20％）。
不同任務的IO波動。接下來要解決的下一個問題是，如果存儲系統負載存在時間分佈上的不平衡，是否會導致IO耗時在不同任務上發生變化？在發現9中揭示的是同一時段內開始的任務中的IO波動。現在需要看看不論開始時間段如何，訪問同一文件的不同任務的IO波動。首先，作者探討針對同一文件，不同任務的數據傳輸量偏差。圖10（a）顯示了對於一個文件，不同任務傳輸數據量CoV的CMF。總體而言，超過80％的文件的CoV小於5％，這表明從不同任務的IO傳輸數據量的變化波動微不足道。RH文件如此，RW文件更是如此，同一個RW文件在絕大多數情況下，都會被任務產生和消耗相似數量的數據。同一個WH文件在不同任務中傳輸數據量的波動最大，平均CoV爲35％。
圖10（b）顯示了每個文件在不同任務中的IO耗時的CoV。針對所有文件，即使不同任務間傳輸的數據量沒有顯着變化（上面的結論），但傳輸此數據所花費的時間卻存在很大的差異：兩次任務之間的IO耗時的平均CoV爲39％。RH文件在不同任務的IO時間偏差最大，平均CoV爲68％，即使它們傳輸的數據量變化最小。這是由於以下事實造成的：由於時間負載不平衡，OST在不同時間段競爭程度不同，由於讀任務平均傳輸的數據量少於寫任務（發現6中討論的那樣），因此這種負載不平衡的影響在其任務的IO耗時上尤爲突出，進而對RH的影響最大。
發現10. HPC文件往往在不同任務中傳輸的數據量相似，但是就傳輸數據所花費的時間而言，它們的確存在很大差異。對於RH文件而言，IO數據量的波動最小，但IO耗時波動最大，這意味着大家需要對RH文件的IO耗時波動偏差投入更多關注和改善。
04 後記
Cori特定環境和工作負載的影響。正如預期的那樣，論文的各個發現受到在美國國家能源研究科學計算中心（NERSC）和Cori在NERSC系統環境中執行的HPC負載的影響，仍然具有一定的侷限性。因此，論文的發現不能照原樣推廣到所有HPC系統中，但是論文所描述的工作提供了一種方法論，可以在其他HPC中心進行類似性質的研究，從而優化HPC中的存儲系統。
我們認爲，這篇論文的最大意義，並不在於其揭示了Cori中HPC負載的IO特點，而在於其描述了一種事實可行的調查IO模型及IO波動等特性的方法論。任何大型的HPC系統，都不是一蹴而就的，任何調優也不能是無根之水，只有基於科學的調研和分析，才能做出最合理的優化和配置。
參考資料
1.https://www.usenix.org/system/files/fast20-patel_uncovering.pdf
2.https://www.usenix.org/sites/default/files/conference/protected-files/fast20_slides_patel.pdf
3.https://sc18.supercomputing.org/proceedings/workshops/workshop_files/ws_pdsw109s2-file1.pdf
4.https://en.wikipedia.org/wiki/Coefficient_of_variation
5.https://www.mcs.anl.gov/research/projects/darshan/
6.https://www.top500.org/list/2019/11/
7.https://en.wikipedia.org/wiki/Coefficient_of_variation
8.http://hpcugent.github.io/vsc_user_docs/pdf/intro-HPC-windows-gent.pdf