第三部分:日志和實(shí)時(shí)流處理
到此為止，我只是描述從端到端數(shù)據(jù)復(fù)制的理想機(jī)制。但是在存儲(chǔ)系統(tǒng)中搬運(yùn)字節(jié)不是所要講述內(nèi)容的全部。最終我們發(fā)現(xiàn)日志是流的另一種說(shuō)法，日志是流處理的核心。
但是，等等，什么是流處理呢？
如果你是90年代晚期或者21世紀(jì)初數(shù)據(jù)庫(kù)文化或者數(shù)據(jù)基礎(chǔ)架構(gòu)產(chǎn)品的愛(ài)好者，那么你就可能會(huì)把流處理與建創(chuàng)SQL引擎或者創(chuàng)建“箱子和箭頭”接口用于事件驅(qū)動(dòng)的處理等聯(lián)系起來(lái)。
如果你關(guān)注開源數(shù)據(jù)庫(kù)系統(tǒng)的大量出現(xiàn)，你就可能把流處理和一些開源數(shù)據(jù)庫(kù)系統(tǒng)關(guān)聯(lián)起來(lái)，這些系統(tǒng)包括了：Storm,Akka,S4和Samza.但是大部分人會(huì)把這些系統(tǒng)作為異步消息處理系統(tǒng)，這些系統(tǒng)與支持群集的遠(yuǎn)程過(guò)程調(diào)用層的應(yīng)用沒(méi)什么差別（而事實(shí)上在開源數(shù)據(jù)庫(kù)系統(tǒng)領(lǐng)域某些方面確實(shí)如此）。
這些視圖都有一些局限性。流處理與SQL是無(wú)關(guān)的。它也局限于實(shí)時(shí)流處理。不存在內(nèi)在的原因限制你不能處理昨天的或者一個(gè)月之前的流數(shù)據(jù)，且使用多種不同的語(yǔ)言表達(dá)計(jì)算。
我把流處理視為更廣泛的概念：持續(xù)數(shù)據(jù)流處理的基礎(chǔ)架構(gòu)。我認(rèn)為計(jì)算模型可以像MapReduce或者分布式處理架構(gòu)一樣普遍，但是有能力處理低時(shí)延的結(jié)果。
處理模型的實(shí)時(shí)驅(qū)動(dòng)是數(shù)據(jù)收集方法。成批收集的數(shù)據(jù)是分批處理的。數(shù)據(jù)是不斷收集的，它也是按順序不斷處理的。
美國(guó)的統(tǒng)計(jì)調(diào)查就是成批收集數(shù)據(jù)的良好典范。統(tǒng)計(jì)調(diào)查周期性的開展，通過(guò)挨門挨戶的走訪，使用蠻力發(fā)現(xiàn)和統(tǒng)計(jì)美國(guó)的公民信息。1790年統(tǒng)計(jì)調(diào)查剛剛開始時(shí)這種方式是奏效的。那時(shí)的數(shù)據(jù)收集是批處理的，它包括了騎著馬悠閑的行進(jìn)，把信息寫在紙上，然后把成批的記錄傳送到人們統(tǒng)計(jì)數(shù)據(jù)的中心站點(diǎn)。現(xiàn)在，在描述這個(gè)統(tǒng)計(jì)過(guò)程時(shí)，人們立即會(huì)想到為什么我們不保留出生和死亡的記錄，這樣就可以產(chǎn)生人口統(tǒng)計(jì)信息這些信息或是持續(xù)的或者是其它維度的。
這是一個(gè)極端的例子，但是大量的數(shù)據(jù)傳送處理仍然依賴于周期性的轉(zhuǎn)儲(chǔ)，批量轉(zhuǎn)化和集成。處理大容量轉(zhuǎn)儲(chǔ)的唯一方法就是批量的處理。但是隨著這些批處理被持續(xù)的供給所取代，人們自然而然的開始不間斷的處理以平滑的處理所需資源并且消除延遲。
例如LinkedIn幾乎沒(méi)有批量數(shù)據(jù)收集。大部分的數(shù)據(jù)或者是活動(dòng)數(shù)據(jù)或者是數(shù)據(jù)庫(kù)變更，這兩者都是不間斷發(fā)生的。事實(shí)上，你可以想到的任何商業(yè)，正如：Jack Bauer告訴我們的，低層的機(jī)制都是實(shí)時(shí)發(fā)生的不間斷的流程事件。數(shù)據(jù)是成批收集的，它總是會(huì)依賴于一些人為的步驟，或者缺少數(shù)字化或者是一些自動(dòng)化的非數(shù)字化流程處理的遺留信息。當(dāng)傳送和處理這些數(shù)據(jù)的機(jī)制是郵件或者人工的處理時(shí)，這一過(guò)程是非常緩慢的。首輪自動(dòng)化總是保持著最初的處理形式，它常常會(huì)持續(xù)相當(dāng)長(zhǎng)的時(shí)間。
每天運(yùn)行的批量處理作業(yè)常常是模擬了一種一天的窗口大小的不間斷計(jì)算。當(dāng)然，低層的數(shù)據(jù)也經(jīng)常變化。在LinkedIn,這些是司空見(jiàn)貫的，并且使得它們?cè)贖adoop運(yùn)轉(zhuǎn)的機(jī)制是有技巧的，所以我們實(shí)施了一整套管理增量的Hadoop工作流的架構(gòu)。
由此看來(lái)，對(duì)于流處理可以有不同的觀點(diǎn)。流處理包括了在底層數(shù)據(jù)處理的時(shí)間概念，它不需要數(shù)據(jù)的靜態(tài)快照，它可以產(chǎn)生用戶可控頻率的輸出，而不用等待數(shù)據(jù)集的全部到達(dá)。從這個(gè)角度上講，流處理就是廣義上的批處理，隨著實(shí)時(shí)數(shù)據(jù)的流行，會(huì)兒更加普遍。
這就是為什么從傳統(tǒng)的視角看來(lái)流處理是利基應(yīng)用。我個(gè)人認(rèn)為最大的原因是缺少實(shí)時(shí)數(shù)據(jù)收集使得不間斷的處理成為了學(xué)術(shù)性的概念。
我想缺少實(shí)時(shí)數(shù)據(jù)收集就像是商用流處理系統(tǒng)注定的命運(yùn)。他們的客戶仍然需要處理面向文件的、每日批量處理ETL和數(shù)據(jù)集成。公司建設(shè)流處理系統(tǒng)關(guān)注的是提供附著在實(shí)時(shí)數(shù)據(jù)流的處理引擎，但是最終當(dāng)時(shí)極少數(shù)人真正使用了實(shí)時(shí)數(shù)據(jù)流。事實(shí)上，在我在LinkedIn工作的初期，有一家公司試圖把一個(gè)非常棒的流處理系統(tǒng)銷售給我們，但是因?yàn)楫?dāng)時(shí)我們的全部數(shù)據(jù)都按小時(shí)收集在的文件里，當(dāng)時(shí)我們提出的最好的應(yīng)用就是在每小時(shí)的最后把這些文件輸入到流處理系統(tǒng)中。他們注意到這是一個(gè)普遍性的問(wèn)題。這些異常證明了如下規(guī)則：流處理系統(tǒng)要滿足的重要商業(yè)目標(biāo)之一是：財(cái)務(wù)， 它是實(shí)時(shí)數(shù)據(jù)流已具備的基準(zhǔn)，并且流處理已經(jīng)成為了瓶頸。