應對挑戰，做好預見性維護的資料準備
本文關鍵點
-
機器學習 (ML) 在工業物聯網 (IIoT ) 領域的資料管理和預測分析中發揮著重要的作用。
-
預見性維護 (PdM) 應用程式旨在將機器學習應用於工業物聯網資料集，以減少職業危害、機器停機時間，以及其他成本。
-
瞭解機器學習行業從業者所面臨的資料準備的挑戰，以及與預測維護相關的資料攝取和特徵工程的解決方案。
-
使用資料流管理工具 (如 streamset 或 Apache Nifi) 可以使資料攝取流程的開發和管理更加容易。
-
通常，長短時記憶 (Long Short-Term Memory, LSTM) 演算法用於預測時間序列資料中的罕見事件。由於一般在預測維護應用中故障是非常罕見的，所以它的建模很適合使用 LSTM 演算法。
機器學習使技術人員能夠用資料做出很奇妙的事情。它與物聯網驅動的網路化製造系統在齊頭並進地發展，物聯網也被稱為工業物聯網 (Industrial IoT)，它使可用於統計建模的資料呈指數級增長。
預見性維護 (PdM) 應用程式 旨在將機器學習應用於工業物聯網資料集，檢測機器何時出現與過去故障相關的特徵，從而減少職業危害、機器停機時間和其他成本。在這個過程中，預測性維護向工廠操作員提供資訊，幫助他們採取預防或糾正措施，例如:
-
以較低的速度或較低的壓力執行機器，將總體故障的發作推遲，
-
現場是否有備用裝置，以及
-
安排在合適的時間進行維護。
實施預見性維護涉及到從資料準備開始到應用機器學習結束的流程。從業人員都知道，為了使機器學習有效，資料準備需要做大量的工作，然而，在機器學習的相關著作中這些挑戰卻不斷地被忽視，而其作者更喜歡去講解概念上的資料集。
在本文中，我希望通過討論與預測維護相關的資料攝取和特徵工程的解決方案，幫助機器學習行業從業者應對所面臨的一些最困難的資料準備的挑戰。
資料攝取
預見性維護的第一步是需要資料採集。工業儀表通常與振動、紅外熱、電流、油脂中的金屬顆粒等物理量的測量密不可分。這些資料通常來源於工業控制網路中所連線的可程式設計邏輯控制器上的感測器。通過開發人員友好的協議 (如 REST 和 MQTT)，橋接控制和公司網路的資料閘道器很方便就能訪問到這些資料。還應考慮帶外資料來源 (如操作員日誌或天氣資料)，這也很重要，因為它們也可以包含與故障事件相關的訊號。如下圖 1 說明了這些型別的資料資產之間的相互關係。
資料流水線設計
資料攝取是由連續收集和儲存資料的過程完成的。這些流程可以按定製應用程式來實現，但通常使用資料流管理工具 (如 StreamSets 或者 Apache Nifi ) 更容易開發和管理。這些工具為建立和管理資料流水線帶來了許多優勢，例如：
-
簡化流水線的開發和部署。像 streamset 和 Nifi 提供的整合開發環境 (ide)，可以幫助把建立流水線所需的程式碼降到最少。它們還集成了實用工具用於監控和除錯資料流。此外，這些工具還支援具有流版本控制和持續交付等功能 DevOps 流程。
-
防止不要因為擴大規模、模式漂移和拓撲遷移而導致故障。資料流管理工具可以作為分散式系統中變更的重要角色。它們為處理增加的負載提供了合理的伸縮方式。例如，streamset 利用 Kubernetes 實現了彈性可伸縮性，預計 Nifi 在不久的將來也會這樣做。在演進基線模式時，資料來源也可以引入了顛覆性的變更。streamset 和 Nifi 使你能夠在即時重定向或重新格式化訊息的資料驗證階段處理模式漂移。基礎設施的結構拓撲也可以在應用程式生命週期中發生變化。streamset 和 Nifi 使您能夠定義拓撲無關的資料流，這些資料流可以跨邊緣、預置、雲和混合雲基礎設施執行，而不會犧牲資料的彈性或隱私性。
為了讓您瞭解資料流管理工具的功能，我準備了一個簡單的 streamset 專案，您可以在裝有 Docker 的膝上型電腦上執行它。該專案演示了一個流水線，該流水線將工業採暖、通風和空調 (HVAC) 系統記錄的時間序列資料流轉到 OpenTSDB 中，以便在 Grafana 中進行視覺化。
- 建立一個用來橋接容器的 docker 網路：
複製程式碼
dockernetworkcreate mynetwork
- 啟動 StreamSets、OpenTSDB 和 Grafana：
複製程式碼
dockerrun-it-p18630:18630-d--name sdc --network mynetwork \ streamsets/datacollector dockerrun-dp4242:4242--name hbase --network mynetwork \ petergrace/opentsdb-docker dockerrun-d -p3000:3000--name grafana --network mynetwork \ grafana/grafana
-
訪問 http://localhost:3000 開啟 Grafana，並以 admin / admin 登入
-
將 http://hbase:4242 作為一個 OpenTSDB 資料來源新增到 Grafana。如果你不知道如何新增資料來源，可以參考 Grafana 文件 。你的資料來源定義應該看起來如下圖 2 中的截圖所示。
-
下載 這個 Grafana 儀表盤檔案 。
-
匯入這個檔案到 Grafana 裡。如果你不知道如何匯入儀表盤，可以看一下 Grafana 的文件。你的匯入對話方塊看起來應該如下截圖所示。
- 下載、解壓和複製 這個 HVAC 資料 到 StreamSets 容器：
複製程式碼
unzip mqtt.json.gz docker cp mqtt.jsonsdc:/tmp/mqtt.json
-
訪問 http://localhost:18630 開啟 StreamSets，並以 admin / admin 登入
-
下載並匯入 f 流流水線 ollowing pipeline 到 StreamSets 中。如果你不瞭解如何匯入流水線，請參考 StreamSets 文件。
-
在 “Parse MQTT JSON” 階段你將看到一個關於缺少類庫的警告，單擊該階段並按照提示安裝這個 Jython 類庫即可。
- 執行 StreamSets 流水線。幾分鐘之後，StreamSets 儀表盤看起來應如下圖 5 截圖所示。
- 讓這個流水線執行幾分鐘之後，Grafana dashboard 儀表盤看起來應如下圖 6 截圖所示。
希望通過設定這個流水線和對 streamset 的研究，您能夠了解資料流管理工具可以做什麼了。
流水線 – 檔案, 表, 還是流?
資料流水線有起點和終點 ，也就是源和接收器。正如前面所提到的，MQTT 和 REST API 通常都用於讀取資料，但是流水線在哪裡結束差別很大，這取決於用例。例如，如果您的目標只是為了遵從法規而歸檔資料，那麼您可能讓流水線終結為一個檔案就可以了，因為檔案很容易建立和壓縮，能最小化儲存成本。如果您的目標是在像 Grafana 之類的監控工具中開發儀表板和警報，從而獲取裝配線上的關鍵指標，那麼您就可以使流水線通往 OpenTSDB 這樣的時間序列資料庫。對於預見性維護，確定如何持久化資料時的其他需求也有重要作用。我們來考慮一下檔案、表和流的相對優勢，以確定為預見性維護設計資料流水線的最佳方式：
檔案：檔案可以用來有效地讀寫資料。如果它們不是太大，也可以很容易壓縮和移動。但是，如果檔案變得很大 (比如千兆位元組) 或者變得非常多 (比如上千個) 時，就會導致難以管理，從而出現問題。除了難以移動之外，在大型檔案中搜索和更新資料可能也會非常慢，因為它們的內容沒有索引。此外，儘管檔案可以讓你以最大的靈活性用任意格式儲存資料，但它們缺少用於模式驗證的內建函式。因此，如果您在儲存損壞的資料前忽略了驗證，沒有丟棄它們，那麼就不得不在稍後資料清理時面對艱難的任務。
流：比如 Apache Kafka，流被設計成通過釋出 / 訂閱介面將資料分發給任意數量的使用者。這在執行多個數據處理器 (如機器學習的推斷任務) 時非常有用，因此它們不一定非要全都連線到原始資料來源，這種做法很沒有必要，而且無法伸縮。像檔案一樣，流也可以非常快速地攝取資料。與檔案不同的是，流提供了根據模式驗證傳入資料的能力 (例如使用 Apache Spark 中的 case 類—我將在後面進行演示)。將流水線終結為流的缺點是它們是不可變的。一旦資料到了流中，就不能修改了。若想更新流中的資料，惟一的方法是將其複製到新流中。如果訓練資料不可變，那麼對於預見性維護就不可取了，因為它阻止了諸如剩餘使用壽命 (RUL) 等特徵在發生重要事件 (如機器故障) 後進行回溯性更新。
資料庫表：可以進行模式驗證嗎？可以。可以進行更新嗎？可以。可以加索引嗎？可以！如果資料庫提供二級索引，那麼表索引尤其有用，因為它們可以加速查詢多個變數的請求。如上提到過流的釋出 / 訂閱介面的優點；資料庫也能提供這些優點嗎？同樣，答案仍是肯定的，當然前提是資料庫提供了更改資料捕獲 (change-data-capture, CDC) 流。資料庫的一個缺點是不能像檔案或流那樣快速地寫入資料。然而，有許多方法可以加速寫操作。一種方法是將流水線終結在流上。在這種情況下，流可以用於兩個目的。第一，它們可以緩衝高速脈衝；第二，它們可以將高速流水線分發給多個使用者，這些使用者可以橫向外擴充套件共同將必要的吞吐量寫入到一個數據庫中。當流和資料庫執行在相同的底層資料平臺上時，這尤其有效，情況與 MapR 類似。同樣值得注意的是， MapR-DB 提供了二級索引和 CDC 流。
將 MapR 作為預見性維護的資料平臺
工業物聯網需要一個以速度和容量伸縮的資料平臺。此外，模型開發要求機器學習工程師能夠在概念上快速迭代。MapR 通過將流、資料庫和檔案儲存聚合在一個線性伸縮的高效能資料平臺上來實現這一點，它提供的特徵使資料科學家能夠快速探索資料、開發模型和使這些模型運轉，而不會遇到阻力。
特徵工程
機器學習的潛力在於它能夠在資料中找到可泛化的模式。傳統的統計常常使用資料縮減技術來合併資料樣本，而機器學習則是在精度 (想象成行) 和維數 (想象成列) 都很高的資料集上蓬勃發展。為使您瞭解預見性維護推理模型需要消化多少資料量，請設想以下情況：
-
製造過程可以以有時速度為每秒多達數千個樣品 (例如，振動感測器) 的裝置來測量數百個指標。
-
失敗通常不常見 (例如，每月一次)。
-
ML 只能預測可以從訓練資料中泛化的事件。如果事件很少發生，那麼肯定需要長得多的時間來收集資料。一個好的做法是使用跨越數百個事件的資料集來訓練模型。
所以，鑑於工業物聯網資料本質上就具備豐富的精度和維度，同時預見性維護需要看到成百上千個罕見的故障案例，所以資料平臺規模過去常常儲存的訓練資料不僅必須按攝取速度和可擴充套件的儲存伸縮，而且還要考慮運維常常在訓練資料中查詢和獲取相關特徵。這個過程稱為特徵工程，它對機器學習能否成功至關重要，因為它是領域特定知識發揮作用的點。
特徵構建
特徵工程經常涉及到向訓練資料中新增新列，從而簡化手動或自動化分析。這些特徵可以幫助人們使用分析工具探索資料，並且它們對於機器演算法檢測所需的模式來說通常非常關鍵。特徵建立可以通過在攝取過程中增加原始資料或者追溯式地更新訓練資料來實現。為了瞭解其工作原理，我們來看一個例子。
製造過程的一個簡單工業物聯網資料集如下圖所示：
時間戳、裝置 ID 和三個名為 x、y 和 z 的指標，代表來自控制網路的效能指標。當我們對錶進行擴充套件以包含操作員日誌和其他帶外資料來源時，它看起來是這樣的：
為了將操作員和天氣列新增到這個表中，必須要做什麼? 我們一起來討論一下。
受控的資料來源和公司網路通常是不同步的。因此，操作員和天氣日誌中的時間戳將與工業物聯網資料中的時間戳不同。統一這些時間戳保持在一定的密度，能夠更好地回答所提出的問題，比如“顯示 Joe 操作的機器的所有物聯網資料”。這種資料整合非常適合在夜間進行批量的處理，因為更新一天的工業物聯網記錄可能需要很長時間。與其每次讓人通過基於時間的查詢同時訪問物聯網和日誌欄位，重複地進行這些處理，倒不如一次性花成本 (例如，每晚) 把資料都整合好。因此，當您檢視如上所示的表時，要識別出幕後的 Spark 作業或其他一些資料整合任務，必須將操作員 / 天氣日誌與工業物聯網日誌連線起來，並將它們統一為同一時間戳。
實現這個任務的方法有很多，但是當這些日誌位於不同的資料豎井中時，將它們合併到一個統一的特徵表中將很緩慢。這就是為什麼資料流水線將資料匯聚靈活的資料平臺如此重要，因為在這種平臺中可以以最小的資料移動執行資料整合。
特徵提取
特徵提取涉及組合變數以生成更有用的欄位。例如，將日期和時間欄位按組成部分進行分割是很有用的，這樣您就可以輕鬆地根據在這一天的幾點、在一週中的哪天、月亮的相位 (誰知道呢，對吧?) 等來劃分訓練資料子集。在批處理作業或流作業中很容易就能實現這種型別的特徵提取，因為可以用 Java、Python 和 Scala 等語言來實現這些作業，而這些語言都有一些用於簡化日期 / 時間操作的庫。但實現一個 SQL 函式來判斷日期 / 時間值是否在週末要困難得多。新增一個 _weekend 屬性，同時在流作業或批處理作業中增加一個特徵表，這樣可以使手動分析更加容易，並有助於機器學習演算法在一週內泛化模式。
特徵滯後
預見性維護是一種稱為 監督式機器學習 的機器學習，因為它涉及到構建一個預測標籤的模型，基於的是這些標籤如何對映到訓練資料中的特徵。預見性維護最常用的兩種標籤是：
-
接下來 n 步失敗的可能性 (例如，“即將失敗”)
-
下一次故障前的剩餘時間 (或機器週期)(如“剩餘使用壽命”)
第一個特徵可以使用二進位制分類模型進行預測，該模型輸出指定時間視窗內的故障概率 (例如，“我有 90% 的把握判斷在未來 50 小時內會發生故障”)。第二個特徵可以使用迴歸模型進行預測，該模型輸出剩餘使用壽命的值 (RUL)。這些變數是滯後的，這意味著直到故障事件發生之前都不能為它們分配標籤。
當出現故障時，可以計算這些滯後變數的值，並將其回溯更新到特徵表中。
如果失敗事件很罕見，但是工業物聯網資料非常多，那麼特徵滯後回溯標記可能會導致大規模的表更新。在下一節中，我將討論 Apache Spark 和 MapR-DB 這兩項技術如何協作來解決這個挑戰。
具有 MapR-DB 和 Spark 的可伸縮特徵工程
預見性維護的特徵表很容易就會超出一臺計算機上儲存和處理的能力。將這些資料分佈在一組機器上可以增加能力，但是如果您最終仍然需要將資料移回一臺機器上進行分析和模型訓練，可能就不希望這樣做了。為了避免資料移動和單點故障，儲存和計算都需要做成分散式的。Apache Spark 和 MapR-DB 為這個任務提供了一個方便的解決方案。
Mapr-DB 是一個分散式 NoSQL 資料庫，它提供了構建大型特徵表所需的伸縮性和模式靈活性。
Apache Spark 提供了分散式計算功能，從而可以突破單機記憶體容量的限制進行特徵表的分析。
如果使用 針對 Spark 的 MapR-DB 連結器 ，則不再需要將整個特徵表複製到 Spark 程序中了。而是由 MapR-DB 在本地執行篩選器，對從 Spark SQL 中提交的資料進行排序，只將結果資料返回給 Spark。
預見性維護特徵工程例項
我為一個工業暖通空調系統構建了一個概念上的預見性維護應用程式，它展示了幾個使用 MapR-DB 和 Spark 進行特徵工程的例子。你可以在 Github 專案 中找到這個演示的程式碼和文件。下面摘取了一部分，通過例項來解釋前面討論的特徵工程概念。
此應用程式的資料流水線由 MQTT 客戶端組成，該客戶機使用 Kafka API 將空調系統資料釋出到流中。當 Spark 程序使用這些記錄時，攝取流緩衝這些記錄，並用派生出的特徵將它們持久化到 MapR-DB 中的一個表中。流水線如下所示：
下面的 Scala 程式碼展示瞭如何使用 Spark 讀取流記錄：
上面的程式碼建立了一個含有原始 MQTT 記錄的資料集物件。這個資料集可以通過派生出的特徵加以豐富，如下所示：
(注意，欄位名稱以下劃線開頭的表示是派生的特徵。)
然後使用 OJAI API 將這個豐富過的資料集儲存到 MapR-DB 中，如下所示:
到目前為止，MapR-DB 中的特徵表包含了空調系統感測器的值和一些派生的特徵，如 _weekend，但是滯後的變數 AboutToFail 和 retain usefullife 的值仍然沒有賦值。
Spark 作業用於接收流上的故障通知和更新滯後的變數，看起來如下所示：
當這個 Spark 作業收到一個失敗通知時，會計算滯後變數的值，然後將這些值回溯更新到 MapR-DB 中的特徵表中。如圖 13，演示了應用程式中對此過程的輸出。
預見性維護演算法示例
在前幾節中，我講到了記錄與導致故障事件的條件相關資料的技術，以便可以通過機器學習訓練預見性維護模型。在這一節中，我將討論如何處理這些資料，以及如何實際訓練一個能夠預測故障的模型。
長短時記憶 (Long Short-Term Memory, LSTM) 演算法通常用於預測時間序列資料中的罕見事件。由於故障在預見性維護應用中非常罕見，所以它的建模很適合使用 LSTM 演算法。對於大多數流行的機器學習框架，都有現成的 LSTM 示例。我選擇 Keras 來實現上面討論的“即將失敗”指標的 LSTM 演算法。如果你想了解更多細節，請閱讀我在 GitHub 上釋出的 Jupyter 筆記本 。
我的 LSTM 實現了使用一張特徵表 (如上面所述) 來訓練一個模型，該模型預測一臺機器在 50 個週期內是否可能出現故障。結果不錯，如下所示：
這是一個很不錯的結果，因為它在故障實際出現之前就預測出來了，而且預測的準確率很高 (>90%)。在下面的例子中，模型做了一個沒有用的預測，因為它只是在故障出現之後才預測出來的：
使用不同的訓練資料集來更好地理解 LSTM 的靈敏性是件很有意思的事。在我的 Jupyter 筆記本中，解釋瞭如何合併資料集和訓練模型，所以你也可以按這種方式在你的筆記本上使用 LSTM 進行實驗。為了使資料準備和 LSTM 實現的步驟更容易理解，我刻意地只使用了該練習中的部分特徵。這些就留待你在 我釋出在 GitHub 上的筆記本 中查詢吧，在此就不加以贅述了。
總結
機器學習有可能比過去使用的傳統方法使預測維護策略更有效。然而，由於工業物聯網資料來源的高頻寬、現實生活中機械故障的稀缺性以及訓練模型需要高解析度資料，預測維護給資料工程帶來了重大挑戰。為了預見性地維護應用程式，任何敢於開發和部署機器學習的有效性還將取決於一個基礎資料平臺，隨著資料科學家迭代特徵工程概念和模型的發展，該平臺的獨立需求是，不僅能夠儲存資料，而且資料訪問還要暢通無阻。
關於作者
Ian Downard 是一位 MapR 的資料工程師和開發者傳道士。他喜歡學習和分享工具和流程相關的知識，使 DataOps 團隊能夠將機器學習應用到生產中。Ian 負責協調俄勒岡州波特蘭市的 Java 使用者組 ，並在 這裡 和 這裡 撰寫關於大資料的文章。
檢視英文原文：[Conquering the Challenges of Data Preparation for Predictive Maintenance](