資料傾斜
資料傾斜是我們在處理大資料量問題時繞不過去的問題，也是在面試中幾乎必問的考點。 正常的資料分布理論上都是傾斜的，就是我們所說的'二八原理'：80%的財富集中在20%的人手中, 80%的使用者只使用20%的功能 , 20%的使用者貢獻了80%的訪問量。 簡單來說資料傾斜就是資料的key 的分化嚴重不均，造成一部分資料很多，一部分資料很少的局面。
表現相信大部分做資料的童鞋們都會遇到資料傾斜，資料傾斜會發生在資料開發的各個環節中，比如：用hive算資料的時候reduce階段卡在99.99% 用sparkstreaming做實時演算法時候，一直會有executor出現oom的錯誤，但是其餘的executor記憶體使用率卻很低。
hadoop
當我們看任務進度長時間維持在99%，這裡如果詳細的看日誌或者和監控介面的話會發現：
spark
spark中的資料傾斜也很常見，spark中乙個 stage 的執行時間受限於最後那個執行完的 task，因此執行緩慢的任務會拖累整個程式的執行速度。過多的資料在同乙個task中執行，將會把executor撐爆，造成oom，程式終止執行。
flink
使用window、groupby、distinct等聚合函式時，頻繁出現反壓，消費速度很慢，個別的task會出現oom，調大資源也無濟於事。
資料傾斜原理和解決方案
在做資料運算的時候會設計到，countdistinct、group by、join等操作，都會觸發shuffle動作。一旦觸發，所有相同 key 的值就會拉到乙個或幾個節點上，發生單點問題。
乙個簡單的場景，在訂單表中，北京和上海兩個地區的訂單數量比其他地區高幾個數量級。那麼進行聚合的時候就會出現資料熱點。
解決資料傾斜的幾個思路：
hadoop/hive引數
spark 引數
flink 引數
如何處理大資料入庫和查詢問題
db的sql查詢所帶來的程式設計方面的靈活，是其他nosql方式的儲存和查詢幾乎無法取代的。就拿elasticsearch的儲存和查詢來舉例，它是很快，處理億級資料是小case。但是 1.結構發生變化怎麼辦？舉個例子，很多時候，都會由於業務的變更而某些表增加欄位的情況。對於db來說，只需要alter...
3n 1問題大資料如何處理？
題目來自codevs 3n 1問題是乙個簡單有趣而又沒有解決的數學問題。這個問題是由l.collatz在1937年提出的。克拉茲問題 collatz problem 也被叫做hailstone問題 3n 1問題 hasse演算法問題 kakutani演算法問題 thwaites猜想或者ulam問題。...
如何處理分類中的訓練資料集不均衡問題
在分類中，訓練資料不均衡是指不同類別下的樣本數目相差巨大。舉兩個例子 在乙個二分類問題中，訓練集中class 1的樣本數比上class 2的樣本數的比值為60 1。使用邏輯回歸進行分類，最後結果是其忽略了class 2，將所有的訓練樣本都分類為class 1。在三分類問題中，三個類別分別為a，b，c...