。這樣也就很難實現(xiàn)實時查詢。例如，對于微博應用來說，可能往往 需要在第二天甚至很多天之后才能統(tǒng)計出當前的熱門微博，而無法在當天即統(tǒng)計出這一天 的熱門微博。與現(xiàn)有技術不同的是，本發(fā)明在將日志數據存儲在文件系統(tǒng)之前，先對日志數 據進行了整理，也就是對日志數據進行邊整理邊存儲，因此文件系統(tǒng)中所存儲的是已整理 好的日志數據。這樣，在對日志數據進行查詢時，可以從部分已整理好的日志數據中查詢， 因此可以節(jié)約數據查詢時間，提高對查詢請求的響應速度，從而可以實現(xiàn)針對大數據的實 時查詢。
[0029]圖3示出根據本發(fā)明另一個實施例的數據處理方法300的流程示意圖。圖3所示的 數據處理方法300的步驟S310、S320和S330分別與圖1所示的數據處理方法100的步驟S110、 S120和S130相對應。本領域技術人員根據圖1和上文的描述可以理解圖3中的上述步驟，為 了簡潔，在此不再贅述。根據本實施例，在步驟S330之后，數據處理方法300可以進一步包括 步驟S340。
[0030] 在步驟S340，從臨時緩存中刪除存儲在臨時緩存中的日志數據中的至少一部分， 以將新消費的日志數據存儲在臨時緩存中。
[0031] 在將經整理的日志數據存儲在文件系統(tǒng)中之后，可以刪除實時節(jié)點的臨時緩存中 的對應的原始的、未經整理的日志數據。相當于，實時節(jié)點以先入先出的方式整理日志數據 并將經整理的日志數據存儲在文件系統(tǒng)中。隨后實時節(jié)點刪除與經整理的日志數據對應的 那部分原始的日志數據以空出緩存空間。隨后實時節(jié)點再繼續(xù)消費新的日志數據并將新消 費的日志數據存儲在空閑的緩存空間中。這是一個類似流水線的工作方式。這種工作方式 比較高效，能夠滿足對大數據的實時處理要求?？偟膩碚f，實時節(jié)點可以不斷地流水線式地 消費、整理并存儲日志數據。通過以上方式，可以使得在文件系統(tǒng)中存儲經過整理的日志數 據，并且相應地在實時節(jié)點的臨時緩存中存儲未經整理的日志數據。
[0032] 可以理解的是，雖然根據本實施例以及圖3,步驟S340在步驟S330之后實施，但是 可以理解的是，步驟S340也可以與步驟S330同時實施。
[0033]圖4示出根據本發(fā)明另一個實施例的數據處理方法400的流程示意圖。圖4所示的 數據處理方法400的步驟S410、S420、S430和S440分別與圖3所示的數據處理方法300的步驟 S310、S320、S330和S340相對應。本領域技術人員根據圖3和上文的描述可以理解圖4中的上 述步驟，為了簡潔，在此不再贅述。根據本實施例，數據處理方法400可以進一步包括以下步 驟。
[0034] 在步驟S450,接收查詢請求。
[0035] 返回參考圖2,可以利用外部的查詢接口 270和druid數據庫中的代理(broker)節(jié) 點240來接收用戶的查詢請求。如下所述，代理節(jié)點240可以匯總實時節(jié)點230和歷史 (history)節(jié)點250查詢到的數據，將查詢結果返回給用戶，并且可以負責查詢數據的緩存。 [0036]在步驟S460,根據查詢請求從存儲在文件系統(tǒng)中的經整理的日志數據以及存儲在 臨時緩存中的日志數據中查詢期望數據。
[0037]代理節(jié)點240在接收到查詢請求時，可以分別從實時節(jié)點230的臨時緩存中以及從 文件系統(tǒng)260中獲取數據。對于存儲在實時節(jié)點230的臨時緩存中的日志數據來說，代理節(jié) 點240可以直接訪問實時節(jié)點230,請求實時節(jié)點230返回期望數據。而對于存儲在文件系統(tǒng) 260中的日志數據來說，代理節(jié)點240可以間接經由druid數據庫的歷史節(jié)點250來查詢。 [00 38]歷史節(jié)點250負責從文件系統(tǒng)下載segment，提供數據查詢服務。歷史節(jié)點250可分 為多個層(tier)，例如熱數據放置在一個層，冷數據放置在另外一個層，以達到冷熱數據分 開處理的目的。
[0039]在步驟S470,對期望數據進行匯總以獲得查詢結果。
[0040]在接收到由實時節(jié)點230返回的未經整理的日志數據和由歷史節(jié)點返回的經整理 的日志數據之后，代理節(jié)點240可以對這些數據進行匯總分析。
[0041]可以理解的是，用戶希望對日志數據進行實時查詢，例如希望獲知當天的熱門微 博。由于日志數據的整理會有一定延時，因此，存儲在文件系統(tǒng)260中的日志數據可能反映 的是當前時刻的半小時之前的微博信息，而存儲在實時節(jié)點230的臨時緩存中的、正在排隊 等待實時節(jié)點230整理的日志數據可能反映的是當前時刻之前的半小時內的微博信息。這 樣，可以統(tǒng)一匯總未經整理的日志數據以及經整理的日志數據來獲得當天的熱門微博信 息。由于存儲在文件系統(tǒng)260中的日志數據已經經過了整理，例如已經基于微博內容、時間 等信息進行了合并，即統(tǒng)計了一定時段內某些微博的閱讀量。這樣，在匯總期望數據時所花 費的時間會很少。尤其與現(xiàn)有技術相比，由于無需對日志數據進行大量統(tǒng)計運算，因此查詢 效率大大增加。
[0042] 在步驟S480,輸出查詢結果。
[0043]代理節(jié)點240在匯總期望數據并獲得查詢結果之后，可以將該查詢結果返回給發(fā) 送查詢請求的客戶端或服務器。這樣，可以使得用戶實時獲得希望獲知的信息。
[0044] 上述查詢方式可以實時高效地獲得希望查詢的信息。
[0045] 可選地，接收查詢請求、對期望數據進行匯總以獲得查詢結果和輸出查詢結果是 利用druid數據庫中的代理節(jié)點來實現(xiàn);根據查詢請求從存儲在文件系統(tǒng)中的經整理的日 志數據以及存儲在臨時緩存中的日志數據中查詢期望數據是利用druid數據庫中的實時節(jié) 點和歷史節(jié)點來實現(xiàn);從消息隊列中消費日志數據并將所消費的日志數據存儲在臨時緩存 中、對存儲在臨時緩存中的日志數據中的至少一部分進行整理，以獲得經整理的日志數據 和將經整理的日志數據存儲在文件系統(tǒng)中是利用實時節(jié)點來實現(xiàn)。
[0046] 結合圖2以及上文的描述可以理解本實施例的實現(xiàn)方式，不再贅述。與其它數據庫 相比，druid數據庫可以滿足大數據的處理需求、滿足實時的數據查詢需求并且寫入性能很 高，是一種非常適合應用于大數據處理的數據庫。
[0047]可選地，S120 (3 20、420)可以包括:將存儲在臨時緩存中的日志數據中的至少一部 分中的相關聯(lián)的日志數據進行合并并將經合并的日志數據按照時間分片，以生成經整理的 日志數據。
[0048] 如上文所述，druid數據庫的實時節(jié)點可以周期性地啟動后臺的計劃任務搜索與 日志數據相關的持久化索引，后臺計劃任務將這些持久化索引合并到一起并生成不可變的 數據塊（即分片）。數據塊包含了一段時間內的所有已經由實時節(jié)點消費的數據。也就是說， 數據塊是持有某段時間間隔的自包含數據容器。每個數據塊包含列方向的數據，以及這些 列的索引。druid數據庫在查詢數據時是基于數據塊過濾的。
[0049] 例如，可以以一個小時為單位生成數據塊。假設在某一日的13點至15點這兩個小 時內，實時節(jié)點消費的日志數據如表1所示。
[0050] 表1示例性的日志數據 rnnsi1
luuozj 衣1?乂間平不m J Η志雙做tfj+w不1列，以用丁況叨卒僅叨tfJ頭MW?？凇挂月裼门fJ 是，表1所示的日志數據的形式并非對本發(fā)明的限制。
[0053]可以將表1所示的日志數據分為兩個數據塊，即13點至14點中的日志數據為一個 數據塊，14點至15點的日志數據為一個數據塊。同時，對日志數據進行合并。因此，得到在13 點至14點的時間段內，a網址的點擊數為1次，b網址為2次，c網址為1次。在14點至15點的時 間段內，a網址的點擊數為2次，b網址為0次，c網址為1次。因此，通過上述合并和分片方式可 以獲得經整理的日志數據。
[0054] 可以理解的是，雖然圖4示出步驟S450至S480在步驟S440之后實施，但是可以理解 的是，步驟S450至S480可以在任意時刻實施，也就是查詢可以是實時的。
[0055] 可選地，在步驟S130(S330、S430)之前，數據處理方法100(300、400)可以進一步包 括:建立數據索引，數據索引用于指示經整理的日志數據在文件系統(tǒng)中的存儲位置。
[0056]在將經整理的日志數據存儲到文件系統(tǒng)之前，實時節(jié)點可以建立數據索引。在后 期希望對查詢文件系統(tǒng)中的經整理的日志數據時，可以根據數據索引來找到所需要的日志 數據的存儲位置。這樣，可以