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. 一個經常使用的參數是檢查點之間的最短時間間隔