大數據的存儲、搜索方法及裝置的制造方法
【專利摘要】本發明提供了一種大數據的存儲、搜索方法及裝置,其中存儲方法包括:獲取大數據的原始日志并分析其具體日志內容;根據所述具體日志內容對所述原始日志進行分類,將指定數目的原始日志集合生成一個文檔,并為該文檔建立與分詞間的映射關系,其中,所述分詞與該文檔的具體日志內容相匹配;對各文檔進行組合處理以生成組合的文件,其中,該文件被搜索時,能夠提供與組合文檔數目相對應的多個分詞;利用所述文件替代所述原始日志存入到分布式存儲系統架構中。采用本發明能夠大大降低了數據的冗余性,從而減少了對服務器資源的浪費,提高存儲資源的利用率。
【專利說明】
大數據的存儲、搜索方法及裝置
技術領域
[0001] 本發明涉及計算機技術領域,特別是涉及大數據的存儲、搜索方法及裝置。
【背景技術】
[0002] 隨著計算機和網絡的發展,搜索功能已經成為最常用的功能,用戶通過搜索操作 方便快捷地獲取目的信息。但是,隨著業務的發展,可搜索的數據量也越來越大,目前將不 斷增大的數據量稱之為大數據,對其的搜索操作稱之為對大數據的搜索。
[0003] 大數據的數據量級通常是百萬級以上,甚至是百萬億級、千萬億級以上,針對如此 龐大的數據體系,首先對數據的存儲提到了較高的要求。例如,目前常用的ES系統(Elected Search),該系統中,搜索匹配操作所需要的索引數據和原始數據均要存儲在該系統中,對 系統的要求較高。并且,為了保證原始數據的可靠性,還需要在分布式系統基礎架構 (hadoop)中進行存儲,這就導致了數據冗余,會造成大量的服務器資源的浪費。
[0004] 進一步,搜索引擎在工作時,首先對搜索詞進行分詞,然后對各分詞執行大數據匹 配操作,即對每個分詞都在大數據體系中進行龐大的匹配操作,那么,尤其在存在數據冗余 的情況下,對搜索詞進行的匹配操作的數量必然也是極高的數量級。
[0005] 考慮到大數據級別的搜索操作的操作本身數量級高,則必然會浪費較多的時間和 系統資源。并且,耗時過長,對于搜索引擎本身也是致命的弱點,若用戶無法在較短的時間 內獲得有效搜索結果,那么,該搜索引擎的用戶粘性就會逐漸下降。
[0006] 因此,現在亟需一種針對大數據搜索的改進方法。
【發明內容】
[0007] 鑒于上述問題,提出了本發明以便提供一種克服上述問題或者至少部分地解決上 述問題的大數據的存儲、搜索方法及裝置。
[0008] 基于本發明的一個方面,本發明實施例提供了一種數據的存儲方法,包括:
[0009] 獲取大數據的原始日志并分析其具體日志內容;
[0010] 根據所述具體日志內容對所述原始日志進行分類,將指定數目的原始日志集合生 成一個文檔,并為該文檔建立與分詞間的映射關系,其中,所述分詞與該文檔的具體日志內 容相匹配;
[0011] 對各文檔進行組合處理以生成組合的文件,其中,該文件被搜索時,能夠提供與組 合文檔數目相對應的多個分詞;
[0012] 利用所述文件替代所述原始日志存入到分布式存儲系統架構中。
[0013] 可選地,對各文檔進行組合處理以生成組合的文件,包括:
[0014] 對各文檔進行文檔壓縮處理,得到壓縮后的壓縮文檔;
[0015] 對各壓縮文檔進行組合處理,得到組合的文件。
[0016] 可選地,所述壓縮文檔格式為gz文件。
[0017] 可選地,所述指定數目的原始日志為128條原始日志,所述組合的文件為256M~2G 之間。
[0018] 可選地,利用所述文件替代所述原始日志存入到分布式存儲系統架構中,包括:
[0019] 利用所述文件中第一個分詞的起始位置作為參考位置,記錄各分詞在所述文件中 的偏移位置;
[0020] 將各分詞在所述文件中的偏移位置信息以及所述文件均存入所述分布式存儲系 統架構中。
[0021] 可選地,所述大數據為百萬級別以上的數據。
[0022] 基于本發明的另一個方面,本發明實施例還提供了一種大數據的搜索方法,應用 于使用上述的大數據的存儲方法的數據存儲系統,所述方法包括:
[0023] 對搜索詞進行分詞,得到多個分詞;
[0024] 利用各分詞到所述使用了大數據的存儲方法的數據存儲系統中進行匹配,得到匹 配結果,其中,所述數據存儲系統中包括多個文件,各文件中包括多個文檔,每個文檔與分 詞間具備映射關系;
[0025] 根據所述匹配結果查找到對應的文檔,并從所述文檔中再次匹配到對應的原始日 ν·、ι、〇
[0026] 可選地,利用各分詞到所述使用了大數據的存儲方法的數據存儲系統中進行匹 配,包括:
[0027] 利用倒排索引結構的方式,利用各分詞到所述使用了大數據的存儲方法的數據存 儲系統中進行匹配。
[0028] 可選地,所述大數據為百萬級別以上的數據。
[0029] 基于本發明的又一個方面,本發明實施例還提供了一種大數據的存儲裝置,包括:
[0030] 日志分析模塊,適于獲取大數據的原始日志并分析其具體日志內容;
[0031 ]文檔生成模塊,適于根據所述具體日志內容對所述原始日志進行分類,將指定數 目的原始日志集合生成一個文檔,并為該文檔建立與分詞間的映射關系,其中,所述分詞與 該文檔的具體日志內容相匹配;
[0032]文件生成模塊,適于對各文檔進行組合處理以生成組合的文件,其中,該文件被搜 索時,能夠提供與組合文檔數目相對應的多個分詞;
[0033]存儲模塊,適于利用所述文件替代所述原始日志存入到分布式存儲系統架構中。 [0034] 可選地,所述文件生成模塊還適于:
[0035]對各文檔進行文檔壓縮處理,得到壓縮后的壓縮文檔;
[0036]對各壓縮文檔進行組合處理,得到組合的文件。
[0037]可選地,所述壓縮文檔格式為gz文件。
[0038]可選地,所述指定數目的原始日志為128條原始日志,所述組合的文件為256M~2G 之間。
[0039] 可選地,其中,所述存儲模塊還適于:
[0040] 利用所述文件中第一個分詞的起始位置作為參考位置,記錄各分詞在所述文件中 的偏移位置;
[0041] 將各分詞在所述文件中的偏移位置信息以及所述文件均存入所述分布式存儲系 統架構中。
[0042]可選地,所述大數據為百萬級別以上的數據。
[0043]基于本發明的再一個方面,本發明實施例還提供了一種大數據的搜索裝置,與上 述的大數據的存儲裝置耦合,所述裝置包括:
[0044]分詞模塊,適于對搜索詞進行分詞,得到多個分詞;
[0045] 第一匹配模塊,適于利用各分詞到所述使用了大數據的存儲裝置的數據存儲系統 中進行匹配,得到匹配結果,其中,所述數據存儲系統中包括多個文件,各文件中包括多個 文檔,每個文檔與分詞間具備映射關系;
[0046] 第二匹配模塊,適于根據所述匹配結果查找到對應的文檔,并從所述文檔中再次 匹配到對應的原始日志。
[0047] 可選地,所述第一匹配模塊還適于:
[0048] 利用倒排索引結構的方式,利用各分詞到所述使用了大數據的存儲裝置的數據存 儲系統中進行匹配。
[0049] 可選地,所述大數據為百萬級別以上的數據。
[0050] 在本發明實施例中,對于原始日志的存儲方式進行了改進,因單條原始日志非常 小,通常只有幾 K或者幾十K,若大量原始日志直接存儲,則會形成大量的存儲碎片,且每次 存儲均要為該原始日志生成對應的索引,浪費大量存儲資源,因此,本發明實施例將指定數 目的原始日志集合合并生成一個文檔。其中,文檔中所包含哪些原始日志由具體日志內容 所決定,這樣就能夠讓具備相似日志內容的原始日志歸納至一個文檔中。進一步,本發明實 施例還根據文檔所對應的具體日志內容生成可用于進行搜索或索引操作的分詞,分詞與具 體的文檔間形成映射關系,以便后期搜索時,能夠利用搜索詞的分詞與文檔的分詞直接匹 配。隨后,本發明實施例還對各文檔再次進行組合處理,生成組合的文件,進而利用文件替 代原始日志存儲到分布式存儲系統架構中。由此可以看出,本發明實施例中,將原始日志進 行了集中合成,生成具備一定規模和容量的文件,并對文件進行統一的存儲管理,文件的容 量要遠遠超過原始日志的大小,對于分布式存儲系統架構而言,文件的管理僅需要設置文 件的索引,而不需要設置每條原始日志的索引,大大降低了數據的冗余性,從而減少了對服 務器資源的浪費,提高存儲資源的利用率。采用本發明實施例所提供的大數據的存儲方法, 因能夠達到減少資源浪費的目的,適用于任何大數據的存儲過程,甚至于百萬級別、百萬億 級、千萬億級的大數據的存儲。
[0051] 在本發明實施例中,因采用了上文所述的大數據的存儲方法的數據存儲系統,數 據存儲利用了分詞與文檔間的映射關系,并將多個原始日志聚合成分詞,這使得數據存儲 的數量級大大下降,也使得搜索詞分詞所得到的各分詞的搜索過程簡單快捷化,分詞無須 依次與各原始日志進行匹配,而是分別匹配數據存儲系統中的分詞,數據存儲系統中的分 詞數據比之原始日志的數量級大大降低,縮短了匹配時間。若匹配上,則進一步在文檔中針 對多條原始日志進行二次匹配即可,匹配操作所需數據級大大下降,那么針對大數據的搜 索方法的搜索時間也必然大大下降,大大提高了搜索效率以及用戶的感受體驗,對于搜索 引擎而言,能夠增加用戶粘性。
[0052]上述說明僅是本發明技術方案的概述,為了能夠更清楚了解本發明的技術手段, 而可依照說明書的內容予以實施,并且為了讓本發明的上述和其它目的、特征和優點能夠 更明顯易懂,以下特舉本發明的【具體實施方式】。
[0053]根據下文結合附圖對本發明具體實施例的詳細描述,本領域技術人員將會更加明 了本發明的上述以及其他目的、優點和特征。
【附圖說明】
[0054]通過閱讀下文優選實施方式的詳細描述,各種其他的優點和益處對于本領域普通 技術人員將變得清楚明了。附圖僅用于示出優選實施方式的目的,而并不認為是對本發明 的限制。而且在整個附圖中,用相同的參考符號表示相同的部件。在附圖中:
[0055] 圖1示出了根據本發明一個實施例的大數據的存儲方法的處理流程圖;
[0056] 圖2示出了根據本發明一個實施例的大數據的搜索方法的處理流程圖;
[0057] 圖3示出了根據本發明一個實施例的大數據的存儲裝置的結構示意圖;以及
[0058] 圖4示出了根據本發明一個實施例的大數據的搜索裝置的結構示意圖。
【具體實施方式】
[0059]下面將參照附圖更詳細地描述本公開的示例性實施例。雖然附圖中顯示了本公開 的示例性實施例,然而應當理解,可以以各種形式實現本公開而不應被這里闡述的實施例 所限制。相反,提供這些實施例是為了能夠更透徹地理解本公開,并且能夠將本公開的范圍 完整的傳達給本領域的技術人員。
[0060]為解決上述技術問題,本發明實施例提供了一種大數據的存儲方法。圖1示出了根 據本發明一個實施例的大數據的存儲方法的處理流程圖。參見圖1,大數據的存儲方法至少 包括:
[0061 ]步驟S102、獲取大數據的原始日志并分析其具體日志內容;
[0062]步驟S104、根據具體日志內容對原始日志進行分類,將指定數目的原始日志集合 生成一個文檔,并為該文檔建立與分詞間的映射關系,其中,分詞與該文檔的具體日志內容 相匹配;
[0063]步驟S106、對各文檔進行組合處理以生成組合的文件,其中,該文件被搜索時,能 夠提供與組合文檔數目相對應的多個分詞;
[0064]步驟S108、利用文件替代原始日志存入到分布式存儲系統架構中。
[0065]在本發明實施例中,對于原始日志的存儲方式進行了改進,因單條原始日志非常 小,通常只有幾 K或者幾十K,若大量原始日志直接存儲,則會形成大量的存儲碎片,且每次 存儲均要為該原始日志生成對應的索引,浪費大量存儲資源,因此,本發明實施例將指定數 目的原始日志集合合并生成一個文檔。其中,文檔中所包含哪些原始日志由具體日志內容 所決定,這樣就能夠讓具備相似日志內容的原始日志歸納至一個文檔中。進一步,本發明實 施例還根據文檔所對應的具體日志內容生成可用于進行搜索或索引操作的分詞,分詞與具 體的文檔間形成映射關系,以便后期搜索時,能夠利用搜索詞的分詞與文檔的分詞直接匹 配。隨后,本發明實施例還對各文檔再次進行組合處理,生成組合的文件,進而利用文件替 代原始日志存儲到分布式存儲系統架構中。由此可以看出,本發明實施例中,將原始日志進 行了集中合成,生成具備一定規模和容量的文件,并對文件進行統一的存儲管理,文件的容 量要遠遠超過原始日志的大小,對于分布式存儲系統架構而言,文件的管理僅需要設置文 件的索引,而不需要設置每條原始日志的索引,大大降低了數據的冗余性,從而減少了對服 務器資源的浪費,提高存儲資源的利用率。采用本發明實施例所提供的大數據的存儲方法, 因能夠達到減少資源浪費的目的,適用于任何大數據的存儲過程,甚至于百萬級別、百萬億 級、千萬億級的大數據的存儲。
[0066] 具體地,以ES系統為例,現有的ES系統,原始日志的原始數據以及相應的索引都需 要存儲在ES系統中,并且,為保證數據的準確性,還需要對原始數據進行備份,在hadoop里 面再存一份,這樣就會導致數據冗余,浪費大量的服務器資源。并且,雖然索引的數據量遠 小于原始數據的數據量,但是,當存儲的是百萬以上級別的大數據時,每天所生成索引的數 量級也會在幾 TB甚至更高,這對于普通的服務器而言也是非常不容易滿足的。進一步,在幾 TB的索引里進行搜索,也是非常耗時耗資源的。若因此為這些索引提供上一級的索引,那么 就得再建索引的索引,形成多層索引,也會浪費大量的資源。
[0067] 而本發明實施例中,可以將指定數目的原始日志(例如128條)合成一個文檔,進而 將該文檔壓縮成gz文件。需要說明的是,gz文件是UNIX系統中的壓縮文件,ZIP的Gnu版本, 功能和WINRAR-樣,是壓縮文件的擴展名。128條日志所組成的文檔經壓縮之后,大概會縮 為100K左右的容量。但是,若以100K為單位存入到hadoop里,容量級太低,仍會存在碎片化 的問題,因此,為改善這一問題,本發明實施例可以將多個gz文件合在一起,并根據一定的 合成規則連成一片,變成一個256M~2G的大文件。其中,文件的大小可以根據具體情況在 256M-2G之間的空間任取一個具體容量值,例如256M的文件、1G的文件、2G的文件等。然后以 文件作為元數據將其存儲到hadoop里面。所組合的文件中有多個由128條原始日志所組成 的文檔,每個文檔可以對應一個分詞。那么,經如此整理后的原始數據所對應的索引,會降 到1-2TB的數量級,因此能夠大大降低對資源的損耗。
[0068]進一步,因文件-文檔-原始日志三層級的存儲方式,本發明實施例在利用文件替 換原始日志存入分布式存儲系統架構中(即步驟S108)時,優選的,可以不記錄每項的存儲 地址,而是利用文件中第一個分詞的起始位置作為參考位置,記錄各分詞在文件中的偏移 位置,那么,其他分詞的位置可以以第一個分詞的起始位置作為參考點,加上自身的偏移位 置,即可得到其他分詞的位置信息,進一步減少了所需存儲的數據。為實現這一優選方式, 本發明實施例將各分詞在文件中的偏移位置信息以及文件均存入分布式存儲系統架構中。 在應用中,找到文件中第一個分詞的起始位置之后,可以根據各分詞在文件中的偏移位置 信息讀取出第N個分詞的偏移量以及第N個分詞的數據長度,然后在第一個分詞的起始位置 加上第N個分詞的偏移量即可找到第N個分詞,而根據第N個分詞的數據長度,則能夠獲取完 整的第N個分詞,也即能獲知具體的原始日志。
[0069] 在存儲之后,為各文件建索引。本發明實施例優選采用倒排索引的方式進行處理。 具體的,對于任一文章,按照倒排索引的分詞算法,從其中抽取多個詞。假設有3篇文章,第 一篇文章是1,第二篇文章是2,第三篇文章是3,那么從第一篇文章中抽取十個詞,這十個詞 就是詞1,再分別抽取十個詞作為詞2、詞3以及詞4,那么詞1-4就對應文章1這個集合,以1作 為標識,則認為詞1-4對應1這個集合。而第二篇文章中抽取得到詞5、詞6,同時還抽取了詞 4,那么詞4-6就對應文章2這個集合,從而實現了倒排索引,即實現了詞到具體文檔的映射 過程。
[0070] 上一段從邏輯上說明了倒排索引的概念,現從具體實現上對倒排索引進行具體說 明。本實施例首先進行一個名詞解釋:
[0071 ]日志:指單條原始日志,或其他業務線的日志。有時候也泛指原始日志 [0072 ] Do c: Do cumen t的縮寫,稱為文檔。是128條原始日志的集合,仍然是明文、按行排列 的原始日志數據。類似于搜索引擎中的文檔。DocGz Doc的gz壓縮數據。預計每天有5.5億個 文件
[0073] Token:-個分詞。按照一定的分詞算法進行分詞分出來的單個元素。例如一個漢 語詞、或一個英文單詞、或一個MD5串、或一個文件名,等等
[0074] RawLogHDFSFile:存在于hdfs(Hadoop分布式文件系統)中的原始日志文件,一般 是壓縮格式
[0075] DocGzHDFSFile:存在于hdf s中的日志文件,該文件是由一組DocGz直接拼接在一 起的文件。由于gz格式特性,該文件仍然可以直接通過gunzip解壓 [0076] DocGzMeta:DocGz的元數據信息,包含下列三個字段:
[0077] string path= 1;//HDFS路徑,例如:/home/cloud/datamining/src/ycs/2014-04-22/00/logl·zwt·2014-04-22-00-17·gz
[0078] uint32 offset = 2;//數據起始偏移量
[0079] uint32 length = 3;//數據長度
[0080] DocIdList
[0081 ] -個分詞可能會出現多個文檔中,每個文檔有多行原始數據組成
[0082]每個關聯數據需要docId、rawIndex兩個信息來描述
[0083] Invertedlndex :倒排索引結構,搜索引擎中的核心數據結構,一般包含1000個 Token及其索引信息
[0084] map〈string/*分詞*/,DocIdList>index = l;
[0085] InvertedlndexGz: Invertedlndex數據結構序列化之后的數據,然后使用gz壓縮
[0086] InvertedlndexGzHDFSFile:在hdfs上存儲的倒排索引結構文件,該文件是由一組 InvertedlndexGz直接拼接在一起的文件
[0087] InvertedlndexGzMeta: InvertedlndexGz文件的元數據信息。包含下列幾個字段:
[0088] uint32 offset= 1;//某一個InvertedlndexGzMeta所在hdfs文件中的起始地址 偏移量
[0089] uint32 length = 2;//InvertedIndexGzMeta的所占數據長度 [0090] //uint32 hashid = 4;//可以通過Token進行hash運算計算出來
[0091 ] //string hdfspath = 3;//可以根據時間、索引表名、hashid等信息推斷出來 [0092]生成倒排索引過程:
[0093] RawLogHDFSFi le->Doc->DocGz->DocGzHDFSFi le
[0094] DocGzHDFSFi le->DocGzMeta, Token
[0095] Token->lnvertedlndex
[0096] 設計細節思路:
[0097]支持在數據節點上跑任務(類似于hadoop的MapReduce機制)
[0098] 是否可以將每天的日志,按照mid歸類,每個mid的所有日志作為一條記錄,這樣數 據集個數能降低1〇〇倍(大小不變)
[0099] 0〇〇1(1->0〇(3的存儲,是否可以存放在外部的1^〇3(^中(可選43(13、口丨1^、16(1丨8(113), 或者HBase中
[0100] RocksDB支持前綴查找和刪除
[0101] 索引數據放到hdfs里
[0102] 對名詞解釋清楚后,現對倒排索引的詳細設計進行說明。
[0103] 1.關于 Docld 及 DocGzHDFSFile 生成算法
[0104] 每個DocGzHDFSFile文件在本地生成好,一次性寫入hdfs,
[0105] 記錄DocGz個數,一次性向id分配中心(etcd)請求回該文件對應的所有id信息
[0106]使用etcd的分布式鎖機制,每次只有一個客戶端能夠獲取id
[0107] 記錄好Meta信息,同時將meta信息也寫入hdfs(寫到一個獨立的文本文件)
[0108] 2.DocId 生成中心
[0109] HTTP GET請求 [0110]參數:count
[0111] count:個數
[0112] day:每天的id都是重新從0開始分配 [0113] business_name:業務名
[0114] URI:/idgen/getid
[0115] 請求舉例:http://middl. safe .lycc.qihoo.net:9360/idgen/getid?count = 135&day = 20160229&business_name = ycs
[0116] HTTP返回數據為JS0N,
[0117] 參數
[0118] business_name:業務名(必選,格式舉例:yes)
[0119] day:日期(可選,默認當前日期,格式舉例:20160316)
[0120] count:要獲取id數量(可選,默認值1)
[0121] 返回數據舉例
[0122]
[0123] 123456 錯誤碼 2 〇 成功 3 100系統錯誤 4 101缺少參數 5 3.各種HDFS文件格式及路徑說明 6 以云查殺國內日志為例
[0130] DocGzHDFSFile
[0131 ]符合 DocGzHDFSFile格式的原始日志/home/cloud/datamining/src/ycs/YYYY-MM-dd/HH/abcde.gz [0132]預計有2w個文件
[0133] 文件名按數字遞增編碼命名,以節省空間,例如:
[0134] /home/cloud/datamining/src/ycs/2016-02-25/00/0. gz
[0135] /home/cloud/datamining/src/ycs/2016-02-25/00/1.gz
[0136] /home/cloud/datamining/src/ycs/2016-02-25/00/100.gz
[0137] /home/cloud/datamining/src/ycs/2016-02-25/01/1100.gz
[0138] /home/cloud/datamining/src/ycs/2016-02-25/23/23101.gz
[0139] DocGzMetaHDFSFile
[0140] 該文件是存儲了DocGzHDFSFile文件的me ta信息
[0141] DocGzMeta protobuf結構中的path字段將前綴都去掉,只留下關鍵信息,小時信 息和文件名編號。其他的信息可以自動推斷出來。
[0142] 例如文件/home/cloud/datamining/src/ycs/2016-02-25/00/100 · gz 對應的 path 為00/100
[0143] 上述path的計算方法為:去掉前綴路徑,去掉日期,去掉.gz后綴
[0144] 每天的me ta數據保存在一個文件中
[0145] 是文本文件,按行切分
[0146] 預計大小40G
[0147] 文件地址:/home/cloud/datamining/src/ycs/poseidon/docmeta/20160205 · gz
[0148] 每個DocGzHDFSFi le文件的DocGzMeta信息對應一個數據塊,全天所有 DocGzHDFSFile文件的數據塊合并到一起形成這個文件。
[0149] -個數據塊格式如下:
[0150] 起始行是DocGzHDFSFile文件路徑 [0151]后面每一行都分三列,以\t分割,分別如下
[0152] Docld
[0153] offset
[0154] lenght
[0155] 舉例如下
[0156]
[0157] 這個數據最終會存放到NoSQL中,例如bada或pika或quakedb等等帶有表空間和持 久化特性的kvdb中
[0158] 表空間命名:業務名,例如:yCS
[0159] key是docld
[0160] value是DocGzMetaGz
[0161] InvertedlndexGzHDFSFile
[0162] 第一階段:
[0163] Map 過程
[0164] 針對每一行日志進行分詞處理,各列有可能使用不同的分詞算法,需要區別對待
[0165] ext字段要進行二級細分,得到ext里面的key/valud對,然后進行分別分詞
[0166] map階段輸出:字段名,分詞的Hashld,分詞Token,Docld
[0167] 輸出的hashid需要模100億,最終的hashid在0~100億之間。算法:hashid = murmur3-hash64(token)% 100億
[0168] 注意hashid要使用12字節0補充對齊格式輸出,例如hashid= 123那么輸出應該為 000000000123
[0169] C++代碼為:std: : cout〈〈std: : setf ill( '0 ')〈〈std: : setw( 12)〈〈11&8111(1;〇++程序 示例
[0170] 這是因為hadoop的MR中間排序算法默認是按照字典序排序的,hashid的排序卻需 要按照數字大小排序
[0171 ]以字段名做hadoop的排序key
[0172] hash 算法推薦使用murmur3: https: //en · wikipedia · org/wiki/MurmurHash
[0173] C++:https://github. com/aappleby/smhasher
[0174] Golang:https ://github. com/spaolacci/murmur3 https://github.com/ hu i chen/murmur
[0175] PHP: https://github.com/lastguest/murmurhash-php
[0176] Java: https ://github. com/yonik/java_util/blob/master/src/util/hash/ MurmurHash3. java
[0177] hash64可以直接取hashl28低64位即可
[0178] 注意:上述3個版本都未經過測試,使用時注意甄別
[0179] Reduce 階段輸出:
[0180] 字段名,分詞的 Hashld,分詞 Token,DocIdl,DocId2,DocId3,DocId4,··.
[0181 ] 輸出路徑:/home/cl oud/datamining/src/ycs/posei don/index-reduce-output/ YYYYMMDD
[0182] 例如:/home/cloud/datamining/ src/ycs/poseidon/index_reduce_output/ 20160205
[0183] 第二階段:生成 InvertedlndexGzHDFSFile
[0184] 每個需要索引的字段生成一個獨立的InvertedlndexGzHDFSFi le文件
[0185] 每個 InvertedlndexGzHDFSFile 文件由很多個 InvertedlndexGz 二進制數據
[0186] 文件路徑如下:/]101116/。1〇11(1/(1&七&111;!_11;!_耶/81'。/:7。8/卩0 861(1〇11/;!_11(161/字段名/ YYYYMMDD.gz
[0187] 例如mid字段的倒排索引文件路徑為:/home/cloud/datamining/src/ycs/ poseidon/index/mid/20160205.gz
[0188] 例如md5字段的倒排索引文件路徑為:/home/cloud/datamining/src/ycs/ poseidon/index/md5/20160205.gz
[0189] 例如包ext字段里面的hi.DURL字段的倒排索引文件路徑為:/h〇me/ Cl〇ud/ datamining/src/ycs/poseidon/index/ext.hi.DURL/20160205.gz
[0190] 例如行ext字段里面的xx字段的倒排索引文件路徑為:/home/cloud/datamining/ src/ycs/poseidon/index/row_ext.xx/20160205.gz [0191 ] InvertedlndexGz 算法,N先暫定取值為200:
[0192] hashid在[0,N)之間的組合為一個 InvertedlndexGz
[0193] hashid在[N,2N)之間的組合為一個 InvertedlndexGz
[0194] hashid 在[2N,3N)之間的組合為一個 InvertedlndexGz
[0195] 依次類推
[0196] Token關聯的docid應該有一個最大值,以防數據集太大導致查詢性能急劇下降。 這個數暫定為1〇〇〇萬如果某個token關聯的docid數大于這個數,也只取1000萬。
[0197] 每個docid預計占用3字節,1000萬就是30MB
[0198] InvertedlndexGzMetaHDFSFile
[0199] 該文件是存儲InvertedlndexGzHDFSFile文件的me ta信息
[0200] 每一個InvertedlndexGz 對應 me ta 信息包含:hdfspath、hashid、offset、length, 數據存儲格式為:
[0201 ]起始行是 InvertedlndexGzHDFSFile 文件路徑
[0202] 后面每一行都分三列,以\t分割,分別如下
[0203] hashid以N取整,也就是上面的區間hashid區間中的最開始一個數字,例如[2N, 3N)應該取2N
[0204] offset
[0207]
[0205] lenght[0206] 舉例如下
[0208]
[0209] 這個數據最終會存放到NoSQL中,例如bada或pika或quakedb等等帶有表空間和持 久化特性的kvdb中
[0210]寫一個MR程序直接讀取這個數據這個數據就可以寫kvdb 了
[0211] 表空間命名:/業務名/索引名,例如:/ycs/mid
[0212] key 是 hashid&P#l整的數據
[0213] value是InvertedlndexGz
[0214] value 中的 Invertedlndex結構只要off set、length 這兩個字段即可,hdfspath、 hashid這兩個字段可以根據規則推算出來。
[0215] 基于同一發明構思,本發明實施例還提供了一種大數據的搜索方法,需要說明的 是,該搜索方法基于的數據存儲系統應是使用了上文所述的大數據的存儲方法的數據存儲 系統。圖2示出了根據本發明一個實施例的大數據的搜索方法的處理流程圖。參見圖2,大數 據的搜索方法至少包括:
[0216] 步驟S202、對搜索詞進行分詞,得到多個分詞;
[0217] 步驟S204、利用各分詞到使用了大數據的存儲方法的數據存儲系統中進行匹配, 得到匹配結果,其中,數據存儲系統中包括多個文件,各文件中包括多個文檔,每個文檔與 分詞間具備映射關系;
[0218] 步驟S206、根據匹配結果查找到對應的文檔,并從文檔中再次匹配到對應的原始 日志。
[0219] 在本發明實施例中,因采用了上文所述的大數據的存儲方法的數據存儲系統,數 據存儲利用了分詞與文檔間的映射關系,并將多個原始日志聚合成分詞,這使得數據存儲 的數量級大大下降,也使得搜索詞分詞所得到的各分詞的搜索過程簡單快捷化,分詞無須 依次與各原始日志進行匹配,而是分別匹配數據存儲系統中的分詞,數據存儲系統中的分 詞數據比之原始日志的數量級大大降低,縮短了匹配時間。若匹配上,則進一步在文檔中針 對多條原始日志進行二次匹配即可,匹配操作所需數據級大大下降,那么針對大數據的搜 索方法的搜索時間也必然大大下降,大大提高了搜索效率以及用戶的感受體驗,對于搜索 引擎而言,能夠增加用戶粘性。
[0220] 前文提及,數據存儲時采用了倒排索引結構的方式,相應的,在搜索過程中,也必 然利用倒排索引結構的方式,利用各分詞到使用了大數據的存儲方法的數據存儲系統中進 行匹配。
[0221] 基于同一發明構思,本發明實施例還提供了一種大數據的存儲裝置。圖3示出了根 據本發明一個實施例的大數據的存儲裝置的結構示意圖。參見圖3,大數據的存儲裝置至少 包括:
[0222] 日志分析模塊310,適于獲取大數據的原始日志并分析其具體日志內容;
[0223] 文檔生成模塊320,與日志分析模塊310耦合,適于根據具體日志內容對原始日志 進行分類,將指定數目的原始日志集合生成一個文檔,并為該文檔建立與分詞間的映射關 系,其中,分詞與該文檔的具體日志內容相匹配;
[0224]文件生成模塊330,與文檔生成模塊320耦合,適于對各文檔進行組合處理以生成 組合的文件,其中,該文件被搜索時,能夠提供與組合文檔數目相對應的多個分詞;
[0225] 存儲模塊340,與文件生成模塊330耦合,適于利用文件替代原始日志存入到分布 式存儲系統架構中。
[0226] 在一個優選的實施例中,文件生成模塊330還適于:
[0227] 對各文檔進行文檔壓縮處理,得到壓縮后的壓縮文檔;
[0228] 對各壓縮文檔進行組合處理,得到組合的文件。
[0229] 在一個優選的實施例中,壓縮文檔格式為gz文件。
[0230] 在一個優選的實施例中,指定數目的原始日志為128條原始日志,組合的文件為 256M-2G之間。
[0231 ]在一個優選的實施例中,存儲模塊340還適于:
[0232] 利用文件中第一個分詞的起始位置作為參考位置,記錄各分詞在文件中的偏移位 置;
[0233] 將各分詞在文件中的偏移位置信息以及文件均存入分布式存儲系統架構中。
[0234] 基于同一發明構思,本發明實施例還提供了一種大數據的搜索裝置,與圖3所示的 大數據的存儲裝置耦合。圖4示出了根據本發明一個實施例的大數據的搜索裝置的結構示 意圖。參見圖4,大數據的搜索裝置至少包括:
[0235] 分詞模塊410,適于對搜索詞進行分詞,得到多個分詞;
[0236]第一匹配模塊420,與分詞模塊410耦合,適于利用各分詞到使用了大數據的存儲 裝置的數據存儲系統中進行匹配,得到匹配結果,其中,數據存儲系統中包括多個文件,各 文件中包括多個文檔,每個文檔與分詞間具備映射關系;
[0237] 第二匹配模塊430,與第一匹配模塊420耦合,適于根據匹配結果查找到對應的文 檔,并從文檔中再次匹配到對應的原始日志。
[0238] 在一個優選的實施例中,第一匹配模塊420還適于:
[0239] 利用倒排索引結構的方式,利用各分詞到使用了大數據的存儲裝置的數據存儲系 統中進行匹配。
[0240] 在本發明實施例中,對于原始日志的存儲方式進行了改進,因單條原始日志非常 小,通常只有幾 K或者幾十K,若大量原始日志直接存儲,則會形成大量的存儲碎片,且每次 存儲均要為該原始日志生成對應的索引,浪費大量存儲資源,因此,本發明實施例將指定數 目的原始日志集合合并生成一個文檔。其中,文檔中所包含哪些原始日志由具體日志內容 所決定,這樣就能夠讓具備相似日志內容的原始日志歸納至一個文檔中。進一步,本發明實 施例還根據文檔所對應的具體日志內容生成可用于進行搜索或索引操作的分詞,分詞與具 體的文檔間形成映射關系,以便后期搜索時,能夠利用搜索詞的分詞與文檔的分詞直接匹 配。隨后,本發明實施例還對各文檔再次進行組合處理,生成組合的文件,進而利用文件替 代原始日志存儲到分布式存儲系統架構中。由此可以看出,本發明實施例中,將原始日志進 行了集中合成,生成具備一定規模和容量的文件,并對文件進行統一的存儲管理,文件的容 量要遠遠超過原始日志的大小,對于分布式存儲系統架構而言,文件的管理僅需要設置文 件的索引,而不需要設置每條原始日志的索引,大大降低了數據的冗余性,從而減少了對服 務器資源的浪費,提高存儲資源的利用率。采用本發明實施例所提供的大數據的存儲方法, 因能夠達到減少資源浪費的目的,適用于任何大數據的存儲過程,甚至于百萬級別、百萬億 級、千萬億級的大數據的存儲。
[0241] 在本發明實施例中,因采用了上文所述的大數據的存儲方法的數據存儲系統,數 據存儲利用了分詞與文檔間的映射關系,并將多個原始日志聚合成分詞,這使得數據存儲 的數量級大大下降,也使得搜索詞分詞所得到的各分詞的搜索過程簡單快捷化,分詞無須 依次與各原始日志進行匹配,而是分別匹配數據存儲系統中的分詞,數據存儲系統中的分 詞數據比之原始日志的數量級大大降低,縮短了匹配時間。若匹配上,則進一步在文檔中針 對多條原始日志進行二次匹配即可,匹配操作所需數據級大大下降,那么針對大數據的搜 索方法的搜索時間也必然大大下降,大大提高了搜索效率以及用戶的感受體驗,對于搜索 引擎而言,能夠增加用戶粘性。
[0242] 在此處所提供的說明書中,說明了大量具體細節。然而,能夠理解,本發明的實施 例可以在沒有這些具體細節的情況下實踐。在一些實例中,并未詳細示出公知的方法、結構 和技術,以便不模糊對本說明書的理解。
[0243]類似地,應當理解,為了精簡本公開并幫助理解各個發明方面中的一個或多個,在 上面對本發明的示例性實施例的描述中,本發明的各個特征有時被一起分組到單個實施 例、圖、或者對其的描述中。然而,并不應將該公開的方法解釋成反映如下意圖:即所要求保 護的本發明要求比在每個權利要求中所明確記載的特征更多的特征。更確切地說,如下面 的權利要求書所反映的那樣,發明方面在于少于前面公開的單個實施例的所有特征。因此, 遵循【具體實施方式】的權利要求書由此明確地并入該【具體實施方式】,其中每個權利要求本身 都作為本發明的單獨實施例。
[0244]本領域那些技術人員可以理解,可以對實施例中的設備中的模塊進行自適應性地 改變并且把它們設置在與該實施例不同的一個或多個設備中。可以把實施例中的模塊或單 元或組件組合成一個模塊或單元或組件,以及此外可以把它們分成多個子模塊或子單元或 子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外,可以采用任何 組合對本說明書(包括伴隨的權利要求、摘要和附圖)中公開的所有特征以及如此公開的任 何方法或者設備的所有過程或單元進行組合。除非另外明確陳述,本說明書(包括伴隨的權 利要求、摘要和附圖)中公開的每個特征可以由提供相同、等同或相似目的的替代特征來代 替。
[0245] 此外,本領域的技術人員能夠理解,盡管在此所述的一些實施例包括其它實施例 中所包括的某些特征而不是其它特征,但是不同實施例的特征的組合意味著處于本發明的 范圍之內并且形成不同的實施例。例如,在權利要求書中,所要求保護的實施例的任意之一 都可以以任意的組合方式來使用。
[0246] 本發明的各個部件實施例可以以硬件實現,或者以在一個或者多個處理器上運行 的軟件模塊實現,或者以它們的組合實現。本領域的技術人員應當理解,可以在實踐中使用 微處理器或者數字信號處理器(DSP)來實現根據本發明實施例的設備中的一些或者全部部 件的一些或者全部功能。本發明還可以實現為用于執行這里所描述的方法的一部分或者全 部的設備或者裝置程序(例如,計算機程序和計算機程序產品)。這樣的實現本發明的程序 可以存儲在計算機可讀介質上,或者可以具有一個或者多個信號的形式。這樣的信號可以 從因特網網站上下載得到,或者在載體信號上提供,或者以任何其他形式提供。
[0247] 應該注意的是上述實施例對本發明進行說明而不是對本發明進行限制,并且本領 域技術人員在不脫離所附權利要求的范圍的情況下可設計出替換實施例。在權利要求中, 不應將位于括號之間的任何參考符號構造成對權利要求的限制。單詞"包含"不排除存在未 列在權利要求中的元件或步驟。位于元件之前的單詞"一"或"一個"不排除存在多個這樣的 元件。本發明可以借助于包括有若干不同元件的硬件以及借助于適當編程的計算機來實 現。在列舉了若干裝置的單元權利要求中,這些裝置中的若干個可以是通過同一個硬件項 來具體體現。單詞第一、第二、以及第三等的使用不表示任何順序。可將這些單詞解釋為名 稱。
[0248] 至此,本領域技術人員應認識到,雖然本文已詳盡示出和描述了本發明的多個示 例性實施例,但是,在不脫離本發明精神和范圍的情況下,仍可根據本發明公開的內容直接 確定或推導出符合本發明原理的許多其他變型或修改。因此,本發明的范圍應被理解和認 定為覆蓋了所有這些其他變型或修改。
[0249] 根據本發明的一個方面,本發明公開了 A1、一種大數據的存儲方法,包括:
[0250] 獲取大數據的原始日志并分析其具體日志內容;
[0251 ]根據所述具體日志內容對所述原始日志進行分類,將指定數目的原始日志集合生 成一個文檔,并為該文檔建立與分詞間的映射關系,其中,所述分詞與該文檔的具體日志內 容相匹配;
[0252] 對各文檔進行組合處理以生成組合的文件,其中,該文件被搜索時,能夠提供與組 合文檔數目相對應的多個分詞;
[0253] 利用所述文件替代所述原始日志存入到分布式存儲系統架構中。
[0254] A2、根據權利要求A1所述的方法,其中,對各文檔進行組合處理以生成組合的文 件,包括:
[0255] 對各文檔進行文檔壓縮處理,得到壓縮后的壓縮文檔;
[0256] 對各壓縮文檔進行組合處理,得到組合的文件。
[0257] A3、根據權利要求A2所述的方法,其中,所述壓縮文檔格式為gz文件。
[0258] A4、根據權利要求A2所述的方法,其中,所述指定數目的原始日志為128條原始日 志,所述組合的文件為256M~2G之間。
[0259] A5、根據權利要求A1-A4任一項所述的方法,其中,利用所述文件替代所述原始日 志存入到分布式存儲系統架構中,包括:
[0260] 利用所述文件中第一個分詞的起始位置作為參考位置,記錄各分詞在所述文件中 的偏移位置;
[0261] 將各分詞在所述文件中的偏移位置信息以及所述文件均存入所述分布式存儲系 統架構中。
[0262] A6、根據權利要求A1-A5任一項所述的方法,其中,所述大數據為百萬級別以上的 數據。
[0263] 根據本發明的另一個方面,本發明還公開了 B7、一種大數據的搜索方法,應用于使 用所述權利要求A1-A6任一項所述的大數據的存儲方法的數據存儲系統,所述方法包括:
[0264] 對搜索詞進行分詞,得到多個分詞;
[0265] 利用各分詞到所述使用了大數據的存儲方法的數據存儲系統中進行匹配,得到匹 配結果,其中,所述數據存儲系統中包括多個文件,各文件中包括多個文檔,每個文檔與分 詞間具備映射關系;
[0266] 根據所述匹配結果查找到對應的文檔,并從所述文檔中再次匹配到對應的原始日 ν·、ι、〇
[0267] B8、根據權利要求B7所述的方法,其中,利用各分詞到所述使用了大數據的存儲方 法的數據存儲系統中進行匹配,包括:
[0268] 利用倒排索引結構的方式,利用各分詞到所述使用了大數據的存儲方法的數據存 儲系統中進行匹配。
[0269] B9、根據權利要求B7或B8所述的方法,其中,所述大數據為百萬級別以上的數據。
[0270]根據本發明的又一個方面,本發明還公開了 C10、一種大數據的存儲裝置,包括: [0271 ]日志分析模塊,適于獲取大數據的原始日志并分析其具體日志內容;
[0272] 文檔生成模塊,適于根據所述具體日志內容對所述原始日志進行分類,將指定數 目的原始日志集合生成一個文檔,并為該文檔建立與分詞間的映射關系,其中,所述分詞與 該文檔的具體日志內容相匹配;
[0273] 文件生成模塊,適于對各文檔進行組合處理以生成組合的文件,其中,該文件被搜 索時,能夠提供與組合文檔數目相對應的多個分詞;
[0274] 存儲模塊,適于利用所述文件替代所述原始日志存入到分布式存儲系統架構中。
[0275] C11、根據權利要求C10所述的裝置,其中,所述文件生成模塊還適于:
[0276] 對各文檔進行文檔壓縮處理,得到壓縮后的壓縮文檔;
[0277] 對各壓縮文檔進行組合處理,得到組合的文件。
[0278] C12、根據權利要求C11所述的裝置,其中,所述壓縮文檔格式為gz文件。
[0279] C13、根據權利要求C11所述的裝置,其中,所述指定數目的原始日志為128條原始 日志,所述組合的文件為256M~2G。
[0280] C14、根據權利要求C10-C13任一項所述的裝置,其中,所述存儲模塊還適于:
[0281] 利用所述文件中第一個分詞的起始位置作為參考位置,記錄各分詞在所述文件中 的偏移位置;
[0282] 將各分詞在所述文件中的偏移位置信息以及所述文件均存入所述分布式存儲系 統架構中。
[0283] C15、根據權利要求C10-C14任一項所述的裝置,其中,所述大數據為百萬級別以上 的數據。
[0284] 根據本發明的再一個方面,本發明還公開了 D16、一種大數據的搜索裝置,與所述 權利要求C10-C15任一項所述的大數據的存儲裝置耦合,所述裝置包括:
[0285] 分詞模塊,適于對搜索詞進行分詞,得到多個分詞;
[0286] 第一匹配模塊,適于利用各分詞到所述使用了大數據的存儲裝置的數據存儲系統 中進行匹配,得到匹配結果,其中,所述數據存儲系統中包括多個文件,各文件中包括多個 文檔,每個文檔與分詞間具備映射關系;
[0287] 第二匹配模塊,適于根據所述匹配結果查找到對應的文檔,并從所述文檔中再次 匹配到對應的原始日志。
[0288] D17、根據權利要求D16所述的裝置,其中,所述第一匹配模塊還適于:
[0289] 利用倒排索引結構的方式,利用各分詞到所述使用了大數據的存儲裝置的數據存 儲系統中進行匹配。
[0290] D18、根據權利要求D16或D17所述的裝置,其中,所述大數據為百萬級別以上的數 據。
【主權項】
1. 一種大數據的存儲方法,包括: 獲取大數據的原始日志并分析其具體日志內容; 根據所述具體日志內容對所述原始日志進行分類,將指定數目的原始日志集合生成一 個文檔,并為該文檔建立與分詞間的映射關系,其中,所述分詞與該文檔的具體日志內容相 匹配; 對各文檔進行組合處理以生成組合的文件,其中,該文件被搜索時,能夠提供與組合文 檔數目相對應的多個分詞; 利用所述文件替代所述原始日志存入到分布式存儲系統架構中。2. 根據權利要求1所述的方法,其中,對各文檔進行組合處理以生成組合的文件,包括: 對各文檔進行文檔壓縮處理,得到壓縮后的壓縮文檔; 對各壓縮文檔進行組合處理,得到組合的文件。3. 根據權利要求2所述的方法,其中,所述壓縮文檔格式為gz文件。4. 根據權利要求2所述的方法,其中,所述指定數目的原始日志為128條原始日志,所述 組合的文件為256M~2G之間。5. 根據權利要求1-4任一項所述的方法,其中,利用所述文件替代所述原始日志存入到 分布式存儲系統架構中,包括: 利用所述文件中第一個分詞的起始位置作為參考位置,記錄各分詞在所述文件中的偏 移位置; 將各分詞在所述文件中的偏移位置信息以及所述文件均存入所述分布式存儲系統架 構中。6. 根據權利要求1-5任一項所述的方法,其中,所述大數據為百萬級別以上的數據。7. -種大數據的搜索方法,應用于使用所述權利要求1-6任一項所述的大數據的存儲 方法的數據存儲系統,所述方法包括: 對搜索詞進行分詞,得到多個分詞; 利用各分詞到所述使用了大數據的存儲方法的數據存儲系統中進行匹配,得到匹配結 果,其中,所述數據存儲系統中包括多個文件,各文件中包括多個文檔,每個文檔與分詞間 具備映射關系; 根據所述匹配結果查找到對應的文檔,并從所述文檔中再次匹配到對應的原始日志。8. 根據權利要求7所述的方法,其中,利用各分詞到所述使用了大數據的存儲方法的數 據存儲系統中進行匹配,包括: 利用倒排索引結構的方式,利用各分詞到所述使用了大數據的存儲方法的數據存儲系 統中進行匹配。9. 一種大數據的存儲裝置,包括: 日志分析模塊,適于獲取大數據的原始日志并分析其具體日志內容; 文檔生成模塊,適于根據所述具體日志內容對所述原始日志進行分類,將指定數目的 原始日志集合生成一個文檔,并為該文檔建立與分詞間的映射關系,其中,所述分詞與該文 檔的具體日志內容相匹配; 文件生成模塊,適于對各文檔進行組合處理以生成組合的文件,其中,該文件被搜索 時,能夠提供與組合文檔數目相對應的多個分詞; 存儲模塊,適于利用所述文件替代所述原始日志存入到分布式存儲系統架構中。10. -種大數據的搜索裝置,與所述權利要求9所述的大數據的存儲裝置耦合,所述裝 置包括: 分詞模塊,適于對搜索詞進行分詞,得到多個分詞; 第一匹配模塊,適于利用各分詞到所述使用了大數據的存儲裝置的數據存儲系統中進 行匹配,得到匹配結果,其中,所述數據存儲系統中包括多個文件,各文件中包括多個文檔, 每個文檔與分詞間具備映射關系; 第二匹配模塊,適于根據所述匹配結果查找到對應的文檔,并從所述文檔中再次匹配 到對應的原始日志。
【文檔編號】G06F17/30GK105975495SQ201610266871
【公開日】2016年9月28日
【申請日】2016年4月26日
【發明人】魏自立, 李 浩, 穆玉偉, 趙晶晶, 蔣東, 馮鑫
【申請人】北京奇虎科技有限公司, 奇智軟件(北京)有限公司