Apache Flink複雜事件處理指南 - softwaremill

banq發表於2020-12-08
Apache事件REM

如今，流處理是一個非常流行的話題。公司處理成千上萬個需要實時或近實時處理的事件。企業需要分析客戶的行為，交易，股票價格變化甚至自動駕駛汽車感測器讀數。但是，今天，我們要專注於複雜事件處理。
 

什麼是複雜事件處理（CEP）
事件流可以以不同的方式處理。在最簡單的情況下，獨立分析單個事件就足夠了。如果溫度感測器的值高於50°C，則傳送警報。在更高階的情況下，將一起分析事件的組或視窗，例如，如果平均5分鐘的溫度感測器讀數高於50°C，則傳送警報。這樣可以過濾異常值和錯誤的讀數。但是，CEP涵蓋了甚至更復雜的情況，其中對流進行分析以尋找特定的資料模式或趨勢。例如，我們檢視5個溫度讀數，這些數值的增長值超過了目標限值，同時煙霧感測器開啟。
CEP允許我們定義各種規則。我們可能會嘗試查詢型別A後面型別B的事件。我們可能還想查詢沒有事件B的事件A。可能與訂單，時間，數字有關。意味著它們之間可能還會發生其他型別的事件。對於人類來說，這聽起來似乎很簡單，但是在處理大資料時，它開始成為主要的計算挑戰。而且，為了拯救人們的生命，經常需要即時接收演算法的結果。
在工業4.0時代，不需要僅在大資料中心中執行復雜的分析。我們注意到圍繞邊緣AI和邊緣分析的術語的增長趨勢。專門的物聯網微晶片與感測器一起部署，因此可以在本地執行分析，從而省去了與將資料傳輸到雲相關的延遲。這樣，可以更快地採取適當的措施。
 

複雜事件處理用例
哪種用例最適合CEP？好吧，我們在資料流中尋找特定模式的所有內容。為了進一步說明，讓我們看幾個例子。

  • 演算法股票交易

在金融世界中，利用技術分析來預測股票價格的走勢。有很多資訊可以使用，但是最重要的資訊涉及交易價格和交易量。僅基於這兩個指標，就有很多模式。各種三角形，楔形，頭和肩膀，雙頂/底等。其中一些實際上看起來很簡單，但是並不是每個人都有時間手動跟蹤整個股票市場的圖表。還有一些更復雜的方法，例如與Wyckoff方法有關的方法。CEP用於建立支援股票交易的系統，也可用於演算法交易系統。
  • 欺詐識別

該領域最常見的主題是信用卡欺詐。銀行會嘗試檢測您的卡詳細資訊是否可能被盜，以免造成損失。可疑模式中可以包含哪些內容？例如，交易晚點或在世界各地的位置。如有任何疑問，將與客戶聯絡以確認交易。
愛沙尼亞的SEB銀行利用Apama Complex Event Processing進行付款欺詐檢測。
  • 系統安全

安全是一個困難的話題，涉及組織的各個領域。可用的解決方案主要集中在異常或入侵檢測以及網路監控。在資訊來源中，最重要的是網路日誌，可以對其進行分析以找出可疑模式。
進一步閱讀：複雜事件處理系統在異常檢測和網路監控中的應用

意外的硬體故障總是代價高昂。它們導致停機時間和生產計劃複雜化。如何避免它們？有些技術僅基於特定模型的故障統計資訊。但是，這些只是統計資訊，永遠不會100％準確。更現代的方法是監視裝置並從各種感測器收集讀數。資料中的模式可能表明裝置即將失效。
  • 其他用例

我們僅描述了一些特定的用例領域，但是更多的用例是可能的。在商務智慧，天氣報告，業務活動監控，點選流分析或自動駕駛工具中也提到了複雜事件處理。範圍非常廣泛，並且隨著工業和5G物聯網的增長趨勢，對於複雜的場景，將需要分析越來越多的資料。
 

用於複雜事件處理的技術
由於可以使用“複雜事件處理”來分析廣泛的領域，因此實際上有大量的產品和工具可以實現此技術。其中一些專門用於特定用例，其中一些僅在付費產品中可用。每個主要參與者都有與CEP相關的產品-例如Azure流分析，Microsoft StreamInsight，SAP ESP，TIBCO BusinessEvents和Streambase。讓我們更深入地研究一種有前途的開源解決方案Apache Flink。
 

Apache Flink
Apache Flink是用於批處理和流處理的工具。通常將它與Apache Spark進行比較，因為它提供了非常相似的功能。但是，從CEP角度來看，有一個主要區別：分別用於複雜事件處理的模組和DSL。
假設我們要在至少三個溫度高於50°C的事件之後傳送警報，然後發出煙霧。
首先，我們需要定義事件型別，以表示系統處理的訊息。

 sealed trait Event

  case class TemperatureEvent(value: Double) extends Event
  case class SmokeEvent() extends Event
  case class LightEvent(value: Double) extends Event


上面Scala程式碼中宣告瞭事件特徵和三種可能的事件型別-一種用於溫度，一種用於煙霧，另一種用於-LightEvent在事件流中引入一些噪聲。
然後，讓我們定義最重要的部分-模式：

 val pattern = Pattern.begin[Event]("temperature").subtype(classOf[TemperatureEvent]).where(_.value >= 50.0).timesOrMore(3)
    .followedBy("smoke").subtype(classOf[SmokeEvent])

該模式以至少三個型別的事件開頭，TemperatureEvent後跟一個SmokeEvent。followedBy表示其他事件可能在兩者之間發生。
最後一部分與執行和報告檢測到的模式有關：

val env = StreamExecutionEnvironment.createLocalEnvironment()

 val patternStream = CEP.pattern(input, pattern)

  case class Alert(message: String) // just for presenting results

  val result: DataStream[Alert] = patternStream.process(
    new PatternProcessFunction[Event, Alert]() {
      override def processMatch(
                                 `match`: util.Map[String, util.List[Event]],
                                 ctx: PatternProcessFunction.Context,
                                 out: Collector[Alert]): Unit = {
        out.collect(Alert(`match`.toString)) // match map converted to string
      }
    })

  result.print()  // let’s display the results

  env.execute() // run the flow


我說這是最後一部分，但是我們已經忘記了input！假設它將是：

  
val input: DataStream[Event] = env.fromElements(
    TemperatureEvent(49.0),
    TemperatureEvent(51.0),
    LightEvent(100),
    TemperatureEvent(52.0),
    TemperatureEvent(53.0),
    LightEvent(125),
    SmokeEvent(),
    LightEvent(135)
  )

結果：

Alert({
    temperature=[TemperatureEvent(51.0), TemperatureEvent(52.0), TemperatureEvent(53.0)],
    smoke=[SmokeEvent()]
})

一切都按預期工作，並報告了警報。但是，提出的示例並不完美。可以透過在實際事件中新增時間戳以及輸入序列必須與模式匹配的最大時間間隔來改善此效果。當前程式碼不受任何時間範圍的限制。如果您想了解有關FlinkCEP的更多資訊，請檢視其文件。
 

結論
複雜的事件處理已經存在了很多年。它涉及各個領域，可以應用於許多領域。市場上的CEP工具為標準流處理增加了一層，因此可以更輕鬆地定義複雜的模式。到目前為止，大多數可用於生產環境的“複雜事件處理”工具都是開源的，並且只能在商業上使用。
Apache Flink是CEP的可靠工具。它已在批處理和流處理領域中得到了一定的採用，因此附加的CEP模組使該技術的訪問範圍更廣，從而使我們能夠發現潛在的新用例。
 

相關文章