對大資料知識架構的梳理

標籤：項目內容   技術   知識   清理   統計   

     近期交接了前期的大資料項目，對之前的項目內容做一個總結。也算是梳理一下項目的架構，對前期也算是一個總結，為後期的學習打下一個基礎。

清理資料

     對傳統行業來說，上來就說要搞大資料，一般都會是一種噱頭，因為之前的資料量不會很大，所以基本上都是一些統計分析內容為主。在這一階段，你對資料理解就尤為重要！這裡邊牽扯到的知識有資料清理，相關的ETL技術。也就是說你要做資料分析，資料在哪裡很是重要，當你不清楚你的資料的位置的時候，你的分析也就無所談起。而未經處理資料裡邊一定會有許多的問題。而此時，你的清理過程就是要深入瞭解未經處理資料。為什麼說一個好的資料分析人員一定是一個好的業務人員，這點也尤為重要。因為只有你對資料更為瞭解的時候，你才能更好的補全，替代。說和通俗一點，就是你要將原始的資料轉換成PC能讀懂的資料。

    這裡也有一個4：3：3的原則，你原始的資料要從測試，訓練，驗證這三個維度來訓練你的資料，這樣構成一個迴圈，好讓你的資料最終的成功度提高。而當你的資料入庫的時候，就採用結構化還是非結構化的時候，這點也非常重要。也是決定著你後期讀取的快慢！

分析資料

　　這一步是要結合著業務來做的，你對業務理解多少。結合著業務需求來分析資料，而不是單純理解資料，不同行業不同工種對同一資料的理解是不同的。相比之下，業務人員要對資料的理解更加深入幾分。你如何分析你的資料，如何理解裡邊的特殊值。如何去找到你所要求的目標資料，這一點尤其重要。

　　分析資料，這一點也關係到你的項目的成敗。這一點個人感覺也是產品經理需要重要把握的地方。首先，做為產品經理，你不可能對所有行業都瞭解的很清楚，在這種情況下，就勢必要求你能夠最大限度的來理解資料的價值。在這一步，你要與業務人員深入交流，確保對資料的詳細瞭解，然後才能夠在接下的環節中脫穎而出。

演算法選取

　　有人說這一點都涉及研發了，作為產品經理是不需求去重點關注的。但從個人角度來說，這一點也同樣重要。因為你初期的演算法選取不當會造成後期的結果錯誤。也就相當於說，基本的東西，你一上來就要選好。

　　而在演算法選取方面，個人感覺也是要結合業務來實施。首先，要弄清楚業務那邊主要關注的是什麼指標。而與這一個指標相關的參數有那些，這些參數都是如何來影響這些指標的。至於演算法的準確度，這一點，可以通過對資料顆粒度的細化來不斷提高。不同的代碼對系統的資源調度是不同的，而若你對演算法的瞭解程度最大限度決定了你最終產品的反應快慢！

需求分析

　　有人說，這一塊是最為重要的。為什麼你不是放在第一部分來講，而是放在最後一部分了。因為深刻的感受到，在傳統行業，使用者的需求不明確，或者說不是那麼明確。又或者是使用者的需求是可以被引導的。一直以來，個人都將使用者的需求分為四種：強需，弱需，真需，假需。

　　有的時候，要分辯這些需求。是要求產品經理具有相關行業的背景的。因為不同行業，不同公司對人的需求是不同的。如何去挖掘使用者的需求，並將這些需求轉換成為可以落地實現的產品。這點對產品經理的要求是很高的。

部門溝通

　　巨量資料產品，我將它分為三個線，一個是產品，一個是業務，一個是研發。這樣就涉及到了部門之間的溝通。業務有許多的使用者需求要經過產品的人來向研發反饋，而研發也需要產品的人把自己的工作落實到實際的項目中來。

　　大資料，對上來說。領導層也許不懂大資料能夠做什麼。這就需要產品人員來給領導層以通俗的語言來講明白。而對合作廠家來說，要有正確的引導，才能夠讓對方看到合作的可能。從而為項目的發展提供動力。

　　大資料項目，以一個產品經理的角度來參於到這個項目中，才發現，自己曾經學到的內容到實際的應用中是那麼的微乎其微。傳統行業對大資料的渴求不再單單的基於概念而是真正的落地，真正的輔助業務創造價值。而這一方面，對一個產品經理的要求只會越來越高。

　　很高興前段時間論文的開題也順利通過了，大資料的路還有很遠，且行且珍惜吧！

對大資料知識架構的梳理