前言：
Ignite是一个以内存为中心的数据平台，具有数据强一致、高可用、支持标准SQL的特性。Ignite从2015年加入apache以来备受关注，截至发文ignite已更新至2.7版本，本文推荐版本2.6以上(支持copy关键字)。此次应用Ignite的计算网格部分，代替Mysql关联查询，降低业务库压力，提升平台效率。
一、 应用场景
数据云及云计算数据缓存层
背景:业务数据库越来越大，全量抽取更新及关联查询维表对业务库Mysql造成巨大压力，较长sql关联查询耗时20分钟以上。
结论：重新改变原始的数据加工逻辑后，引入ignite框架完成分钟级数据同步。单任务提高效率，由每小时同步一次数据，提升至15分钟，性能提高4倍。并且关联计算由ignite完成，减少了业务端Mysql的压力。
二、 应用场景架构对比
image.png
在之前的架构中耗时较长的部分为：
Mysql关联查询，并对业务库Mysql造成较大压力，随着数据量的增加，较长关联查询已经到达20分钟以上。
文件读写，利用spark将csv转orc文件并写入hive表。
数据分发，由hive写入hdfs文件，通过BulkLoad加载到hbase，后续使用phoenix做业务关联查询。
优化后的ignite架构：
Mysql关联查询移到Ignite中。Ignite的内存关联查询部分优于Mysql数据库。
取消数据的文件读写，使用Mysql binlog接入kafka实时更新ignite表数据，规避csv转orc过程。
同时将ignite数据分发到hive和phoenix做业务关联查询使用。
三、 详细架构图
image.png
四、 Ignite SQL数据网格优势
为了提升性能Ignite对sql查询做了很多优化，并且支持事务。
分布式查询
Ignite借用了H2的SQL查询解析器以及优化器还有执行计划器。H2会在一个特定的节点执行本地化的查询(一个分布式查询会被映射到节点或者查询是以本地模式执行的)，然后会将本地的结果集传递给分布式SQL引擎用于后续处理。
数据和索引，通常是存储于Ignite数据网格端的，而Ignite以分布式以及容错的方式执行SQL查询。
Ignite SQL网格执行查询
首先，如果查询在一个部署有REPLICATED模式缓存的节点上执行，那么Ignite会假定所有的数据都是本地化的，然后将其直接传递给H2数据库引擎执行一个简单的本地化SQL查询，对于LOCAL模式的缓存，也是同样的执行流程。
第二，如果查询执行于PARTITIONED模式缓存，那么执行流程如下：
查询会被解析然后拆分为多个映射查询以及一个汇总查询；
所有的映射查询都会在持有缓存数据的所有数据节点上执行；
所有的节点都会将本地执行的结果集提供给查询发起者(汇总节点),它会通过正确地合并结果集完成汇总的过程。
处理带有ORDER BY以及GROUP BY的结果集
带有ORDER BY语句的SQL查询不需要将所有结果集都加载到查询发起(汇总)节点来完成排序。而是查询映射的每个节点都会对自己那部分数据进行排序然后汇总节点以流的方式进行合并。
对于有序的GROUP BY查询也是同样的优化方式，不需要在将其返回给应用之前将所有数据加载到汇总节点用于分组。在Ignite中，来自单独节点的部分结果集可以被逐步地流化、合并、聚合以及返回给应用。
Ignite SQL对事务的支持
原子化模式、跨缓存事务和近缓存事务、阶段提交(2PC)、并发模型和隔离级别、悲观事务、乐观事务、死锁检测、无死锁事务。
五、 当前版本存在的不足及解决方法
在Ignite sql 存在与Mysql不同的函数和语法
修改原sql为当前Ignite支持的sql，如：collect_set
编写自定义函
开启多备份和磁盘存储效率下降
为提高性能，关闭磁盘同步，因此存在数据安全和恢复问题，我们编写高效的数据加载模块，快速的加载数据提高集群的恢复能力。
Mysql与Ignite表的元数据管理，以及kafka任务管理
使用数据云的元数据管理
开发任务管理模块、包括启动、监控、自启等功能
Ignite数据批量导入导出
2.6以上版本，使用copy命令初始化导入数据
使用binlog解析模块，解析kafka中的Mysql binlog对Ignite进行更改操作
使用客户端执行导出文件到csv，设置参数：!outputformat csv
六、 未来规划
目前ignite的稳定性无法攀比当前应用广泛的数据仓库架构，无法成为核心的应用进行大规模部署。为了满足业务场景构建10台ignite集群。未来随着ignite 的发展，我们将不断进行集群扩容，逐渐加入更复杂、数据量更大的业务场景。