Flink CEP 新特性進展與在實時風控場景的落地

摘要：本文整理自阿里雲開發工程師耿飆&阿里雲開發工程師胡俊濤，在 FFA 實時風控專場的分享。本篇內容主要分為四個部分：
Flink CEP 介紹&新功能解讀
動態多規則支援與 Demo
Flink CEP SQL 語法增強
未來規劃
■ 分享中的動態 CEP 和 CEP SQL 新功能目前已在阿里雲實時計算 Flink 版上線支援。

點選檢視直播回放 & 演講PPT

一、Flink CEP 介紹&新功能解讀

1.1 什麼是 Flink CEP

CEP 是複雜事件處理 Complex Event Processing 的縮寫，而 Flink CEP 則是基於 Flink 實現的複雜事件處理庫，它可以識別出資料流中符合特定模式（Pattern）的事件序列，並允許使用者作出針對性處理。

下面我們舉個例子，如上圖所示，假設我們對模式 A、B、B、C 感興趣，它代表我們想要找到這樣的事件序列：A 類事件發生後，發生了兩次 B 類事件，又發生一次 C 類事件。注意，這裡我們並不要求事件之間是嚴格連續的。

當我們使用 Flink CEP 開發了相關程式碼並跑起作業後，遇到 d1、a1、b1、b2、d2、c1 的事件流，Flink CEP 就能找到其中的 a1、b1、b2、c1 這一次匹配，之後使用者就可以在作業中針對這次匹配做出處理，比如傳送報警到下游系統等。

1.2 Flink CEP 應用場景

在實際場景中，Flink CEP 基於 Flink 的分散式特性、毫秒級處理延遲以及自身豐富的規則表達能力有非常多的應用。我們這裡展示三個典型場景：

第一個場景，實時風控。Flink CEP 可以運用到風險使用者識別中，例如讀取並分析客戶行為日誌，將 5 分鐘內轉賬次數超過 10 次且金額大於 10000 的客戶識別為異常使用者。
第二個場景，實時營銷。Flink CEP 可以用來做營銷策略的最佳化，比如檢測使用者行為日誌，從而在電商大促時，找到“10 分鐘內，在購物車中新增超過 3 次的商品，但最終沒有付款”的使用者，針對性的調整營銷策略。同樣，在實時營銷的反作弊場景中，我們也可以使用 Flink CEP。
第三個場景，物聯網。Flink CEP 可以用於檢測異常狀態併發出告警，比如共享單車被騎出指定區域，且 15 分鐘內沒有回到指定區域時發出風險提示。如果和物聯網感測器結合，還可以用於檢測工業生產中的流水線異常。比如檢測到三個時間週期內，溫度感測器都反饋溫度超過設定閾值，就釋出報警等等。

1.3 Flink CEP 在 1.16 的改進

在 1.16 版本中，Flink CEP 主要包含四個改進。

FLINK-27392：支援在 Pattern 內的相鄰事件之間定義時間視窗。之前 Flink CEP 的時間視窗只能定義到整個複合 Pattern 中，這個改進則允許在兩個相鄰的子 Pattern 之間也定義時間視窗，提高了靈活性，之後會有個例子詳細介紹這個改進。
FLINK-26941：支援在帶有視窗的 Patten 中以 notFollowedBy 結尾。1.16 之前 notFollowedBy 語法只能出現在 Pattern 中間，現在我們允許在定義時間視窗的前提下，把 notFollowedBy 放到 Pattern 的結尾。
FLINK-24865：支援批模式下使用 MATCH_RECOGNIZE。1.16 支援在批模式下使用 Flink SQL 的 MATCH_RECOGNIZE 語法，進而呼叫 Flink CEP 的能力。
FLINK-23890：最佳化 Timer 建立策略。它改進了 Flink CEP 實際執行中定時器的建立策略，降低了 CPU 的消耗。

接下來舉一個簡單的例子來演示 1.16 的新特性給使用者帶來的好處。

在營銷場景中，我們希望使用者在領取品類優惠券，並新增對應品類商品後，馬上下單付款。如果沒有付款，我們會採取一些針對性的措施。把剛才的描述細化成一個具體的營銷場景，也就是尋找大促當天在領取優惠券後的五分鐘內，向購物車中新增了商品，但最終沒有結賬付款的使用者。找到這些使用者就可以讓下游業務方進行使用者分析，或者採取營銷措施（例如實時傳送提醒訊息等）。

針對該場景，1.16 後我們就可以寫出上圖中的 Pattern。首先起始判斷的條件是領取了優惠券，具體判斷優惠券領取的邏輯，我們寫在 StartCondition 對應的程式碼中。中間的 Pattern 是 addItem，它對應著新增商品到購物車，具體的判斷邏輯我們寫在 MiddleCondition 程式碼中。

注意，這裡我們在相鄰的子 Pattern 之間定義了 Within 時間視窗，型別為 REVIOUS_AND_CURRENT，它表示只有在領取優惠券事件發生後的五分鐘內，發生的新增商品事件，才會被納入這次模式匹配的考慮中。

最後以 notFollowedBy 結尾，後面是付款 Pattern，並且定義整個付款 Pattern 的時間視窗是一天。可以看到整個 Flink CEP 的 Pattern 寫起來更輕鬆，表達能力也更強。

二、動態多規則的設計與雲上實踐

2.1 動態規則支援：背景

在介紹我們為什麼需要動態規則更新前，先看一下右邊的圖，明確一下規則究竟包含哪些要素。我們認為 Flink CEP 中的規則（即 Pattern）是由閾值、條件、事實三部分組成的。下面我們以“五分鐘內透過廣告連結訪問某商品超過五次，但最終沒有購買”為例來介紹這三個要素。

閾值指的是超過五次中的“五”；事實指的是規則所針對的動作，比如透過廣告連結訪問某商品等；而條件則是用來描述如何過濾符合要求的動作。比如超過五次中的“超過”。

明晰規則的組成要素後，我們也更容易理解為什麼需要支援規則動態更新。在實際生產中，頻繁變化的現實場景要求我們對規則的內容，進行修改或者新增。

比如有一個 CEP 作業會在某個使用者在一分鐘內連續進行某操作超過 10 次後將其認為是風險使用者。但在流量暴增或者舉行某些活動的時候，這個閾值被改為 20 或者 30 次才更合適。現有的條件下想要更新規則，我們只能重新編寫 Java 程式碼，再重啟作業來使最新規則生效。

這樣做時間成本高、延遲敏感的作業很難接受，除此之外，如果規則的時間視窗較長，狀態又比較大的話，重啟作業的代價會更高，因此我們需要支援動態規則更新。

要做到這一點，我們有兩個關鍵問題需要解決。

第一，如何讓 Flink 作業不停機載入新規則。第二，如何解決規則（Pattern）的序列化與反序列化。第二個問題本質上是由第一個問題衍生而來的。如果想讓作業不停機載入，作業就必須從某個地方拿到我們傳給它的 Pattern，並生成對應的 Pattern 物件在作業中使用。

針對上述兩個問題，有一些現有的解決方案，比如透過修改 CepOperator 新增註入規則的介面，來實現不停機載入，以及基於 Groovy 引擎動態生成 Pattern 物件，解決序列化問題。但我們也發現，這兩個方案其實都有一些不足。

比如第一個方案，通常情況下，規則都會儲存在資料庫中，而典型的對 CepOperator 的修改，則是讓 CepOperator 直接和資料庫互動，拉取最新規則。這樣當 CEP 作業併發較多的時候，每個 sub_task 都要去連線資料庫，這會給資料庫帶來額外的壓力，並且更大的問題是，不同的 sub_task 拉取到的規則一致性難以保證。除此之外，這種修改通常只支援修改單條規則，不容易擴充到多規則的場景。

對於第二個方案，使用 Groovy 引擎動態生成 Pattern 物件也有自己的缺點。比如它的表達能力有限，一般只能結合 Aviator 動態修改閾值，很難改變規則整體的邏輯。並且 Groovy 是一個較重的引擎，它生成規則的時間也相對較長。

2.2 動態規則支援：設計

基於以上提到的背景和問題，阿里的同學在社群內提出了 FLIP-200，並在阿里內部按照 FLIP-200 實現了一版 CEP 中動態多規則的支援。下面我將詳細介紹我們是如何實現的，以及如何解決剛才提到的那些問題。

首先我們新增了 PatternProcessor 介面，用於完整的定義 CEP 中的一條規則。PatternProcessor 包含 getId，getVersion 等用於獲取該 Pattern 唯一識別符號的方法；getTimestamp 等用於獲得時間戳，進行排程的方法；getPattern 物件用於拿到 PatternProcessor 所內嵌的規則；PatternProcessorFunction 用於描述如何處理找到的匹配。除此之外，為了功能的完整性，我們還新增了 PatternProcessorDiscoverer 和 PatternProcessorManager，用於描述如何發現和管理 Processor。

下面介紹一下動態規則支援的整體架構。首先要提一下 Flink 的 OperatorCoordinator 機制，顧名思義它負責協調 Flink 作業中的各個 operator。OperatorCoordinator 自身執行在 JobManager 中，可以給 TM 的 Operator 傳送事件，之前主要在 Source 和 Sink 中使用，用於發現和分配讀寫的 Workload。

在 CEP 中我們也複用了這一機制，實現了 DynamicCEPOperatorCoordinator，它是 JobManager 中執行的執行緒，負責呼叫 PatternProcessorDiscoverer 介面拿到最新的 Pattern。

上圖左側展示的是從資料庫中讀取序列化後的 PatternProcessor 的過程。可以看到 Operator 拿到 PatternProcessor 後，會傳送給和它關聯的 DynamicCEPOperator。DynamicCEPOperator 接收到傳送的事件並進行解析與反序列化，最終生成要使用的 PatternProcessor 並構造對應的 NFA，用於處理上游傳送的事件並輸出到下游。

另外注意一下，這裡允許一個 CepOperator 裡有多個 NFA 對應多個 PatternProcessor，這樣可以比較好的支援多規則。

基於這樣的方式，我們就可以做到不停機的更新規則內容，且只有 OperatorCoordinator 會和外部規則資料庫互動，可以有效減少對資料庫的訪問，並保證了各個下游 sub_task 中使用規則的一致性。

2.3 動態規則支援：(de)serialization

接下來我們來思考下 Pattern 的抽象。Pattern 本質上是描述了規則匹配時用到的 NFA 的狀態轉換圖，即根據輸入事件如何從一個狀態轉移到另一個狀態，直到終態為止。

有了這樣的觀察後，我們就可以稍微做一些簡化。比如將一個複合 Pattern 看成一個圖，節點是每個子 Pattern，邊則對應事件選擇策略，即如何從一個子 Pattern 的匹配轉移到另一個子 Pattern 的匹配。而每個圖也可以看作是一個更大的圖的子節點，這樣我們就允許了模式的巢狀。

那麼我們該如何描述這個圖呢？我們定義的格式有如下幾個設計原則。

有完整的表達能力，能對標完整的 Java API。
方便序列化和反序列化，最好能依賴於一個常見的格式。
易於擴充，方便整合。當使用者或者平臺方新增一個欄位或者一個型別的時候要足夠方便，方便被更上層平臺修改和使用。
可讀可編輯，方便策略人員在視覺化頁面理解與編輯規則內容。

根據這些原則，最終我們選擇了基於 JSON 定義一套描述 Pattern 的規範。下面用一個簡單的例子來展示我們定義的 JSON 格式。

上圖左側是我們用 Java API 定義的示例 Pattern，當滿足 StartCondition 的事件出現大於等於三次之後，如果跟著一個滿足 EndtCondition 的事件，那麼我們就認為這是一個匹配。

可以注意到這裡的 Pattern 包含兩個子 Pattern，第一個 Pattern 對應 Star Pattern，第二個 Pattern 對應 End Pattern，邏輯上也存在兩條邊。由於 StartCondition 包含 timesOrMore 的宣告，所以它有一條指向自己的邊，另外也有一條從 StartCondition 指向 EndCondition 的邊。

上圖右側就是用我們定義的 JSON 格式來描述 Java Pattern 得到的結果。我們注意這裡有幾個關鍵欄位。

第一個是 node 欄位，它是一個陣列，包含每個子 Pattern 的完整描述，比如這裡我們用 times 欄位表示這個子 Pattern 對應的 Condition，要被滿足大於等於三次。第二個是 edges 欄位，它用於記錄邊的資訊。

整個 JSON 格式完整的定義，可以參考阿里雲的官方文件。

2.4 動態規則支援：擴充 Condition

接下來我們介紹一下我們是如何支援動態修改 Condition 中使用的閾值。和業界典型的實踐一樣，我們基於 Aviator 表示式引擎定義了 AviatorCondition。在 AviatorCondition 的建構函式中，根據輸入的表示式字串生成 AviatorExpression，然後在 filter 方法中透過反射來解析傳入的事件欄位和閾值，執行 AviatorExpression，最後返回 true or false 作為 filter 這個方法的返回結果。

舉一個簡單的例子，假設有一個叫 Event 的類，它有兩個欄位 price 和 action。那麼我們就可以構造一個這樣的 AviatorCondition，它的引數是一個表示式字串，這個字串裡描述了對 Event 中事件欄位的取值要求。比如我們要求 action==1&&price>20。如果我們想要更新閾值，就直接修改表示式，變成 action==0&&price>50。

注意這個字串是傳入的引數，它也可以在我們剛才介紹的 JSON 格式中定義和描述，所以我們也可以直接編輯資料庫中的欄位進行閾值的動態更新。

2.5 多規則支援

多規則是指在同一輸入流上運用多條規則。按照開源 Flink CEP 的方案，我們要想在一個 Flink 作業中做到這點，就需要定義多個 Pattern Stream，對應也會生成多個 CepOperator 和 NFA，這也意味著上游資料要複製多次，這顯然帶來了很多額外的開銷。

所以我們進行了最佳化，允許一個 DynamicCEPOperator 在它裡面構建多個 NFA，這樣上游的資料只需要傳遞一次，避免了額外的資料複製。

2.6 動態 CEP Demo

接下來我們以廣告投放中的實時反作弊場景來演示動態 CEP Demo。

首先為大家介紹一下 demo 所針對的場景，我們知道在電商平臺投放廣告時，廣告主通常有預算限制。例如對於按點選次數計算費用的廣告而言，如果有黑灰產構造虎假流量，攻擊廣告主，就會很快消耗掉正常廣告主的預算，使得廣告內容被提前下架。

在這種情況下，廣告主的利益受到了損害，容易導致後續的投訴與糾紛。為了應對上述作弊場景，我們需要快速辨識出惡意流量，採取針對性措施。例如限制惡意使用者、向廣告主傳送告警等來保護使用者權益。同時考慮到可能有意外因素，例如達人推薦、熱點事件引流等導致某一商品的流量驟變，我們也需要動態調整用於識別惡意流量的規則，避免損害正常使用者的利益。

本 Demo 將為大家演示如何使用 Fink 動態 CEP 解決上述問題。

我們假設客戶的行為日誌會被存放入訊息佇列 Kafka 中，Fink CEP 作業會消費 Kafka 資料，同時會去輪詢 RDS 資料庫中的規則表，拉取策略人員新增到資料庫的最新規則，並用最新規則去做事件匹配。針對匹配到的事件，Flink CEP 作業會發出告警或將相關資訊寫入其他資料儲存中，整體資料鏈路如上圖所示。

在一會兒的演示中，我們對使用者的日誌做了一些簡化，日誌中的 action 欄位，它的值如果為 0，就代表點選事件，為 1 代表購買事件，為 2 代表分享事件。接下來為大家演示具體的操作步驟。

首先需要建立好 Flink 全託管例項、RDS MySQL 例項、訊息佇列 Kafka 例項。然後準備好資料庫相關內容，在 RDS 控制檯建立 database。

注意在配置好之後，我們要在資料庫連線中設定白名單，來保證我們的 Flink 全託管例項能訪問 RDS 資料庫。

然後開啟 RDS 的 SQL 編輯頁面建立一張資料表，命名為 RDS demo，四個欄位 id、version、pattern、function。id 和 version 用於標名唯一的版本和 id 資訊，pattern 代表了序列化後的 Pattern Stream，function 用於指代要用的 PatternProcessor 的函式名。然後編寫 Flink DataStream 作業並打包提交到 Flink 全託管例項中執行。

接下來為大家介紹 main 函式的大致流程以及部分關鍵實現。首先讀取一些必要的引數用於構造 KafkaSource 以及 RDS 資料庫的一些連線資訊。然後對 Source 基於使用者和商品的 ID 做 keyBy，方便後續進行 CEP 的匹配。

接下來介紹一下在動態 CEP 中引入的新介面 DynamicPatterns。它有四個引數，第一個用來指定輸入事件流，第二個引數 PatternProcessorDiscovererFoctory 用來構造 PatternProcessorDiscoverer；第三個引數 TimeBehaviour 用來指定是按照 even time 處理事件還是按照 processing time 處理事件；第四個用來描述輸出流的型別資訊。

另外注意這裡用的是 JDBCPeriodPatternProcessorDiscovererFactory，它會週期性地掃描指定的資料庫，檢測到更新後，會對應地更新 Flink CEP 作業中使用的 PatternProcessor。

完成作業的打包後，我們接下來把作業上傳到 Flink 全託管中，然後指定了一些必要的引數，比如 KafkaBrockers 以及 RDS 的一些連線資訊，然後點選上線，進入運維，啟動作業。

接下來我們在 RDS 資料庫中插入插入規則 1： “連續 3 條 action 為 0 的事件發生後，下一條事件的 action 仍非 1”，其業務含義為連續 3 次訪問該產品但最後沒有購買。

它的 JSON 序列化表現如上圖。

然後將該條 JSON 資料插入到資料庫中。

接下來我們去作業中檢視一下 TaskManager 日誌，可以看到已經插入了最新規則。

接下來我們嘗試往 Kafka 中傳送幾條訊息來驗證 CEP 的匹配邏輯，這裡直接發四條一樣的訊息。

接下來檢測一下，TaskManager 中是否有相應的輸出。可以看到(id=1, version=1)的規則的最新匹配，匹配的事件序列就是剛才傳送的那四條事件。

然後我們來驗證動態修改這個規則並插入新的規則。這裡將出現次數改為大於等於五次，StartCondition 的判斷條件也改為 action==0 或者 action==2，然後執行插入。同時我們插入第二條規則，它的 ID 為 2，版本為 1，內容和規則 1 的第 1 個版本完全一致，主要用來輔助展示對多規則的支援。

接下來可以在作業日誌中檢視到我們剛剛插的兩個規則，然後用 Kafka 傳送三條 action 為 0 的訊息，一條 action 為 2 的訊息，並將之前的四條訊息再發一遍。

接著我們檢視作業的匹配結果，可以看到針對(id=1, version=2)的規則，作業匹配到 1 次“5 個 action 為 0 或 1 的事件+1 個 action 非 1 的事件”的序列後輸出了匹配結果，代表動態修改的規則成功生效；而對於(id=1, version=2)的規則，CEP 作業匹配到 2 次“3 個 action 為 0 的事件+1 個 action 非 1 的事件”的序列後輸出結果，代表新增的規則也在作業中被採用。

三、Flink CEP SQL 語法增強

3.1 Flink CEP SQL 簡介

Flink CEP SQL 主要基於 SQL2016 標準中的行模式識別語句，將 Flink 流表，例如上圖中的 csv_source 作為 MATCH_RECOGNIZE 語句的輸入，使用非確定有窮狀態機對流表中的時序資料進行匹配，最終對識別出特定模式的資料序列進行計算後重新輸出為 Flink 流表，從而無縫對接 Flink SQL 生態。

其 MATCH_RECOGNIZE 語句主要包含以下幾個部分：

PARTITION BY 定義表的邏輯分割槽，類似 GROUP BY 操作，用於在並行執行時確定資料的分割槽。
ORDER BY 指定資料的排序方式，由於 CEP 需要在時序資料中識別特定模式，排序是必須的，並且要求 ORDER BY 的第一個欄位必須是升序的時間屬性。
MEASURES 類似 SELECT 操作，對識別出的序列執行對映、聚合等操作計算輸出結果。例如，上圖中使用了 FIRST、LAST、COUNT 函式對迴圈模式 A 執行了聚合計算，而對普通模式 B 則執行了簡單的對映操作。
PATTERN 是 MATCH_RECOGNIZE 語句的核心，使用類似正規表示式的語法來定義匹配的序列模式。例如，上圖中的 A + B 表示序列中先連續出現一個或多個 A 事件，緊接再出現一個 B 事件。
DEFINE 定義 PATTERN 中所使用變數對應的事件匹配條件。例如，PATTERN 中 A 和 B 對應資料中 event_type 欄位的不同取值。若 PATTERN 中使用的變數在 DEFINE 中未定義，則表示任意匹配一條資料。

對於上圖中的源表，示例中的 CEP SQL 語句會輸出四條結果，其中 Alice 使用者識別到序列為 AAAB，如紅色箭頭所指。由於預設使用的 AFTER MATCH 策略為 SKIP TO NEXT ROW，結果表中會包含 AAAB 序列的兩個子序列 AAB、AB 對應的輸出。對於 Bob 使用者則匹配到 AB 序列，如藍色箭頭所指。

3.2 Flink CEP SQL 語法增強

目前 Flink CEP 的主要工作集中在 Java API 上，但基於 Flink SQL 和其他 SQL 類 ETL 軟體龐大的使用者群和成熟的生態考慮，我們也儘可能在保持對 SQL 標準相容的同時，持續完善和改進 Flink CEP SQL 的功能和使用體驗。

在最近的工作中，Flink CEP SQL 主要在語法層面對以下三個功能進行了支援：

輸出帶時間約束模式的匹配超時序列。
定義事件之間的連續性。
定義迴圈模式中的連續性和貪婪性。

■ 01 輸出帶時間約束模式的匹配超時序列

在目前版本的 Flink CEP SQL 中可以透過 WITHIN 語句對模式的整體匹配時間進行約束。例如一個常見的應用場景是使用者行為模式識別，從流量入口到最終完成使用者價值轉化的一系列流程中，我們希望整體流程週期在十分鐘之內的高潛使用者，則可以像上圖中在 PATTERN 後使用 WITHIN INTERVAL 加時間引數來進行約束。

例如對於上圖中的源表，前面的 MATCH_RECOGNIZE 語句示例將會匹配到 Alice 使用者在十分鐘之內完成了 ABC 操作。而 Bob 使用者由於 C 操作距離 A 操作已經過去了 13 分鐘，將會匹配失敗。

但可能也存在這樣的需求，對於這些流程週期超過十分鐘或流程中斷的使用者，我們也希望能夠識別出來，進一步去分析其超時或中斷的原因。那麼我們可以如上圖中示例，在 ONE ROW PER MATCH 之後使用 SHOW TIMEOUT MATCHES 來宣告輸出匹配超時的序列。

在 Java API 中，我們使用 Output Tag 來將超時序列輸出到側流處理，而在 SQL 中，匹配超時序列和匹配成功序列會在同一張流表中，但對超時序列未匹配到的事件，在 MEASURES 中計算將會得到空值。上圖結果表中 Bob 使用者的 C 操作超時，因此得到 C 的對映操作結果也為空值。透過這些空值，我們可以將這些匹配超時序列從流表中分離出來，並且判斷是在哪個步驟超時的。

■ 02 定義事件之間的連續性

在使用 Flink CEP Java API 的時候，我們可以透過函式很方便地定義事件之間的連續性，例如用 next()指定嚴格連續，模式中相鄰的事件在資料流中必須緊接著出現，使用 followedBy()則可以指定鬆散連續，模式中相鄰事件匹配時可以忽略一些不匹配的事件。

之前的 Flink CEP SQL 中只支援宣告嚴格連續，即表中第一行的語法，現在每一個 Java API 中的連續性函式在 SQL 中都有了對應的表達方式。

例如 followedBy()對應的 SQL 語法，在 A 和 B 之間使用 SQL EXCLUDE 的語法，即{- X*?-}，其中使用了一個未在 DEFINE 中定義的變數 X 來表示任意匹配，並使用 X*?表示非貪婪地匹配 0 至任意多個任意事件，其效果是 exclude 部分會連續匹配任何非 B 的事件，等效於 followedBy()的語義。在 followedBy() SQL 語法的基礎上去掉 X 上的非貪婪修飾即為 followedByAny()的語義。對於 notNext()，則使用[^B] 的表達形式，表示 A 事件之後緊接著不能出現 B 事件。對於 notFollowedBy()，只需要將 followedBy()和 notNext()的 SQL 語法結合使用即可。

■ 03 定義迴圈模式中的連續性和貪婪性

對於一個迴圈模式，例如上表中的 A+，在之前的 Flink CEP SQL 中已經支援了貪婪性的宣告，不使用任何符號為貪婪匹配，使用一個問號則為非貪婪。兩者的區別是，例如上圖示例中當 a3 可以同時匹配 A 條件或 C 條件，貪婪匹配會選擇更長的序列，而非貪婪則會選擇更短的。

現在我們在原有貪婪性的宣告上新增了對連續性的宣告，使用??表示鬆散連續且貪婪，???表示鬆散連續非貪婪。迴圈模式的鬆散連續可以認為是在迴圈模式中的事件之間使用 followedyBy 關係，例如 a1、a2 之間有非匹配的 b1 事件，在嚴格連續的情況下，a1 會無法匹配到迴圈模式 A 中，如表中(A+ C)得到的 a2 a3 c1 序列，而鬆散連續的情況下則可以跳過 b1 事件而形成更長的匹配序列，例如(A+?? C)得到的 a1 a2 a3 c1 序列。

四、未來規劃

Flink CEP 未來工作的重點還是在動態 CEP 和 CEP SQL 上：

擴充套件動態 CEP 多規則能力到靜態場景。在目前版本的 Flink CEP 中，如果要在靜態場景下使用多規則的話，只能透過建立多個 CepOperator，而這會帶來資料的額外複製。在動態 CEP 中我們已經支援了在一個 Operator 中處理多條規則的能力，後續會將這個能力擴充套件到靜態場景中。
動態 CEP 的 JSON 格式規則描述支援定義引數化的 Condition。目前只有示例中的 AviatorCondition 支援在 JSON 中傳入表示式作為構造的引數，其他 Condition 只能傳入類名。因此之後我們考慮透過 Condition 的引數化來提高自定義 Condition 的擴充套件性，避免需要動態新增新的 Condition 類實現。
CEP SQL 表達能力增強。一方面 CEP SQL 相比 Java API 缺失的能力是首要進行對齊的，另一方面我們可以看到 PATTERN 定義的語法和正則語法非常相似，未來我們也會去做更多對正則語法的對齊，讓使用者在定義 PATTERN 的時候更加自然。
動態 CEP 作為一個備受關注的新功能，我們計劃讓 Flink CEP SQL 也支援動態 CEP，能夠在保持 schema 不變的情況下動態更新事件匹配條件和模式的定義。