大數(shù)據(jù)的初期大家都在拼什么?拼集群規(guī)模,節(jié)點(diǎn)數(shù)量，拼存儲能力，拼調(diào)度能力。此時企業(yè)展示技術(shù)能力的時候一般都會強(qiáng)調(diào)什么集群規(guī)模過萬，存儲能力過百P,每天執(zhí)行數(shù)十萬的job。
　　在大數(shù)據(jù)初期，人們基本不太在意，數(shù)據(jù)的存儲成本，執(zhí)行性能和響應(yīng)速度。更在意的的是構(gòu)建初始的大數(shù)據(jù)環(huán)境，讓數(shù)據(jù)更大，以及對大數(shù)據(jù)的掌控能力。
　　隨著這方面的技術(shù)越來越成熟，人們會對數(shù)據(jù)的時效性，查詢響應(yīng)時間要求越來越高。在這個時期出現(xiàn)了許多預(yù)處理技術(shù)，比方說storm,hbase等，以及一些對性能優(yōu)化的一些處理方法比如說基于嵌套列存儲技術(shù)的google dremel,apache drill，impala等，但這些僅僅能在某一領(lǐng)域滿足人們的時效性要求，通用性不強(qiáng)，只能說是預(yù)處理技術(shù)和列存儲，并不能滿足通用的低延遲的即席查詢要求。
　　目前開源的mdrill技術(shù)以及騰訊自主研發(fā)的hermer目前的索引的索引量只能達(dá)到千億規(guī)模，萬億規(guī)模以上的成功案例還沒有，糾其原因有兩點(diǎn)
　　其一是索引存儲在本地硬盤，他對容災(zāi)，異常的恢復(fù)的處理邏輯，進(jìn)程異常后的任務(wù)遷移成本制約了其索引規(guī)模的大小。
　　其二是受限其調(diào)度系統(tǒng)的實(shí)現(xiàn)，管理的事情太多，既要管理索引，又要管理心跳，也要維護(hù)容災(zāi)，導(dǎo)致調(diào)度系統(tǒng)的機(jī)器規(guī)模上不來。
　　索引管理，容災(zāi)心跳管理，計(jì)算資源管理三者將來必須分離。否則萬億以上的目標(biāo)別想。
　　其三內(nèi)嵌過多的來源代碼，比如說jstorm,solr等等，他們的架構(gòu)制約了拓展性。
　　隨著yarn技術(shù)的趨于成熟以及在hdfs中的索引技術(shù)的成熟和性能的提升，低延遲的萬億規(guī)模的索引技術(shù)有了希望。
　　第一，yarn分配的資源不在像之前那樣還要維護(hù)索引狀態(tài)，存儲位置，僅僅負(fù)責(zé)對索引的檢索和寫入，單獨(dú)的索引管理將以服務(wù)的形式獨(dú)立出來，yarn的資源不在固定的處理某個索引，而是聽從索引管理服務(wù)的安排。這樣的放權(quán)也給外部更多的靈活的空間
　　第二，索引與editlog直接存放在hdfs，容災(zāi)交給成熟的hdfs去管理，也不要再說索引在hdfs中性能差了，那是過去，現(xiàn)在性能還是不錯的。
　　第三，獨(dú)立的索引管理，讓索引更靈活。
　　將索引從原有的進(jìn)程中抽出，每個進(jìn)程可以處理多個索引,提升進(jìn)程的利用率。單獨(dú)的索引管理，針對不同的業(yè)務(wù)，更容易靈活的變通。
　　第四，基于這個版本的大索引不在像之前單獨(dú)對外提供服務(wù)，會更加的開放，對外提供了很多拓展功能，現(xiàn)有的hive以及spark可以很方便的通過類似 inputformat的方式直接使用大索引。同時可以方便的將hdfs,hbase,hive,實(shí)時的消息隊(duì)列比如說kafka,metaq等系統(tǒng)方便的導(dǎo)入導(dǎo)出。
　　試想下，spark在利用上這個大索引后，一個幾萬億的數(shù)據(jù)，幾秒鐘就返回結(jié)果，而且還支持了很多的復(fù)雜查詢，是不是很值得期待呢。
　　同志們，我們嘗試的已經(jīng)夠多，是時候開啟新的大索引技術(shù)之路，求更多的戰(zhàn)友組隊(duì)。
　　“夢想還是要有的”，大索引未來我看好你哦。（文章來源：CDA數(shù)據(jù)分析師）