前言：筆者自2019年碩士畢業(yè)，先后任職于兩家一線互聯(lián)網大廠，加上實習經歷在數據行業(yè)已經摸爬滾打近5年。近來愈發(fā)認識到工作中自我沉淀的重要性，既是對自己日常工作的梳理總結，也可以幫助到一些數據新人少走彎路。本篇從數據庫引申到數據倉庫，用一個生動形象的例子來介紹數據倉庫的特性與必要性。了解數據底層可以幫助我們更好的去做數據相關工作，如果本篇文章能幫助到屏幕前困惑的你，會讓我很開心。

Excel 能存儲的數據量有限，一般以一百萬條為界限，超過這個數量級運行起來就很慢且會程序崩潰；

Excel穩(wěn)定性并不好，我相信大家肯定都有過 Excel卡死然后數據丟失的經歷； 

為什么Excel會有諸如此類這些缺點呢？說白了，因為像Excel這種工具它根本不是為了存儲數據而生，它的主要功能是對小量級的數據做一些輕量級處理加工，使用門檻低。但也決定了它絕對不可能被工業(yè)界應用于大量級數據的記錄、存儲及運算。

相比被大眾廣泛使用的Excel，數據庫這種東西則顯得更加小眾和專業(yè)化一些。和上者比起來，數據庫的優(yōu)勢在于存儲的數據量更加龐大、運行起來更加穩(wěn)定。我們實在無法想象類似淘寶、天貓這種巨大的互聯(lián)網電商平臺，在使用時突然存儲數據的工具崩了，將會造成多大量級的損失。

從某種程度來講，數據庫這種工具就是為數據的安全、穩(wěn)定兜底而存在的。此外，還需要同外部系統(tǒng)工具有良好的交互性，畢竟數據不是存進去就完事，如何應對頻繁地增、刪、改、查所帶來的IO壓力，以及在高并發(fā)場景下所能承受的數據洪流壓力，都是數據庫的系統(tǒng)設計者需要考慮的問題。可以說 ，數據庫這個方向在整個計算機科學領域內，都占有重要的地位，而數據庫方向的研究者也歷來是圖靈獎的得獎大戶。

在如今高度信息化、智能化的社會里，無處不在的信息系統(tǒng)背后都少不了數據庫的身影，你在各種APP中的每一次瀏覽、每一次上傳、每一次下載、每一次下單，每一次行為，背后可能都對應著數據庫的一條數據變化，是數據庫幫我們承載了人類社會越來越多、越來越龐大的數據流量洪峰。

02 數據庫or數據倉庫？

說到這里，大家應該已經對數據庫有了一個基本認知。但是數據庫與數據倉庫有什么本質區(qū)別呢？我先用專業(yè)術語來描述一下這兩者的區(qū)別，數據處理大致可以分成兩大類：聯(lián)機事務處理OLTP（On-line transaction processing ）、聯(lián)機分析處理OLAP（On-Line Analytical Processing）。我們所說的數據庫屬于OLTP類型，側重于基本的、日常的事務處理，例如銀行交易。而本文的主角數據倉庫則屬于OLAP類型，側重于復雜的分析、查詢操作，為業(yè)務提供決策支持。

當然以上這一大段專業(yè)描述，不是數據相關從業(yè)者沒有數據倉庫基礎的人基本看不懂。所以接下來我會帶大家進入一個具體業(yè)務場景，結合實際的例子去講解數據倉庫的前世今生。

在打造業(yè)務場景之前，我們先總結一下數據倉庫的幾個特點，供大家在接下來的業(yè)務場景中慢慢體會：

數據倉庫的誕生，其本質目的是將兩種不同作用的庫分開，讓數據的采集與計算解耦；

數據倉庫的數據產出具有T+1的特性，即今天看到的是昨天的報表（本文主要針對傳統(tǒng)離線數倉）；

數據倉庫起到了對不同平臺、不同來源的數據，進行整合的作用；

數據倉庫順應了大數據時代數據爆炸的現狀與趨勢，以分布式存儲與計算的方法，提高了計算機對數據的處理能力；

03 一個栗子

有一個程序猿，我們叫他小明。小明就職于一家電商公司，負責電商系統(tǒng)中很重要的一個子模塊—— “訂單交易”模塊的開發(fā)與維護。既然系統(tǒng)中存著大量訂單數據，老板自然想根據這些訂單數據做一些報表，以便運營和管理者更直觀、更方便地探查業(yè)務現狀。小明根據老板的需求，寫了幾個SQL腳本，直接查詢線上數據導入BI系統(tǒng)，方便老板可以隨時隨地跟蹤、觀測公司的業(yè)務經營狀況。老板很滿意，并期望可以將這種數據能力輸出到全公司，讓下游相關的同學都有自己所需數據可以看。

很快，運營同學也根據自己的需要，提出了相關的數據需求，并且各業(yè)務線的運營同學提出的需求千差萬別、口徑紛繁不一，小明只能硬著頭皮開發(fā)各種SQL腳本上線。同時，各業(yè)務線的數據分析師也通過申請，直連線上數據庫進行各種探索、分析查詢。大家都根據自己的需求用上了數據，儼然一副 “數字化轉型”成功的樣子，但是身為后端程序猿的小明卻隱隱覺得事情不對勁。

因為最近，越來越多人反饋線上的系統(tǒng)變慢，小明一查后臺監(jiān)控嚇了一跳。原來是自己開發(fā)的各類報表、以及分析師的SQL查詢擠占了本應屬于線上庫的計算、IO資源，影響了其正常運行。這可不行啊，雖然大家看數據用數據重要，但線上系統(tǒng)的穩(wěn)定性更重要。舍棄線上系統(tǒng)穩(wěn)定而去追逐數字化，是本末倒置。于是小明思考，如何在滿足大家取數用數的同時，還能兼顧線上系統(tǒng)的穩(wěn)定運行呢？

這樣就引出了我們對數據倉庫總結的特性一：數據倉庫的誕生，其本質目的是將兩種不同作用的庫分開，讓數據的采集與計算解耦。如果數據的采集用一個庫，數據的探索、分析查詢用另一個庫，是不是就能最大程度避免對線上系統(tǒng)的影響呢？于是小明定時將線上庫的數據copy一份到另一個拷貝庫，以后所有探索、分析查詢都在拷貝庫進行，那么所有的計算、IO壓力都被轉嫁到拷貝庫了。線上庫其實只需要承受一次數據copy帶來的IO壓力，其他的壓力則都煙消云散。

此外，由于數據的 采集與計算 解耦了，所帶來的另一個變化是——線上數據庫（OLTP）逐漸偏重于針對單條數據的高頻操作；而拷貝庫（OLAP）則逐漸偏重于大范圍的整表掃描、聚合等復雜的分析、查詢操作。

想象一下，OLTP最典型的應用場景：熱門商品秒殺、火車票搶購、支付寶雙十一支付，這些場景都有一個共同特點：在極短的時間內進行極高頻次地增、刪、改、查。要在與數據流量洪峰交互的同時，還要保證系統(tǒng)穩(wěn)定性和數據線程安全，但其操作對象僅僅是針對單條數據或多條數據。

而OLAP最典型的應用場景：制作數據報表、供分析師和運營做數據探查、對全量數據做核心挖掘，這些場景則具有另一個共同的特點：低頻，但對數據的運算量、吞吐量要求高，可以容忍一定時間的延遲和等待，但每執(zhí)行一次查詢，其操作對象針對的則是十萬、百萬、千萬甚至上億的數據量級。

事實上，由于應用場景不同，工業(yè)界對其不斷地更新、優(yōu)化、迭代，這兩種不同工具之間的差異已經愈發(fā)明顯，就像生物界的物種分化一樣，雖然擁有相同的祖先，但在不同環(huán)境下逐漸進化成了兩個物種。雖然都是用來處理數據的，雖然看上去都能存儲結構化的表數據，雖然都支持SQL查詢，但在其本質和內核層面，已經完全是兩個不同的 “物種” 。

話題說回小明的場景，在引入拷貝庫以后，雖然解決了擠占線上系統(tǒng)資源的問題，但又帶來了另一個問題——數據更新的實時性，這便引出了我們對數據倉庫總結的特性二：數據倉庫的數據產出具有 T+1的特性，即今天所看到的是昨天的報表（本文僅針對傳統(tǒng)離線數倉，實時數倉并不包含在內）。因為數據的采集與計算解耦了，所帶來的另一個結果就是——承載計算、IO壓力的拷貝庫無法實時更新。

從線上庫copy數據到拷貝庫，一天只發(fā)生一次（業(yè)內通常采用的做法是copy的時間定為凌晨12點，該時間段內用戶熱度小，數據copy帶來的IO壓力能被有效減輕），線上庫新增、更新的數據，要等到第二天才能被拷貝庫獲取，所以在這種模式下，基本是T+1的數據產出模式。

自從大批量復雜的分析、查詢操作被從線上庫剝離出去之后，線上系統(tǒng)的穩(wěn)定性得到了強保障，讓老板甚是滿意。各方源源不斷的數據需求被提了過來，小明所負責的數據域開始不僅僅局限于訂單交易系統(tǒng)了，這雖然是好事，但與此同時也伴隨著更大的挑戰(zhàn)。其中面臨的一個重要挑戰(zhàn)是，新納入小明負責范圍的系統(tǒng)，底層并不都是采用相同的數據庫。以訂單系統(tǒng)交易為例，數據庫采用的是互聯(lián)網常用的MySQL，而公司的人力資源系統(tǒng)PeopleSoft的底層數據庫則是Oracle，除此之外，一些邊緣系統(tǒng)的底層還采用了SQLServer、PostgreSQL，甚至在一些特定的業(yè)務場景下還會采用MongoDB、Redis這種非關系型NoSQL數據庫。

這可讓小明感到大為頭疼，之前自己只負責訂單交易系統(tǒng)，從線上庫到拷貝庫都是MySQL，所以數據同步很容易。而在不同數據庫之間進行數據同步，必須要借助Kettle或Informatica這種ETL工具，這就引出了我們對數據倉庫總結的特性三：數據倉庫起到了對不同平臺、不同來源的數據，進行整合的作用。事實上，在真正的工業(yè)界、大中型企業(yè)里絕不會僅僅采用一種數據庫作為生產工具，一定是多種數據庫并存的。這就帶來一個問題，底層采用不同數據庫的軟件系統(tǒng)數據不能互通，造成了嚴重的數據孤島現象。導致其本來應該發(fā)揮的重要作用被大打折扣，這將會嚴重地影響企業(yè)的數字化轉型。所以整合不同平臺的數據也是數倉誕生的重要使命之一。

在小明負責的拷貝庫經過ETL工具整合了越來越多不同平臺的數據以后，終于可以名正言順的稱其為數據倉庫了。該數倉因為整合了公司各大平臺的數據，所以可以進行各種復雜、多維度的統(tǒng)計分析工作，例如：統(tǒng)計各類不同渠道來源的流量數據PV、UV、DAU；結合公司的人力資源結構情況計算ROI；分析買家在不同垂類商品、不同時期下的復購情況等。

隨著數據分析、探索工作的不斷深入，越來越多的SQL腳本上線，也隨著公司的電商業(yè)務不斷做大，各類數據以指數型的速度爆炸式增長，終于有一天數據倉庫承受不住了。

還記得上文我們講過OLTP和OLAP的區(qū)別么？本質上小明所搭建的數據倉庫是采用OLTP功能為主的MySQL為基石，大范圍大批次的復雜分析、查詢操作并不是它的強項。并且MySQL是單機的，更加難以承受日漸擴張的龐大運算量，也就引出了我們對數據倉庫總結的特性四：數據倉庫順應了大數據時代 數據爆炸的現狀與趨勢，以分布式存儲與計算的方法，提高了計算機對數據的處理能力。

小明想到市面上很火熱的分布式計算系統(tǒng)架構Hadoop能利用廉價普通的PC機搭建集群，實現分布式數據存儲和計算。通過查閱資料以后，小明發(fā)現Hadoop其中的一個組件Hive能將結構化的數據文件映射為一張數據庫表。且能將復雜的Mapreduce程序翻譯為簡單的SQL語句，支持SQL查詢，非常適合用來當作數據倉庫（實際上，99%互聯(lián)網公司的數據倉庫是用 Hive搭建的，在很多人眼里 數據倉庫 ≈ Hive，這種說法固然片面，但也側面反映了 Hive的影響力之強大）。

04 歸納總結

通過以上這個巨漫長的栗子，不知道大家對數據倉庫的認識有沒有更加直觀深入一丟丟呢?？偠灾覀冞€是給數據倉庫再寫一段歸納性的總結作為收尾：

數據庫與數據倉庫，本質上同宗同源，且存續(xù)相依，只是因為業(yè)務場景需求的不同，逐漸分化成了側重點不同的兩種工具。如果將數據庫比做一艘海上快艇，那數據倉庫則更像一艘巨型的貨運郵輪，前者靈巧、輕便、好掉頭且在海上穿梭自如，適合零碎貨物的高頻轉運。而后者笨重、體型龐大、不便于頻繁調整航行方向，且巨型郵輪本身的啟動、運轉就會耗費大量的時間，但是一旦啟動完成，其所能容納承載的貨物量遠非快艇可比。

數據倉庫的本質，其實是大數據時代數據爆炸所衍生的產物。其作為一個大平臺，整合各系統(tǒng)無序、雜亂、口徑不一的數據，消除數據孤島、提升可用的數據質量。另一方面借助分布式計算系統(tǒng)架構，讓數據的采集與計算解耦，在保障線上系統(tǒng)正常運行的同時，還能有效支撐大批量復雜的分析、查詢操作。在當今火熱的 “大數據時代”，數據是一座金礦，更是各大互聯(lián)網巨頭賴以生存的血脈，而對于傳統(tǒng)公司來講，想要提高企業(yè)效率，數字化轉型則是必不可少的。而數據倉庫就是這一切所仰仗的基石，少了這塊東西，在數據的世界里就如同人被抽走心臟。數據會像靜止的血液一般，重要但卻無法正常流轉。

現在，你對數據倉庫的前世今生，了解了么？

-END-