盛夏時節，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](https://github.com/lf-edge/ekuiper/releases/tag/1.6.0).

## 面向 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)。

```prolog
{
  "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 進行建立。

[![Flow Editor](http://img.blog.itpub.net/blog/2022/08/04/5b228c75f583c28f.png?x-oss-process=style/bb "Flow Editor")](https://www.emqx.com/zh/blog/ekuiper-newsletter-202207 "Flow Editor")

## SQL 更新，編寫規則更輕鬆

新版本中新增了幾個 SQL 語法相關的更新：提供了 LAG 函式用於獲取資料流中之前的值；提供了 BETWEEN 和 LIKE 語法；修改了時間視窗使其對齊到自然時間。

### LAG 函式助力有狀態分析

LAG 函式可檢視資料流裡之前的資料並與當前的資料進行計算。它對於計算一個變數的增長率，檢測一個變數何時越過閾值，或一個條件何時開始或停止為真等等依賴快取狀態的計算都非常有用。之前版本中，有狀態計算依賴於視窗或者使用者自行擴充套件的外掛，複雜度較高。LAG 函式可以大大降低有狀態分析的門檻。

其使用語法為 lag(expr, [offset], [default value])，返回表示式前一個值在偏移 offset 處的結果，如果沒有找到，則返回預設值，如果沒有指定預設值則返回 nil。如果除 expression 外其餘引數均未指定，偏移量預設為 1，預設值為 nil。在下例中，我們計算了溫度值的變化率。

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

### 更多過濾方式

新版本中新增了 BETWEEN 和 LIKE 語法。其中，BETWEEN 用於數字型別資料的過濾，選出在一個範圍內的資料。LIKE 用於字串的過濾，選出滿足某個模式的字串。在下例中，我們選出了溫度在 15 到 25 之間，同時 deviceName 以 device 開頭的資料。

```n1ql
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](https://www.emqx.com/zh/blog/ekuiper-newsletter-202207)

eKuiper Newsletter 2022-07｜v1.6.0：Flow 編排 + 更好用的 SQL，輕鬆表達業務邏輯

相關文章