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時，好好計劃分析場景並評估響應時間還是很有價值的。
請提供關於你以互動方式處理的資料量的上限的相關經驗反饋。