关于物联网:eKuiper-Newsletter-202207｜v160Flow-编排-更好用的-SQL轻松表达业务逻辑

隆冬季节，eKuiper 本年度第二个大版本 v1.6.0 如约而至。面向 Flow 编排的图规定 API 的开发和外部试用打磨贯通了整个冬季版本的开发过程，终于在 7 月实现。与此同时，咱们也实现了多个 SQL 语法和函数的晋升，冀望 Flow 编排 和 SQL 双剑合璧可能帮忙用户更容易地表白业务逻辑，笼罩更多样的应用场景，进一步缩小定制开发的需要和老本。此外，咱们也优化了内部零碎连贯的应用。例如 EdgeX 和 MQTT 连贯中断时不再退出规定、SQL 和 TDengine Sink 反对批量写入等。

在之前的 Newsletter 中，咱们曾经陆续介绍过 v1.6.0 已开发实现的一些新性能，包含 protobuf 编解码的反对、离线缓存和重发等。本期 Newletter 将介绍其余新性能。残缺的性能列表请查看1.6.0 Release.

面向 Flow 编排的图规定 API

在之前的版本中，eKuiper 的规定逻辑是通过 SQL + actions 的形式指定的。基于 SQL 语法的规定好处多多：

• SQL 语法利用宽泛，对于有技术背景的用户来说，比拟容易上手。
• SQL 语法简洁，在数据库畛域已失去宽泛验证，能够用很短的文本写出简单的规定。
• SQL 是申明式的语言，执行引擎须要解析生成执行打算。这样，执行引擎可自行对理论运行的执行打算进行优化而无需用户做任何更改。

SQL 在解决数据变换为外围的规定时显得得心应手。然而在局部场景中，SQL 语法并不是很适合。

• 面向非技术人员的场景，SQL 难以上手。
• 对于某些场景，SQL 语法难以表白或者过于简单。例如，对某个事件依据模式匹配做分流解决，温湿度传感器的数据，若温度大于某个值，则做一种流程，温度小于某个值则执行另一个流程。总体来说，Flow 可笼罩更多的场景。
• SQL 因为本身形象水平高，难以实现 UI。

图规定 API 采纳 JSON 格局，间接形容运行时执行的算子的有向无环图构造，可一对一映射成 UI 上的 Flow 编排。新的版本中，图规定 API 将作为 SQL 的补充提供。

值得注意的是，SQL 规定在新版本中依然残缺反对，用户可依据场景选用应用的 API。其中，SQL 更适宜用户手写规定，而图 API 因为 JSON 构造简短，较适宜由 UI 生成。

应用办法

图规定 API 与 SQL 共用以后的规定 REST API endpoint，创立规定的时候通过指定 graph 属性来应用。graph 属性是有向无环图的 JSON 表述。它由 nodes 和 topo 组成，别离定义了图中的节点和它们的边。上面是一个由图形定义的最简略的规定。它定义了 3 个节点：demo，humidityFilter 和 mqttOut。这个图是线性的，即demo->humidityFilter->mqttOut。该规定将从 MQTT 的 demo 主题读取数据，通过湿度做过滤(humidityFilter)并将后果汇入 MQTT 的另一个主题(mqttOut)。

{
  "id": "rule1",
  "name": "Test Condition",
  "graph": {
    "nodes": {
      "demo": {
        "type": "source",
        "nodeType": "mqtt",
        "props": {
          "datasource": "devices/+/messages"
        }
      },
      "humidityFilter": {
        "type": "operator",
        "nodeType": "filter",
        "props": {
          "expr": "humidity > 30"
        }
      },
      "mqttout": {
        "type": "sink",
        "nodeType": "mqtt",
        "props": {
          "server": "tcp://${mqtt_srv}:1883",
          "topic": "devices/result"
        }
      }
    },
    "topo": {
      "sources": ["demo"],
      "edges": {
        "demo": ["humidityFilter"],
        "humidityFilter": ["mqttout"]
      }
    }
  }
}

图的 JSON 中的每个节点至多有 3 个字段：

• type：节点的类型，能够是source、operator和sink。
• nodeType：节点的实现类型，定义了节点的业务逻辑，包含内置类型和由插件定义的扩大类型。
• props：节点的属性。它对每个 nodeType 都是不同的。

对于 source 和 sink，其 nodeType 与零碎中内置的和通过插件扩大的类型齐全对应。对于 operator 节点，咱们提供了一系列对应 SQL 语法的内置节点，打到与 SQL 雷同的表达能力。用户扩大的函数，可通过 funciton 节点或者 aggfunc 节点进行调用。残缺的节点列表，请参考https://ekuiper.org/docs/zh/latest/rules/graph_rule.html#内置-operator-节点类型 。

Flow Editor

在 eKuiper 外围版本中仅提供后盾的图规定 API，厂商和用户可基于此实现拖拽的图形界面。咱们也将在近期推出 Flow 编排 实现，不便用户应用。

参考实现的图形界面如下所示。图形界面中可在左侧画板中列出可用的内置和扩大节点，容许节点拖拽到画布上并连接成图、设置属性等。画板上的数据流图可不便地示意为 JSON，通过图规定 API 进行创立。

SQL 更新，编写规定更轻松

新版本中增加了几个 SQL 语法相干的更新：提供了 LAG 函数用于获取数据流中之前的值；提供了 BETWEEN 和 LIKE 语法；批改了工夫窗口使其对齐到天然工夫。

LAG 函数助力有状态剖析

LAG 函数可查看数据流里之前的数据并与以后的数据进行计算。它对于计算一个变量的增长率，检测一个变量何时越过阈值，或一个条件何时开始或进行为真等等依赖缓存状态的计算都十分有用。之前版本中，有状态计算依赖于窗口或者用户自行扩大的插件，复杂度较高。LAG 函数能够大大降低有状态剖析的门槛。

其应用语法为 lag(expr, [offset], [default value])，返回表达式前一个值在偏移 offset 处的后果，如果没有找到，则返回默认值，如果没有指定默认值则返回 nil。如果除 expression 外其余参数均未指定，偏移量默认为 1，默认值为 nil。在下例中，咱们计算了温度值的变化率。

SELECT lag(temperature) as last, temperature,  lag(temperature)/temperature as rate FROM demo

更多过滤形式

新版本中增加了 BETWEEN 和 LIKE 语法。其中，BETWEEN 用于数字类型数据的过滤，选出在一个范畴内的数据。LIKE 用于字符串的过滤，选出满足某个模式的字符串。在下例中，咱们选出了温度在 15 到 25 之间，同时 deviceName 以 device 结尾的数据。

SELECT * FROM demo WHERE temperature BETWEEN 15 AND 25 AND deviceName LIKE "device%"

天然工夫窗口

之前 eKuiper 工夫窗口的开始工夫是以理论窗口开始运行工夫为准的。然而在理论场景中，工夫的聚合通常都是基于天然工夫。例如，1 个小时的工夫窗口，冀望的后果是每个天然小时的聚合。大部分的流式解决引擎也会将工夫窗口对齐到天然工夫中。因而，在本版本中，工夫窗口的聚合也对齐到零碎时区的天然工夫。

更高效和稳固的连贯

eKuiper 通过 source 和 sink 与内部零碎进行连贯。本版本中着力进步连贯的稳固行和效率，次要改良了现有的 source 和 sink 的性能。

数据库批量写入

在 SQL sink 和 TDengine Sink 中，增加了属性 tableDataField，可写入内嵌的数据（单行或多行）。同时，二者在接管到数组数据（多行数据）时，将一次性批量写入所有的数据。

稳固 EdgeX 连贯

改良了 EdgeX 的连贯逻辑，当音讯总线连贯中断时不会立刻退出规定也不会打印大量的 log 造成风暴。音讯总线复原后，可主动重连。总之，连贯 EdgeX 的规定在创立后运行更加稳固，不会因为可复原的谬误而退出。

版权申明： 本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/ekuiper-newsletter-202207