Spark Tungsten揭祕 Day1

jvm下的性能優化

今天開始談下Tungsten,首先咱們須要瞭解下其背後是符合了什麼樣的規律。java

jvm對分佈式天生支持

整個Spark分佈式系統是創建在分佈式jvm基礎上的,jvm很是偉大的一點在於把不一樣機器的計算能力聯合起來了,jvm也把不一樣機器的存儲能力鏈接起來了。算法

jvm是怎麼作到這一點的,jvm自己就是一個軟件,有本身的通信方式以及本身的一套協議,在進行java或者scala開發的時候,就支持了一個最重要的設計模式:代理模式,基於代理模式可使用其餘的進程,這些進程能夠在同一個OS,或者不一樣的OS上,可使用其餘地方的進程,像使用本地進程同樣。編程

jvm一個基本特徵是,代理端和實現端看起來是徹底同樣的接口,由於咱們編程時是面向接口的,因此代理模式是一個近乎完美的設計模式,既實現了面向接口編程,又能把不一樣的功能組合起來。設計模式

關於不一樣機器之間通信的細節,這個是jvm幫咱們處理掉了。因此jvm的口號是網絡即OS。屏蔽掉了不一樣機器的區別。這個帶來的影響很是的深遠。jvm正在從技術的角度實現"共產主義"目標。緩存

Scala的函數自然是可序列化與可反序列化的。這二者結合起來,致使數據和算法均可以在機器之間傳輸。這個就構建出了整個分佈式。性能優化

通常大數據系統都是運行在jvm上的,完成不一樣機器之間溝通的代價最小。jvm有一個自然的特性,是數據序列化和反序列化的能力,這個就爲不一樣機器傳輸數據打下了良好的基礎,jvm的提供這種能力可讓咱們根據接口進行數據的自定義,數據的自定義達到的好處是咱們能夠隨意進行數據建模實現咱們數據的業務邏輯,並這個建模在不一樣機器間進行傳輸。網絡

GC是jvm頭上的烏雲

jvm是一個應用程序而已,運行在一個user space進程中,從OS角度講,進程分爲兩種,一種是user space,一種是kernel space。從kernel space角度講,並無進程之間的差別,內核空間看用戶空間的一切,只是一個又一個的句柄。用戶空間進程只是註冊下,須要進行內存映射。jvm

內存映射是一種算法,用戶空間的某個地址和內核空間會進行某種公式的緩存,由於內核空間不是那麼大,可是用戶空間愈來愈大,從內核空間講,用戶空間的jvm進程是計算資源的表明,例如對core和內存的使用。分佈式

jvm當初重要的目標是跨平臺,是一種標準,提供統一的編程,底層來適配不一樣的硬件。jvm的推出,讓咱們能夠僅關心對象的使用,讓咱們在對象的三階段中解放操做,不用關心分配和銷燬。學習者和開發者的角度講簡單了不少。從整個分佈式角度考慮,jvm提供了不少的便利。相似吃自助餐,直接吃就能夠,會有服務員補餐和收餐。函數

可是,這個是有代價的,jvm會有本身的一套機制來分配和清理,可是這裏有個很大的問題,由於程序運行和gc是兩套東西,有時候會有衝突,通常gc時都要中止工做,會影響程序的運行,對實時性要求特別高的程序就特別麻煩。這個就是jvm頭上的那朵烏雲。

Tungsten緣起

爲了既享受jvm的好處,又擺脫弊端,就展開了Tungsten,Tungsten在最開始時候使用native級別的存儲空間,從而不受jvm gc的影響,而只是被咱們程序的邏輯所控制,分配和銷燬全由程序說了算。

jvm管理的空間受gc影響和native空間徹底是兩碼事。Tungsten第一階段,就是這個思路,從jvm走向native。就是把一部分的空間轉移到native級別。

第二階段是程序有效運行的問題,java是後來出現的,是C和C++的一層封裝,但這個封裝是有代價的,弊端是從語言級別,效率更爲低下,由於有一部分時間浪費在處理語言的流程和空間的使用。Tungsten作的是分析代碼,看哪些是真正有效的計算,把CPU的有效使用效率最大化。

內存、CPU沒問題了,下一步還有什麼,是磁盤和內存的切換,因此第三階段就是使用NIO的方式進行優化。

把這幾點都完成後,就能夠把機器運用到極致。

欲知後事如何,且聽下回分解!

DT大數據天天晚上20:00YY頻道現場授課頻道68917580

相關文章
相關標籤/搜索