老錢說大資料(1)----大資料OLAP與OLTP分析

標籤：

1. 首先，咱們先不拿大資料說事，先分析一下OLAP及OLTP。

    OLAP: 線上分析處理（OLAP）系統是資料倉儲系統最主要的應用，專門設計用於支援複雜的分析操作，側重對決策人員和高層管理員的決策支援。

    OLTP: 聯機交易處理(OLTP，On-line Transaction Processing)應用，它所儲存的資料被稱為操作資料或者業務資料。

    所以從定位上來講，OLAP的定位是用來做資料分析(類BI),OLTP適合做一些事務的類的資料管理如查詢如訂單資料的產生。

 

    舉個通俗的例子，一個小規模的電商網站，會有下單的流程，那麼這個下單流程產生的訂單會是在OLTP資料庫中，而如果電商的CEO想看本個月的運營情況，如果訂單統計，理論上是應該在OLAP資料庫（或者倉庫）。

   所以從本質上來講，OLAP是讀為主而OLTP以寫為主。

    

   然後，我們在來做一個基本的分析，就是常見的分析方式：

1. Ad-hoc query：即席查詢（Ad Hoc）是使用者根據自己的需求，靈活的選取查詢條件，系統能夠根據使用者的選擇產生相應的統計報表。
2. 固定欄位分析：即使用者的查詢條件是固定的，我們可以按照定義好的欄位進行報表提供，如周報、月報
3. 關鍵字查詢：如，使用者的地址為 北京市朝陽區XXXXX，那麼提供按照北京市XXX為關鍵字的檢索查詢
4. 統計類查詢：如產生一些箱圖，熱力圖等

   可以簡單分析一下就是，在OLTP中，合理設計的情況下會存在1，3類查詢，而在OLAP中會在1,2,3,4類查詢。

   

2. 接下來，我們分析一下傳統技術的問題：

      大家知道，不管在牛逼的系統，都逃不開硬體的限制，如磁碟IO、記憶體、CPU（往往也是大家忽略的）、網路IO。一般SATA硬碟的讀寫速度是在50~75M之間，普通網路均為千兆交換器，即100M傳輸速度。

     

      那我們在來分析一下，資料庫的特性：（本文章不討論資料庫的具體實現）

 

1. 資料庫能進行較快查詢的原因是因為索引（及緩衝）的存在，不同資料庫的索引實現結構會稍微不太一樣。索引也需要維護。          

   再結合我們之前講到的分析，大家可以認為資料庫在查詢上的效能其實還是比較容易實現最佳化（結合資料庫緩衝），但是大家需要注意的是，如果查詢的時候同時存在彙總（group by，sum，count），那麼壓力就會落在IO上，比如排序（因為單機記憶體有限，必須通過硬碟來實現排序）  這個時候壓力就會落到IO上（請回顧上文提到的效能），所以當我們需要返回的資料條數越大（尤其分頁），那麼資料庫就會變的非常非常的慢。

   

• 很多人會用資料庫來進行資料清洗，也是因為IO的問題，導致變慢
• 大家不能忽略：當資料不大時，也會出現分析很慢的問題，是因為CPU計算能力有限的問題。   

     所以綜合我的分析，大家可以得出幾個結論：

 

• 資料庫的問題在計算資源的有限
• 本身也沒有支援關鍵字查詢的方式（搜尋引擎）。
• 主要是在查詢+統計的情境下，資料庫會有問題，其實本質來講Ad-hoc query 如果沒有統計的話，咱們通過分庫+hash的方式是可以做到非常快的。

     

3.目前開源大資料方案，是否Ready？

   接下來，我通過工作中使用的一些技術給大家做一些分析，希望大家能對這個東西的解決方案有一些瞭解

   我們在幾個方面做比較，架構、效率、成熟度等級、學習難度等。

 

Hadoop+Hive+Tez：

 

• 架構 ： Hive 目前是Hadoop上的資料倉儲，底層的技術為Tez(DAG MapReduce)，採用Yarn 作為資源管理平台，提供類SQL 介面，HQL,採用資料庫作為中繼資料管理工具。

• 成熟度等級：Hive目前已經被非常多的人來使用，所以整體比較成熟。

• 效率：Hive目前結合Orcfile+壓縮整體還是比較快的，但是也沒有達到一些ad-hoc query要求的3秒內返回

• 學習難度 ：HQL，Hadoop 入門的難度都不高，所以學習曲線比較簡單。

   總結如下：

 

1. Hive 目前這個軟體適合做OLAP資料倉儲類分析、資料清洗等對即時性要求不高的情境
2. Hive 不支援按照關鍵詞查詢，所以不能做搜尋
3. Hive 索引比較弱，達不到資料庫的效能。
4. Hive 不能滿足3秒，5秒類似的快速返回的Ad-hoc query（即便將HDFS資料加入記憶體）
5. 有Insert,update 等初級事務操作，所以可以認為未來可能可以做oltp。

 Spark+Hadoop：

• 架構：Spark 技術中有一個比較好的技術就是-Spark SQL，這個技術可以實現使用SQL來操作Spark的RDD，當然Spark SQL最終也是要通過Spark的引擎，來使用所以最終會轉換成Spark的MapReduce。

• 成熟度等級 ：目前仍是告訴發展。
• 效率： 整體比Hive率高，但是如果資料量非常大，沒有特別好的效果。資料加入記憶體後查詢（無統計）非常快。
• 學習曲線：需要學習Hadoop，Spark等，比較陡峭。

    總結如下：

 

1. 資料量不是特別大，完全裝入記憶體，可以提供秒內的非統計類查詢。  
2. 不能完全裝入記憶體的統計分析，結果與hive+tez的組合不會差太多，也不會領先特別多。
3. 適合一定的Ad-hoc query情境與Olap 情境，不能做oltp
4. 沒有索引，無法做精確的尋找，都是暴利掃描。

 Impala+Hadoop：

• 架構：Impala技術目前效能不錯，拋棄了MapReduce設計，結合HDFS緩衝可以做更好的效能提高
• 成熟度等級：比較成熟
• 效率：配合Parquet ,效能與Hive+Tez接近，因為不需要啟動在一定程度分析比Hive快
• 學習曲線：學習SQL與Impala 本身，所以難度一般。

   總結：

 

• Impala效能不錯，但是在大資料排序上，需要限制返回的行數，大表間Join也是個問題。
• 適合一定的Ad-hoc query情境與Olap 情境，不能做oltp
• 沒有索引，無法做精確的尋找，都是暴利掃描。

     所以綜合看，目前開源的大資料SQL方案，沒有一個是完美的，都是或多或少的缺陷，我們需要由搜尋引擎+nosql+redis等方案配合，來完成很多的情境。

 

     我們需要對效能有一個結論：要求5秒內的，基本不適合用這種大資料SQL方案手段來做。需要藉助更昂貴的資料庫，或者等待開源技術成熟。

老錢說大資料(1)----大資料OLAP與OLTP分析