RouteOnAttribute

示例1

    使用Route做流程的分支，根据一个叫SO的栏位是否为空决定走不同的流程(左右的UpdateAttribute可以把它们想象成两个完全不同的处理流程来看)




    RouteOnAttribute，作用是根据Attribute的Bool值来决定是否进入该分支

• HasSO / NonSO：这是我自行定义的两个Route名称 (不是属性名称)，Value是一个表达式，若它的值=true，则Output会进该Route
• Nifi的表达式语法不怎么好写，官方的文档上有些东西并不支持 (不确定是不是Nifi版本缘故)。这里还是可以看得出来就只是判断一个叫SO的Attribute的值是否为空 --- 还记得有些Processor里面还有叫"Null Value Representation"的属性吧，若是那里配成"null"那这里也要与之匹配。
• 经过该Processor处理后，SO为空的会走右端逻辑，而不为空的则会走左段逻辑，同时它会加多一个叫"RouteOnAttribute.Route"的Attribute，内容即为Route名称
  

示例2：

    根据多个栏位是否有值(不为空)，让它们能够进入不同的Route，后面再根据Route名称去动态的取值，它的特点是Nifi流程并没有出现分支(Connection上是勾了所有的Route)，只是为不同的数据设上了一个变量名称



    RouteOnAttribute，借用分支名称在后面搞事，这里相当于是给资料加上了一个变量名称

• MO / MODELFAMILY / UPN / USN：这是定义的四个Route名称，判断条件都很简单，就只是不为空
• 值得注意的是这4个条件并非是互斥条件，比如有一笔资料它的MO、USN都不为空，那么就会同时进入两个Route进行输出，所以Output笔数会是2
• 下面这是进入UPN这个Route后的资料上的Attribute: "RouteOnAttribute.Route"
  
  

    UpdateAttribute，比较精彩的用法

• mqttTopic：这是定义的一个MQTT的Topic变量，它的内容是可变动的，会根据Route的不同产生不同的结果
• MO/MODELFAMILY/UPN/USN这4个条件有任一不为空，则会要求推送Topic： xxxx/【Type】/【Value】/yyyy
• 【Type】: 为"mo"、"modelfamily"、"upn"、"usn"这四个值之一
• 【Value】: 为MO/MODELFAMILY/UPN/USN这四个Attribute的取值 (即 ${MO} / ${MODELFAMILY} / ${UPN} / ${USN} 的值)，这里使用了双层${${"RouteOnAttribute.Route"}}的取值方法来实现动态的取用变量值

思路：

解决方案：

虽然与前一篇来说差异不大，但Nifi流程上却有很大不同，下面会详细描述为什么要这样做

Processor及其设定：

• SQL1：这才是这次花招的关键，在这里根据STATUS自行构建SQL语句
• Status=0：构建的就是Delete From xxx Where Key1=? and Key2=? 这样的删除语句
• Status!=0：构建的就是Replace Into xxx (Key1,Key2,col3,col4) Values ( ?, ?, ?, ?) 这样的Insert or Update语句
• 经此Processor处理后，资料落地所需的SQL就构建好了，后续的问题就是如何去绑定参数和执行

• Search Value：这里使用的是Default的(?s)(^.*$)，作用就是把原先的整份文件全部换掉
• Replacement Value：这里放的就是一个固定结构的JSON，可以看到里面的属性值都是使用的Attribute (它们的值来源于前面的EvaluateJsonPath从源JSON文件中的提取)
• 细心的朋友可以发现这里是与前一篇文章的最大不同，这里没有使用AttributeToJson去直接产生JSON文件，而使用的是更加笨拙的方式
• 前面的文章有提过，我们产生的Attribute以及AttributeToJson所生成JSON中各属性的顺序问题，结论是怎么搞它都不是我所想象到的顺序。但是ConvertJsonToSQL这个东东却很实在，它确确实实是按JSON中属性的顺序去生成的SQL以及参数名称(还记得参数名称sql.args.1.value中的这个顺序1么)，所以问题就来了：
  
• SQL由于必须要有Delete和Replace，所以它们的参数个数一定是不同的，而Delete压的参数又是我们的Key，所以就必须要保证ConvertJsonToSQL生成属性的顺序，这样我们才能够保证我们的两个Key一定会是sql.args.1和sql.args.2
• 换句话说，如果AttributesToJson若是能够保证JSON属性顺序的话，那就不用这么费劲

• Delete Attributes Expression：这里我根据Delete的条件(STATUS=0)去删除多余的SQL绑定参数
• 这里的写法比较死，我Hard-code删除掉大与2的其它所有参数(" * "是一个通配符，" | "是一个多条件的间隔符)，感觉上还有更好的写法
• 至此我们就可以保证绑定参数的数量与SQL语法参数个数一致 (不一致它死给你看)

• SQL Statement：前面用UpdateAttribute产生的SQL1参数，它会根据STATUS=0去判断是使用DELETE还是REPLACE语法
• 这个属性压上后，无论SQL1是不是为空，这个组件都不会再去管FlowFile的内容(空属性时是把FlowFile的内容当成SQL去执行的)

解决方案(仅新增、修改)：

    这个场景是最常见的，资料不会有被删除的状态，所有的更新就只有Insert Or Update这两种状态，先上实例的图 (两边的LogMessage是为了接收Fail，有感叹号是避免一起开启的时候它也被开启----这样failure的讯息就不会再卡在Connection中了)

思路：

Processor及其设定：

• Kafka Brokers：Kafka的Broker列表，多个Broker以逗号分隔，类似www.broker1.com:9193,www.broker2.com:9193这样的形式配置
• Topic Name：需要Consume的Kafka Topic名称
• Record Reader/Writer：关于Record所需要设定的Reader和Writer，要先行在Configure中设定，当然也要设定好Schema  
  
• Group ID：Consumer所要设定的ID，这个的设定要依Kafka的配置来，现在我们一般就只有单个的Partition，所以会要求每个Processor都设定有不同
• Offset Reset：需要设定为"earliest"，这样就会依GroupID没有收过的资料来进行收取，否则就只会收新推上去的资料。第一次玩的兄弟经常坑在GroupID和Offset Reset这两项上，若是收不到资料则有  可能就是GroupID没有换成新的(旧的已经收过一次就不会重新再收)，或者是Offset Reset = latest又没有新资料推上去~~~
  
• Max Poll Records和SCHEDULING中的Run Schedule：需要根据实际接收的速度来进行调整。经过观察发现Consume的速度超快，但整个Nifi Flow的速度会卡在其它需要做解析或读写DB的Processor外 (通常解析JSON会是前面的关卡)，所以任由Consumer的高速读取就会造成整个Nifi流程在后段被卡住。造成这个的主要原因其实就在于kafka处理的高速上，所以当有新换GroupID或新流程时，Kafka上积累的海量资料就会在一瞬间被接收下来，然后就是各种红 (其实红了也没事，它会自动向上推，让前一个Processor停止处理)。
  
• 若是常态下的资料推送量就已经超过了你的Nifi处理速度，那么就要考量使用多个线程处理或者是从源头的Kafka上就把资料分割开来  
• SCHEDULING的Cocurrent Tasks：这个Default=1，就是当前Processor需要开起来的线程数。但是这个设置需要当心，你需要仔细考量过你的资料流是否允许乱序 (多线程时当然不可能还能保证资料处理的顺序)，所以它是仅适用于不Care资料处理顺序的场景，例如每笔Key就只会有一笔资料，而且哪笔资料先收后收无所谓

将资料从Oracle推至MQTT，资料结果使用JSON格式
场景1：直接推送
场景2：仅当资料有变更时才推送

解决方案

Processor及其设定：

QueryDatabaseTable，作用是从DB中捞取资料，可以想象Nifi把它转成一个Select语句在执行

• Database Connection Pooling Service：在Configure中设定的数据库连接，可以在Processor Group中被共用
• Database Type：这个设定的是Oracle。其实它与数据库连接设定有点重叠，那边已经有指定是哪一种类型的DB，这里需要再指定，我想会不会是利用它来生成不同的Select查询语法?
• Table Name：表名，我这里使用的是View名称，View其实就已经对Table做出一些限定，可以挑选列及设定查询条件
• Maximum-value Columns：这个属性很重要，如果不设定则Nifi在查询的时候会捞取所有的资料，如果有设定某个列，则Nifi仅会捞取“新”资料
• 例如图上设定“BATCHID”这个列。第一次Nifi启动时捞取资料中最大BATCHID = 10，则下一次Nifi再次启动时就只会捞取BATCHID>10的资料，并且会自动记录下已经捞过的最大值
• 最大值保存在下面这里，Processor上右键选择“View State”
  
  
  
• 下图可以看到当前最新的值，点“Clear State”则可以将保留值清空（Nifi下次启动时就会捞取所有资料）
  
  
• 对于仅需要简单拉取资料的场景1来说，“Maximum-value Columns”置空即可；而对于仅在资料有更新时才要拉取的场景2来说，则需要设定并且在View中做出一些调整才可以达成
• 当有资料更新时，则被更新资料的BatchID会是更新的值，所以只要在View中虚拟BatchID列 = Max(BatchID)，就可以达成有资料更新才要拉取的效果

ConvertAvroToJSON，将Avro类型资料转换为JSON，这个可以不用改设定

PublishMQTT，将资料Publish到MQTT指定Topic

• Broker URI：MQTT的Broker地址
• Client ID：发布MQTT的Client端ID（注意不要多个Processor使用相同的Client ID，这样Processor容易被卡死）
• Topic：发布至MQTT的Topic名称
• Retain Message：MQTT的遗言属性，即是否保留推送的消息（若设为false，则仅有当前连上MQTT的客户端才能收到这笔消息）