經常有人拿 Ignite 和 Spark 進行比較，然後搞不清兩者的區別和聯絡。Ignite 和 Spark，如果籠統歸類，都可以歸於記憶體計算平臺，然而兩者功能上雖然有交集，並且 Ignite 也會對 Spark 進行支援，但是不管是從定位上，還是從功能上來說，它們差別巨大，適用領域有顯著的區別。本文從各個方面對此進行對比分析，供各位技術選型參考。

一、綜述

Ignite 和 Spark 都為 Apache 的頂級開源專案，遵循 Apache 2.0 開源協議，經過多年的發展，二者都已經脫離了單一的技術元件或者框架的範疇，向著多元化的生態圈發展，並且發展速度都很快。

Ignite

Ignite 技術來源於 GridGain 公司的商業產品，於 2014 年將絕大部分功能捐贈給 Apache 社群，並於 2015 年 8 月畢業成為 Apache 的頂級專案。Ignite 目前一直保持著高強度的快速迭代式開發，基本一個季度釋出一個大版本，從提交數量、版本釋出數量等若干指標來評估，一直保持在 Apache 社群 300 多個開源專案的前五位。目前已經聚攏了來自多家組織或公司的眾多開發者，處於非常活躍的狀態，開發者社群和產品生態正在形成中。

Spark

作為 Hadoop 生態圈重要成員的 Spark 於 2009 年由 Matei Zaharia 在加州大學伯克利分校 AMPLab 開發，於 2013 年 6 月捐贈給 Apache 基金會並切換協議至 Apache2.0，2014 年 2 月畢業成為 Apache 的頂級專案。鑑於 Spark 核心計算模型的先進性，它吸引了眾多大企業和組織的積極參與，促成了 Spark 的高速發展和社群的空前繁榮，隨著 Spark 技術不斷地向縱深發展以及向外延伸，形成了龐大的 Spark 社群和生態圈，目前幾乎成為了大資料領域影響力最大的開源專案。

二、定位

Ignite 和 Spark 都是分散式架構，都歸類於目前的大資料技術類別，二者都是利用大量記憶體的高效能，為原有的技術方案進行提速，但是定位差別很大。

Ignite

Ignite 的核心定位是一個分散式的記憶體快取解決方案，通過將資料儲存在記憶體中，提供比傳統的基於磁碟的方案更快的效能。然後在分散式快取的基礎上，一方面進一步深入，通過標準 SQL 功能的引入，向分散式記憶體資料庫的方向發展，一方面功能不斷擴充套件，引入了記憶體計算、流資料處理、機器學習等功能。Ignite 部署靈活，可以輕易地整合進已有的系統，非常方便地與已有的資料庫系統整合（NoSQL、HDFS 也支援），為已有的業務進行加速服務。不顛覆已有架構，是 Ignite 很重要的邏輯。

Spark

Spark 的核心定位是一個分散式統一大資料分析引擎，通過先進的 RDD 模型和大量記憶體的使用，解決了使用 Hadoop 的 MapReduce 進行多輪迭代式計算的效能問題。然後在 RDD 的基礎上不斷完善，引入了 Dataset 和 DataFrame、SparkSQL、Spark Streaming、SparkML 等更高階的功能。Spark 對 Hadoop 技術棧有非常好的支援，很多可以直接整合，雖然也可以支援 RDBMS 的讀寫，但是這不是 Spark 主要的關注方向。

三、核心技術

Ignite 和 Spark 核心技術截然不同。

Ignite

Ignite 的核心資料結構為分散式雜湊，即鍵-值型儲存，和 Redis 等可以歸於同一類，對於分散式記憶體資料庫，核心技術來源於 H2 資料庫，也即 Ignite 對 SQL 的支援來源於 H2 的 SQL 引擎。Ignite 的核心計算模型為 MapReduce+支援 SQL 查詢的快取優化。

Ignite 的記憶體資料模型為固化記憶體架構，同時支援記憶體儲存和磁碟儲存（可選）。資料儲存在堆外，因此只要記憶體夠用，不用擔心記憶體溢位，也不用擔心大量佔用記憶體導致垃圾回收暫停。

Spark

Spark 的核心是建立在統一的抽象 RDD 之上，使得 Spark 的各個元件可以無縫進行整合，在同一個應用程式中完成大資料計算任務。RDD 的設計理念源自 AMP 實驗室發表的論文《Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing》。RDD 可以認為是 MapReduce 的超集，也即 RDD 也可以實現傳統的 MapReduce 計算機制。

四、部署模型

Ignite 和 Spark 的組網基本模式有很大的不同，但在更高層面的資源管理上，支援能力是差不多的。

Ignite

Ignite 叢集基於無共享架構，所有的叢集節點都是平等的、獨立的，整個叢集不存在單點故障。 通過靈活的 Discovery SPI 元件，Ignite 節點可以自動地發現對方，因此只要需要，可以輕易地對叢集進行縮放。

Ignite 可以獨立執行，可以組成叢集，可以運行於 Kubernetes 和 Docker 容器中，也可以執行在 Apache Mesos 以及 Hadoop Yarn 上，可以運行於虛擬機器和雲環境，也可以運行於物理機，從技術上來說，叢集部署在哪裡，是沒有限制的。

Ignite 還支援嵌入式部署，也就是和應用整合在一起。

Spark

Spark 支援四種分散式部署方式：分別是 Standalone、Spark on Mesos、Spark on YARN 和 Kubernetes。

Spark 的部署屬於 Master/Slave 模式，可能存在單點故障問題，但是可以通過 ZooKeeper 解決。

五、功能

記憶體計算

Ignite 和 Spark 都有記憶體計算的能力，尤其記憶體計算是 Spark 的主打功能，從技術原理上來看它們的能力：SparkRDD > Ignite MapReduce+Cache > Hadoop MapReduce。

但具體來說，Ignite 的計算模型優於 Hadoop 毋庸置疑。但是 Ignite 和 Spark，雖然 Ignite 技術原理上不如 SparkRDD 先進，但是落實到具體的實踐中，則要看具體的業務場景、技術人員對技術和設計的掌控力、程式碼優化程度等，無法直接下結論，這個要具體問題具體分析。

Spark 擅長的多輪迭代式計算、互動式計算、圖計算等，Ignite 則沒有對應的解決方案。

Ignite

Ignite 的計算功能原理與 Hadoop 一致，都是 MapReduce 正規化，即可以將一個批量任務拆分為多個部分，然後在不同的節點並行執行，這樣就可以並行地利用所有節點的資源，來減少計算任務的整體執行時間。

但是 Ignite 的計算有兩個重要的獨特之處，一個是鑑於 Ignite 靈活的部署模型，Ignite 可以是離線計算，也可以是線上計算，對於線上的場景，比如 OLTP 業務，它可以通過將請求中的計算負載同步地放在多個可用節點上，然後將結果返回，這樣可以提高整個系統的擴充套件性和容錯能力。 另一個是計算可以和資料並置，即計算會被髮送到要處理的資料所在的節點，這樣會使開銷最小化。

Spark

Spark 的計算模型從原理上來說，作為 MapReduce 的超集是非常先進的，Spark 也具有 MapReduce 的機制和開發介面，所以用 Spark 實現 MapReduce 計算模型是可以的。

Spark 的核心概念 RDD，作為一個通用的資料抽象，著重解決了 MapReduce 模型在處理多輪迭代式演算法（比如機器學習、圖演算法等）的效能瓶頸，避免了中間結果落盤導致的大量資料複製、磁碟 IO 和序列化開銷。但是 Spark 的計算功能是按照離線系統設計的，無法實現 Ignite 的線上計算功能。

儲存支援能力

Ignite 和 Spark 都可以將第三方儲存作為資料來源用作後續的處理，兩者對第三方儲存的支援程度、側重點完全不同。這裡說的第三方儲存，暫時劃分為傳統的 RDBMS 和 NoSQL（HDFS、Hive、Cassandra 等）。但是 Ignite 在支援第三方儲存的同時，本身還具有原生持久化的能力。

Ignite

• RDBMS：Ignite 作為一個快取系統，天然對 RDBMS 有良好的支援，基本上只要支援 JDBC/ODBC 協議的資料庫都沒有問題。對於資料的載入、資料的讀寫及其一致性（事務）保證、各種工具的支援、各種通訊協議的支援都一應俱全，是一個完整的方案；
• NoSQL：Ignite 對於各種 NoSQL 資料庫的支援是有限的，因為功能定位的原因，不是任何 NoSQL 產品都適合和 Ignite 整合進而提升能力，就目前來說，Ignite 在不同的功能場景對 NoSQL 提供了支援，包括對 HDFS 的支援，也包括與 Cassandra 的原生整合；
• 原生持久化：Ignite 基於固化記憶體架構，提供了原生持久化，可以同時處理儲存於記憶體和磁碟上的資料和索引，它將記憶體計算的效能和擴充套件性與磁碟持久化和強一致性整合到一個系統中。 原生持久化以有限的效能損失，透明地提供了更強大的功能，即使整個叢集重啟，記憶體不需要預熱，資料可以直接訪問。

Spark

• RDBMS：SparkRDD 可以將 RDBMS 作為資料來源之一，支援 RDBMS 資料的批量讀寫，也支援各種型別的 RDBMS，但是 Spark 對 RDBMS 的讀寫，屬於批量模式，Spark 更多地會將 RDBMS 作為分析型業務的資料來源之一，最後如有必要，則將業務分析的結果批量回寫 RDBMS；
• NoSQL：Spark 原生支援 JDBC、JSON、Parquet、csv、libsvm 以及 orcFile 等，也可以通過擴充套件介面自定義資料來源。Spark 可以直接或者通過各種聯結器讀取 Hive、Hbase、Cassandra 中的資料，然後建立對應的 RDD，寫入也是同理，這個能力是 Ignite 所不具備的；
• 原生持久化：Spark 不具備原生的持久化能力。

SQL

Ignite 和 Spark 都支援 SQL，但是兩者的定位和能力，有所不同。

Ignite

Ignite SQL 目前的語法兼容於 ANSI-99，支援查詢、刪除、更新與插入，但語法和功能與標準並不完全一致。Ignite 如果做好了資料並置，SQL 查詢的效能是很好的，同時 Ignite 還支援索引，這都進一步提升了 Ignite SQL 的能力。另外，Ignite SQL 對快取的功能進行了極大的增強，通常用於快取的線上查詢和計算，用於離線資料處理也是可以的。

Spark

SparkSQL 最初來源於 Shark 專案，後來兩者進行了合併，SparkSQL 構建於 Dataset/DataFrame 機制基礎上，目前只支援查詢，主要適用於分析型業務以及對來自不同資料來源的結構化資料進行處理。它也可以進行互動式查詢，因為不支援索引等等原因，所以效能較差，響應時間可能較長。

資料一致性（事務）

Ignite

Ignite 整體來說對事務的支援還不完善，具體來說，在鍵-值 API 層面，有完善的事務機制，主要原理來自於經過優化的二階段提交協議，但是 SQL 層面的 DML 語句還不支援事務，未來版本會解決該問題。

在計算層面，因為支援豐富的程式設計介面，也可以非常容易地與各種開源的 ORM 框架整合，所以也可以方便地對事務進行細粒度的控制，比如 CRUD 都是沒問題的。

Spark

SparkSQL 本身並不提供事務機制。Spark 本身也不適用於 RDBMS 的細粒度資料維護，RDBMS 對於 Spark 來說，只是資料的一個來源和儲存地之一，通常都是批量操作，如果批量操作失敗，Spark 有容錯機制可以重來，以保證整體的一致性。

流計算

Spark 有 Spark Streaming，Ignite 也支援流資料處理。

Ignite

Ignite 可以與主流的流處理技術和框架進行整合，比如 Kafka、Camel、Storm 與 JMS，提供可擴充套件和容錯的能力。流處理技術為 Ignite 提供了一種資料載入機制，針對流式資料，Ignite 也提供了各種處理和查詢功能。Ignite 社群官方提供了 10 種流處理技術的整合實現，利用統一的 API，開發者也可以自行開發流處理技術實現。Ignite 為所有流入 Ignite 的資料以可擴充套件和容錯的方式提供至少一次保證。

Spark

Spark Streaming 是基於 Spark 的流式批處理引擎，其基本原理是把輸入資料以某一時間間隔批量的處理，即以時間為單位切分資料流，每個切片內的資料對應一個 RDD，進而可以採用 Spark 引擎進行快速計算。其同樣支援眾多的資料來源，內部的資料表示形式為 DStream。Spark Streaming 吞吐量高，可以做複雜的業務邏輯，但是秒級別的延遲是否符合業務需求需要確認。Spark Streaming 可以與 Spark 其他技術完美整合，包括 SparkML、SparkSQL 等。

機器學習

Ignite 和 Spark 都支援機器學習。

Ignite

Ignite 從 2.5 版本開始，提供了完整的機器學習解決方案，Ignite 的機器學習有兩個優點：一個是如果已經在 Ignite 中持有了大量的資料，那麼繼續在 Ignite 中進行機器學習的訓練和推理，就不需要在不同系統間進行 ETL 的等待，提高效率。另一個是 Ignite 提供了一系列的機器學習和深度學習演算法，對 Ignite 的分散式並置處理進行優化，這樣在處理大規模的資料集或者不斷增長的輸入資料流時，提供了記憶體級的速度和近乎無限的擴充套件性，而不需要將資料移到另外的儲存。目前支援的演算法包括迴歸、分類、聚類以及對資料進行預處理等。另外 Ignite 還支援了一組遺傳演算法，該演算法適合於以最優的方式檢索大量複雜的資料集。

Spark

Spark 很早就包含了機器學習庫，RDD 模型面向的一個主要場景就是機器學習這樣的多輪迭代式計算。目前的 Spark 機器學習庫有 2 個實現，正在逐步向 SparkML 過渡，SparkML 基於 DataFrame API，更強大更靈活，而傳統的 MLlib 會處於維護狀態。SparkML 基於 DataFrames 對 API 進行了統一，使用體驗更友好。可以使用 SparkSQL 等更高階的功能，支援流水線，特別是特徵變換。Spark 的機器學習因為 RDD 的原因效能更好，支援的演算法也更多。

圖計算

Ignite

暫不支援

Spark

Spark 中包含了 GraphX，這是一個圖計算元件。它在 RDD 基礎上引入了新的 Graph 抽象，為了支援圖形計算，GraphX 公開了一組基本運算子（例如子圖、連線頂點和聚合訊息）以及 Pregel API 的優化變型。此外，GraphX 還包括了越來越多的圖形演算法和構造者，以簡化圖形分析任務。

開發語言和客戶端協議

Ignite

Ignite 是以 Java 語言為主進行開發的，因此可以在 JVM 支援的任何作業系統和架構上部署和執行。Java 的 API 支援 Ignite 的所有功能，使用 Java 或者 Scala 開發的應用，相關的邏輯可以直接嵌入 Ignite，然後藉助於 SQL 以及鍵-值操作與叢集進行互動，執行分散式計算和機器學習演算法等等。

除了 Java，Ignite 還支援 .NET 平臺與 C++，Ignite.NET 和 Ignite C++ 使用 JNI，會把大部分的呼叫轉發給 Java。

Ignite 還支援使用標準的 JDBC 或者 ODBC 連線，可以像其它 SQL 儲存一樣與 Ignite 進行互動。Ignite 還為 Java、.NET 和 C++ 開發者提供原生的 SQL API，效能更好。

Ignite 還支援其它的語言訪問，比如 Python、Ruby、PHP 與 NodeJS，另外還可以考慮使用 Ignite 的二進位制客戶端協議接入叢集。

Spark

Spark 使用 Scala 語言開發，目前支援使用 Scala、Java、Python、R 語言開發 Spark 程式。

監控運維工具支援

Ignite

Ignite 開源版沒有提供圖形化的監控工具，但是提供了簡易的命令列工具，同時為了簡化開發，Ignite 提供了圖形化的 Web 控制檯。

Ignite 執行時可以通過 API 介面獲取大量的指標，通過程式設計的方式瞭解叢集的狀況。

如果需要強大的監控運維工具，可以購買 GridGain 的商業版軟體和服務。如果搭建的是一個小規模的叢集，鑑於 Ignite 的無共享架構，部署運維都是比較簡單的。

Spark

Spark 啟動後會有一個 Web 控制檯，雖然不是很美觀，但是可以從總體上看到 Spark 的當前執行狀態。

Spark 屬於 Master/Slave 模式，如果直接拿開源版本搭建大規模叢集，部署運維還是非常麻煩的，但是國內有很多廠商開發包含 Spark 元件的大資料平臺，為部署和運維提供了很大的便利。

六、總結

綜上所述，Ignite 和 Spark 功能都很全面，已經脫離了簡單開源技術元件的範圍，都成為了自成體系的開源大資料平臺。上面主要對 Ignite 和 Spark 的主要功能做了簡單的梳理對比，不一定全面，也沒有對其各自特有的功能進行梳理。但經過這麼一些分析，還是可以得出這樣一個結論：兩者差別很大，定位不同，因此會有不同的適用領域。

Ignite

Ignite 以快取為中心構建大資料體系，底層儲存模型更偏向傳統關係型資料架構，上層為應用開發的便利做了大量的工作，包括為各種常見語言和協議提供支援。中間核心層在快取的基礎上不斷向外擴充套件，功能日趨豐富強大。

Ignite 從定位上來說有兩個突出點，一是可以獨立組網，構建獨立的大資料平臺，然後企業在其上開發全新的大資料應用，包括快取、計算、流資料處理、機器學習應用等等。二是還可以與傳統應用緊密整合，在不顛覆已有架構的前提下，幫助使用者進行傳統應用的分散式架構轉型。為執行多年的複雜、執行緩慢、技術架構落後的業務系統，提供加速能力的同時，引入眾多的先進功能，大幅提升原有系統的能力從而延長已有架構的壽命，產生更大的價值，保護客戶原有投資。

Ignite 的定位和架構，與 Hadoop 體系大資料元件有很大的不同，但是並不衝突，即使企業已經部署了基於 Hadoop 技術體系的大資料平臺，那麼也可以繼續引入 Ignite 作為補充。

Spark

Spark 以計算為中心構建大資料體系，底層儲存對各種資料來源進行了抽象，總體上更偏向非結構化的資料，上層應用支援多種語言，核心層基於 RDD 模型，然後進行了大量的擴充套件，支援了更多更高階的功能，比如 SparkSQL、Spark Streaming、SparkML 與 Spark GraphX 等。Spark 的核心優勢是進行多輪迭代式計算、互動式計算以及圖計算等。

Spark 是圍繞 RDD 構建生態，使用者可以以 Spark 為中心搭建大資料平臺，滿足大量資料的獲取、清洗、處理、載入、計算、儲存等需求，核心定位是解決大資料的分析問題。雖然 Spark 的計算能力也可以處理傳統的關係型資料，但這並非 Spark 的強項，因此和傳統業務系統並沒有太多的交集。企業基於 Spark 搭建大資料平臺之後，其上的應用基本需要全新開發。傳統的資料處理業務，即使適合用 Spark 實現，原有的業務邏輯也無法直接、簡單地移植進入 Spark 技術堆疊。Spark 技術堆疊更適合用於處理傳統技術處理起來很麻煩、效能很差、資料量又很大的非結構化資料，Spark 適合對眾多系統的相關資料進行整合，通過分析後能產生更大價值的業務場景。

作者

李玉珏，架構師，有豐富的架構設計和技術研發團隊管理經驗，社群技術翻譯作者以及撰稿人，開源技術貢獻者。Apache Ignite 技術中文文件翻譯作者，長期在國內進行 Ignite 技術的推廣/技術支援/諮詢工作。

本文系作者投稿文章。歡迎投稿。

投稿內容要求

• 網際網路技術相關，包括但不限於開發語言、網路、資料庫、架構、運維、前端、DevOps（DevXXX）、AI、區塊鏈、儲存、移動、安全、技術團隊管理等內容。
• 文章不需要首發，可以是已經在開源中國部落格或網上其它平臺釋出過的。但是鼓勵首發，首發內容被收錄可能性較大。
• 如果你是記錄某一次解決了某一個問題（這在部落格中佔絕大比例），那麼需要將問題的前因後果描述清楚，最直接的就是結合圖文等方式將問題復現，同時完整地說明解決思路與最終成功的方案。
• 如果你是分析某一技術理論知識，請從定義、應用場景、實際案例、關鍵技術細節、觀點等方面，對其進行較為全面地介紹。
• 如果你是以實際案例分享自己或者公司對諸如某一架構模型、通用技術、程式語言、運維工具的實踐，那麼請將事件相關背景、具體技術細節、演進過程、思考、應用效果等方面描述清楚。
• 其它未盡 case 具體情況具體分析，不虛的，文章投過來試試先，比如我們並不拒絕就某個熱點事件對其進行的報導、深入解析。

文章轉自：https://my.oschina.net/editorial-story/blog/2050881