1. 流處理系統
1.1. 時間就是金錢
-
1.1.1. 從資料中提取有價值的知識和獲得洞見的速度越快，就能越快地響應系統所觀察的世界的變化
-
1.1.2. 信用卡欺詐檢測
-
1.1.3. 網路安全中異常網路流量的捕獲
-
1.1.4. 在支援GPS的駕駛應用程式中進行的實時路線規劃
-
1.1.5. 社交媒體網站上的熱門話題識別
1.2. 需要對最近的一組觀察結果進行計算
- 1.2.1. 此類計算對時間很敏感，需要訪問最近的相關資料
1.3. 傳統上，可以透過將外部提供的資料儲存到資料庫並設計可提取所需資訊的查詢來構建此類應用程式
1.4. 需要從資料庫和索引中獲得快速、可擴充套件的寫入效能，來實現低延遲聚合讀取和最近資料點的連線
- 1.4.1. 有時“終於”是在漫長的等待之後到來的，在當今世界，遲到的結果（即使遲到幾秒鐘）與根本沒有結果一樣糟糕
1.5. 面對來自感測器、裝置和使用者的海量資料來源的數量不斷增加，我們出現了一種被稱為流處理系統的新技術
-
1.5.1. 流處理系統旨在提供在記憶體中處理資料流的能力，而無須透過持久化資料來獲得所需的結果
-
1.5.2. 動態資料或實時分析
1.6. 流處理平臺正在成為可擴充套件系統的常見部分
1.7. 流系統產生實時相關結果的能力在許多應用領域都極具吸引力
-
1.7.1. 可以實時轉換、聚合和分析傳入的資料
-
1.7.2. 應用程式可以根據時間視窗或訊息量對有限批次的資料執行分析
-
1.7.3. 使得識別資料趨勢並根據最新資料視窗中的值計算指標成為可能
1.8. 利用許多流平臺來構建可容錯、可擴充套件的應用程式
-
1.8.1. 可擴充套件性是透過將邏輯資料流應用程式架構轉換為一個叢集中與之物理等價的跨計算資源分佈和連線的處理節點來實現的
-
1.8.2. 容錯機制持久儲存處理節點的狀態並跟蹤哪些訊息已透過完整的資料流應用程式成功處理
-
1.8.2.1. 當發生故障時，可以從第一個未完成的訊息重新啟動流
2. 流處理簡介
2.1. 自從軟體系統問世以來，批處理就在處理新的可用資料方面發揮了重要作用
-
2.1.1. 批處理是大型系統的一個可靠有效的重要組成部分
-
2.1.2. 缺點是新資料從到達到可用於查詢和分析存在時間差
2.2. 在批處理系統中，代表新的和更新後的物件的原始資料會被累積到檔案中
2.3. 一個被稱為批處理資料載入任務的軟體元件會定期處理這些新的可用資料，並將其插入應用程式的資料庫中
-
2.3.1. 稱為ETL（提取、轉換、載入）流程
-
2.3.2. ETL的意思是處理包含新資料的批處理檔案，將資料聚合並轉換為適合插入儲存層的格式
2.4. 流系統可以實時處理新資料和事件
-
2.4.1. 使用支援向量機等快速統計模型預測技術來評估交易是否具有潛在欺詐性
-
2.4.2. “實時”高度依賴於應用程式，處理延遲可能從不到一秒至幾秒不等
-
2.4.3. 流系統也可以對一批批的或一個個視窗的新資料進行處理
-
2.4.3.1. 微批次
2.5. 批處理和流處理架構，以及像Lambda架構這樣的混合架構在現代可擴充套件系統中都有自己的地位
2.6. Lambda架構
-
2.6.1. 誕生於2011年左右，作為一種結合了傳統批處理和新興流處理方法的混合體
-
2.6.2. 批處理層
-
2.6.2.1. 該層定期處理大量新事件資料並更新應用程式的資料庫
-
2.6.2.2. 在Lambda剛出現時，用於可擴充套件批處理的主導技術是Apache Hadoop
-
2.6.2.3. 與任何批處理系統一樣，資料庫更新頻率大約為幾分鐘到幾小時，具體取決於批處理的頻率
-
2.6.3. 速度層
-
2.6.3.1. 該層透過處理新到達的事件以提供低延遲結果來補充批處理層
-
2.6.3.2. 定期批處理的資料正在累積時，速度層會處理相關事件，從而能快速瞭解最新的資料
-
2.6.3.3. 將速度層視為處理新資料和服務層更新造成的高延遲補償
-
2.6.3.4. Apache Storm是一種廣泛用於速度層的技術
-
2.6.4. 服務層
-
2.6.4.1. 該層是批處理層和速度層儲存結果的地方，它負責處理查詢和生成結果
-
2.6.4.2. 結果可以基於批處理層或速度層的輸出，或基於將兩者結合的計算結果
3. 流處理平臺
3.1. 資料通常是佇列或者分散式儲存系統中的檔案
3.2. 流處理節點從資料來源中提取資料物件並執行轉換、聚合和特定於應用的業務邏輯
-
3.2.1. 節點被組織為有向無環圖(DAG)
-
3.2.2. 來自資料來源的資料物件作為流來處理
-
3.2.3. 資料流是單個資料物件的無限序列
3.3. 在概念上，資料物件是在處理節點之間傳遞或流動的，因此流應用程式也被稱為資料流系統
3.4. 流處理系統為處理節點提供了將一個節點處的輸入流轉換為由一個或多個下游節點處理的新流的能力
3.5. 流處理應用程式有兩種常見的風格
-
3.5.1. 簡單地處理和轉換流中的單個事件，不需要每個事件的任何上下文或狀態
-
3.5.2. 有些流應用程式需要維護在處理流中各個資料物件的過程中持續存在的狀態
-
3.5.2.1. 有狀態流應用程式
3.6. 流處理平臺需要能夠使應用程式擴充套件處理能力以及具備故障快速恢復的能力
- 3.6.1. 通常透過跨計算資源叢集執行多個處理節點例項，並實現狀態檢查點機制以支援故障恢復來實現
3.7. Apache Storm是一個功能強大且可擴充套件的流處理平臺
4. Apache Flink
4.1. 誕生於2014年，基於European Union Stratosphere專案中的原始研究
4.2. Flink的核心是一個分散式流處理系統，專為高吞吐量和低延遲而設計
-
4.2.1. Flink提供了一組操作，用於過濾、聚合、對映和連線來自資料來源的資料流
-
4.2.2. 與明確定義的Apache Storm拓撲不同，Flink程式被編譯並自動轉換為可以部署在叢集計算環境中的資料流程式
4.3. Flink還支援兩種基於關係概念的API，即Table和SQL API
4.4. Data Stream API
-
4.4.1. Flink DataStream API為Java和Scala系統提供流處理功能
-
4.4.2. 可以利用豐富的流處理操作來拆分、過濾、聚合和轉換事件流，並使用有界時間視窗建立週期性的批處理流事件
-
4.4.3. 在Flink中，資料流是型別化事件流的邏輯表示，即Java中的DataStream＜T＞
-
4.4.4. Flink支援包括檔案在內的多種本地資料來源，並具有用於各種外部技術的聯結器
-
4.4.5. 視窗操作定義了有限的事件集合的邊界並對這組事件執行操作
4.5. 可擴充套件性
-
4.5.1. Flink程式會被轉換成一個邏輯DAG（有向無環圖）
-
4.5.2. 資料流透過程式碼中定義的轉換從源移動到接收器
-
4.5.3. 可以使用執行環境物件為程式中的所有運算元、資料來源和資料接收器指定預設的並行度級別
-
4.5.4. 常見的策略是分配與每個工作管理員節點上可用CPU核心相同數量的插槽
-
4.5.5. Flink實現了一個複雜的轉換演算法，將邏輯DAG對映到可用的物理資源
-
4.5.5.1. 包括了運算元鏈的最佳化，將運算元並置在單個任務槽中，最大限度地減少資料通訊成本
4.6. 資料安全
-
4.6.1. 故障處理是任何流處理系統都需要考慮的問題
-
4.6.2. 如果部署的一部分流應用程式由於某個節點崩潰、網路故障或應用程式異常而發生故障，儲存在記憶體中的任何狀態都會丟失
-
4.6.3. 兩種支援資料安全的機制
-
4.6.3.1. 持久化狀態儲存和定期為完整流呼叫檢查點
-
4.6.4. 需要配置有狀態的運算元以定期將其狀態儲存為鍵值對
-
4.6.4.1. 所有運算元的快照都是基於對來自流源的完全相同的輸入事件的處理
-
4.6.5. 持久儲存使得在流處理失敗的情況下可以從快照恢復狀態
-
4.6.6. Flink使用流屏障(stream barrier)確保快照是一致的
-
4.6.6.1. 一旦屏障在所有輸入上傳遞到流接收器，檢查點就被標記為完成
-
4.6.6.2. 檢查點可以有效提高Flink應用程式的容錯能力
-
4.6.7. Flink透過配置各種引數來控制何時觸發檢查點
-
4.6.7.1. 一個經常使用的引數是檢查點之間的最短時間間隔