數據挖掘應用開發中的辯證法

數據挖掘應用的開發流程見下圖，因為數據挖掘應用整個開發流程是一個探索的過程，所以各個過程之間不是嚴格分開的。

1、問題與數據

數據挖掘應用，是數據驅動的應用，不同的用戶，因訴求不同，觀察同樣的數據，理解也不盡相同。在瀏覽數據時，建議不斷問自己：用戶是誰？分析的對象是誰？要解決什么問題？只有不斷的提醒自己，才能保證分析過程的始終有一條清晰的主軸，這是在分析傳統應用時非常不同的地方。傳統的應用，需要解決的問題是很清晰的，已具備的條件也是清楚的，缺少的就是設計和實現。

定義問題階段，具體的問題，可能對最終方案直接產生較大影響的時，解決這個問題，最終的硬件需要多少？譬如：通過信令數據分析手機用戶的常駐點行為。一個應用是給公安系統開放接口：輸入一個手機號，將指定用戶最近的常駐點顯示出來。另一個應用是給交通部門開放接口，根據用戶群體的行為，規劃道路設計。這兩類應用，從數據分析角度觀察都不大，都是常駐點分析，但從具體的應用觀察，系統架構設計完全就不是一回事了。

2、數據預處理與模型選擇和驗證

解決相同的問題，可以有多個模型，不同的模型，對數據格式有不同的要求。數據的預處理過程與模型緊密相關。同樣是解決聚類問題的算法，有的算法能夠直接處理大、中、小這樣的數據類型，有的算法需要大中小轉換成 0、1、2這樣的數字才能處理。

選擇一個模型時，最終的分析結果可能并不理想，這時不能輕易的否定掉這個模型，如果數據預處理不到位，好的模型也會產生不好的結果。反過來，選錯了模型，數據預處理模塊再怎么努力，效果也不會有本質的提高。對于系統設計人員，除了知道不同的分析模型對應解決的問題，還需要知道每個分析模型適用范圍和先決條件。

數據預處理過程還有一個誤區，原始的數據總是有殘缺的和異常值等現象存在。但從另一個角度思考，水至清則無魚，異常數據不等于無價值數據。異常數據對數據分析結果肯定有影響，但如果把異常數據都穿上漂亮的衣服，那么有可能就會將數據的本來面目同樣隱藏起來了。對異常數據的處理態度，還是與具體的應用有關，如果是分析人員的常駐地點，異常值價值就不大，如果是分析信用卡詐騙的應用，異常值就是價值特別高的數據。

數據預處理，從某種意義說就是一門藝術，是整個數據挖掘過程中最耗時的一個過程。

選擇了一個模型，效果好不好，還需要對模型的效果進行驗證。模型需要快速的反饋結果。驗證模型的過程，是一個反復的過程，期間需要對不同的參數進調整。如果不能快速輸出結果，例如每調整一個參數，都需要一天才能看到最終的運行結果，在系統設計過程中，這樣的速度是不能接受的。為了能夠快速的驗證模型，需要對數據進行抽樣。抽樣過程可以分為廣度優先和深度優先兩種方式，譬如：通過上網記錄分析用戶的行為習慣，在選擇和驗證模型時，不可能對全量數據進行分析。這時，可以選取部分人群進行深層次的分析：選擇100個人，分析3年的上網記錄。也可以選取全量人員，分析最近一個星期的上網記錄。具體采取何種方式，還是與具體的應用相關。

驗證模型時，除了從技術方面考慮，還要從考慮成本的可行性。成本可分為直接成本和替代成本。直接成本，就是按照現在的模型投入到生產環境中，最樂觀的情況下，需要多少硬件成本和后期維護成本。影響直接成本的因素很多，在相同的模型下，分析精度是影響直接成本的一個重要因素。除了直接成本，還要考慮替代成本。什么是替代成本？舉個例子，有個數據分析應用是：分析電信用戶賬單，找出高價值用戶。開發成本100W，硬件成本200W，后期維護需要兩個工程師，每年成本50W。對應這樣的系統，達到的分析效果，很可能雇傭兩個普通職員，采用普通SQL語句和EXCEL表格統計，就能把相同的事情做了。此種場景，替代成本是很低的，系統是沒有競爭力。

3、部署模型

選定了模型，下面就是部署模型了。部署模型不是簡單的將驗證過的模型放在生產環境下運行。部署模型，是一個完整的開發流程。驗證模型時，為了提高反饋速度，可以不考慮系統的完整性、架構、開發語言、可服務性等等因素。簡單說，怎么快就怎么來。不同應用，部署模型的過程不一樣。

例一：文本分類器。在驗證模型階段，使用不同的算法對大量的語料進行分析，輸出一個模型，然后使用另外一些語料對這個模型進行驗證，如果可行，將這個模型部署到生產環境中。此例中，被部署的模型可以使用模型驗證階段相同的技術得到。但是使用這個模型，驗證和生產的實現可能完全不一樣。在驗證階段，慢慢對文本進行分類問題不大，但在生產環境中，有大量待分類的文本需要處理，效率、并發、接口方式都需要綜合考慮了。

例二：通過分析信令信息得到用戶的常駐地。此應用，驗證模型中的直接產出（如代碼）在生產環境中就很難復用。模型驗證時，可能使用Python語言編寫的公開代碼庫，在實現時為了效率，可能采用JAVA在Hadoop架構上實現。

部署模型階段，簡單理解就是常規系統的開發過程。