用 C++ 實現 Spark 有意義嗎？

01-05

1、關於生態圈問題，C++ 如何與使用 Java 作為開發第一開發語言的 Hadoop 生態圈融合？現有的技術 CORBA 做為銜接如何？或使用 Zeroc Ice 等中間件做處理？還是會存在效率問題或開發難度？
2、可能有人說Scala提過Actor模式方便並發編程，C++ 目前也有不少 Actor 模型的並發庫可以使用，例如 Theron、CAF - C++ Actor Framework 等等；可否一試？
3、C++ 帶來的可以移植性也將是一個問題？可以學習Nginx那樣，先以類Unix系統平台加以實現嗎？
4、C++ 方面並沒有很好的序列化解決方案，該如何破？
（歡迎大家多多補充，擼袖準備開干！）

Nginx沒有出來以前，誰會想到重寫個Web伺服器呢？而且用c重寫？你腦子裡有吧，用這種沒有RAII，沒有智能指針，需要自己管理內存，沒有構造析構，沒用異常，沒用多態，沒有stl，沒有模版，所有輪子自己造，現代語言一個優勢都沒有的老東西來重寫？c語言不如java的，你看tomcat jboss馬上就要成為標準了。再說apache可是一群黑客一起寫出來的經典，你寫出來誰會用呢？你能兼容apache現有的模塊嗎？告訴你apache的模塊已經是生態，你那點優勢沒用的，apache也會升級，然後把你的優勢全乾掉。

事實呢，apache正在被不斷蠶食。所以客戶是最沒有忠誠度的一幫人，只要寫出來性能更好，更好配置的新版本他們就會迫不及待的用起來。所以最關鍵的是你做出來東西的品質。你只要保證最後的結果品質。反正那幫人只會用用，他們只會開開車而已，對於造車就不要指手畫腳了。

C++ 的坑太多而必要的 feature 又不足（比如可序列化的 closure），不太看好 C++ 版的 Spark，即便做出來，應該也挺難用的。

不過我個人挺期待有人來實現 Rust 版的 Spark。當然 Rust 現在也還沒有可序列化的 closure，不過基於 LLVM IR + compiler plugin 目測不是特別困難。或者更進一步說，希望能夠出現 native 的類 Spark 計算引擎。當然，跟 Hadoop 的交互會成為一個大問題。不過印象里 Hadoop 本身也有計劃通過 Avro RPC 來暴露語言無關的通訊介面，所以這個問題今後或許會有所改善？

Spark 當初選擇 Scala，很重要的一個原因當然是為了和 Hadoop 互操作。但 JVM 本身很多時候確實已經成為系統優化的一大桎梏，比如嚴重的 GC 停頓導致大數據量的分析任務跑不下去。其他答案中說單機性能不足，多上幾個節點就好了。但是節點多了，往往也會遇上 scalability 的問題。所以提高單機性能仍然相當有必要。Spark 近期展開的 Project Tungsten 實際上就是為了在維持 JVM 這個大前提下利用 unsafe 盡量往 native 靠近以大幅提升性能，為未來五年做準備。目前來看，Tungsten 已經有了明顯的效果。一方面是現有作業的性能往往可以有明顯的提升，另一方面是原先在給定集群規模下由於受制於 JVM 內存管理而跑不了的數據量，現在也可以輕鬆跑起來了。

由於現有的生態優勢，全部使用 C++ 重寫 Spark 意義不大。

但是如果谷歌開源了，那就是另外一種場景了。

Spark』s relatively high CPU time may also stem from the fact that Spark was written Scala, as opposed to a lower-level language such at C++. For one query that we re-wrote in C++, we found that the CPU time reduced by a factor of more than 2×. Existing work has illustrated that writing analytics in C++ instead can significantly improve performance, and the fact that Google』s MapReduce is written in C++ is an oft-quoted reason for its superior performance.

出處：Making Sense of Performance in Data Analytics Frameworks

鏈接：https://www.eecs.berkeley.edu/~keo/publications/nsdi15-final147.pdf

論文中也提到了 Spark 的一些性能上的問題：

從1.1開始引入的壓縮數據格式 Parquet，犧牲 CPU 時間，減少 IO 時間。
從硬碟讀取的數據需要反序列化成 Java 對象。

正是因為 Spark 的一些任務可以將接近一半的 CPU 時間用於反序列化、解壓數據上，所以才會建議大家緩存一些中間結果來減少任務時間。

沒意義。脫離了整個Hadoop生態圈，誰用啊。你怎麼去說服人家，拼信仰么？

除非哪天Google良心發現把內部的GFS/MapReduce/BigTable/Chubby的實現一下子都給開源了，否則罵歸罵，大家還是會繼續圍著JVM打轉。

在討論哪種選擇更有意義之前，人們往往忘記了他們根本就沒得選。

沒有意義。

c++版的分散式計算有Phoenix（基於mapreduce）和Dato（前身是GraphLab，類似於Spark mllib），運行效率的確高了不少，然而又有什麼卵用？有幾個人用過這兩個東西？

spark和hadoop的強大之處，在於完整的生態圈，簡單易用編程範式，完善的說明文檔。除非能在這三點上都有超越，否則替代spark就是不可能的。

====================================================

貼幾張c++版本和jvm版本的運行時間對比圖，c++版本的高了很多，又如何？

今天再看Dato，已經提供了python api，可以跑在yarn集群上，還可以和spark做交互操作了。這樣看來這個項目還有挺大希望的。

並沒有，hadoop是純java，spark是基於jvm的scala，storm一樣是基於jvm的。不要再想用c,c++什麼的可以提高效率了，以後時間，人力才是最寶貴的資源，要是用c++實現spark，並發控制，進程同步，以及大量的計算邏輯的編寫難度要難多少倍。再加上c++還是依賴硬體平台，遠沒有jvm的跨平台優勢，萬一在不同機子上出了bug怎麼辦。而且，如果不是非常好的程序員，寫出來的演算法效率還遠比不上jvm自帶的功能，何必費盡心力地搞高效率的c++呢，集群多上兩台電腦好了。。。

有意義啊.做出來你就知道意義在哪了

C++做閉包不是非常友好（或者說沒有java/scala那麼方便），所以如果要follow Spark的思路去實現C++版本的Spark會發現jvm中簡單lamda函數閉包串列化，在C++需要額外的許多操作，這對於提交任務的用戶而言實在是不太友好。

此外如果你要使用類似jvm中的范型 + 多態 + RTTI 的編程模型，會被C++編譯器打臉：C++ class member function templates can"t be virtual。你需要手動的寫type erasure的代碼（可以使用boost:any）來進行。

所以，簡單來說，如果只是簡單的移植spark所有的代碼邏輯到c++裡面，沒那麼方便，對於使用者而言也沒那麼方便。

以上。

據我所知，有一些team已經開始在spark中用native替代JVM，來提高效率。

百度不是已經造了一個了，叫elf，得百萬美元最高獎。

那些底層的Jar也要用C++實現？

聽說有搞spark師兄進阿里做的就是這個事

贊！

沒啥意義