Flink 從0到1學習—— 分享四本 Flink 國外的書和二十多篇 Paper 論文

前言

之前也分享了不少自己的文章，但是對於 Flink 來說，還是有不少新入門的朋友，這裏給大家分享點 Flink 相關的資料（國外數據 pdf 和流處理相關的 Paper），期望可以幫你更好的理解 Flink。

書籍

1、《Introduction to Apache Flink book》

這本書比較薄，簡單介紹了 Flink，也有中文版，讀完可以對 Flink 有個大概的瞭解。

2、《Learning Apache Flink》

這本書還是講的比較多的 API 使用，不僅有 Java 版本還有 Scala 版本，入門看這本我覺得還是 OK 的。

3、《Stream Processing with Apache Flink》

這本書是 Flink PMC 寫的，質量還是很好的，對 Flink 中的概念講的很清楚，還有不少圖片幫忙理解，美中不足的是沒有 Table 和 SQL API 相關的介紹。

4、《Streaming System》

這本書是講流處理引擎的，對流處理引擎的發展帶來不少的推動，書本的質量非常高，配了大量的圖，目的就是讓你很容易的懂流處理引擎中的概念（比如時間、窗口、水印等），我強烈的推薦大家都看一下，這本書的內容被很多博客和書籍都引用了。

Paper

這是一份 streaming systems 領域相關的論文列表 20+ 篇，涉及 streaming systems 的設計，實現，故障恢復，彈性擴展等各方面。也包含自 2014 年以來 streaming system 和 batch system 的統一模型的論文。

2016 年

Drizzle: Fast and Adaptable Stream Processing at Scale (Draft): Record-at-a-time 的系統，如 Naiad, Flink，處理延遲較低、但恢復延遲較高；micro-batch 系統，如 Spark Streaming，恢復延遲低但處理延遲略高。Drizzle 則採用 group scheduling + pre-scheduling shuffles 的方式對 Spark Streaming 做了改進，保留低恢復延遲的同時，降低了處理延遲至 100ms 量級。
Realtime Data Processing at Facebook (SIGMOD): Facebook 明確自己實時的使用場景是 seconds of latency, not milliseconds，並基於自己的需求構建了 3 個實時處理組件：Puma, Swift, 以及 Stylus。Puma, Swift 和 Stylus 都從 Scribe 讀數據，並可向 Scribe 寫回數據（Scribe 是 Facebook 內部的分佈式消息系統，類似 Kafka）。

2015 年

The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing (VLDB): 來自 Google 的將 stream processing 模型和 batch processing 模型統一的嘗試。在 Dataflow model 下，底層依賴 FlumeJava 支持 batch processing，依賴 MillWheel 支持 stream processing。Dataflow model 的開源實現是 Apache Beam 項目。
Apache Flink: Stream and Batch Processing in a Single Engine Apache Flink 是一個處理 streaming data 和 batch data 的開源系統。Flink 的設計哲學是，包括實時分析 (real-time analytics)、持續數據處理 (continuous data pipelines)、歷史數據處理 (historic data processing / batch)、迭代式算法 (iterative algorithms - machine learning, graph analysis) 等的很多類數據處理應用，都能用 pipelined fault-tolerant 的 dataflows 執行模型來表達。
Lightweight asynchronous snapshots for distributed dataflows: Apache Flink 所實現的一個輕量級的、異步做狀態快照的方法。基於此，Flink 得以保證分佈式狀態的一致性，從而保證整個系統的 exactly-once 語義。具體的，Flink 會持續性的在 stream 裏插入 barrier markers，製造一個分佈式的順序關係，使得不同的節點能夠在同一批 barrier marker 上達成整個系統的一致性狀態。
Twitter Heron: Stream Processing at Scale (SIGMOD): Heron 是 Twitter 開發的用於代替 Storm 的實時處理系統，解決了 Storm 在擴展性、調試能力、性能、管理方式上的一些問題。Heron 實現了 Storm 的接口，因此對 Storm 有很好的兼容性，也成爲了 Twitter 內部實時處理系統的事實上的標準。

2014 年

Trill: A High-Performance Incremental Query Processor for Diverse Analytics (VLDB): 此篇介紹了 Microsoft 的 Trill - 一個新的分析查詢處理器。Trill 很好的結合以下 3 方面需求：(1) Query Model: Trill 是基於時間-關係 (tempo-relational) 模型，所以很好的支持從實時到離線計算的延遲需求；(2) Fabric and Language Integration: Trill 作爲一個類庫，可以很好的與高級語言、已有類庫結合；以及 (3) Performance: 無論實時還是離線，Trill 的 throughput 都很高 —— 實時計算比流處理引擎高 2-4 個數量級，離線計算與商業的列式 DBMS 同等。從實現角度講，包括 punctuation 的使用來分 batch 滿足 latency 需求，batch 內使用列式存儲、code-gen 等技術來提高 performance，都具有很好的借鑑意義 —— 尤其注意這是 2014 年發表的論文。
Summingbird: A Framework for Integrating Batch and Online MapReduce Computations (VLDB): Twitter 開發的目標是將 online Storm 計算和 batch MapReduce 計算邏輯統一描述的一套 domain-specific language。Summingbird 抽象了 sources, sinks, 以及 stores 等，基於此抽象，上層應用就不必爲 streaming 和 batch 維護兩套計算邏輯，而可以使用同一套計算邏輯，只在運行時分別編譯後跑在 streaming 的 Storm 上和 batch 的 MapReduce 上。
Storm@Twitter (SIGMOD): 這是一篇來遲的論文。Apache Storm 最初在 Backtype 及 Twitter，而後在業界範圍都有廣泛的應用，甚至曾經一度也是事實上的流處理系統標準。此篇介紹了 Storm 的設計，及在 Twitter 內部的應用情況。當然後面我們知道 Apache Storm 也暴露出一些問題，業界也出現了一些更優秀的流處理系統。Twitter 雖沒有在 2012 年 Storm 時代開啓時發聲，但在 2014 年 Storm 落幕時以此文發聲向其致敬，也算是彌補了些許遺憾吧。

2013 年

Discretized Streams: Fault-Tolerant Streaming Computation at Scale (SOSP): Spark Streaming 是基於 Spark 執行引擎、micro-batch 模式的準實時處理系統。對比 RDD 是 Spark 引擎的數據抽象，DStream (Discretized Stream) 則是 Spark Streaming 引擎的數據抽象。DStream 像 RDD 一樣，具有分佈式、可故障恢復的特點，並且能夠充分利用 Spark 引擎的推測執行，應對 straggler 的出現。
MillWheel: Fault-Tolerant Stream Processing at Internet Scale (VLDB): MillWheel 是 Google 內部研發的實時流數據處理系統，具有分佈式、低延遲、高可用、支持 exactly-once 語義的特點。不出意外，MillWheel 是 Google 強大 infra structure 和強大 engeering 能力的綜合體現 —— 利用 Bigtable/Spanner 作爲後備狀態存儲、保證 exactly-once 特性等等。另外，MillWheel 將 watermark 機制發揚光大，對 event time 有着非常好的支持。推薦對 streaming system 感興趣的朋友一定多讀幾遍此篇論文 —— 雖然此篇已經發表了幾年，但工業界開源的系統尚未完全達到 MillWheel 的水平。
Integrating Scale Out and Fault Tolerance in Stream Processing using Operator State Management (SIGMOD): 針對有狀態的算子的狀態，此篇的基本洞察是，scale out 和 fault tolerance 其實很相通，應該結合到一起考慮和實現，而不是將其割裂開來。文章提出了算子的 3 類狀態：(a) processing state, (b) buffer state, 和 (c) routing state，並提出了算子狀態的 4 個操作原語：(1) checkpoint state, (2) backup state, (3) restore state, (4) partition state。

2010 年

S4: Distributed Stream Computing Platform (ICDMW): 2010 年算是 general stream processing engine 元年 —— Yahoo! 研發併發布了 S4, Backtype 開始研發了 Storm 並將在 1 年後（由 Twitter）將其開源。S4 和 Storm 都是 general-purpose 的 stream processing engine，允許用戶通過代碼自定義計算邏輯，而不是僅僅是使用聲明式的語言或算子。

2008 年

Out-of-Order Processing: A New Architecture for HighPerformance Stream System (VLDB): 這篇文章提出了一種新的處理模型，即 out-of-order processing (OOP)，取消了以往 streaming system 裏對事件有序的假設。重要的是，這篇文章提出了並實現了 low watermark: lwm(n, S, A) is the smallest value for A that occurs after prefix Sn of stream S。我們看到，在 2 年後 Google 開始研發的 MillWheel 裏，watermark 將被發揚光大。
Fast and Highly-Available Stream Processing over Wide Area Networks (ICDE): 針對廣域網 (wide area networks) 的 stream processing 設計的快速、高可用方案。主要思想是依靠 replication。

2007 年

A Cooperative, Self-Configuring High-Availability Solution for Stream Processing (ICDE): 與 2005 年 ICDE 的文章一樣，此篇也討論 stream processing 的高可用問題。與 2005 年文章做法不同的是，此篇的 checkpointing 方法更細粒度一些，所以一個節點上的不同狀態能夠備份到不同的節點上去，因而在恢復的時候能夠並行恢復以提高速度。

2005 年

The 8 Requirements of Real-Time Stream Processing (SIGMOD): 圖領獎得主 Michael Stonebraker 老爺子與他在 StreamBase 的小夥伴們勾畫的 stream processing applications 應當滿足的 8 條規則，如 Rule 1: Keep the Data Moving, Rule 2: Query using SQL on Streams (StreamSQL), Rule 3: Handle Stream Imperfections (Delayed, Missing and Out-of-Order Data) … 等等。雖然此篇有引導輿論的嫌疑 —— 不知是先有了這流 8 條、再有了 StreamBase，還是先有了 StreamBase、再有了這流 8 條 —— 但其內容還是有相當的借鑑意義。
The Design of the Borealis Stream Processing Engine (CIDR): Borealis 是 Aurora 的分佈式、更優化版本的續作。Borealis 提出並解決了 3 個新一代系統的基礎問題：(1) dynamic revision of query results, (2) dynamic query modification, 以及 (3) flexible and highly-scalable optimization. 此篇講解了 Borealis 的設計與實現 —— p.s. 下，Aurora 及續作 Borealis 的命名還真是非常講究，是學院派的風格 :-D
High-availability algorithms for distributed stream processing (ICDE): 此篇主要聚焦在 streaming system 的高可用性，即故障恢復。文章提出了 3 種 recovery types: (a) precise, (b) gap, 和 (c) rollback，並通過 (1) passive standby, (2) upstream backup, (3) active standby 的方式進行 recover。可與 2007 年 ICDE 的文章對比閱讀。

2004 年

STREAM: The Stanford Data Stream Management System (Technique Report): 這篇 technique report 定義了一種 Continuous Query Language (CQL)，講解了 Query Plans 和 Execution，討論了一些 Performance Issues。系統也注意到並討論了 Adaptivity 和 Approximation 的問題。從這篇 technique report 可以看出，這時的流式計算，更多是傳統 RDBMS 的思路，擴展到了處理實時流式數據；這大約也是 2010 以前的 stream processing 相關研究的縮影。

2002 年

Monitoring Streams – A New Class of Data Management Applications (VLDB): 大約在 2002 年前後，從實時數據監控（如監控 sensors 數據等）應用出發，大家已經開始區分傳統的查詢主動、數據被動 (Human-Active, DBMS-Passive) 模式和新興的數據主動、查詢被動 (DBMS-Active, Human-Passive) 模式的區別 —— 此篇即是其中的典型代表。此篇提出了新式的 DBMS 的 Aurora，描述了其基本系統模型、面向流式數據的操作算子集、優化策略、及實時應用。
Exploiting Punctuation Semantics in Continuous Data Streams (TKDE): 此篇很早的注意到了一些傳統的操作算子不能用於無盡的數據流入的場景，因爲將導致無盡的狀態（考慮 outer join），或者無盡的阻塞（考慮 count 或 max）等。此篇提出，如果在 stream 里加入一些特殊的 punctuation，來標識一段一段的數據，那麼我們就可以把無限的 stream 劃分爲多個有限的數據集的集合，從而使得之前提到的算子變得可用。此篇的價值更多體現在給了 2008 年 watermark 相關的文章以基礎，乃至集大成在了 2010 年 Google MillWheel 中。