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

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

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

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

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

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

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

02 數(shù)據(jù)庫or數(shù)據(jù)倉庫？

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

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

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

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

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

數(shù)據(jù)倉庫起到了對不同平臺、不同來源的數(shù)據(jù)，進(jìn)行整合的作用；

數(shù)據(jù)倉庫順應(yīng)了大數(shù)據(jù)時代數(shù)據(jù)爆炸的現(xiàn)狀與趨勢，以分布式存儲與計(jì)算的方法，提高了計(jì)算機(jī)對數(shù)據(jù)的處理能力；

03 一個栗子

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

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

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

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

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

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

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

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

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

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

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

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

在小明負(fù)責(zé)的拷貝庫經(jīng)過ETL工具整合了越來越多不同平臺的數(shù)據(jù)以后，終于可以名正言順的稱其為數(shù)據(jù)倉庫了。該數(shù)倉因?yàn)檎狭斯靖鞔笃脚_的數(shù)據(jù)，所以可以進(jìn)行各種復(fù)雜、多維度的統(tǒng)計(jì)分析工作，例如：統(tǒng)計(jì)各類不同渠道來源的流量數(shù)據(jù)PV、UV、DAU；結(jié)合公司的人力資源結(jié)構(gòu)情況計(jì)算ROI；分析買家在不同垂類商品、不同時期下的復(fù)購情況等。

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

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

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

04 歸納總結(jié)

通過以上這個巨漫長的栗子，不知道大家對數(shù)據(jù)倉庫的認(rèn)識有沒有更加直觀深入一丟丟呢?？偠灾?，我們還是給數(shù)據(jù)倉庫再寫一段歸納性的總結(jié)作為收尾：

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

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

現(xiàn)在，你對數(shù)據(jù)倉庫的前世今生，了解了么？

-END-