? ? ? ? 海量數(shù)據(jù)多維分析我這里指的是通過數(shù)據(jù)庫，然后通過某種專業(yè)olap工具（例如cognos等）進行靈活查詢的行為，這種查詢具有以下特定：
1、行為不可控，在模型范圍內(nèi)隨意查詢，大表與大表關(guān)聯(lián)，多表關(guān)聯(lián)等等，各種查詢行為都有。
2、數(shù)據(jù)量巨大，大表都有1個T以上的數(shù)據(jù)。
按我們這么多年的工作實踐，海量數(shù)據(jù)的olap要想達到快速查詢其實是非常難的事情，主要難在：
1、查詢行為不固定，即使你再努力調(diào)優(yōu)，發(fā)現(xiàn)你只能解決一個場景，不能解決所有場景。例如機構(gòu)，你按照某個字段“機構(gòu)”進行分區(qū)了，命中后提升了查詢效率，但是我們有好幾個機構(gòu)，開戶機構(gòu)、管理機構(gòu)、交易機構(gòu)，導致了你根本無法對這個模型全面優(yōu)化
2、專業(yè)olap工具我們使用并不是很理想，我們曾經(jīng)嘗試過cube或者麒麟等產(chǎn)品，但是因為需求不會一成不變，一旦需求變更整個模型就要從新加載數(shù)據(jù)；維度多，多到產(chǎn)品都無法支持，即使能夠支持cube也會膨脹非常厲害，所以我們最終還是放棄了。
????現(xiàn)在，我們主要基于數(shù)據(jù)庫+BI工具的方式，因為這樣數(shù)據(jù)加載、修數(shù)、模型變更等非常靈活，但是這樣一來就會把所有壓力傳導給數(shù)據(jù)庫，也就是你的bi效率快慢完全取決于數(shù)據(jù)庫的快慢。下面我說一下幾個產(chǎn)品的比較：
1、oracle數(shù)據(jù)庫，它的性能調(diào)優(yōu)主要通過主鍵、分區(qū)、索引等解決，所以對于千萬級別數(shù)據(jù)量簡單查詢還可以，但是對于動輒大幾千萬、億以上的多表關(guān)聯(lián)，一旦沒有命中索引，cpu馬上就會告警。前面已經(jīng)說過，靈活查詢根本無法預知查詢行為。所以不命中是大概率事件。
2、mpp數(shù)據(jù)庫（例如GP），由于實現(xiàn)了分布式，會自動重分布，不用建索引也能實現(xiàn)高效查詢，所以對于海量數(shù)據(jù)查詢我們目前使用的方案基本都是采用gp。但是同時也帶來一些問題，查詢性能不高，分鐘級以上是經(jīng)常發(fā)生，并發(fā)不大。
3、hadoop+spark的方式，底層可以提供HIVE、hbase等數(shù)據(jù)庫，大寬表查詢我們可以直接指向hbase，我感覺靈活性比gp數(shù)據(jù)庫好。雖然有索引，但是經(jīng)測試基本沒有任何效率的提升。使用這種方式，最好能夠強制命中分區(qū)鍵（例如日期），命中的情況下效率非常好。
4、Spark+ignite，這是我目前認為最好解決海量數(shù)據(jù)高性能計算、查詢的最好方案：
Ignite是一個分布式的內(nèi)存數(shù)據(jù)庫、緩存和處理平臺，為事務型、分析型和流式負載而設(shè)計，在保證擴展性的前提下提供了內(nèi)存級的性能。
Spark是一個流式數(shù)據(jù)和計算引擎，通常從HDFS或者其他存儲中獲取數(shù)據(jù)，一直以來，他都傾向于OLAP型業(yè)務，并且聚焦于MapReduce類型負載。
整合這兩種技術(shù)會為Spark用戶帶來若干明顯的好處：
通過避免大量的數(shù)據(jù)移動，獲得真正可擴展的內(nèi)存級性能；
提高RDD、DataFrame和SQL的性能；
在Spark作業(yè)之間更方便地共享狀態(tài)和數(shù)據(jù)。
下圖中顯示了如何整合這兩種技術(shù)，并且標注了顯著的優(yōu)勢：
經(jīng)測試，我們對某個場景進行查詢1天數(shù)據(jù)只用3秒、明顯高于hadoop好幾倍。查詢一個月數(shù)據(jù)，只要4秒，說明在大數(shù)據(jù)量情況下依然能夠保持良好的查詢效率。
Ignite有索引，經(jīng)測試，加索引以后效率快很多
Ignite既可以用內(nèi)存，也可以用ssd盤，所以在一定數(shù)據(jù)量情況下是能夠保證效率。他本身就是一個數(shù)據(jù)庫，也可以把一些內(nèi)容持久化到硬盤。并且是多備份的，保證數(shù)據(jù)不丟失。但是我并不建議把它完全當硬盤數(shù)據(jù)庫使用，取其優(yōu)勢就可以了。
但是他的弊端也是非常明顯的，就是完全依賴內(nèi)存或SSD盤的大小，我們發(fā)現(xiàn)其實只有20%的應用承載了80%的訪問量，所以我們大不不必把所有應用采用這種方案，只把訪問量大放到ignite就可以了。其他低頻的依然在hadoop或者mpp數(shù)據(jù)庫，采用傳統(tǒng)數(shù)據(jù)庫和這個方案相結(jié)合。
新技術(shù)層出不窮，特別是現(xiàn)在基于hadoop也有很多實現(xiàn)方案，如果我發(fā)現(xiàn)好東西再告訴大家
