大資料面試那些事（1）

來源：大資料左右手

摘錄於知識星球星友問題：主要是常見面試問題，結合自己的開發經驗，做出的個人回答，僅供參考。文末留言，提出不足和你的見解！

可以講講Flink的最佳化嗎，具體以專案中某個例子舉例一下。

最佳化的話：可以參考下面幾點

1. GC的配置

（1）有必要的時候調整老年代與新生代的比值 或者 更換垃圾收集器 。

（2）有必要的時候增加JVM記憶體。

   2. 資料傾斜

（1）需要重新設計key，以更小粒度的key使得task大小合理化。

（2）當分割槽導致資料傾斜時，需要考慮最佳化分割槽。避免非並行度操作，有些對DataStream的操作會導致無法並行，例如WindowAll。

（3）呼叫rebalance操作，使資料分割槽均勻。

（4）自定義分割槽：使用一個使用者自定義的Partitioner對每一個元素選擇目標task，由於使用者對自己的資料更加熟悉，可以按照某個特徵進行分割槽，從而最佳化任務執行。

1. checkpoint

（1）頻率不宜過高。

（2）超時時間不要過長，一般在頻率一半。

（3）可使用非同步。

1. 其他配置

（1）配置JobManager記憶體。

（2）配置TaskManager個數。

（3）配置TaskManager Slot數。

........

1. 其他

(1)背壓的時候大家往往忽略了資料的序列化和反序列化，過程所造成的效能問題。

(2) 一些資料結構 ，比如 HashMap 和 HashSet 這種 key 需要經過 hash 計算的資料結構，在資料量大的時候使用 keyby 進行操作， 造成的效能影響是非常大的。

(3) 如果我們的下游是 MySQL，HBase這種，我們都會進行一個批處理的操作，就是讓資料儲存到一個 buffer 裡面，在達到某些條件的時候再進行傳送，這樣做的目的就是減少和外部系統的互動，降低網路開銷的成本。

(4) 頻繁GC ，無論是 CMS 也好，G1也好，在進行 GC 的時候，都會停止整個作業的執行（SWT），GC 時間較長還會導致 JobManager 和 TaskManager 沒有辦法準時傳送心跳，此時 JobManager 就會認為此 TaskManager 失聯，它就會另外開啟一個新的 TaskManager。

1. 場景

產生背壓的時候如果定位下游計算不過來，導致上遊擠壓嚴重，這個時候想著怎麼去增加並行度也好或者利用多執行緒也好，目的就是增加計算能力。如果多執行緒計算，這個時候更多關注cpu核數，來分配更多的時間片，提高計算能力。

在sql最佳化的過程中，有沒有面試說出後比較新穎的案例，而不是老一套的八股文？

有這樣的一個場景，行為資料，列有150列左右，某個事件有order_id 屬性，現在有個需求，要取行為事件同一個order_id最新的那條資料 

平常的做法:

1. 開窗，按order_id partition by,按時間 order by
2. 排序
3. 取序號為1

如果資料量大的時候，over開窗很容易oom，那怎麼最佳化可以達到取出最新資料呢？

1. max(order_id + 時間 + 其他欄位)
2. 取值的時候 spit 擷取，按下標取值即可

手段很多，看你怎麼靈活運用。

Redis是多執行緒還是單執行緒的？為什麼那麼快？

首先，採用了多路複用io阻塞機制。

然後，資料結構簡單，操作節省時間。

最後，執行在記憶體中，自然速度快 – 完全基於記憶體，絕大部分請求是純粹的記憶體操作，非常快速。資料存在記憶體中，類似於HashMap，HashMap的優勢就是查詢和操作的時間複雜度都是O(1)。

• 資料結構簡單，對資料操作也簡單，Redis中的資料結構是專門進行設計的；
• 採用單執行緒，避免了不必要的上下文切換和競爭條件，也不存在多程式或者多執行緒導致的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的效能消耗；
• 使用多路I/O複用模型，非阻塞IO；
• 使用底層模型不同，它們之間底層實現方式以及與客戶端之間通訊的應用協議不一樣，Redis直接自己構建了VM 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求；

請詳細解釋介紹一下多路複用io阻塞機制？

• IO：網路IO，作業系統層面指資料在核心態和使用者態之間的讀寫操作。
• 多路：多個客戶端連線(連線就是套接字描述符，即Socket)。
• 複用：用一個或多個連線處理，其實就是用一個服務端連線進行處理多客戶端的請求。