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。
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