全面對比，深度解析 Ignite 與 Spark

常常有人拿 Ignite 和 Spark 進行比較，而後搞不清二者的區別和聯繫。Ignite 和 Spark，若是籠統歸類，均可以歸於內存計算平臺，然而二者功能上雖然有交集，而且 Ignite 也會對 Spark 進行支持，可是無論是從定位上，仍是從功能上來講，它們差異巨大，適用領域有顯著的區別。本文從各個方面對此進行對比分析，供各位技術選型參考。

1、綜述

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 社區和生態圈，目前幾乎成爲了大數據領域影響力最大的開源項目。

2、定位

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 主要的關注方向。

3、核心技術

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 計算機制。

4、部署模型

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 解決。

5、功能

內存計算

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 組件的大數據平臺，爲部署和運維提供了很大的便利。

6、總結

綜上所述，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 具體狀況具體分析，不虛的，文章投過來試試先，好比咱們並不拒絕就某個熱點事件對其進行的報導、深刻解析。

投稿方式

• 以 Word 或者 Markdown 文檔的形式將稿件投遞到 oscbianji@oschina.cn 郵箱

重要說明

• 做者須要擁有所投文章的全部權，不能將別人的文章拿過來投遞。
• 投遞的文章須要通過審覈，若是開源中國編輯以爲須要的話，將與做者一塊兒進一步完善文章，意在使文章更佳、傳播更廣。
• 文章版權歸做者全部，開源中國得到文章的傳播權，可在開源中國各個平臺進行文章傳播，同時保留文章原始出處和做者信息，可在官方博客中標原創標籤。