最近在做一個數據圖表化實時展示的系統，從構思到基本完成，雖遇到了無數的坑，但通過該項目的研發，讓我對數據分析與建模有了更進一步的認識，更重要的是讓我對之前自己的構思像接口聚合，殭屍應用的數據重組，核心價值信息的獲取，數據模型分類的實現有了完整的實現方案。
爲什麼要進行數據分析
正規的項目開發，一般我們會先有需求，然後根絕用戶需求進行需求評估，接着編寫需求文檔，最後根據已經規範化的需求文檔，抽象分析，創建合適的關係型數據庫表格（ER圖原理）。也就是說常規的項目，數據都是在我們進行開發之前規範設計好的，後續的前後臺都是按照已經規範好的數據模型進行數據通信。而數據分析則不然，之所以要分析，是因爲數據源種類繁多，數據內容雜亂無章，這些數據之間可能有潛在的聯繫，但這種聯繫需要我們對已有的數據進行統計，分類，發掘，鑽研，然後提取有價值的信息進行建模，最後根據具體的場景實現應用。所以數據分析區別於“需求建模”，前者是愚公移山，大海撈針的行爲，我們是在大量的數據中找尋有價值有關聯的信息，我們不是數據源，而是數據加工廠。而後者則不同，我們在直接設計數據誕生時的樣子。所以理解數據分析首先要明白我們扮演的角色，以及爲什麼要進行分析。
如何提取有價值信息
前不久看過一篇文章說的是Docker這類容器化技術正在破壞像Hadoop這種老牌的大數據生態，個人感覺有點危言聳聽，編程界沒有取代關係，有的只是合適不合適，任何一門技術即便他是老掉牙的東西無論在任何時代也都有他存在的價值，鄙視鏈這種邏輯不應該出現在技術圈。好了迴歸主題，既然要進行數據分析，那麼我們該如何從數據中找尋有價值的信息呢，沒錯Hadoop，有些不懂技術的人將Hadoop神化，其實在我來看他就是一個工具，瞭解其歷史的大概就知道Hadoop的誕生離不開Google開源的GFS以及MapReduce，有人會說我們找尋有價值的數據爲什麼要用這個玩意呢，用我前面的話來說就是應用場景，數據分析往往面對的是海量的數據，而對這些數據的分析整合必須要有一個穩定的，安全的容器，面對這種情況Hadoop的HDFS（分佈式文件系統類似硬件的虛擬化）便是“不二人選”。而構建廉價的用來處理大數據的服務器引擎的最佳方案便是服務器的集羣化，應用的分佈式部署，這樣針對分佈式運算的MapReduce便有了用武之地，MapReduce中的Map函數會根據輸入生成若干組鍵值對，Reduce函數則以Map生成的鍵值對列表爲輸入，根據列表的鍵更改其對應的值，達到去重並減少數據總量的效果，在此基礎之上配合Hadoop提供的接口和抽象類以及Java固有的邏輯運算接口，我們可以對數據進行更快速，更有效的分析處理。
數據分類與建模
數據的分類與建模我更想用面向對象的思想來解釋，其實在業務分析項目構建的過程中針對不同的應用場景，我們早就具備了數據分類與建模的能力。舉個簡單的例子，比如在開發Web項目的過程中，我們通常會寫若干沒有業務邏輯的實體類，實體類通常會分爲POJO,DTO,VO等等，其實項目實體類的構建過程就是數據分類建模的過程，二者的思想基本差不多。數據的分類建模一般是建立在對現有的數據有了充分認識之後才進行的，分類與建模往往是同步進行，互爲關聯，完成這一步往往需要對實際的應用開發有一定預期，我們可以根據實際的業務邏輯進行數據分類建模，也可以根據數據呈現方式進行有效數據的規範整理。分類建模的最終目的是整合有效數據，過濾無用信息，讓數據根據業務場景實現有效組合，進而體現數據本身的價值。
發掘數據模型的聯繫
在我開發當前的數據實時展示系統的過程中，面臨一個問題，就是如何實現數據的有效整合，領導給我的是若干個存儲過程（數據庫層的接口），而我需要的是找到這些數據的共性，並把不同的數據關聯起來，比如我通過在線離心機的數量可以找出其實時產量，通過實時產量的進展情況可以提前對庫房入庫情況進行推演。發現數據模型之間聯繫的能力需要擁有一定水平的邏輯抽象能力，舉個簡單例子，現在流行的推薦算法，我們從用戶的購買行爲中根據特定商品信息進行數據發掘，可以找到針對特定用戶的虛擬數據模型，例如百度的百度大腦，通過對用戶搜索行爲產生的數據進行統計分析，量化之後可以對不同年齡層，不同地區進行統計定位，生成針對不同地域，不同人羣產品推廣的有價值信息。模型的建立很重要，但只有真正找到數據模型之間的聯繫，找到打通模型數據與實際應用場景之間的鑰匙，纔算有意義的數據分析。相信不久的將來，在5G步入正軌，萬物互聯時代到來之後，我們定能對數據如金這句話有深刻的認識。