供職于LinkedIn公司流處理架構部門的Kartik Paramasivam在今年夏天撰寫了兩篇文章，解釋了LinkedIn力圖在使用Apache Samza做數(shù)據(jù)處理中避免Lambda架構的原因及具體做法。
流處理是一種非常有用的技術，解決了如何從數(shù)據(jù)流中快速獲取結果的問題。但是流處理技術并不能滿足苛求高一致性和魯棒性需求的用例的要求。
Lamda架構是一種結合了批處理和流處理的解決方案，曾被廣泛地采用。其基本理念是提供兩條獨立的數(shù)據(jù)路徑，一條是使用流處理技術的速度層，提供低延遲的結果；另一條是運行任務的批處理層，對批量數(shù)據(jù)提供精確的結果。由于依賴于多種技術，并合并了兩條數(shù)據(jù)路徑的處理結果，所以Lamda架構實現(xiàn)很復雜。
LinkedIn使用Samza處理從Apache Kafka流出的數(shù)據(jù)。在文章里描述的其中一個問題是事件的延遲到達。Samza添加了一個基于RocksDB的鍵值庫，實現(xiàn)了對輸入事件的長期保存。在事件延遲到達時，由于在本地存儲了足夠重新計算的信息，架構將重新發(fā)送所有的結果給受到影響的計算窗口。鑒于依賴于外部存儲（例如NoSQL）就隱含著通信和序列化中的網絡和CPU開銷，基于RocksDB的解決方案經證明是可取的。
另一種流處理架構Apache Flink適合于在時間窗口上基于時間戳的計算。時間戳可以是特定于事件的，或是攝入時間戳，用于對亂序的數(shù)據(jù)流給出一致的結果。Flink在內存中維護數(shù)據(jù)，并在接收到水印線（Watermark）事件時觸發(fā)窗口計算。水印線代表了一個時鐘周期，為Flink提供了時間的概念（可以是特定于事件的）。
流處理中還存在其它的一些問題，例如如何處理由多次交付保證所導致的重復消息等。對于大部分具有內部檢查點機制的架構而言，這些問題都已經得到解決。
最后一類流處理問題是以交互的方式對流經系統(tǒng)的數(shù)據(jù)進行實驗的能力。敏捷實驗在Azure Stream Analytics等商業(yè)產品中可用，通常是在批處理系統(tǒng)上使用SQL等高層語言執(zhí)行的。
Julian Hyde將Samza SQL描述為一種試圖在Samza流處理器中應用Apache Calcite的嘗試。由于Samza SQL目前依然尚未生產就緒，LinkedIn還是使用Hadoop的批處理本能在離線數(shù)據(jù)上開展迭代測試。一些離線數(shù)據(jù)是從線上服務數(shù)據(jù)庫中拷貝過來的，即基于Samza的流處理器在流處理時所查詢的同一數(shù)據(jù)庫。
Flinkn也在努力實現(xiàn)魯棒的流SQL支持。2016年8月發(fā)布的Flink 1.1版本支持了流數(shù)據(jù)上的過濾和合取操作。Flink也已支持復雜事件處理（Complex Event Processing），用做對事件序列反應方式的一種高層描述。
查看英文原文：Stream Processing and Lambda Architecture Challenges
京公網安備 11010502049343號