以下是一些數(shù)據(jù)倉庫面試題：
1. 什么是數(shù)據(jù)倉庫？
2. 數(shù)據(jù)倉庫的作用是什么？
3. 數(shù)據(jù)倉庫和數(shù)據(jù)庫的區(qū)別是什么？
4. 數(shù)據(jù)倉庫的架構(gòu)是什么？
5. 如何進行數(shù)據(jù)倉庫的建模？
6. 如何進行數(shù)據(jù)倉庫的 ETL 流程？
7. 如何進行數(shù)據(jù)倉庫的性能優(yōu)化？
8. 如何進行數(shù)據(jù)倉庫的備份和恢復(fù)？
9. 如何進行數(shù)據(jù)倉庫的安全管理？
10. 如何進行數(shù)據(jù)倉庫的監(jiān)控和優(yōu)化？
以上是一些常見的數(shù)據(jù)倉庫面試題，你可以根據(jù)自己的經(jīng)驗和知識進行回答。
--建立臨時視圖1，檢索每個部門第一名分?jǐn)?shù)
createorreplaceviewtemp_v1as
select部門號,max(成績)as成績fromEmployeegroupby部門號;
--在臨時視圖1的基礎(chǔ)上建立臨時視圖2，檢索第二名分?jǐn)?shù)
createorreplaceviewtemp_v2as
select部門號,max(成績)as成績fromEmployee
where(部門號,成績)notin(select*fromtemp_v1)
groupby部門號;
--聯(lián)合兩個臨時視圖的查詢結(jié)果，建立臨時視圖3
createorreplaceviewtemp_v3as
select*from
(select*fromtemp_v1unionselect*fromtemp_v2)
orderby部門號,成績;
--建立目標(biāo)視圖
createorreplaceviewVdepEm2as
select部門號,員工號,成績fromEmployee
where(部門號,成績)in(select*fromtemp_v3);
*******************
昨天有點事情耽擱了，這個應(yīng)該可以實現(xiàn)你的要求。如果不允許建立臨時視圖的話，你把這幾個臨時視圖糅進去就可以了。
高層整理倉庫數(shù)據(jù)，數(shù)字筆記，人員運行，另外還包括機器操作等數(shù)據(jù)，也就是查看的意思。
絕對有錢途， 我推薦過兩個大學(xué)畢業(yè)生，做了2,3年月薪都7-8k,如果英語不錯，絕對上萬
數(shù)據(jù)倉庫最吃錢了，許多都是有錢的大公司錢沒地花，大部分的數(shù)據(jù)倉庫在投入前3年都沒有多大的ROI,知道正在開始使用在markting, CRM才會產(chǎn)生更多revenue,但對于基本dashboard,還有作為stratedgy的數(shù)據(jù)基礎(chǔ)。
沒有數(shù)據(jù)倉庫大企業(yè)勢必會失去一些競爭優(yōu)勢，特別是前瞻。
大數(shù)據(jù)主要有三個特點：實時、多樣、量大、價值。大數(shù)據(jù)不僅量大，對于數(shù)據(jù)的處理也成為了最基本的配置。大數(shù)據(jù)還能整合各種各樣的數(shù)據(jù)類型，無論是結(jié)構(gòu)化數(shù)據(jù)還是非結(jié)構(gòu)化數(shù)據(jù)都能夠進行處理。
在這個時代，數(shù)據(jù)依然是最重要的，如何在利用的時候控制好數(shù)據(jù)，是對一個企業(yè)的考驗。數(shù)據(jù)在生活中是無處不在的，手機產(chǎn)生的記錄、移動互聯(lián)網(wǎng)產(chǎn)生的數(shù)據(jù)、取款時產(chǎn)生的數(shù)據(jù)、購物時產(chǎn)生的數(shù)據(jù)、行李從一個城市到另外一個城市產(chǎn)生的數(shù)據(jù)等。就算一個小小的店鋪，賣出一瓶飲料，也會產(chǎn)生數(shù)據(jù)，而數(shù)據(jù)就記錄著這個世界的存在與變化。
當(dāng)某個企業(yè)的數(shù)據(jù)量巨大、資產(chǎn)非常重要時，就需要對它進行管理控制。如今數(shù)據(jù)已經(jīng)成為了企業(yè)的資產(chǎn)。在以前，數(shù)據(jù)被人們看作是附屬物，而不是資產(chǎn)。只要企業(yè)進行交易就會產(chǎn)生這些附屬物，而現(xiàn)在發(fā)現(xiàn)這些交易的數(shù)據(jù)信息中蘊含著用戶的需求，成千上萬條信息積累下來，就能夠準(zhǔn)確的知道用戶的需求，為用戶這幾新的產(chǎn)品，在營銷上就產(chǎn)生了新的價值。所以，數(shù)據(jù)就成為了企業(yè)的資產(chǎn)，需要被管理和控制起來。
近幾年，數(shù)據(jù)的控制管理工具發(fā)展的很緩慢而且它只是一些大型公司的工具，有實力的公司才會為它買單，這就讓數(shù)據(jù)的控制管理變得高高在上，這就讓數(shù)據(jù)作為資產(chǎn)還只停留在理念的層面上。
人們也一直在討論，數(shù)據(jù)倉庫能給企業(yè)帶來什么？數(shù)據(jù)倉庫對數(shù)據(jù)的控制主要體現(xiàn)在以下6個方面：
企業(yè)要通過快速、及時、方便、安全、準(zhǔn)確、整合這6個方面對數(shù)據(jù)庫進行有效的控制。下面具體介紹一下數(shù)據(jù)庫對數(shù)據(jù)控制的體現(xiàn)方面，其內(nèi)容包括以下幾點：
1.對數(shù)據(jù)快速的訪問
利用數(shù)據(jù)倉庫模型中的軟件和硬件對數(shù)據(jù)快速的訪問。比如剛收集來的數(shù)據(jù)，選擇是否需要存儲，或是采用其它的存儲技術(shù)。
2.能確保數(shù)據(jù)的整合性
當(dāng)企業(yè)需要一年內(nèi)的大量數(shù)據(jù)，或者是企業(yè)的視圖數(shù)據(jù)時，需要數(shù)據(jù)庫模型的整合支持。
3.保障數(shù)據(jù)的及時性
當(dāng)數(shù)據(jù)批量抽取不足夠時，需要及時的對數(shù)據(jù)進行數(shù)據(jù)流處理。
4.控制讓數(shù)據(jù)的訪問更便捷
不僅將數(shù)據(jù)以表格的形式進行控制管理，還可以將數(shù)據(jù)以字段的形式進行管理，這樣就可以將數(shù)據(jù)分成更小更細的數(shù)據(jù)進行控制。
5.控制管理后的數(shù)據(jù)能夠保證數(shù)據(jù)一致性，讓數(shù)據(jù)變得更加的可信。
6.對數(shù)據(jù)進行權(quán)限管理
對數(shù)據(jù)加以控制后，可以防止企業(yè)的數(shù)據(jù)外漏，保障了數(shù)據(jù)的訪問安全。
傳統(tǒng)的數(shù)據(jù)庫并不能對數(shù)據(jù)進行分析控制，數(shù)據(jù)倉庫的興起，使傳統(tǒng)的數(shù)據(jù)庫和面向分析的分析型數(shù)據(jù)分離開來，形成各自的形式。數(shù)據(jù)倉庫的形態(tài)一般都是軟硬一體，這樣能夠提供最佳的控制效果。這樣的數(shù)據(jù)庫會采用更先進的查詢技術(shù)，以大規(guī)模并行處理和列式處理為代表。
另外，新興的互聯(lián)網(wǎng)企業(yè)也在嘗試一些性的技術(shù)對大數(shù)據(jù)進行控制，比如谷歌的MapReduce，就能夠?qū)?shù)據(jù)很好的控制。一些相對低廉的數(shù)據(jù)倉庫也能夠降低數(shù)據(jù)控制的門檻，一些小型的公司不必和大型的公司去較真價格。有開源的產(chǎn)品和足夠的硬件存儲，再加上一支專業(yè)的團隊，就可以構(gòu)建一個數(shù)據(jù)倉庫平臺，對數(shù)據(jù)進行有效的控制。
數(shù)據(jù)倉庫的網(wǎng)絡(luò)要求必須擁有穩(wěn)定，而且符合功率的網(wǎng)速條件才可以達到要求
一直想整理一下這塊內(nèi)容，既然是漫談，就想起什么說什么吧。我一直是在互聯(lián)網(wǎng)行業(yè)，就以互聯(lián)網(wǎng)行業(yè)來說。先大概列一下互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)倉庫、數(shù)據(jù)平臺的用途：
整合公司所有業(yè)務(wù)數(shù)據(jù)，建立統(tǒng)一的數(shù)據(jù)中心；
提供各種報表，有給高層的，有給各個業(yè)務(wù)的；
為網(wǎng)站運營提供運營上的數(shù)據(jù)支持，就是通過數(shù)據(jù)，讓運營及時了解網(wǎng)站和產(chǎn)品的運營效果；
為各個業(yè)務(wù)提供線上或線下的數(shù)據(jù)支持，成為公司統(tǒng)一的數(shù)據(jù)交換與提供平臺；
分析用戶行為數(shù)據(jù)，通過數(shù)據(jù)挖掘來降低投入成本，提高投入效果；比如廣告定向精準(zhǔn)投放、用戶個性化推薦等；
開發(fā)數(shù)據(jù)產(chǎn)品，直接或間接為公司盈利；
建設(shè)開放數(shù)據(jù)平臺，開放公司數(shù)據(jù)；
。。。。。。
上面列出的內(nèi)容看上去和傳統(tǒng)行業(yè)數(shù)據(jù)倉庫用途差不多，并且都要求數(shù)據(jù)倉庫/數(shù)據(jù)平臺有很好的穩(wěn)定性、可靠性；但在互聯(lián)網(wǎng)行業(yè)，除了數(shù)據(jù)量大之外，越來越多的業(yè)務(wù)要求時效性，甚至很多是要求實時的 ，另外，互聯(lián)網(wǎng)行業(yè)的業(yè)務(wù)變化非常快，不可能像傳統(tǒng)行業(yè)一樣，可以使用自頂向下的方法建立數(shù)據(jù)倉庫，一勞永逸，它要求新的業(yè)務(wù)很快能融入數(shù)據(jù)倉庫中來，老的下線的業(yè)務(wù)，能很方便的從現(xiàn)有的數(shù)據(jù)倉庫中下線；
其實，互聯(lián)網(wǎng)行業(yè)的數(shù)據(jù)倉庫就是所謂的敏捷數(shù)據(jù)倉庫，不但要求能快速的響應(yīng)數(shù)據(jù)，也要求能快速的響應(yīng)業(yè)務(wù)；
建設(shè)敏捷數(shù)據(jù)倉庫，除了對架構(gòu)技術(shù)上的要求之外，還有一個很重要的方面，就是數(shù)據(jù)建模，如果一上來就想著建立一套能兼容所有數(shù)據(jù)和業(yè)務(wù)的數(shù)據(jù)模型，那就又回到傳統(tǒng)數(shù)據(jù)倉庫的建設(shè)上了，很難滿足對業(yè)務(wù)變化的快速響應(yīng)。應(yīng)對這種情況，一般是先將核心的持久化的業(yè)務(wù)進行深度建模（比如：基于網(wǎng)站日志建立的網(wǎng)站統(tǒng)計分析模型和用戶瀏覽軌跡模型；基于公司核心用戶數(shù)據(jù)建立的用戶模型），其它的業(yè)務(wù)一般都采用維度+寬表的方式來建立數(shù)據(jù)模型。這塊是后話。
整體架構(gòu)下面的圖是我們目前使用的數(shù)據(jù)平臺架構(gòu)圖，其實大多公司應(yīng)該都差不多：
邏輯上，一般都有數(shù)據(jù)采集層、數(shù)據(jù)存儲與分析層、數(shù)據(jù)共享層、數(shù)據(jù)應(yīng)用層?？赡芙蟹ㄓ兴煌?，本質(zhì)上的角色都大同小異。
我們從下往上看：
數(shù)據(jù)采集數(shù)據(jù)采集層的任務(wù)就是把數(shù)據(jù)從各種數(shù)據(jù)源中采集和存儲到數(shù)據(jù)存儲上，期間有可能會做一些簡單的清洗。
數(shù)據(jù)源的種類比較多：
網(wǎng)站日志：
作為互聯(lián)網(wǎng)行業(yè)，網(wǎng)站日志占的份額最大，網(wǎng)站日志存儲在多臺網(wǎng)站日志服務(wù)器上，
一般是在每臺網(wǎng)站日志服務(wù)器上部署flume agent，實時的收集網(wǎng)站日志并存儲到HDFS上；
業(yè)務(wù)數(shù)據(jù)庫：
業(yè)務(wù)數(shù)據(jù)庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種數(shù)據(jù)庫中將數(shù)據(jù)同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數(shù)據(jù)量大小，都需要啟動MapReduce來執(zhí)行，而且需要Hadoop集群的每臺機器都能訪問業(yè)務(wù)數(shù)據(jù)庫；應(yīng)對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構(gòu)數(shù)據(jù)源海量數(shù)據(jù)交換工具-Taobao DataX 下載和使用》），有資源的話，可以基于DataX之上做二次開發(fā)，就能非常好的解決，我們目前使用的DataHub也是。
當(dāng)然，F(xiàn)lume通過配置與開發(fā)，也可以實時的從數(shù)據(jù)庫中同步數(shù)據(jù)到HDFS
來自于Ftp/Http的數(shù)據(jù)源：
有可能一些合作伙伴提供的數(shù)據(jù)，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求;
其他數(shù)據(jù)源：
比如一些手工錄入的數(shù)據(jù)，只需要提供一個接口或小程序，即可完成
數(shù)據(jù)存儲與分析毋庸置疑，HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉庫/數(shù)據(jù)平臺最完美的數(shù)據(jù)存儲解決方案。
離線數(shù)據(jù)分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當(dāng)其沖的選擇，豐富的數(shù)據(jù)類型、內(nèi)置函數(shù)；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基于結(jié)構(gòu)化數(shù)據(jù)上的統(tǒng)計分析遠遠比MapReduce要高效的多，一句SQL可以完成的需求，開發(fā)MR可能需要上百行代碼；
當(dāng)然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很樂意開發(fā)Java，或者對SQL不熟，那么也可以使用MapReduce來做分析與計算；Spark是這兩年非?；鸬模?jīng)過實踐，它的性能的確比MapReduce要好很多，而且和Hive、Yarn結(jié)合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經(jīng)有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關(guān)于Spark On Yarn的相關(guān)文章，可參考：《Spark On Yarn系列文章》
實時計算部分，后面單獨說。
數(shù)據(jù)共享這里的數(shù)據(jù)共享，其實指的是前面數(shù)據(jù)分析與計算后的結(jié)果存放的地方，其實就是關(guān)系型數(shù)據(jù)庫和NOSQL數(shù)據(jù)庫；
前面使用Hive、MR、Spark、SparkSQL分析和計算的結(jié)果，還是在HDFS上，但大多業(yè)務(wù)和應(yīng)用不可能直接從HDFS上獲取數(shù)據(jù)，那么就需要一個數(shù)據(jù)共享的地方，使得各業(yè)務(wù)和產(chǎn)品能方便的獲取數(shù)據(jù)； 和數(shù)據(jù)采集層到HDFS剛好相反，這里需要一個從HDFS將數(shù)據(jù)同步至其他目標(biāo)數(shù)據(jù)源的工具，同樣，DataX也可以滿足。
另外，一些實時計算的結(jié)果數(shù)據(jù)可能由實時計算模塊直接寫入數(shù)據(jù)共享。
數(shù)據(jù)應(yīng)用
業(yè)務(wù)產(chǎn)品
業(yè)務(wù)產(chǎn)品所使用的數(shù)據(jù)，已經(jīng)存在于數(shù)據(jù)共享層，他們直接從數(shù)據(jù)共享層訪問即可；
報表
同業(yè)務(wù)產(chǎn)品，報表所使用的數(shù)據(jù)，一般也是已經(jīng)統(tǒng)計匯總好的，存放于數(shù)據(jù)共享層；
即席查詢
即席查詢的用戶有很多，有可能是數(shù)據(jù)開發(fā)人員、網(wǎng)站和產(chǎn)品運營人員、數(shù)據(jù)分析人員、甚至是部門老大，他們都有即席查詢數(shù)據(jù)的需求；
這種即席查詢通常是現(xiàn)有的報表和數(shù)據(jù)共享層的數(shù)據(jù)并不能滿足他們的需求，需要從數(shù)據(jù)存儲層直接查詢。
即席查詢一般是通過SQL完成，最大的難度在于響應(yīng)速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應(yīng)速度較Hive快很多，而且能很好的與Hive兼容。
當(dāng)然，你也可以使用Impala，如果不在乎平臺中再多一個框架的話。
OLAP
目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數(shù)據(jù)，都是通過將需要的數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)庫中做OLAP，但如果數(shù)據(jù)量巨大的話，關(guān)系型數(shù)據(jù)庫顯然不行；
這時候，需要做相應(yīng)的開發(fā)，從HDFS或者HBase中獲取數(shù)據(jù)，完成OLAP的功能；
比如：根據(jù)用戶在界面上選擇的不定的維度和指標(biāo)，通過開發(fā)接口，從HBase中獲取數(shù)據(jù)來展示。
其它數(shù)據(jù)接口
這種接口有通用的，有定制的。比如：一個從Redis中獲取用戶屬性的接口是通用的，所有的業(yè)務(wù)都可以調(diào)用這個接口來獲取用戶屬性。
實時計算現(xiàn)在業(yè)務(wù)對數(shù)據(jù)倉庫實時性的需求越來越多，比如：實時的了解網(wǎng)站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數(shù)據(jù)下，依靠傳統(tǒng)數(shù)據(jù)庫和傳統(tǒng)實現(xiàn)方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平臺中，另外，Spark Streaming比Storm延時性高那么一點點，那對于我們的需要可以忽略。
我們目前使用Spark Streaming實現(xiàn)了實時的網(wǎng)站流量統(tǒng)計、實時的廣告效果統(tǒng)計兩塊功能。
做法也很簡單，由Flume在前端日志服務(wù)器上收集網(wǎng)站日志和廣告日志，實時的發(fā)送給Spark Streaming，由Spark Streaming完成統(tǒng)計，將數(shù)據(jù)存儲至Redis，業(yè)務(wù)通過訪問Redis實時獲取。
任務(wù)調(diào)度與監(jiān)控在數(shù)據(jù)倉庫/數(shù)據(jù)平臺中，有各種各樣非常多的程序和任務(wù)，比如：數(shù)據(jù)采集任務(wù)、數(shù)據(jù)同步任務(wù)、數(shù)據(jù)分析任務(wù)等；
這些任務(wù)除了定時調(diào)度，還存在非常復(fù)雜的任務(wù)依賴關(guān)系，比如：數(shù)據(jù)分析任務(wù)必須等相應(yīng)的數(shù)據(jù)采集任務(wù)完成后才能開始；數(shù)據(jù)同步任務(wù)需要等數(shù)據(jù)分析任務(wù)完成后才能開始； 這就需要一個非常完善的任務(wù)調(diào)度與監(jiān)控系統(tǒng)，它作為數(shù)據(jù)倉庫/數(shù)據(jù)平臺的中樞，負(fù)責(zé)調(diào)度和監(jiān)控所有任務(wù)的分配與運行。
前面有寫過文章，《大數(shù)據(jù)平臺中的任務(wù)調(diào)度與監(jiān)控》,這里不再累贅。
總結(jié)在我看來架構(gòu)并不是技術(shù)越多越新越好，而是在可以滿足需求的情況下，越簡單越穩(wěn)定越好。目前在我們的數(shù)據(jù)平臺中，開發(fā)更多的是關(guān)注業(yè)務(wù)，而不是技術(shù)，他們把業(yè)務(wù)和需求搞清楚了，基本上只需要做簡單的SQL開發(fā)，然后配置到調(diào)度系統(tǒng)就可以了，如果任務(wù)異常，會收到告警。這樣，可以使更多的資源專注于業(yè)務(wù)之上。
比爾·恩門(Bill Inmon),被稱為數(shù)據(jù)倉庫之父,最早的數(shù)據(jù)倉庫概念提出者,在數(shù)據(jù)庫技術(shù)管理與數(shù)據(jù)庫設(shè)計方面,擁有逾35年的經(jīng)驗。他是“企業(yè)信息工廠”的合作創(chuàng)始人與“政府信息工廠”的創(chuàng)始人。
包括表的名字，表的列和分區(qū)及其屬性，表的屬性（是否為外部表等），表的數(shù)據(jù)所在目錄等。解釋器、編譯器、優(yōu)化器、執(zhí)行器解釋器、編譯器、優(yōu)化器完成 HQL 查詢語句從詞法分析、語法分析、編譯、優(yōu)化以及查詢計劃的生成。
含義數(shù)據(jù)倉庫是一個面向主題的，集成的，不可更新的，隨時間不斷變化的數(shù)據(jù)集合，他可以支持企業(yè)或組織的決策分析處理。
區(qū)別：1.數(shù)據(jù)庫只存放在當(dāng)前值，數(shù)據(jù)倉庫存放歷史值；
2.數(shù)據(jù)庫內(nèi)數(shù)據(jù)是動態(tài)變化的，只要有業(yè)務(wù)發(fā)生，數(shù)據(jù)就會被更新，而數(shù)據(jù)倉庫則是靜態(tài)的歷史數(shù)據(jù)，只能定期添加、刷新；
3.數(shù)據(jù)庫中的數(shù)據(jù)結(jié)構(gòu)比較復(fù)雜，有各種結(jié)構(gòu)以適合業(yè)務(wù)處理系統(tǒng)的需要，而數(shù)據(jù)倉庫中的數(shù)據(jù)結(jié)構(gòu)則相對簡單；
4.數(shù)據(jù)庫中數(shù)據(jù)訪問頻率較高，但訪問量較少，而數(shù)據(jù)倉庫的訪問頻率低但訪問量卻很高；
5.數(shù)據(jù)庫中數(shù)據(jù)的目標(biāo)是面向業(yè)務(wù)處理人員的，為業(yè)務(wù)處理人員提供信息處理的支持，而數(shù)據(jù)倉庫則是面向高層管理人員的，為其提供決策支持；
6.數(shù)據(jù)庫在訪問數(shù)據(jù)時要求響應(yīng)速度快，其響應(yīng)時間一般在幾秒內(nèi)，而數(shù)據(jù)倉庫的響應(yīng)時間則可長達數(shù)幾小時
