2 か月の開発を経て、eKuiper 1.10.0 が正式にリリースされたことを発表できることを嬉しく思います。

eKuiper 1.10.0 はマイルストーンバージョンとして、Go 言語のバージョンが 1.20 にアップグレードされ、EdgeX が最新のメジャーバージョン Minnesota (v3) をサポートするなど、基本的な依存関係のバージョンがアップグレードされました。また、エッジ導入に向けて軽量かつコンパクトに保ちながら、製品の表現力、接続性、使いやすさの向上を続けています。

最新バージョンの新機能と改善点には主に次の点が含まれます。

ルール管理: ルールの実行時間を計画できるため、ルールのエッジ自律性がある程度実現されます。
接続エコロジー: EdgeX v3、Kafka シンク、ファイルシンクなどを含む、より多くのデータソースとターゲットを追加/改善しました。シンク/ソースは、データ抽出、バッチ処理、圧縮など、より効率的なデータ変換をサポートします。ユーザーがさまざまなデータソースとターゲットをより適切に接続し、より複雑なデータ構造に適応できるようにするため。
表現力: ユーザーがより複雑なデータ処理を実現できるように、配列とオブジェクトの処理、外部状態のサポート、配列の動的添字構文などの関数と構文が追加されました。

詳しいアップデート内容はアップデートログをご確認ください。

ルールの定期的な実行

シナリオによっては、ユーザーデータが定期的である場合があります。実行中のリソースを節約するために、ユーザーはデータがないときにルールを停止し、指定された期間のみルールを有効にしたいと考えています。ユーザーは、ルールを自動的かつ定期的に (毎朝、週に 1 回など) 実行する必要があります。ユーザーは eKuiper の API を使用してルールを手動で開始および停止できますが、エッジでの大規模な展開の場合、手動での開始および停止は現実的ではなく、エッジルールの自律性が差し迫っています。そこで、新バージョンのルールにはスケジュール実行機能を追加し、ユーザーがルールのスケジュール実行時刻を指定することで、手動操作なしで指定時間内に自動的にルールが開始・停止されるようにしました。

ルールのオプションにより、cronとという 2 つのパラメータが追加されますduration。

cronパラメーターはルールのスケジュールされた実行時間を指定し、形式は cron 式の形式に従います (0 0 0 * * *毎日午前 0:00 に 1 回実行するなど)。
durationこのパラメーターは、ルールの実行時間を期間文字列の形式で指定します。数値と時間単位 ( 1m1 分間の実行時間など) が含まれます。

たとえば、次のルールはオプションのパラメータによって 2 分ごとに実行されるように定義されており、各実行は 1 分です。

{
  "id": "ruleSchedule",
  "sql": "SELECT * FROM demo;",
  "options": {
    "cron": "*/2 * * * *",
    "duration": "1m"
  },
  "actions": [{
    "mqtt":  {
      "server": "tcp://broker.emqx.io:1883",
      "topic": "result/rule"
    }
  }]
}

期間は 2 つの cron サイクル間の時間間隔を超えてはいけないことに注意してください。そうでない場合、予期しない動作が発生します。

スケジュールされたタスクのルールの追加、削除、変更、状態照会は通常のルールと同様で、APIまたはCLIを通じて操作できます。スケジュールされたタスクが実行されると、ルールはRunning状態になります。スケジュールされたタスクの実行時間が経過すると、ルールは次のスケジュールの待機を自動的に停止し、ステータスがに変わりますStopped: waiting for next schedule.。Stop コマンドを使用してスケジュールされたタスクを停止すると、ルールが直ちに停止され、スケジューラから削除されます。

データソースとターゲットの柔軟な適応

eKuiper は、EdgeX Foundry のデフォルトのルールエンジン実装です。次期 EdgeX Minnesota (v3) は重要なバージョンであり、eKuiper もサポートされ、同時に更新されます。同時に、Kafka シンク、ファイルシンクなどのデータソースとターゲットも追加しました。これらのデータソースとターゲットのサポートにより、eKuiper はさまざまなデータソースとターゲットをより適切に接続し、さまざまなデータインフラストラクチャにより便利にアクセスできるようになります。

EdgeX v3 のサポート

EdgeX v3 は EdgeX Foundry の次に重要なバージョンであり、eKuiper 1.10.0 バージョンはすでに EdgeX v3 をサポートしています。eKuiper の EdgeX ソースとシンクは更新および適応されており、ユーザーの既存のルールはシームレスに EdgeX v3 に移行できます。

同時に、私たちのテストでは、eKuiper バージョン 1.10 は依然として EdgeX v2 と互換性があり、ユーザーはニーズに応じて EdgeX v2 または EdgeX v3 を選択できます。

ZeroMQ バスのサポートが EdgeX で削除されたため、eKuiper の EdgeX Source/Sink の zmq プロトコルサポートも削除されたことに注意してください。デフォルトの Redis バスまたは MQTT バスを使用しているユーザーは影響を受けません。

より強力なファイルシンク

ファイルシステムはオペレーティングシステムのカーネルに属し、外部システムへの依存関係を必要としないため、適用性が高く、ほぼすべての展開環境、特にリソースが限られているシステムに適用できます。ファイルシンクを使用すると、高度なセキュリティ要件がある環境、またはネットワークがない環境でデータをバッチで保持し、他の手段を通じてデータを他のシステムに転送して、ネットワークゲートウェイの侵入を実現する方法として使用できます。さらに、帯域幅が低い環境では、圧縮して送信する前にデータをバッチでファイルに書き込むことができるため、圧縮率が向上し、帯域幅の消費が削減されます。

以前のバージョンでのファイルコネクタの最適化を継続し、新しいバージョンでも、ファイルシンクは、csv、json、lines など、より多くのファイルタイプをサポートします。同時に、ファイルシンクは、データ抽出、バッチ処理、圧縮などのより多くのデータ変換をサポートするため、より多くのアプリケーションの適応に役立ちます。さらに、ファイル書き込みはカスタムセグメンテーション戦略をサポートし、より大きなデータ量とより便利な管理をサポートします。

ファイルシンクの新しいバージョンの主なハイライトは次のとおりです。

複数のファイル形式をサポートしており、書き込まれたファイルをファイルソースから読み取ってデータのサイクリック送信を実現します。
複数のセグメンテーション戦略がサポートされています。
- 時間による分割、ファイル分割の間隔時間の設定をサポート
- メッセージ数で割る
- ファイル名の重複を避けるためにファイル名を分割してタイムスタンプを自動的に追加し、タイムスタンプを追加する場所を設定します
複数のファイル、つまり動的ファイル名の書き込みをサポートします。メッセージの内容に応じて、メッセージを別のファイルに書き込むことでデータの迂回を実現します。
書き込みパフォーマンスの最適化、バッチ書き込みのサポート、書き込み効率の向上。複数のファイルを書き込む場合、同時書き込みがサポートされ、タイマーが共有されるため書き込み効率が向上します。
圧縮をサポートし、gzip と ztsd の 2 つの圧縮方法をサポートします。

これらの機能はすべてプロパティを通じて構成できます。以下は、ファイルシンクを使用したルールの例です。このうち、パスには動的なファイル名が採用されます。つまり、メッセージはメッセージの内容に応じて異なるファイルに書き込まれます。次の例では、ファイルタイプはに設定されcsv、rolling先頭の属性によってファイル分割戦略が構成されます。圧縮では、gzip 圧縮を使用して圧縮方法を構成します。詳しい設定手順については、製品ドキュメントを参照してください。

{
  "id": "fileSinkRule",
  "sql": "SELECT * from demo ",
  "actions": [
     {
      "file": {
        "path": "{
   
   {.device}}_{
   
   {.ts}}.csv.gzip",
        "format": "delimited",
        "delimiter": ",",
        "hasHeader": true,
        "fileType": "csv",
        "rollingCount": 10,
        "rollingInterval": 0,
        "rollingNamePattern": "none",
        "compression":"gzip"
      }
    }
  ]
}

カフカシンク

Kafka は、高スループット、高可用性、拡張性、耐久性を備えた分散メッセージシステムです。新バージョンでは、eKuiperのデータをKafkaに書き込むことができるKafka Sinkを追加し、eKuiperとKafkaのシームレスな接続を実現した。使用例は次のとおりです。

{
  "id": "kafka",
  "sql": "SELECT * from demo",
  "actions": [
    {
      "kafka":{
        "brokers": "127.0.0.1:9091",
        "topic": "sample_topic",
        "saslAuthType": "none"
      }
    }
  ]
}

データベースサポートの最適化

新しいバージョンでは、SQL ソース/シンクプラグインにいくつかの最適化が行われました。主に以下が含まれます：

ClickHouse ドライバーを更新し、ClickHouse のサポートをテストします。
Damenデータベースをサポートします。
データベース接続の効率を向上させるための接続プール構成をサポートします。

ユーザーは、構成ファイル etc/kuiper.yaml で sql/maxConnections プロパティを構成するか、環境変数を使用してデータベース接続プール内の最大接続数を指定し、接続数が多すぎることによって引き起こされるパフォーマンスの問題を回避できます。例は次のようになります。

  sql:
    # maxConnections indicates the max connections for the certain database instance group by driver and dsn sharing between the sources/sinks
    # 0 indicates unlimited
    maxConnections: 0

シンクデータ変換

ユーザーのデータは入れ子構造になっている場合があります。たとえば、Neuron がアクセスするデータには通常、何らかのメタデータが含まれており、ペイロードの値フィールドがユーザーが必要とするデータです。また、データ処理に複雑な SQL 文を使用する場合、計算の途中結果の一部を SELECT 句に定義する場合があり、そのすべてをシンクに出力する必要はありません。この場合、Sink 側でデータを再度変換またはフォーマットする必要があります。データテンプレートは一般的に使用される方法であり、強力でさまざまな形式をサポートしています。ただし、ユーザーにはテンプレートを作成するための一定の能力が必要であり、同時に実行パフォーマンスも悪くなります。

新しいバージョンでは、シンク側は、データ抽出、バッチ送信の関連属性など、より一般的に使用されるデータ変換をサポートし、ほとんどのシンクタイプに拡張されています。一般的に使用される一部の単純なデータ変換では、ユーザーがパラメーターを設定できるため、テンプレートを作成する際のユーザーの作業負荷が軽減され、操作効率が向上します。

一括送信

デフォルトでは、Sink はイベントごとに 1 つのデータを生成します。ただし、データスループットが大きいとIOオーバーヘッドが大きい、圧縮すると圧縮率が低い、クラウドに送信する際のネットワークオーバーヘッドが大きいなどの問題が発生します。同時に、送信速度が速いため、クラウド上の処理負荷が増大する可能性があります。これらの問題を解決するため、新バージョンではMQTT Sinkにおける一括送信機能をサポートしました。

バッチ送信の原理は、シンクが特定の戦略を採用してデータをキャッシュし、それを一度にクラウドに送信することです。ユーザーはパラメータbatchSizeとを設定することでlingerInterval、バッチで送信されるデータの量と時間間隔を制御できます。例は次のようになります。

{
    "id": "batch",
    "sql": "select a,b from demo",
    "actions": [
       {
        "log": {
        },
        "mqtt": {
          "server": "tcp://broker.emqx.io:1883",
          "topic": "devices/messages",
          "lingerInterval": 10000,
          "batchSize": 3
        }
      }
    ]
}

この例では、データ量が 3 に達するか、10 秒間蓄積されると、シンクはデータを 1 回送信します。ユーザーは、必要に応じてこれら 2 つのパラメータを調整できます。

データ抽出

中間データを使用する場合や、計算されたデータの形式が書き込まれたデータの形式と一致しない場合、Sink 側で必要なデータを抽出する必要があります。fields新しいバージョンでは、2 つの共通パラメータとがすべてのシンクに追加されますdataField。これら 2 つのパラメーターは、SQL、Redis、InfluxDB など、以前のデータストレージ関連のシンクでサポートされていました。データ書き込みでは、通常、ターゲットデータベースには厳密な列定義があり、SQL SELECT ステートメントは必ずしも列と一致しない可能性があり、多くの場合、冗長な選択フィールドが存在するためです。他のシンクでも、このようなデータ抽出要件が存在します。新しいバージョンでは、これら 2 つの属性が MQTT、Kafka、File などのシンクに拡張されています。その中で、dataFieldパラメータは、データを表すフィールドを指定し、メタデータなどの他のデータを表すフィールドと区別するために使用されますdataField: values。fieldsパラメータは、出力する必要があるフィールドを指定するために使用され、ターゲットシステム要件に正確に一致するようになりますfields: ["a","b"]。

例 1: Neuron データの値セクション出力を抽出します。次のように dataField 属性を構成して、ネストされたデータを抽出します。

{
  "id": "extract",
  "sql": "SELECT * FROM neuronStream",
  "actions": [
    {
      "mqtt": {
        "server": "tcp://broker.emqx.io:1883",
        "topic": "devices/messages",
        "dataField": "values"
      }
    }
  ]
}

例 2: 中間計算結果の一部のフィールドの出力を無視して、必要なフィールドを抽出します。以下に示すように、指定されたフィールドは、fields プロパティを構成することで抽出されます。

{
  "id": "extract",
  "sql": "SELECT temperature, lag(temperature) as lt, humidity FROM demo WHERE lt > 10",
  "actions": [
    {
      "mqtt": {
        "server": "tcp://broker.emqx.io:1883",
        "topic": "devices/messages",
        "fields": ["temperature","humidity"]
      }
    }
  ]
}

この例では、SQL ステートメントでlag(temperature) as lt中間計算結果が生成されます。これは、WHERE フィールドでのフィルター処理に便利で、SQL の記述が簡素化されます。ただし、シンク側ではtemperatureとのhumidity2 つのフィールドだけが必要なので、fieldsプロパティを構成して出力する必要があるフィールドを指定します。

これら 2 つの属性は同時に使用することも、DataTemplate と組み合わせて使用して、より複雑なデータ変換を完了することもできます。3 つのプロパティをすべて構成した後、最初に DataTemplate が実行され、次に dataField が実行され、最後に dataField のデータ抽出が実行されます。

配列とオブジェクトの処理

SQL 構文はもともとリレーショナルデータベース用に設計されたもので、データベース内の複合データ型が少ないため、配列やオブジェクトの処理能力が限られています。IoT シナリオでは、アクセスされるデータ形式はほとんどが JSON であり、ネストされた複合データ型は第一級の要素です。eKuiper SQL には、最初からネストされたデータにアクセスする機能が組み込まれています。しかし、より深いデータ変換に対する満たされていないニーズは依然として数多くあります。新バージョンでは、配列データの複数行への変換や配列・オブジェクトの処理機能など、配列・オブジェクトの処理機能を強化しました。

データソースをサポートする配列ペイロード

データソースが JSON 形式を使用する場合、以前のバージョンでは JSON オブジェクトのペイロードのみがサポートされていましたが、新しいバージョンでは JSON 配列のペイロードがサポートされます。さらに、ユーザーが設定する必要はなく、システムが自動的にペイロードタイプを識別します。

たとえば、配列型データは、新しいバージョンの MQTT ソースでアクセスできます。

[
    {"temperature":23},
    {"temperature":24},
    {"temperature":25}
]

配列データを受信すると、データは複数のデータに分割されて処理され、各データには配列要素が含まれます。例えば上記のデータは3つのデータに分割されます。以降の処理は通常のJSONオブジェクトデータと同様です。

データを複数の行に配列する

一部のデータソースはデータのバッチで渡されますが、共通のメタデータがいくつかあるため、全体的な形式は依然として JSON オブジェクトです (次のデータなど)。このデータ形式は、HTTP サービスの戻り値で特に一般的です。

{
    "device_id": "device1",
    "data": [
        {"temperature":23},
        {"temperature":24},
        {"temperature":25}
    ]
}

このようなデータは、 eKuiper では1 行のデータとして処理されます。論理的には、ユーザーが必要とするのは複数行のデータです。新しいバージョンでは、単一行データを複数行処理に変換するために使用される新しい関数タイプ、複数行関数が追加されました。また、唯一の複数行関数を追加しましたunnest。配列の列を複数行に展開するために使用されます。

unnest | unnest(array) | パラメータ列は配列オブジェクトでなければなりません。この関数はパラメータ配列を複数行に展開し、結果を返します。配列オブジェクト内の各サブ項目が map[string]interface{} オブジェクトの場合、そのサブ項目は返される行の列としてリストされます。

ネストされたデータは複数の行として処理できるため、複数の出力結果が得られます。たとえば、上記のデータでは 3 つの出力結果が得られます。

使用例

フローデモを作成し、次の入力を行います。

{"a": [1,2], "b": 3}

ネスト解除の結果を取得するためのルール:

SQL: SELECT unnest(a) FROM demo
___________________________________________________
{"unnest":1}
{"unnest":2}

他の列のネスト解除結果を取得するためのルール:

SQL: SELECT unnest(a), b FROM demo
___________________________________________________
{"unnest":1, "b":3}
{"unnest":2, "b":3}

フローデモを作成し、次の入力を行います。

{"x": [{"a": 1,"b": 2}, {"a": 3,"b": 4}], "c": 5}

他の列のネスト解除結果を取得するためのルール:

SQL: SELECT unnest(x), b FROM demo
___________________________________________________
{"a":1, "b":2, "c": 5}
{"a":3, "b":4, "c": 5}

配列およびオブジェクト処理関数

新しいバージョンでは、配列とオブジェクトを関数の形式で処理する機能が改善されました。たとえば、 list 内の最大値を取得する関数array_max、 list 内の最小値を取得する関数array_min、 list 内の要素の数を取得する関数array_length、 list 内の要素を取得するarray_element関数、オブジェクト内の要素を取得しますobject_element。現在サポートされている関数については、関数のドキュメントを確認してください。

次のバージョンでは、配列とオブジェクトを処理する機能を引き続き強化する予定です。

入れ子構造にアクセスするための糖衣構文

おそらく、eKuiper を初めて使用するユーザーからの最も一般的な質問は、入れ子構造のデータにアクセスする方法です。標準 SQL にはそのような構文は定義されていません。プログラミング言語では、通常、ネストされたデータにアクセスするためにドット (.) を使用します。ただし、SQL ではピリオドはテーブル名を表します。したがって、埋め込み構造にアクセスするために矢印表記 (->) を使用するように SQL 構文を拡張しました。ただし、この構文は直感的ではないため、初心者にとっては学習コストがかかります。

新しいバージョンでは、入れ子構造へのアクセスを簡素化するために、入れ子構造アクセス構文糖衣を追加しました。あいまいさがない場合、ユーザーはドット表記を使用してネストされた構造にアクセスできます。たとえば、次のデータの場合:

{
    "a": {
        "b": {
            "c": 1
        }
    }
}

ステートメント内で直接使用して、a.b.cネストされた構造にアクセスできます。元の矢印表記も引き続き互換性を持ってサポートされていますa->b->c。

外部状態のサポート

eKuiper はステートフルストリーム処理エンジンであり、ウィンドウの状態、分析関数の状態などの状態は主に内部で使用されます。以前のリリースでは、テーブルを介した外部状態へのより粒度の高い (行ベースの) アクセスがサポートされていました。新しいバージョンでは、キー (列) ベースの外部状態ストレージとアクセス機能が追加されました。外部状態アクセスを通じて、動的しきい値や動的スイッチ状態など、より多くの機能を実現できます。ユーザーはサードパーティのアプリケーションとステータスを簡単に共有して、共同作業を実現できます。

外部状態ストレージは、システムの内部状態ストレージと共存することも、独立して使用することもできます。外部状態ストアは SQLite または Redis もサポートします。KV ベースの Redis は、外部状態の保存に適しています。設定ファイル etc/kuiper.yaml で、外部状態ストレージのタイプを設定できます。

store:
  #Type of store that will be used for keeping state of the application
  extStateType: redis

状態アクセス: サードパーティアプリケーションがキャッシュデータ$device1$temperatureL「20」を書き込んだと仮定します。SQL では、get_keyed_state関数を通じて外部状態にアクセスできます。たとえば、get_keyed_state(\"$device1$temperatureL\", \"bigint\", 0) as temperatureLこれにより外部状態が計算に参加できるようになります。
状態の書き込み: 計算結果を Redis 外部状態に書き込む必要がある場合、Redis シンクを使用できます。新しいバージョンでは、Redis シンクは一度に複数のキーと値のペアの書き込みをサポートします。次の例では、のkeyTypeように設定することでmultiple、複数のキーと値のペアを一度に書き込むことができます。field書き込むフィールド名は設定項目で指定することもできます。

{
  "id": "ruleUpdateState",
  "sql":"SELECT status as `$device1$status`,temperatureH as `$device1$temperatureH`,temperatureL as `$device1$temperatureL` FROM stateStream",
  "actions":[
    {
      "redis": {
        "addr": "{
   
   {localhost}}:6379",
        "dataType": "string",
        "keyType": "multiple",
        "sendSingle": true
      }
    }
  ]
}

SQL 構文の更新

前述のいくつかの SQL 構文の更新に加えて、新しいバージョンには次の SQL 構文の更新も含まれています。

現在のルールを取得する

rule_id()現在のルールの ID を取得する関数が追加されました。これは、ユーザーがデータによって生成されたルールを追跡するのに便利です。

配列の動的添字

新バージョンでは、配列の添字に式を使用して動的なインデックス付けを実現できるようになりました。たとえば、SELECT a[start] FROM streamは、start値が変数であるフィールドにすることができ、添え字には任意の式を使用できます。

動的化により、以前のバージョンでは実現が困難であった非常に柔軟な配列操作が可能になります。たとえば、パイプライン上には複数のセンサーがあり、そのデータは配列として収集されます。物体が組立ラインに入った後、組立ラインと速度に従って組立ライン上の物体の位置を計算し、物体のセンサーデータを決定することができる。この計算処理は、配列の添え字を動的に計算することで実現できます。

遅延実行機能

新バージョンでは遅延実行機能を追加しました。これらの関数を実行すると、一定期間の遅延が発生します。たとえば、delay関数は遅延後に入力の値を返します。

データ目的にトラフィック制限がある場合、この機能を使用してピークの除去と谷の埋め合わせの効果を実現します。

グラフ API の機能強化

新しいバージョンでは、定義されたストリームとクエリテーブルにアクセスするための Graph API のサポートが追加されました。また、JoinOp はストリームとルックアップテーブルをサポートします。また、ユーザーがエラーを見つけやすくするために、Graph API 検証メッセージも改善されました。グラフ API とそれに基づくビジュアルエディタでも、より多くのデータ処理機能を実現できます。

Create Streamユーザーは、およびを通じてCreate Tableストリームを定義し、テーブルにクエリを実行する必要があります。Graph API ルールでは、sourceNameプロパティを通じて定義されたストリームとルックアップテーブルをポイントできます。たとえば、次のルールでは、demoはalertTable定義されたストリームとクエリテーブルをそれぞれ指します。

{
  "id": "ruleAlert",
  "graph": {
    "nodes": {
      "demo": {
        "type": "source",
        "nodeType": "mqtt",
        "props": {
          "sourceType": "stream",
          "sourceName": "demo"
        }
      },
      "alertTable": {
        "type": "source",
        "nodeType": "memory",
        "props": {
          "sourceType": "table",
          "sourceName": "alertTable"
        }
      },
      "joinop": {
        "type": "operator",
        "nodeType": "join",
        "props": {
          "from": "demo",
          "joins": [
            {
              "name": "alertTable",
              "type": "inner",
              "on": "demo.deviceKind = alertTable.id"
            }
          ]
        }
      },
      "log": {
        "type": "sink",
        "nodeType": "log",
        "props": {}
      }
    },
    "topo": {
      "sources": ["demo", "alertTable"],
      "edges": {
        "demo": ["joinop"],
        "alertTable": ["joinop"],
        "joinop": ["log"]
      }
    }
  }
}

依存関係の更新

EdgeX 関連の依存関係に加えて、eKuiper は次の依存関係も更新しました。

Go言語バージョンが1.20に更新されました
SQLite の依存関係が純粋な Go バージョンに切り替わりました
Redis は GitHub に依存しています - redis/go-redis: Redis Go クライアントが v9 に更新されました
デフォルトの zeroMQ 依存関係を削除します。
他の依存ライブラリを更新する

特別な感謝

eKuiper バージョン 1.10 の開発は、コミュニティからの強力なサポートを受けています。

以下の貢献者に心より感謝いたします。

@carlclone: Kafka シンクの実装とさまざまな圧縮/解凍アルゴリズムの実装に貢献しました。
@wangxye: 複数の配列/オブジェクト関数に貢献しました。

開発チームとすべての貢献者の多大な努力と献身に感謝します。eKuiper を楽しんでください!

著作権に関する声明: この記事は EMQ によるオリジナルです。転載する場合は出典を明記してください。
元のリンク: https://www.emqx.com/zh/blog/ekuiper-v-1-10-0-release-notes

eKuiper 1.10.0 リリース: タイミングルールと EdgeX v3 の適応

ルールの定期的な実行

データソースとターゲットの柔軟な適応

EdgeX v3 のサポート

より強力なファイルシンク

カフカシンク

データベースサポートの最適化

シンクデータ変換

一括送信

データ抽出

配列とオブジェクトの処理

データソースをサポートする配列ペイロード

データを複数の行に配列する

配列およびオブジェクト処理関数

入れ子構造にアクセスするための糖衣構文

外部状態のサポート

SQL 構文の更新

現在のルールを取得する

配列の動的添字

遅延実行機能

グラフ API の機能強化

依存関係の更新

特別な感謝

おすすめ

eKuiper 1.10.0 リリース: タイミング ルールと EdgeX v3 の適応

ルールの定期的な実行

データソースとターゲットの柔軟な適応

EdgeX v3 のサポート

より強力なファイルシンク

カフカシンク

データベースサポートの最適化

シンクデータ変換

一括送信

データ抽出

配列とオブジェクトの処理

データソースをサポートする配列ペイロード

データを複数の行に配列する

配列およびオブジェクト処理関数

入れ子構造にアクセスするための糖衣構文

外部状態のサポート

SQL 構文の更新

現在のルールを取得する

配列の動的添字

遅延実行機能

グラフ API の機能強化

依存関係の更新

特別な感謝

おすすめ

eKuiper 1.10.0 リリース: タイミングルールと EdgeX v3 の適応