Flink流處理（一）- 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 使用場景包括：
- 實時推薦（例如客戶在瀏覽賣家網站時，為客戶推薦產品）
- 模式識別或是復雜事件處理（例如信用卡詐騙識別）
- 異常檢測（例如網絡入侵檢測）
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 常用場景有：
- 監控手機網絡的質量
- 分析手機應用用戶的行為
- 實時數據的Ad-hoc 分析
Flink 同時也提供在流上的 SQL query。
6. Flink 的特點
Apache Flink可以在大規模集群中提供了高吞吐與低延時，相對於其他流處理器，有以下有點：
- Event-time 與 processing-time 語義。事件-時間語義可以，在有無序事件的情況下，提供一致與準確的結果。處理-時間語義可以被用於需要低延遲的application
- Exactly-once 狀態一致性的保障
- 以毫秒級的延遲處理每秒百萬級的事件。Flink應用可以被擴展運行到上千個核
- 易於使用的API
- 多種connectors用於連接不同數據源，如Kafka，Cassandra，Elasticsearch，JDBC，Kinesis，HDFS以及S3
- 沒有單點故障，支持HA設置，極少有downtime。與YARN，Kuberntes等集成較好。快速從錯誤恢復，以及動態擴展的能力
- 更新application 代碼，然後遷移到另一Flink 集群時，可以不丟失application的state 信息
- 詳細、可自定義的系統及應用指標收集
- 也可以用作為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
Flink流處理（一）- Flink 簡介