資料架構目標

大家有沒有遇到下面這種情形

情形1:

每個月總有那麼幾次別人反饋資料不準的問題，並且有些人反映我們的資料，髒，亂，差，不準確，最終導致業務方不滿意，對資料團隊產生抱怨情緒。

情形2：

取數不斷，需求不斷，疲於奔命，四處救火，一會這裡有問題，一會那裡有問題，最終團隊內部成為人肉取數機，天天加班，成為了一名真正的SQL-BOY。到了年底考核，你們團隊加班最多，但是產出價值最低，考慮到你們還是有苦勞的，給你箇中等把，一臉懵逼，還不知道所以然。

聊到這裡，上面情形面對的問題是不是我們在設計架構時候，就需要考慮解決的問題。為什麼資料不準確，為什麼產資料的資料沒有價值，得不到業務認可，得不到老闆的認可，那麼這幾個為什麼引出的我們的架構目標。

一個資料團隊假設有5個人，平均薪水2w，那麼對企業來說，一個月的成本10w，一年的人工成本120w，再加上IT成本，至少200w+。企業不會養閒人的。成本在這裡，那麼我們架構的目標其實也在這裡，就是如何減少企業成本，提高效率。資料價值該如何體現，是我們架構的主要目標。

高管會關心目前公司產品運轉現狀，資料是否錄得好的增長，營收情況如何，企業效率是否有所提高。從宏觀層面，大資料能夠很好概括、監控公司的產品大盤，整體性反饋使用者行為。

產品運營會關心，當前使用者滿意度如何，AB測試下的新功能是否顯著有效，產品現有功能是否穩定，使用者行為是怎樣的，運營活動效果表現如何?從微觀層面，大資料能夠刻畫每類乃至每個使用者的行為模式和反饋，並且透過洞察這些行為打造相關的效率工具。

研發、測試和運維會關心，我們所打造所維護的軟體服務、系統、客戶端是否足夠健壯，可用性是否得到保障，各個模組是否反應足夠敏捷快速。大資料透過合理的資料埋點，能夠輕易勾勒出全鏈路的產品服務質量，打造企業獨有的APM工具系統。

大資料中臺架構

為了面向業務服務服務建模，為了整合資源，為了讓資料複用，為了讓資料的價值得到更好的分析挖掘，為了.....，我們設計了下面大資料中臺分層架構。

大資料中臺總體分層架構耦合性比較低，分為PAAS(platform as a service)層、 DAAS (data as a service)層、DA(data application)層共三層架構。

資料倉儲層可以分為四層，分別是ODS層、 DW層、 DM層、 DA層等。

為什麼這樣設計?清晰的資料結構，每一個資料分層它的作用域，在使用表的時候能更方便的定位和理解;遮蔽業務的影響，不需要每次業務的變動，就需要重新接入資料，進行計算;遮蔽原始資料的異常，經過前面幾層的資料清洗，後續資料分析得到的資料都是非常乾淨的資料;減少重複開發工作，嚴格規範資料分層的作用，開發出來一些公共的資料，可以極大的減少資料的重複計算;將複雜的資料統計邏輯簡單化，將複雜的任務按照分層，分層一個個任務，每一層只是處理其中的一步，後續資料自測的時候，進行資料準確性校驗，同時後續萬一資料有問題了，修復問題後重新跑資料，我們沒必要把資料資料都跑一遍，只要跑有問題的那一張表後面的任務流程就可以了。

其實最重要的是，我們可以做資料地圖，當我們業務部門特別多的時候，我們給他們開發寬表資料，對應的寬表，如果有一張表有問題，我們可以透過資料地圖快速的定位找到這張寬表從哪裡來的，涉及到哪些資料來源，做了哪些清洗等。