資料庫
說到資料庫，我們一般是指傳統的關係型資料庫，也就是“聯機事務處理”（OLTP），主要使用者線上交易處理。比如銀行業務、電信業務之前很多都是Oracle或者DB2（可能現在很多開發者沒再用過），到後來的網際網路電商用的MySql，這些都是關係型資料庫。
後來有了newSQL、NoSQL（not only sql），現在也分了很多種類，比如大型網際網路公司儲存使用者畫像的HBase，還有用於儲存文件，日誌，問答等內容的文件資料庫MongoDB，建議大家都去了解一下。
關係型資料庫，大多都有主鍵這個概念。比如我可以透過手機號（主鍵）來查詢使用者都儲存的什麼資訊。
資料倉庫
資料倉庫：資料倉庫系統的主要應用主要是OLAP（On-Line Analytical Processing），支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。
資料倉庫彙總有可能有很多維度資料的統計分析結果，取百家之長（各個資料來源的資料），成就自己的一方天地（規劃各種業務域的模型，指標）。
舉個栗子~
車聯網早期是肯定沒有資料倉庫的，剛開始啟動階段就是車上傳送什麼資料我就儲存什麼資料，比如出現告警，就實時展示出來給使用者。
慢慢的車多了，傳統的關係型資料庫已經受不了壓力了，就需要我們升級架構，多個伺服器，多個業務庫。這個階段的業務指標還可以勉強從業務資料庫裡查詢。
隨著業務的發展，資料爆發式增長，公司的大神越來越多。和其他部門的聯絡也越來越緊密，業務的同事知道有這個好工具，也行用一下。負責電池的王老師來了說，我想知道現在咱們車輛的充電情況分佈和天氣是否有關係。程式猿小A說，“好的，但是需要等一個月我把天氣資料爬下來，在把充電資料跑一下，然後再彙總一下就好了”。王老師默默的走了，再也沒有來找過小A。
慢慢越來越多的王老師來了，發現我們都無法及時解決問題。公司的CIO就要求我們想辦法了。這時候【資料倉庫】來了，我們把各種渠道收集的資料提前做好模型（初級資料彙總）。分各個業務主題，很多個表。比如電池就有一個主題了。這次小A主動聯絡王老師，表達了可以提供各種服務（在繁雜的SQL苦中作樂）。
參考書籍《資料倉庫工具箱》
後來越來越多的王老師來找小A，包括其他部門的程式小姐姐。小A不想被一群小姐姐再煩了，於是設計了“資料中臺”
總結
說了這些資料倉庫有什麼過過人之處，第一提高生產力，第二，多源關係資料管理。資料倉庫不是一個元件（技術），更像是一種方法論。
為什麼前兩年大資料環境下，資料倉庫概念火了。其一，以前做過傳統電信行業資料倉庫的先行者，沒有及時佈道（畢竟之前沒有微信這種好工具）。其二，網際網路行業的興起，資料量暴增，需求場景更明確了。其三，技術和方法論都是靠傳播的，技術人的宣傳，加上阿里出版的一些書籍（大資料之路）對此專業都推動巨大。
