儲存格式的選擇：
採取行式還是列式儲存？
列儲存寫入時次數多，損耗時間多
反過來查詢的時候較快
壓縮格式的選擇：
考慮壓縮速度和壓縮檔案的分割性
壓縮能夠較少儲存空間、提高資料傳輸速度
**的優化：
選擇的高效能的運算元：
foreachpartition => partitionofrecords.foreach 獲得每一條資料
分割槽的好處是把partition所有的資料先儲存到list當中去，然後我們在插入mysql的時候就可以結合pstmt的批處理，一次過把整個分割槽資料寫進去
復用已有的資料：
在專案中，如果同時實現多個功能（本例中就是有三個），在計算時觀察每個功能間是否有重疊產生的資料，若有的話把相應的資料提取出來生成，所有的功能實現都能共用（相當於做乙個快取，把中間資料cache ）
引數的優化：
並行度：spark.sql.shuffle.partitions
預設的是200，配置的是partitions的數量，對應了task的數量
若覺得執行得太慢，則需要吧這個值調大
在conf裡面改（yarn啟動時）
分割槽字段型別推測：spark.sql.sources.partitioncolumntypeinference.enabled
預設為開啟，若開啟之後系統就會自動推測分割槽欄位的型別
關閉後能提公升效能
專案中的效能優化
在實際專案中，由於需要把介面返回來的物件存在資料庫中，所以用到了jackson元件把物件轉成json後再保持到資料庫中。由於每天處理的資料量太大，而業務對時間的要求非常嚴格，即使採用4臺機器做分布式後，計算時間仍然在2 3個小時，於是效能優化提上了日程。用jprofiler工具觀察到效能主要在兩個地...
專案中如何優化細節
一.記憶體優化 1.減少記憶體洩露。如timer，delegate，block，corefoundation物件 c物件 image 2.降低記憶體使用峰值。如使用懶載入 二.效能優化 卡頓產生的原因 cpu計算時間以及gpu渲染時間較長，造成vsync 垂直同步的訊號 重新整理銜接不上 解決卡頓主...
專案中優化查詢速度案例
近期在專案中遇到的問題在本文記錄一下。首先業務內容是通過ip去mysql中查詢相應資訊，批量匯入ip進行查詢。庫中的資料量大約為553萬條。一開始用遍歷單條查詢的方式查詢資料非常慢，查詢1.7萬條數需要十幾分鐘 這也太慢了 網頁都超時了。專案啟動時讀資料到專案中 不推薦 最開始想到的方法就是空間換時...