摘要：另外，將機制發揚光大，對有著非常好的支持。系統也注意到并討論了和的問題。總結本文分享了四本相關的書籍和一份領域相關的論文列表篇，涉及的設計，實現，故障恢復，彈性擴展等各方面。

之前也分享了不少自己的文章，但是對于 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》

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

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

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

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 內部實時處理系統的事實上的標準。

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 落幕時以此文發聲向其致敬，也算是彌補了些許遺憾吧。

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。

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

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。

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

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 的文章對比閱讀。

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 相關研究的縮影。

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

本文分享了四本 Flink 相關的書籍和一份 streaming systems 領域相關的論文列表 20+ 篇，涉及 streaming systems 的設計，實現，故障恢復，彈性擴展等各方面。

如何獲取呢？你可以加我的微信：zhisheng_tian，然后回復關鍵字：Flink 即可無條件獲取到。

更多私密資料請加入知識星球！

另外你如果感興趣的話，也可以關注我的公眾號。

本篇文章連接是：http://www.54tianzhisheng.cn/2019/06/13/flink-book-paper/

https://github.com/zhisheng17/flink-learning/

以后這個項目的所有代碼都將放在這個倉庫里，包含了自己學習 flink 的一些 demo 和博客。

1、Flink 從0到1學習 —— Apache Flink 介紹

2、Flink 從0到1學習 —— Mac 上搭建 Flink 1.6.0 環境并構建運行簡單程序入門

3、Flink 從0到1學習 —— Flink 配置文件詳解

4、Flink 從0到1學習 —— Data Source 介紹

5、Flink 從0到1學習 —— 如何自定義 Data Source ？

6、Flink 從0到1學習 —— Data Sink 介紹

7、Flink 從0到1學習 —— 如何自定義 Data Sink ？

8、Flink 從0到1學習 —— Flink Data transformation(轉換)

9、Flink 從0到1學習 —— 介紹 Flink 中的 Stream Windows

10、Flink 從0到1學習 —— Flink 中的幾種 Time 詳解

11、Flink 從0到1學習 —— Flink 讀取 Kafka 數據寫入到 ElasticSearch

12、Flink 從0到1學習 —— Flink 項目如何運行？

13、Flink 從0到1學習 —— Flink 讀取 Kafka 數據寫入到 Kafka

14、Flink 從0到1學習 —— Flink JobManager 高可用性配置

15、Flink 從0到1學習 —— Flink parallelism 和 Slot 介紹

16、Flink 從0到1學習 —— Flink 讀取 Kafka 數據批量寫入到 MySQL

17、Flink 從0到1學習 —— Flink 讀取 Kafka 數據寫入到 RabbitMQ

18、Flink 從0到1學習 —— Flink 讀取 Kafka 數據寫入到 HBase

19、Flink 從0到1學習 —— Flink 讀取 Kafka 數據寫入到 HDFS

20、Flink 從0到1學習 —— Flink 讀取 Kafka 數據寫入到 Redis

21、Flink 從0到1學習 —— Flink 讀取 Kafka 數據寫入到 Cassandra

22、Flink 從0到1學習 —— Flink 讀取 Kafka 數據寫入到 Flume

23、Flink 從0到1學習 —— Flink 讀取 Kafka 數據寫入到 InfluxDB

24、Flink 從0到1學習 —— Flink 讀取 Kafka 數據寫入到 RocketMQ

25、Flink 從0到1學習 —— 你上傳的 jar 包藏到哪里去了

26、Flink 從0到1學習 —— 你的 Flink job 日志跑到哪里去了

27、阿里巴巴開源的 Blink 實時計算框架真香

28、Flink 從0到1學習 —— Flink 中如何管理配置？

29、Flink 從0到1學習—— Flink 不可以連續 Split(分流)？

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

31、Flink 架構、原理與部署測試

32、為什么說流處理即未來？

33、OPPO 數據中臺之基石：基于 Flink SQL 構建實時數據倉庫

34、流計算框架 Flink 與 Storm 的性能對比

35、Flink狀態管理和容錯機制介紹

36、Apache Flink 結合 Kafka 構建端到端的 Exactly-Once 處理

37、360深度實踐：Flink與Storm協議級對比

38、如何基于Flink+TensorFlow打造實時智能異常檢測平臺？只看這一篇就夠了

39、Apache Flink 1.9 重大特性提前解讀

40、Flink 全網最全資源（視頻、博客、PPT、入門、實戰、源碼解析、問答等持續更新）

41、Flink 靈魂兩百問，這誰頂得住？

1、Flink 源碼解析 —— 源碼編譯運行

2、Flink 源碼解析 —— 項目結構一覽

3、Flink 源碼解析—— local 模式啟動流程

4、Flink 源碼解析 —— standalone session 模式啟動流程

5、Flink 源碼解析 —— Standalone Session Cluster 啟動流程深度分析之 Job Manager 啟動

6、Flink 源碼解析 —— Standalone Session Cluster 啟動流程深度分析之 Task Manager 啟動

7、Flink 源碼解析 —— 分析 Batch WordCount 程序的執行過程

8、Flink 源碼解析 —— 分析 Streaming WordCount 程序的執行過程

9、Flink 源碼解析 —— 如何獲取 JobGraph？

10、Flink 源碼解析 —— 如何獲取 StreamGraph？

11、Flink 源碼解析 —— Flink JobManager 有什么作用？

12、Flink 源碼解析 —— Flink TaskManager 有什么作用？

13、Flink 源碼解析 —— JobManager 處理 SubmitJob 的過程

14、Flink 源碼解析 —— TaskManager 處理 SubmitJob 的過程

15、Flink 源碼解析 —— 深度解析 Flink Checkpoint 機制

16、Flink 源碼解析 —— 深度解析 Flink 序列化機制

17、Flink 源碼解析 —— 深度解析 Flink 是如何管理好內存的？

18、Flink Metrics 源碼解析 —— Flink-metrics-core

19、Flink Metrics 源碼解析 —— Flink-metrics-datadog

20、Flink Metrics 源碼解析 —— Flink-metrics-dropwizard

21、Flink Metrics 源碼解析 —— Flink-metrics-graphite

22、Flink Metrics 源碼解析 —— Flink-metrics-influxdb

23、Flink Metrics 源碼解析 —— Flink-metrics-jmx

24、Flink Metrics 源碼解析 —— Flink-metrics-slf4j

25、Flink Metrics 源碼解析 —— Flink-metrics-statsd

26、Flink Metrics 源碼解析 —— Flink-metrics-prometheus

26、Flink Annotations 源碼解析

27、Flink 源碼解析 —— 如何獲取 ExecutionGraph ？

28、大數據重磅炸彈——實時計算框架 Flink

29、Flink Checkpoint-輕量級分布式快照

30、Flink Clients 源碼解析原文出處：zhisheng的博客，歡迎關注我的公眾號：zhisheng