Flink之流處理基礎
目錄
Chapter 1. Introduction to Stateful Stream Processing
Traditional Data Infrastructures
企業的應用，如enterprise resource planning (ERP) systems, customer relationship management (CRM) software, or web-based applications等都會對DBMS進行操作，有時操作還會公用一個庫甚至一個表。為減少應用間的耦合性，最近提出微服務概念。微服務之間通過標準介面，如RESTful HTTP進行連線。在這種情況下，微服務就可以使用自己的技術棧。
各個應用與事務資料庫系統互動，這個系統的資料不能直接用於分析（格式、業務單一等問題）。想要對資料進行分析，需要對事務資料庫的資料進行extract-transform-load (ETL)，即複製、轉換資料到資料倉庫。
資料查詢通常分為週期報告和熱點查詢。
Apache Hadoop的出現使得資料倉庫的使用（儲存、分析）成為可能。
Stateful Stream Processing
幾乎所有的資料都是通過連續的事件流來建立的。 Stateful stream processing就是一個用來處理無界事件流的、較為通用的應用設計模式。任何處理事件流（不是簡單的記錄資料）的應用都需要是stateful的，即有能力儲存和訪問中間資料。這些狀態state可儲存在各種地方，如program variables, local files, or embedded or external databases。Flink把state儲存到記憶體或繫結的資料庫（不包括遠端資料庫），並週期性地將state的一致性checkpoint寫到remote and durable storage。（state, state 一致性, and Flink’s checkpointing 機制後面介紹）
Stateful stream processing applications 通常處理事件日誌，日誌是append-only的，所以順序是不變的。Flink能夠保持日誌的這一特點，即便是遇到掛機、升級和測試。
Stateful stream processing可以解決很多案例，其中常見的三類如下：
Event-driven Applications：接收事件流並對其執行業務邏輯，根據處理結果做出反應。場景：實時推薦、complex event processing (CEP如反作弊）、異常檢測
Data Pipelines and Real-time ETL
Streaming Analytics：Flink可以把過去的資料分析步驟穿起來，包括 event ingestion, continuous computation including state maintenance, and updating the result.
The Evolution of Open Source Stream Processing
第一代分散式開源流處理器focused在millisecond latencies and provided guarantees that events would never be lost in case of a failure，但降低了結果的準確性、且處理一條資料多於一次。
第二代提高了準確性（結果仍取決於計時、事件到達時間）和資料只處理一次，但延遲提高到了秒級。
第三代解決了high throughput和low latency，made the lambda architecture obsolete。
Chapter 2. Stream Processing Fundamentals
Introduction to dataflow programming
Dataflow graphs
Dataflow programs：類似Spark的DAG，節點稱為operators並表示計算，而邊表示資料依賴。沒有輸入埠的operators稱為sources，沒有輸出埠的operators稱為sinks。
physical dataflow graph：包含計算的細節。在這裡operators變為tasks
Data parallelism and task parallelism
前者 partition input data and have tasks of the same operation execute on the data subsets in parallel
後者 have tasks from different operators performing computations on the same or different data in parallel.
Data exchange strategies
定義資料在physical dataflow graph中的分配方式。
- forward：兩個任務的資料在同一機器上，不跨節點
- broadcast：如果下一級有n個並行任務，那麼一個節點的所有資料都被複制n份，分別發到n個節點上。
- key-based：類似於groupbyKey，相同key到相同的任務
- random：為了平均分佈資料到n個並行任務
Processing infinite streams in parallel
定義：A data stream is a potentially unbounded sequence of events
events可以是監測資料、感測器的測量、信用卡交易等。
Latency and throughput
Latency：不是平均延遲，而是每次都要低延遲。Throughput：處理速度。兩者必須做取捨，除非增加機器來提高並行處理。
背壓backpressure ：資料湧入的速度大於處理速度，並擠爆了緩衝區，資料就會丟失。
Operations on data streams
計算可分為無狀態和有狀態。前者不保留歷史，計算更快，失敗也可重算。有狀態則可以用於更新。
Data ingestion and data egress，即source和sink
Transformation operations：相當於map操作
Rolling aggregation
Window：為了得到計算結果，必須收集並存儲資料時用（在儲存期間可用於查詢）。視窗運算不斷產生有限資料集buckets。事件會被根據其特徵或到達時間分配到buckets。所以這種運算要定義buckets什麼時候被使用（觸發條件），事件分配規則和產生buckets的頻率。
Tumbling：不重疊的固定大小（數量或者時間）
Sliding：重疊固定大小
Session：設定不活躍時間長度，timeout就算session視窗結束
這些視窗也可以並行，比如一個視窗針對同一id的資訊
Time semantics
Processing time：服務端處理資料的時點，適合低延遲要求高的，準確度稍低的，因為不需要理會延遲和資料產生順序，資料一旦到達或達到觸發數量就可以進行計算。但這樣的結果是不一致的（不同順序、資料），不可reproduce的。
Event time：客戶端產生資料的時點，適合場景反之，即便亂序也能保持唯一正確。
Watermarks：設定多久不再接受延遲的資訊，這是低延遲和準確性的權衡。stream processing system提供超出watermarks範圍的資料的處理方式很重要，比如忽略、記錄或者用它來更新資料。
State and consistency models
由於流資料是無界的，所以要限定state的大小，比如聚合成一些指標或保留部分特徵等。state的實現要防止併發更新、劃分資料流和保證資料的準確。
Task failures：一個任務的順序：接收事件（存入buffer）、可能要更新state、產生結果。任務失敗可以是這裡的任何一個步驟。
假設：這裡假設網路不會丟失和重複資料。未失敗的任務都遵循上述步驟。
Result guarantees
AT-MOST-ONCE：do nothing，資料丟失，適合準確度要求不高的。
AT-LEAST-ONCE：保證沒有資料丟失，即便對資料進行重複處理（即也不一定準確）。
EXACTLY-ONCE：沒有資料丟失、資料只處理一次。即如果任務失敗，在重啟計算時會知道上一次更新是否已經反映在state上。
END-TO-END EXACTLY-ONCE：包括source和sink的整個pipeline
不一定所有情況都需要最高級別的保證，如計算最值就可以採用AT-LEAST-ONCE
參考：
Stream Processing with Apache Flink by Vasiliki Kalavri; Fabian Hueske