Leo Yeh's Blog

SAS Viya (59)

教學目標

初步了解 SAS Viya 平台部署之前的資源建議配置。(此篇為心得分享)

重點概念

首先 SAS Viya 主要提供可擴展的資料處理步驟和統計程序有效平行處理大量資料,並且透過高效能的硬體架構解決方案來支持可擴展性和大數據模型,以利提高使用者體驗,以及在短時間內提供最大的商業價值,至於 SAS Viya 高效能設定的最佳實務我們主要會修改硬件和網路選項,像是 CPU、記憶體、CAS_Disk_Cache 設定和伺服器之間的網路頻寬,以利我們透過平行處理快速地完成非常長時間執行或高資料量的作業,當減少作業執行時間,將有益於資料管理和建模工作負載。而在 SAS Viya 中平行處理主要可以透過以下幾個方面來實現,分別為:

  1. 根據 I/O、記憶體使用情況和內容優化所有低效率程式碼和任務活動,
  2. 橫向擴展硬體基礎架構,以利支援平行負載和處理任務集的即時資源需求。
  3. 透過適當硬體規模調整、規劃和設定,以利支援應用程式工作負載的績效目標。

接著根據 I/O、記憶體使用情況和內容優化所有低效率程式碼和任務活動,有許多使用 SAS 9 的客戶所撰寫的 SAS 程式碼我們除了可以透過調整程式碼獲得更高效能的資料處理之外,更能夠 CAS 橫向擴展作業架構進行高效能的處理工作任務規模。此外在 SAS 中處理資料的效率主要與將被提升至記憶體中的資料進行排序和分析處理有關,若是 SAS 9 使用者則會認為執行此操作的最佳方法是使用 PROC SORT,但是在 SAS Viya 中我們使用DATA STEP 程式碼和 BY GROUP 處理來取代 PROC SORT,主要原因有兩個,分別為:

  1. 記憶體速度:SAS Viya 主要執行記憶體中的程序,其需要保持在記憶體中才能正常執行,而 PROC SORT 是使用 SAS 9 中的記憶體,因此我們將其替換為 SAS Viya 中的DATA STEP 程式碼,以利透過更少的記憶體更有效的執行任務。
  2. 平行工作負載管理:DATA STEP 程式碼主要可以利用 CAS 中的高度並行處理資源 (Parallel DATA STEP),其可以將資料進行劃分,並且發送到大量擴展的伺服器,並且同時在許多伺服器的記憶體中進行處理,這大大減少了整個工作負載時間,僅佔原始任務執行時間的一小部分。

此時我們透過適當硬體規模調整、規劃和設定,以利支援應用程式工作負載的績效目標,我們主要針對工作負載進行規劃,SAS Viya CAS 和 SAS 9 在操作和效能方面有很大差異,對於大小調整和設定,需要考慮常見的工作負載關鍵因素,分別為:

  1. 資料擷取的類型是序列或平行,以及 SMP 架構或 MPP 架構。
  2. 混合作業類型所需的 I/O 、CPU 和記憶體,以及平行處理的作業數量。
  3. 期望執行的時間或解決方案的時間,工作負載資源管理資源限制和優先順序。

深入了解上述關鍵因素,以利協助調整 CPU 核心數、記憶體大小和速度、網路頻寬和速度、儲存容量和輸出量以及主機系統或應用程式的工作負載限制等系統管理資源 (cgroup、ulimit、…) 的要求。請注意 CAS是一種記憶體處理系統,我們主要透過 CAS 在記憶體中以高記憶體的速度進行資料處理,替換記憶體對應,以利透過傳統文件系統從磁盤向磁盤進行較慢的硬分頁,記憶體大小和效能非常重要,透過並行處理 CAS 作業和提高記憶體處理速度將有助於縮短解決方案的時間,此外由於許多工作任務是並行啟動的,因此需要大量資源來滿足瞬間負載的需求。

再來在 MPP 架構中我們可能會被分配 CAS 主節點、CAS 工作節點和微服務節點,而微服務啟動時將會需要初始化 60 GB 的記憶體,若我們嘗試將 CAS 微服務與另一個節點相結合,此時我們必須提供足夠的CPU 、記憶體、網路和 I/O 等要求。其中 CAS 授權的最小 CPU 核心數為 4 個核心,並且強烈建議啟用 Hyper-threading。而記憶體建議為傳入文件大小的 2-3 倍以上,以及建議使用最低記憶體速度為 1600 MHz。而網路主要涉及讀入的非常大的資料來源和結果集,建議 SMP 架構提供每個主機核心數至少每秒 100 MB 的網路頻寬,而 MPP 架構建議每個 CAS 伺服器節點使用多個 10 Gbit 最小適配器來實現所需的頻寬,像是若在 CAS Worker 節點中使用 16 個核心數,則通常需要的最小帶寬為每個核心至少每秒 100 MB 的網路頻寬,或著每個節點的總頻寬為 1.6 GB 的網路頻寬。

最後我們針對資料傳輸的 I/O 主要探討載入到 MPP CAS 的序列資料,CAS Controller 將會對本地磁碟上的傳入資料,當所有資料皆傳入完成之後,CAS Controller 就會將資料分發給 CAS Workers,也適用於將數據儲存回雲端提供商,像是 Amazon S3,此時所有 CAS 伺服器節點的臨時暫存該資料的本地磁碟位置建議 I/O 頻寬為每秒 100 - 150 MB。此外當我們發生資料超過記憶體空間時,CAS 則會使用記憶體對應的檔案系統 (CAS_Disk_Cache) 為後續記憶體資料的存儲提供額外的空間。所謂記憶體對應的檔案系統主要是將虛擬記憶體對應至另一個資料來源,像是 HDD、SSD 或 NVMe 儲存設備,而 CAS_Disk_Cache 會指定記憶體對應的檔案系統,其主要是​​一個儲存記憶體可存取 CAS 資料區塊的位置,或由 CAS 處理需要後續儲存或複制副本,其資料區塊預設大小為16MB,我們能夠增加至 512 MB,以利更高效地操作非常大的文件檔案,以及建議 CAS_Disk_Cache 的大小至少為 CAS 節點中記憶體大小的 1.5 - 3 倍。至於有關主機系統或應用程式的工作負載限制等系統管理資源 (cgroup、ulimit、…) 的要求,這些部份之後有空再分享啦!

相關資源

⬅️ Go back