個人理解，資料倉庫其實也是資料庫的一種應用型別，主要與線上事務處理的資料庫進行區別，資料倉庫中的資料一般都是從生產系統中透過抽取，清洗，然後分類儲存形成不同的主題倉庫，最終服務於資料分析（比如BI）等用途

通常情況下基於業務資料庫資料分析人員也能完成資料分析需求，但是為什麼要建資料倉庫？

沒有資料倉庫時，我們需要直接從業務資料庫中取資料來做分析。

業務資料庫主要是為業務操作服務的，雖然可以用於分析，但需要很多額度的調整。

一，業務資料庫中存在的問題

基於業務資料庫來做分析，主要有以下幾個問題：結構複雜，資料髒亂，難以理解，歷史缺失，資料量大時查詢緩慢。

結構複雜

業務資料庫通常是根據業務操作的需要進行設計的，遵循3NF正規化，儘可能減少資料冗餘。這就造成表與表之間關係錯綜複雜。在分析業務狀況時，儲存業務資料的表，與儲存想要分析的角度表，很可能不會直接關聯，而是需要透過多層關聯來達到，這為分析增加了很大的複雜度。

資料髒亂

因為業務資料庫會接受大量使用者的輸入，如果業務系統沒有做好足夠的資料校驗，就會產生一些錯誤資料，比如不合法的身份證號，或者不應存在的Null值，空字串等。

理解困難

業務資料庫中存在大量語義不明的操作程式碼，比如各種狀態的程式碼，地理位置的程式碼等等，在不同業務中的同一名詞可能還有不同的叫法。

這些情況都是為了方便業務操作和開發而出現的，但卻給我們分析資料造成了很大負擔。各種操作程式碼必須要查閱文件，如果操作程式碼較多，還需要了解儲存它的表。同義異名的資料更是需要翻閱多份文件。

缺少歷史

出於節約空間的考慮，業務資料庫通常不會記錄狀態流變歷史，這就使得某些基於流變歷史的分析無法進行。比如想要分析從使用者申請到最終放款整個過程中，各個環節的速度和轉化率，沒有流變歷史就很難完成。

大規模查詢緩慢

當業務資料量較大時，查詢就會變得緩慢。

二，資料倉庫解決方案

上面的問題，都可以透過一個建設良好的資料倉庫來解決。

業務資料庫是面向操作的，主要服務於業務產品和開發。

而資料倉庫則是面向分析的，主要服務於我們分析人員。評價資料倉庫做的好不好，就看我們分析師用得爽不爽。因此，資料倉庫從產品設計開始，就一直是站在分析師的立場上考慮的，致力於解決使用業務資料進行分析帶來的種種弊端。

資料倉庫解決的問題

結構清晰，簡單

資料倉庫不需要遵循資料庫設計正規化，因此在資料模型的設計上有很大自由。

資料模型一般採用星型模型，表分為事實表和維度表兩類。

其中事實表位於星星的中心，儲存能描述業務狀況的各種度量資料。

維度表圍繞在事實表的周圍，透過外來鍵一對一的形式關聯，提供了看待業務狀況的不同角度。

星型模型使用方便，易於理解，聚焦於業務。

當我們做資料分析時，首先選定主題，比如分析使用者註冊情況；其次根據選定的主題找到對應的業務資料來源，然後觀察業務資料來源提供了哪些分析角度，最後根據資料進行分析。

星形模型非常適合這個思路，並且大大簡化了這個過程。下面以我們目前的模型來舉例。

可複用，易拓展

星型模型不僅便於理解和使用，而且維度表還便於重複使用，維度表中欄位易於拓展。

比如日期維度表，不僅可以被不同的事實表是使用，在同一張事實表裡也可被複用，比如一個事實表裡不同的操作日期，一個商品的訂單有建立日期、付款日期、發貨日期、退款時間、收貨時間等等。

維度表中欄位易於擴充套件，只要保證維度資料的主鍵不變，直接在維度表裡新增新的欄位內容即可，新增的新內容只會影響到維度表而已。而且，維度表通常資料量不大，即使完全重新載入也不需要花費多少時間。

資料乾淨

在ETL過程中會去掉不乾淨的資料，或者打上標籤，使用起來更為方便。

注：由於資料清洗需要建立一定的規則，而目前的工作重心是資料建模和ETL系統設計，沒有額外的時間精力設計清洗規則。為了保證資料的完整性，沒有在當前的ETL中做清洗。

資料語義化／統一描述

各種狀態都可以直接寫成具體的值，不再需要使用操作碼進行查詢，SQL語句更自然，更易理解。

對於部分常用的組合狀態，可以合併成一個欄位來表示。比如在還款分析中，需要根據還款狀態、放款狀態／發貨狀態的組合來篩選出有效的訂單，可以直接設定一個訂單有效的欄位，簡化篩選條件。

對於同一含義的資料在不同情境下的表示，也可以統一描述了。比如對於放款日期的描述，在產品是消費貸時，指的是發貨的日期，產品是現金貸時，指的是放款給使用者的日期。這兩個日期都是表示放款日期，就可以統一起來，同樣也簡化了篩選條件。

儲存歷史

資料倉庫可透過拉鍊表的形式來記錄業務狀態變化，甚至可以設計專用的事實表來記錄。只要有歷史分析的需要，就可以去實現。

高速查詢

資料倉庫本身並不提供高速查詢功能。只是由於其簡單的星形結構，比業務資料庫的複雜查詢在速度上更有優勢。如果仍然採用傳統的關係型資料庫來儲存資料。在資料量上規模之後，同樣也會遇到查詢緩慢的問題。

但是，使用Hive來儲存資料，再使用基於Hive構建的多維查詢引擎Kylin，把星型模型下所有可能的查詢方案的結果都儲存起來，用空間換時間，就可以做到高速查詢，對大規模查詢的耗時可以縮短到次秒級，大大提高工作效率。

資料庫按照操作的資料模型劃分，可以分為關係型資料庫、鍵-值資料庫、文件資料庫、圖資料庫、等等。

資料倉庫，則彙總了各個資料來源的有價值資料。這些資料來源可能包括公司內部系統的資料庫、電子表格等，也可能是來自外部機構如社交網站、銀行等。

透過對資料倉庫中的資訊進行分析和挖掘，可以從各個時間、區域、等維度對業務情況進行彙總分析，如：“雙十一活動”的各種資料報告，哪個省份的人最愛買什麼，等等。

我看了下下面已經有的答案，大家從理論層面把資料庫和資料倉庫的本質區別解釋的很全面了，我就給大家舉個實際例子吧，方便大家看懂。

資料庫：傳統的關係型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。

資料倉庫：資料倉庫系統的主要應用主要是OLAP（On-Line Analytical Processing），支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。

我嘗試著再補充些具體的事例來說明，這樣更可以幫助大家更好理解一些。

舉個最常見的例子，拿電商行業來說好了。

基本每家電商公司都會經歷，從只需要業務資料庫到要資料倉庫的階段。

電商早期啟動非常容易，入行門檻低。找個外包團隊，做了一個可以下單的網頁前端 + 幾臺伺服器 + 一個MySQL，就能開門迎客了。這好比手工作坊時期。第二階段，流量來了，客戶和訂單都多起來了，普通查詢已經有壓力了，這個時候就需要升級架構變成多臺伺服器和多個業務資料庫（量大+分庫分表），這個階段的業務數字和指標還可以勉強從業務資料庫裡查詢。初步進入工業化。第三個階段，一般需要 3-5 年左右的時間，隨著業務指數級的增長，資料量的會陡增，公司角色也開始多了起來，開始有了 CEO、CMO、CIO，大家需要面臨的問題越來越複雜，越來越深入。高管們關心的問題，從最初非常粗放的：“昨天的收入是多少”、“上個月的 PV、UV 是多少”，逐漸演化到非常精細化和具體的使用者的叢集分析，特定使用者在某種使用場景中，例如“20~30歲女性使用者在過去五年的第一季度化妝品類商品的購買行為與公司進行的促銷活動方案之間的關係”。這類非常具體，且能夠對公司決策起到關鍵性作用的問題，基本很難從業務資料庫從調取出來。原因在於：業務資料庫中的資料結構是為了完成交易而設計的，不是為了而查詢和分析的便利設計的。業務資料庫大多是讀寫最佳化的，即又要讀（檢視商品資訊），也要寫（產生訂單，完成支付）。因此對於大量資料的讀（查詢指標，一般是複雜的只讀型別查詢）是支援不足的。而怎麼解決這個問題，此時我們就需要建立一個數據倉庫了，公司也算開始進入資訊化階段了。資料倉庫的作用在於：資料結構為了分析和查詢的便利；只讀最佳化的資料庫，即不需要它寫入速度多麼快，只要做大量資料的複雜查詢的速度足夠快就行了。

那麼在這裡前一種業務資料庫（讀寫都最佳化）的是業務性資料庫，後一種是分析性資料庫，即資料倉庫。

最後總結一下：

資料庫 比較流行的有：MySQL, Oracle, SqlServer等資料倉庫 比較流行的有：AWS Redshift, Greenplum, Hive等

這樣把資料從業務性的資料庫中提取、加工、匯入分析性的資料庫就是傳統的 ETL 工作。現在也有一些新的方法，這展開說又是另一件事情了，我的文章裡也有寫到，有機會再詳細說說。

資料倉庫知多少

首先，來了解一下資料倉庫吧！資料倉庫是一個面向主題的、整合的、相對穩定的、反應歷史變化的資料集合。

我們來看這幾個詞：

面向主題，資料倉庫會規劃各種業務主題，所以我們需要理解各大主題的範疇以及之間的關係，這樣就瞭解了資料倉庫的基本架構。整合，資料倉庫的資料會來自各個業務系統資料或者外部爬取資料，所以需要我們知道每個資料倉庫的模型欄位都是來自哪個源，這樣我們就能快速全面的瞭解相關業務。相對穩定，資料倉庫的資料一般不會實時變化，所以我們今天看去年的資料和明天看去年的資料是一樣的，如果我們發現某一個月度資料不對，就可能需要重新彙總歷史月份每天的資料（請理解數數倉小夥伴們沒及時給你資料）反應歷史變化，這就是為什麼預測一般就需要資料分析師們大顯身手了。如何利用資料倉庫最佳化資料分析

首先資料分析又是幹什麼的呢？基於業務需求，結合歷史資料，利用相關統計學方法和某些資料探勘工具演算法對資料進行整合、分析，並形成一套最終解決某個業務場景的方案（剛入門資料分析的淺顯思考）。

聽團隊小夥伴說，在資料分析的過程中有大部分的工作都是在處理資料（大部門分我認為是60%工作量），所以為了提高工作效率和質量，藉助資料倉庫進行資料分析無疑是一個很好的選擇。

如何來使用資料倉庫呢？瞭解原始資料，想要真正地理解指標，你必須瞭解原始明細資料，知道是哪裡來的，經過了怎樣維度的計算得到的。尋找“乾淨”資料，資料分析要求資料都是“乾淨的”（可以作為演算法特徵輸入），而資料倉庫中的模型一般都符合你的要求。我們需要找到“乾淨的”模型，但事實往往不會很順利，我們需要找到相近的資料，然後自己找到之間同的“紐帶”（關聯條件）彙總資料。反饋資料，資料分析在做完整個分析方案後，可以和資料放倉庫小夥伴一起分享成果，讓資料倉庫同事學習資料分析思路的同時，也可以更好地規劃模型，從而進入良性迴圈。結語

資料倉庫和資料分析都存在的組織架構在很多大團隊會有，很多小團隊是沒有專門的資料分析人員或者資料倉庫人員的，二者是合為一體的。

~

7月5日，Kyligence融資暨新產品釋出會在上海舉行。Kyligence 團隊宣佈正式釋出下一代企業級資料倉庫產品與解決方案Kyligence Enterprise v3.0，及雲端一站式大資料分析解決方案KyligenceCloud v2.0。新版解決方案革命性地實現了自動建模功能，並將在查詢提速15倍的同時節省50%儲存空間。

Kyligence 聯合創始人兼CEO韓卿

　　Kyligence Enterprise v3.0釋出，打造融合、智慧資料倉庫

　　作為本次釋出會的重頭戲之一，Kyligence 聯合創始人兼CTO李揚，詳細介紹了新版Kyligence Enterprise如何在保持PB級資料集上亞秒級查詢響應速度的同時，革命性地實現自動化建模以承載企業日益增長的自動化需求。

　　對於Kyligence Enterprise3.0的行業定位，韓卿認為，它是一個融合智慧的大資料平臺，代表未來資料倉庫的方向。

　　在今天資料呈指數級爆炸的時代，絕大部分的資料倉庫專案仍然使用人工進行操作，這種原始的基於人工的資料分析方式顯然已經遠不能滿足快速增長的業務需求。

　　韓卿表示：“下一代的資料倉庫，一定是融合的、智慧的資料倉庫，透過將這些技術應用到資料倉庫本身的技術變革中，能為許多產業帶來變革。”

　　在產品架構上，新版Kyligence Enterprise 採用了高效能的融合架構，實現了關鍵業務的亞秒級查詢延遲，也支援海量資料的自主探索；資料來源可對接分散式平臺Hadoop的多重資料引擎，也可以對接傳統的RDBMS；資料種類上，既可以對接實時資料流，也可以進行批處理。

　　“對比上一代查詢引擎，新版Kyligence Enterprise 可實現查詢提速15倍的同時節省50%儲存空間，而對比市場上的同類查詢產品，根據資料倉庫典型查詢場景測試中查詢的完成度與查詢的效能比較來看，都具有顯著優勢。”李揚介紹道，Kyligence Enterprise v3.0具有出色的資料分析能力，它的出現將有效降低企業人力成本，併成倍提升企業生產效率。

　　聚焦金融、電信、零售和製造4大領域，要成為資料倉庫行業NO.1

　　在產品釋出會上，Kyligence宣佈完成由斯道資本領投，原有股東紅點中國、思科、寬頻資本、順為資本跟投的1500萬美元B輪融資，這也是Kyligence2年內的第三輪融資。

　　對於本輪融資計劃，韓卿表示，本輪融資後，公司將主要在三個方面加大投入。其中包括加快產品技術研發；擴大市場和銷售團隊，以儘快擴張市場認知度；佈局國際化發展，目前公司已在美國、歐洲拓展客戶，接下來將會尤其在美國進行大規模擴張，真正做到技術出海。

　　目前，Kyligence旗下開發的產品服務已經獲得超30家來自各行各業頭部企業的付費支援，包括國泰君安、華為、聯通、OPPO、上汽集團、太平洋保險集團、中國銀聯等企業。

　　在釋出會圓桌論壇上，太平洋保險大資料平臺負責人時愛民表示，大資料分析作為面向未來的IT技術服務，對太平洋保險而言早已不是一道選擇題，而是一道必答題，太平洋保險之所以選擇與使用Kyligence Enterprise，看中的就是Kyligence的技術實力與長期、持續的服務能力。

　　本輪領投的斯道資本中國風險投資團隊合夥人張柏舟也表示：“我們很榮幸能成為Kyligence 的投資方。我們在盡職調查期間收集了廣泛的客戶意見，Kyligence 突出的能力讓我們印象深刻，比如透過資料建模處理和AI 增強技術來預處理海量資料集並將延遲降低至亞秒級，透過整合Tableau、Power BI 甚至Microsoft Excel 等常用簡單工具來獲取新知，Kyligence 沒有侷限在簡單的分析場景，而是致力於幫助客戶快速而輕鬆地管理、訪問和分析海量資料，遠遠超越了傳統解決方案，堪稱新一代資料倉庫。”

　　目前，Kyligence商業化已經一一落地。韓卿表示，Kyligence的產品服務未來將主要專注於金融、電信、零售和製造四大領域的應用，因為這四大行業擁有大量的資料，對基於資料底層的架構和分析需求渴求極大。

　　就金融而言，韓卿稱，傳統金融機構客戶更願意嘗試成熟的新技術。“有銀行使用我們的技術進行了大半年的全面測試，最後看到他們平臺和技術能力得到很大提升，最終選擇了Kyligence的方案。”

資料庫和資料倉庫有著本質的區別：

資料庫是一個工具，而資料倉庫是一個系統

資料庫這個工具可以用於很多地方，比如ERP系統、CRM系統或者大大小小的網站等；

資料倉庫的本質是一個集成了很多業務或者日誌資料的資料集合，用於支援決策管理，那麼資料倉庫是用什麼儲存這些資料的呢，就是資料庫了。同時資料倉庫還需要ETL工具來負責清洗加工資料，需要排程工具來安排協調資料清洗加工任務的進行，還有資料質量工具、元資料工具等等。資料庫主要是OLTP，而資料倉庫是OLAP

OLTP即聯機事務處理，資料庫主要應用是日常事務處理，比如使用者資訊的增刪改、交易資料的記錄等等；

OLAP即聯機分析查詢，資料倉庫主要應用是資料分析，側重決策支援，支援複雜的聯表操作；如即席查詢、統計報表、資料視覺化等等都是資料倉庫的應用。

資料倉庫的概念提出來快20年了，它的主要目的是為了解決不同的資料庫相互聯接的問題。

各大銀行早已經聯網了，您可以到工商銀行的提款機裡取出存在建設銀行賬戶裡的錢，銀行間匯款也很容易，幾乎可以實時地完成。過去可沒那麼容易，記得有一次去北京出差，沒帶現金只帶了一張本地的銀行卡，結果我的卡在北京用不了，住不進賓館，連飯都吃不上了，只好四處找朋友借現金狼狽不堪。這就是沒有資料倉庫的結果。想知道某個地區資料倉庫用得怎樣，您可以隨便找個小賣部看看能不能用銀行卡或手機買瓶礦泉水。現在連街邊的小販都能用手機支付了，可見在中國資料倉庫的應用有多強了。

各大銀行的資料結構完全不同，把這些連欄位名都不一樣的資料表結合起來可是件傷腦筋的事。人們想了很多辦法，其中就有現在很火的人工智慧。當時打算用人工智慧對資料庫的表結構，資料內容進行分析，自動找到對應關係。理想很豐滿現實很骨感，人工智慧這條路最終也沒有什麼重大突破。現在的資料倉庫基本上都是採取建立上級的彙總資料庫，然後按照不同的邏輯分別同各個下級資料庫同步的方式實現的資料庫聯網。

資料倉庫技術還帶來了一種新的應用方式，這就是分散資料庫的管理。想想看淘寶的交易量那麼大，用單一的資料庫來處理恐怕是遠遠不夠用的，有了資料倉庫技術，就可以把大量的交易資料分散到成千上萬個數據庫中，共同來處理，這就好辦多了。

好了就說這麼多吧，現在您能分清楚資料庫和資料倉庫了嗎？

先講講來龍去脈

很久以前是沒有資料倉庫這個概念的，只有資料庫，資料庫就是很多資料表的集合，這樣把存放不同內容的表放在一起，就能滿足一些基本的查詢了。

比如提取2019年6月18日在淘寶購買Bose耳機的使用者，只要幾張表關聯一下查詢就出結果了。

後來在實際工作中人們發現當你在海量資料中做非常複雜的分析的時候，效率就很低了：比如找到2019年雙11和2018年雙11這兩天，在淘寶下單超過500元且購買了Bose耳機的使用者，這兩撥使用者在最近2兩年的平均消費能力差異。要完成這個查詢，首先要關聯查詢很多表，其次要查詢2018和2019年兩年的資料，最後你還要從海量的資料中找到符合要求的消費金額和消費者，這三點加起來就讓資料提取變成了非常複雜的事兒，而且不一定能立刻查到，往往一個查詢任務就要跑好幾個小時。

所以隨著資料體量增大，查詢條件越來越複雜，大家一看不行啊，需要提高效率。所以資料倉庫出現了。

資料倉庫和資料庫相比，有啥特點

1.資料倉庫有主題性，有作業流的概念

上面的例子告訴我們，資料倉庫是為了某一個/某一類特定的分析任務將資料重新聚合起來的，而資料庫只是資料儲存表的集合，所以資料倉庫有主題性。同時也因為有主題的概念，資料倉庫會根據你預設的邏輯，自動化的完成各個作業之間的排程，最終自動化的把結果輸出給你。所以資料倉庫也會有資料流和作業流的概念。

2.資料倉庫讓「查詢」效率最大化

資料庫本質就是很多資料表，所以資料表嘛，就要兼顧增刪改查這些操作，但是資料倉庫將資料重新組合，是為了讓你更高效的查詢並且支援你的分析工作的，所以資料庫一般只讓「查詢」的效率最大化，「增刪改」的效率不做主要考慮。

3.資料倉庫有歷史資料，而資料庫一般只有近期資料

上面舉的例子中，要查詢淘寶2018年和2019年兩年的雙11資料，所以跨度很大。一般資料庫只能存近期的資料，太久遠的資料放不下，效率也低。但是資料倉庫可以將某些維度的歷史資訊統一抽取出來以更合理的儲存結構放到資料倉庫中，這樣查詢跨年的資料時直接查詢就行了，效率極大的提升。

4.資料倉庫是基於資料庫層面的升級

一家公司，一般是現有幾張資料表，後來資料表集合成了資料庫，再後來資料庫不滿足需求了，才有了資料倉庫。所以資料表，資料庫，資料倉庫之間是有依賴關係的，不是割裂的。

怎麼建立資料倉庫

1.需求分析

分析你為了哪個目的建立資料倉庫，資料倉庫需要哪些維度的資料，這些資料表都在哪裡是否能訪問。

2.ETL

將你所有需要的資料表都找到，然後根據你的需求將需要的欄位都提取出來並對資料格式進行清洗加工轉換。保證資料原料是合格可用的

3.資料結構設計

包括維度表，事實表的設計，是否要用列式儲存代替行式儲存，是否需要將資料分層（詳細可查詢OLAP方面的資料模型），總之就是要保證資料查詢的效率

4.作業排程

每一個你看到的資料背後，都是多個數據表被一系列指令碼呼叫最終計算而成，所以多個作業之間肯定涉及排程關係，過程監控，結果監控等。所以要保證邏輯正確和執行正確。

以上4步完成後，一個數據倉庫的雛形就有了，剩下的資料管理，計算管理，元資料等如果有需要可以在此基礎上不斷新增完善。