1.3 實時分析——神話與現實

實時分析的最大真相是實際上沒有什么東西是真正實時的，這僅僅是一個神話。實際上，只能說它接近于實時。通過分析可以得到這樣的結論：只有提高解決方案的性能和減少操作延時，分析才能接近于實時。由于實際中計算、操作和網絡的延遲，實際上不可能消除實時和近實時之間的差距。

在進一步討論之前，我們帶領讀者快速了解一下這些所謂的實時分析解決方案的高層次需求。圖1-2展現了滿足高層次需求的一個系統，該系統可以使用各種結構化和非結構化數據集處理數百萬個事務。首先，程序引擎應該超快，并能夠處理非常復雜的連接操作和多樣化的業務邏輯；其次，可以準確產生令人嘆為觀止的報告，在一瞬間恢復即席查詢（AdHoc查詢），并在沒有延遲的情況下渲染可視化的儀表面板。

以前對實時解決方案的要求是不夠的，如果把它們推廣到生產環境中，即在當今的數據生成和零停機時代，最基本的要求是，系統應該能夠以最小的代價實現自我管理或被管理，并且以容錯和自動恢復的方式來構建，以處理大多數情況（即便不是所有情況）。它還應該能夠提供類似于基本SQL的接口。

盡管前面對實時分析的要求聽起來有些極端可笑，但是它們都是當今大數據解決方案最正常和最基本的要求。然而，回到實時分析這個主題，既然已經簡要地談到了數據、處理和輸出方面的系統級要求，這些正在設計和已被設計的系統用于處理數以萬計的事務并動態應用復雜的數據科學和機器學習算法，以盡可能接近實時地計算結果。圖1-3描述了計算時間、上下文的概念以及最終見解的重要意義。

如圖1-3所示，在有限時間背景下，存在以下問題。

●對澤字節（ZB）數據的即席查詢占用了小時級的時間，因此這通常被稱為批處理。圖1-3中圓的大小比喻的是以圖形式處理的數據的大小。

●廣告展示次數/標簽廣告趨勢/確定性工作流程/推文：這些大多被稱為在線時間和計算時間的用例通常為500ms/1s。雖然與以前的用例相比，計算時間大大減少了，但是處理的數據量也顯著減少了。它可以非常迅速處理幾吉字節大小（GB）的數據流。

●財務跟蹤/關鍵任務應用程序：典型特點是數據量很低，數據率非常高，處理非常快，并且在幾毫秒的時間窗口中產生低延遲計算結果。

除了計算時間，批處理、實時處理以及解決方案設計之間還有一些顯著的差異，見表1-2。

在本節，我們想強調的是近實時（NRT）解決方案是接近真正實時的，因為它實際上是可能實現的。所以，如上所述，RT實際上是一個神話（或假設），而NRT是一個現實。每天處理和查看的NRT應用程序，包括車聯網、預測和推薦引擎、醫療保健和可穿戴設備。

有一些關鍵的環節實際上會引入延遲到總周轉時間，或者稱之為TAT。實際上，事件發生與產生可行的措施之間的時間間隔是由它產生的。

數據/事件通常通過有線（互聯網/電信信道）從不同的地理位置傳輸到處理中心。這項活動已經過了一段時間。其處理如下。

●數據著陸：由于安全方面的原因，數據通常落在邊緣節點上，然后被提取到集群中。

●數據清理：需要滿足數據準確性方面的要求，在處理之前消除錯誤/不正確的數據。

●數據修改和豐富：使用維度數據來綁定和豐富交易數據。

●實際處理。

●存儲結果。這里，所有以前的處理過程都會產生：CPU周期、磁盤I/O、網絡I/O、數據序列化方面的主動編組和解組。

既然已經了解了實時分析的實際情況，接下來我們將更深入地了解這些解決方案的架構。