這類SQL引擎的另一個(gè)重要進(jìn)步是對諸如ORC/Parquet等列式文件格式的支持，這對于分析工作是有著顯著好處的。例如，連接兩個(gè)有Avro記錄的Kafka主題將比連接兩個(gè)通過ORC/Parquet文件格式存儲(chǔ)的Hive/Spark的表的開銷大得多。這是因?yàn)?，對于Avro記錄來說，你最終要反序列化整個(gè)記錄，而列式文件中只需要讀取在記錄中會(huì)被查詢所用到的列。如果我們簡單地從一條編碼的Kafka Avro事件中的1000個(gè)字段中投影出10個(gè)字段，我們?nèi)匀恍枰獮樗凶侄位ㄙM(fèi)CPU和I/O的開銷。列式文件格式通?？梢愿鼮?ldquo;聰明”地投影到存儲(chǔ)層。
圖三：Kafka事件和HDFS上列式文件，將10個(gè)字段從1000個(gè)字段中投影出來的CPU和I/O開銷的對比。由Vinoth Chandar提供
較少的運(yùn)動(dòng)部件
現(xiàn)在被廣泛實(shí)現(xiàn)的Lambda架構(gòu)（一個(gè)基于MapReduce 和 Storm 構(gòu)建的流式處理的應(yīng)用架構(gòu)）有兩個(gè)模塊：速度層和批處理層。它們通常由兩個(gè)獨(dú)立的實(shí)現(xiàn)（從代碼到基礎(chǔ)設(shè)施）來管理。例如，Storm是速度層上的一個(gè)熱門選項(xiàng)，而MapReduce可以作為批處理層來提供服務(wù)。實(shí)際上，人們經(jīng)常依賴速度層來提供更新的結(jié)果（可能并不準(zhǔn)確），而一旦數(shù)據(jù)被認(rèn)為是完整了之后，通過批處理層在稍后的時(shí)候里來糾正速度層的結(jié)果。隨著增量處理的使用，我們有機(jī)會(huì)以統(tǒng)一的方式在代碼層面和基礎(chǔ)設(shè)施層面來實(shí)現(xiàn)Lambda架構(gòu)。