第一篇:資料探勘概述

穆晨發表於2016-04-27

何為資料探勘?

        資料探勘就是指從資料中獲取知識

        好吧,這樣的定義方式比較抽象,但這也是業界認可度最高的一種解釋了。對於如何開發一個大資料環境下完整的資料探勘專案,業界至今仍沒有統一的規範。說白了,大家都聽說過大資料、資料探勘等概念,然而真正能做而且做好的公司並不是很多。

        筆者本人曾任職於A公司雲端計算事業群的資料引擎團隊,有幸參與過幾個比較大型的資料探勘專案,因此對於如何實施大資料場景下的資料探勘工程有一些小小的心得。但由於本系列博文主要是結合傳統資料探勘理論和筆者自身在A雲的一些實踐經歷,因此部分觀點會有較強主觀性,也歡迎大家來跟我探討。

資料探勘背後的哲學思想

        在過去很多年,首要原則模型(first-principle models)是科學工程領域最為經典的模型。

        比如你要想知道某輛車從啟動到速度穩定行駛的距離,那麼你會先統計從啟動到穩定耗費的時間、穩定後的速度、加速度等引數;然後運用牛頓第二定律(或者其他物理學公式)建立模型;最後根據該車多次實驗的結果列出方程組從而計算出模型的各個引數。通過該過程,你就相當於學習到了一個知識 --- 某輛車從啟動到速度穩定行駛的具體模型。此後往該模型輸入車的啟動引數便可自動計算出該車達到穩定速度前行駛的距離。

        然而,在資料探勘的思想中,知識的學習是不需要通過具體問題的專業知識建模。如果之前已經記錄下了100輛型號效能相似的車從啟動到速度穩定行駛的距離,那麼我就能夠對這100個資料求均值,從而得到結果。顯然,這一過程是是直接面向資料的,或者說我們是直接從資料開發模型的。

        這其實是模擬了人的原始學習過程 --- 比如你要預測一個人跑100米要多久時間,你肯定是根據之前瞭解的他(研究物件)這樣體型的人跑100米用的多少時間做一個估計,而不會使用牛頓定律來算。

資料探勘的起源

        由於資料探勘理論涉及到的面很廣,它實際上起源於多個學科。如建模部分主要起源於統計學和機器學習。統計學方法以模型為驅動,常常建立一個能夠產生資料的模型;而機器學習則以演算法為驅動,讓計算機通過執行演算法來發現知識。仔細想想,"學習"本身就有演算法的意思在裡面嘛。

        然而資料探勘除了建模外,還有不少其他要做的工作(本文後面會一一講到),因此涉及到不少其他知識,如下圖所示:

資料探勘的基本任務

        資料探勘的兩大基本目標是預測描述資料。其中前者的計算機建模及實現過程通常被稱為監督學習(supervised learning),後者的則通常被稱為無監督學習(supervised learning)。往更細分,資料探勘的目標可以劃分為以下這些:

        預測主要包括分類 - 將樣本劃分到幾個預定義類之一,迴歸 - 將樣本對映到一個真實值預測變數上;描述主要包括聚類 - 將樣本劃分為不同類(無預定義類),關聯規則發現 - 發現資料集中不同特徵的相關性。本系列其他文章將會分別對這些工作深入進行講解,如果讀者是第一次接觸這些概念請不要糾結。

資料探勘的基本流程

        從形式上來說,資料探勘的開發流程是迭代式的。開發人員通過如下幾個階段對資料進行迭代式處理:

        其中,

        1. 解讀需求

        絕大多數的資料探勘工程都是針對具體領域的,因此資料探勘工作人員不應該沉浸在自己的世界裡YY演算法模型,而應該多和具體領域的專家交流合作以正確的解讀出專案需求。這種合作應當貫穿整個專案生命週期。

        2. 蒐集資料

        在大型公司,資料蒐集大都是從其他業務系統資料庫提取。很多時候我們是對資料進行抽樣,在這種情況下必須理解資料的抽樣過程是如何影響取樣分佈,以確保評估模型環節中用於訓練(train)和檢驗(test)模型的資料來自同一個分佈。

        3. 預處理資料

        預處理資料可主要分為資料準備和資料歸約兩部分。其中前者包含了缺失值處理、異常值處理、歸一化、平整化、時間序列加權等;而後者主要包含維度歸約、值歸約、以及案例歸約。後面兩篇博文將分別講解資料準備和資料歸約。

        4. 評估模型

        確切來說,這一步就是在不同的模型之間做出選擇,找到最優模型。很多人認為這一步是資料探勘的全部,但顯然這是以偏概全的,甚至絕大多數情況下這一步耗費的時間和精力在整個流程裡是最少的。

        5. 解釋模型

        資料探勘模型在大多數情況下是用來輔助決策的,人們顯然不會根據"黑箱模型"來制定決策。如何針對具體環境對模型做出合理解釋也是一項非常重要的任務。

資料探勘的工程架構

        回到本文開頭提到的那個問題,“如何開發一個大資料環境下完整的資料探勘專案?”。這個問題每個公司有自己的答案,這裡僅以A公司的情況進行介紹。

        在A公司的資料引擎團隊中,主要人員分成A、B、C、D四個大組。這四個大組的分工非常明確,如下圖所示:

        圖中的這些個資料引擎架構在一個基於維度建模的雲資料倉儲之上,並對上層應用提供演算法支撐、推薦支撐、視覺化支撐等等。這裡也能看出A公司的資料探勘工程架構主要由三大塊組成:底層資料倉儲、中間資料引擎、高層視覺化/前端輸出。很多小夥伴問我,你是一名資料探勘工程師呀,可為什麼你前面的博文都是資料倉儲和資料視覺化呢?我想如果他們看到這裡想必不會有此疑問了:)。

        至於這些引擎的具體作用、開發方法,體系結構等則由於涉及公司祕密不能深入細說,請各位讀者見諒。

小結

        資料探勘涵蓋的面非常大,本文僅旨在讓讀者對資料探勘有一個感性的認識。關於什麼是資料探勘如果讀者還不清楚的話也不要糾結,跟著本系列一起學習一定能有所收穫並會最終發現:資料探勘是一門非常有趣的學問,比單純的寫程式碼要有意思多了。

相關文章