Categories
程式開發

企業究竟該如何構建數據模型?


模型沒有對錯之分,只有適合的業務場景之分。數據模型能夠促進業務與技術進行有效溝通。只要基於數據進行決策及拓展業務邊界,好的數據模型必不可少。那麼,企業究竟該如何構建數據模型呢?

數據中台能解決什麼問題?

我們用四個字總結:全、統、通、用。全:數據中台和數據倉庫的區別,數據倉庫是滿足業務需求或業務主題的;而數據中台是一個大而全的概念,為企業提供戰略性的數據中台服務。數據應收盡收,所有能沉澱到數據中台的數據都收集到數據中台,包括增量、全量、實時、離線的數據。

統:統一數據標準規範。從數據質量標準、安全標準、模型規範、開發規範統一起來形成數據資產。

通:打通人的身份ID、商品ID、媒介ID,消除數據孤島。

用:體現在數據服務,用起來會有流共享、批共享及其他共享。總結起來:「全」是基礎;「統和通」是途徑;「用」是最終目的,最高境界是數據驅動業務創新和變革。

數據中台=方法論+實施+工具

數據中台能落地的關鍵點:強大的數據中台理論體系支撐+大數據實施流程體系、業務團隊能力+大數據建設產品工具集。

One Data方法論

企業究竟該如何構建數據模型? 1

一種數據=一種型號+一種ID +一種服務

One Model:統一數據模型,規範指標、標籤,消除二義性,將數據從成本中心變成利潤中心。

企業究竟該如何構建數據模型? 2

One ID:實體ID的唯一性,數據打通後進行數據升維,將數據從孤立變為融通。

One Service:統一數據服務,數據從過去的複製到一次開發,多次復用。

數據模型選擇思考

熟悉數據倉庫的同學都了解兩位大師,一位是數據倉庫之父——Bill Inmon,他提倡的頂層設計是自頂向下的,採用三範式的設計,非常嚴謹可減少數據的冗餘。

另一位是維度建模大師——Ralph Kimball,維度建模更簡單,執行起來更容易上手。頂層設計思路是自底向上的,從業務出發,從概念模型到邏輯模型再到物理模型,提倡先有數據集市,各個小的數據集市可以組成數據倉庫。

企業究竟該如何構建數據模型? 3

這裡僅列舉兩種模型:星型模型與雪花模型。星型模型是維度建模中比較經典的模型,也是目前用的較普遍的模型,星型模型是所有維度表都直接連接到事實表上,整個圖解就像星星一樣。

雪花模型是對星型模型的擴展。通過三範式建模,數據冗餘比較少,更加規範、嚴謹,更有利於保持數據的一致性。

企業究竟該如何構建數據模型? 4

通常情況下,為了讓下游能更好理解業務,快速提供數據服務,我們會選擇星型模型;而在維度信息變化非常頻繁,或者數據存儲成本非常高的情況下,我們可以採用雪花模型。歸根到底,數據模型沒有好壞之分,只有能否解決業務問題。

那泛零售企業該如何選擇數據中台模型?

從頂層設計、建模理論、業務場景三個大方向考慮。

頂層設計:數據中台是大而全的概念,Inmon大師自頂向下的設計思路兼顧業務全局,比較符合數據中台理論。

建模理論:主要以維度建模為核心,結合多種建模百花齊放。

業務場景:如泛零售行業最主要的是,“人貨場”,從“人”:組織、客戶;“貨”:商品、服務;“場”:渠道、門店、商場等;“行為”:訂單、營銷、工單等考慮。 OneModel圖片

普遍情況下,一個大的集團可能有好多個大的業務板塊,比如地產、金融、電商等。而一般的小公司業務比較單一的話就只分一個業務板塊。

數據域是面向業務分析,將業務過程或者維度進行抽象的集合。

業務過程是指企業的業務活動事件,如下單、支付、退款都是業務過程。

維度設計是維度建模的靈魂,也是數據中台模型設計的基礎,維度設計的核⼼是構建⼀致性維度。而粒度可以認為是維度的組合,如賣家和買家結合起來可以理解為兩個維度,一個粒度。數據模型最佳實踐

好的數據模型最終都為業務而生。

具體來說,就是把業務抽象化,提煉成數據模型,再通過數據解決業務問題。

數據建模過程中有哪些常見問題?

數據域劃分:可理解,全局考慮,數量適中。

業務過程:是一個邏輯的概念,需與度量關聯。

一致性維度:做維度表的時候,有的公司有自己的主數據系統,但有些公司沒有自己的主數據系統,需要將數據合併,因此誕生了橋接表,用邏輯的維度表,底層是多張表拼湊而成,且維度表每天都在變化。

明細事實表:分為多事實、單事實、無事實的事實表,很多人會誤解為事實表一定要有度量值,但不一定,有的是行為的操作數據,甚至維度表和事實表之間可以相互轉換,只有在粒度一致的情形下,才能將多個的事實進行合併。

數倉分層:從ODS-CDM-ADS。

企業究竟該如何構建數據模型? 5

了解維度和粒度之間的關係, 粒度是維度的組合。

數據模型過程中,有何設計心得?

數據不丟失,是最重要的一點。在ODS層的設計就需體現,要長期保留數據。

數據不重複,為保證數據治理的準確性,重複的數據需要提前剔除。

模型能共享,數據集市中的模型共享容易做到,數據集市是滿足業務需求的,但是數據中台的模型共享,明細事實表和維度表都需要用到,但是業務會不斷進行迭代和創新,所以也可能避免不了要從原始數據中取的可能。

空間換時間,為了能更大程度進行共享,可以做冗餘的設計。

任務能重跑,保證後期的運維能力。

業務是爸爸,所有不考慮業務的數據模型都是耍流氓。即使數據模型設計得再好,若業務模型不認可,不滿足業務的數據模型都是無效的。數據模型最終都是為業務服務的。不管是黑貓白貓,在一定的設計思想裡滿足之後都是可以進行創新的。

數據模型的前沿暢想

新方向=產品化+行業化+智能化

企業究竟該如何構建數據模型? 6

模型產品化

盤點即上雲:若對數據進行認真盤點,收集足夠多的元數據,把表結構、字段類型、數據庫類型,只要把元數據盤點完後一鍵導入,並可以一鍵生成頭部任務,因此,數據開發人員只需要解決異常情況即可。

設計即開發:有了模型的設計,維度表、事實表、指標定義後,底層的代碼是自動實現的,不必再擔心SQL的優化、性能調優。

資產即服務:所有的數據進行模型設計後,所有的表都可以進行數據資產化,有了資產即有服務。

模型行業化

每個行業有明顯的特點,如泛零售行業對人貨場的分析比較固定,因此建的模型固定的部分是可以通用的。

模型智能化

模型設計越來越簡單,容易上手,模型物理層的優化越來越智能,模型和智能應用結合,賦能業務。

作者簡介:

天啟,奇點雲高級數據架構專家。原海爾集團數據架構師,原阿里巴巴政務團隊數據架構師。

精通數據倉庫建模理論及數據開發技術,具備零售、政務、醫藥、製造等多個領域數倉和數據中台建設經驗及PB級數據倉庫與數據中台建設經驗。