eKuiper 1.8.0 釋出：零程式碼實現影像/影片流的實時 AI 推理

EMQX發表於2023-03-01
UIAI
LF Edge eKuiper 是 Golang 實現的輕量級物聯網邊緣分析、流式處理開源軟體，可以執行在各類資源受限的邊緣裝置上。eKuiper 的主要目標是在邊緣端提供一個流媒體軟體框架（類似於 Apache Flink ）。eKuiper 的規則引擎允許使用者提供基於 SQL 或基於圖形（類似於 Node-RED）的規則，在幾分鐘內建立物聯網邊緣分析應用。

近日，eKuiper 釋出了 1.8.0 版本。該版本的主要亮點有：

  • 零編碼 AI 推理： 透過通用 AI 函式，使用者無需編碼即可針對流式資料或影片流實現實時 AI 演算法推理。該函式可以推理任意的 Tensor Flow Lite 模型。使用者模型訓練完成後下發模型即可使用，十分靈活快捷。
  • 視覺化規則建立： 管理控制檯中整合了視覺化規則編輯器 Flow Editor。使用者使用免費的 eKuiper manager 管理控制檯時，可透過視覺化拖拽 UI 進行規則的新建和編輯。
  • 更靈活的資料傳輸配置： 重構了外部連線 source/sink 的格式和序列化實現，解耦了格式和傳輸協議，並支援更多的格式如 csv 和自定義格式。

完整功能列表，請檢視 Release Note。

同時，產品團隊也重構了文件結構，更新了安裝和應用場景文件，方便使用者快速找到有用的文件資訊。

通用 AI 函式

之前的版本中，eKuiper 支援透過擴充套件的方式，在外掛中呼叫 AI/ML 模型進行流式資料演算法推理。這種方法方便使用者進行演算法的預處理和後處理，但有較高的使用門檻，運維更新也比較複雜。

新版本提供了 Tensor Flow Lite 函式外掛，用於在流式計算和影片流中進行實時 AI 推理。這個函式為通用的 AI 函式，可用於處理大部分已預訓練好的 Tensor Flow Lite 模型。使用中，使用者只需上傳或提前部署好需要使用到的模型，無需額外編碼即可在規則中使用這些模型。

tfLite 函式接收兩個引數，其中第一個引數為模型（副檔名須為 .tflite）的名稱，第二個引數為模型的輸入。假設使用者預先訓練好了文字分類模型 text_model 和智慧回覆模型 smart_reply_model，需要對實時流入 eKuiper 的資料應用這兩個模型分析。使用時僅需要兩個步驟：

  1. 下發模型到 eKuiper 部署的邊緣端，可透過 eKuiper 的 upload API 或者其他應用管理。
  2. 配置規則，使用 tfLite 函式，指定模型名稱即可使用，如下示例：
SELECT tfLite(\"text_model\", data) as result FROM demoModel
SELECT tfLite(\"smart_reply_model\", data) as result FROM demoModel

函式會在 eKuiper 層面針對輸入資料格式進行驗證。使用者可以透過更多的 SQL 語句對模型的輸入和輸出做預處理或者後處理。

影像/影片流推理

配合新版本提供的影片流源（詳情見下文），eKuiper 提供了影片接入並定時獲取影像幀的能力。影像幀可在規則中，使用 tfLite 函式進行 AI 推理。Tensor Flow 模型通常是針對特定的影像大小進行訓練的，對影像進行推理時，經常需要進行變更大小等預處理。eKuiper 也提供了 resize、thumnail 等預處理方法。函式會返回 output tensor 的陣列表示供後續規則或應用處理。

在以下的規則 ruleTf 中，我們呼叫了 label.tflite 模型，對傳入的影像先進行預處理，大小調整為 224 * 224。

SELECT tfLite(\"label\", resize(self, 224, 224, true) as result FROM tfdemo

這個規則的執行示意圖如下所示。

1

使用通用 AI 函式，使用者可以快速部署、驗證和更新 AI 模型，加快應用的迭代更新。

視覺化編輯器 Flow Editor

eKuiper 從 1.6.0 版本開始提供適合面向視覺化介面的圖規則 API，相比於 SQL 更適合於構建 UI 介面。在 1.8.0 版本中，我們正式在免費的 eKuiper manager 管理控制檯中提供了 Flow Editor 視覺化編輯器。使用者在建立和編輯規則時，可選擇使用原有的 SQL 規則編輯器或使用試用版本的 Flow Editor。

Flow Editor 的介面如下圖所示。它的使用遵循主流視覺化工作量編輯器的風格和使用邏輯。左側是可用節點，使用者自定義外掛和函式也會出現在列表中。中間是畫布，使用者可拖拽節點並連線；右側是屬性配置檢視，點選節點後可在此配置。歡迎大家試用並反饋寶貴意見。

除了整合原有功能到 Flow Editor 中，新版本中還新增了兩種節點：

  • Switch node: 該節點允許訊息被路由到不同的流程分支，類似於程式語言中的 switch 語句。
  • Script node: 該節點允許針對傳遞的資訊執行 JavaScript 程式碼。

有了這兩種節點，Flow Editor 可以建立傳統多分支工作流並且更加容易進行節點的擴充套件，實現指令碼編寫。

連線格式最佳化和自定義：序列化和 Schema

eKuiper 透過 source/sink 與外部系統進行連線、讀入或寫出資料。以 source 為例，每種型別的 source 讀取資料時都需要經過連線（connect）和序列化（serialization）兩個步驟。例如，MQTT source，連線意味著遵循 MQTT 協議連線 broker，而序列化則是將讀取到的資料 payload 解析成 eKuiper 內部的 map 格式。

連線和序列化

此前，連線和序列化通常在 source 內部實現，因此當使用者需要解析自定義格式時，即使連線協議是 MQTT 等已支援協議，仍然需要編寫完整的 source 外掛。新的版本中，格式和 source 型別進一步分離，使用者可以自定義格式，而各種格式可以與不同的連線型別結合使用。自定義格式的編寫方法請參考格式擴充套件。

例如，建立 MQTT 型別的資料流時可定義各種不同的 payload 格式。預設的 JSON 格式：

CREATE STREAM demo1() WITH (FORMAT="json", TYPE="mqtt", DATASOURCE="demo")

MQTT 型別的資料流使用自定義格式，此時 MQTT 的 payload 中的資料應當使用自定義的格式：

CREATE STREAM demo1() WITH (FORMAT="custom", SCHEMAID="myFormat.myMessage", TYPE="mqtt", DATASOURCE="demo")

Schema

此前 eKuiper 支援在 Create Stream 的時候指定資料結構型別等。但該方式存在一些不足：

  • 額外效能消耗。當前的 Schema 沒有與資料原本的格式 Schema 關聯，因此在資料解碼之後，需要再額外進行一次驗證/轉換；而且該過程基於反射動態完成，效能較差。例如，使用 Protobuf 等強Schema 時，經 Protobuf 解碼之後的資料應當已經符合格式，不應再進行轉換。
  • Schema 定義繁瑣。同樣無法利用資料本身格式的 Schema，而是需要額外配置。

新的版本中，Stream 定義時支援邏輯 Schema 和格式中的物理 Schema 定義。SQL 解析時，會自動合併物理 Schema 和邏輯 Schema，用於指導 SQL 的驗證和最佳化。同時，我們也提供了 API，用於外部系統獲取資料流的實際推斷 Schema。

GET /streams/{streamName}/schema

格式列表

新版本中，支援的格式擴充套件到如下幾種。部分格式包含內建的序列化；部分格式（如 Protobuf）既可以使用內建的動態序列化方式也可以由使用者提供靜態序列化外掛以獲得更好的效能。在 Schema 支援方面，部分格式帶有 Schema，而自定義格式也可以提供 Schema 實現。

分析能力增強

新的版本繼續加強了有狀態分析函式的能力，同時提供了統計函式，提升了產品原生的分析能力。

有條件分析函式

分析函式新增了 WHEN 條件判斷子句，根據是否滿足條件來確定當前事件是否為有效事件。 當為有效事件時，根據分析函式語意計算結果並更新狀態。當為無效事件時，忽略事件值，複用儲存的狀態值。完整的分析函式語法為：

AnalyticFuncName(<arguments>...) OVER ([PARTITION BY <partition key>] [WHEN <Expression>])

增加了 WHEN 子句之後，分析函式可以實現更加複雜的有狀態分析。例如，計算狀態的持續時間：

SELECT lag(StatusDesc) as status, StartTime - lag(StartTime) OVER (WHEN had_changed(true, StatusCode)), EquipCode FROM demo WHERE had_changed(true, StatusCode)

其中，lag(StartTime) OVER (WHEN had_changed(true, StatusCode)) 將返回上次狀態變化時的時間。因此，使用當前時間減去該時間可實時計算出狀態的持續時間。

統計函式

新的版本中，我們提供了多個聚合統計函式，例如標準差、方差和百分位的計算。

連線生態擴充套件

eKuiper 可以處理二進位制影像資料，但是此前的測試中，影像都是經由 MQTT、HTTP 等偏向文字資料傳輸的協議來傳送。新版本提供了影片流源，增加了一種新的二進位制資料來源。另外，我們大幅增強了檔案 source 的能力，支援更多檔案型別並支援流式消費檔案內容。

檔案源

之前版本的檔案源主要用於建立 Table，對流式處理的支援不夠完善。新的版本中，檔案源也支援作為用作流，此時通常需要設定 interval 引數以定時拉取更新。同時增加了資料夾的支援，多種檔案格式的支援和更多的配置項。

新版本中支援的檔案型別有：

  • json：標準的 JSON 陣列格式檔案。如果檔案格式是行分隔的 JSON 字串，需要用 lines 格式定義。
  • csv：支援逗號分隔的 csv 檔案，以及自定義分隔符。
  • lines：以行分隔的檔案。每行的解碼方法可以透過流定義中的格式引數來定義。例如，對於一個行分開的 JSON 字串，檔案型別應設定為 lines，格式應設定為 JSON。

建立讀取 csv 檔案的資料流，語法如下：

CREATE STREAM cscFileDemo () WITH (FORMAT="DELIMITED", DATASOURCE="abc.csv", TYPE="file", DELIMITER=",")

影片流源

影片源用於接入影片流，例如來自攝像頭的影片或者直播影片流。影片流源定期採集影片流中的幀，作為二進位制流接入 eKuiper 中進行處理。

透過影片源接入的資料，可以使用已有的 SQL 功能，例如 AI 推理函式功能等，轉換成資料進行計算或輸出為新的二進位制影像等。

規則自動化運維

部署在邊緣端的規則運維相對困難。而邊緣端的部署數量通常較大，手工重啟規則或重啟 eKuiper 也會成為較為繁瑣的工作。新的版本中，我們增強了規則的自治和自適應能力。

規則自動重啟策略

規則因各種原因出現異常時可能會停止執行，其中有些錯誤是可恢復的。eKuiper 1.8.0 提供了可配置的規則自動重啟功能，使得規則失敗後可以自動重試從而從可恢復的錯誤中恢復執行。

使用者可配置全域性的規則重啟策略，也可以針對每個規則配置單獨的重啟策略。規則重啟配置的選項包括：

  • 重試次數
  • 重試間隔
  • 重試間隔係數，即重試失敗後重試時間增加的倍數
  • 最大重試間隔
  • 隨機重試延遲，防止多個規則總是在同一個時間點重試，造成擁塞

透過配置重試，可以在出現偶發錯誤時自動恢復，減少人工運維的需要。

資料匯入匯出

新版本中提供了 REST API 和 CLI 介面，用於匯入匯出當前 eKuiper 例項中的所有配置（流、表、規則、外掛、源配置、動作配置、模式）。這樣可以快速地備份配置或者移植配置到新的 eKuiper 例項中。匯入匯出的規則集為文字的 JSON 格式，可讀性較強，也可以手工編輯。

  • 匯出配置的 rest 介面為 GET /data/export，透過此 API 可匯出當前節點的所有配置
  • 匯出配置的 rest 介面為 POST /data/import，透過此 API 可匯入已有配置至目標 eKuiper 例項中
  • 如果匯入的配置中包含外掛（native）、靜態模式（static schema）的更新，則需要呼叫介面POST /data/import?stop=1
  • 匯入配置的狀態統計可用 GET /data/import/status 介面檢視

Portable 外掛熱更新

相比原生外掛，Portable 外掛更加容易打包和部署，因此也有更多的更新需求。之前的版本中，Portable 外掛更新後無法立即生效，需要手動重啟使用外掛的規則或者重啟 eKuiper。eKuiper 1.8.0 中，外掛更新後，使用外掛的規則可無縫切換到新的外掛實現中，減少運維工作。

版權宣告： 本文為 EMQ 原創，轉載請註明出處。

原文連結：https://www.emqx.com/zh/blog/ekuiper-v-1-8-0-release-notes

相關文章