本發(fā)明屬于互聯(lián)網(wǎng)
技術(shù)領(lǐng)域：
：，尤其涉及一種indexr實(shí)時(shí)數(shù)據(jù)分析庫(kù)。
背景技術(shù)：
：：程序化廣告業(yè)務(wù)需要對(duì)接全網(wǎng)的各大媒體，每秒產(chǎn)生上百萬(wàn)的分析數(shù)據(jù)。這些數(shù)據(jù)對(duì)廣告投放活動(dòng)的過(guò)程進(jìn)行了精細(xì)的追蹤和描述，比如創(chuàng)意的展示量、點(diǎn)擊量，活動(dòng)產(chǎn)生的注冊(cè)數(shù)、回訪數(shù)等。我們需要對(duì)這些數(shù)據(jù)進(jìn)行實(shí)時(shí)分析處理，用于包括客戶報(bào)告，投放優(yōu)化，欺詐分析，收費(fèi)結(jié)算等。數(shù)據(jù)使用者的查詢模式是非固定的，無(wú)法預(yù)測(cè)的，并且隨著業(yè)務(wù)量的激增，數(shù)據(jù)量也急劇增長(zhǎng)。我們需要一種新的技術(shù)來(lái)解決這些需求：1、超大數(shù)據(jù)集，低查詢延時(shí)：查詢模式無(wú)法預(yù)測(cè)，無(wú)法預(yù)計(jì)算；表數(shù)據(jù)量普遍超過(guò)1億，甚至上百億千億，過(guò)濾條件有可能會(huì)命中大量數(shù)據(jù)；數(shù)據(jù)在查詢的同時(shí)還會(huì)有大量的更新，每秒入庫(kù)幾萬(wàn)的數(shù)據(jù)。要保證較低的查詢延時(shí)，一般情況下查詢延時(shí)要求在5s以內(nèi)，常用高頻查詢要求1s以內(nèi)。2、準(zhǔn)實(shí)時(shí)：數(shù)據(jù)從產(chǎn)生到體現(xiàn)在分析結(jié)果延時(shí)幾秒以內(nèi)。時(shí)效性對(duì)于某些業(yè)務(wù)至關(guān)重要，并且越實(shí)時(shí)的數(shù)據(jù)，價(jià)值越大。3、可靠性，一致性，高可用：這些數(shù)據(jù)是公司最重要的數(shù)據(jù)之一，任何錯(cuò)誤和不一致可能會(huì)直接體現(xiàn)在客戶報(bào)表中，對(duì)公司的業(yè)務(wù)和品牌形象產(chǎn)生影響，至關(guān)重要。4、可擴(kuò)展，低成本，易維護(hù)：業(yè)務(wù)會(huì)快速發(fā)展，會(huì)產(chǎn)生新的數(shù)據(jù)源，加入新的表，舊的數(shù)據(jù)不能刪除，這帶來(lái)巨大的成本壓力，和運(yùn)維壓力。典型的更新如加列、列值更新等操作不能影響線上服務(wù)，不能帶來(lái)入庫(kù)或者查詢延遲。5、sql支持：全面支持sql，要像mysql一樣好用，功能強(qiáng)大。不僅僅支持常見(jiàn)的多維分析，還需要支持復(fù)雜的分析查詢，如join，子查詢等，支持自定義函數(shù)(udf，udfa)。6、與hadoop生態(tài)整合：hadoop生態(tài)的蓬勃發(fā)展給大數(shù)據(jù)處理帶來(lái)越來(lái)越強(qiáng)的處理能力，如果能與它的工具鏈深度結(jié)合，會(huì)極大擴(kuò)展系統(tǒng)的價(jià)值。7、多維分析、ad-hoc查詢：大部分的查詢結(jié)果是基于一個(gè)或多個(gè)維度組合的匯總，并且要求短時(shí)間內(nèi)響應(yīng)，最好全面支持sql和udf。目前提供相似功能的產(chǎn)品，有些通過(guò)使用傳統(tǒng)的關(guān)系型數(shù)據(jù)技術(shù)，或者通過(guò)預(yù)先建cube加速查詢。這些方式可能會(huì)帶來(lái)一些問(wèn)題，比如運(yùn)維困難，數(shù)據(jù)量瓶頸，或者模式不夠靈活，無(wú)法支持業(yè)務(wù)變化。有些方案使用內(nèi)存存儲(chǔ)技術(shù)，使用上成本比較高，而且在大數(shù)據(jù)分析場(chǎng)景并無(wú)特別大的速度優(yōu)勢(shì)。近年出現(xiàn)的一些時(shí)序數(shù)據(jù)庫(kù)，解決了一些入庫(kù)延遲方面的問(wèn)題，但是在查詢性能，可用性，可擴(kuò)展性等方面存在一些問(wèn)題?，F(xiàn)有的技術(shù)解決方案如mysql，postgresql等關(guān)系型數(shù)據(jù)庫(kù)，它們一般都有非常完整的功能支持，但無(wú)法支持超大量數(shù)據(jù)，統(tǒng)計(jì)分析的性能也不好，一般作為t+1架構(gòu)的實(shí)時(shí)庫(kù)。hbase，或者redis等k-v數(shù)據(jù)庫(kù)，上層一般有一個(gè)sql查詢層，比如phoenix，上游由spark、storm等流式框架預(yù)聚合數(shù)據(jù)。這類架構(gòu)限制非常多，很難支持復(fù)雜及頻繁修改的業(yè)務(wù)。kylin也屬于這一類，離線預(yù)聚合。infobright，greenplum，memsql等各有特點(diǎn)的數(shù)據(jù)庫(kù)，有開(kāi)源社區(qū)版本。在一定條件、數(shù)據(jù)量下能滿足特定需求，但是缺點(diǎn)較多，有些不支持更新，或者運(yùn)維困難，數(shù)據(jù)量支持小等。hana,vertica，以及云服務(wù)等收費(fèi)數(shù)據(jù)庫(kù)。我們沒(méi)有選擇這個(gè)方向，認(rèn)為把分析系統(tǒng)構(gòu)建在這類第三方封閉系統(tǒng)上，與目前現(xiàn)有數(shù)據(jù)工具的整合相對(duì)困難，擔(dān)心對(duì)后續(xù)擴(kuò)展、遷移的影響。最近幾年較火的所謂時(shí)間序列數(shù)據(jù)庫(kù)，代表為druid，pinot，influxdb等。筆者曾經(jīng)比較深入的研究過(guò)，甚至在項(xiàng)目中有過(guò)部署，但最終認(rèn)為都不適合。有些項(xiàng)目并不成熟，或者對(duì)硬件要求極高，缺少?gòu)椥?，有些架?gòu)上有比較大的問(wèn)題，實(shí)際應(yīng)用時(shí)表現(xiàn)的非常不穩(wěn)定。其他開(kāi)源分析工具，如impala，drill，或者sparksql。它們一般專注于計(jì)算層，缺少一個(gè)合適的數(shù)據(jù)格式，并且它們通常是分析靜態(tài)文件的，沒(méi)法做到分析實(shí)時(shí)數(shù)據(jù)。目前的arquet，orc等數(shù)據(jù)格式通常有不錯(cuò)的掃描、壓縮性能，但缺少有效的索引和必要的靈活性。技術(shù)實(shí)現(xiàn)要素：本發(fā)明的目的在于提供一種indexr實(shí)時(shí)數(shù)據(jù)分析庫(kù)，以解決上述
背景技術(shù)：
：中提出的問(wèn)題。本發(fā)明的目的是通過(guò)下述技術(shù)方案予以實(shí)現(xiàn)：一種indexr實(shí)時(shí)數(shù)據(jù)分析庫(kù),包括：系統(tǒng)構(gòu)架、部署架構(gòu)、存儲(chǔ)結(jié)構(gòu)和實(shí)時(shí)模塊；所述系統(tǒng)構(gòu)架負(fù)責(zé)文件存儲(chǔ)格式，包括索引和數(shù)據(jù)，數(shù)據(jù)的實(shí)時(shí)導(dǎo)入、表定義操作，查詢優(yōu)化，以及數(shù)據(jù)緩存等。分布式計(jì)算框架(drill/spark)負(fù)責(zé)在indexr數(shù)據(jù)上的具體查詢操作，以及其他計(jì)算任務(wù)，hadoop以及周邊工具-提供分布式文件存儲(chǔ)，離線批量計(jì)算，離線數(shù)據(jù)管理，以及各種離線etl任務(wù)，indexr與hadoop完美結(jié)合，可以作為一個(gè)高度壓縮、自帶索引的文件格式，兼容hive的所有操作，kafka-消息隊(duì)列，數(shù)據(jù)經(jīng)過(guò)kafka流入indexr，zookeeper-集群狀態(tài)管理；所述部署架構(gòu)在hadoop系統(tǒng)的環(huán)境下，在現(xiàn)有集群上部署indexr通常可以在半小時(shí)之內(nèi)完成，只需要在所有hadoop的datanode(和namenode)節(jié)點(diǎn)上部署一份帶有indexr插件的drill節(jié)點(diǎn)，只有幾項(xiàng)必須配置項(xiàng)，并且所有節(jié)點(diǎn)的配置都是一樣的，indexr的服務(wù)邏輯嵌入了drillbit進(jìn)程，無(wú)需額外啟動(dòng)服務(wù)；所述存儲(chǔ)結(jié)構(gòu)以列式存儲(chǔ)數(shù)據(jù)，并分片存儲(chǔ)，分片稱為segment，每一個(gè)segment都是自解釋的，包括schema，數(shù)據(jù)以及索引，segment通常是固定不變的，這極大簡(jiǎn)化了數(shù)據(jù)管理，便于分布式處理；所述實(shí)時(shí)模塊可以極高效率的導(dǎo)入實(shí)時(shí)數(shù)據(jù)，并且數(shù)據(jù)可以立刻被查詢，可以多節(jié)點(diǎn)同時(shí)導(dǎo)入，實(shí)時(shí)導(dǎo)入的數(shù)據(jù)叫做realtimesegment，在達(dá)到一定閥值后，indexr會(huì)將它們合并成歷史segment，并上傳到hdfs，之后數(shù)據(jù)就可以被離線分析工具所使用和管理，realtimesegment具體實(shí)現(xiàn)參考了lsm-tree，通過(guò)在磁盤上的commitlog文件保存所有更新操作，最新數(shù)據(jù)放在內(nèi)存中以快速入庫(kù)和索引，周期性將內(nèi)存數(shù)據(jù)dump到磁盤，indexr進(jìn)程可以隨時(shí)被重啟，或者直接殺死，不用擔(dān)心數(shù)據(jù)丟失；進(jìn)一步的，所述indexr實(shí)時(shí)數(shù)據(jù)分析庫(kù)的測(cè)試硬件標(biāo)準(zhǔn)包括以下部分：1)每個(gè)節(jié)點(diǎn)12核(24線程)cpu,60g內(nèi)存,sata接口7200轉(zhuǎn)機(jī)械硬盤，2)實(shí)時(shí)導(dǎo)入速度：超過(guò)30k消息/秒/節(jié)點(diǎn)/表，即，假如有10個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)擁有10個(gè)表，可以在一秒鐘之內(nèi)消費(fèi)3m條消息，一天輕松實(shí)時(shí)導(dǎo)入千億數(shù)據(jù)，3)掃描速度：通常一行內(nèi)通常會(huì)讀取多個(gè)字段，在現(xiàn)代cpu和計(jì)算框架的幫助下，可以同時(shí)對(duì)多個(gè)字段進(jìn)行運(yùn)算，從而獲得比以下數(shù)據(jù)更好的性能，4)冷數(shù)據(jù)-30m字段/秒/節(jié)點(diǎn)，5)熱數(shù)據(jù)-100m字段/秒/節(jié)點(diǎn)，6)掃描速度約為parquet的2.5倍，7)olap查詢：在我們的實(shí)際業(yè)務(wù)中，我們發(fā)現(xiàn)95％的查詢延時(shí)在3s內(nèi)，數(shù)據(jù)量規(guī)模為千億級(jí)別，20個(gè)節(jié)點(diǎn)，8)相同的drill環(huán)境下約為parquet格式的3～8倍，9)壓縮率：在我們的實(shí)際業(yè)務(wù)中，相對(duì)于csv格式，壓縮率約為10:1，有些表甚至達(dá)到20:1，10)壓縮后大小約為orc格式的75％。本發(fā)明的有益效果是：1、快速統(tǒng)計(jì)分析查詢：indexr使用列式存儲(chǔ)，對(duì)于超大量數(shù)據(jù)集，它提供高效的索引，通過(guò)過(guò)濾掉無(wú)關(guān)數(shù)據(jù)，快速定位有效數(shù)據(jù)，減少io。它使用了優(yōu)秀的apachdrill作為上層查詢引擎。特別適合于ad-hoc的olap查詢。2、數(shù)據(jù)實(shí)時(shí)導(dǎo)入：indexr支持超高速實(shí)時(shí)導(dǎo)入數(shù)據(jù)。數(shù)據(jù)一到達(dá)indexr節(jié)點(diǎn)，立刻可以被查詢到。實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)可以一起查，再也不需要考慮所謂t+1架構(gòu)。且區(qū)分于其他有類似功能的系統(tǒng)，indexr永遠(yuǎn)不會(huì)主動(dòng)丟棄任何數(shù)據(jù)。3、高效硬件利用率：相較于其他系統(tǒng)，indexr可以跑在廉價(jià)的機(jī)器上。不需要昂貴的ssd硬盤，高端cpu，甚至小型機(jī)，你就可以獲得非常好的性能，雖然在上面跑會(huì)更加快。雖然跑在jvm上，它手動(dòng)管理幾乎所有的內(nèi)存，使用經(jīng)過(guò)高度設(shè)計(jì)、緊湊的數(shù)據(jù)結(jié)構(gòu)。4、集群高可用，易擴(kuò)展，易管理，簡(jiǎn)單：分布式系統(tǒng)發(fā)展到現(xiàn)在，高可用和擴(kuò)展性已經(jīng)是標(biāo)配了。indexr的特點(diǎn)是結(jié)構(gòu)非常簡(jiǎn)單可靠，且只有極少的必須配置項(xiàng)。5、與hadoop生態(tài)的深度整合：indexr把數(shù)據(jù)存放于hdfs。這意味著你可以使用mapreduce，或者任何hadoop工具處理這些文件。我們目前提供了hive插件，用于各種etl相關(guān)工作，或者跑離線任務(wù)。對(duì)接spark的工作正在進(jìn)行，將被使用于數(shù)據(jù)挖掘以及機(jī)器學(xué)習(xí)。6、高度壓縮的數(shù)據(jù)格式：indexr以列式存儲(chǔ)，并提供超高的壓縮率，可以顯著的減少io以及網(wǎng)絡(luò)開(kāi)銷。7、方便的數(shù)據(jù)管理：indexr可以方便的導(dǎo)入、刪除數(shù)據(jù)，并且支持修改表schema，如對(duì)列的添加、刪除、修改等。具體實(shí)施方式具體實(shí)施例一種indexr實(shí)時(shí)數(shù)據(jù)分析庫(kù),包括：系統(tǒng)構(gòu)架、部署架構(gòu)、存儲(chǔ)結(jié)構(gòu)和實(shí)時(shí)模塊；所述系統(tǒng)構(gòu)架負(fù)責(zé)文件存儲(chǔ)格式，包括索引和數(shù)據(jù)，數(shù)據(jù)的實(shí)時(shí)導(dǎo)入、表定義操作，查詢優(yōu)化，以及數(shù)據(jù)緩存等。分布式計(jì)算框架(drill/spark)負(fù)責(zé)在indexr數(shù)據(jù)上的具體查詢操作，以及其他計(jì)算任務(wù)，hadoop以及周邊工具-提供分布式文件存儲(chǔ)，離線批量計(jì)算，離線數(shù)據(jù)管理，以及各種離線etl任務(wù)，indexr與hadoop完美結(jié)合，可以作為一個(gè)高度壓縮、自帶索引的文件格式，兼容hive的所有操作，kafka-消息隊(duì)列，數(shù)據(jù)經(jīng)過(guò)kafka流入indexr，zookeeper-集群狀態(tài)管理；所述部署架構(gòu)在hadoop系統(tǒng)的環(huán)境下，在現(xiàn)有集群上部署indexr通常可以在半小時(shí)之內(nèi)完成，只需要在所有hadoop的datanode(和namenode)節(jié)點(diǎn)上部署一份帶有indexr插件的drill節(jié)點(diǎn)，只有幾項(xiàng)必須配置項(xiàng)，并且所有節(jié)點(diǎn)的配置都是一樣的，indexr的服務(wù)邏輯嵌入了drillbit進(jìn)程，無(wú)需額外啟動(dòng)服務(wù)；所述存儲(chǔ)結(jié)構(gòu)以列式存儲(chǔ)數(shù)據(jù)，并分片存儲(chǔ)，分片稱為segment，每一個(gè)segment都是自解釋的，包括schema，數(shù)據(jù)以及索引，segment通常是固定不變的，這極大簡(jiǎn)化了數(shù)據(jù)管理，便于分布式處理；所述實(shí)時(shí)模塊可以極高效率的導(dǎo)入實(shí)時(shí)數(shù)據(jù)，并且數(shù)據(jù)可以立刻被查詢，可以多節(jié)點(diǎn)同時(shí)導(dǎo)入，實(shí)時(shí)導(dǎo)入的數(shù)據(jù)叫做realtimesegment，在達(dá)到一定閥值后，indexr會(huì)將它們合并成歷史segment，并上傳到hdfs，之后數(shù)據(jù)就可以被離線分析工具所使用和管理，realtimesegment具體實(shí)現(xiàn)參考了lsm-tree，通過(guò)在磁盤上的commitlog文件保存所有更新操作，最新數(shù)據(jù)放在內(nèi)存中以快速入庫(kù)和索引，周期性將內(nèi)存數(shù)據(jù)dump到磁盤，indexr進(jìn)程可以隨時(shí)被重啟，或者直接殺死，不用擔(dān)心數(shù)據(jù)丟失；所述indexr實(shí)時(shí)數(shù)據(jù)分析庫(kù)的測(cè)試硬件標(biāo)準(zhǔn)包括以下部分：1)每個(gè)節(jié)點(diǎn)12核(24線程)cpu,60g內(nèi)存,sata接口7200轉(zhuǎn)機(jī)械硬盤，2)實(shí)時(shí)導(dǎo)入速度：超過(guò)30k消息/秒/節(jié)點(diǎn)/表，即，假如有10個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)擁有10個(gè)表，可以在一秒鐘之內(nèi)消費(fèi)3m條消息，一天輕松實(shí)時(shí)導(dǎo)入千億數(shù)據(jù)，3)掃描速度：通常一行內(nèi)通常會(huì)讀取多個(gè)字段，在現(xiàn)代cpu和計(jì)算框架的幫助下，可以同時(shí)對(duì)多個(gè)字段進(jìn)行運(yùn)算，從而獲得比以下數(shù)據(jù)更好的性能，4)冷數(shù)據(jù)-30m字段/秒/節(jié)點(diǎn)，5)熱數(shù)據(jù)-100m字段/秒/節(jié)點(diǎn)，6)掃描速度約為parquet的2.5倍，7)olap查詢：在我們的實(shí)際業(yè)務(wù)中，我們發(fā)現(xiàn)95％的查詢延時(shí)在3s內(nèi)，數(shù)據(jù)量規(guī)模為千億級(jí)別，20個(gè)節(jié)點(diǎn)，8)相同的drill環(huán)境下約為parquet格式的3～8倍，9)壓縮率：在我們的實(shí)際業(yè)務(wù)中，相對(duì)于csv格式，壓縮率約為10:1，有些表甚至達(dá)到20:1，10)壓縮后大小約為orc格式的75％。indexr存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)，比如以下是一個(gè)虛構(gòu)的廣告投放用戶表tablea:columnnamedatatypedateintcontrystringcampaign_idlongimpressionslongclickslong數(shù)據(jù)文件稱為segment，一個(gè)segment保存一個(gè)表的部分行，包含所有的列。segment文件是自解釋的，它包含版本信息，完整的表定義，各個(gè)部分的元數(shù)據(jù)(offset)，以及索引。indexr默認(rèn)對(duì)所有的列進(jìn)行索引。行順序可以是入庫(kù)的自然順序，也可以是按照用戶定義的字段排序。這樣的設(shè)計(jì)可以簡(jiǎn)化系統(tǒng)架構(gòu)，不需要額外的元數(shù)據(jù)存儲(chǔ)，非常適合于分布式環(huán)境下的并行處理，也方便外部系統(tǒng)如hive直接使用。segment的行數(shù)據(jù)在內(nèi)部會(huì)進(jìn)一步細(xì)分為pack，每個(gè)pack都有獨(dú)立的索引。pack內(nèi)部的行數(shù)據(jù)是以列存儲(chǔ)的，即某一列的數(shù)據(jù)會(huì)集中存放在一起。這種方式對(duì)于列數(shù)據(jù)的快速遍歷，和壓縮帶來(lái)極大的優(yōu)勢(shì)。對(duì)于現(xiàn)代通用計(jì)算機(jī)架構(gòu)，cache友好，方便vectorprocess，充分發(fā)揮現(xiàn)代多核cpu的性能。segment的列數(shù)據(jù)使用特別優(yōu)化的壓縮算法，根據(jù)數(shù)據(jù)類型選擇不同的算法和參數(shù)，通常壓縮率10：1以上。在實(shí)際業(yè)務(wù)數(shù)據(jù)測(cè)試中，indexr每個(gè)節(jié)點(diǎn)每秒可以處理1億個(gè)字段。測(cè)試機(jī)器配置：[intel(r)xeon(r)cpue5-2620v2@2.10ghz]x2,60gram,sata7200rpmdisk。這個(gè)配置在目前服務(wù)器配置中算低端的，更強(qiáng)大的cpu會(huì)對(duì)indexr有非常大的性能提升。索引indexr采用粗糙集索引(roughsetindex)，它能以極低的成本，很高的精確度定位到相關(guān)文件和位置。比如我們的某一個(gè)數(shù)據(jù)塊(pack)有以下數(shù)據(jù)，有date(int類型)和use_name(string)類型。indexr對(duì)于number和string類型有不同的索引方式，這里描述基本的思路。對(duì)于number類型，會(huì)記錄該列的最大值(max),最小值(min)，然后把它們的區(qū)間(max-min)進(jìn)行分割成多個(gè)區(qū)間，每一個(gè)區(qū)間使用一個(gè)bit表示。然后把各個(gè)具體的值映射到這個(gè)區(qū)間之中。bitindexchunkvalue020170101～201701021120170103～201701040220170105～201701060320170107～201701081420170109～201701101如上表，value值為1表示這個(gè)區(qū)間存在一行或者多行的數(shù)據(jù)，為0表示不存在。我們只需要存儲(chǔ)max，min，和value序列(5個(gè)bit)就完成了對(duì)這一列的索引。比如查詢selectuser_namefromawheredate＝'20170106'因?yàn)?20170106'屬于區(qū)間2，value是0，即可以知道'20170106'不存在于這個(gè)pack，可以直接跳過(guò)。這是一種類似于bloomfilter的過(guò)濾方式，索引不命中的pack一定不包含需要的數(shù)據(jù)string類型的索引和number類似，不過(guò)更加復(fù)雜一點(diǎn)。目前常見(jiàn)的索引有b+樹(shù)索引，倒排索引，這些索引可以精確定位到具體行，在相對(duì)小數(shù)據(jù)量情況下很有效。這種方式通常沒(méi)有特別有效的壓縮，數(shù)據(jù)文件大小一般在原始數(shù)據(jù)的1～3倍之間，當(dāng)數(shù)據(jù)量膨脹到一定程度，這類索引的代價(jià)就會(huì)被放大，甚至無(wú)法服務(wù)。indexr的粗糙集索引的優(yōu)勢(shì)是非?？焖?，索引文件足夠小，可以低成本的方式load到內(nèi)存，在極大數(shù)據(jù)量場(chǎng)景下仍然能有效的工作。由于數(shù)據(jù)通常是排序的內(nèi)聚的，通過(guò)實(shí)際數(shù)據(jù)的觀察，列的值基數(shù)(cardinality)通常比較小，這種方式是可以有效的過(guò)濾掉無(wú)關(guān)的pack。它會(huì)對(duì)所有的列進(jìn)行索引，非常適合于業(yè)務(wù)不固定，或者數(shù)據(jù)分析場(chǎng)景的探索型分析。實(shí)時(shí)入庫(kù)indexr支持實(shí)時(shí)數(shù)據(jù)追加，但不支持?jǐn)?shù)據(jù)在線更新，可以通過(guò)離線的方式使用hive等工具更新數(shù)據(jù)，這樣的設(shè)計(jì)和mesa類似。它的入庫(kù)速度非?？?，通常單個(gè)節(jié)點(diǎn)單表可以達(dá)到30k消息/s。消息到達(dá)indexrnode之后，可以立刻被查詢。indexr的實(shí)時(shí)入庫(kù)模塊使用類似lsm-tree的結(jié)構(gòu)。使用commitlog文件保存消息，最新的數(shù)據(jù)存放于內(nèi)存，在達(dá)到一定閥值之后會(huì)被寫入硬盤。內(nèi)存中的數(shù)據(jù)周期性的存儲(chǔ)到硬盤，時(shí)間一久會(huì)產(chǎn)生較多碎片文件，這些文件在達(dá)到一定閥值之后，會(huì)被整理合并。行的存儲(chǔ)順序可以是自然入庫(kù)順序，也可以按照指定字段排序，類似于關(guān)系型數(shù)據(jù)庫(kù)中的一級(jí)索引和hbase中的columnfamily，這樣做可以讓數(shù)據(jù)更加內(nèi)聚，對(duì)于查詢非常有利。類似于mesa，如果需要，indexr實(shí)時(shí)入庫(kù)可以根據(jù)多維分析(multidimensionalanalysis)的概念，把字段分成維度(dimension)和指標(biāo)(metric/measure)，具有相同維度的行會(huì)合并到一起，指標(biāo)使用聚合函數(shù)(aggregationfunction,e.g.sum,count)，并且表之間可以設(shè)計(jì)成父子關(guān)系。tableb與tablec可以可以認(rèn)為是tablea的子表。tablea擁有三個(gè)維度(date,country,campaign_id)，可以表達(dá)最詳細(xì)的信息。tableb與tablec通過(guò)減少維度，減少了數(shù)據(jù)量，可以更加快速的獲得查詢結(jié)果。應(yīng)用層只需要做簡(jiǎn)單的表路由，比如selectdate,country,sum(impressions)frombwherecountry＝'cn'groupbydate,country可以路由到tableb表，快速獲得結(jié)果。如果需要下鉆(drilldown)查詢，如selectcampaign_id,sum(impressions)fromawherecountry＝'cn'anddate＝'20170101'groupbycampaign_id則會(huì)路由到tablea。這種設(shè)計(jì)類似于關(guān)系型數(shù)據(jù)庫(kù)中預(yù)聚合view。在olap領(lǐng)域，特別是多維分析場(chǎng)景，這種設(shè)計(jì)非常有效。架構(gòu)設(shè)計(jì)indexr的架構(gòu)設(shè)計(jì)遵循簡(jiǎn)單可靠、易擴(kuò)展的原則。它可以大規(guī)模集群部署，支持上千個(gè)節(jié)點(diǎn)。事實(shí)上indexr的硬件成本相對(duì)來(lái)說(shuō)很低，并且可以通過(guò)加節(jié)點(diǎn)線性擴(kuò)展處理能力。apachedrill作為indexr的查詢層。drill是一個(gè)全新的查詢引擎，專注于sql計(jì)算，使用了代碼生成技術(shù)，vectorprocess，列式計(jì)算，堆外內(nèi)存(消除gc)等技術(shù)，有專門針對(duì)對(duì)于大數(shù)據(jù)集的優(yōu)化。速度極快，并且支持標(biāo)準(zhǔn)sql，沒(méi)有遷移負(fù)擔(dān)。從我們的使用經(jīng)驗(yàn)來(lái)看，它非常穩(wěn)定，工程質(zhì)量很高。indexr主要負(fù)責(zé)存儲(chǔ)層，并且對(duì)具體的查詢過(guò)程進(jìn)行優(yōu)化，比如常見(jiàn)的條件下推(predicatepushdown)，limit下推等，未來(lái)還將支持聚合下推(aggregationpushdown)。indexr通過(guò)任務(wù)分配算法，結(jié)合數(shù)據(jù)距離、節(jié)點(diǎn)繁忙程度等，把計(jì)算任務(wù)分配到最合適的節(jié)點(diǎn)。hdfs存儲(chǔ)具體的數(shù)據(jù)文件，分布式文件系統(tǒng)幫助構(gòu)建節(jié)點(diǎn)無(wú)狀態(tài)的服務(wù)。數(shù)據(jù)存放于hdfs中，可以方便的使用各種hadoop工具進(jìn)行其他復(fù)雜分析。我們對(duì)接了hive，方便對(duì)數(shù)據(jù)進(jìn)行離線處理。由于hdfs上的數(shù)據(jù)只有一份，可以同時(shí)被多個(gè)工具處理，省去了繁瑣的同步步驟，在10：1的高壓縮比上又節(jié)省一倍空間。數(shù)據(jù)經(jīng)過(guò)kafka等隊(duì)列高速導(dǎo)入indexr。indexr的實(shí)時(shí)導(dǎo)入非常靈活，可以隨時(shí)增加或者刪除導(dǎo)入節(jié)點(diǎn)。它擁有極高的導(dǎo)入性能(30k/s)，入庫(kù)延遲的壓力成為歷史。在indexr集群中只有一種節(jié)點(diǎn)(indexrnode)，有利于部署和維護(hù)，不需要對(duì)節(jié)點(diǎn)進(jìn)行劃分。目前indexr作為drill插件嵌入了drillbit進(jìn)程。indexr提供了indexr-tool工具，提供了完整的運(yùn)維工具。比如可以在線更新表結(jié)構(gòu)，在線添加、修改實(shí)時(shí)入庫(kù)配置。工程實(shí)現(xiàn)的挑戰(zhàn)算法和數(shù)據(jù)結(jié)構(gòu)要真正落地，必須通過(guò)具體的工程來(lái)實(shí)現(xiàn)，而工程實(shí)現(xiàn)的質(zhì)量決定了項(xiàng)目的最終效果。如果空有高超的設(shè)計(jì)圖紙，而沒(méi)有高質(zhì)量的施工和合適的材料，高樓大廈是建不起來(lái)的。indexr在工程上最求極致的性能，但又不失靈活的擴(kuò)展性。使用直接內(nèi)存(directmemory))。indexr主要使用java8編寫，而java的堆內(nèi)存(heap)與垃圾回收(gc)的模式在大數(shù)據(jù)運(yùn)算場(chǎng)景下面臨比較大的挑戰(zhàn)。在需要使用較大內(nèi)存(超過(guò)32g)以及數(shù)據(jù)更新頻繁時(shí)，jvm的gc問(wèn)題比較明顯，容易造成性能不穩(wěn)定，并且對(duì)象實(shí)例的內(nèi)存模型通常很浪費(fèi)內(nèi)存。我們?cè)趇ndexr項(xiàng)目中把所有的存儲(chǔ)數(shù)據(jù)和運(yùn)算臨時(shí)數(shù)據(jù)存放于堆外，手動(dòng)管理內(nèi)存申請(qǐng)釋放。這樣提高了代碼復(fù)雜度，但相比于傳統(tǒng)的堆內(nèi)存模式，節(jié)省了超過(guò)1/2內(nèi)存，并且沒(méi)有了gc代價(jià)，涉及大量數(shù)據(jù)的賦值操作通?？梢允褂脙?nèi)存拷貝，節(jié)省大量cpu循環(huán)。充分利用現(xiàn)代cpu能力。indexr的堆外內(nèi)存模型對(duì)于充分發(fā)掘硬件潛能非常有益，它們通常是連續(xù)的內(nèi)存塊，沒(méi)有類指針跳轉(zhuǎn)，沒(méi)有虛函數(shù)損耗，cpu寄存器和多級(jí)緩存都可以充分利用，而且對(duì)于使用vectorprocessor非常便利，沒(méi)有結(jié)構(gòu)轉(zhuǎn)換開(kāi)銷。避免隨機(jī)讀取。通常磁盤的特點(diǎn)是連續(xù)讀取非?？欤蚨鴎afka可以使用磁盤做消息隊(duì)列；而隨機(jī)讀取相對(duì)很慢，故傳統(tǒng)數(shù)據(jù)庫(kù)的瓶頸一般在io。indexr的索引方式對(duì)磁盤連續(xù)讀取友好，并且它會(huì)對(duì)數(shù)據(jù)進(jìn)行整理從而更加內(nèi)聚。我們還特別對(duì)文件讀取方式進(jìn)行了細(xì)致的優(yōu)化。優(yōu)化線程、io調(diào)度。在任務(wù)非常繁忙的時(shí)候，cpu爭(zhēng)搶帶來(lái)的線程切換的開(kāi)銷變的不可忽視。并且由于數(shù)據(jù)庫(kù)環(huán)境的特殊性，在做繁忙cpu任務(wù)的同時(shí)，還會(huì)進(jìn)行網(wǎng)絡(luò)、io操作。如何做任務(wù)調(diào)度，合理安排線程數(shù)量和任務(wù)，對(duì)整體性能影響比較大。有時(shí)候單線程比多線程效率更高，并且更省資源。關(guān)鍵性能點(diǎn)使用c++實(shí)現(xiàn)。它在同時(shí)涉及內(nèi)存操作和復(fù)雜cpu運(yùn)算場(chǎng)景時(shí)，運(yùn)行效率優(yōu)勢(shì)明顯。我們把關(guān)鍵的性能點(diǎn)，比如壓縮算法，使用c++實(shí)現(xiàn)。工具選型indexr是一個(gè)新的工具，如果你的項(xiàng)目有以下需求，或者之前已經(jīng)有一些選型但是無(wú)法滿足需求，可以考慮使用indexr。經(jīng)典場(chǎng)景：需要在海量數(shù)據(jù)之上做快速的統(tǒng)計(jì)分析查詢。要求入庫(kù)速度非?？?，并且需要實(shí)時(shí)分析。存放超大量歷史明細(xì)數(shù)據(jù)庫(kù)。比如網(wǎng)站瀏覽信息，交易信息，安保數(shù)據(jù)，電力行業(yè)數(shù)據(jù)，物聯(lián)網(wǎng)設(shè)備采集數(shù)據(jù)等。這類數(shù)據(jù)通常量非常大，數(shù)據(jù)內(nèi)容復(fù)雜，存放時(shí)間比較久，且希望在需要時(shí)可以比較快速的根據(jù)各種條件做明細(xì)查詢，或者在一定范圍內(nèi)做復(fù)雜的分析。這種情況下可以充分發(fā)揮indexr的低成本，可擴(kuò)展，適合超大數(shù)據(jù)集的優(yōu)勢(shì)。典型選型：使用mysql，postgresql等關(guān)系型數(shù)據(jù)庫(kù)，不僅用于業(yè)務(wù)查詢(oltp)，也做統(tǒng)計(jì)分析，一般是在現(xiàn)有業(yè)務(wù)數(shù)據(jù)庫(kù)上直接做一些分析需求。這種方式在數(shù)據(jù)量增長(zhǎng)之后就會(huì)遇到性能問(wèn)題，特別是分析查詢會(huì)對(duì)業(yè)務(wù)查詢產(chǎn)生極大影響?？梢钥紤]把數(shù)據(jù)導(dǎo)入indexr做分析，即把業(yè)務(wù)數(shù)據(jù)庫(kù)和分析數(shù)據(jù)庫(kù)分開(kāi)。es，solr等全文搜索數(shù)據(jù)庫(kù)用于統(tǒng)計(jì)分析場(chǎng)景。這類數(shù)據(jù)庫(kù)最大的特點(diǎn)是使用了倒排索引解決索引問(wèn)題。對(duì)于統(tǒng)計(jì)分析場(chǎng)景通常沒(méi)有特別優(yōu)化，在大數(shù)據(jù)量場(chǎng)景下內(nèi)存和磁盤壓力比較大。如果遇到性能問(wèn)題，或者數(shù)據(jù)量撐不住了，可以考慮使用indexr。druid，pinot等所謂時(shí)序數(shù)據(jù)庫(kù)。在查詢條件命中大量數(shù)據(jù)情況下可能會(huì)有性能問(wèn)題，而且排序、聚合等能力普遍不太好，從我們的使用經(jīng)驗(yàn)來(lái)看運(yùn)維比較困難，靈活性和擴(kuò)展性不夠，比如缺乏join、子查詢等。在保存大量歷史數(shù)據(jù)情況下需要的硬件資源相對(duì)昂貴。這種場(chǎng)景下可以考慮使用indexr直接替換，不用擔(dān)心業(yè)務(wù)實(shí)現(xiàn)問(wèn)題。infobright，clickhose等列式數(shù)據(jù)庫(kù)。列式數(shù)據(jù)庫(kù)本身非常適合于olap場(chǎng)景，indexr也屬于列式數(shù)據(jù)庫(kù)。最大的區(qū)別在于indexr是基于hadoop生態(tài)的。離線預(yù)聚合，建cube，結(jié)果數(shù)據(jù)存放于hbase等kv數(shù)據(jù)庫(kù)，如kylin等。這種方式在只有多維分析場(chǎng)景且查詢比較簡(jiǎn)單的情況下非常有效。問(wèn)題就在于靈活性不足(flexibility)，無(wú)法探索式分析，以及更復(fù)雜的分析需求。indexr可以通過(guò)表配置達(dá)到預(yù)聚合的效果，并且聚合是實(shí)時(shí)，沒(méi)有延遲的；可以保留原始數(shù)據(jù)或者高維度數(shù)據(jù)，通過(guò)表路由決定具體的查詢表。為了解決大數(shù)據(jù)量的即時(shí)分析問(wèn)題，上層使用impala，presto，sparksql，drill等計(jì)算引擎來(lái)做查詢，存儲(chǔ)層使用開(kāi)源數(shù)據(jù)格式比如parquet，基于hadoop生態(tài)。這類架構(gòu)和indexr很相似。indexr的優(yōu)勢(shì)在于更有效的索引設(shè)計(jì)，更好的性能，并且支持實(shí)時(shí)入庫(kù)，秒級(jí)延遲。我們?cè)谙嗤h(huán)境下與parquet格式做過(guò)查詢性能對(duì)比，indexr的查詢速度提升在3～8倍以上。之后indexr經(jīng)歷了很大的性能優(yōu)化，估計(jì)會(huì)有更好的表現(xiàn)。kudu，phoenix等既支持oltp場(chǎng)景，又為olap場(chǎng)景優(yōu)化等開(kāi)源產(chǎn)品。通常很難兩者兼顧，建議分成實(shí)時(shí)庫(kù)和歷史庫(kù)，針對(duì)不同數(shù)據(jù)特點(diǎn)采用不用的存儲(chǔ)方案。內(nèi)存數(shù)據(jù)庫(kù)。飛科技大數(shù)據(jù)平臺(tái)組對(duì)于以上提到的大部分技術(shù)選型有著豐富的經(jīng)驗(yàn)，即這些工具我們或者在生成環(huán)境中使用過(guò)，或者有過(guò)深入的調(diào)研和測(cè)試，這也促使了indexr的誕生。本發(fā)明的有益效果是：1、快速統(tǒng)計(jì)分析查詢：indexr使用列式存儲(chǔ)，對(duì)于超大量數(shù)據(jù)集，它提供高效的索引，通過(guò)過(guò)濾掉無(wú)關(guān)數(shù)據(jù)，快速定位有效數(shù)據(jù)，減少io。它使用了優(yōu)秀的apachdrill作為上層查詢引擎。特別適合于ad-hoc的olap查詢。2、數(shù)據(jù)實(shí)時(shí)導(dǎo)入：indexr支持超高速實(shí)時(shí)導(dǎo)入數(shù)據(jù)。數(shù)據(jù)一到達(dá)indexr節(jié)點(diǎn)，立刻可以被查詢到。實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)可以一起查，再也不需要考慮所謂t+1架構(gòu)。且區(qū)分于其他有類似功能的系統(tǒng)，indexr永遠(yuǎn)不會(huì)主動(dòng)丟棄任何數(shù)據(jù)。3、高效硬件利用率：相較于其他系統(tǒng)，indexr可以跑在廉價(jià)的機(jī)器上。不需要昂貴的ssd硬盤，高端cpu，甚至小型機(jī)，你就可以獲得非常好的性能，雖然在上面跑會(huì)更加快。雖然跑在jvm上，它手動(dòng)管理幾乎所有的內(nèi)存，使用經(jīng)過(guò)高度設(shè)計(jì)、緊湊的數(shù)據(jù)結(jié)構(gòu)。4、集群高可用，易擴(kuò)展，易管理，簡(jiǎn)單：分布式系統(tǒng)發(fā)展到現(xiàn)在，高可用和擴(kuò)展性已經(jīng)是標(biāo)配了。indexr的特點(diǎn)是結(jié)構(gòu)非常簡(jiǎn)單可靠，且只有極少的必須配置項(xiàng)。5、與hadoop生態(tài)的深度整合：indexr把數(shù)據(jù)存放于hdfs。這意味著你可以使用mapreduce，或者任何hadoop工具處理這些文件。我們目前提供了hive插件，用于各種etl相關(guān)工作，或者跑離線任務(wù)。對(duì)接spark的工作正在進(jìn)行，將被使用于數(shù)據(jù)挖掘以及機(jī)器學(xué)習(xí)。6、高度壓縮的數(shù)據(jù)格式：indexr以列式存儲(chǔ)，并提供超高的壓縮率，可以顯著的減少io以及網(wǎng)絡(luò)開(kāi)銷。7、方便的數(shù)據(jù)管理：indexr可以方便的導(dǎo)入、刪除數(shù)據(jù)，并且支持修改表schema，如對(duì)列的添加、刪除、修改等。對(duì)于本領(lǐng)域技術(shù)人員而言，顯然本發(fā)明不限于上述示范性實(shí)施例的細(xì)節(jié)，而且在不背離本發(fā)明的精神或基本特征的情況下，能夠以其他的具體形式實(shí)現(xiàn)本發(fā)明。因此，無(wú)論從哪一點(diǎn)來(lái)看，均應(yīng)將實(shí)施例看作是示范性的，而且是非限制性的，本發(fā)明的范圍由所附權(quán)利要求而不是上述說(shuō)明限定，因此旨在將落在權(quán)利要求的等同要件的含義和范圍內(nèi)的所有變化囊括在本發(fā)明內(nèi)。不應(yīng)將權(quán)利要求中的任何附圖標(biāo)記視為限制所涉及的權(quán)利要求。此外，應(yīng)當(dāng)理解，雖然本說(shuō)明書按照實(shí)施方式加以描述，但并非每個(gè)實(shí)施方式僅包含一個(gè)獨(dú)立的技術(shù)方案，說(shuō)明書的這種敘述方式僅僅是為清楚起見(jiàn)，本領(lǐng)域技術(shù)人員應(yīng)當(dāng)將說(shuō)明書作為一個(gè)整體，各實(shí)施例中的技術(shù)方案也可以經(jīng)適當(dāng)組合，形成本領(lǐng)域技術(shù)人員可以理解的其他實(shí)施方式。當(dāng)前第1頁(yè)12當(dāng)前第1頁(yè)12