進入主頁，點擊右上角「設爲星標」python
比別人更快接收好文章mysql
前言
技術是爲業務服務的，業務是爲公司創造價值的，離開業務的技術是無心義的web
業務介紹
公司屬於金融科技ToC企業，針對不一樣需求的用戶開發不一樣的產品，因此公司內部有不少條業務線，可是對於數據部門來講，全部業務線的數據都是數據源。對數據的劃分不僅是根據業務進行，而是結合數據的屬性。sql
早期規劃
以前開發是不一樣業務線對應不一樣的數據團隊，每一個數據團隊互不干擾，這種模式比較簡單，只針對本身的業務線進行數倉建設及報表開發便可。shell
可是隨着業務的發展，頻繁迭代及跨部門的垂直業務單元愈來愈多，業務之間的出現耦合狀況，這時再採用這種煙囪式開發就出現了問題：數據庫
例如權限問題，公司對數據管理比較嚴格，不一樣的數據開發組沒有權限共享數據，須要其餘業務線的數據權限須要上報審批，比較耽誤時間；微信
還有重複開發問題，不一樣業務線會出現相同的報表需求，若是每一個業務方都開發各自的報表，太浪費資源。架構
因此對於數據開發而言，須要對各個業務線的數據進行統一管理，因此就有了數據中臺的出現。app
數據中臺
我認爲數據中臺是根據每一個公司具體的業務需求而搭建的，不一樣的業務，對中臺的理解有所不一樣。框架
公司內部開發的敏捷數據中臺，主要從數據技術和計算能力的複用，到數據資產和數據服務的複用，數據中臺以更大價值帶寬，快準精讓數據直接賦能業務。提供一個統一化的管理，打破數據孤島，追溯數據血緣，實現自助化及高複用度。
以下所示：
以上解釋比較抽象，咱們以實際項目開發來看下數據中臺的便利性。
好比咱們以前作報表開發流程，首先是要數據採集，不一樣的數據源經過sqoop等工具採集到大數據平臺，而後進行數倉搭建，最後產出報表數據，放到可視化系統展現，最終把整個流程寫成腳本放到調度平臺進行自動化執行。
而有了數據中臺以後就不須要那麼繁瑣，直接進行數倉搭建，產生報表便可，無需將精力過多放在數據源、可視化展現及調度。而且能夠直觀的查看數據血緣關係，計算表之間血緣。像下面圖中，表之間的依賴關係很明確：
另外一點，數據中臺的異構數據系統能夠很是簡單的進行關聯查詢，好比hive的表關聯mysql的表。
可透明屏蔽異構數據系統異構交互方式，輕鬆實現跨異構數據系統透明混算。
跨異構數據系統原理是數據中臺提供虛擬表到物理表之間的映射,終端用戶無需關心數據的物理存放位置和底層數據源的特性，可直接操做數據，體驗相似操做一個虛擬數據庫。
數據中臺還額外集成可視化展現，提供一站式數據可視化解決方案，支持JDBC數據源和CSV文件上傳，支持基於數據模型拖拽智能生成可視化組件，大屏展現自適應不一樣大小屏幕。
調度系統是公司內部自寫集成到數據中臺的，在編寫完sql語句以後能夠直接進行調度。
數倉建設
到這才真正到數倉建設，爲何前面要佔那麼大篇幅去介紹公司業務及所使用的數據中臺系統，由於下面的數倉建設是根據公司的業務發展及現有的數據中臺進行，數倉的建設離不開公司的業務。
數倉建設核心思想：從設計、開發、部署和使用層面，避免重複建設和指標冗餘建設，從而保障數據口徑的規範和統一，最終實現數據資產全鏈路關聯、提供標準數據輸出以及創建統一的數據公共層。
有了核心思想，那怎麼開始數倉建設，有句話說數倉建設者便是技術專家，也是大半個業務專家，因此採用的方式就是需求推進數據建設，而且由於數據中臺，因此各業務知識體系比較集中，各業務數據再也不分散，加快了數倉建設速度。
數倉建設主要從兩個方面進行，模型和規範，全部業務進行統一化
模型
全部業務採用統一的模型體系，從而下降研發成本，加強指標複用，而且能保證數據口徑的統一
模型分層
結合公司業務，後期新增需求較多，因此分層不宜過多，而且須要清晰明確各層職責，要保證數據層的穩定又要屏蔽對下游影響，因此採用以下分層結構：
數據流向
遵循模型開發時分層結構，數據從 ods -> dw -> dm ->app 這樣正向流動，能夠防止因數據引用不規範而形成數據鏈路混亂及SLA時效難保障等問題，同時保證血緣關係簡潔化，可以輕易追蹤數據流向。
在開發時應避免如下狀況出現：
數據引用鏈路不正確，如 ods -> dm ->app ，出現這種狀況說明明細層沒有徹底覆蓋數據；如 ods -> dw -> app ，說明輕度彙總層主題劃分未覆蓋全 。減小跨層引用，才能提升中間表的複用度。理想的數倉模型設計應當具有：數據模型可復⽤，完善且規範。
儘可能避免一層的表生成當前層的表，如dw層表生成dw層表，這樣會影響ETL效率。
禁止出現反向依賴，如dw表依賴於dm表。
規範
表命名規範
對於ods、dm、app層表名：類型_主題_表含義，如：dm_xxsh_user
對於dw層表名：類型_主題_維度_表含義，如：dw_xxsh_fact_users（事實表）、dw_xxsh_dim_city（維度表）
字段命名規範
構建詞根，詞根是維度和指標管理的基礎，劃分爲普通詞根與專有詞根普通詞根：描述事物的最小單元體，如：sex-性別。
專有詞根：具有行業專屬或公司內部規定的描述體，如：xxsh-公司內部對某個產品的稱呼。
腳本命名規範
腳本名稱：腳本類型.腳本功用.[庫名].腳本名稱，如 hive.hive.dm.dm_xxsh_users
腳本類型主要分爲如下三類：常規Hive sql：hive
自定義shell腳本：sh
自定義Python腳本：python
腳本內容規範
#變量的定義要符合python的語法要求
#指定任務負責人
owner = "zhangsan@xxx.com"
#腳本存放目錄/opt/xxx
#腳本名稱 hive.hive.dm.dm_xxsh_users
#source用來標識上游依賴表，一個任務若是有多個上游表，都須要寫進去
#(xxx_name 是須要改動的，其他不須要改)
source = {
"table_name": {
"db": "db_name",
"table": "table_name"
}
}
#如source，可是每一個任務target只有一張表
target = {
"db_table": {
"host": "hive",
"db": "db_name",
"table": "table_name"
}
}
#變量列表
#$now
#$now.date 經常使用，格式示例：2020-12-11
task = '''
寫sql代碼
'''
數據層具體實現
使用四張圖說明每層的具體實現
數據源層ODS
數據源層主要將各個業務數據導入到大數據平臺，做爲業務數據的快照存儲。
數據明細層DW
事實表中的每行對應一個度量，每行中的數據是一個特定級別的細節數據，稱爲粒度。維度建模的核心原則之一是同一事實表中的全部度量必須具備相同的粒度。這樣能確保不會出現重複計算度量的問題。
維度表通常都是單一主鍵，少數是聯合主鍵，注意維度表不要出現重複數據，不然和事實表關聯會出現數據發散問題。
有時候每每不能肯定該列數據是事實屬性仍是維度屬性。記住最實用的事實就是數值類型和可加類事實。因此能夠經過分析該列是不是一種包含多個值並做爲計算的參與者的度量，這種狀況下該列每每是事實；若是該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性每每是維度屬性。可是仍是要結合業務進行最終判斷是維度仍是事實。
數據輕度彙總層DM
此層命名爲輕彙總層，就表明這一層已經開始對數據進行彙總，可是不是徹底彙總，只是對相同粒度的數據進行關聯彙總，不一樣粒度可是有關係的數據也可進行彙總，此時須要將粒度經過聚合等操做進行統一。
數據應用層APP
數據應用層的表就是提供給用戶使用的，數倉建設到此就接近尾聲了，接下來就根據不一樣的需求進行不一樣的取數，如直接進行報表展現，或提供給數據分析的同事所需的數據，或其餘的業務支撐。
總結
一張圖總結下數據倉庫的構建總體流程：
實際生產中注意事項
生產環境中操做不能像咱們本身測試時那樣隨意，一不當心均可能形成生產事故。因此每步操做都要十分當心，需全神貫注，管好大腦管住右手。
僅列出如下但不限於如下的注意事項：
請勿操做本身管理及受權表以外的其它庫表；
未經受權，請勿操做生產環境中其餘人的腳本及文件；
在修改生產環境腳本前，請務必自行備份到本地；
請確認本身的修改操做能迅速回滾；
生產環境中表名及字段等全部命名請遵循命名規則。
歡迎小夥伴們 點贊，在看，轉發，收藏
本文分享自微信公衆號 - 五分鐘學大數據（gh_d4a7af3ecd50）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。