Apache Ignite

3 月，跳不动了？>>> 在本系列 前面的文章 中，简单介绍了一下Ignite的线性回归算法，下面会尝试另一个机器学习算法，即k-最近邻(k-NN)分类。该算法基于对象k个最近邻中最常见的类来对对象进行分类，可用于确定类成员的关系。 一个适合k-NN分类的数据集是鸢尾花数据集，它可以很容易地通过 UCI网站 获得。 鸢尾花数据集由150个样本组成，来自3种不同种类的鸢尾花各有50朵（Iris Setosa, Iris Versicolour和Iris Virginica）。以下四个特征可供每个样本使用： 萼片长度（cm） 萼片宽度（cm） 花瓣长度（cm） 花瓣宽度（cm） 下面会创建一个模型，利用这四个特征区分不同的物种。 首先，要获取原始数据并将其拆分成训练数据（60%）和测试数据（40%）。然后再次使用Scikit-learn来执行这个任务，下面修改一下前一篇文章中使用的代码，如下： from sklearn import datasets import pandas as pd # Load Iris dataset. iris_dataset = datasets.load_iris() x = iris_dataset.data y = iris_dataset.target # Split it into train and test subsets. from

3 月，跳不动了？>>> 在本系列 前面的文章 中，简单介绍了一下Ignite的机器学习网格，下面会趁热打铁，结合一些示例，深入介绍Ignite支持的一些机器学习算法。 如果要找合适的数据集，会发现可用的有很多，但是对于线性回归来说，一个非常好的备选数据集就是房价，可以非常方便地从UCI网站获取 合适的数据 。 在本文中会训练一个线性回归模型，并且计算R 2 得分。 需要先准备一些数据，并且要将数据转换成Ignite支持的格式，这通常是数据科学家需要花时间做的事。 首先，需要获取原始数据并将其拆分成训练数据（80%）和测试数据（20%）。Ignite暂时还不支持专用的数据拆分，路线图中的未来版本会支持这个功能。但是就目前来说有许多可用的免费和开源工具可以执行这样的数据拆分，或者也可以用一种Ignite支持的编程语言自己编写这种代码。在本文中会使用下面自己编写的代码来实现此任务： from sklearn import datasets import pandas as pd # Load Boston housing dataset. boston_dataset = datasets.load_boston() x = boston_dataset.data y = boston_dataset.target # Split it into train and test

3 月，跳不动了？>>> 在Ignite上运行微服务：第二部分 本文是系列文章的第二篇，这个系列会详细描述如何使用像Ignite这样的内存数据网格（IMDG）技术来构建容错和可扩展的微服务解决方案。 在 第一篇 中，作为一个系统，一个可能的架构由如下层次组成： Ignite集群层 持久化存储层 外部应用层 本文中会关注第一层（Ignite集群层），可以参考一个 GitHub项目 ，他包含了日常中实现拟议的微服务架构所必须的构建块，尤其是要覆盖如下部分： 配置和启动数据节点； 使用Ignite的服务API的典型服务实现； 配置和启动驻有Ignite服务的服务节点； 一个连接到集群并且触发服务执行的虚拟应用。 微服务位于内存数据网格架构之上时的数据节点 正如第一篇中提到的，数据节点是持有数据集一部分数据的服务端节点，应用逻辑端会在这个数据集上执行查询和计算。通常来说，这种类型的节点对应用逻辑是透明的，因为这些节点只是简单地存储数据集，然后当应用访问数据时高效地进行处理就可以了。 下面会看一下在实现层面如何定义一个数据节点。 可以下载这个 GitHub项目 然后找到 data-node-config.xml ，它会用于创建一个新的数据节点，这个配置包含了一组与数据节点有关的段落和参数。 首先，需要为每一个要部署到集群中的Ignite缓存配置一个特定的节点过滤器

Apache Ignite 2.8做出了数千项变更，这些变更几乎增强了平台的所有组件，但本文不会面面俱到，主要是指导Ignite开发人员关注核心的增强功能，详细的 更新列表 请看这里。 新的产品监控和跟踪子系统 很多Ignite开发者将Ignite部署于核心应用系统，并希望Ignite可以与许多外部监控工具集成并易于扩展，基于此，Ignite团队花费了几个月的时间，开发了一个强大而灵活的监视和分析子系统，用于生产监控和诊断（也称为分析）。 新的子系统由多个与特定的Ignite组件相关的单独分组的指标注册表组成，例如可以找到和缓存、计算或服务网格API相关的注册表。由于注册表是通用的，因此可以通过大量支持各种协议的工具来观察Ignite的状态。Ignite 2.8为监控接口默认也提供了若干个出口，比如日志文件、JMX和SQL视图之类，同时也支持诸如OpenCensus之类的现代工具。 目前，此新子系统以实验性模式发布，只是给Ignite开发者一些时间来验证新API并提出改进建议。 机器学习能力提高 Ignite 2.8的机器学习（ML）功能与以前的版本有很大的不同，目前已经稳定，开发者可以放心使用了。 模型训练通常是一个多步骤的过程，包括预处理、训练和评估/验证阶段。新的流水线API通过将所有阶段组合成单一的工作流来简化这个过程。 除了流水线API，Ignite 2.8引入了集成方法

本文会介绍Apache Ignite的C++ API（称为 Ignite C++ ），主要面向C/C++开发者。 Ignite和Ignite C++ Ignite C++构建于Ignite之上； Ignite C++在同一个进程中启动JVM，并且通过JNI与之通信； .NET、C++和Java节点可以加入同一个集群，使用相同的缓存，并且使用通用的二进制协议进行互操作； Java计算作业可以在任意节点上执行（Java、.NET和C++）。 入门 因为Ignite是一个分布式平台，所以开始就要先启动一个节点，这方面如果使用 ignite::Ignition 类是非常简单的： 好了，在C++环境中已经使用默认的配置启动了第一个Ignite节点！其中 Ignite 类是访问集群的主要入口点。 数据操作 暴露数据操作API的主要Ignite C++组件是 ignite::cache::Cache<K,V> 。它包含了基本的数据操作方法集。由于缓存本质上是作为分布式哈希表的接口，因此基本上可以像处理简单容器（ map 或者 unordered_map ）那样与它进行交互。 Ignite主要是用Java开发的，Ignite组件的实现也使用了很多Java的特性，比如，对象的序列化/反序列化就用在了磁盘存储和对象的网络传输上。 在Ignite C++中，这个特性通过 ignite::binary:

介绍 Ignite原生提供了若干种主要编程语言的支持，最近，还通过 瘦客户端技术 对其它的编程语言提供了支持，其中在2.7版本中新增加的瘦客户端包括Python、PHP和Node.js。 瘦客户端具有如下的特征： 这些都是轻量级的客户端，使用标准套接字连接接入集群； 它们不是集群拓扑的一部分； 它们不会持有数据； 它们不会被用作计算网格的计算节点。 总而言之，一个瘦客户端只是建立了与标准节点之间的套接字连接，然后通过该节点执行各种操作。 在本文中，会聚焦 Node.js ，然后快速学习如何使用Node.js瘦客户端。 要求 Node.js客户端的要求如下： Node.js V8及更新的版本； Ignite V2.7及更新的版本。 下面的演示会基于macOS操作系统。 安装 下面会使用Ignite的二进制发行版，可以从 这里 下载。 在macOS上安装Node.js的最简单的方法是使用 HomeBrew ，只要在终端中简单地执行下面的命令就可以： brew install node 安装完成之后，可以像下图这样确认一下软件的版本： Node.js的源代码和其它操作系统的安装文件可以从 Node.js官网 下载。 下一步，需要安装Ignite的Node.js瘦客户端包，最快的方式是在终端中执行下面的命令： npm install -g apache-ignite-client

Ignite的集群部署 Ignite具有非常先进的集群能力，本文针对和集群有关的技术点做一个简短的介绍，然后针对实际应用的可能部署形式做了说明和对比，从中我们可以发现，Ignite平台在部署的灵活性上，具有很大的优势。 1.相关概念 1.1.节点平等 Ignite没有master节点或者server节点，也没有worker节点或者client节点，按照Ignite的观点所有节点都是平等的。但是开发者可以将节点配置成master，worker或者client以及data节点。 1.2.发现机制 Ignite节点之间会自动感知，集群可扩展性强，不需要重启集群，简单地启动新加入的节点然后他们就会自动地加入集群。这是通过一个发现机制实现的，他使节点可以彼此发现对方，Ignite默认使用 TcpDiscoverySpi 通过TCP/IP协议来作为节点发现的实现，也可以配置成基于多播的或者基于静态IP的，这些方式适用于不同的场景。 1.3.部署模式 Ignite可以独立运行，也可以在集群内运行，也可以将几个jar包嵌入应用内部以嵌入式的模式运行，也可以运行在Docker容器以及Mesos和Yarn等环境中，可以在物理机中运行，也可以在虚拟机中运行，这个广泛的适应性是他的一个很大的优势。 1.4.配置方式 Ignite的大部分配置选项

任何深度学习都是从数据开始的，这是关键点。没有数据，就无法训练模型，也无法评估模型质量，更无法做出预测，因此，数据源非常重要。在做研究、构建新的神经网络架构、以及做实验时，会习惯于使用最简单的本地数据源，通常是不同格式的文件，这种方法确实非常有效。但有时需要更加接近于生产环境，那么简化和加速生产数据的反馈，以及能够处理大数据就变得非常重要，这时就需要Apache Ignite大展身手了。 Apache Ignite 是以内存为中心的分布式数据库、缓存，也是事务性、分析性和流式负载的处理平台，可以实现PB级的内存级速度。借助Ignite和TensorFlow之间的现有集成，可以将Ignite用作神经网络训练和推理的数据源，也可以将其用作分布式训练的检查点存储和集群管理器。 分布式内存数据源 作为以内存为中心的分布式数据库，Ignite可以提供快速数据访问，摆脱硬盘的限制，在分布式集群中存储和处理需要的所有数据，可以通过使用Ignite Dataset来利用Ignite的这些优势。 注意Ignite不只是数据库或数据仓库与TensorFlow之间ETL管道中的一个步骤，它还是一个 HTAP （混合事务/分析处理）系统。通过选择Ignite和TensorFlow，可以获得一个能够处理事务和分析的单一系统，同时还可以获得将操作型和历史型数据用于神经网络训练和推理的能力。 下面的测试结果表明

开发者在搭建第一个Ignite集群时，常常会遇到各种障碍，社区在收集了各种常见问题后，整理了一份检查清单帮助开发者，总之，本文的目的是帮助开发者在一开始就搭建一个正常的集群，走在正确的道路上。 配置日志 准备启动：设置日志 首先，需要日志，因为在解决很多问题的时候，需要每个节点的日志。 虽然Ignite默认是开启日志记录的，但是默认为 QUIET 模式，会忽略掉 INFO 和 DEBUG 级别的日志输出，如果系统属性 IGNITE_QUIET 配置为 false ，则Ignite将以正常的、没有限制的日志记录模式运行，注意，所有 QUIET 模式的日志都会输出到标准输出(STDOUT)。 只有严重的日志才会出现在控制台中，其它的日志都会记录在文件中，默认位置为 ${IGNITE_HOME}/work/log ，注意不要删除它，以后可能有用。 Ignite以默认方式启动时的标准输出 对于一些简单问题的处理，不需要做单独的监控，只需要在命令行中以详细模式启动即可： 然后，系统会将所有事件与其它一些应用日志信息一起，输出到标准输出中。 这时，再有问题就可能从日志中找到解决方案，比如如果集群崩溃，可能会发现"在某某配置处增加某某超时配置"之类的信息，这就说明，该配置太小了，网络质量很差。 禁用组播 很多人遇到的第一个问题是，集群中出现了预期之外的节点，即启动一个节点后，在集群的拓扑快照中

很多人会问，Ignite有没有持久化存储，或者说是不是一个单纯的内存存储？ 答案是都有，Ignite的原生持久化可以打开，也可以关闭。这使得Ignite可以存储比可用内存量大得多的数据集，也就是说，少量的操作型数据集可以只存储于内存中，而内存装不下的更大的数据集可以存储在磁盘上，这样将内存作为一个缓存层，性能会更好。 Ignite原生持久化 Ignite原生持久化是一个分布式的支持ACID和兼容SQL的磁盘存储，它可以与Ignite的固化内存架构透明地集成。Ignite的持久化是可选的，可以打开也可以关闭，如果关闭，Ignite就是一个纯内存的存储。 打开原生持久化之后，Ignite会始终在磁盘上存储数据的超集，然后根据内存的容量在其中存储尽可能多的数据。比如，一共有100条数据，然后内存容量只能存储20条，那么所有的100条都会存储于磁盘上，然后在内存中只缓存20条数据，这样性能会更好。 此外，还要注意，和内存存储的场景一样，如果打开了持久化，每一个节点只会持有所有数据的一个子集，只会包含该节点作为主/备节点所属分区的数据，而整个集群则包含完整的数据集。 不同于作为备份持久层的第三方数据库，Ignite的原生持久化有如下的关键特性： SQL查询可以跨越内存和磁盘的完整数据集，这意味着Ignite可以作为以内存为中心的分布式SQL数据库； 不需要将所有的数据和索引放在内存中