经常有人拿 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 具体情况具体分析，不虚的，文章投过来试试先，比如我们并不拒绝就某个热点事件对其进行的报导、深入解析。
投稿方式
- 以 Word 或者 Markdown 文档的形式将稿件投递到 oscbianji@oschina.cn 邮箱
重要说明
- 作者需要拥有所投文章的所有权，不能将别人的文章拿过来投递。
- 投递的文章需要经过审核，如果开源中国编辑觉得需要的话，将与作者一起进一步完善文章，意在使文章更佳、传播更广。
- 文章版权归作者所有，开源中国获得文章的传播权，可在开源中国各个平台进行文章传播，同时保留文章原始出处和作者信息，可在官方博客中标原创标签。
来源：oschina
链接：https://my.oschina.net/u/2918182/blog/2050881