無邊界數(shù)據(jù)和有邊界數(shù)據(jù)
這個世界上的數(shù)據(jù)可以抽象成為兩種，分別是無邊界數(shù)據(jù)（Unbounded Data）和有邊界數(shù)據(jù)（Bounded Data）草巡。
顧名思義，無邊界數(shù)據(jù)是一種不斷增長型酥，可以說是無限的數(shù)據(jù)集山憨。
這種類型的數(shù)據(jù)，我們無法判定它們到底什么時候會停止發(fā)送冕末。
例如萍歉，從手機(jī)或者從傳感器發(fā)送出來的信號數(shù)據(jù)，又比如我們所熟知的移動支付領(lǐng)域中的交易數(shù)據(jù)档桃。因為每時每刻都會有交易產(chǎn)生枪孩，所以我們不能判定在某一刻這類數(shù)據(jù)就會停止發(fā)送了。
在國外的一些技術(shù)文章上，有時候我們會看到“流數(shù)據(jù)（Streaming Data）”這一說法蔑舞，其實它和無邊界數(shù)據(jù)表達(dá)的是同一個概念拒担。
與此相反，有邊界數(shù)據(jù)是一種有限的數(shù)據(jù)集攻询。
這種數(shù)據(jù)更常見于已經(jīng)保存好了的數(shù)據(jù)中从撼。例如，數(shù)據(jù)庫中的數(shù)據(jù)钧栖，或者是我們常見的 CSV 格式文件中的數(shù)據(jù)低零。
當(dāng)然了，你可能會問拯杠，那我們把無邊界數(shù)據(jù)按照時間窗口提取一小份出來掏婶，那這樣的數(shù)據(jù)是什么數(shù)據(jù)呢？
拿我們之前提到過的移動支付中的交易數(shù)據(jù)來說吧潭陪。移動支付中的交易數(shù)據(jù)可以看作是無邊界數(shù)據(jù)雄妥。那我們按 2019 年 4 月 29 日這個時間窗口提取出來的數(shù)據(jù)呢？這個當(dāng)日的交易數(shù)據(jù)就變成了有邊界數(shù)據(jù)了依溯。
所以老厌，有邊界數(shù)據(jù)其實可以看作是無邊界數(shù)據(jù)的一個子集。
事件時間和處理時間
在處理大規(guī)模數(shù)據(jù)的時候黎炉，我們通常還會關(guān)心時域（Time Domain）的問題枝秤。
我們要處理的任意數(shù)據(jù)都會有兩種時域，分別是事件時間（Event Time）和處理時間（Precessing Time）拜隧。
事件時間指的是一個數(shù)據(jù)實際產(chǎn)生的時間點宿百，而處理時間指的是處理數(shù)據(jù)的系統(tǒng)架構(gòu)實際接收到這個數(shù)據(jù)的時間點。
批處理
數(shù)據(jù)的批處理洪添，可以理解為一系列相關(guān)聯(lián)的任務(wù)按順序（或并行）一個接一個地執(zhí)行。批處理的輸入是在一段時間內(nèi)已經(jīng)收集保存好的數(shù)據(jù)雀费。每次批處理所產(chǎn)生的輸出也可以作為下一次批處理的輸入干奢。
絕大部分情況下，批處理的輸入數(shù)據(jù)都是有邊界數(shù)據(jù)盏袄，同樣的忿峻，輸出結(jié)果也一樣是有邊界數(shù)據(jù)。所以在批處理中辕羽，我們所關(guān)心的更多會是數(shù)據(jù)的事件時間逛尚。
舉個例子，你在每年年初所看到的“支付寶年賬單”就是一個數(shù)據(jù)批處理的典型例子刁愿。
支付寶會將我們在過去一年中的消費數(shù)據(jù)存儲起來绰寞，并作為批處理輸入，提取出過去一年中產(chǎn)生交易的事件時間，然后經(jīng)過一系列業(yè)務(wù)邏輯處理滤钱，得到各種有趣的信息作為輸出觉壶。
在許多情況下，批處理任務(wù)會被安排件缸，并以預(yù)先定義好的時間間隔來運行铜靶，例如一天，一個月或者是一年這樣的特定時間他炊。
批處理架構(gòu)通常會被設(shè)計在以下這些應(yīng)用場景中：
- 日志分析：日志系統(tǒng)是在一定時間段（日争剿，周或年）內(nèi)收集的，而日志的數(shù)據(jù)處理分析是在不同的時間內(nèi)執(zhí)行痊末，以得出有關(guān)系統(tǒng)的一些關(guān)鍵性能指標(biāo)蚕苇。
- 數(shù)據(jù)倉庫：數(shù)據(jù)倉庫的主要目標(biāo)是根據(jù)收集好的數(shù)據(jù)事件時間，將數(shù)據(jù)信息合并為靜態(tài)快照 （static snapshot）舌胶，并將它們聚合為每周捆蜀、每月、每季度的報告等幔嫂。
- 計費應(yīng)用程序：計費應(yīng)用程序會計算出一段時間內(nèi)一項服務(wù)的使用程度辆它，并生成計費信息，例如銀行在每個月末生成的信用卡還款單履恩。
由 Google MapReduce 衍生出來的開源項目 Apache Hadoop 或者是 Apache Spark 等開源架構(gòu)都是支持這種大數(shù)據(jù)批處理架構(gòu)的锰茉。
由于完成批處理任務(wù)具有高延遲性，一般可以需要花費幾小時切心，幾天甚至是幾周的時間飒筑。要是在開發(fā)業(yè)務(wù)中有快速響應(yīng)用戶的時間需求，我們則需要考慮使用流處理 / 實時處理來處理大數(shù)據(jù)绽昏。
流處理
數(shù)據(jù)的流處理可以理解為系統(tǒng)需要接收并處理一系列連續(xù)不斷變化的數(shù)據(jù)协屡。例如，旅行預(yù)訂系統(tǒng)全谤，處理社交媒體更新信息的有關(guān)系統(tǒng)等等肤晓。
流處理的輸入數(shù)據(jù)基本上都是無邊界數(shù)據(jù).
流處理的特點應(yīng)該是要足夠快、低延時认然，以便能夠處理來自各種數(shù)據(jù)源的大規(guī)模數(shù)據(jù)补憾。流處理所需的響應(yīng)時間更應(yīng)該以毫秒（或微秒）來進(jìn)行計算。像我們平時用到的搜索引擎卷员，系統(tǒng)必須在用戶輸入關(guān)鍵字后以毫秒級的延時返回搜索結(jié)果給用戶盈匾。
流處理速度如此之快的根本原因是因為它在數(shù)據(jù)到達(dá)磁盤之前就對其進(jìn)行了分析。
當(dāng)流處理架構(gòu)擁有在一定時間間隔（毫秒）內(nèi)產(chǎn)生邏輯上正確的結(jié)果時毕骡，這種架構(gòu)可以被定義為實時處理（Real-time Processing）削饵。
而如果一個系統(tǒng)架構(gòu)可以接受以分鐘為單位的數(shù)據(jù)處理時間延時岩瘦，我們也可以把它定義為準(zhǔn)實時處理（Near real-time Processing）。
還記得我們在介紹批處理架構(gòu)中所說到的不足嗎葵孤？沒錯担钮，是高延遲。而流處理架構(gòu)則恰恰擁有高吞度量和低延遲等特點尤仍。
在如今的開源架構(gòu)生態(tài)圈中箫津，如 Apache Kafka、Apache Flink宰啦、Apache Storm苏遥、Apache Samza 等，都是流行的流處理架構(gòu)平臺赡模。
批處理模式在不需要實時分析結(jié)果的情況下是一種很好的選擇田炭。尤其當(dāng)業(yè)務(wù)邏輯需要處理大量的數(shù)據(jù)以挖掘更為深層次數(shù)據(jù)信息的時候。
而在應(yīng)用需求需要對數(shù)據(jù)進(jìn)行實時分析處理時漓柑，或者說當(dāng)有些數(shù)據(jù)是永無止境的事件流時（例如傳感器發(fā)送回來的數(shù)據(jù)時）教硫，我們就可以選擇用流處理模式。
最簡單的說辆布，基本的區(qū)別在于每一條新數(shù)據(jù)在到達(dá)時是被處理的瞬矩，還是作為一組新數(shù)據(jù)的一部分稍后處理。這種區(qū)分將處理分為兩類：批處理和流處理锋玲。
批量處理
在批處理中景用，新到達(dá)的數(shù)據(jù)元素被收集到一個組中。整個組在未來的時間進(jìn)行處理（作為批處理惭蹂，因此稱為“批處理”）伞插。確切地說，何時處理每個組可以用多種方式來確定 - 例如盾碗，它可以基于預(yù)定的時間間隔（例如媚污，每五分鐘，處理任何新的數(shù)據(jù)已被收集）或在某些觸發(fā)的條件下（例如廷雅，處理只要它包含五個數(shù)據(jù)元素或一旦它擁有超過1MB的數(shù)據(jù)）杠步。
基于時間的批處理間歇過程
通過類比的方式，批處理就像你的朋友（你當(dāng)然知道這樣的人）從干衣機(jī)中取出一大堆衣物榜轿，并簡單地把所有東西都扔進(jìn)一個抽屜里，只有當(dāng)它很難找到東西時才分類和組織它朵锣。這個人避免每次洗衣時都要進(jìn)行分揀工作谬盐，但是他們需要花費大量時間在抽屜里搜索抽屜，并最終需要花費大量時間分離衣服诚些，匹配襪子等飞傀。當(dāng)它變得很難找到東西的時候皇型。
歷史上，絕大多數(shù)數(shù)據(jù)處理技術(shù)都是為批處理而設(shè)計的砸烦。傳統(tǒng)的數(shù)據(jù)倉庫和Hadoop是專注于批處理的系統(tǒng)的兩個常見示例弃鸦。
術(shù)語“microbatch”經(jīng)常用于描述批次小和/或以小間隔處理的情況。即使處理可能每隔幾分鐘發(fā)生一次幢痘，數(shù)據(jù)仍然一次處理一批唬格。Spark Streaming是設(shè)計用于支持微批處理的系統(tǒng)的一個例子。
流處理
在流處理中颜说，每一條新數(shù)據(jù)都會在到達(dá)時進(jìn)行處理购岗。與批處理不同，在下一批處理間隔之前不會等待门粪，數(shù)據(jù)將作為單獨的碎片進(jìn)行處理喊积，而不是一次處理批量。
盡管每個新的數(shù)據(jù)都是單獨處理的玄妈，但許多流處理系統(tǒng)也支持“窗口”操作乾吻，這些操作允許處理也引用在當(dāng)前數(shù)據(jù)到達(dá)之前和/或之后在指定時間間隔內(nèi)到達(dá)的數(shù)據(jù)。
繼續(xù)我們的比喻拟蜻，組織洗衣店的流程處理方法將分類绎签，匹配和整理從洗衣機(jī)中取出的衣物。 在這種方法中瞭郑，最初對每一件衣物都進(jìn)行了更多的工作辜御，但是以后不再需要返回并重新整理整個抽屜，因為它已經(jīng)組織好了屈张，并且不再浪費時間搜尋 用于埋藏衣物的抽屜擒权。
有越來越多的系統(tǒng)設(shè)計用于流處理，包括Apache Storm和Apache Heron阁谆。 這些系統(tǒng)經(jīng)常部署以支持近乎實時的事件處理碳抄。
