實時資料的去中心化是Streamr專案很重要的一部分。在全球資料產量日益增長的背景下，尤其是隨著物聯網的廣泛採用，更多針對大資料的點對點解決方案很可能成為提高吞吐量的必要條件。在成熟的P2P MapReduce式解決方案可用之前，我們必須在可預見的未來訓練ML模型等時迴歸到集中式解決方案。這就是為什麼我們為當今最常用的大資料處理工具之一Apache Spark建立了Streamr整合模板。
在構建能夠處理萬億位元組甚至千萬億位元組的資料架構時，通常需要多種不同的工具。 工具的高速執行、水平擴充套件非常重要。您可能需要像Apache NiFi這樣的工具來輕鬆處理架構內的資料傳輸，以及Apache Cassandra和HDFS等工具來儲存資料，以便在之後的使用中實現資料快速恢復。
您可能還需要在架構各個不同結點計算資料的工具。例如，當使用機器學習時，您需要訓練ML模型直至其能夠使用大量已儲存資料，進而在新資料集到來時您能夠實時使用訓練模型。如果您還需要基於機器學習進行視窗異常檢測又該怎麼辦？ 您可以探索並設定不同的工具來應對每一種情況—— 或者您可以使用Apache Spark。
Apache Spark是一個用於大規模資料處理的開源統一分析引擎。最初設計是為了成為比Hadoop MapReduce更快的替代品，它聲稱較Hadoop MapReduce的執行速度提升了100倍。Spark具有的彈性分散式資料集（RDD）是效能提升的主要原因。RDDs使得在記憶體中進行分散式計算成為可能，這是其較MapReduce效能提升的主要原因。實際上，由於不太可能在記憶體中獲取所有資料，因此在大多數情況下這種提升是不太現實的。但是，RDDs會將所有不適合記憶體的資料溢位到磁碟容錯，因此您不必擔心記憶體管理。但這也意味著Apache Spark的效能會基於磁碟中的資料量增多而下降。
除了對HDFS，Cassandra等資料來源的大型資料集進行計算外，Spark還為Spark SQL（結構化資料），Spark Streaming，Spark MLlib（機器學習）和Spark GraphX（圖處理）提供了庫。對於Streamr而言，重要的是Spark SQL還具有結構化流處理功能。使用結構化流處理，您可以在微批或更大的視窗中對JSON格式的Streamr資料進行實時計算。實時資料的分散化是Streamr專案的重要組成部分。
我們為Java和Scala都提供了Streamr整合模板。對於Java，只有一個使用Sparks 自定義接收器抽象類的Spark Streaming直接整合模板。目前還沒有直接釋出資料的示例，因為Streamr的Java客戶端不能在Spark的執行程式之外工作。如果您希望直接從Spark釋出資料到Streamr，您需要直接呼叫Streamr的Data API。
對於Scala，就有更多與Streamr整合的示例。在Scala中為結構化流處理和Spark Streaming提供了類似於Java整合模板的直接整合示例。以下是用Scala實現Spark的Streamr訂閱自定義接收器的示例程式碼：
還有一個Node.js指令碼，允許您將歷史和實時資料從Streamr提取到檔案系統，以及一個Scala模板，用於解決如何使用Spark SQL處理已建立的JSON檔案的資料。同時還提供了如何使用Apache NiFi從Streamr提取資料並將資料通過Kafka傳輸到Spark進行分析的示例。您也可以反向執行該過程，並將分析的資料釋出回Streamr。使用Spark的Python版本PySpark也可以通過這種開箱即用的NiFi處理器直接從NiFi將資料傳輸到Spark。
一旦Streamr的Java客戶端處於更穩定的狀態，我們就可以釋出Streamr的自定義Spark接收器和sinks節點到Maven。這將使Streamr與Apache Spark的整合變得更加容易，因為您只需要在沒有任何替換方法的情況下，將Maven庫宣告為Spark啟動指令碼中的依賴項。目前，整合儲存庫中記錄了如何在Java或Scala中利用Apache Spark開始使用Streamr資料所需的步驟。
Spark的流媒體庫有一個明顯漏洞，即資料處理實際上並不是針對流中的單個事件實時完成的。相反，Spark Streaming和結構化流處理以微批進行計算。這意味著您經常會看到多個輸出，因為微批往往包含多個數據點。這就是Apache Flink作為實時資料處理的更佳候選者所在。Apache Flink在事件中進行實時處理，因此每個到達的資料集在其自己的視窗中只處理一次。我們也與Apache Flink進行了整合，很快就會發布。
如果您是一個對Streamr堆疊感興趣的開發人員，或者有一些整合的想法，您可以通過GitHub或者社群論壇與我們溝通。