性能調優的最佳實踐

[isaac_gritz]

對於磚的性能調優的最佳實踐建議

我們也建議檢查這篇文章從我的同事@Franco Patano磚性能調優的最佳實踐。

性能調優您的工作負載是一個重要步驟之前將您的項目投入生產,以確保你得到最好的性能和最低的成本,以幫助滿足你省錢並滿足sla。

磚上的調優時,重要的是遵循框架如下圖所示:

1. 首先,注重基礎,文件布局。有效的文件布局是最重要的關注任何MPP係統1)減少開銷從太多的小文件,2)減少或刪除數據傾斜,3)減少你所掃描的數據量和閱讀到MPP係統中。
2. 一旦文件布局優化,然後你可以優化你的代碼庫刪除潛在代碼瓶頸。
3. 最後,一旦你優化的文件和代碼,你可以調整你的工作負載,選擇最優為您的工作負載集群配置。

繼續下麵的

[isaac_gritz]

文件布局優化——建議有效的文件布局

1. 利用三角洲湖對你的工作負載開啟z值聚類等性能。
2. 使用z值(AWS|Azure|GCP)在高基數列常用過濾器。z值工作類似於索引和把相關數據顯著減少需要讀取的數據量,從而導致顯著的性能改進。
3. 使用計算統計分析表(AWS|Azure|GCP)收集列統計列經常用於連接和過濾器。這些列磚基於成本的優化器所使用的統計數據自適應查詢執行確保最優的查詢計劃是選擇你的工作量。
4. 使用分區(AWS|Azure|GCP)分區最大的表由低基數列常用過濾器(這通常是日期列)。我們不推薦分區表小於1 TB,因為這可能導致跨越式你的數據集。DBR 11.2 +,攝入時間聚類將保留你攝取的天然日期順序數據,消除需要分區或z值在表1 TB和導致偉大的開箱即用的性能。
5. 為工作負載合並和寫操作頻繁,你的工作量可能會受益於自動調諧基於工作負載(AWS|Azure|GCP),而不是默認的基於表的大小。
6. 你的工作量可能會受益於增加並行通過設置火花洗牌分區汽車(AWS|Azure|GCP)

[isaac_gritz]

代碼優化——建議避免代碼瓶頸

1. 避免操作等操作打印,收集,數在生產中管道。這些操作力火花立刻執行,而不是流水線多個操作和確定最佳的查詢計劃。
2. 盡可能避免使用抽樣。抽樣API不受益於催化劑的性能優化優化器和許多磚內置的運行時性能的優化。
3. 避免單線程Python或R在多節點集群工作負載,因為這些隻會導致司機節點被利用,而工人節點仍然閑置。這包括使用.toPandas ()。
   1. 處理較小的數據集和單線程的操作,我們強烈推薦使用單節點集群(AWS|Azure|GCP)成本優化。
   2. 處理大規模數據集,我們建議利用內置的激發函數盡可能多的。當這是不可能的我們建議使用熊貓udf (AWS|Azure|GCP使用火花)分配現有的python代碼。另外,您還可以利用熊貓火花API (AWS|Azure|GCP),允許您利用90%的python熊貓功能而分發處理引發的可伸縮性。

[isaac_gritz]

集群優化——如何選擇正確的對你的工作負載集群

1. 選擇最優/ VM實例類型的工作負載。一般建議如下:
   1. Storage-optimized實例最適合大的批處理作業和特別分析
   2. Compute-optimized機器學習和結構化流工作負載
   3. Memory-optimized對於內存密集型工作負載
   4. GPU-optimized深學習工作負載
2. 使光子(AWS|Azure|GCP你的集群節省80%的TCO在分析工作量。光子是默認啟用的磚SQL的倉庫。
3. 啟用自動伸縮磚集群(AWS|Azure|GCP),DLT集群(AWS|Azure|GCP)、SQL倉庫(AWS|Azure|GCP)自動添加和刪除節點基於工作負載。
4. 啟用最新LTS磚運行時(AWS|Azure|GCP)。磚運行時符合最新的火花和磚的發展包括最新的性能增強。磚LTS運行時是支持2年以上。
5. 優化集群大小根據你的sla和集群利用率。我們建議測試幾個集群概念驗證發現集群配置,給你最好的價格表現,同時滿足sla和預期的可伸縮性。

[isaac_gritz]

在評論中讓我們知道如果你有任何其他的性能調優技巧和竅門