在Hive中適不適合像傳統數據倉庫一樣利用維度建模？

01-21

在Hive中適不適合像傳統數據倉庫一樣利用維度建模？還是說Hive只能用於ETL，然後將統計過後的數據導出到關係型的資料庫再進行維度建模呢？

這取決於你的查詢模式。如果只是每天或每小時統計一下例行報表，那是完全沒有問題的。如果是靈活的查詢並且對響應時間可以接受10分鐘以上，那也是沒有問題的。但如果你要想滿足秒級的互動式查詢，那就不行了。

提交一個hive查詢，轉化成一個mapreduce任務輸出結果，即使最簡單的任務，可能也會花費一兩分鐘。

對於維度建模，在互聯網時代同樣很有價值。只是因為業務變化快，不可能像傳統領域維度和查詢模式很固定，在設計上一定要考慮滿足業務的靈活擴展。這方面的內容可以看看我的知乎專欄。

先說結論，我覺得Hive不支持維度建模是因為它的目標應用場景不適合採用維度建模，而不是因為架構或是技術上無法實現。

對數據進行維度建模的前提是用戶對數據訪問的維度是預先了解的，而Hive的設計目標是支持更靈活的Ad hoc查詢，即可在任意維度對數據進行任意方式的分析。為了實現這個更通用的使用場景，Hive基於MapReduce或是其他分散式計算框架，將查詢切分成很多更小粒度的計算邏輯分發到分散式節點上計算。Hive還支持非常多的UDF，以及用戶在查詢中嵌入自定義的mapper和reducer,可見其設計目標更多的考慮數據分析的靈活性。

基於MapReduce等分散式計算框架之上的SQL引擎是完全可以設計成支持維度建模的數據倉庫，Kyvos Insights就是一個例子，不過這是一個商業產品，並未開源。Apache Kylin是一個採用不同架構的OLAP on Hadoop項目，由Ebay貢獻給開源社區，原始表在Hive中，建模生成的cube存儲在HBase中，比較適合配合Hive使用，基於Hive進行Ad hoc查詢，基於Kylin進行互動式的數據分析。

首先，數據倉庫基於hive的應用是個技術問題。二者並沒有必然的聯繫，縱然看似hive是底層基於mapreduce計算引擎的數據倉庫，但實際上只是把sql轉換成一個或者多個mapreduce的查詢介面，可以用來做相對高延時的ad hoc查詢，也同樣可以用來做etl的批處理工作。如果只是應用的角度來看的話跟傳統的關係型資料庫就有一定的相似性，只是數據倉庫的工具。

其次，數據倉庫維度建模是個理論問題。為什麼說它是個理論問題呢？它的產生是源自數據倉庫大師kimball的《維度建模工具箱》提出的概念，提供了數據倉庫建模的另一套理論，基於事實表和維度表的數據倉庫建模。在某些零散的業務場景及某些業務的各個環節的建模是高效的，能夠有很好的擴展性，並且從一定程度上能夠屏蔽需求的變化所帶來的變化。當然有利也有弊，相對基於主題域的實體關係建模，雖然有數據倉庫匯流排可以把各個事實表統一起來，但是對於整個業務的按主題進行高度的抽象和歸納，按各個主題的域確定數據的邏輯存儲，這樣的一套清晰的理論，維度建模還是顯得不夠穩定和缺乏企業級的規劃，而且有很大冗餘。

結論，既然這兩項並不衝突為何不能融合到一起用呢，對於底層技術工具的選型是平台架構師考慮的，而選取合適的建模方式是數據倉庫架構師考慮的。

1、先聊可不可以

維度建模，是數據倉庫模型設計的一種方法理論；

Hive，是搭建數據倉庫的一種工具。

所以，基於某方法論（維度建模）、利用某工具（Hive）搭建數據倉庫，肯定是可以的。

2、再聊合不合適

我建議先去比較下Hive與傳統數據倉庫有什麼差別？

單純的基於Hive，只適合做批量的離線計算（MR）；

如果有OLAP分析需求、對查詢響應要求很高，建議引入上層分析工具。

比如：Kylin——OLAP、Impala——基於內存...

同時再對存儲的數據結構做調整優化（文本轉Parquet、壓縮、索引...）

好了，這下常用的數據場景都能支持了。

首先我覺得hive的定位是大量數據的非實時性處理，hive是使用分散式的架構去處理各種數據，換句話說就是ETL工具，而且無法達到實時處理數據的要求。而維度建模，是針對關係係數據數據分析查詢為目標設定一套數據組織方法。假如我們最終的分析數據要存儲在關係型資料庫中，我們就可以考慮維度建模。但是hive作為etl工具，可以把我們要存儲在關係型資料庫中的數據先加工出來，但是直接基於hive的去查詢這些數據顯然無法滿足數據應用需要快速響應的要求。

針對你這個問題本身，沒問題。

新版本的hive已經支持ACID，可以應對緩慢變化維的情況，性能問題也可以切換spark計算引擎。對報表輸出用impala。

Kylin就可以的，如上面的大牛所說，直接用Hive去做維度建模，顯然不合適。而Kylin的設計者曾經說過，他們做Kylin之初是使用的Kimball的維度建模架構。

在使用了一段時間的Kylin之後感覺Kylin還是挺強大的，目前的1.5.3的缺點是只能支持星型模型。

另外，OLAP和維度建模這種技術活還是跟業務扯不開關係，沒有具體的業務，何談OLAP和維度建模需求？然而很多團隊在業務分析上走了很多冤枉路，浪費了很多時間。

1.維度建模難點在於需要對業務過程的分解，但超大規模的企業中業務流程非常複雜，不是不好用，是很少有業務專家能準確合理地拆解業務過程為合理的維度模型，不是大型企業級不適用，而是缺乏具備足夠業務能力的建模專家而已，但中小型項目還是非常順手的。這大概也是IIW和LS-FDM均為範式建模的原因吧。

2.Hive不「太」適用維度建模，主要是數據分布計算的特性，就如同Teradata等MPP計算形態的產品，Pi主索引的分布計算選擇對性能有較大限制，維度建模後性能可能是個問題，除非維度建模功力較深，且join index等性能策略設置合理，能有效解決多維度關聯時數據重分布性能問題，否則hive跑起來恐怕M/R次數極多。

是不是可以考慮上impala