[[398259]]

本文轉載自微信公眾號「虞大膽的嘰嘰喳喳」，作者虞大膽。轉載本文請聯(lián)系虞大膽的嘰嘰喳喳公眾號。  

大數(shù)據(jù)領域體系非常龐大，最近自己在了解數(shù)倉部分，做些記錄。

首先解釋OLTP和OLAP的概念，作為開發(fā)對OLTP比較了解，操作對象是數(shù)據(jù)庫，也稱為OLTP數(shù)據(jù)庫(比如Mysql)，主要用于CRUD操作，講求高并發(fā)、低延時，一般作為業(yè)務數(shù)據(jù)使用。

而OLAP則是聯(lián)機分析處理，做數(shù)據(jù)分析用的，比如進行數(shù)據(jù)聚合操作，它操作的數(shù)據(jù)源比較大，對性能要求相對較低。操作對象是數(shù)倉。有的時候OLAP也等同數(shù)倉。

數(shù)倉一般是多維模型模型，數(shù)據(jù)分層，ETL處理。它的數(shù)據(jù)源來源很多，格式也很多，比如結構化的數(shù)據(jù)，非結構化的數(shù)據(jù)。

對于ETL處理，需要對業(yè)務的理解非常透，比如MySQL是作為業(yè)務使用的，比如商品業(yè)務可能有很多類型的表，而到數(shù)倉后，可能會重新建模，比如分為維度表和事實表。

現(xiàn)在我們面臨兩個問題，第一就是ETL機制非常弱，基本上是原樣將MySQL庫導入到數(shù)倉;第二業(yè)務庫變更后，需要重新構建，對于業(yè)務數(shù)據(jù)庫的理解總是落后的。

那數(shù)倉有什么用呢，可以進行交互式查詢，數(shù)據(jù)分析，數(shù)據(jù)挖掘，BI報表。

根據(jù)不同的理解，數(shù)倉也有很多的分類，比如：

1：根據(jù)建模分為MOLAP，ROLAP，HOLAP

MOLAP需要進行預計算，將可能的查詢結果存儲起來，適合分析比較穩(wěn)定的場景，Kylin是這個領域的解決方案。

ROLAP是目前的主流，基于關系模型，構建在多維數(shù)據(jù)模型上，一般通過SQL就能查詢。

2：對于ROLAP:有兩種解決方案，一種是寬表模型，比如現(xiàn)在比較流行的clockhouse;另外就是多表組合模型，比如Presto。

3：從實時性分:分為實時數(shù)倉和離線數(shù)倉，本文主要理解離線數(shù)倉，也叫批處理，就是數(shù)據(jù)是提前準備好的，比如Hadoop就是解決這類問題的。

4：對于OLAP來說，處理的數(shù)據(jù)是非常大的，為了加快處理，有兩種解決方案：并行處理(比如 Hadoop 的Mapreduce，Spark，或者MPP架構的Presto)，另外就是預計算(比如Kylin)。

那具體如何選型呢?

1：我們用的是比較常規(guī)的Hadoop，HDFS作為分布式存儲，Mapreduce作為并行計算框架，但HDFS只是存儲，沒有結構化的概念，那怎么做數(shù)倉呢?

使用Hive解決了兩個問題，首先它存儲表結構元數(shù)據(jù)，其次Hive查詢中的sql自動變?yōu)镸R并行任務，MR從元數(shù)據(jù)中讀取信息，然后去HDFS中讀取數(shù)據(jù)，最后進行運算。

一般情況下這屬于離線數(shù)倉，HDFS存儲的是T-1的全量數(shù)據(jù)(不支持數(shù)據(jù)增刪改查，只能整個文件覆蓋)，使用sqoop工具將MySQL導入到HDFS中。

2：MPP on Hadoop 的解決方案

由于MR操作HDFS的中間結果還是在磁盤，所以運算還是很慢的。

Presto是基于MPP架構，充分利用各個節(jié)點的cpu能力，中間結果放入內(nèi)存，減少磁盤消耗。

比如Presto作為SQL執(zhí)行引擎，本身不存儲數(shù)據(jù)，它可以直接調(diào)用MySQL進行運算。

也可以調(diào)用Hive，讀取元數(shù)據(jù)，然后操作HDFS的數(shù)據(jù)，進行并行運算。

有了Hive，有了Presto，結合可視化的BI工具，就能產(chǎn)生數(shù)據(jù)報表，進行數(shù)據(jù)分析和挖掘。

最后簡單說下BI，有個公式：

BI平臺=數(shù)據(jù)倉庫+OLAP服務/報表。