eKuiper 專案填補了邊緣端實時計算的空白，在工業物聯網、車聯網等領域得到了越來越廣泛的應用。根據 GitHub、微信群、論壇等多個渠道收集到的大量使用者反饋，我們對 eKuiper 的易用性和可靠性進行了持續提升，並於近日正式釋出了 1.5.0 版本。

本次更新主要亮點有：

- SQL 改進：用於定義資料流和分析規則的 eKuiper 核心功能 SQL 提供了包括變化監測函式以及 object_construct 函式等在內的更多內建函式，提升了表達能力；
- 生態連線：提供內建的 Neuron 連線支援，可以輕鬆處理 Neuron 生態中的資料；同時通用的 SQL 外掛可以接入多種傳統 SQL 資料庫，一定程度上實現批資料的流式處理。
- 運維和文件改進：規則執行時穩定性提升，支援按需編譯。文件的導航結構重構，閱讀體驗和查詢效果提升。

社群站網址：https://ekuiper.org/zh

GitHub 倉庫：https://github.com/lf-edge/ekuiper

Docker 映象地址：https://hub.docker.com/r/lfedge/ekuiper

## 生態連線

各種 source/sink 是 eKuiper 連線資料處理生態的途徑。新版本中，eKuiper 新增了更多的連線型別 Neuron 和 SQL。同時我們也改進了原有連線，例如 TDEngine sink 中新增了超級表的支援。

### Neuron 整合

[Neuron](https://www.emqx.com/zh/products/neuron) 是一個EMQ 發起並開源的工業物聯網（IIoT）邊緣工業協議閘道器軟體，用於現代大資料技術，以發揮工業 4.0 的力量。它支援對多種工業協議的一站式訪問，並將其轉換為標準 MQTT 協議以訪問工業物聯網平臺。Neuron 和 eKuiper 整合使用，可以方便地進行 IIoT 邊緣資料採集和計算。

在之前的版本中，Neuron 與 eKuiper 之間需要採用 MQTT 作為中轉。二者協同時，需要額外部署 MQTT Broker。同時，使用者需要自行處理資料格式，包括讀入和輸出時的解碼編碼工作。Neruon 2.0 版本與 eKuiper 1.5.0 版本將無縫整合，使用者無需配置即可在 eKuiper 中接入 Neruon 中採集到的資料，進行計算；也可以方便地從 eKuiper 中反控 Neuron 。兩個產品的整合，可以顯著降低邊緣計算解決方案的部署成本，簡化使用門檻。使用 NNG 協議，使用程式間通訊，也可顯著降低網路通訊消耗，提高效能。

使用者接入 Neuron 時，只需要在 eKuiper 中建立一個型別為 Neuron 的流:

```n1ql
CREATE STREAM demo() WITH (TYPE="neuron",SHARED="TRUE")
```

反控 Neuron 時，需要在規則的動作裡新增 Neuron 動作，指定需要寫入的組名，節點名和 tag 名（均可為動態屬性）。eKuiper 將會自動轉換格式，適配 Neuron 的輸入格式。

```prolog
"neuron": {
  "nodeName": "{{.node}}",
  "groupName": "grp",
  "tags": [
    "tag0"
  ]
}
```

詳細資訊，請參考文件 [Neuron 源](https://ekuiper.org/docs/zh/latest/rules/sources/builtin/neuron.html)和 [Neuron Sink](https://ekuiper.org/docs/zh/latest/rules/sinks/builtin/neuron.html)。

### SQL 拉取和寫入

SQL 拉取源提供了一種批次資料轉為流式資料的方式，使得 eKuiper 支援初步的流批一體處理的方式。

在舊的系統升級改造過程中，我們往往還需要考慮對原有的系統的相容。大量的老舊系統採用傳統關聯式資料庫儲存採集的資料。在新的系統中，可能也有儲存在資料庫中，不方便提供流式接入的資料卻需要進行實時計算的資料。還有更多的場景需要接入形形色色數量龐大的支援 SQL 的資料庫或其他外部系統。

eKuiper 提供了統一的\多資料庫通用的 SQL 拉取 source，可定時拉取支援 SQL 的資料來源的資料，並提供基礎的去重能力，形成流式資料進行統一的流式計算處理。該外掛的預編譯版本支援 MySQL、PostgresSQL 等常見資料庫的接入；同時外掛中搭載了幾乎所有常見資料庫的連線能力，使用者只需要在編譯時提供所需支援的資料庫的引數，即可自行編譯支援自定義資料庫型別的外掛。

除了資料拉取，我們也提供了資料寫入的通用 SQL 外掛。值得注意的是，eKuiper 本身已經提供了針對 InfluxDB、TDengine 等時序資料庫的專用外掛。通用 SQL 外掛同樣可以支援連線這些資料庫，但提供的是 insert 功能，不支援特定資料庫的非標準概念，例如 TDengine 的超級表只能使用 TDengine 外掛進行寫入。

更多資訊以及支援的資料庫列表，請參見 [SQL source 外掛](https://ekuiper.org/docs/zh/latest/rules/sources/plugin/sql.html)和 [SQL sink 外掛文件](https://ekuiper.org/docs/zh/latest/rules/sinks/plugin/sql.html)。

## eKuiper SQL 改進

內建函式是 SQL 完成各種計算的主要組織形式，也是 SQL 表達能力的重要來源。新版本中的 SQL 改進主要透過新增新的函式來實現。

### 變化監測函式

新的版本中新增了三個通用的變化檢測相關函式： CHANGED_COLS，CHANGED_COL 和 HAD_CHANGED 。

CHANGED_COLS 函式的作用是檢測指定的列是否發生變化，如果發生變化，則返回變化的列的值，否則不返回。在變化檢測的場景中，使用者經常需要監測多個列/表示式，而且數量不固定。因此，該函式可接收不定數量的引數，同時其返回值為多個列。相比於普通的標量函式固定返回單一結果列（多列結果會被包含在 map 中），這是第一個返回多列的函式，我們對函式的實現進行了重構以實現多列函式的支援。該函式的引數個數是可變的，同時列的引數也可以是別的表示式。列引數也支援星號，表示檢測所有列，例如 SELECT CHANGED\*COLS("c\*", true,* ) FROM demo。

多列函式僅可在 Select 子句中使用，其選出的值不能用於 WHERE 或其他子句中。若需要根據變化值做過濾，可以使用 CHANGED_COL 函式獲取變化後的值做為過濾條件；或者使用 HAD_CHANGED 函式獲取多個列的變化狀態作為過濾條件。詳細資訊和使用示例，請參考[文件](https://ekuiper.org/docs/zh/latest/sqls/built-in_functions.html#監控變化的函式)。

### 對選擇的列進行分組

規則的 SQL 語句中 select 選擇出的所有列會組成一個物件，供 sink 外掛和下游的應用進行處理。在有些場景中，下游應用需要對選擇的列進行分組，然後靈活地對每個分組進行處理。例如，把選擇出來的結果分成多個 key/value 集合，其中 key 為檔名，這樣可以動態地把結果寫入到多個檔案中。

新的內建方法 object_construct 可以輕鬆實現列的分組和命名。其語法為 object_construct(key1, col, ...)，可支援多個引數，並返回由引數構建的物件 。引數為一系列的鍵值對，因此必須為偶數個。鍵必須為 string 型別，值可以為任意型別。例如，使用者需要把列 1，2，3 寫入到檔案 1；而列 4，5 寫入到檔案 2 中。則可使用一條 SQL 規則對列進行分組，並對組名進行賦值：

```reasonml
SELECT object_construct("key1", col1, "key2", col2, "key3", col3) AS file1, object_construct("key4", col4, "key5", col5) AS file2 FROM demoStream
```

其輸出結果形如下列 JSON 物件：

```json
{
"file1":{"key1":"aValue","key2":23,"key3":2.5},
"file2":{"key4":"bValue","key5":90}
}
```

## 運維更容易

新的版本在運維方面的主要改進包括提升了執行時的穩定性，提供了方便的編譯引數方便使用者根據需求進行軟體功能的裁剪以適應更小算力的裝置。

### 規則隔離

新的版本中，我們對規則執行和生命週期進行了最佳化和重構，增加了規則執行的穩定性，提高規則之間的隔離性。主要表現在以下幾個方面：

規則錯誤隔離：即使是使用共享源的規則，某個規則的執行時錯誤也不會影響另外的相關規則。同時，新版本的規則系統級的 panic 錯誤也會在規則級別進行處理，不再導致整個 eKuiper 程式崩潰。

規則負載隔離：使用共享源或者記憶體源的兄弟規則之間，在保持訊息順序的同時，訊息流入吞吐量不受其他規則的影響。

### 按需編譯

作為邊緣流式處理引擎，需要部署的異構目標系統很多，既有算力較好的邊緣端的機房、閘道器等，也有出於成本以及業務的特殊要求考慮而採用成本更便宜或是定製化的軟硬體方案。隨著功能的逐漸增強，全功能的 eKuiper 在極端資源受限的裝置上，例如記憶體少於 50MB 的終端上，可能會稍顯臃腫。新的版本中，我們將 eKuiper 的核心功能和其他功能透過 go 語言的編譯標籤進行剝離。使用者在使用的時候，可以透過設定編譯引數的方式，按需編譯部分功能，從而得到更小的執行檔案。例如，僅編譯核心功能，可使用 make build_core 得到一個只包含核心功能的執行檔案。進一步資訊，請參考 [按需編譯](https://ekuiper.org/docs/zh/latest/features.html)。

## 文件更易用

在 4 月上線的官網（[https://ekuiper.org](https://ekuiper.org/) ）中，eKuiper 文件進行了目錄結構的重構，並編譯到文件網站上。新的文件網站增加了概念介紹、教程等模組，調整了導航樹，希望能幫助使用者更方便地找到有用的資訊。

## 升級說明

eKuiper 的版本迭代會盡量保持新舊版本的相容，新的版本也不例外。升級到 1.5.0 版本，大部分功能無需改動即可平穩升級，但是有兩處改動需要使用者手動更改：

1. Mqtt source 的伺服器配置項由 servers 改成 server，配置值由陣列改為字串。使用者的配置檔案 etc/mqtt_source.yaml 中需要進行更改。若使用環境變數，例如Docker 啟動和 docker compose 檔案啟動等，需要更改環境變數：MQTT_SOURCE**DEFAULT**SERVERS =》 MQTT_SOURCE**DEFAULT**SERVER 。Docker 啟動的命令更改為 docker run -p 9081:9081 -d --name ekuiper MQTT_SOURCE**DEFAULT**SERVER="$MQTT_BROKER_ADDRESS" lfedge/ekuiper:$tag。
2. 若使用 Tdengine sink, 其屬性名 ip 改為 host , 屬性值必須為域名。

## 號外：eKuiper 在開源之夏 2022

開源之夏是由「開源軟體供應鏈點亮計劃」發起並長期支援的一項暑期開源活動，旨在鼓勵在校學生積極參與開源軟體的開發維護，培養和發掘更多優秀的開發者。

作為開源專案，LF edge eKuiper 也參加了今年的開源之夏活動，並開放了兩個專案。其中，流式計算視窗函式最佳化探索專案涉及通用的流式處理知識和前沿研究方向，是以實戰方式深入瞭解流式處理的硬核專案。而 WASM 函式擴充套件專案側重於 eKuiper 的生態擴充套件，上手比較容易，有助於瞭解時下較為熱門的 WASM 技術在邊緣側的應用。

關於本屆開源之夏的更多資訊請檢視：https://www.emqx.com/zh/blog/summer-ospp-2022 ，期待大家的參與！

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/ekuiper-v-1-5-0-release-notes](https://www.emqx.com/zh/blog/ekuiper-v-1-5-0-release-notes)

eKuiper 1.5.0 釋出: 實現無縫式工業資料採集+邊緣流處理

相關文章