「最近看到一句話：「架構設計的關鍵思維是判斷和取捨，程式設計的關鍵思維是邏輯和實現」，深以為然！
文 | 個推cto anson
引言資料智慧型就是以資料作為生產資料，通過結合大規模資料處理、資料探勘、機器學習、人機互動、視覺化等多種技術，從大量的資料中提煉、發掘、獲取知識，為人們在基於資料制定決策時提供有效的智慧型支援，減少或者消除不確定性。
從對資料智慧型的定義來看，資料智慧型的技術體系至少需要包含幾個方面，見下圖所示：
▲資料智慧型技術體系構成
其中資料資產治理、資料質量保證、資料智慧型下的安全計算體系會在後續的系列文章中重點闡述。
然而最近在實際工作中，發現大家對於如何處理多維資料進行分析以解決實際業務問題方面存在一些實實在在的困擾，特別是對於選擇什麼樣的底層系統無所適從，畢竟有資源給大家進行試驗的公司並不是太多。
正文內容
分析系統的考量要素
cap 理論大家都已經比較熟悉， c.a.p 之間無法兼得，只能有所取捨。在分析系統中同樣需要在三個要素間進行取捨和平衡，三要素分別是資料量、靈活性以及效能。
▲分析系統考量三要素
有的系統在資料量達到一定數量，譬如超過p級別後，在資源不變情況下，就無法滿足處理要求了，哪怕是乙個簡單的分析需求。
靈活性主要指運算元據時的方式是否靈活，比如對於一般的分析師而言，使用sql來操作是首選，沒有太多的約束，如果使用特定領域的語言 (dsl) 相對就比較受限；另外乙個意思是操作是否受預先條件的限制，譬如是否支援在多個維度下進行靈活的即席(ad-hoc)查詢；最後乙個就是效能要求，是否滿足多併發操作、能否在秒級進行響應。
資料查詢的過程分析
對資料進行聚合型別的查詢時，一般按照以下三個步驟進行：
▲實時查詢過程
首先，需要用索引檢索出資料所對應的行號或者索引位置，要求能夠從上億條資料中快速過濾出幾十萬或幾百萬的資料。這方面是搜尋引擎最擅長的領域，因為一般關係型資料庫擅長用索引檢索出比較精確的少量資料。
然後從主儲存按行號或者位置進行具體資料的載入，要求能夠快速載入這過濾出的幾十上百萬條資料到記憶體裡。這方面是分析型資料庫最擅長的領域，因為一般它們採用列式儲存，有的還會採用mmap的方式來加快資料的處理。
最後進行分布式計算，能夠把這些資料按照group by和select的要求計算出最終的結果集。而這是大資料計算引擎最擅長的領域，如spark、hadoop等。
架構的比較和分析
結合以上兩方面的要素，在架構方面目前主要是三類：
mpp (massively parallel processing)
基於搜尋引擎的架構
預計算系統架構
mpp架構
傳統的rdbms在acid方面具有絕對的優勢。在大資料時代中，如果你的資料大部分依然還是結構化的資料，並且資料並不是如此巨大的話，不一定非要採用類似hadoop這樣的平台，自然也可以採用分布式的架構來滿足資料規模的增長，並且去解決資料分析的需求，同時還可以用我們熟悉的sql來進行操作。
這個架構就是mpp(massively parallel processing)–大規模並行處理。
當然實際上mpp只是乙個架構，其底層未必一定是rdbms, 而可以是架設在hadoop底層設施並且加上分布式查詢引擎(由query planner、query coordinator和query exec engine等組成)，不使用mapreduce這樣的批處理方式。
這個架構下的系統有：greenplum、impala、drill、shark等，其中greenplum (一般簡稱gp) 使用postgresql作為底層資料庫引擎。
基於搜尋引擎的架構
相對比mpp系統，搜尋引擎在進行資料（文件）入庫時將資料轉換為倒排索引，使用term index、term dictionary、posting **結構建立索引，同時採用一些壓縮技術來進行空間的節省。
這些資料（文件）會通過一定的規則（譬如對文件id進行雜湊演算法）分散到各個節點上。在進行資料檢索的時候，採用scatter-gather計算模型，在各個節點上分別進行處理後，集中到發起搜尋的節點進行最終聚合。
這個架構下的系統主要有：elasticsearch、solr，一般採用dsl進行操作。
預計算系統架構
類似apache kylin這樣的系統就是預計算系統架構。其在資料入庫時對資料進行預聚合，通過事先建立一定的模型，對資料進行預先的處理，形成「物化檢視」或者資料cube，這樣對於資料的大部分處理實際是在查詢階段之前就完成了，查詢階段相當於進行二次加工。
這個架構下的系統主要有: kylin，druid。雖然kylin和druid都屬於預計算系統架構，兩者之間還是有不少差別。
kylin是使用cube的方式來進行預計算（支援sql方式），一旦模型確定，要去修改的成本會比較大，基本上需要重新計算整個cube，而且預計算不是隨時進行，是按照一定策略進行，這個也限制了其作為實時資料查詢的要求。
而druid 更加適合做實時計算、即席查詢（目前還不支援sql），它採用bitmap作為主要索引方式，因此可以很快地進行資料的篩選及處理，但是對於複雜的查詢來說， 效能上比kylin要差。
基於上面的分析，kylin一般主推超大資料量下的離線的olap引擎，druid是主推的大資料量下的實時olap引擎。
三種架構的對比
mpp架構的系統：
有很好的資料量和靈活性支援，但是對響應時間是沒有必然保證的。當資料量和計算複雜度增加後，響應時間會變慢，從秒級到分鐘級，甚至小時級都有可能。
搜尋引擎架構的系統：
相對比mpp系統，犧牲了一些靈活性換取很好的效能，在搜尋類查詢上能做到亞秒級響應。但是對於掃瞄聚合為主的查詢，隨著處理資料量的增加，響應時間也會退化到分鐘級。
預計算系統：
在入庫時對資料進行預聚合，進一步犧牲靈活性換取效能，以實現對超大資料集的秒級響應。
結合上面的分析，以上三種分別是：
對於資料量的支援從小到大
靈活性從大到小
效能隨資料量變大從低到高
因此，我們可以基於實際業務資料量的大小、對於靈活性和效能的要求綜合來進行考慮。譬如採用gp可能就能滿足大部分公司的需要，採用kylin可以滿足超大資料量的需求等。
結語
最近看到一句話：「架構設計的關鍵思維是判斷和取捨，程式設計的關鍵思維是邏輯和實現」，深以為然！
未來，我們個推技術團隊也將不斷探索多維度分析系統的選型方法，與大家共同**，一如既往地為各位開發者提供更優質的服務。
魔推mpush 實現精準智慧型訊息推送的五個關鍵
前言 因為工作性質的關係，筆者會接觸到很多非常資深的移動開發商。大部分技術工程師出身的ceo 對技術本身的智財權非常敏感。kk的預言 一文中提出乙個觀點 當擁有智財權不在能夠保證盈利，擁有精準只能的資訊推送能力是今後 開發公司盈利的保證 魔推mpush 是一款訊息推送類 sdk外掛程式，它專門為開發...
讓服務更智慧型 長虹佳華攜手摩托羅拉推大資料解決方案
在日常生活中，每個人都有自己專屬的消費習慣。百貨零售企業如果能夠把握住每乙個人的消費特點，則必然會收穫優異的銷售業績。然而，要對每一位顧客都進行分析，這在以往完全不可想象。但隨著大資料的興起，這正快速成為現實。為了助力百貨零售企業能夠充分把握顧客的消費特點，國內領先的大資料整合it分銷企業 長虹佳華...
滴滴快的推蒼穹平台 用大資料下活「智慧型出行」棋
zdnet至頂網軟體頻道訊息 下午1點鐘，北京金融街的打車需求中，去往機場方向的機率更高 如果你是瀋陽的計程車司機，想要生意好就要比其他城市的司機更早起 這些交通執行的 秘密 來自於上個月底上線的 滴滴快的 大資料移動智慧型出行平台 蒼穹 在北京 上海 杭州等10個城市，所有專車和計程車的資料每個小...