Flink流處理（一）- 狀態流處理簡介

1. Flink 簡介

Flink 是一個分佈式流處理器，提供直觀且易於使用的API，以供實現有狀態的流處理應用。它可以以fault-tolerant的方式高效地運行在大規模系統中。

流處理技術在當今地位愈發重要，由於它爲不少業務場景提供了很是優秀的解決方案，例如數據分析，ETL，事務應用等。

 

2. 有狀態的流處理

在不少場景下，數據都是以持續不斷的流事件建立。例如網站的交互、或手機傳輸的信息、服務器日誌、傳感器信息等。有狀態的流處理（stateful stream processing）是一種應用設計模式，用於處理無邊界的流事件。下面咱們簡單介紹一下有狀態流處理的機制。

對於任何處理流事件的應用來講，並不會僅僅簡單的一次處理一個記錄就完事了。在對數據進行處理或轉換時，操做應該是有狀態的。也就是說，須要有能力作到對處理記錄過程當中生成的中間數據進行存儲及訪問。當一個application 收到一個 event，在對其作處理時，它能夠從狀態信息（state）中讀取數據進行協助處理。或是將數據寫入state。在這種準則下，狀態信息（state）能夠被存儲（及訪問）在不少不一樣的地方，例如程序變量，本地文件，或是內置的（或外部的）數據庫中。

Apache Flink 存儲應用狀態信息在本地內存或是一個外部數據庫中。由於Flink 是一個分佈式系統，本地狀態信息須要被有效的保護，以防止在應用或是硬件掛掉以後，形成數據丟失。Flink對此採起的機制是：按期爲應用狀態（application state）生成一個一致（consistent）的checkpoint，並寫入到一個遠端持久性的存儲中。下面是一個有狀態的流處理Flink application的示例圖：

 

Stateful stream processing 應用的輸入通常爲：事件日誌（event log）的持續事件。Event log 存儲而且分發事件流。事件被寫入一個持久性的，僅可追加的（append-only）日誌中。也就是說，被寫入的事件的順序始終是不變的。因此事件在Publish 給多個不一樣用戶時，均是以徹底同樣的順序發佈的。在開源的event log 系統中，最著名的當屬 Kafka。

使用flink流處理程序鏈接event log的理由有多種。在這個架構下，event log 持久化輸入的 events，而且能夠以既定的順序replay這些事件。萬一應用發生了某個錯誤，Flink會經過前一個checkpoint 恢復應用的狀態，並重置在event log 中的 read position，並據此對events作replay（and fast forward），直到它抵達stream 的末端。這個技術不只被用於錯誤恢復，而且也能夠用於更新application，修復bugs，以及修復以前遺漏結果等場景中。

狀態流處理主要有三種常見的實現方式：（1） Event-driven applications；（2）Data pipeline applications；（3）Data Analytics applications

在實際場景中，大部分應用會使用以上多種結合的方式。

 

3. Event-Driven Applications

事件驅動應用（event-driven application）消費事件流，並以業務邏輯處理events。根據業務邏輯，event-driven application 能夠觸發某些action（例如發送警報或是email），亦或是向另外一事件流寫入events，並被其餘event-driven application 處理。

常見event-driven applications 使用場景包括：

1. 實時推薦（例如客戶在瀏覽賣家網站時，爲客戶推薦產品）
2. 模式識別或是復瑣事件處理（例如信用卡詐騙識別）
3. 異常檢測（例如網絡入侵檢測）

Event-driven application是微服務的演變。微服務使用 REST 調用以及外部數據存儲（例如 Key-Value store）。而事件驅動應用使用的是 event log，並使用本地狀態（local state）記錄應用數據。下面是事件驅動應用的一個示例圖：

 

 

 

從上圖咱們能夠看出，多個應用經由event log 鏈接。一個application 將輸出寫入 event log，並繼而被另外一application 消費。Event log 將發送端與接收端解耦，並提供了異步非阻塞的事件傳輸。每一個application 均可以是有狀態的，並能夠在本地管理它本身的狀態，而不須要外部數據存儲。Applications 能夠獨立地運行並擴展。

相對於微服務來講，事件驅動應用有多個優勢。相較於讀寫外部數據庫，本地狀態訪問（local state access）提供了很是好的性能。擴展以及容錯，由流處理器解決。利用event log 做爲輸入源，application的輸入被穩定存儲，並可以以既定的順序replay。再者，Flink 能夠重置application的狀態到前一個檢查點，這樣能夠實如今不丟失application 狀態的狀況下，對應用進修改或是rescale。

Event-driven 應用對流處理器的要求較高。並非全部流處理器均適用於跑event-driven applications。對此應用的要求包括：處理state的有效方式，事件時間支持等。同時，exactly-once 狀態的一致性，以及伸縮能力也一樣重要。Apache Flink 的實現符合全部這些需求，對於這類應用來講，是一個很好的選擇。

 

4. Data Pipelines

當今的IT 架構中，涵蓋了多種不一樣的數據存儲，例如關係型數據庫、nosql 數據庫、event logs、分佈式文件系統、in-memory cache 以及 search indexes 等。全部這些系統以不一樣的格式和結構存儲數據，覺得它們特定的訪問模式提供最高效的性能。在實際場景中，能夠常常看到一樣的數據被存儲在多個不一樣的系統中，以提升數據訪問的性能。例如，一個產品的信息能夠被存儲在關係型數據庫、nosql 數據庫，以及cache 和search index中。因爲數據有多個備份，因此各個位置存儲的數據必須保持同步（in-sync）。

一個傳統的實現方案是：使用按期的 ETL jobs對存儲在不一樣系統中的數據作同步。可是，此方法致使的高延遲，在當今系統中不少場景都沒法接受。另外一個方法是使用event log用於發佈數據的更新。更新操做被寫入到event log，而後被 event log 發佈出去。根據使用的場景，被傳輸的數據可能須要被標準化，亦或是與外部數據進行整合後，再寫入到目標存儲。

以低延遲的方式消費、轉換，而後插入數據，是另外一個stateful stream processing application 的應用場景。這種應用被稱爲data pipeline。Data pipeline 必須能在短期內處理大量的數據。做爲 data pipeline 的流處理器應有能力鏈接不一樣的數據源，並進行寫入。Flink 對此有較好的支持。

 

5. Streaming Analytics

ETL 任務會按期導入數據到存儲， 而後數據會被一次（或是按期的query）處理。這種批處理與架構是否基於數據倉庫，或是Hadoop 生態應用無關。按期載入數據到數據分析系統，在不少年都是業界標準用法。可是它對analytics pipeline 來講，增長了至關的延遲。

取決於每兩次操做的間隔，每次操做可能須要消耗幾個小時或是幾天，直到生成一個結果。在必定程度內，能夠經過使用data pipeline application 將數據導入到datastore，以減小延遲。然而，即便是持續的 ETL，直到event被query處理以前，也會存在delay。這個delay在過去是能夠被接受的，可是在當今場景中，數據更須要被實時收集並處理（例如，即時推薦）。

相對於等待一個按期觸發的job處理數據，streaming analytics application 能夠持續消費事件流，並以低延遲整合最新的事件，並更新輸出的結果。通常來講，streaming applications 會將它們的結果存儲在一個外部datastore，此datastore支持高效的update，例如數據庫，或是key-value 存儲。流處理程序輸出的實時更新的結果，能夠被用於Dashboard applications。以下圖：

 

 

 

除了能以更短的時間將一個event整合到最終的分析結果中，streaming analytics applications 還有另外一個優勢。傳統analytics pipeline由多個獨立的部分組成，如一個ETL 系統，一個存儲系統，大數據分析系統等。然而，stateful stream application 能夠顧及到全部這些步驟，包括事件消費，持續計算（並維護狀態信息），以及更新數據。進一步的，流處理器能夠從錯誤恢復（經過保證exactly-once state consistency），並調整應用的計算資源。Flink 這類流處理器也支持event-time處理，以產生正確、肯定的結果，並有能力在短期內處理大量的數據。

Streaming analytics applications 經常使用場景有：

1. 監控手機網絡的質量
2. 分析手機應用用戶的行爲
3. 實時數據的Ad-hoc 分析

Flink 同時也提供在流上的 SQL query。

 

6. Flink 的特色

Apache Flink能夠在大規模集羣中提供了高吞吐與低延時，相對於其餘流處理器，有如下有點：

1. Event-time 與 processing-time 語義。事件-時間語義能夠，在有無序事件的狀況下，提供一致與準確的結果。處理-時間語義能夠被用於須要低延遲的application
2. Exactly-once 狀態一致性的保障
3. 以毫秒級的延遲處理每秒百萬級的事件。Flink應用能夠被擴展運行到上千個核
4. 易於使用的API
5. 多種connectors用於鏈接不一樣數據源，如Kafka，Cassandra，Elasticsearch，JDBC，Kinesis，HDFS以及S3
6. 沒有單點故障，支持HA設置，極少有downtime。與YARN，Kuberntes等集成較好。快速從錯誤恢復，以及動態擴展的能力
7. 更新application 代碼，而後遷移到另外一Flink 集羣時，能夠不丟失application的state 信息
8. 詳細、可自定義的系統及應用指標收集
9. 也能夠用做爲batch processor

除了這些特色，Flink的API的使用較爲簡單。內置的execution mode 能夠啓動一個application，並讓整個Flink 系統運行在一個JVM 進程中，方便開發者作開發、測試與debug。

 

7. 第一個flink程序

在啓動一個 flink 集羣后，使用命令執行示例程序：

> flink run -m yarn-cluster -yn 2 /usr/lib/flink/examples/streaming/WordCount.jar --input hdfs:///user/hadoop/input --output hdfs:///user/hadoop/output

> cat output

(3123,1)

(asdf21,1)

…

 

References：

Vasiliki Kalavri, Fabian Hueske. Stream Processing With Apache Flink. 2019