什么是數(shù)倉
從字面上來看，數(shù)據(jù)倉庫就是一個存放數(shù)據(jù)的倉庫，它里面存放了各種各樣的數(shù)據(jù)，而這些數(shù)據(jù)需要按照一些結構、規(guī)則來組織和存放。這里我們會遇到一個問題就是同樣是存放數(shù)據(jù)的倉庫，那數(shù)據(jù)庫和數(shù)據(jù)倉庫是一樣的嗎？
數(shù)據(jù)庫 VS 數(shù)據(jù)倉庫
數(shù)據(jù)庫就是我們常用的關系型數(shù)據(jù)庫（MySQL、Oracle、PostgreSQL...），還有什么非關系型數(shù)據(jù)庫，它主要存放業(yè)務數(shù)據(jù)，那數(shù)據(jù)倉庫有有些什么數(shù)據(jù)呢？說到他們的區(qū)別，我們一般會提到OLTP和OLAP。
他們的區(qū)別，面試時也會提到，主要從幾個點談談就行。數(shù)據(jù)倉庫其實是一套體系，他不是一門什么技術，而是整合了很多已有的技術，來更好地組織和管理數(shù)據(jù)。傳統(tǒng)數(shù)倉的話，主要是基于關系型數(shù)據(jù)庫，后面還有一些分布式的數(shù)據(jù)庫像Greenplum，還有很多公司會提供基于硬件的一整套解決方案。在傳統(tǒng)數(shù)倉開發(fā)時，由于硬件的性能有限，所以有很多的要求，而隨著硬件價格的下降、云服務器的廣泛使用，還有大數(shù)據(jù)技術的成熟發(fā)展，數(shù)倉的很多場景都變了，有些規(guī)則都不需要去嚴格遵守了，這樣也可以剩下很多的成本。再往前幾年，數(shù)倉這個東西是有點兒神秘的，感覺很高大上，而現(xiàn)在，起碼在互聯(lián)網(wǎng)公司來說，誰都知道數(shù)倉，誰都知道數(shù)據(jù)平臺，誰都可以來說兩句，已經(jīng)大眾化了。記得以前面數(shù)倉的話，總有幾個必備的面試題：
- 什么是OLAP？什么是OLTP？區(qū)別是什么？
就目前互聯(lián)網(wǎng)數(shù)倉這一崗位，感覺更加偏重業(yè)務+建模思想，面試不太好考察這些內(nèi)容的，去年招聘的時候，就是問些基本問題，聊聊以往主要的工作內(nèi)容，還會問問SQL題，真的想了解下建模的話，還是找本書借鑒性的看看，還是很有益處的。
傳統(tǒng)數(shù)倉與互聯(lián)網(wǎng)數(shù)倉
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團隊去服務業(yè)務方，業(yè)務方嗷嗷待哺的等待被動方式去滿足。中低層數(shù)據(jù)基本不會對業(yè)務方開放，所以不管數(shù)據(jù)模型采用何種建模方式，主要滿足當時數(shù)據(jù)架構規(guī)劃即可。互聯(lián)網(wǎng)業(yè)務的快速發(fā)展使得大家已經(jīng)從經(jīng)營、分析的訴求重點轉為數(shù)據(jù)化的精細運營上，如何做好精細化運營問題上來，當資源不夠時用戶就叫喊，甚至有的業(yè)務方會挽起袖子來自己參與到從數(shù)據(jù)整理、加工、分析階段。此時呢，原有建設數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)、模型設計）可能轉為對其它非專業(yè)使用數(shù)據(jù)方，做培訓、咨詢與落地，寫更加適合當前企業(yè)數(shù)據(jù)應用的一些方案與開發(fā)些數(shù)據(jù)產(chǎn)品等。在互聯(lián)網(wǎng)數(shù)據(jù)平臺由于數(shù)據(jù)平臺變?yōu)樽杂砷_放，大家使用數(shù)據(jù)的人也參與到數(shù)據(jù)的體系建設時，基本會因為不專業(yè)性，導致數(shù)據(jù)質(zhì)量問題、重復對分數(shù)據(jù)浪費存儲與資源、口徑多樣化、編碼不統(tǒng)一、命名問題等等原因。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題。
數(shù)倉架構
現(xiàn)在說數(shù)倉，更多的會和數(shù)據(jù)平臺或者基礎架構搭上，已經(jīng)融合到整個基礎設施的搭建上。這里呢，我們不說Hadoop各種組件之間的配合，我們就簡單說下數(shù)倉的分層架構。說到數(shù)倉建模，就得提下經(jīng)典的2套理論：Inmon提出的集線器的自上而下（EDW-DM）的數(shù)據(jù)倉庫架構。Kimball提出的總線式的自下而上（DM-DW）的數(shù)據(jù)倉庫架構。數(shù)倉的建模或者分層，其實都是為了更好的去組織、管理、維護數(shù)據(jù)，實際開發(fā)時會整合2種方式去使用，當然，還有些其他的，像Data Vault模型、Anchor模型，暫時還沒有應用過，就不說了。維度建模，一般都會提到星型模型、雪花模型，星型模型做OLAP分析很方便。簡單點兒，直接ODS+DM就可以了，將所有數(shù)據(jù)同步過來，然后直接開發(fā)些應用層的報表，這是最簡單的了；當DM層的內(nèi)容多了以后，想要重用，就會再拆分一個公共層出來，變成3層架構，最近看了本阿里的書，《大數(shù)據(jù)之路》，里面有很多數(shù)倉相關的內(nèi)容，很不錯，參考后，目前使用的分層模式如下：
按照這種分層方式，我們的開發(fā)重心就在dwd層，就是明細數(shù)據(jù)層，這里主要是一些寬表，存儲的還是明細數(shù)據(jù)；到了dws層，我們就會針對不同的維度，對數(shù)據(jù)進行聚合了，按道理說，dws層算是集市層，這里一般按照主題進行劃分，屬于維度建模的范疇；ads就是偏應用層，各種報表的輸出了。
指標字典
前面我們說過，數(shù)倉是一套體系，一個建設過程，它整合了很多的方法論，并不是一門新的技術。這里我們說說數(shù)倉中的指標體系，指標也不是數(shù)倉或者數(shù)據(jù)平臺中特有的， 很多場景都會有指標這個概念。這里我們說的指標，其實就是KPI（Key Performance Indicator），關鍵績效指標。企業(yè)關鍵績效指標(KPI：Key Performance Indicator)是通過對組織內(nèi)部流程的輸入端、輸出端的關鍵參數(shù)進行設置、取樣、計算、分析，衡量流程績效的一種目標式量化管理指標，是把企業(yè)的戰(zhàn)略目標分解為可操作的工作目標的工具，是企業(yè)績效管理的基礎。KPI可以使部門主管明確部門的主要責任，并以此為基礎，明確部門人員的業(yè)績衡量指標。數(shù)據(jù)平臺的作用是為分析、決策提供支持，來時刻關注企業(yè)的運營情況的。那我們怎樣來看公司的運營情況呢？就是看KPI，公司層面有公司最關注的KPI，比如：日活、GMV、訂單量等等；不同的部門又有不同的關注KPI，比如：新用戶數(shù)、復夠人數(shù)等等，有了KPI，我們就可以根據(jù)KPI來考察部門的表現(xiàn)，也就是績效。這也是數(shù)字化轉型嘛，所有的管理、績效都數(shù)字化。就數(shù)據(jù)平臺來說，指標算是元數(shù)據(jù)的一種，指標的維護和管理是有套路的，下面就簡單分享下關于指標的管理-指標字典。指標字典，其實就是對指標的管理，指標多了以后，為了共享和統(tǒng)一修改和維護，我們會在Excel中維護所有的指標。當然，Excel對于共享和版本控制也不是很方便，有條件的話，可以開發(fā)個簡單的指標管理系統(tǒng)，再配合上血緣關系，就更方便追蹤數(shù)據(jù)流轉了。基礎指標：不能再進一步拆解的指標，可以直接計算出來的指標，如“訂單數(shù)”、“交易額” 衍生指標：在基礎指標的基礎上，通過某個特殊維度計算出的指標，如“微信訂單數(shù)”、“支付寶訂單數(shù)” 計算指標：通過若干個基礎指標計算得來的指標，在業(yè)務角度無法再拆解的指標，如“售罄率”、“復購率”指標最重要的就是，明確指標的統(tǒng)計口徑，就是這個指標是怎么算出來的，口徑統(tǒng)一了，才不會產(chǎn)生歧義。除了上面，我們說到的幾點，還有一些基本的，像“指標名稱”、計算公式，就組成了指標的模板。
以前的話，我們還會有責任部門，就是說這個指標是哪個部門負責維護的，這個KPI是哪個部門來關注和承擔。說到指標，就離不開維度，我們后面會說說維度的故事。一開始指標的梳理是很麻煩的，因為要統(tǒng)一一個口徑，需要和不同的部門去溝通協(xié)調(diào)；還有可能會有各種各樣的指標出現(xiàn)，需要去判斷是否真的需要這個指標，是否可以用其他指標來替代；指標與指標之間的關系也需要理清楚。而且第一版指標梳理好之后，需要進行推廣和維護，不斷地迭代，持續(xù)推動，讓公司所有部門都統(tǒng)一站在一個視角關注問題。
最重要的維度之日期維度
日期維度是我們最常用的維度，平臺初始，最先初始化的可能就是日期維度，這里我們就簡單介紹下日期維度。我們?nèi)粘Ｉ?，?shù)據(jù)的產(chǎn)生都和日期有關，每一分、每一秒都會產(chǎn)生數(shù)據(jù)，數(shù)據(jù)分析也離不開日期。日期維度就是一張固化的日歷，一年365天，每一天都有，我們打開電腦中的日歷：
這里面有的，我們都可以固化下來，像周幾、農(nóng)歷、年、月、日、節(jié)假日，我們都可以固化下來，方面我們分析的時候使用。日期維度可以盡可能多的包含日期詳細信息，這樣在分析的時候可以直接使用，還要結合公司的一些特殊情況，像一些特殊展示的日期格式。
可能還有些農(nóng)歷信息、農(nóng)歷年份等，公司自定義周的開始日期、結束日期等，和日期相關的所有內(nèi)容都可以加進來進行維護。
數(shù)據(jù)初始化，我們可以使用Java、Python或者SQL，通過常用的日期函數(shù)基本可以滿足我們的數(shù)據(jù)需求，用SQL初始化，需要使用有循環(huán)控制語句的，如：MySQL、PG都行，Hive的話要結合Shell或者Python來使用。一般不需要初始化太多年的數(shù)據(jù)，只要覆蓋公司業(yè)務數(shù)據(jù)就好了，還有節(jié)假日信息每年都需要結合國務院發(fā)布的信息就行維護。
平時我們還會分析小時數(shù)據(jù)，一般不會把他放在日期表中，而是會單獨放在一張小時維度表里，需要的時候一起使用就行了。
命名規(guī)范
話說，沒有規(guī)矩不成方圓。在搭建數(shù)據(jù)平臺的時候，在數(shù)據(jù)組內(nèi)部，一定要先制定好各種規(guī)范，越早越好，并且不斷的監(jiān)督大家是否按照約定執(zhí)行。一旦讓大家自由發(fā)揮，后期想要統(tǒng)一或者重構，會浪費很大的人力成本和時間成本，記住，這都是坑。常規(guī)來說，數(shù)倉的建設是按照數(shù)倉分層模型開發(fā)的。也有會按照業(yè)務線來分層，在各自業(yè)務線下重新分層，單獨開發(fā)的。我這里使用的是阿里云的MaxCompute，這是阿里提供的數(shù)據(jù)平臺，一整套開發(fā)環(huán)境，用起來還是很方便的，省去了自建平臺的麻煩。MaxCompute里面有一個項目的概念，一開始本來打算直接根據(jù)分層模型的設計來創(chuàng)建項目，但是由于某種原因，改成了按照業(yè)務線來創(chuàng)建項目。對于這個項目名，一定要想好，不管根據(jù)什么來設計，都需要想清楚，想明白，定了以后就不要再改了，也沒法改。我忘記是不是叫“詞根”了，先寫著，后面找本書確認下。詞根屬于數(shù)倉建設中的規(guī)范，屬于元數(shù)據(jù)管理的范疇。哦，現(xiàn)在都把這個劃到數(shù)據(jù)治理的一部分。正常來說，完整的數(shù)倉建設是包含數(shù)據(jù)治理的，只是現(xiàn)在談到數(shù)倉偏向于數(shù)據(jù)建模，而談到數(shù)據(jù)治理，更多的是關于數(shù)據(jù)規(guī)范、數(shù)據(jù)管理。我們學習英語的時候應該有了解過詞根這個東西，它就是最細粒度的最簡單的一個詞語，我們主要用來規(guī)范中文和英文的映射關系。我們公司一部分業(yè)務是關于貨架的，英文名是：rack，rack就是一個詞根，那我們就在所有的表、字段等用到的地方都叫rack，不要叫成別的什么。這就是詞根的作用，用來統(tǒng)一命名，表達同一個含義。指標體系中有很多“率”的指標，都可以拆解成XXX+率，率可以叫rate，那我們所有的指標都叫做XXX+rate。詞根可以用來統(tǒng)一表名、字段名、主題域名等等。表名需要見名知意，通過表名就可以知道它是哪個業(yè)務域，干嘛用的，什么粒度的數(shù)據(jù)。
常規(guī)表是我們需要固化的表，是正式使用的表，是目前一段時間內(nèi)需要去維護去完善的表。規(guī)范：分層前綴[dwd|dws|ads|bi]業(yè)務域主題域XXX粒度 業(yè)務域、主題域我們都可以用詞根的方式枚舉清楚，不斷完善，粒度也是同樣的，主要的是時間粒度、日、月、年、周等，使用詞根定義好簡稱。
中間表一般出現(xiàn)在Job中，是Job中臨時存儲的中間數(shù)據(jù)的表，中間表的作用域只限于當前Job執(zhí)行過程中，Job一旦執(zhí)行完成，該中間表的使命就完成了，是可以刪除的（按照自己公司的場景自由選擇，以前公司會保留幾天的中間表數(shù)據(jù)，用來排查問題）。規(guī)范：mid_tablename [0~9|dim] table_name是我們?nèi)蝿罩心繕吮淼拿?，通常來說一個任務只有一個目標表。這里加上表名，是為了防止自由發(fā)揮的時候表名沖突，而末尾大家可以選擇自由發(fā)揮，起一些有意義的名字，或者簡單粗暴，使用數(shù)字代替，各有優(yōu)劣吧，謹慎選擇。通常會遇到需要補全維度的表，這里我喜歡使用dim結尾。中間表在創(chuàng)建時，請加上 ,如果要保留歷史的中間表，可以加上日期或者時間戳
drop table if exists table_name;
create table_name as xxx;
臨時表是臨時測試的表，是臨時使用一次的表，就是暫時保存下數(shù)據(jù)看看，后續(xù)一般不再使用的表，是可以隨時刪除的表。規(guī)范：tmp_xxx 只要加上tmp開頭即可，其他名字隨意， 注意tmp開頭的表不要用來實際使用，只是測試驗證而已。
維度表是基于底層數(shù)據(jù)，抽象出來的描述類的表。維度表可以自動從底層表抽象出來，也可以手工來維護。規(guī)范：dim_xxx 維度表，統(tǒng)一以dim開頭，后面加上，對該指標的描述，可以自由發(fā)揮。
手工表是手工維護的表，手工初始化一次之后，一般不會自動改變，后面變更，也是手工來維護。一般來說，手工的數(shù)據(jù)粒度是偏細的，所以，暫時我們統(tǒng)一放在dwd層，后面如果有目標值或者其他類型手工數(shù)據(jù)，再根據(jù)實際情況分層。規(guī)范：dwd _ 業(yè)務域manual xxx 手工表，增加特殊的主題域，manual，表示手工維護表指標的命名也參考詞根，避免出現(xiàn)同一個指標，10個人有10個命名方法。具體操作結合公司實際情況，規(guī)范及早制定。
數(shù)據(jù)治理
廣義數(shù)據(jù)倉庫的建設包含很多的解決方案，其中就包含數(shù)據(jù)治理，數(shù)據(jù)治理也是貫穿整個項目始終的，是一件長久的事情?，F(xiàn)在很多人都把數(shù)據(jù)倉庫簡單的理解成數(shù)據(jù)建模了。數(shù)據(jù)治理包含很多的事情，我也沒做過，所以在網(wǎng)上找些資料分享下。隨著數(shù)據(jù)量越來越大，數(shù)據(jù)成為一種資產(chǎn)，我們需要更好地管理這些數(shù)據(jù)，更好地體現(xiàn)數(shù)據(jù)的價值，這就需要數(shù)據(jù)治理。其實在搭建數(shù)據(jù)平臺的時候，我們遇到的一系列問題都可以通過數(shù)據(jù)治理來解決：
- 數(shù)據(jù)質(zhì)量越來越差，問題發(fā)現(xiàn)嚴重滯后
- 缺少數(shù)據(jù)標準，各個部門標準不統(tǒng)一
- 數(shù)據(jù)變更對下游的影響不清晰，無法確認影響范圍
數(shù)據(jù)治理（Data Governance），是一套持續(xù)改善管理機制，通常包括了數(shù)據(jù)架構組織、數(shù)據(jù)模型、政策及體系制定、技術工具、數(shù)據(jù)標準、數(shù)據(jù)質(zhì)量、影響度分析、作業(yè)流程、監(jiān)督及考核流程等內(nèi)容。簡單來說就是有很多流程和標準，像“元數(shù)據(jù)管理”、“主數(shù)據(jù)管理”、“數(shù)據(jù)質(zhì)量”都包含其中。通過數(shù)據(jù)治理來解決我們使用數(shù)據(jù)的過程中遇到的問題。
關于增量
很多初學者或者沒有做個ETL這件事兒的同學對這個增量是有誤解的，尤其是在和業(yè)務開發(fā)同學對接的時候，他們對這個增量的理解也是有偏差的。先來說說他們以為的增量是什么。他們以為“增量，就是按照時間增量去拿就好了，增量同步，你就把增量后的數(shù)據(jù)給我好了，不要總是全量同步?！?按道理說，這么做思路是對的，但是不嚴謹，而且會出錯，下面我們就一步一步看看。增量是相對于全量來說的，它們都是處于“同步數(shù)據(jù)”這個場景下的，比如說業(yè)務系統(tǒng)的數(shù)據(jù)同步到數(shù)倉，數(shù)倉的數(shù)據(jù)同步給業(yè)務系統(tǒng)，都會使用同步的方式，這都是相對于我們開發(fā)來說的，從數(shù)據(jù)庫級也是可以同步的，這里我們就不介紹了。全量同步，就是說把數(shù)據(jù)全部同步過去，100條就同步100條，1萬條就同步1萬條，1億條就同步1億條，大家也應該會發(fā)現(xiàn)這種方式存在的問題，在數(shù)據(jù)量小的時候，全量同步簡單方便易執(zhí)行，而當數(shù)據(jù)量大了以后，尤其是歷史數(shù)據(jù)不會經(jīng)常變化的時候，全量同步就會浪費大量的資源和時間，嚴重影響同步效率。
--全量同步一般先delete，然后insert
delete from tmp_a;
insert into tmp_a xxx;
-- 或者直接 insert overwrite
insert overwrite table tmp_a xxx;
記住一定要刪除或者覆蓋插入，不然數(shù)據(jù)可就越來越多了。
- 數(shù)據(jù)量很大，而且歷史數(shù)據(jù)不會頻繁變化
使用增量同步，對表有一些要求，比如，需要有create_time，update_time字段 create_time表示記錄創(chuàng)建時間，update_time表示記錄更新時間，增量的話，只需要把變化的數(shù)據(jù)拿過來就行了（使用update_time），注意：這里還需要有一個主鍵，主鍵是用來覆蓋數(shù)據(jù)的。這里和不同的業(yè)務場景有關系，有的記錄創(chuàng)建后不會再更新，類似于流水數(shù)據(jù)，這種數(shù)據(jù)直接增量拿過來就好，可以不進行刪除操作；但是有的數(shù)據(jù)是會更新的，當已經(jīng)同步過來的數(shù)據(jù)發(fā)生了變化，數(shù)倉側也是需要同步發(fā)生變化的。
create table tmp_a(
id bigint,
create_time datetime,
update_time datetime
);
一般離線場景下，都會選擇在業(yè)務量最少的時候去做同步操作，而這個時間大部分都是在半夜凌晨的時候，所以大部分同步都是從0點以后開始，同步昨天的數(shù)據(jù)，也就是常說的T+1了。假設3月1號創(chuàng)建了如下4條記錄，數(shù)倉會在2號凌晨進行同步
2號的時候，新增了1條記錄，并且有一條記錄更新了，按照增量規(guī)則，我們會拿到兩條記錄
拿到增量數(shù)據(jù)之后，我們需要將增量的數(shù)據(jù)合并到我們數(shù)倉的表中
新增的數(shù)據(jù)，可以直接插入，但是更新的數(shù)據(jù)，我們需要把原紀錄更新掉，或者先刪除再插入，以前我們還會記錄一個數(shù)據(jù)插入的狀態(tài)，如果是更新的，就記一個“update”，如果是插入的就記一個“insert”，到了這里，應該知道為啥需要有主鍵了吧，如果沒有主鍵，你咋知道這條記錄到底變沒變過。使用增量，一般需要兩套表，一套表用來存增量數(shù)據(jù)，一套用來存完整的全量數(shù)據(jù)。不管是增量還是全量，我都比較喜歡加一個時間戳字段，用來標識記錄的插入時間，這個尤其是在對比增量數(shù)據(jù)的時候，排查數(shù)據(jù)問題很有用。我們呢，一創(chuàng)業(yè)公司，數(shù)據(jù)量不算多，使用的都是阿里云的工具，一開始為了方便，所有的數(shù)據(jù)，都是全量來的，剛看了眼數(shù)據(jù)量又10幾T吧，其中很多是歷史數(shù)據(jù)。雖然我們是全量來的，但是為了捕捉記錄數(shù)據(jù)的變化，用的是pt（分區(qū)）的方式，每天都是一個全量快照，這也是現(xiàn)在存儲便宜的一種處理方法，簡單粗暴。我剛來的時候，就提過搞成增量，被拒絕了，后來也沒有人來搞這個，表太多了，修改起來成本太高。Hive現(xiàn)在也算是標配了，上面說的增量方案，可能還是基于關系型數(shù)據(jù)庫的，在Hive上，由于運算能力更強大，可以不考慮數(shù)據(jù)量的問題，所以衍生出來幾種方案。主要原因還是Hive上對于delete操作的支持問題，盡量不要有delete。
我們依然每天獲取增量數(shù)據(jù)，然后將增量數(shù)據(jù)插入到每個分區(qū)中，每個分區(qū)都是當天的增量數(shù)據(jù)，當然數(shù)據(jù)變化的話，同一個主鍵的記錄會出現(xiàn)在多個分區(qū)中，所以如果我們要獲取最新的完整版數(shù)據(jù)，可以使用row_number根據(jù)主鍵和時間排序，獲取最新版本的全量數(shù)據(jù)
使用full join的方式，將增量數(shù)據(jù)和歷史全量數(shù)據(jù)，進行關聯(lián)，然后取出最新完整版數(shù)據(jù)
這個和full join的方式類似，感覺這個更美觀嚴謹一些，以前在GP上面做增量也用的這種方式。說到增量，也需要提一下拉鏈表，拉鏈表以前用的多一些，感覺在互聯(lián)網(wǎng)公司用的很少，基本都使用分區(qū)的方式處理掉了。拉鏈表其實就是記錄數(shù)據(jù)的每一次變化，處理起來稍微有點兒麻煩，這個以前好像寫過，等我找找貼過來。
上下游約定
由于數(shù)倉的特性和定位，它就需要強依賴上游的業(yè)務系統(tǒng)，當然也會有一些下游系統(tǒng)，所以定好上下游的規(guī)范，變更的通知機制是非常有必要的。感覺好像寫過上下游的事情，剛才沒找到，這里就再重新寫寫。這里說的主要是基于小公司，類似我目前所在的創(chuàng)業(yè)公司為例，像發(fā)展成熟的大公司，各種流程規(guī)定、容錯監(jiān)控類的機制都很完善，對于這些場景，我說的可能就不適用了。對于數(shù)倉來說，最重要的就是數(shù)據(jù)了，數(shù)倉中的數(shù)據(jù)，主要來源是業(yè)務系統(tǒng)，就是公司各種業(yè)務數(shù)據(jù)，所以數(shù)倉需要不斷的將業(yè)務系統(tǒng)數(shù)據(jù)同步到自身平臺來，所以一旦上游業(yè)務系統(tǒng)發(fā)生變化，數(shù)倉也要同步變化，不然，這種同步操作很可能失敗。
上游的表結構經(jīng)常會發(fā)生變化，新增字段、修改字段、刪除字段（除非真的不用這個字段了，通常會選擇標識為棄用）。表結構最好要維護清楚，表名、字段名、字段類型、字段描述，都整理清楚，不使用的字段要么刪除，要么備注好，當業(yè)務頻繁發(fā)生變化或者迭代優(yōu)化的時候，很容易出現(xiàn)，我寫了半天的代碼，最后發(fā)現(xiàn)表用的不對，字段用的不對，這就尷尬了。對于這種變化，人工處理的話，就是手動在數(shù)倉對應的表中增加、修改字段，然后修改同步任務；這個最好可以搞成自動化的，比如，自動監(jiān)控上游表結構的變更，變化后，自動去修改數(shù)倉中的表結構，自動修改同步任務。
業(yè)務系統(tǒng)中會有很多的常量，用來標識一些狀態(tài)或者類型，這種值經(jīng)常會新增，數(shù)倉中會對這些值做些處理，比如轉換成維度，會翻譯成對應的中文，而實際上這種映射關系，我們是不知道的，只有業(yè)務開發(fā)才知道，所以最好可以讓他們維護一張枚舉值表，我們?nèi)ネ竭@張表。
- create_time & update_time
正常來說，create_time，當這條記錄插入后，就不會再變了，但是某種情況下，哈哈，開發(fā)同學會去更新它；update_time，當這條記錄變化后，這個時間也要變，有的開發(fā)同學不去更新它......所以在做增量操作的時候，一定和開發(fā)說好這兩個字段的定義和使用場景。
有些場景下，我們需要刪除某些數(shù)據(jù)，一般不會物理刪除，會通過一個字段來做邏輯刪除，請和開發(fā)同學溝通好，使用固定的一個字段，并確認該字段雙方的理解是一致的，不然后面又很多坑。說完了上游，我們說說下游，對于數(shù)倉來說，一般的郵件、報表、可視化平臺都是下游，所以當我們在數(shù)倉中進行某些重構、優(yōu)化操作的時候，也需要通知他們。主要就是對數(shù)倉模型做好維護，表的使用場景、字段描述等。
任務注釋
沒有注釋，誰知道你這些代碼是用來干嘛的，從代碼角度來看，你想做的是A，而實際上需求確是B，具體干啥得靠猜；代碼有注釋，也不一定就可以高枕無憂，注釋可能是最初版的需求，改了幾版后，代碼早就變了，注釋沒有變，注釋和代碼不匹配，誰知道該以哪個為準啊。我們的數(shù)倉都是基于阿里云的，使用了它的DataWorks作為離線工具，所有的代碼都在這上面，所以這里簡單介紹下，在阿里云上的任務，幾點注釋規(guī)范。
-- @name p_dwd_rack_machine
-- @description 貨架寬表
-- @target rack.dwd_rack_machine
-- @source owo_ods.kylin__machine_release_his
-- @source owo_ods.kylin__machine_device_his
-- @author yuguiyang 2017-12-25
-- @modify
@name：任務的名字，我們的任務名一般都是以 p_目標表名，后來阿里的DataWorks升級后，推薦是任務名和表名保持一致。@description：任務描述，該任務的主要內(nèi)容 @target：目標表名，一般一個任務只輸出一個目標表@source：來源表，就是任務中使用的底層表，這里也可以省略，從血緣關系中可以直接看到，而且很容易漏更新@author：創(chuàng)建者，和創(chuàng)建日期， @modify：內(nèi)容變更記錄，變更人，變更日期，變更原因 ，這個從版本控制中也可以找到，但是這些這里更直觀一些。
