Spark The Definitive Guide(Spark權威指南) 中文版。本書詳細介紹了Spark2.x版本的各個子產品，目前市面上最好的Spark2.x學習書籍！！！
掃碼關注公衆号:登峰大資料，閱讀中文Spark權威指南(完整版)，系統學習Spark大資料架構！
如果您覺得作者翻譯的内容有幫助，請分享給更多人。您的分享，是作者翻譯的動力
既然我們已經簡要概述了流處理，現在讓我們直接進入結構化流。在本章中，我們将再次說明結構化流背後的一些關鍵概念，然後将它們與一些代碼示例一起應用，這些代碼示例展示了系統的易用性。
21.1.Structured Streaming(結構化流)基礎知識
正如我們在第20章末尾所讨論的，結構化流是建構在Spark SQL引擎上的流處理架構。結構化流使用Spark中現有的結構化API (DataFrames、dataset和SQL)，而不是引入單獨的API，這意味着支援您熟悉的所有操作。使用者表達流計算的方式與在靜态資料上編寫批處理計算的方式相同。在指定這一點并指定流目的地之後，結構化流引擎将負責在新資料到達系統時以增量和連續的方式運作查詢。然後使用本書第二部分中讨論的相同Catalyst引擎執行這些計算邏輯指令，包括查詢優化、代碼生成等。除了核心的結構化處理引擎之外，結構化流還包括許多專門用于流的特性。例如，結構化流通過檢查點和write-ahead logs確定端到端、精确的一次處理以及容錯。
結構化流背後的主要思想是将資料流視為一個表，資料不斷地附加到該表中。然後，作業定期檢查新的輸入資料，對其進行處理，在需要時更新狀态存儲中的一些内部狀态，并更新其結果。該API的一個基礎是，在進行批處理或流處理時，您不應該更改查詢的代碼——您應該隻指定是以批處理方式還是流方式運作該查詢。在内部，結構化流将自動指出如何“增量化”您的查詢，即在新資料到達時有效地更新其結果，并以容錯方式運作它。
簡單地說，結構化流是“您的DataFrame，且是流式的”。這使得開始使用流處理應用程式變得非常容易。您可能已經有了它們的代碼! 然而，結構化流能夠運作的查詢類型有一些限制，還有一些您必須考慮的特定于流的新概念，如事件時間和無序資料。我們将在本章和接下來的章節中讨論這些問題。最後，通過與Spark的其餘部分內建，結構化流使使用者能夠建構我們稱為連續應用程式的應用程式。continous應用程式是一個端到端應用程式，它通過組合各種工具實時響應資料:流作業、批處理作業、流和離線資料之間的連接配接以及互動式查詢。因為現在大多數流作業都是在一個更大的連續應用程式上下文中部署的，是以Spark開發人員希望能夠更容易地在一個架構中指定整個應用程式，并在不同的部分中獲得一緻的結果。例如，您可以使用結構化流連續更新一個表，使用者可以使用Spark SQL互動式地查詢該表，為Mllib訓練的機器學習模型提供服務，或者在Spark的任何資料源中使用離線資料連接配接流。
21.2.重要概念
既然我們已經說到了進階概念，現在讓我們介紹結構化流作業中的一些重要概念。你會發現，沒有很多重要概念。這是因為結構化流被設計得很簡單。閱讀一些其他的大資料流書籍，你會注意到他們開始介紹術語，比如用于傾斜資料reducers的分布式流處理拓撲(一種誇張但準确的描述)和其他複雜的術語。Spark的目标是自動處理這些問題，并為使用者提供在流上運作任何Spark計算的簡單方法。
21.2.1.Transformations 和 Actions
結構化流使用了我們在本書中看到的相同的Transformations和Actions概念。結構化流中可用的Transformations與我們在第二部分中看到的Transformations完全相同，但有一些限制。這些限制通常涉及引擎還不能支援的某些類型的查詢，盡管一些限制已經在Spark的新版本中被取消了。在結構化流中通常隻有一個action可用于啟動流，然後流将連續運作并輸出結果。
21.2.2.Input Sources
結構化流支援以流方式讀取的多個輸入源。從Spark 2.2開始，支援的輸入源如下:
- Apache Kafka 0.10
- 分布式檔案系統上的檔案，如HDFS或S3 (Spark将不斷讀取目錄中的新檔案)
- 用于測試的socket
我們将在本章後面深入讨論這些，但值得一提的是，Spark的作者正在開發一個穩定的源API，以便您可以建構自己的流連接配接器。
21.2.3.Sinks
就像源允許您将資料放入結構化流中一樣，sink指定流的結果集的目标。接收器和執行引擎還負責可靠地跟蹤資料處理的确切進度。以下是Spark 2.2支援的輸出接收器:
- Apache Kafka 0.10
- 幾乎任何檔案格式
- 用于在輸出記錄上運作任意計算的foreach接收器
- 用于測試的控制台接收器console sink
- 用于調試的記憶體接收器 memory sink
我們将在本章後面讨論Sources時更詳細地讨論這些。
21.2.4.Output Modes
為我們的結構化流工作定義一個接收器隻是故事的一半。我們還需要定義我們希望Spark如何向該接收器寫入資料。例如，我們是否隻想添加新資訊?随着時間的推移，我們是否希望随着接收到關于行的更多資訊而更新行(例如，更新給定web頁面的點選計數)?我們是否希望每次都完全覆寫結果集(即始終為所有頁面編寫具有完整點選計數的檔案)? 為此，我們定義了一個輸出模式，類似于我們在靜态結構化api中定義輸出模式的方式。
支援的輸出模式如下:
- Append (隻向輸出接收器添加新記錄)
- Update (更新已更改的記錄)
- Complete (重寫完整輸出)
一個重要的細節是，某些查詢和某些接收器隻支援特定的輸出模式，我們将在本書的後面讨論。例如，假設您的工作隻是在流上執行map。當新記錄到達時，輸出資料将無限增長，是以使用Complete模式沒有意義，因為Complete模式要求立即将所有資料寫入一個新檔案。相反，如果您要做一個聚合到有限數量的鍵中，那麼Complete和Update模式是有意義的，但是Append沒有意義，因為有些鍵的值需要随着時間的推移而更新。
21.2.5.Triggers
輸出模式定義資料的輸出方式，觸發器定義資料何時輸出——也就是說，結構化流何時應該檢查新的輸入資料并更新其結果。預設情況下，結構化流将在處理完最後一組輸入資料後立即查找新的輸入記錄，進而為新結果提供盡可能低的延遲。然而，當接收器是一組檔案時，這種行為可能導緻許多小的輸出檔案。是以，Spark還支援基于處理時間的觸發器(隻在固定的時間間隔内查找新資料)。将來，還可能支援其他類型的觸發器。
21.2.6.Event-Time Processing事件時間處理
結構化流還支援事件時間處理(即，根據記錄中包含的時間戳處理可能出現故障的資料)。這裡有兩個關鍵的概念，你們現在需要了解;我們将在下一章更深入地讨論這兩個問題，是以如果您現在對它們還不是很清楚，也不要擔心。
21.2.6.1.Event-time data事件時間資料
事件時間是指嵌入到資料中的時間字段。這意味着，您不是根據資料到達系統的時間來處理資料，而是根據生成資料的時間來處理資料，即使由于上傳速度慢或網絡延遲導緻流應用程式中的記錄無法正常到達流應用程式。
在結構化流中，表示事件時間處理非常簡單。因為系統将輸入資料視為一個表，是以事件時間隻是該表中的另一個字段，您的應用程式可以使用标準SQL操作符進行分組、聚合和視窗操作。然而，在底層，當結構化流知道您的列之一是事件時間字段時，它可以采取一些特殊的操作，包括優化查詢執行或确定何時可以安全地忘記關于時間視窗的狀态。其中許多操作可以使用水印來控制。
21.2.6.2.Watermarks水印
水印是流處理系統的一個特性，允許您指定希望在事件發生時多晚看到資料。例如，在處理來自移動裝置的日志的應用程式中，由于上傳延遲，日志可能會延遲30分鐘。支援事件時間(包括結構化流)的系統通常允許設定水印，以限制需要記住舊資料的時間。水印還可以用于控制何時為特定的事件時間視窗輸出結果(例如，等待水印通過)。
21.3.Structured Streaming 實戰
請在公衆号中閱讀本章剩下的内容。