轉行做資料相關的工作有近兩年時間，除了具體技術，還有許多其它思考。在涉及具體的技術前，先想一想為什麼需要olap這樣的系統，它有什麼價值或者說在公司或部門這是不可取代的麼？ 可以帶來哪些價值，是直接變現還是間接變現。 如果不能回答或回答不了，那麼就是乙個很大的問題，這其實意味著資料的質量存在問題。沒有質量的資料，體量再大也毫無價值。
假設已經有很好的oltp系統，那麼oltp系統在資料量不大的情況下，繼續扮演olap角色也還可以。一旦業務紅火，那麼oltp中的analyze部分勢必會分離出來，也就是olap和oltp相互單獨存在。
olap中儲存大量歷史資料，資料儲存成了olap中要解決的第乙個也是首要問題，這個需求的解決方案有多種，可以是hdfs，也可以是nosql資料庫，也可以是distributed rdbms，當中的取捨要視具體情況而定。後面會涉及具體的考慮維度。
如何將資料從oltp遷移到olap，這個同步機制需要考慮資料一致性，zero data-loss, 實時性要求等等。
在大量甚至是海量的歷史資料中如何快速定位到所要符合條件的記錄？ 資料量如果在tb級以上，就需要考慮使用solr或是elasticsearch
花了好多代價儲存下來的海量資料，只是用了做簡單明細查詢，任何老闆都不能容忍，一定要在歷史的資料進行複雜的分析才行。這時候有乙個好的分布式計算引擎就很有必要了。如spark/presto/impala
資料探勘是一種比資料分析更為複雜的資料分析，呵呵，個人理解，有些繞。這個時候什麼演算法啦，什麼機器學習啦，可以上場了。
資料分析中還需要考慮到另乙個重要約束就是時間，如果希望分析結果愈快愈好，那麼就需要採用如druid這樣的系統。
如果資料規模在10tb以下，資料報含結構化和半結構化資料，明細查詢中條件比較固定，不存在全文搜尋。需要在比較短的時間內如秒級得到複雜分析結果，可以考慮使用distributed rdbms.
如果資料規模遠遠超過10tb，那麼就需要將資料儲存/資料查詢/資料分析交由不同的系統來處理，這個時候就需要組成乙個技術棧來解決總量。如hdfs/solr or elasticsearch/spark or presto or impala. 為了提公升分析的效率，除了從distributed computing engine側進行優化之外，還需要從儲存側進行優化，採用先進的儲存格式如parquet/orc/carbondata將會極大的提公升分析效能。
大資料時代下OLAP的角色轉換
在傳統的資料倉儲下，基本上都是以為資料的完全擁有與完全儲存為己任，進而在上面進行相應的資料操作與資料處理，然而大資料時代下olap本身的功能需要因為大資料相關技術的發展而產生一些變化。個人感覺可能會產生以下幾個方向的轉換 1 資料處理方式的變化，之前通過一種資料即可處理資料，當資料量達到一定規模時，...
大資料時代挑戰就是商機
摘要 隨著計算機技術的快速發展，特別是大資料 雲計算 社交網路 移動客戶端以及資訊傳播技術的進步，資料正以驚人的速度快速增長。多年以前，資訊界就在議論乙個話題 如何處理海量資料？尤其是需要處理大量使用者資料的行業。他們的使用者基本在任意時間段，隨時產生資料。這些相關行業的伺服器，必須將隨時產生的資料...
雲計算大資料時代IT管理的機遇和挑戰
文章講的是雲計算大資料時代it管理的機遇和挑戰，近日，由國際最佳實踐管理聯盟主辦 雲計算大資料時代it管理的機遇和挑戰 為主題的第二屆國際最佳實踐管理聯盟中國年會 以下簡稱年會 於2015年5月28日在北京新世紀日航酒店隆重召開。此次年會是繼2014年首屆國際最佳實踐管理聯盟中國年會成功召開後的又一...