大資料現在火到不行，究其原因是大資料的價值引得各大企業趨之若鶩。其實大資料之所以價值潛力無窮，其核心是資料探勘，挖掘找到人們所需要的有價值的東西。然而這個過程又是怎樣的呢？如何開始？如何通過資料探勘過程中找到我們需要的東西，這個過程又是什麼？
總結的過程也是乙個學習的過程，通過有章節的整理對目前正在的學習的內容做規整。在這個過程中我們會從具體的專案實施中去談資料探勘，中間會貫穿很多的概念，演算法，業務轉換，過程，建模等等。
我們列一下要談論的話題：
1、什麼是資料探勘及為什麼要進行資料探勘？
2、資料探勘在營銷和crm中的應用？
3、資料探勘的過程
4、你應理解的統計學
5、資料描述與**：剖析與**建模
6、經典的資料探勘技術
7、各類演算法
8、資料倉儲、olap、分析沙箱和資料探勘
9、具體的案例分析
什麼是資料探勘？
是知識發現、商業智慧型、**分析還是**建模。其實都可以歸為一類：資料探勘是一項探測大量資料以發現有意義的模式（pattern）和規則（rule）的業務流程。
這裡談到了發現模式與規則，其實就是一項業務流程，為業務服務。而我們要做就是讓業務做起來顯得更簡單，或直接幫助客戶如何提公升業務。在大量的資料中找到有意義的模式和規則。在大量資料面前，資料的獲得不再是乙個障礙，而是乙個優勢。在現在很多的技術在大資料集上比在小資料集上的表現得更好——你可以用資料產生智慧型，也可以用計算機來完成其最擅長的工作：提出問題並解決問題。模式和規則的定義：就是發現對業務有益的模式或規則。發現模式就意味著把保留活動的目標定位為最有可能流失的客戶。這就意味著優化客戶獲取資源，既考慮客戶數量上的短期效益，同時也考慮客戶價值的中期和長期收益。
而在上面的過程，最重要的一點就是：如何通過資料探勘技術來維護與客戶之間的關係，這就是客戶關係管理，crm。
專注於資料探勘在營銷和客戶關係管理方面的應用——例如，為交叉銷售和向上銷售改進推薦，**未來的使用者級別，建模客戶生存價值，根據使用者行為對客戶進行劃分，為訪問**的客戶選擇最佳登入頁面，確定適合列入營銷活動的候選者，以及**哪些客戶處於停止使用軟體包、服務或藥物**的風險中。
兩種關鍵技術：生存分析、統計演算法。在加上文字挖掘和主成分分析。
經營有方的小店自然地形成與客戶之間的學習關係。隨著時間的推移，他們對客戶的了解也會越來越多，從而可以利用這些知識為他們提供更好的服務。結果是：忠實的顧客和盈利的商店。
但是擁有數十萬或數百萬客戶的大公司，則不能奢望與每個客戶形成密切的私人關係。面臨這樣困境，他們必須要面對的是，學會充分利用所擁有的大量資訊——幾乎是每次與客戶互動產生的資料。這就是如何將客戶資料轉換成客戶知識的分析技術。
資料探勘是一項與業務流程互動的業務流程。資料探勘以資料作為開始，通過分析來啟動或激勵行為，這些行為反過來又將建立更多需要資料探勘的資料。
因此，對於那些充分利用資料來改善業務的公司來說，不應僅僅把資料探勘看作是細枝末節。相反，在業務策略上必須包含：1、資料收集。2、為長期利益分析資料。3、針對分析結果做出分析。
crm（客戶關係管理系統）。在各行各業中，**遠矚的公司的目標都是理解每個客戶，並通過利用這種理解，使得客戶與他們做生意更加容易。同樣要學習分析每個客戶的價值，清楚哪些客戶值得投資和努力來保留，哪些准許流失。把乙個產品為中心的企業轉變成以客戶為中心的企業的代價超過了資料探勘。假設資料探勘的結果是像乙個使用者推薦乙個小首飾而不是乙個小發明，但是如果經理的獎金取決於小發明的季度銷售量而不是小首飾的銷售量（即便後者更為有利可圖或者收穫長期盈利更多的客戶），那麼資料探勘的結果就會被忽視，這就導致挖掘結果不能產生決策。
我們要學會：從記錄的內容中學習。
為什麼是現在要學會：
資料正在產生，不斷的產生，不斷的更新
資料正在儲存在資料倉儲中——資料倉儲以乙個共同的格式匯集許多不同**的資料，具有一致格式的關鍵字和字段定義。業務系統旨在快速向終端提供結果，就對資料的格式和字段有額外的要求。資料倉儲的建立是為提供決策而設計，簡化資料探勘工作者的工作。
計算能力能夠承受
對客戶關係管理的興趣非常強烈
商業的資料發掘軟體已經形成
資料探勘人員的技能：
需要有數字技能
excel**使用能力，現在excel**處理能力相當強大。自從office 365出來之後，此勢不可小覷。
一種態度：不畏懼為了得到結果可能需要處理大資料量和複雜的過程。處理大型資料集、資料倉儲以及分析沙箱是資料探勘成功的關健。資料探勘不僅僅是產生技術結果，結果必須用來幫助人們（或者幫助越來越多自動化的流程）做出更明智的決定。產生技術結果只是第一步，通過結果了解真正的需求，把結果轉化為資訊，資訊轉化為行動，行動轉化為價值，才是真正的目的。
資料探勘的良性迴圈的重心在於業務的結果，而不只是利用先進的技術。
識別業務機會
挖掘資料將其轉換成可操作的資訊
根據資訊採取行動
度量結果
資料探勘成功的關鍵是把其結合到業務流程中，並能夠促進資料探勘人員和使用結果的業務使用者之間的通訊。首先，必須明確，找到合適的業務需求，很多的人員，沒有在意這一點，導致解決的是對業務沒有幫助的問題。
在面臨不斷日新的社會，進步，遠不在改變，而在與變中的不變。即使改變時絕對的，但是仍有未改進之處以及沒有可能改變的方向：如果經驗不會保留，永遠保持幼年，那些不吸取教訓的人，注定要重蹈覆轍。
當與業務人員討論資料探勘的機會時，確保重心在業務而不是技術和演算法。讓我們的技術專家專注技術，同時讓我們業務專家專注業務。
電信客戶流失：
乙個關鍵因素是過度呼叫，新的客戶在第乙個月使用的分鐘數超過了他們的費用的計畫，當第一月的的賬單往往在第二月中旬送達客戶，客戶才了解費用使用計畫。到那個時候，客戶已經在第二個月產生了乙個很大的賬單，導致客戶很不快樂。遺憾的是客戶服務人員也要等相同的時間等賬單週期到之後才能檢測到過度使用的狀況，致使沒有時間來主動反應。其實在這個過程中導致問題產生的原因就是，反饋時間的問題，如果在這個月末，分析報告能夠給出明確的**或建議，上面的問題就會有很大的改善。這中間可以能也會包括運營商之間的手段問題，這個暫時不考慮。
上述問題折中的解決辦法：新生的資料探勘組擁有資源，而且已經鑑別和調查了適當的資料來源。採用一些相當簡單的程式，該小組能夠在這些客戶中第一次過度呼叫時把他們標識出來。使用這個資訊，客戶中心能夠聯絡處於風險中的客戶，並在第乙個賬單失效之前把他們移到適當的賬單計畫中。
問題很簡單：在實驗室工作的很好的模型，為什麼走出實驗室就不能工作？乙個問題在於它通過記憶資料過擬合了模型集。這就導致在實驗室很成功的模型，拿到實際就令人很失望。建模的目標不是產生最好的模型。資料探勘的目標是能處理現實世界中的問題，從而可以影響某種變化。你需要的穩定，即該模型不僅在模型集中工作的很好，在未知的資料上工作的也得很好。
導致不穩定有四大原因：
1、把事情搞錯：由於不了解具體的需求，就動手。導致矛盾在實際過程中爆發。
4、未來的事情可能與過去的不一樣：模型是建立在歷史資料上的，但利用在其他時段。這裡隱含乙個假設——用過去發生的事情指導未來發生的事情。雖然不要求模型總是假設過去式未來的序幕。
時間幀：
模型集中的每個變數都有乙個與它相關的時間幀，它描述了該變數產生作用的時間段。可以理解為對在過去一段時間的資料的整合，超過這個時間的資料就作廢。
輸入變數和目標變數都有時間幀。輸入變數的時間幀嚴格早於目標變數，任何建立在此模型集上的模型都是一種**模型。另一方面：當輸入變數和目標來自同乙個時間幀內，它們產生剖析模型。
**模型：
很多資料探勘問題都可以概括為**問題：基於過去的響應，基於過去的相應，誰將會有相應？基於過去的登出記錄，誰有乙個不良風險？解決問題最好的辦法是限定輸入變數嚴格產生於目標變臉之前。
如：考慮到乙個零售商，它擁有乙個目標**，並計畫在9月份舉行乙個活動。我們的目的，收集9月1日之前的資料，並對這些資料建立乙個模型，以確定哪些客戶才加該活動，以及應採用哪些的營銷措施。應該使用什麼樣的資料建立模型？而且應該使用相同時間段的資料進行此模型評分。把日曆回翻一年，即前一年的9月1日，對那個使用者資料作為乙個起點，然後把結束日期放到去年年底的營銷資料上，這種就保證沒有「未來」資料的輸入資訊會影響模型的目標估計能力。
**面臨的挑戰是建立模型集所需的工作量。把日曆往回翻，這一做法寫起來很容易，但是在以客戶為中心、規範化的資料倉儲中很難實現。目的結果是為了獲取更穩定的結果，這些模型能發現導致客戶的一些重要行為的原因。
剖析模型：
剖析，從字面上的理解是，基於人口統計變數，例如：地理位置、性別和年齡等。剖析模型能發現同一條件下的關係，但他們不能指出原因和影響。出於這個原因，剖析模型經常使用客戶的人口統計資訊作為輸入，而把客戶行為作為目標，在這種情況下，確定原因和影響更直觀。
有指導資料探勘方法：
·把業務問題轉換為資料探勘問題 →選擇合適的資料 →認識資料 → 建立乙個模型集→修復問題資料→轉換資料以揭示資訊→構建模型 →評估模型→部署模型 → 評估結果 → 重新開始
最後祝福所有遇到瓶頸的大資料程式設計師們突破自己，祝福大家在往後的工作與面試中一切順利。
WinPcap核心資料
npf驅動核心指南 如何編譯winpcap packet.dll 資料報驅動api 這部分指南從最底層的模組開始，描述了winpcap的核心結構與介面。這部分內容的適合那些想要擴充套件或修改本軟體的人，或者是那些對winpcap的工作原理感興趣的人。因此，那些只希望在他們的軟體中，使用winpcap...
核心資料結構
關於開發驅動重要的核心資料結構，方便自己理解 driver object typedef struct driver object cshort type cshort size 乙個鍊錶，記錄了該驅動建立的所有裝置物件 pdevice object deiceobject ulong flags ...
核心資料結構
核心需要儲存i o元件使用的狀態資訊，可以通過若干核心資料結構比如說檔案開啟表等來完成 unix系統中在讀取乙個使用者檔案的時候，核心需要去檢查下快取，然後再去決定是否執行磁碟i o，在讀乙個程序映象時候，核心只需要從記憶體當中讀取資料，也就是說這些操作都可以呼叫read 函式來完成，但是語義不同 ...