Nifi Processor开发 02

简单记录一下关于Nifi中，组件属性的定义部分
样例代码如下：

private static final PropertyDescriptor CATALOG_NAME = new PropertyDescriptor.Builder()
            .name("catalog").displayName("Catalog Name")
            .description("The name of the catalog that the statement should update. This may not apply for the database that you are updating. In this case, leave the field empty")
            .required(false)
            .expressionLanguageSupported(ExpressionLanguageScope.NONE)
            .addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
            .build();

其中

• name是前端实际调用API向后传参，以及后端识别的的实际参数名。必填
• displayName则是前端实际显示的参数名，这个可以不写，默认会和name一致，如果显示的参数名过长，或者其中包含诸如空格，中划线等等一系列特殊字符的时候，建议将两者分开。
• description不用多解释了，针对于这个参数的注释，会显示在页面上，参数名后面的小问号里。是使用这个组件的人，在不进行源码解读的时候，能知道你这个参数干吗用的唯一途径，所以，尽可能写的详细一些，但是，这个参数是可以没有的
• required 用于表明这个参数是否是必填项，与页面验证有关，必填的参数在没有填写的时候，页面上组件会有黄色叹号来警告用户，提醒还有东西没有做完，要根据组件功能和具体业务功能来使用，建议必填项
• expressionLanguageSupported 从名字上就能看出，是否支持正则，这个在不同的版本稍有区别，本人目前只用过1.4.0以及1.8.0进行组件开发，这两个版本中，1.4.0版，这个参数只需要指明true和false，也就是直接说明是否支持就可以，而上面的样例就是1.8.0的使用方式需要给定一个正则范围常量，上面的NONE表示不支持正则。另外还有VARIABLE_REGISTRY和FLOWFILE_ATTRIBUTES，分别表示仅支持参数正则和支持参数以及FlowFile中的参数（你要处理的数据）正则。可以不填
• addValidator 用于添加验证，一般的字段只需要添加非空验证即可，另外，NIFI本身还提供了诸如整数，INT，LONG甚至验证是否是FlowFile的Attribute。必填，没有的话，嗯，编译什么的都不会有问题，等你扔到环境中，把组件拖出来，黄色会一直跟着你。

一般来说，一个完整的输入参数定义需要上面这些就足够了。

另外，部分的参数可能想做成select那种提供有限想想的方式，这时候，会用到.allowableValues()，通过设置允许的值，来限定用户选择范围，比如下面这段代码

public static final AllowableValue update = new AllowableValue("update", "更新", "重复数据，使用新数据更新已经存在的存量数据");
public static final AllowableValue ignore = new AllowableValue("ignore", "忽略", "重复数据，忽略传入的新数据");
static final PropertyDescriptor METHOD = new PropertyDescriptor.Builder().name("duplicate handler")
            .description("mothod to handle duplication datas \\n 重复数据处理方式").required(true).allowableValues(update,ignore)
            .defaultValue("update") .addValidator(StandardValidators.NON_EMPTY_VALIDATOR).build();

其中 new AllowableValue(Name,displayName,Description)用于创建一个参数值的可选对象
.allowableValues()方法也支持参数是String…。但是，这种方式不推荐使用，因为没有办法对可选值添加描述，或者适用于Name和DisplaName不一致的情况，一般只有当可选值为简单的true、false的时候可用

2019年4月17日补充

Relationship

Relationship是Nifi中用来定义数据的具体流向的，一般来说，一个完整的组件都应该有3个基本的关系（个人更喜欢叫数据流向）：

• 处理成功
• 处理失败
• 异常失败

但是，一般情况下，处理失败和异常失败可以合并到一起来进行处理。
以Nifi1.8.0为例Relationship的定义代码如下

private static final Relationship REL_SUCCESS = new Relationship.Builder()
		.name("success")
		.autoTerminateDefault(true)
		.description("匹配成功").build();

• name用来声明这个数据流向的名称，和上面的PropertyDescriptor不一样的是，Relationship不区分name和displayname（至少1.8.0是这样的）
• autoTerminateDefault用来声明这个数据流向是否自动关闭，对于任意一个Processor，其中的所有关系的数据都必须进行处理，要么流向另外一个Processor，要么就是自动销毁
• description就很好理解了，对于这个数据流向的描述，建议开始支持description的版本都将这个添加上，特别是对于错误数据流向，会在画布配置流程的时候，节约很多的工作。但是如果你设计的组件希望这个数据流向的数据被切实的处理，不要设置这个属性为true

2019年4月22日补充

FlowFile转发问题

Nifi中，每一个输入的FlowFile都必须且唯一的要转发到某一个Relationship中，在没有进行转发或者转发重复的时候，都会在运行是报错。所以在开发过程中，一定要注意FlowFile的转发关系，同时，处理过程中，非输出（入库，入队列等），不应该出现处理完成后，FlowFile没有被转发的任何一个关系（输出其实也应该这样）

---

下面开始吐槽一下
公司在最近的一个项目上，使用了Nifi1.4.0作为导数工具，进行倒数，怎么说的，用的很糟糕，但还是记录一下具体情况

NIFI使用了集群模式（超级烂啊，同时并行任务多了掉节点，缓存数据多了掉节点，时钟差距过大掉节点，一个节点掉了，整个集群不工作，啊啊啊啊），共5个节点
因为组件限制，所有的流程只能通过Primary node模式执行（所以，这个集群模式有什么意义？），并且，配套的分发组件，我们的‘技术支持’封装的有问题，没法用！是不是特别好玩。（1.8.0以后的版本就已经修改了这个问题，所有的组件间的队列，都可以用作数据平衡，集群模式下可用，用起来还可以，比之前的分发组件好用）
NIFI每个节点的启动内存配置为了4GB，运行内存为32GB
总得来说，就是下面这样

模式	节点数量	执行方式	分配内存大小	最大线程数	服务器核数
cluster	5	Primary node	32BG	200	64

看着还不错，但是实际上呢，我们用的相当于是一个时不时会罢工的单节点NIFI。
关于集群模式的吐槽到此为止，下面简单记录一下抽取数据的时间。
有记录的其中一个57G的表，完成导数用了3~5个小时（不确定，因为中午吃饭的时候，这东西完成的！其他表没记录！理直气壮.jpg）
按最坏的5小时完成计算，这套NIFI流程的速度约为3.25M/s，在大数据时代，这个数不算大，比sqoop要慢不少，但是考虑到这是单节点执行，如果数据能分发到5个节点，同步执行，速度至少能有4-5倍的提升，按照4去计算，那这样，这套NIFI流程的速度为14M/s相较其他的数据抽取工具，速度上确实有不小提升，但是，就现在来看，集群稳定性等问题上还需要改善。

相对于其他工具，速度上基本不是问题，甚至自定义开发的组件，在性能上还有提升的空间，问题在于，如何在众多组件中甄别自己要用的，如何快速确定是否有符合自己功能的组件，没有的话如何快速开发实现功能。