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

時間 2019-11-17

標籤 flink 學習分享二十多 paper 論文简体版

原文原文鏈接

前言

以前也分享了很多本身的文章，可是對於 Flink 來講，仍是有很多新入門的朋友，這裏給你們分享點 Flink 相關的資料（國外數據 pdf 和流處理相關的 Paper），指望能夠幫你更好的理解 Flink。git

書籍

一、《Introduction to Apache Flink book》github

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

二、《Learning Apache Flink》sql

這本書仍是講的比較多的 API 使用，不只有 Java 版本還有 Scala 版本，入門看這本我以爲仍是 OK 的。微信

三、《Stream Processing with Apache Flink》session

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

四、《Streaming System》併發

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

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