[資料科學筆記]第6章 流資料處理
流資料處理
1.流資料處理應用
有一類資料密集型應用，資料快速到達，轉瞬即逝，需要及時進行處理
這些應用來自不同的領域，包括網路監控(Network Monitoring)、電信資料管理(Telecommunication Data Management)、工業製造(Manufacturing)、感測器網路(Sensor Network)、電子商務(Electronic commerce)、量化交易(Algorithm Trading)等。
2.流式處理和批處理的區別
對於批處理來講，首先資料被不斷地採集，儲存到資料庫中(不一定是關係資料庫，可以是HBase或者Hive資料庫)，然後進行分析處理(包括SQL查詢)。批處理適用於對大量資料(High Volume)進行處理的場合。人們需要等到整個分析處理任務完成，才能獲得最終結果。
在流式資料處理模式裡，資料持續到達，系統及時處理新到達的資料，並不斷產生輸出。處理過的資料一般丟棄掉，當然也可以儲存起來。流式資料處理模式，強調資料處理的速度(Velocity)。部分原因，是因為資料產生的速度很快，需要及時進行處理。由於流式資料處理系統，能夠對新到達的資料進行及時的處理，所以它能夠給決策者提供最新的事物發展變化的趨勢，以便對突發事件進行及時響應，調整應對措施。
3.流資料模型
在流資料模型(Stream Data Model)中，將要進行處理的資料，從一個或者多個上游資料來源，持續不斷地到達，而不是從儲存在磁碟或者記憶體中的資料來源，進行隨機地存取。
流資料模型和傳統的關係模型(Relational Model)，有幾個重要的區別
(1) 資料流的資料元素持續到達。
(2) 流資料處理系統，不能控制資料元素到達的順序。
(3) 資料流有可能是無限的，或者說資料流的大小是無限大(Infinite)。
(4) 資料流的一個數據元素被處理後，可以丟棄或者歸檔(Archived)，一般不容易再次提取，除非目前該資料元素還在記憶體中。能夠儲存在記憶體中的資料元素，相對於整個資料流來講，是極少量的資料。
在流資料模型中，資料流可以看作是隻允許進行元組新增操作(Append Only)的關係表。對應關係資料庫的SQL查詢語言，在資料流上，我們可以使用經過擴充套件的SQL語言，進行資料流的查詢
4.資料流上的查詢
資料流上的查詢，和傳統資料庫上的查詢(比如關係資料庫上的SQL查詢)，有很多共同的特點，但是兩者有兩個重要的區別
(1).第一個區別，是一次性查詢(One Time Query)和持續查詢(Continuous Query)的區別:
一次性查詢One Time Query(比如關係資料庫的SQL查詢)，指的是在資料集的某個時刻的快照(Point in Time Snapshot)上執行的查詢，對資料進行分析，獲得結果後，返回給使用者。
持續查詢，則是在一系列持續到達的資料流的資料元素上執行的查詢，它產生一系列結果。這些結果是根據查詢不斷執行時，不斷看到的新資料而產生的
(2).第二個區別，是預定義查詢(Predefined Query)和即席查詢(Ad-Hoc Query)對系統的影響
預定義查詢一般是持續查詢，當然我們也可以預先定義一些一次性查詢。
即席查詢，則是在資料流的資料開始流動起來，資料不斷到達的時候，才提交給流資料處理系統的。即席查詢可以是一次性查詢，也可以是持續查詢。即席查詢使得系統的設計和實現複雜化了
流資料管理系統一般通過提供面向流資料處理的一些原語(Primitive)，擴充套件SQL語言，支援使用者通過熟悉的SQL查詢語言，操作資料流
擴充套件的原語，主要提供時間視窗(Time Windows)的定義辦法。
包括物理時間視窗(Physical Window)、和邏輯時間視窗(Logical Window)。物理時間視窗通過ROWS關鍵字指定,而邏輯時間視窗通過RANGE關鍵字指定
<hr/>
5.流資料處理系統的查詢處理
記憶體需求
大部分資料流，是無法預知其最終大小的，或者說資料流的大小(記錄數量)可能是無限的。在這種
情況下，如果要在資料流上計算一個準確的結果(比如累計數)，需要的儲存空間將無法預知，有可
能超過可用的記憶體。
在某些流資料處理應用中，新資料以極高的速率到達，以至於老資料都還沒有來得及處理。我們需
要儘量降低處理每個資料元素的時間，每個資料元素要處理得夠快，否則流資料的處理，跟不上數
據到達的速度。為了達到高速的資料處理，流資料處理系統一般優先採用基於記憶體的資料處理算
法，無需存取磁碟
近似查詢結果
在記憶體容量有限的情況下，獲得一個準確的結果，是不太可能的。正好，在很多應用場合，我們無
需一個準確的答案。近似的查詢結果，只要足夠好，可以作為準確結果的替代。
在流資料處理領域，人們為資料流上的查詢，研究了一系列資料縮減(Data Reduction)或者摘要
(Summary Construction)構建技術，具體包括資料輪廓(Sketche)、隨機取樣(Random
Sampling)、直方圖(Histogram)、小波變換(Wavelet)等。基於這些摘要(Summarization)資料
結構，實現了計算近似結果的方法，包括聚集查詢(Aggregate Query)和連線查詢(Join Query)
滑動視窗
從資料流上產生近似查詢結果的一種技術，是滑動視窗及其之上的查詢處理技術。所謂滑動視窗上
的查詢處理，指的是在資料流的最近資料元素(記錄)上執行查詢，而不是在資料流的所有歷史記錄
上執行查詢。比如，進行查詢處理的時候，僅僅存取資料流上最近一天的資料元素，一天前的資料
元素則丟棄掉。在記憶體容量有限的情況下，獲得一個準確的結果，是不太可能的。正好，在很多應
用場合，我們無需一個準確的答案。近似的查詢結果，只要足夠好，可以作為準確結果的替代。
為了實現資料流上基於滑動視窗的查詢，一般需要在查詢語言裡，增加滑動視窗的定義方法(一般
是對SQL語言進行擴充)。滑動視窗的大小是任意的，當滑動視窗過大的時候，窗口裡的資料元素
(記錄)過多，不能快取在記憶體裡，需要利用磁碟儲存部分資料，這將增加處理的延遲，研究人員在
研究利用有限的記憶體，實現近似計算的演算法
查詢資料流的歷史資料
在標準的流資料處理模式中，當某個資料元素處理結束後，將無法再訪問到。這就意味著，某些數
據已經被丟棄以後，使用者發起即席查詢(Ad-Hoc Query)，將無法獲得準確的結果。
針對這個問題，最簡單的辦法，是規定即席查詢只能參考它提交以後到達的新資料，之前的歷史數
據直接忽略掉。這種辦法簡單粗暴，但是在很多應用中，這樣的規定卻是可以接受的。
另外一個辦法，則稍微複雜一些，它允許新提交的即席查詢參考歷史資料。歷史資料不是原原本本
地儲存起來，而是儲存一個摘要(Summary)，是資料的一個梗概(Synopsis)或者聚集彙總
(Aggregate)。這些資料摘要，有助於為未來的即席查詢，計算一個近似的結果。這種辦法，需要
考慮到系統需要支援什麼型別的查詢，然後利用記憶體資源，維護一個數據摘要，最大限度地支援這
些型別的查詢
多查詢優化與查詢計劃的適應性
在流資料處理系統中，大多數的查詢是長時間執行的持續查詢。系統同時執行大量的查詢，可以通
過多查詢優化(Multi Query Optimization)技術，提高查詢處理的效能。由於系統不斷有新的即
席查詢提交上來，為一組查詢尋找最佳的執行計劃，需要線上(Online)進行優化決策。
此外，即席查詢帶來另外一個問題，就是查詢計劃的適應性(Adaptivity in Query Plan)
堵塞操作符
堵塞操作(Blocking Operator)，是這樣的操作，它需要看到所有的輸入資料以後，才能開始產
生輸出結果。排序就是堵塞操作的一個例項，此外，包括Sum、Count、Min、Max、Avg等聚集操
作，也是堵塞操作，因為只有看到所有的輸入資料，才能開始產生輸出。
讓流資料處理系統有效處理排序、聚集等操作，是一個嚴峻的挑戰。
其中的一種技術，稱為標點技術(Punctuation)。所謂標點，就是一個斷言(Assertion)，它規
定，在剩下的資料流資料中，什麼資料可以出現，什麼資料不可以出現。標點和資料元素交織在一
塊，被插入在資料流的不同位置上，幫助資料流上的操作做出決策。
資料流裡的時間戳
滑動視窗，是基於是資料流元素的時間戳(Timestamp)或者順序號(Sequence Number)屬性進行
定義的。對於來自一個數據流的資料來講，時間戳一般不存在歧義。但是在一些場合，我們必須對
時間戳給予關注，原因是：(1) 如果滑動視窗是在從多個數據流上產生的組合元組上定義的(比如
一個Join操作，連線了兩個資料流S1/S2)，如果來自兩個資料流的元素的時間戳數值不一樣，那
麼兩個元組連線產生的組合元組，應該賦予什麼時間戳，是一個問題。(2) 當若干分散式的資料
流，構成一個邏輯資料流的時候，以及在分散式的感測器網路上，比較不同資料流的資料元素的時
間戳，具有實際業務意義
批處理(Batch Processing)、取樣(Sampling)、梗概(Synopsis)
批量處理(Batch Processing)
但是實際情況往往不是這樣的。第一種情形是，update操作足夠快，但是computeAnswer操作很
慢，跟不上資料流資料到達的速率。最自然的辦法，是以批處理方式處理資料，也就是新來的數
據元素先快取起來，在資源允許的情況下，定期計算查詢的結果。查詢結果不是根據最新的資料
進行計算的(最新資料快取起來，有待下一次進行成批的處理)，而是有一定的時間延遲。這種計
算方法，獲得的查詢結果是準確的，只不過它是最近的準確的結果，而不是當前的準確結果。也
就是，因為使用批量處理，犧牲了結果的及時性，但是跟上了資料流新資料到達的速率。
取樣(Sampling)
在第二種情況下，computeAnswer操作足夠快，但是update操作很慢，不足以及時處理新到達的
資料。由於資料到達實在太快，沒有必要利用所有的資料來計算查詢的結果。我們可以忽略一部
分元組，在資料流上進行取樣，在取樣上而不是整個資料流上，計算查詢的結果。
梗概(Synopsis)
我們希望有某種資料結構，既支援快速的update操作，也支援快速的computeAnswer操作，能夠
及時處理資料流新到達的資料。對於很多資料流上的查詢，根本就不存在兩者兼得的資料結構。
於是人們設計一種近似資料結構，它是資料流的一個梗概(Synopsis or Sketch)。梗概是一個
比較小的資料結構，它能夠把每個元素的處理代價保持到最低水平，從而使得流資料處理系統，
能夠趕上資料到達的速度。梗概技術的細節，請參考下一節內容。
6.查詢處理的基礎演算法
隨機取樣
資料上的隨機取樣，可以看作是一種摘要式的資料結構(Summary Structure)，它包含了整個數
據集的基本特徵。在隨機取樣上，我們還可以建立各種梗概(Synopsis)。
人們研發了各種取樣方法，其中分層取樣(Stratified Sampling)方法，首先按照對觀察指標影
響較大的某種特徵，將總體分為若干個類別，再從每一類別內隨機抽取一定數量的樣本，合起來組成一個樣本。
蓄水池取樣(Reservoir Sampling)方法，只需要對資料進行一遍掃描，特別適合於資料流的取樣。
蓄水池取樣的基本原理是，首先建立一個數組，將資料流裡的前k個數，儲存在陣列中，即所謂
的"蓄水池"。對於第n個數據元素(元組)An，以k/n的概率取An並以1/k的概率隨機替換“蓄水池”
中的某個元素，如果沒有發生替換，則“蓄水池”陣列元素不變，依此類推處理新到達的其它各個
元素。該演算法可以保證取到資料的隨機性
梗概技術
梗概(Sketch)技術，是在資料流上，使用少量的記憶體，建立一個摘要結構。這個摘要結構，可以
用於特定查詢的近似結果的估計。梗概技術，能夠解決資料流上的很多問題。比如估計資料集的二
階矩的大小、估計資料集自連線(Self Join)的大小、獲得資料集中熱門元素的列表等
直方圖(Histogram)
直方圖是一種摘要資料結構，人們使用直方圖，來捕抓資料集裡的一個欄位或者一組欄位的取值的
分佈情況。在資料庫裡，直方圖一般用來進行查詢結果集大小估計(Query Size Estimation)、
給出近似的查詢結果(Approximate Query Answering)、以及用於資料探勘(Data Mining)
布隆過濾器
Bloom Filter 是一種簡單、高效的資料結構，用來判斷一個元素是否屬於一個集合。對其操作包
括初始化、元素插入和元素查詢過程。Bloom Filter由一個長度為m的bit陣列和k個Hash函式構
成。M和k兩個引數，可以根據我們可以接受的假陽性(False Positive)比率來進行調整。
計數最小梗概
計數最小梗概(Count-Min Sketch)，使用一個次線性空間(Sub-Linear Space)，來計算頻率。
它包含d行w列的一個矩陣，w和d的選擇，體現了準確性和時間/空間開銷的折中(Trade Off)。每
一行有一個Hash函式，當一個元素到達，它被針對每行進行Hash操作，即使用每行對應的Hash函
數，對元素資料進行對映，得到每行的一個下標，於是對應這些下標的列的元素儲存的計數器
(Counter)，增加1，如圖所示。可以看出，Count-Min Sketch和Bloom Filter有一些相似度之
處
7.流資料處理系統
Storm
Storm是一個分散式的、高度容錯的實時資料(流資料)處理的開源系統。Storm是為流資料處理設
計的，具有很高的處理效能。一個小叢集，每秒鐘可以處理數以百萬計的訊息。Storm保證每個消
息至少能夠得到一次完整的處理。任務失敗時，它會負責從訊息源重試訊息，從而支援可靠的訊息
處理。Storm 由Twitter開發並且開源，它使用 Clojure語言實現。
使用者可以使用多種語言，為Storm編寫應用程式，包括Clojure、Java、Ruby和Python等，還可以
通過實現Storm通訊協議，提供其它語言的支援。
Storm叢集由一個主節點和多個工作節點組成。主節點執行一個 “Nimbus”守護程序，它的工作是分配程式碼、佈置任務以及故障檢測。每個工作節點執行一個“Supervisor”守護程序，用於監聽、開始並終止工作(Worker)程序。
(1) 資料流(Stream)
資料流是Storm的一個關鍵的概念。
(2) 計算拓撲(Topology)
在Storm裡，一個實時計算應用程式的處理邏輯，封裝成一個Topology物件，稱為計算拓撲。
(3) 訊息源(Spout)
在Storm裡，訊息源稱為Spout，是訊息的生產者。
(4) 訊息處理者(Bolt)
所有的訊息處理邏輯，被封裝在訊息處理者(Bolt)裡面。
(5) Spout和Bolt之間的資料分發策略(Stream Grouping)
Spout和Bolt之間的資料分發策略，稱為Stream Grouping。
(6) 工作程序(Worker)
Supervisor監聽分配給它那臺機器的工作，根據需要啟動/關閉工作程序，這些工作程序稱為
Worker。
(7) 任務(Task)和執行器(Executor)
Topology的每個Spout或者Bolt，當作若干個任務(Task)在整個叢集裡面執行。一個程序包含若
幹線程。預設情況下，每一個Task對應到一個執行緒，稱為Executor，這個執行緒用來執行這個
Task。同一個Spout/Bolt的Task可能會共享一個物理執行緒。
Apex
Apache Apex是一個建立在Hadoop平臺上的流資料處理系統，廣泛用於資料匯入(Ingestion)、ETL、實時分析(Real-Time Analytics)等應用場合。Apex使用Hadoop HDFS檔案系統作為儲存層，並且依賴於Hadoop平臺的YARN資源管理器，實現資源分配和應用執行。Apex保證日誌資料不會丟失，每個事件都得到處理。它利用基於記憶體的資料處理，獲得極高的效能。Apex的擴充套件性好，容錯性高，成為Storm及其後繼者Heron的有力競爭者。
Spark Streaming
Spark大資料平臺本質是一個批處理平臺。在Spark平臺上，Spark Streaming通過一系列小批量資料(Mini Batch)的及時處理，實現資料流處理。它把資料流快取並且分割成一系列的小批量資料，每個Mini Batch一次進行處理。由此可見，Spark Streaming並不是真正的流資料處理系統，它使用批處理系統，來模擬實現了流資料處理模式
Flink
Apache Flink是一個開源的分散式流資料處理系統，它具有極高的效能、高度的容錯性和擴充套件能力。Flink被Alibaba用於優化電子商務網站的搜尋結果(使用者對商品的搜尋)，他們對商品的一些細節屬性和庫存資訊，進行實時更新，提高查詢結果的相關性。此外，Flink還被應用到網路/感測器監控及錯誤檢測、ETL等應用場合(https://flink.apache.org/usecases.html)。
Onyx
Onyx是一個無中心的、容錯的分散式計算系統，它支援批處理和流資料處理兩種資料處理模式。Onyx應用於實時事件流處理、持續計算、ETL等應用場合。Onyx使用Clojure語言寫成，開發人員可以使用Clojure或Java語言編寫程式。
Samza
Apache Samza是一個開源的分散式流資料處理框架。它使用Apache Kafka作為訊息佇列，暫時儲存不斷到達的資料，保證資料不丟失。同時它利用Hadoop YARN資源管理和應用程式排程框架，獲得高度的容錯性和擴充套件能力。