Apache Spark在內存數據處理領域有很多創新。有了這個框架，你可以上傳數據到集群內存，并在交互模式下以非常快的速度處理這些數據(交互模式是Spark另一個重要特性)。2014年 Databricks宣布 Apache Spark能在23分鐘內完成100T數據的排序。
這里有一個有趣的問題—— 你可以在集群中以交互方式處理的數據量的上限是什么?如果你的集群中有100T數據呢? 你可能驚訝內存竟然如此之快。直覺告訴你可以內存可以交互式處理100T的輸入數據或者至少能處理一半的規模。然而，像往常一樣，在分布式系統的世界，我們的直覺是錯誤的。
交互式Apache Spark
1. 響應時間
對于一個簡單的數據處理場景和一個比較復雜的，各自的響應時間是什么?那我們還是在一個交互模式嗎?我們應該這樣思考，但是很不幸，我們沒有。我看到的是，在實際的場景中，一個有8T數據的“where sum(), count()”語句的簡單場景的響應時間是20-40秒。對于更復雜更實際的情形(有幾個“group by”和幾個“join”)，響應時間是3-5分鐘。這絕不是我說的交互模式!
在日常生活中，我只會在響應時間比較關鍵的情形下作分析。對我來說，3到10秒之后我就會放棄，好吧也許會到15秒之后我仍然認為這是交互模式。除此之外，我會認為它是批處理模式。和MapReduce之類的磁盤處理相比，幾秒鐘或是3-5分鐘替代了15-60分鐘可能看起來比較不可置信。然而，這不是交互式的。
2. 交互在哪里結束?
交互模式下幾秒延遲內我能處理的最大內存數量限制在1TB以內。盡管這樣，效率還算不錯的。然而，超出了1TB，我發現響應時間被極度延長了。
我猜測是為了提高效率(5-10TB只有幾秒鐘延遲)，我們需要更新硬件(我想嘗試一個擁有非常強大的EC2機器，250GB的RAM存儲的集群)，以及調整軟件設置(Apache Spark驅動設置，內存列格式，可能還有YARN設置)。
即使軟硬件都更新了，我很清楚，交互模式的限制也不會接近100TB。
3. 先把數據讀入內存
正如你回想起的一樣，要記住你每迭代一次數據處理都會花費數秒甚至數分鐘。然而，這并不是故事的結局。如果你正用Ad Hoc分析或者是創建機器學習模型，你的初始數據集很大可能都存放在一個HDFS存儲集群中。這意味著在內存迭代操作之前，你應該先從耗時較長的磁盤中讀入數據。按往常，性能通常依賴于硬件和軟件設置。更可能的是，讀一個5-8TB的數據集耗時在15-30分鐘之間。即使是1TB數據也會消耗5分鐘左右。
總結
在接觸Apache Spark內存處理之前，特別是數據集超過1TB時，好好計劃分析場景并評估響應時間還是很有價值的。
請提供關于你以交互方式處理的數據量的上限的相關經驗反饋。
京公網安備 11010502049343號