建構企業級資料倉庫的底層邏輯

最近這些年，“底層邏輯”這個詞很火，什麼是底層邏輯呢？筆者認為可以将其了解為事物背後最本質的特征或原理。那麼企業建構資料倉庫的底層邏輯是什麼？筆者認為主要是資料倉庫能夠反映出企業經營管理過程産生的資料洞見（insight），這些洞見有價值而且不靠資料倉庫無法産生，這是數倉存在的根本邏輯。

具備條件的企業都要建立資料倉庫，因為可以幫助企業基于數字驅動的決策、營運，這是數字化時代企業的生存手段和必備技能。一個緻力于數字化轉型的企業可以沒有資料湖，但必須有數倉。那麼如何建構一個企業級數倉？筆者結合工作實際談一下思路。

需要提前說明的是，本文讨論範圍僅限于數倉的建構思路，不涉及模組化方法（如ER、雪花、星型等）、不涉及技術平台（如Oracle、TD、GaussDB、Hadoop、Hudi等）。因為筆者認為随着存儲成本的持續走低，對模組化方法的讨論意義不大。而且資料倉庫與資料中台類似，更多的是一種理念，是無關技術平台的。如果資料量不大，哪怕用mysql建構數倉都可以。

1、确定主題域。

主題域就是企業經營管理所涉及的一個個相對獨立的宏觀分析領域。如何确定主題域？如果所在企業是金融行業的，直接可以拿來主義，比如IBM提出的FSDM、TD提出的FS-LDM都有很成熟的實施經驗。如果是其他行業，簡單的方法是可以考慮按照已建成的系統或業務部門來劃分，但這兩種方法都存在系統變化、部門變動的問題，對數倉架構可能有比較大的影響，筆者還是建議根據企業的業務進行一定的抽象，抽象成穩定的、可經曆時間考驗的主題域，這需要對企業的業務、企業建成系統有很深的了解。

2、盡可能完整反映每個主題域下的業務流程。

這裡的關鍵詞是“完整”，如果業務流程不完整，數倉反映的資料就是不健全的，缺少事實情況或次元情況，後續的分析就會有短闆。筆者參加過一個數字化營銷交流會議，一位在四大行裡面負責數字營銷的老師也分享到，支撐數字化營銷的資料基礎中，最重要的是資料能夠反映真實業務的串聯，資料不能有斷點和片面性。

做到“完整”可能并不是一件容易的事，比如，有的企業和第三方合作，一些關鍵資訊并未落入企業自己的系統；有的系統與其他系統的關聯較為複雜，一些互動資訊、流程等資料可能産生在别的系統；一項業務較為複雜，可能需要合并多個系統中的資料才能完整反映整個業務。是以，在這種情況下，數倉架構師需要做的是“盡可能”，應當做好做足充分的調研，調研對象要包含業務人員、系統開發建設人員、資料中心人員等等。

3、确定複合/高維名額。

做好前兩步後，數倉的資料基礎已經全了，能夠滿足一些報表統計、簡單分析。但要使數倉的資料更有含金量，還需要更多的高維/複合名額，這是因為高維/複合名額可以支援機器學習模型，更好地産生資料洞見。做過機器學習的都知道，特征工程可以帶來更好的模型效果，而特征工程最重要的就是建構高維/複合名額。如何建構高維/複合名額呢？通常的說法是需要一個“領域專家經驗”，但筆者認為這誇大了業務專家的能力、增加了數倉的建構難度。

筆者認為，不失一般性地，可以參考營銷領域的“RFM”模型來建構高維/複合名額。RFM模型的具體含義是：最近一次消費時間（Recency，最近一次消費記錄到目前時間的間隔）、一定時間内消費頻率（Frequency）、一定時間内累計消費金額（Monetary），圍繞RFM可以做很多營銷領域的特征，比如對于F，可以根據消費類目、消費時間衍生出大量高維/複合名額：最近1/3/6/12個月購買/浏覽/搜尋服裝類/食品類/電子産品/書籍的次數；對于M，最近1/3/6/12個月購買服裝類/食品類/電子産品/書籍的金額總和/平均金額/最大金額/環比；對于R，最近一次購買/浏覽/搜尋服裝類/食品類/電子産品/書籍距今時間。

以上是營銷領域的特征，如果換成其他領域呢？比如客戶資産領域的特征，也可以參考RFM模型，隻不過要将消費類名額變為資産類名額，比如：對于M類名額，最近1/3/6/12個月A類資産/B類資産/C類資産餘額的總和/平均金額/環比/占比/标準差；比如客戶偏好類的特征，要将消費類名額變為行為類名額，對于F類名額，最近1/3/6/12個月聽搖滾樂/評書/獨幕喜劇/古典樂/民族樂/流行樂的次數。

需要說明的是，除了RFM類名額，還有一些基礎類和個性化的名額也非常關鍵，比如客戶基本資訊、季節性因素、商品特征、促銷活動、節假日事件等等都會影響到使用者的行為，資料倉庫設計師也需要考慮到這些因素，相關資料應反映在數倉中，此處不再贅述。

4、确定存儲政策。

雖然存儲已經白菜價了，但誰家也不是地主，不可能對所有表，每天都搞個全量快照。确定合适的存儲政策不僅有利于成本的壓降，也能減輕資料倉庫維護的難度。一般而言，對于交易類資料，毫無疑問存儲方式是流水表；對于變化不頻繁的資料可以按月彙總存為全量快照表；非必要情況下，不推薦使用拉連結清單，因為拉連結清單的可了解性差、解釋成本高、在追曆史的時候容易出錯，而且時間久了以後分區數量也會極度膨脹，對于一些變化頻繁的資料，拉連結清單也并不能帶來存儲成本的降低。

5、确定架構和開發規範，傳遞開發實施。

數倉架構設計的一項重點内容是數倉分層，分層是業界的共識了，各層各司其職，一般底層是用于鋪墊資料基礎、一些轉換和清洗，中間層合并、彙總，上層産生資料統計、複合/高維特征，就類似于我們的求學：義務教育階段是打牢基礎知識->高中階段重點學科強化->大學選擇一門學科方向->研究所學生選擇更加細分的領域精進突破。具體而言，一般業界有“ODS-DWD-ADS-集市”這樣的經典數倉分層架構，此處不再贅述。

開發規範方面，需要有開發實施人員一起參與制定，這個階段涉及到開發語言和平台選擇、命名規範、層次調用規範、一些開發習慣、共識約定等等。

6、數倉營運

數倉營運雖然寫在最後，但是作用卻是極為重要的，任務也非常繁重。這幾年流行一個詞叫“熵增”，數倉營運就是對抗熵增，保障熵減的過程。因為數倉連接配接了上下遊，源系統變動、邏輯修改多、下遊影響多，是以資料模型更新、變動曆史、修數情況，都要記錄在案，時常維護、更新釋出。除此之外，資料品質監控、作業運作、日志檢查、通知機制等等，都是需要每天關注、長期維護的。數倉營運的工作很枯燥，也很難是工作亮點、很難引起上級上司重視，可以說是一種“下水道”工作。筆者建議做數倉營運的人，在順利調崗之前，千萬不要體制化（institutionalized），不要适應和陷入那種忙忙碌碌的事務主義。