淺談大資料之語言和資料壓縮比

不知道大家有沒有看過這篇關於TWritter的文章《看Twitter如何應對大選：少些Ruby 多些JAVA》。

有興趣的朋友可以去搜索一下看看。

文中說：奧巴馬和羅姆尼的選舉日當天，Twitter伺服器每分鐘處理的數目為327452條！ 當天人們在Twitter上發佈了3100萬條跟選舉相關的內容，而Twitter訪問量階段性飆升，一度達到每秒15107條。 在互聯網世界裡，真正成功的不是奧巴馬，而是Twitter，因為Twitter這次沒有宕機。

「作為遷移Ruby的一部分，我們重新配置了伺服器，移動用戶端的訪問將通過JAVA虛擬機器堆疊，從而避免與Ruby堆疊同時進行」，Rawashdeh如是說，「能承受這樣的負載得益于Twitter利用JAVA改寫了Ruby on RailsTwitter。 起初公司內部是反對JAVA，支援Scala，而今，Twitter將Scala和JAVA結合了。

而Hadoop作為大資料的開放框架中的巨獸，處理過的資料量難以估量。 它也是基於JAVA開發的。

筆者研發的BI產品系列也基於JAVA，競爭對手在國外一般就是Cognos、BO和BIEE等。 從所經歷的客戶選型來看，客戶往往對我們的兩大利器頗有讚譽：一是資料的高性能計算，二是資料視覺化。 這兩個方面都是筆者親手一磚一瓦搭建起來的，所以也有點發言權：準備用JAVA處理大資料的童鞋，請放心服用。

筆者經常在工作中網路上看到有童鞋說海量資料處理、海量資料計算不能用JAVA，得要用C或者C ，云云。 每次只能一笑了之。 大多數時候，辯論是完全沒有意義的，因為沒有標準答案。

經常看到一些資料倉儲產品講資料壓縮比，壓縮到1/10以上，省盤90％云云。

筆者以為，對於MPP節點之間的資料傳遞，綜合網路頻寬也許需要比較狠的資料壓縮，除此之外省盤聊勝於無，它並不太重要。

現在PC機的磁片標配都是TB了，省不省盤沒啥用處，還可能有副作用。 分析如下：

當處理海量資料計算請求的時候，一般都需要把資料裝載入記憶體，如果有壓縮，需要在記憶體中展開資料再進行計算。 一般的Developer都知道，展開資料是一個容易導致頻繁記憶體申請和釋放，而解壓縮又極可能是一個比較消耗CPU的過程。

所以，當衡量一個資料倉儲或者資料集市產品的時候，省盤可以考慮一下，更重要的是去考慮它是不是省記憶體、省CPU、省時間。

一款好的產品，會有比較好的記憶體設計去省略或優化資料展開的過程，這一過程不會導致頻繁的記憶體申請和釋放；基於高性能的考慮，它會選取高效的辦法去裝載磁片資料或丟棄記憶體資料，以追求最快回應；而在CPU負載上， 則會儘量節省CPU計算量，做到海量資料即時計算。

因而，在衡量一個資料倉儲或者BI產品的時候，建議基於一系列的磁片、記憶體和CPU配置，進行測試。