一、數(shù)據(jù)集體與數(shù)據(jù)倉庫的區(qū)別？
數(shù)據(jù)集體和數(shù)據(jù)倉庫是有區(qū)別的，數(shù)據(jù)集體是指對(duì)于數(shù)據(jù)的內(nèi)容方面，它的界定，而數(shù)據(jù)倉庫是對(duì)于數(shù)據(jù)存儲(chǔ)方面，它的界定。
二、數(shù)據(jù)倉庫工程師是什么？
數(shù)據(jù)倉庫工程師是一個(gè)專注于數(shù)據(jù)倉庫設(shè)計(jì)和構(gòu)建的職業(yè)人員。數(shù)據(jù)倉庫是一個(gè)特殊的數(shù)據(jù)庫，主要用于支持企業(yè)的決策制定和業(yè)務(wù)分析。數(shù)據(jù)倉庫工程師的主要工作職責(zé)包括：
1. 數(shù)據(jù)倉庫架構(gòu)設(shè)計(jì)：設(shè)計(jì)和構(gòu)建數(shù)據(jù)倉庫的架構(gòu)，確保數(shù)據(jù)倉庫能夠支持業(yè)務(wù)需求。
2. 數(shù)據(jù)倉庫管理：確保數(shù)據(jù)倉庫的可靠性、安全性、穩(wěn)定性和性能。
3. ETL數(shù)據(jù)集成：設(shè)計(jì)和開發(fā)數(shù)據(jù)抽取（Extract）、轉(zhuǎn)換（Transform）、加工（Load）（ETL）過程，使得數(shù)據(jù)能夠從源系統(tǒng)中抽取并預(yù)處理到數(shù)據(jù)倉庫中。
4. 數(shù)據(jù)挖掘和業(yè)務(wù)智能：使用數(shù)據(jù)挖掘和業(yè)務(wù)智能工具，從數(shù)據(jù)倉庫中獲取有價(jià)值的業(yè)務(wù)信息，幫助企業(yè)提高業(yè)務(wù)效率、優(yōu)化業(yè)務(wù)決策。
5. 數(shù)據(jù)質(zhì)量保證：記錄、監(jiān)控和維護(hù)數(shù)據(jù)倉庫，確保數(shù)據(jù)質(zhì)量符合標(biāo)準(zhǔn)和架構(gòu)設(shè)計(jì)規(guī)范。
6. 數(shù)據(jù)倉庫優(yōu)化：診斷數(shù)據(jù)倉庫的性能和瓶頸，采取必要的手段，提高數(shù)據(jù)倉庫的性能。
數(shù)據(jù)倉庫工程師需要具備扎實(shí)的數(shù)據(jù)庫、數(shù)據(jù)倉庫和數(shù)據(jù)挖掘技能，同時(shí)也需要具備業(yè)務(wù)分析能力和團(tuán)隊(duì)協(xié)作精神。越來越多的企業(yè)需要數(shù)據(jù)倉庫工程師來幫助他們解決數(shù)據(jù)相關(guān)問題，因此該職位也愈發(fā)重要。
三、數(shù)據(jù)倉庫與hdfs的關(guān)系？
Hive 是一個(gè)基于 Hadoop 文件系統(tǒng)之上的數(shù)據(jù)倉庫架構(gòu)，存儲(chǔ)用hdfs，計(jì)算用mapreduce
四、數(shù)據(jù)倉庫與數(shù)據(jù)模型的區(qū)別？
數(shù)據(jù)模型是負(fù)責(zé)讀取數(shù)據(jù)，數(shù)據(jù)倉庫負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，功能不同
五、數(shù)據(jù)集市與數(shù)據(jù)倉庫有什么區(qū)別？
都是數(shù)據(jù)庫里面的概念，本質(zhì)上并沒有什么不同。 從字義上看， “倉庫”可以想像成一所大房子，高高的貨架，合理的出入路線，是一種集中存儲(chǔ)貨物的地方，一般顧客是不來參觀訪問的； 而說到“集市”，就容易聯(lián)想到空曠的場(chǎng)地，川流不息，大小商戶擺出攤子，賣衣物的、賣燒餅及賣藝的，是讓顧客來消費(fèi)的地方。
具體來說，數(shù)據(jù)倉庫僅僅是提供存儲(chǔ)的，提供一種面向數(shù)據(jù)管理的服務(wù)，不面向最終分析用戶；而數(shù)據(jù)集市是面向分析應(yīng)用的，面向最終用戶。
六、數(shù)據(jù)倉庫工程師有前途嗎？
當(dāng)然有了，還得看你工作經(jīng)驗(yàn)豐富不，大公司會(huì)設(shè)置這個(gè)崗位，小公司沒有這個(gè)需求！
七、數(shù)據(jù)集市和數(shù)據(jù)倉庫的區(qū)別與聯(lián)系？
數(shù)據(jù)集市概念在實(shí)際工業(yè)屆使用的比較少，一般用數(shù)據(jù)倉庫，有時(shí)候會(huì)把他們等同。我一般是把數(shù)據(jù)集市看做是數(shù)據(jù)倉庫的上層，比如圍繞一些主題的數(shù)據(jù)，當(dāng)做數(shù)據(jù)集市。
八、數(shù)據(jù)倉庫十大主題模型？
數(shù)據(jù)倉庫十大的主題模型如下
高層模型：考慮所有上層主題，主題之間的關(guān)系
中層模型：細(xì)化 上層主題 數(shù)據(jù)項(xiàng)
物理模型：基于性能，存儲(chǔ)，平臺(tái)特點(diǎn)，數(shù)據(jù)合并，分區(qū)設(shè)計(jì)
維度建模（Ralph Kimball 拉爾夫·金博爾）提出 （當(dāng)前最主流的模型）
星型：所有維表直接連接到事實(shí)表
雪花型： 當(dāng)有一個(gè)或多個(gè)維表沒有直接連接到事實(shí)表上，而是通過其他維表連接到事實(shí)表上
九、數(shù)據(jù)倉庫工程師發(fā)展與職業(yè)前景
數(shù)據(jù)倉庫工程師發(fā)展與職業(yè)前景
數(shù)據(jù)倉庫工程師是一種專門負(fù)責(zé)數(shù)據(jù)倉庫設(shè)計(jì)、開發(fā)和維護(hù)的職業(yè)。隨著數(shù)據(jù)技術(shù)的迅猛發(fā)展和企業(yè)對(duì)數(shù)據(jù)分析的需求不斷增長(zhǎng)，數(shù)據(jù)倉庫工程師的職業(yè)前景越來越廣闊。
數(shù)據(jù)倉庫工程師技能要求
作為一名數(shù)據(jù)倉庫工程師，掌握以下技能是至關(guān)重要的：
- 數(shù)據(jù)庫知識(shí)：熟練掌握SQL語言和關(guān)系數(shù)據(jù)庫管理系統(tǒng)（如Oracle、SQL Server），能夠熟練操作和管理數(shù)據(jù)庫。
- 數(shù)據(jù)建模：具備數(shù)據(jù)建模的能力，能夠?qū)I(yè)務(wù)需求轉(zhuǎn)化為數(shù)據(jù)模型，并設(shè)計(jì)合理的數(shù)據(jù)結(jié)構(gòu)。
- ETL開發(fā)：熟悉ETL工具（如Informatica、DataStage），能夠開發(fā)ETL流程，實(shí)現(xiàn)數(shù)據(jù)從源系統(tǒng)到數(shù)據(jù)倉庫的抽取、轉(zhuǎn)換和加載。
- 數(shù)據(jù)質(zhì)量管理：了解數(shù)據(jù)質(zhì)量管理的基本概念和方法，能夠進(jìn)行數(shù)據(jù)質(zhì)量評(píng)估和數(shù)據(jù)清洗。
- 數(shù)據(jù)倉庫架構(gòu)：具備數(shù)據(jù)倉庫的構(gòu)建和管理經(jīng)驗(yàn)，能夠設(shè)計(jì)滿足業(yè)務(wù)需求的數(shù)據(jù)倉庫架構(gòu)。
- 數(shù)據(jù)分析：具備數(shù)據(jù)分析的能力，能夠?qū)?shù)據(jù)進(jìn)行分析和挖掘，提供有價(jià)值的洞察。
數(shù)據(jù)倉庫工程師職業(yè)發(fā)展路徑
數(shù)據(jù)倉庫工程師職業(yè)發(fā)展路徑通常包括以下幾個(gè)階段：
- 初級(jí)數(shù)據(jù)倉庫工程師：在初級(jí)階段，主要負(fù)責(zé)數(shù)據(jù)倉庫的開發(fā)和維護(hù)工作，熟悉數(shù)據(jù)倉庫領(lǐng)域的基本概念和技術(shù)。
- 高級(jí)數(shù)據(jù)倉庫工程師：在此階段，需要具備深入的數(shù)據(jù)倉庫知識(shí)和豐富的項(xiàng)目經(jīng)驗(yàn)，能夠獨(dú)立設(shè)計(jì)和實(shí)現(xiàn)復(fù)雜的數(shù)據(jù)倉庫解決方案。
- 數(shù)據(jù)倉庫架構(gòu)師：成為數(shù)據(jù)倉庫架構(gòu)師需要具備全面的數(shù)據(jù)倉庫設(shè)計(jì)和管理能力，負(fù)責(zé)整個(gè)數(shù)據(jù)倉庫系統(tǒng)的規(guī)劃和架構(gòu)。
- 數(shù)據(jù)倉庫顧問：擔(dān)任數(shù)據(jù)倉庫顧問的工作需要具備豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)和深入的業(yè)務(wù)理解，能夠?yàn)槠髽I(yè)提供專業(yè)的數(shù)據(jù)倉庫解決方案。
數(shù)據(jù)倉庫工程師職業(yè)前景
數(shù)據(jù)倉庫工程師職業(yè)前景非常廣闊：
- 數(shù)據(jù)清洗與分析：隨著大數(shù)據(jù)時(shí)代的到來，企業(yè)對(duì)數(shù)據(jù)清洗和分析的需求不斷增長(zhǎng)，數(shù)據(jù)倉庫工程師在這一領(lǐng)域?qū)⒂懈嗟墓ぷ鳈C(jī)會(huì)。
- 數(shù)據(jù)倉庫系統(tǒng)集成：隨著企業(yè)信息化建設(shè)的推進(jìn)，數(shù)據(jù)倉庫工程師將發(fā)揮重要作用，負(fù)責(zé)數(shù)據(jù)倉庫系統(tǒng)的集成、優(yōu)化和升級(jí)。
- 人工智能與機(jī)器學(xué)習(xí)：數(shù)據(jù)倉庫工程師可以通過整合和分析大量數(shù)據(jù)，為人工智能和機(jī)器學(xué)習(xí)提供基礎(chǔ)支持，參與到相關(guān)項(xiàng)目中。
- 跨行業(yè)發(fā)展：數(shù)據(jù)倉庫是各個(gè)行業(yè)都需要的技術(shù)，數(shù)據(jù)倉庫工程師可以根據(jù)個(gè)人興趣和發(fā)展方向選擇不同行業(yè)的工作機(jī)會(huì)。
總之，數(shù)據(jù)倉庫工程師是當(dāng)今數(shù)據(jù)領(lǐng)域非常重要的職業(yè)之一，具有廣闊的職業(yè)前景和發(fā)展空間。只要不斷學(xué)習(xí)和提升專業(yè)能力，并與時(shí)俱進(jìn)地掌握新技術(shù)，數(shù)據(jù)倉庫工程師必將在未來的職業(yè)道路上獲得更多機(jī)會(huì)和成就。
感謝您閱讀本文，希望通過對(duì)數(shù)據(jù)倉庫工程師職業(yè)發(fā)展與職業(yè)前景的介紹，對(duì)您有所幫助。
十、數(shù)據(jù)倉庫的含義,數(shù)據(jù)倉庫和數(shù)據(jù)庫的區(qū)別？
一直想整理一下這塊內(nèi)容，既然是漫談，就想起什么說什么吧。我一直是在互聯(lián)網(wǎng)行業(yè)，就以互聯(lián)網(wǎng)行業(yè)來說。先大概列一下互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)倉庫、數(shù)據(jù)平臺(tái)的用途：
整合公司所有業(yè)務(wù)數(shù)據(jù)，建立統(tǒng)一的數(shù)據(jù)中心；
提供各種報(bào)表，有給高層的，有給各個(gè)業(yè)務(wù)的；
為網(wǎng)站運(yùn)營(yíng)提供運(yùn)營(yíng)上的數(shù)據(jù)支持，就是通過數(shù)據(jù)，讓運(yùn)營(yíng)及時(shí)了解網(wǎng)站和產(chǎn)品的運(yùn)營(yíng)效果；
為各個(gè)業(yè)務(wù)提供線上或線下的數(shù)據(jù)支持，成為公司統(tǒng)一的數(shù)據(jù)交換與提供平臺(tái)；
分析用戶行為數(shù)據(jù)，通過數(shù)據(jù)挖掘來降低投入成本，提高投入效果；比如廣告定向精準(zhǔn)投放、用戶個(gè)性化推薦等；
開發(fā)數(shù)據(jù)產(chǎn)品，直接或間接為公司盈利；
建設(shè)開放數(shù)據(jù)平臺(tái)，開放公司數(shù)據(jù)；
。。。。。。
上面列出的內(nèi)容看上去和傳統(tǒng)行業(yè)數(shù)據(jù)倉庫用途差不多，并且都要求數(shù)據(jù)倉庫/數(shù)據(jù)平臺(tái)有很好的穩(wěn)定性、可靠性；但在互聯(lián)網(wǎng)行業(yè)，除了數(shù)據(jù)量大之外，越來越多的業(yè)務(wù)要求時(shí)效性，甚至很多是要求實(shí)時(shí)的 ，另外，互聯(lián)網(wǎng)行業(yè)的業(yè)務(wù)變化非常快，不可能像傳統(tǒng)行業(yè)一樣，可以使用自頂向下的方法建立數(shù)據(jù)倉庫，一勞永逸，它要求新的業(yè)務(wù)很快能融入數(shù)據(jù)倉庫中來，老的下線的業(yè)務(wù)，能很方便的從現(xiàn)有的數(shù)據(jù)倉庫中下線；
其實(shí)，互聯(lián)網(wǎng)行業(yè)的數(shù)據(jù)倉庫就是所謂的敏捷數(shù)據(jù)倉庫，不但要求能快速的響應(yīng)數(shù)據(jù)，也要求能快速的響應(yīng)業(yè)務(wù)；
建設(shè)敏捷數(shù)據(jù)倉庫，除了對(duì)架構(gòu)技術(shù)上的要求之外，還有一個(gè)很重要的方面，就是數(shù)據(jù)建模，如果一上來就想著建立一套能兼容所有數(shù)據(jù)和業(yè)務(wù)的數(shù)據(jù)模型，那就又回到傳統(tǒng)數(shù)據(jù)倉庫的建設(shè)上了，很難滿足對(duì)業(yè)務(wù)變化的快速響應(yīng)。應(yīng)對(duì)這種情況，一般是先將核心的持久化的業(yè)務(wù)進(jìn)行深度建模（比如：基于網(wǎng)站日志建立的網(wǎng)站統(tǒng)計(jì)分析模型和用戶瀏覽軌跡模型；基于公司核心用戶數(shù)據(jù)建立的用戶模型），其它的業(yè)務(wù)一般都采用維度+寬表的方式來建立數(shù)據(jù)模型。這塊是后話。
整體架構(gòu)下面的圖是我們目前使用的數(shù)據(jù)平臺(tái)架構(gòu)圖，其實(shí)大多公司應(yīng)該都差不多：
邏輯上，一般都有數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)與分析層、數(shù)據(jù)共享層、數(shù)據(jù)應(yīng)用層。可能叫法有所不同，本質(zhì)上的角色都大同小異。
我們從下往上看：
數(shù)據(jù)采集數(shù)據(jù)采集層的任務(wù)就是把數(shù)據(jù)從各種數(shù)據(jù)源中采集和存儲(chǔ)到數(shù)據(jù)存儲(chǔ)上，期間有可能會(huì)做一些簡(jiǎn)單的清洗。
數(shù)據(jù)源的種類比較多：
網(wǎng)站日志：
作為互聯(lián)網(wǎng)行業(yè)，網(wǎng)站日志占的份額最大，網(wǎng)站日志存儲(chǔ)在多臺(tái)網(wǎng)站日志服務(wù)器上，
一般是在每臺(tái)網(wǎng)站日志服務(wù)器上部署flume agent，實(shí)時(shí)的收集網(wǎng)站日志并存儲(chǔ)到HDFS上；
業(yè)務(wù)數(shù)據(jù)庫：
業(yè)務(wù)數(shù)據(jù)庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時(shí)候，我們迫切的需要一種能從各種數(shù)據(jù)庫中將數(shù)據(jù)同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數(shù)據(jù)量大小，都需要啟動(dòng)MapReduce來執(zhí)行，而且需要Hadoop集群的每臺(tái)機(jī)器都能訪問業(yè)務(wù)數(shù)據(jù)庫；應(yīng)對(duì)此場(chǎng)景，淘寶開源的DataX，是一個(gè)很好的解決方案（可參考文章 《異構(gòu)數(shù)據(jù)源海量數(shù)據(jù)交換工具-Taobao DataX 下載和使用》），有資源的話，可以基于DataX之上做二次開發(fā)，就能非常好的解決，我們目前使用的DataHub也是。
當(dāng)然，F(xiàn)lume通過配置與開發(fā)，也可以實(shí)時(shí)的從數(shù)據(jù)庫中同步數(shù)據(jù)到HDFS
來自于Ftp/Http的數(shù)據(jù)源：
有可能一些合作伙伴提供的數(shù)據(jù)，需要通過Ftp/Http等定時(shí)獲取，DataX也可以滿足該需求;
其他數(shù)據(jù)源：
比如一些手工錄入的數(shù)據(jù)，只需要提供一個(gè)接口或小程序，即可完成
數(shù)據(jù)存儲(chǔ)與分析毋庸置疑，HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉庫/數(shù)據(jù)平臺(tái)最完美的數(shù)據(jù)存儲(chǔ)解決方案。
離線數(shù)據(jù)分析與計(jì)算，也就是對(duì)實(shí)時(shí)性要求不高的部分，在我看來，Hive還是首當(dāng)其沖的選擇，豐富的數(shù)據(jù)類型、內(nèi)置函數(shù)；壓縮比非常高的ORC文件存儲(chǔ)格式；非常方便的SQL支持，使得Hive在基于結(jié)構(gòu)化數(shù)據(jù)上的統(tǒng)計(jì)分析遠(yuǎn)遠(yuǎn)比MapReduce要高效的多，一句SQL可以完成的需求，開發(fā)MR可能需要上百行代碼；
當(dāng)然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很樂意開發(fā)Java，或者對(duì)SQL不熟，那么也可以使用MapReduce來做分析與計(jì)算；Spark是這兩年非常火的，經(jīng)過實(shí)踐，它的性能的確比MapReduce要好很多，而且和Hive、Yarn結(jié)合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計(jì)算。因?yàn)橐呀?jīng)有Hadoop Yarn，使用Spark其實(shí)是非常容易的，不用單獨(dú)部署Spark集群，關(guān)于Spark On Yarn的相關(guān)文章，可參考：《Spark On Yarn系列文章》
實(shí)時(shí)計(jì)算部分，后面單獨(dú)說。
數(shù)據(jù)共享這里的數(shù)據(jù)共享，其實(shí)指的是前面數(shù)據(jù)分析與計(jì)算后的結(jié)果存放的地方，其實(shí)就是關(guān)系型數(shù)據(jù)庫和NOSQL數(shù)據(jù)庫；
前面使用Hive、MR、Spark、SparkSQL分析和計(jì)算的結(jié)果，還是在HDFS上，但大多業(yè)務(wù)和應(yīng)用不可能直接從HDFS上獲取數(shù)據(jù)，那么就需要一個(gè)數(shù)據(jù)共享的地方，使得各業(yè)務(wù)和產(chǎn)品能方便的獲取數(shù)據(jù)； 和數(shù)據(jù)采集層到HDFS剛好相反，這里需要一個(gè)從HDFS將數(shù)據(jù)同步至其他目標(biāo)數(shù)據(jù)源的工具，同樣，DataX也可以滿足。
另外，一些實(shí)時(shí)計(jì)算的結(jié)果數(shù)據(jù)可能由實(shí)時(shí)計(jì)算模塊直接寫入數(shù)據(jù)共享。
數(shù)據(jù)應(yīng)用
業(yè)務(wù)產(chǎn)品
業(yè)務(wù)產(chǎn)品所使用的數(shù)據(jù)，已經(jīng)存在于數(shù)據(jù)共享層，他們直接從數(shù)據(jù)共享層訪問即可；
報(bào)表
同業(yè)務(wù)產(chǎn)品，報(bào)表所使用的數(shù)據(jù)，一般也是已經(jīng)統(tǒng)計(jì)匯總好的，存放于數(shù)據(jù)共享層；
即席查詢
即席查詢的用戶有很多，有可能是數(shù)據(jù)開發(fā)人員、網(wǎng)站和產(chǎn)品運(yùn)營(yíng)人員、數(shù)據(jù)分析人員、甚至是部門老大，他們都有即席查詢數(shù)據(jù)的需求；
這種即席查詢通常是現(xiàn)有的報(bào)表和數(shù)據(jù)共享層的數(shù)據(jù)并不能滿足他們的需求，需要從數(shù)據(jù)存儲(chǔ)層直接查詢。
即席查詢一般是通過SQL完成，最大的難度在于響應(yīng)速度上，使用Hive有點(diǎn)慢，目前我的解決方案是SparkSQL，它的響應(yīng)速度較Hive快很多，而且能很好的與Hive兼容。
當(dāng)然，你也可以使用Impala，如果不在乎平臺(tái)中再多一個(gè)框架的話。
OLAP
目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數(shù)據(jù)，都是通過將需要的數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)庫中做OLAP，但如果數(shù)據(jù)量巨大的話，關(guān)系型數(shù)據(jù)庫顯然不行；
這時(shí)候，需要做相應(yīng)的開發(fā)，從HDFS或者HBase中獲取數(shù)據(jù)，完成OLAP的功能；
比如：根據(jù)用戶在界面上選擇的不定的維度和指標(biāo)，通過開發(fā)接口，從HBase中獲取數(shù)據(jù)來展示。
其它數(shù)據(jù)接口
這種接口有通用的，有定制的。比如：一個(gè)從Redis中獲取用戶屬性的接口是通用的，所有的業(yè)務(wù)都可以調(diào)用這個(gè)接口來獲取用戶屬性。
實(shí)時(shí)計(jì)算現(xiàn)在業(yè)務(wù)對(duì)數(shù)據(jù)倉庫實(shí)時(shí)性的需求越來越多，比如：實(shí)時(shí)的了解網(wǎng)站的整體流量；實(shí)時(shí)的獲取一個(gè)廣告的曝光和點(diǎn)擊；在海量數(shù)據(jù)下，依靠傳統(tǒng)數(shù)據(jù)庫和傳統(tǒng)實(shí)現(xiàn)方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時(shí)低的、高可靠的實(shí)時(shí)計(jì)算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡(jiǎn)單，不想多引入一個(gè)框架到平臺(tái)中，另外，Spark Streaming比Storm延時(shí)性高那么一點(diǎn)點(diǎn)，那對(duì)于我們的需要可以忽略。
我們目前使用Spark Streaming實(shí)現(xiàn)了實(shí)時(shí)的網(wǎng)站流量統(tǒng)計(jì)、實(shí)時(shí)的廣告效果統(tǒng)計(jì)兩塊功能。
做法也很簡(jiǎn)單，由Flume在前端日志服務(wù)器上收集網(wǎng)站日志和廣告日志，實(shí)時(shí)的發(fā)送給Spark Streaming，由Spark Streaming完成統(tǒng)計(jì)，將數(shù)據(jù)存儲(chǔ)至Redis，業(yè)務(wù)通過訪問Redis實(shí)時(shí)獲取。
任務(wù)調(diào)度與監(jiān)控在數(shù)據(jù)倉庫/數(shù)據(jù)平臺(tái)中，有各種各樣非常多的程序和任務(wù)，比如：數(shù)據(jù)采集任務(wù)、數(shù)據(jù)同步任務(wù)、數(shù)據(jù)分析任務(wù)等；
這些任務(wù)除了定時(shí)調(diào)度，還存在非常復(fù)雜的任務(wù)依賴關(guān)系，比如：數(shù)據(jù)分析任務(wù)必須等相應(yīng)的數(shù)據(jù)采集任務(wù)完成后才能開始；數(shù)據(jù)同步任務(wù)需要等數(shù)據(jù)分析任務(wù)完成后才能開始； 這就需要一個(gè)非常完善的任務(wù)調(diào)度與監(jiān)控系統(tǒng)，它作為數(shù)據(jù)倉庫/數(shù)據(jù)平臺(tái)的中樞，負(fù)責(zé)調(diào)度和監(jiān)控所有任務(wù)的分配與運(yùn)行。
前面有寫過文章，《大數(shù)據(jù)平臺(tái)中的任務(wù)調(diào)度與監(jiān)控》,這里不再累贅。
總結(jié)在我看來架構(gòu)并不是技術(shù)越多越新越好，而是在可以滿足需求的情況下，越簡(jiǎn)單越穩(wěn)定越好。目前在我們的數(shù)據(jù)平臺(tái)中，開發(fā)更多的是關(guān)注業(yè)務(wù)，而不是技術(shù)，他們把業(yè)務(wù)和需求搞清楚了，基本上只需要做簡(jiǎn)單的SQL開發(fā)，然后配置到調(diào)度系統(tǒng)就可以了，如果任務(wù)異常，會(huì)收到告警。這樣，可以使更多的資源專注于業(yè)務(wù)之上。
