为什么80%的码农都做不了架构师？>>> 
经常有人拿Ignite和Spark进行比较，然后搞不清两者的区别和联系。Ignite和Spark，如果笼统归类，都会归类于内存计算平台，两者功能上虽然有交集，并且Ignite也会对Spark进行支持，但是不管是从定位、还是从功能上来说，差别巨大，适用领域有显著的区别。下面会拿出主要的点做出对比分析，供技术选型参考。
1.综述
Ignite和Spark都为Apache的顶级开源项目，遵循Apache 2.0开源协议，经过多年的发展，都已经脱离了单一的技术组件或者框架，向着多元化的生态圈发展，并且发展速度都很快。
Ignite
Ignite技术来源于GridGain公司的商业产品，于2014年将绝大部分功能捐赠给Apache社区，2015年8月毕业成为Apache的顶级项目，但是GridGain将部分高级企业级功能保留在商业版本中，企业级的功能和服务，则需要付费。Ignite目前一直保持着高强度的快速迭代式开发，基本一个季度发布一个大版本，目前从提交数量、版本发布数量等若干指标来评估，一直保持Apache社区300多个开源项目的前五位。目前已经聚拢了来自多家组织或者公司的众多开发者，处于非常活跃的状态，开发者社区和产品生态正在形成中。
Spark
Spark在2009年由Matei Zaharia在加州大学伯克利分校AMPLab开发，于2013年6月捐赠给Apache基金会并切换协议至Apache2.0，2014年2月毕业成为Apache的顶级项目，是Hadoop生态圈的一员，之后Spark的核心开发者创立了Databricks公司，在开源社区之外进行商业化运作，提供商业服务。但是鉴于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.功能点比较
5.1.内存计算
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的在线计算功能。
5.2.存储支持能力
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不具备原生的持久化能力。
5.3.SQL
Ignite和Spark都支持SQL，但是两者的定位和能力，有所不同。
Ignite
Ignite SQL目前的语法兼容于ANSI-99，除了支持查询，删除、更新、插入都是支持的，但语法和功能于标准并不完全一致，具体差别可以看官方文档。
Ignite如果做好了数据并置，SQL查询的性能是很好的，同时Ignite还支持索引，这都进一步提升了Ignite SQL的能力。
Ignite SQL对缓存的功能进行了极大的增强，通常用于缓存的在线查询和计算，用于离线数据处理也是可以的。
Spark
SparkSQL最初来源于Shark项目，后来两者进行了合并，SparkSQL构建于Dataset/DataFrame机制基础上，目前只支持查询，主要适用于分析型业务以及对来自不同数据源的结构化数据进行处理。也可以进行交互式查询，因为不支持索引等等原因，性能较差，响应时间可能较长。
5.4.数据一致性（事务）
Ignite
Ignite整体来说对事务的支持还不完善，具体来说，在键-值API层面，有完善的事务机制，主要原理来自于经过优化的二阶段提交协议，但是SQL层面的DML语句，还不支持事务，未来版本会解决该问题。
在计算层面，因为支持丰富的编程接口，也可以非常容易地与各种开源的ORM框架集成，所以也可以方便地对事务进行细粒度的控制，比如CRUD，都是没问题的。
Spark
SparkSQL本身并不提供事务机制。Spark本身也不适用于RDBMS的细粒度数据维护，RDBMS对于Spark来说，只是数据的一个来源和存储地之一，通常都是批量操作，如果批量操作失败，Spark有容错机制可以重来，保证整体的一致性。
5.5.流计算
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等。
5.6.机器学习
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的原因性能更好，支持的算法也更多。
5.7.图计算
Ignite
暂不支持
Spark
Spark中包含了GraphX，这是一个图计算组件。它在RDD基础上引入了新的Graph抽象，为了支持图形计算，GraphX公开了一组基本运算符（例如子图、连接顶点和聚合消息）以及Pregel API的优化变型。此外，GraphX还包括了越来越多的图形算法和构造者，以简化图形分析任务。
5.8.开发语言和客户端协议
Ignite
Ignite是以Java语言为主进行开发的，因此可以在JVM支持的任何操作系统和架构上部署和运行。Java的API支持Ignite的所有功能，使用Java或者Scala开发的应用，相关的逻辑可以直接嵌入Ignite，然后借助于SQL以及键-值操作与集群进行交互，执行分布式计算和机器学习算法等等。
除了Java，Ignite还支持.NET平台，Ignite.NET和Ignite C++使用JNI，会把大部分的调用转发给Java。
Ignite还支持使用标准的JDBC或者ODBC连接，可以像其他的SQL存储一样与Ignite进行交互。Ignite还为Java、.NET和C++开发者提供原生的SQL API，性能更好。
Ignite还支持其他的语言访问Ignite，比如Python、Ruby、PHP或者NodeJS，另外还可以考虑使用Ignite的二进制客户端协议接入集群。
Spark
Spark使用Scala语言开发，目前支持使用Scala、Java、Python、R语言开发Spark程序。
5.9.监控运维工具支持
Ignite
Ignite开源版没有提供图形化的监控工具，但是提供了简易的命令行工具，同时为了简化开发，Ignite提供了图形化的Web控制台。
Ignite运行时可以通过API接口获取大量的指标，可以通过编程的方式了解集群的状况。
如果需要强大的监控运维工具，可以购买GridGain的商业版软件和服务。如果搭建的是一个小规模的集群，鉴于Ignite的无共享架构，部署运维都是比较简单的。
Spark
Spark启动后会有一个Web的控制台，虽然不是很美观，但是可以从总体上看到Spark的当前运行状态。
Spark属于Master/Slave模式，如果直接拿开源版本搭建大规模集群，部署运维还是非常麻烦的。但是国内有很多厂商开发包含Spark组件的大数据平台，为部署和运维提供了很大的便利。
6.总结
综上所述，Ignite和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适合于对众多系统的相关数据进行整合，通过分析后能产生更大价值的业务场景。