最常見(jiàn)的導(dǎo)致不完整的原因是遲到的數(shù)據(jù)（正如在這篇谷歌云數(shù)據(jù)流的演示文稿中詳細(xì)解釋的）。在真實(shí)的環(huán)境中，遲到的數(shù)據(jù)可以是基礎(chǔ)設(shè)施層存在問(wèn)題，例如數(shù)據(jù)中心的連接斷開(kāi)了15分鐘；或是用戶層面的問(wèn)題，例如移動(dòng)應(yīng)用由于在飛行中不良的連接質(zhì)量而導(dǎo)致事件的延遲發(fā)送。在優(yōu)步，我們面臨著十分相似的挑戰(zhàn)，正如我們今年早些時(shí)候在Strata + Hadoop World大會(huì)上所闡述的。
為了有效地支持如此多樣的應(yīng)用集合，編程模型需要以一等公民的方式來(lái)對(duì)待遲到的數(shù)據(jù)。然而，Hadoop的處理通常是基于在完整數(shù)據(jù)（例如Hive中的分區(qū)）上的批處理，有保證完整性的職責(zé)，也要完全依賴數(shù)據(jù)產(chǎn)生者。在如今復(fù)雜的數(shù)據(jù)生態(tài)系統(tǒng)里，這對(duì)于單個(gè)數(shù)據(jù)產(chǎn)生者來(lái)說(shuō)職責(zé)簡(jiǎn)直太多了。大部分產(chǎn)生者最終通過(guò)在一個(gè)諸如Kafka這樣的存儲(chǔ)系統(tǒng)上使用流式處理來(lái)達(dá)到較低的延遲，而依賴Hadoop存儲(chǔ)來(lái)達(dá)到更加“完整”的（重）處理。我們將在下一節(jié)對(duì)此展開(kāi)來(lái)講。
缺乏用于增量處理的原語(yǔ)
正如在這篇關(guān)于流式處理的文章中詳細(xì)描述的，事件時(shí)間以及其相對(duì)的到達(dá)時(shí)間的定義和遲到數(shù)據(jù)的處理是低延遲計(jì)算中很重要的方面。遲到的數(shù)據(jù)要求重新計(jì)算時(shí)間窗口（通常就是Hadoop中的Hive分區(qū)），盡管這些時(shí)間窗口的結(jié)果可能已經(jīng)被計(jì)算完成甚至是已經(jīng)與終端用戶進(jìn)行過(guò)了交互。通常來(lái)說(shuō)，在流式處理世界中這類重新計(jì)算是通過(guò)使用可擴(kuò)展的鍵值存儲(chǔ)，在記錄/事件層面增量發(fā)生的，并針對(duì)點(diǎn)查詢和更新進(jìn)行優(yōu)化。然而，在Hadoop中，重新計(jì)算通常意味著重寫(xiě)整個(gè)（不可變）的Hive分區(qū)（或者簡(jiǎn)而言之是一個(gè)HDFS中的文件夾），并且重新計(jì)算所有在那個(gè)Hive分區(qū)上已經(jīng)被消費(fèi)過(guò)的任務(wù)。
從延遲和資源利用角度來(lái)看，這些操作都是開(kāi)銷昂貴的。這一開(kāi)銷通常會(huì)級(jí)聯(lián)地傳導(dǎo)到整個(gè)Hadoop的數(shù)據(jù)流中，最終導(dǎo)致延遲增加了數(shù)小時(shí)。因此，增量處理需要使得這兩種操作更加得快速，從而使我們可以有效地將改變包含到已有的Hive分區(qū)中，并且為下游的表數(shù)據(jù)消費(fèi)者提供一個(gè)僅獲取新改變的數(shù)據(jù)的方式。