從大資料談起1：OLTP和OLAP的設計差別

    最近網際網路技術有四個趨勢非常火爆：

1. 移動
2. 社交
3. 雲計算
4. 大資料

    這個文章系列主要講大資料的一些方方面面。首先要講的是一個抽象概念，可能很多人想起大資料必定首先想起hadoop和mysql叢集一類的，可惜這些都是工具，并非是大資料的全部，隻研究工具怎麼玩在技術上就落了下乘。我們首先還是從概念來看，大資料處理系統概念其實很簡單，隻有兩個組成部分：存儲+查詢。不管再複雜的大資料分析系統，都是這兩個部分的組合： 存儲是指将所有有效資料存放到媒體中，必要時讀取。這個資料的範圍就太廣了，包括了結構化的，常見比如資料庫的資料表、比如訂單、使用者關系、收藏清單。也有可能是非結構化的，這種在網際網路公司很常見，比如通路日志、新聞文本、郵件正文、微網誌内容等。查詢其實是對資料的加工和變化，簡單比如過濾、求和、求平均等，複雜的比如協同過濾， 自然語言處理。 我們最簡單的來想可以把查詢當做是對N維資料的變換輸出。在設計大資料處理系統時，首先需要從這兩個層面來考慮，需要考慮的因素包括：1、資料大小有多大；2、資料如何使用； 3、資料更新頻率。     不管再牛X的技術人員，都是要老老實實做需求的，老闆簡單的需求往往可以把幾個超牛X的技術人員搞得痛不欲生。從目前來看需要大資料的主要應用領域，也隻有兩個： 聯機事務處理OLTP（On-line Transaction Processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關系型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是資料倉庫系統的主要應用，支援複雜的分析操作，側重決策支援，并且提供直覺易懂的查詢結果。 OLTP一般就是把大資料用于線上業務，比如淘寶的訂單交易、商品展示、曆史交易、百度的網頁搜尋、新浪的微網誌内容展示等。這種需求要求有實時性，查詢以後需要在秒級别傳回，且對于服務穩定性和容錯性有一定要求的。另外，讀操作的數量遠遠大于寫操作，且增量資料的大小要遠遠小于曆史資料。在設計OLTP的資料系統中，主要技術難點有：

1. 分層
2. 分片
3. 分布式事務

    OLAP主要是做離線分析，對時效性要求不高，跑幾個小時到幾天問題都不大，并且機器挂了也沒事，大不了restart一下。但是這種系統往往資料量非常大，維數特别多，基本都需要把曆史資料全部掃描1-2遍。在設計OLAP系統裡主要涉及到技術有：

1. 列存儲
2. 降維
3. 切分

OLTP	OLAP
使用者	操作人員，低層管理人員	決策人員，進階管理人員
功能	日常操作處理	分析決策
設計	面向應用	面向主題
資料	目前的， 最新的細節的， 二維的分立的	曆史的， 聚集的， 多元的，內建的， 統一的
存取	讀/寫數十條記錄	讀上百萬條記錄
工作機關	簡單的讀寫	複雜查詢
DB大小	0-100G	TB-PB級别

    從我自己的觀點來看，OLTP做起來相對容易，并且企業産品和開源産品非常多。小型項目用mysql+redis+memcached足夠應付。大型項目在開源社群的支援下，hadoop +hbase+redis也可以從無到有地應對需求，迅速減少小公司同大公司的差距。甚至連之前NOSQL的各大産品一直糾結的CAP原則，目前也隐隐有了逼近的解決方案，至少在可用性A和分區容忍度P達到的基礎上，基本能把一緻性C的延遲時間降低到秒級甚至毫秒級。而大型商業産品推出的分布式資料庫，和一些開源分布式産品，例如淘寶開源的OceanBase都在保證分布式資料庫的ACID的原子性上進行了一定程度的嘗試。 而OLAP相對起來較為複雜，由于資料是多元的，以往以語義性著稱的SQL語言也在資料分析時顯得力不從心。在這方面模組化和抽象變得很重要，如何解決資料的語義性和查詢的可描述性變得很困難。相比起來，這方面的突破才顯得不那麼容易。目前OLAP主要的開源産品包括HDFS、HIVE和Impala等，至于商業産品，因為沒有機會用到，在這裡就不提了     總體來看，如何根據需求來設計系統才是一個技術人員需要考慮的問題，過分的設計和過分的資源消耗都是不合适。下次我們再介紹下OLTP裡的分層思想