工業資料分析之數倉建模 | 正規化建模和維度建模，你pick誰？

工業資料分析是指利用資料管理和資料分析技術，對工業資料進行處理和分析，挖掘資料價值，實現裝置執行安全可靠、生產效率提升、成本降低、產品質量提升等業務目標。

工業資料分析的基礎是對工業資料進行良好的組織和管理。在典型的資料湖-資料倉儲兩層資料架構中，資料湖讓資料聚集、可以被集中訪問，但是資料湖中的資料是按照資料來源的格式原樣儲存的。在面向資料分析的場景中，例如裝置智慧運維、生產過程優化等，還需要利用資料倉儲技術，對來自多個資料來源的大量歷史資料進行格式化處理和整合，建立資料基礎，為分析課題的成功提供保障。

然而在實踐中，我們發現面向工業資料分析的資料倉儲經常存在以下的問題：

• 資料模型的定義比較隨意，會隨著資料分析的要求隨意增減欄位和資料表;

• 資料欄位和資料表表達的業務語義不明，重要的業務規則隱藏在資料處理邏輯中;

• 業務專家和資料分析師不能很好的參與到資料建模過程中，資料工程師只能根據業務專家的描述和資料分析師的具體需求被動的進行響應;

• 多個相關的資料分析課題不能互相複用資料，存在大量的重複資料處理和清洗過程。

如果您是一名在工業企業內部的IT工程師或資料分析師，您可能對資料倉儲這種來自資料管理領域的抽象晦澀的概念不是很瞭解，更不知道如何在實際的工作中應用此技術;如果您是一名來自較強IT技術背景的資料專家，服務於工業領域，您可能希望瞭解在工業資料分析領域應用資料倉儲和其他資料管理技術的實踐經驗，少踩一些坑。那麼希望本文能夠對您有所幫助。

在下文中，我們通過工業場景的示例，對資料倉儲建模的基本概念進行解釋。本文對解資料倉儲的兩種基礎建模體系-正規化建模和維度建模的異同點以及分別適用的工業資料分析場景進行探討。說明為什麼在當前工業資料分析領域成熟度下，應當優先選擇正規化建模。

工業資料分析的特點

在工業資料分析中，有幾個較為突出的特點，在確定資料管理思路時需要結合考慮。

1)需要跨界融合。工業資料分析涉及工業核心裝置、生產過程的多領域機理，還需要結合專家經驗，因此其行業門檻較高，這就需要工業專家(以下或簡稱OT)、資料科學家/分析師(以下或簡稱DT)、IT和資料工程師(以下或簡稱IT)的跨界溝通、協作。

2)資料質量參差不齊。一個典型的工業企業發展過程中會持續進行自動化和資訊化建設，週期跨度從幾年到幾十年不等，來自不同建設時期和背景的資訊化系統中的資料含義、格式、規範區別較大，也較少存在資料標準，因此資料分析課題需要對資料質量有定量理解。

3)資料分析從單點到全面轉換。工業資料分析在企業中的應用逐漸廣泛，其價值開始體現，越來越多的企業從單點應用開始考慮有規模、有計劃的建設資料分析能力，這就需要一個能夠持續積累資料資源的資料底座，使得資料倉儲能夠在多個資料分析課題中得到複用，減少重複建設浪費。

資料倉儲建模體系

資料倉儲從產生到今日，其建模體系和思路是不斷髮展的。本文我們著重探討其中兩種最為基礎和常用的建模體系：正規化建模和維度建模。在瞭解其基本方法之後，我們討論如何在工業場景中選擇和應用這兩種方法。

值得強調的是，任何資料模型都是對要解決的業務問題領域的抽象，強依賴於業務領域中的基本概念和業務規則，因此資料建模一定需要業務專家、資料管理技術專家全程參與建立和更新。

正規化建模

資料倉儲的正規化建模是從OLTP資料庫設計中衍生而來，正規化建模使用實體-關係模型(Entity-Relationship Model)作為建模語言。在OLTP資料庫設計中，正規化建模主要強調資料的插入和更新一致性，而資料倉儲的正規化建模主要強調對業務領域的基本概念、規則的辨析和準確表達。

實體(Entity)指業務領域中我們感興趣的那些物件和事件，實體可能是物理上的存在，例如一臺裝置，一條產線，一個產品，也可能是邏輯上的存在，例如一個訂單，一次銷售。因為筆者主要從事的是以工業裝置為核心的生產執行過程的資料智慧應用，所以主要涉及的都是前者，我們稱為“工業物理物件”。

實體型別(Entity Type)指一批具有相同型別的實體的集合。嚴格來說，在資料建模的過程中，我們從一個特定的實體(例項)出發，去抽象和定義的是他所屬的實體型別。實體及其型別一定是一個名詞，命名之後最重要的工作就是仔細辨析這個名稱(概念)的內涵和外延，最後定義實體的屬性來反映這個概念。

工作組中所有人都應該對模型中的實體型別表達的概念理解一致無歧義。舉個例子，在生活中我們提到“物料”和“產品”，通常認為“物料”是原材料，“產品”是最終產品，然而在特定的工業資料模型中，例如ISA95生產資訊整合模型，“物料”被定義為可以是原料、半成品或者成品(因為從更大的範圍來看，一個生產段產生的“成品”其實是下階段的“原材料”)。如果不把這個概念表達清楚，工作組中的溝通就會變得失真、低效，甚至南轅北轍。

針對同一個業務問題，資料模型也不是隻有一個正確答案，換一個抽象的層次和角度，把“原料”和“最終產品”分開定義當然也是對的。筆者強調的是在一個特定的模型版本中，所有的概念都應該是清晰無歧義，形成共識的;如果模型更新了，所有人的共識都要跟著更新。

關係(Relationships)指實體和實體之間由於某種業務規則而產生的聯絡和互動。關係就像膠水一樣，把原本獨立的實體資訊整合在一起。例如，一臺裝置上有多個感測器、多個感測器可能會度量同一個邏輯測點(感測器冗餘)、一個車間包含多條產線、一條產線包含多個工段等等。

關係的定義也需要依照業務規則進行，如果我們識別到兩個實體之間會產生一個關係，我們要進一步識別以下幾方面的內容：

1)關係的基數，即一對一、一對多、還是多對多;

2)關係的強弱，即產生關係的兩個實體生命週期是否受關係的影響;

3)關係的附加屬性;

4)關係雙方在這個關係中的角色名稱。

舉個例子，假設我們對一個金屬鑄造的過程進行資料建模。模具需要安裝到鑄造機臺上進行鑄造使用，假設業務目標是要找出不同的鑄造機臺是否會對鑄造質量產生影響，那麼機臺和模具之間的關係可以由下圖表示：

在上圖中，機臺和模具的關係基數是一對一，因為一個機臺最多繫結一個模具，同時一個模具也不可能安裝到多個機臺上;關係的強弱是強關係，因為鑄造是由機臺和模具共同完成的，在當前定義的問題中，沒有必要把他們分開看，如果從系統中把一個鑄造機臺記錄刪除，那麼上面安裝的模具記錄也可以一併刪除;關係上也無需附加任何額外屬性;雙方的角色名只有在資料訪問的時候才會用到，目前暫不討論。

之後，我們從業務專家那裡瞭解到，我們忽略了一條重要的業務規則，即“鑄造機臺和模具之間雖然在一段時間內是一對一的繫結關係，但是每隔一段時間，都會把模具從機臺上拆卸下來換上新的模具，拆下的模具會被清洗儲存，直到下次安裝到其他(不確定是哪臺)的機臺上使用，如此迴圈”。基於上述新的業務知識，我們修改關係如下：

在版本2中，關係的基數變成了多對多，因為任何一個機臺都可能安裝任意一個模具，反過來，一個模具也有可能被安裝到任意一個機臺上;關係的強弱變成了弱關係，因為模具不再依賴於機臺的存在，因為模具會被單獨清洗保管，有可能沒有安裝在任何一個機臺上。我們還需要一個關係附加屬性來表達“在什麼情況下，一個特定的機臺會和一個特定的模具繫結在一起”。業務專家反饋說：“換模具是在換批次的間歇進行的，換批次的時候可能換模具，也可能不換，取決於模具是否需要清洗，但是在一個鑄造批次執行過程中不可能換模具”，因此我們得知，只要在關係額外屬性上記錄批次號，機臺和模具的繫結關係就完整了。

通過上面的例子，我們體會到資料模型中關係的定義是如何反映實際的業務規則的。假設業務專家說：“換模具的時間沒有特定規則，就是班組長覺得需要換了就換，即使在一個批次生產過程中。但是換模具的時候我們有記錄，因為工人會掃碼”，感興趣的讀者可以思考，在上述規則下，機臺和模具的關係應該怎麼建。

最後，正規化建模也會有一些門檻，即資料模型要滿足三正規化的要求，這需要一定的資料庫模型理論和技能基礎，這也是正規化建模體系最終不被採用的重要因素之一。但是筆者相信，在工業資料智慧領域，最大的門檻不是特定的資料庫技術，而是工業知識、IT知識和資料分析知識的融合。在正規化建模過程中，業務專家、IT專家、資料分析專家依據業務規則對資料模型進行反覆澄清討論，由此產生的資訊交流和最後產出的資料模型會幫助整個團隊建立共同業務認知和語言體系，這對後續資料分析和應用的研發是一個重要的基礎。

維度建模

在維度建模(Dimensional Modeling)中，資料被分為事實和維度兩種型別。事實指在業務過程中發生的一次度量，而維度指這次度量發生的上下文。一次度量(事實表中的一行)可以包含多個度量結果和多個與之關聯的維度資訊。

在工業領域中，來自於DCS或者SCADA系統中的裝置時序資料是最典型的事實資料之一：PLC的一次取樣會產生多條測點資料，例如溫度、壓力等，同時伴隨這條事實資料的至少有兩個維度——時間戳和點位號。另一個工業產品製造領域常見的事實資料是生產過程中的質檢資料：一個半成品或者成品在檢測環節經過特定檢測手段會產生的一次檢測結果記錄。檢測的指標，例如尺寸、重量等屬於度量資料;而被檢測的產品ID、檢測程式、檢測機臺等屬於維度資料。

在事實表中，維度列的取值只是一個單值(標量)，但背後通常代表的是一個業務實體(這也是為什麼很多維度列以某某ID命名)，我們稱其為維度實體。一個維度實體又可以和其他的實體產生聯絡。例如上面的例子中，裝置時序資料表中的“點位號”代表的“點位”可以抽象為一個物件，除了點位號(ID)之外還有度量單位、量程、物理意義等屬性。通常多個點位又同屬於一臺裝置，所以一個點位物件又和一個裝置物件發生關聯，等等。根據事實表和維度表之間組織成的形狀不同，維度模型分為星型模型(Star Schema)和雪花模型(Snowflake Schema)兩種型別。

星型模型是以事實表為中心，所有的維度直接和事實表相關聯，維度和維度之間沒有關聯，維度表圍繞在事實表周圍成星狀分佈。

雪花模型以星型模型為基礎擴充套件，允許維度表和維度表之間繼續產生關聯關係，也就是說，事實表可以通過維度和維度的關聯獲得間接維度。

同一個問題，既可以用星型模型組織資料，也可以用雪花模型組織資料，那麼這兩種模型的優缺點分別是什麼呢?我們用裝置時序資料為例進行對比說明。

上圖是裝置時序資料的星型模型組織。首先，點位號是裝置時序資料的一個維度，通過一個點位實體型別來記錄點位物件的其他屬性;時間戳是一個維度但是一般在工業資料分析中，時間戳直接參與運算，並不會像銷售資料那樣，時間是小時、天、月、年等自然時間段進行分析聚合的，因次不用進行物件化處理。接下來，假設分析課題要在裝置的粒度上對監測資料進行聚合，例如存在多個點位是對同一裝置元件的冗餘測量，我們需要計算他們的平均值。針對這個問題，星型模型方式需要重新處理事實表，增加一個“裝置ID“維度，並且與裝置實體型別進行關聯。

上圖是裝置時序資料的雪花模型組織。點位號和時間戳兩個維度的處理方式與星型模型相同，這裡不再贅述。不同之處在於，如果我們要增加一個新的分析維度“裝置”，並且經過業務分析我們知道多個點位是屬於同一個裝置的，也就是說，裝置和點位之間存在一個一對多的關係，那麼我們就按照正規化建模的思維在點位和裝置實體型別事件建立一個新的關係，時序資料需要在裝置維度進行聚合時，要通過關聯點位再關聯裝置的方式進行。

對於兩種模型，我們不難發現雪花模型其實是星型模型的維度部分用正規化建模處理的結果。星型模型的好處是維度資料和事實表永遠直接關聯，因此資料庫訪問的效率相對較高，但是缺點是間接維度在事實表中存在資料冗餘，如果維度資料進行更新，或者業務上提出新的分析需求需要增加維度，那麼事實資料就需要重新進行清洗處理，因此星型模型比較適合處理“預先定義的，需求相對確定的”資料分析課題。

相比之下，雪花模型的維度部分用正規化建模處理，在關聯查詢，尤其是多層次的維度關聯查詢時，效率略低，但是換來的好處是資料模型相對穩定，維度的更新、增加等操作代價較小，對分析需求的變更有一定的自適應性，因此雪花模型適合解決“探索性的、隨時有可能變化的、臨時的”資料分析課題。

工業領域的資料倉儲建模體系選擇

表：正規化建模對比維度建模

上表對比了資料倉儲正規化建模和維度建模體系的優缺點。在工業領域應用時，企業應該結合自身的資料智慧應用成熟度和具體建設專案目標來確定資料倉儲的建模和實施思路。

對於資料智慧的嚐鮮者，可以採用維度建模針對單個課題進行資料組織建模，這樣專案的建設啟動時間短，資料建模的難度也相對較低，能夠快速完成資料分析課題，獲得價值，這樣可以幫助團隊和企業建立對資料智慧應用的信心。

對於開始有規劃的建設跨課題、跨部門統一資料底座的企業，建議開始採用正規化建模的思路，通過有意識的組織業務專家、IT專家、資料分析專家進行協作，對一個給定的業務範圍的基本業務物件、規則進行辨析，規範命名，構建統一正規化資料模型;對於事實資料的部分，建議採用維度建模中的雪花模型進行組織，即維度部分也儘量採用正規化建模的方式處理。這樣可以獲得相對穩定，維護代價較小的資料模型，雖然啟動的成本增加，但是從長期維護和應用，是總體效率較高的方式。更重要的是，正規化建模可以促進團隊乃至組織對業務概念、規則、知識進行溝通交流，構建統一語言。

實施正規化建模的一大誤區就是一開始就陷入大而全的境地。例如以工業裝置為核心的生產執行領域，基本生產要素包括裝置、工藝方法、物料、人、環境等幾大模組，每個模組分解後，其包含的實體型別數量都會有幾個到幾十個不等，試圖一次性把範圍如此龐大業務領域梳理清楚是幾乎不可能，也沒有必要的。建議按照主題的方式進行業務劃分，每個主題的範圍不宜過大，但是要儘量做透，以業務場景驅動完成底層基礎資料建模。如此迭代幾次，以拼圖的方式完成更大業務範圍的基礎資料建模工作。

總結

本文介紹了資料倉儲建模的兩種基本體系：正規化建模和維度建模的概念和基礎方法。通過與工業資料分析領域相結合，探討了如何把這些抽象的IT方法與具體的工業資料分析業務結合進行實踐。我們著重對比了不同資料建模體系的優缺點，主張結合企業自身資料智慧應用的成熟度和專案目標選擇合適的資料建模體系。在有可能的情況下，我們推薦優先使用正規化建模相關的技術，會給分析課題和企業帶來以下價值：

• 有利於在工業企業內部推動工業專家、資料科學家/分析師、IT和資料管理技術的融合，促進跨領域交流，形成共同語言;

• 讓資料的業務意義顯現化，讓業務和資料分析師以更直觀的方式獲取資料，提高資料的可被消費性;

• 為資料整合奠定良好的後設資料基礎。