<object id="3iwlw"><noframes id="3iwlw"></noframes></object>

      <th id="3iwlw"></th>

    1. <rp id="3iwlw"></rp>
      <rp id="3iwlw"></rp>

    2. <button id="3iwlw"></button>
      云計算·大數據 頻道

      范式建模和維度建模,你pick誰?

      工業數據分析是指利用數據管理和數據分析技術,對工業數據進行處理和分析,挖掘數據價值,實現設備運行安全可靠、生產效率提升、成本降低、產品質量提升等業務目標。

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

      然而在實踐中,我們發現面向工業數據分析的數據倉庫經常存在以下的問題:

      ? 數據模型的定義比較隨意,會隨著數據分析的要求隨意增減字段和數據表;

      ? 數據字段和數據表表達的業務語義不明,重要的業務規則隱藏在數據處理邏輯中;

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

      ? 多個相關的數據分析課題不能互相復用數據,存在大量的重復數據處理和清洗過程。

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

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

      工業數據分析的特點

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

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

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

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

      數據倉庫建模體系

      數據倉庫從產生到今日,其建模體系和思路是不斷發展的。本文我們著重探討其中兩種最為基礎和常用的建模體系:范式建模和維度建模。在了解其基本方法之后,我們討論如何在工業場景中選擇和應用這兩種方法。

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

      范式建模

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

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

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

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

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

      關系(Relationships)指實體和實體之間由于某種業務規則而產生的聯系和互動。關系就像膠水一樣,把原本獨立的實體信息整合在一起。例如,一臺設備上有多個傳感器、多個傳感器可能會度量同一個邏輯測點(傳感器冗余)、一個車間包含多條產線、一條產線包含多個工段等等。

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

      1)關系的基數,即一對一、一對多、還是多對多;

      2)關系的強弱,即產生關系的兩個實體生命周期是否受關系的影響;

      3)關系的附加屬性;

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

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

      圖片

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

      之后,我們從業務專家那里了解到,我們忽略了一條重要的業務規則,即“鑄造機臺和模具之間雖然在一段時間內是一對一的綁定關系,但是每隔一段時間,都會把模具從機臺上拆卸下來換上新的模具,拆下的模具會被清洗保存,直到下次安裝到其他(不確定是哪臺)的機臺上使用,如此循環”?;谏鲜鲂碌臉I務知識,我們修改關系如下:

      圖片

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

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

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

      維度建模

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

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

      圖片

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

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

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

      同一個問題,既可以用星型模型組織數據,也可以用雪花模型組織數據,那么這兩種模型的優缺點分別是什么呢?我們用設備時序數據為例進行對比說明。

      圖片

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

      圖片

      上圖是設備時序數據的雪花模型組織。點位號和時間戳兩個維度的處理方式與星型模型相同,這里不再贅述。不同之處在于,如果我們要增加一個新的分析維度“設備”,并且經過業務分析我們知道多個點位是屬于同一個設備的,也就是說,設備和點位之間存在一個一對多的關系,那么我們就按照范式建模的思維在點位和設備實體類型事件建立一個新的關系,時序數據需要在設備維度進行聚合時,要通過關聯點位再關聯設備的方式進行。

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

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

      工業領域的數據倉庫建模體系選擇

      圖片

      表:范式建模對比維度建模

      上表對比了數據倉庫范式建模和維度建模體系的優缺點。在工業領域應用時,企業應該結合自身的數據智能應用成熟度和具體建設項目目標來確定數據倉庫的建模和實施思路。

      對于數據智能的嘗鮮者,可以采用維度建模針對單個課題進行數據組織建模,這樣項目的建設啟動時間短,數據建模的難度也相對較低,能夠快速完成數據分析課題,獲得價值,這樣可以幫助團隊和企業建立對數據智能應用的信心。

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

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

      總結

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

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

      ? 讓數據的業務意義顯現化,讓業務和數據分析師以更直觀的方式獲取數據,提高數據的可被消費性;

      ? 為數據集成奠定良好的元數據基礎。

      0
      相關文章
        漂亮的苏酥全文阅读