學習筆記 | 解析 Spark 數據處理與分析場景

數據處理場景

在這裏插入圖片描述

按照大數據的作業類型

在數據工程與數據科學中,很大一部分數據處理任務都可以被稱爲批處理(Batch Processing),所謂批處理,就是對數據進行批量處理,一次性對一定量的數據進行處理,根據數據量的大小,批處理從開始到結束的時間從數十秒到數小時都有可能,當然如果時間花費太長,還是會考慮優化、切分等,因爲這樣作業執行失敗的成本太高了。

  • 批處理任務的輸入和輸出通常都是一批數據,在數據工程中常見的ETL場景中,經常會從數據庫中抽取一部分數據進行去重後寫入到存儲系統,另外機器學習中訓練模型都是典型的批處理。對於批處理來說,最大的缺點是數據處理任務延遲較長,無法與在線系統進行實時對接,但對於每條數據來說,消耗的計算成本是最低的。

而與批處理相對應的是流處理(Streaming Processing),與靜止在某個系統中的批量數據不同,流處理在處理數據時數據是動態的,源源不斷的,而且數據蘊含的價值會隨着時間的流逝降低,所以需要對數據流進行實時處理。

  • 流處理在數據工程領域運用比較廣泛,一般都與在線系統對接,比如實時數據分析、業務系統的消息流轉等。但在數據科學中,幾乎沒有流處理的場景,除了個別如在線訓練這種比較特殊的應用。由於流處理可以認爲是數據一到來就進行處理,所以對於每條數據來說,雖然延遲很低,但消耗計算成本是最高的。

這裏舉一個批處理與流處理結合的場景,比如模型分析師用機器學習算法對一批數據進行訓練,得到一個模型,測試完畢後,數據工程師會將這個模型部署到線上環境對數據流進行實時預測。這也是數據科學與數據工程相結合的一個場景。

按照需求確定性

對於數據工程師與數據科學家來說,想要了解新的數據集最好的方式就是按照自己的習慣對數據進行一些查詢處理,雖然這些查詢處理的目的與方式都不同,比如數據科學家可能關注的是某一列的分佈,從而發現一些有趣的東西,而數據工程師則關心的是某一列的異常值,進而修改自己的處理邏輯。但是這類查詢處理都有一個共同點就是不確定,有可能根據數據集的不同而不同,也有可能根據用戶的不同而不同,甚至下一個查詢是基於上一個查詢的結果,這類查詢我們稱之爲數據探索

  • 數據探索的第一個特點是不確定,而第二個特點是時間不能太長,如果太長的話,就會嚴重影響數據探索的效率也達不到探索的效果了。

與需求不確定的數據探索相對應的就是需求確定的數據處理任務,這類任務一般都會定時、定期運行,是公司、組織以及流程中的一部分,比如數據預處理、按照分析需求生成報表等等,通常再開發這類數據處理任務之前,會進行數據探索。

按照結果響應時間

在這個維度下,按照結果響應時間分類,可以分爲兩類:

  • 可以在線響應;
  • 不能在線響應。

第 1 類通常指的是基於數據庫操作或者是基於支持某種查詢語言的工具(例如SQL)進行操作,並且實時返回結果,主要有兩類:OLTP和OLAP

  • OLTP(Online Transaction Processing)通常指的是業務系統中常見的事務處理,對應數據庫的增刪改查操作。
  • OLAP(Online Analytic Processing)主要指的是在線分析處理,對應數據庫的查詢操作,但不僅限於數據庫,主要幫助分析人員可以迅速地、一致地、可交互地查詢數據,也被稱作交互式查詢

OLAP 與 OLTP 代表對數據處理兩種截然不同的方式,但它們有個共同點,就是在線,這裏在線意味着查詢返回的結果不能太長,並且一般要能夠支持在線應用,所以可以統稱爲在線處理。通常來說事務處理與分析處理分別代表了寫優化與讀優化兩種方向,很難完全共存。

目前業界提出了一個新的場景和解決方案 HTAP(Hybrid Transaction and Analytical Process,混合事務與分析處理)系統,例如 TiDB 和阿里雲的 AnalyticDB,既可以進行事務處理也可以進行分析處理,這裏不展開介紹。

對於不能在線響應的場景,也就是第2類,這裏籠統的稱爲離線計算或者離線處理,這裏注意離線處理與在線處理界限並不是絕對的,對於同一個場景,如果全方位的進行優化,例如提升大幅度提升計算能力或者對數據進行預處理等,那麼可以讓原有的離線處理場景變爲在線處理場景。

前面說到,這種分類方法存在一些概念的交叉與重合,很容易想到的,例如在數據探索中,會非常頻繁地進行 OLAP,那麼這類操作,我們一般稱爲即席(ad-hoc 查詢)查詢。在數據探索中,通常也可以忍受進行 1 分鐘(或者更多)時間的批處理;數據處理任務中有可能有批處理,也有可能有流處理。

在上面的圖中,除了 Spark 一般不會用於在線處理部分(OLTP、OLAP與HTAP)之外,在其他所有場景下,都能夠很好的滿足企業與用戶的需求,但值得一提的是 Spark 與 OLAP 並不是完全沒有關係,這裏舉一個例子:

在歷史訂單數據庫中,保存了極其巨量的數據(從過去到現在的所有訂單),而用戶只關心歷史某個品類的月度銷量數據,但是由於原始數據過於巨大,所以導致普通的查詢及其緩慢,在這裏,可以用 Spark 將數據從數據庫抽取出來並按照時間與品類維度進行轉換和彙總(批處理),處理後的數據的大小與原始數據相比可能是上萬倍的差距,用戶就能很容易地進行在線分析了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章