1.3 流式數據架構基本概念

1.3.1 流

流往往代表事物的無盡特征，它豐富的內涵往往會造成人們對流式數據處理是什么的誤解，以及對流式數據處理系統特征（能做什么、不能做什么）的混淆。在開始詳述流式數據處理理論之前，我們先定義流。

最初，流式數據處理是通過批處理系統實現的，如Spark Streaming，其原理是將多個微批處理任務串接起來構建流式數據處理任務。但是這種采用微批重復運行的機制，犧牲了延遲和吞吐，引發了Spark Streaming是不是真正流式數據處理引擎的爭議。為此，業界便開始構建用于處理沒有時間邊界數據（無界數據集，Unbounded Data）的實時數據系統。

因此，從這個角度可以定義流是一種為無界數據集設計的數據處理引擎，這種引擎具備以下特征：

（1）具備強一致性，即支持exactly-once語義。

（2）提供豐富的時間工具，如事件時間、處理時間、窗口。

（3）保證系統具有可彈性、伸縮性。

（4）同時保證高吞吐、低延遲與容錯。

（5）支持高層語義，如流式關系型API（SQL）、復雜事件處理（CEP，Complex Event Processing）。

此外，本書中還用流式數據處理系統、流式數據處理架構及流處理等具有相同內涵的術語指代streaming，其中流式數據處理架構用在描述系統架構的語境中。雖然“流處理”這個詞用得較為廣泛，但是本書只在和批處理對比分析的語境中使用流處理這個口語化稱呼。

1.3.2 時間

在流式數據處理理論中，經常使用事件或記錄表示從所處理的數據集中拉取的數據，在Flink中通常以有結構的對象表示事件。

在無界數據處理中，主要有兩類事件概念。

（1）事件時間（Event Time）：事件實際發生的時間。

（2）處理時間（Processing Time）：事件被處理的時間。

并不是所有應用場景都關注事件時間，但其重要性是不言而喻的。例如，在用戶行為特征分析、異常檢測、基于信貸歷史的風控模型等分析中，事件時間起到了決定性的作用。

用戶行為特征分析

用戶瀏覽網頁或App時會產生一系列頁面點擊與瀏覽時長數據，這些數據被稱為用戶行為數據。用戶行為數據可以用來判斷用戶的產品喜好，因此可以用在精準營銷、產品功能迭代等環節。

我們可以從這種點擊流數據中抽取很多行為指標，如訪問頻率、平均停留時長、消費行為、信息互動行為、內容發布行為等，從這些指標可以分析出用戶的黏性、活躍度，以及產出。

（1）黏性是衡量用戶在一段時間內持續訪問情況的指標，如訪問頻率、訪問間隔時間。

（2）活躍度指標表征用戶訪問網頁/App的頻次，如平均停留時間、平均訪問頁面數。

（3）產出指標用來衡量用戶的購買價值，如訂單數、客單價。

可以對這些指標進一步建模創造商業價值。

異常檢測

異常檢測（Anomaly Detection）是指找出與大部分對象不同的對象，這種異常對象也被稱為離群點。異常檢測的應用領域很廣，例如可用于數據預處理、病毒木馬檢測、工業制造產品檢測、網絡流量檢測。

常見的異常檢測有以下兩類方法。

（1）基于模型的方法：可以通過參數估計的方法創建數據的概率分布模型，以剔除一個不服從該分布的對象。

（2）基于距離的方法：該方法定義對象之間的距離度量，據此檢測離群點。

基于信貸歷史的風控模型

金融的核心在于控制風險，消費信貸領域也不例外。基于信貸歷史的風控模型主要用于反欺詐、判定客戶逾期風險、確定用戶授信額度。針對消費金融產品的特性，每個公司都有自己的風控模型，這些模型的核心變量是貸款用戶的信貸歷史數據，包括貸前申請與審核、貸中還款、逾期與催收情況等。除了信貸歷史數據，用戶個人的其他數據也是模型的輸入變量，如個人身份信息（學歷、年齡等）、社交信息、電商購物信息等。

在現實世界里，事件時間與處理時間往往并不一致，兩者的偏差也因數據源特性、處理引擎及硬件的差別而千差萬別，而這種變化給處理引擎的設計帶來了不小的挑戰。圖1-15描述了星球大戰系列電影的上映時間。

在這個例子中，事件時間指這是第幾部星球大戰電影，處理時間指上映時間，如《星球大戰1：幽靈的威脅》這部電影的事件時間為1，處理時間為1999年。從圖1-15中可以看出，事件時間和處理時間是不一致的。

事件時間與處理時間有所偏差的主要原因如下。

（1）受共享資源局限：如網絡阻塞時延、網絡分區（參考 CAP 定理）、共享CPU等。

（2）軟件構架：如分布式系統中的并發競爭、時鐘不一致等。

（3）數據自身特性：如key的特殊分布、吞吐量的快速漲落、亂序等。

CAP定理

CAP定理指出：一個分布式系統最多能具備一致性（Consistency）、可用性（Availability）及分區容錯性（Partition tolerance）中的兩個特性，而不可能同時具備這三個特性。

（1）一致性：在分布式系統中同一數據的所有備份，在同一時刻，其值是相同的，或者說，所有客戶端讀取的值是相同的。

（2）可用性：在集群的部分節點出現故障后，集群還能正常響應客戶端的讀寫請求。

（3）分區容錯性：分區是對分布式系統通信時限的要求，即如果不能在有限時間內達成數據一致，則系統發生分區。所謂分區容錯性，是指即便發生了分區，分布式系統仍然能正確響應客戶端的讀寫請求。

1.3.3 窗口

窗口（window）是將（有界或無界）數據集拆分成一個個有限長度數據區間的機制，即在數據集中增加臨時處理邊界，用于將事件按照時間或其他特征分組分析，其中臨時這個定語說明窗口并沒有物理地改變數據集。通常有三類窗口，以下舉例詳細說明。

（1）滾動窗口（Tumbling Window）：將時間拆分成固定長度。如圖1-16所示，圓點表示事件，屬于每個user（user 1、user 2、user 3）的事件被劃到不重疊且等時長（window size）的5個窗口（window 1、window 2、window 3、window 4、window 5）中，其中時間（time）可以是事件時間或處理時間。

（2）滑動窗口（Sliding Window）：按照滑動步長（window slide）將時間拆分成固定的長度，當滑動步長小于窗口長度時，相鄰窗口間會有重疊。如圖1-17所示，4個窗口之間有重疊區域。

（3）會話窗口（Session Window）：以活動時間間隔為邊界，將一系列連續事件拆分到不同的會話中。會話窗口的長度是動態的。圖1-18中的session gap為窗口的活動時間間隔，user 1和user 2的數據仍被劃分為4個窗口，但user 3的數據被劃到了3個窗口中。

1.3.4 水印

水印（watermark）是嵌入在事件時間軸上用于判斷事件時間窗口內所有數據均已到達引擎的一種時間推理工具，是一種既可以在流處理引擎側嵌入，又可以在消息系統側嵌入的時間戳。

水印的語義是事件時間小于水印標記時間的事件不會再出現，因此水印是事件的推進器（metric of progress）。

時空穿梭是另一個相關概念。出于調試或審計目的，數據處理程序有時需要將事件時間倒回至過去某個時間點重新開始數據處理任務。

1.3.5 觸發器

觸發器（trigger）決定在窗口的什么時間點啟動應用程序定義的數據處理任務。

水印遲到會拉長窗口生存期，水印早到會導致數據處理結果不準確，觸發器就是為解決這兩個問題而被引入的。

1.3.6 數據處理模式

1.有界數據處理

通常，我們使用批處理引擎處理有界數據集（盡管流處理引擎也具備這個功能）。在Hadoop的WordCount程序中，WordCountMapper負責遍歷數據集的每一行，切分出以空格為間隔的單詞，并輸出格式為（word，1）的中間處理數據；WordCountReducer讀入shuffle后的中間數據集，聚合輸出每個單詞的出現次數，代碼如下：

這類數據處理模式的特征是將有界數據集處理成規整的形式并輸出，可用圖1-19形象地描述。

2.無界數據批處理

在流處理引擎沒有出現之前，業界通常使用窗口機制將無界數據集分割成一系列有界數據塊，使用批處理方式分析每個數據塊，即微批處理模式，如圖1-20所示。

3.無界數據流式處理

基于微批模式的無界數據批處理的原理是，將多個微批處理任務串接起來構建流式數據處理任務，這通常是以犧牲延遲和吞吐為代價的。解決這種缺陷是流處理引擎的發展目標之一，解決方案建立在分析無界數據集的無序和事件時間偏差特性的基礎上。

（1）無序意味著引擎需要時間處理機制。

（2）事件時間偏差意味著引擎不能假定在某個時間窗口內能夠觀察到所有事件。

下面分4種情況分析無界數據的流式處理模式。

1）時間無關

流處理引擎能成功應用于需要時間機制的輸出處理任務中，也能用于解決與時間無關的數據處理任務，如過濾、數據源連接。

（1）過濾：用于過濾給定規則的事件，如從網站后臺日志中過濾出給定源地址的請求。

（2）連接：將兩個數據源中相關聯的記錄連接成一條記錄，如圖1-21所示。

2）近似計算

近似計算是另一種與時間無關的流式數據處理應用，優點是系統開銷小。由于算法過于復雜，這類流式數據處理模式應用范圍較窄。下面以Streaming k-means為例加以說明。

Streaming k-means算法的基本思想是以空間中k個點為中心進行聚類，該算法在流式數據處理應用中的擴展方式如下。

（1）初始以隨機位置作為聚類的中心點，因為此時還沒有觀察到任何數據。

（2）收到新的數據后，調用Streaming k-means算法更新中心點。

（3）以更新后的中心點為初始中心點，跳轉至步驟2。

3）根據處理時間開滾動窗口

這種窗口是根據事件被觀察的時間設計的，優點有以下3個。

● 使用起來簡單。

● 窗口邊界易于確定。

● 易于提供與事件時間無關的語義。

根據處理時間開滾動窗口的數據處理模式，如圖1-22所示。

4）根據事件時間開滾動窗口

根據事件時間開滾動窗口的數據處理模式，如圖1-23所示。

事件時間窗口提供了更靈活的機制，但與處理時間窗口相比，事件時間窗口通常需要更長的生存期，這會給引擎的架構設計帶來諸多挑戰，例如需要大容量的緩存以持久化狀態；窗口邊界難以確定，事件遲到導致確定窗口結束點較為困難。

1.3.7 如何理解流式數據架構的內在機制

可以通過以下4個問題深入理解流式數據處理的內在機制。

● what：定義數據處理是什么，即對數據進行怎樣的轉換操作，如Spark的算子。

● where：定義轉換操作的輸入數據取自什么時間區間，窗口是這個問題的答案。

● when：定義轉換操作發生在時間軸的什么時間點，水印和觸發器是這個問題的答案。

● how：定義如何刻畫同一窗口內多次轉換操作結果的關系，累加模式是這個問題的答案。

其中，轉換操作有時也用聚合代替，轉換內涵更豐富，而聚合用于在數據集（如窗口）上計算某個值的場合（如窗口內數據的求和）。