Ignite(三): Ignite VS Spark

时间 2019-12-08

标签 ignite spark 栏目 Apache 繁體版

原文原文链接

参考：https://www.itcodemonkey.com/article/9613.htmlhtml

gnite 和 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 适合对众多系统的相关数据进行整合，经过分析后能产生更大价值的业务场景。