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

Excel 能存儲(chǔ)的數(shù)據(jù)量有限，一般以一百萬(wàn)條為界限，超過(guò)這個(gè)數(shù)量級(jí)運(yùn)行起來(lái)就很慢且會(huì)程序崩潰；

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

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

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

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

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

02 數(shù)據(jù)庫(kù)or數(shù)據(jù)倉(cāng)庫(kù)？

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

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

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

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

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

數(shù)據(jù)倉(cāng)庫(kù)起到了對(duì)不同平臺(tái)、不同來(lái)源的數(shù)據(jù)，進(jìn)行整合的作用；

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

03 一個(gè)栗子

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

04 歸納總結(jié)

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

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

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

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

-END-