崑崙數據田春華老師在微信公衆號的專欄培訓：工業數據分析與實戰。培訓給出了一些實際的數據分析例子，包括“設備管理”、“運作優化”和“營銷服務”三類；然後講了數據分析的基本框架、方法和技術；最後給出了大數據時代，數據分析的認識誤區和挑戰。田老師發音不標準啊，好多詞聽好幾遍，再關聯上下文，連猜帶蒙的才勉強能明白，不過有的也不一定對。記錄以反覆學習。
視頻鏈接
————————————————
接上篇：工業數據分析技術與實戰之入門
介紹第一個案例。在設備運維裏面經常有預測性維護或預防性維修。這個案例是講的城市官網的預防性維修。在預防性維修場景中，就是我們在做季度計劃時，高風險的網段有哪些。如果有針對性的維修的話，可以提高維修的效率。這裏涉及到的數據，首先是管網本身的拓撲結構，它的管材、管徑、管齡，包括一些周邊信息，周邊土地使用狀況，包括天氣信息、車流量信息等，包括內部的水壓，水質信息比如PH值等。考慮這些信息，就是希望能通過儘可能多的數據得出一個比較好的風險等級。過去的手段使用風險矩陣，講的直白一點就是打分，管齡佔多少總分的零點幾，管徑佔多少比例，用專家打分的方式，把風險矩陣做出來。這個用了兩年之後呢，發現這風險矩陣不好使，發現這個維修準確率和盲猜差不多。是不是各種因素的綜合沒有考慮到，所以準確率比較低。後來發現這個矩陣爲什麼不好使了，是因爲把全部管子替換掉以後呢，肯定在新的管子上其確定性不高了。那就想說用數據分析的方法，把這些因素之間的相關性、關聯關係，包括非線性關係，都考慮到。一個很簡單的例子，比如交通流量，對地下管網的失效到底影響是大還是小，是正向還是反向。從專家的角度，這個其實很難講。一方面，車流量大，外部壓力大，失效風險就高，但是從另一方面講，交通流量大的地方，我們開挖性施工的概率就小，不可能在高速路旁天天挖溝，那不均勻沉降的概率就比較小。所以這個因素的影響，一個是正向的一個是反向的。如果讓人去打分，這個交通流量到底是正向還是反向，就很難給出。而我們通過機器學習的簡單統計就可以發現，這兩個作用很有意思，交通流量高的地方，失效率特別低，交通流量低的地方，失效率也特別低，就是那些交通流量既不高也不低的中間的地方，路邊的地方，失效風險反而高。這是兩個風險因素相互作用的結果。這樣的結果，在傳統的專家打分或風險矩陣上很難表達出來。所以我們綜合考慮這麼多因素，最後用數據挖掘的結果，準確率提高不到12倍，比人好一些。這裏面最大的挑戰就是事故率太低。大家知道，在正常的工況，在正常的影響下，失效率不可能特別高，這種情況在技術上叫不均衡的數據集，失效率不到1%，100根管子一年壞不了1根。這種情況下怎麼做，數據算法在技術上提供了一些方法，比如說生存分析，怎麼來保證樣本均衡性，做了一些工作。從這裏面我們發現另外一個問題，大家都說的數據質量的問題，我們做的這個客戶在國際上算是比較領先的，對於大多數企業來說他的信息化水平至少領先10年到15年左右，他們從九幾年開始就做GIS地理信息系統，做MRO（Maintenance維護、Repair維修、Operation運行 ）這些系統，所以他們自認爲他們的工單管理，以及所有細節管理非常完備，數據質量問題不用擔心，但是當我們真正的深入進去，把管段數據、交通流量數據等各種數據都考慮進去，就會發現缺失特別嚴重。這是大數據分析遇到的普遍問題。也就是當看一個特徵的數據，它的質量還可以，缺失率只有10%到20%，但是當我們把所有的因素都綜合考慮進去，那5個數據源或6個數據源數據合併後，嚴格意義上的數據完整率不到30%。這也是讓客戶非常喫驚，說我們做了這麼多年，數據質量還是這麼差。這其實在大數據分析中是個常態。以爲大數據分析是多數據源的融合，每個數據源是80%，那多個80%乘起來以後，其完整率就非常低了。這就是我們在實際分析中遇到的情況，數據整合的問題，在傳統操作數據庫中不明顯，但在數據分析裏面會凸顯些問題。而且好多數據質量問題不只是數值上的，或者說類型上面的，通常都是業務語義上的一些缺失。這些就需要我們數據分析時反覆注意，比如我們在分析的過程中，發現有一段管道的預測特別差特別差，我們的預測水平還不如亂猜，基本上和實際結果是相反的。後來我們專門拿這一塊兒去請教業務專家，專家看了一眼說，這塊兒在提供數據的時候沒有告訴我們，這塊是圍海造田區，它的不均勻沉降非常嚴重，它的風險，它的管道失效模式與別的地方完全不一樣。這種只要把圍海造田區域數據提供，就立馬能看出來。這種情況，不是說客戶可以忘記，我們也不可能知道這種圍海造田區的情況，而且即使這個城市有，或這次知道了，下次也可能有新的狀況，也不知道還會有多少其它這種情況存在，我們不可能窮舉出所有的情況。這就要求我們在做數據分析的時候，要多去跟業務專家進行迭代，拿我們最差最不好的結果跟業務部門去碰，這樣就發現，很多時候，是由於其它原因，這個原因不在我們當前數據集中間，這也是給我們數據分析一個提醒：我們拿到的數據不一定是全的數據，很多因素可能不在我們的數據集裏面，我們要反覆確定這個數據的事情。
下面介紹第二個案例。第一個案例還是偏計劃性，預測性維修的例子，第二個例子我們來介紹一下石油管道里面管道泄露檢測。這個檢測的重要性大家應該都能理解。比如當石油管道泄露的時候，油會先往下滲，地面發現的時候一般都比較晚了。另外油氣管道還有爆炸風險。所以問題就是當有泄露後能不能及時檢測到。泄露檢測的方法有很多種，有使用壓力傳感器的，還有用光纖的。本例中使用的壓力傳感器來檢測，原理也很簡單。就是當有泄露的時候，壓力就會下降，形成負壓渦。負壓渦在油裏面以每秒1.2公里的速度傳播，兩邊傳感器感知到壓力下降之後呢，如果泄漏點不在中間的話，它會有一個時間差，再根據管道長度，就變成小學五年級的數學題，求兩個相對行走的人相遇時的位置。這個問題看起來特別簡單，簡單到都不值得使用數據分析來做。但是當我們拿到數據以後，就發現真的難的地方在幾個方面。一是壓力數據，我們以爲的壓力數據是光滑的數據，但現實中我們拿到的數據是帶有強噪聲的數據。因爲它是進行油氣輸送，有油有氣，油氣混合，它本身的壓力波動非常大，另外壓力傳感器也存在壓力噪聲。所以在這種強噪聲情況下怎麼做壓力下降的定位，本身就很難。這就需要我們考慮去做濾波，如果濾狠了，那精度就受影響，如果濾輕了，就會有很多虛假預警。其實定位信號這個問題還不是很難，雖然我們的算法還是要精心調整。更難的一個是虛假預警，虛假預警包括什麼呢，比如泄露會造成壓力下降，其它一些正常情況也會造成壓力下降。比如我換油品了，從煤油換成柴油了，換成航空用油了。不同油品，本身傳送壓力就相差很多，這時候輸油泵就會調壓，輸油泵造成的壓力下降，比泄露造成的壓力下降要大得多；還有其它情況，比如中間有很多閥門開關，要倒灌，比如一個罐滿了，要倒到另一個空油罐的時候，都會造成壓力下降。還有假如油中間有空氣，當這個氣泡破裂時也會造成壓力下降。有這麼多正常因素造成壓力下降，我們需要識別哪些是泄露，哪些不是泄露。這個問題非常重要，否則我們的報警系統會天天報警。那這個系統就不可用。因爲報警後檢測人員要帶着儀器到報警位置開挖檢測定位，系統反而給檢查人員造成很多困擾。這種情況在工程中間經常遇到，檢測到一個異常不難，但是要判斷這個異常的來源是故障造成的還是其它正常因素造成的，是我們面臨的很大的問題。更難的一點是我們這裏只有壓力信號，那我們該怎麼做呢？好的一點是，一個泄露會有多個壓力傳感器測到，60公里內的，壓力下降信號沒有衰減到一定程度時，我們的傳感器都能檢測到，可以進行多點匹配。可以用時域，查看形狀，比較好的一點就是泄露造成的壓力下降有一個比較好的形狀，到底部會有有規律的波動，會有毛刺。而調泵調壓，在中間會有毛刺，但是到底部會很光滑。通過這些模式匹配，我們也可以把它們區別開來。有這些以後，我們就把系統的預警從每天的幾十起，降到一兩天一起，但是這樣沒有到我們理想的結果。我們還是想進一步優化。但是這時候我們發現，我們的數據都用盡了，特徵都用盡了。再想進一步解決呢，我們跟客戶商量，一方面是引入不同傳感器，用光纖測量溫度、震動，看聲波，看各種方面，用多傳感器融合去預警。這樣基本上干擾這個的不惑干擾那個，這樣是從根本上解決辦法。從這個例子我們看出，我們的干擾源其實是非常多的。對於數據分析最難的東西，就是怎麼區別開，怎麼降低虛假預警。
第三個案例，是關於抽油機的。抽油機就是油田裏的磕頭機。它的工作原理非常簡單，就是4個衝程，它中間有一個標準的傳感器，叫示功儀。示功儀是測量位移與力矩的關係。橫軸是位移，縱軸是力矩。理想情況下是一個平行四邊形。一個週期大概採120個點，這裏面有一個顯著的問題，就是原來的抽油機都沒有聯網，現在中石油以及一些國內的油田實現加入互聯網之後，這些數據能夠實時的跑到監控中心來。這樣一個自然的問題就是，能不能通過這些數據自動判別抽油機的故障。抽油機的原理非常簡單，正常情況下抽油機的示功圖是平行四邊形，當出現故障時這個圖形就會發生變化，有的變成刀把型，有的變成圓形。需要根據這個形狀反過來研判到底出了什麼故障。這個從算法角度也挺簡單的，我們把一個實際的圖，做平滑，向多邊形逼近，再根據圖形的特徵，包括角度，邊長，很容易的做到匹配成功率92%左右。但是，這並沒有解決客戶的問題。採油廠做這個課題的原因是，想要降低工作量。原來的工作是天天看着屏幕上的圖形，來判斷有沒有故障。那我們做了一個92%的模型，還講不清楚那8%是錯的。但是這減少不了客戶的工作量，模型對一個圖的判斷，92%是有故障，8%是沒有故障，那所有的圖還是得全部看一遍才能確定究竟是不是有故障。客戶想要的是，要麼能完全準確的判斷有或沒有故障，要麼就打個標籤說判斷不了。那麼完全準確判斷的客戶就不用再看了。對於模型無法判斷的，再由業務專家人工干預。這樣就能夠減少工作量了。客戶要的是一個完全對的東西。後來我們就把這個92%的模型做明示化的規則提取，做成決策樹，跟業務專家反覆討論，制定一個非常保守的，但是100%對的模型。這個模型只能判斷30%——40%的圖形，但是判斷的結果是完全正確的。這樣客戶的工作量就降低了。另外40%的樣本，可以打一個85%正確率的標籤，給一個建議，客戶也覺得有意義，雖然幫助不大。剩下10%——20%的疑難雜症就交給業務專家來解決。從這個例子我們看到，數據分析只是一個技術，我們要把這個技術應用到實際的業務流程裏面，纔會發揮作用。其實有的時候客戶看起來對數據分析要求苛刻，其實也是合理的，不能說你模型精度99%，但是那1%哪裏錯了不知道，那這個東西是沒法用的。