1寫在前面， 大數據發展越來越火
2 結合業務需求拆解架構圖
這裏，我們把之前一章已經上過的架構圖再貼一次：
先簡單的從整體上說一下這個架構圖。
從架構圖中，我們可以看出來，我們整個數據架構中，需要做的事情很多。
隨着數據的流向，從下到上，主要分三層：
-
第一層是數據收集層，負責基礎數據的收集工作；
-
第二層是數據存儲以及處理層，負責數據存儲，以及對數據進行深度處理，數據的轉換，價值的挖掘等；
-
最上層是應用層，基於下面的數據處理，進行價值轉換；當然還有貫穿整個過程的監控以及任務調度相關的工作。
第一層中，主要有四個數據來源：用戶行爲埋點上報數據、服務日誌的數據、後端的業務數據、互聯網的公開數據。
第二層中，我們主要的核心框架是hadoop的核心生態，基於HDFS的存儲(本質上hive的存儲也是基於HDFS)，以及基於spark的部分實時處理的需求場景，主要是平臺級的架構。
當然，至於說具體的處理以及數據的加工、挖掘詳細數據業務，後續其他章節再詳述。
第三層中，我們直接面向的是業務方。
一方面是數據生態中最基礎最常見的的數據智能商業化分析，我們以EXCEL封裝成郵件日報週報的形式提供另一方面是平臺化的BI系統，以及高度自助性的數據自助查詢系統。
在深度挖掘方面，推薦是一個大方向，基於數據的當代搜索也是數據生態的重要組成部分，以及業務畫像、用戶畫像(絕對核心價值所在)等。
當然，除了以上這些，還有一些基於數據的推送服務啊、榜單數據啊、精準營銷系統啊，都是數據進一步有效應用，以及數據化價值的直接體現。
收回話題，在時間有限，人力有限，並且基礎是0的前提下，事情解決的順序就顯得尤爲重要了。
當前的業務需求。
想要使用數據，前提是有數據。所以，我們第一個需要解決的問題是數據源，但是核心的驅動價值因素是我們的業務需求。
我們第一個業務需求就是從數據上洞察產品的運營效果，電商的各種數據運營需求，指導內容數據化運營、電商數據化運營以及通過數據改進產品。
跟業務強相關的基礎數據是產品的業務數據庫，這個是現成的，只要打通數據流通即可。
與用戶行爲強相關的則是最直接的用戶行爲埋點上報數據，以及用戶使用服務，在應用服務中留下的訪問LOG。
基於服務日誌LOG解析數據，一方面如果需要從服務LOG中清洗出有用數據，前提是服務中已經有意識的進行相關信息的LOG落地，這一點，很遺憾，當時並沒有這個前瞻性。
其次，從服務LOG中清洗數據的代價略高，且信息量有限。
所以，在這個階段中，我們並沒有打算直接從服務LOG中清洗數據，因爲在服務LOG中埋入數據收集點位，也是一個巨大的改造工程，但效果並不一定好。
我們將最快限度的打通業務數據庫與數據中心的通道，然後以最快速度的對業務方提供可參考性的數據化日報。
打通行爲數據到數據應用的鏈路，結合用戶行爲數據，進一步優化數據化運營體系，以及爲產品優化迭代提供數據支撐。
構造最基礎的數據中心平臺，打通數據收集到數據分析應用的鏈路，爲業務方、決策層提供數據化運營決策方案，爲產品迭代提供最真實的數據反饋支撐。
歡迎交流問題，可加我個人企鵝 630892562，一起探討交流問題
或者加我的裙交流 ： 710219868， 邀請碼 南風 （必填）裏面有大神有系統學習路線及大數據快速入門寶典及最新資源文章分享，一起交流學習，共同進步。
這就是我們數據部門第一個戰略目標，什麼深度挖掘，什麼推薦系統，這些在這個時候統統都不要想太多啦，飯需要一口一口的吃！
我們之所以需要拆分階段目標，依然是投入與產出比的問題！
當我們有一個大目標時，我們需要把目標進行拆分，進一步拆分爲階段可實施、成果可見的階段性目標，在這裏同樣適用。
並且，記住，你的老闆是不懂技術的，他纔不會管你的平臺又建設到什麼什麼程度，集羣又搭建了多少臺，他只會問，這都一兩個月了，你們數據怎麼還沒有給公司帶來價值啊？！(哈哈，有點黑BOSS的感覺了)
不過這肯定是現實，不同位置上的人關注的核心重點不一樣。可能你需要關注整體的進度，而業務層只關心你的產出給他帶來什麼幫助。
是的，拆解大目標有利於我們快速入手啓動項目；成果階段化，更具有鼓勵性，成就感；最後就是階段性目標的實現情況更容易量化你的效率。
從人力的需求評估角度上說，也是有道理的，只有隨着你的體系一步一步完善，你才知道哪個環節真正的缺人，缺什麼人，這點很關鍵。
不過最本質的問題，還是投入與產出比。
我們在做人一件事情的時候，都需要注意投入與產出的比例，在一定的時間段內、投入一定的精力、產出一定比例的成果。
有這種價值觀，處理事務才更有效率！
3 如何做機器需求的評估
要打通數據收集到數據分析業務的輸出鏈路，那麼，你需要一個數據平臺進行支撐。甚至，後續你將持續開挖的數據核心價值，也是基於平臺上做的。
所以，我們需要一個數據平臺，而說到平臺，則機器資源是繞不過去的一個問題。
那麼，如何去評估你的集羣需要多少臺機器呢？每個機器又是以一個什麼樣的角色而存在呢？
在評估之前，你首先清楚的瞭解到，你平臺上需要承載的業務，包括內部的處理業務以及對外暴露的數據業務。
其次，你需要考慮後續一個可擴展性，即後續數據量上漲的情況下，機器的橫向擴展當然是沒有問題的，但是部分角色機器的資源需求是在縱向。
舉個簡單例子，Hadoop的datanode可以在橫向上進行擴展，但是namenode的資源需求則無法做到。
至於說如何進行機器資源評估，在瞭解自身業務需求的前提下，這裏所說的業務需求，不單純是業務範圍，也意味着業務範圍承載的數據量是什麼情況。
在瞭解自身數據量的情況下，多查找其他公司的案例，與其他同行多交流溝通，借鑑其他公司的數據量與集羣規模，來評估自身所需要的機器資源。
不過需要注意一點的是，對於電商行業，經常會出現節日性、活動性質的流量暴漲。
所以，你的機器資源一定是需要考慮這些實際場景負載的，或者對於這種場景，你有其他的方案進行處理也OK。
4 使用Nginx做數據上報僞服務
上面說到第二個重點，那就是用戶行爲數據的上報。
瞭解數據上報以及埋點相關邏輯的朋友應該清楚，其實所謂的SDK，其本質也是一個接受數據上報的服務。
直接往上報服務中丟數據，跟封裝成工具SDK，本質的意義是一樣的，我們需要提供一個對外的數據上報服務。
上報什麼數據，數據以什麼格式上報，這個在下一章的“數據上報體系”部分詳細闡述，這裏只是對上報服務這塊進行講解。
那這意味着，我們需要爲客戶端或者H5的童鞋提供一個統一的上報服務接口，讓他們在用戶特定行爲操作的時候。
比如瀏覽了某個頁面，操作了某個按鈕等之類的操作，進行這種信息的收集統一上報。
說白了，封裝用戶的行爲數據，在適當時候調我們的接口，把用戶的行爲數據給我傳過來。
那這看似就是一個後臺服務，用於處理上報過來的數據。
但是請注意，不管你是一個服務也好，僞服務也好，一般情況下絕不會直接把獲取到的數據直接落地的，這是傳統的思維路子。
要知道上報的業務流量是很大的，特別是你的點位足夠豐滿的情況下，在流量高峯期，你要是敢直接進行數據落地，它就敢直接把你的服務給搞死。
一般情況下，我們都會把數據丟給緩存，以解耦上報與落地兩端的壓力。
既然如此，在有限的人力資源下，在項目時間有限的前提下，爲何要花這麼大的精力去維護一個服務呢？於是，有了僞服務設想。
我們直接使用Nginx對外僞裝成一個Web服務，提供Restful API，但我們不對上報的內容做任何處理，直接落地成Nginx的日誌，再通過Flume對日誌進行監控，丟到Kafka中。
這樣我們就迅速的搭建起一個上報“服務”，提供給客戶端童鞋以及H5的童鞋，制定好數據上報的規範，然後就可以坐等數據過來了。
關於數據的合理性校驗、規範性校驗、有效性校驗、以及進一步的解析，我們都放到Spark Streaming這一層去做。
其實當時也是調研過lua的，在Nginx這一層也是可以做到數據完整性以及有效性校驗的，但是爲了不至於給Nginx端帶來過大的負荷，我們把複雜的邏輯處理放到後端。
基於這種僞服務的設計，還有一個好處就是，即使後端鏈路出現故障，但我的原始數據是落到LOG中的，了不起我進行數據的回溯，再通過LOG清洗出異常的部分就行了。
這也是我們後續實時數據容錯的核心依據所在，所以，重點推薦。
5 使用Spark Streaming做實時數據清洗
接上面的上報，我們在後端一層是使用Spark Streaming做數據校驗、進一步清洗的。
如果業務對於實時性要求不高，我們完全是不必要做數據的實時鏈路的，只需要週期性的把Nginx中的上報日誌進行批量清洗入庫即可。
但是，一方面基於部分對實時性稍高(其實也不高，分鐘級別)，例如電商活動期間對數據的實時監控；另一方面來說，實時性的數據上報鏈路是最終的目標，爲了業務的時效性，遲早是需要做的。
由於我們需要在後端的處理環節中，對數據的有效性、規範性做校驗，並且做進一步的屬性解析，例如通過IP解析地理位置之類的，所以承載的業務邏輯還是蠻複雜的。
所以，我們打算引入一個實時處理框架來做這件事。
關於實時框架這塊，我想，熟悉的朋友都會想到兩個：Storm與Spark Streaming。
簡單的說一下兩者的對比。
很久以前翻譯過一篇文章《翻譯：Storm與Spark Streaming的對比》，這裏只是簡單的說一說。
Storm與Spark Streaming最本質的區分在於，Storm是真正實時處理，而Spark Streaming的處理本質則是微批處理。
所以Storm能夠將實時業務達到毫秒級，而Spark Streaming雖然也能達到亞秒級，但對於效率的影響會比較大，所以一般會用於秒級的數據處理。
目前就我們自身的業務需求來說，對於實時性並沒有高到毫秒級的要求。
並且，爲了維護系統平臺的統一性(統一的平臺架構，統一的YARN資源管理，同一個垂直生態)，我們選擇使用Spark Streaming作爲我們數據清洗的入口。
使用Spark Streaming需要解決的一個問題就是，輸出結果的高度碎片化。
正如上面所說，Spark Streaming其核心依然是Spark的路子，在微小的時間窗內，對微小批量的數據進行處理，達到類似實時的效果。
而其每一個批量處理之後都是以批量結果得以輸出，於是，就會產生大量的碎片文件。
其實，解決這個問題也簡單，那就是合併！進行週期性的文件合併，這點就不多說了。
既然說到了Spark Streaming，也就順帶着說一說Spark這個生態。
在很早以前，Hadoop、MapReduce經常會被人提到，但是隨着Spark的興起，已經越來越少人願意使用MapReduce去批量處理數據了。
是的，Spark目前在Hadoop大生態中，已經形成一個比較完整的子生態:
-
包括與數據查詢分析關聯的Spark SQL；
-
實時處理領域的Spark Streaming；
-
正常內存處理可以替代MapReduce的離線批量；
-
還有集成大量機器學習包的MLlib；
-
以及還有什麼圖形處理的什麼鬼(好吧，那個不是我擅長的)。
在效率至上的數據時代，MapReduce說拋棄就被拋棄了(哈哈，其實也沒有這麼嚴重，只是越來越多人棄用MapReduce，這肯定是事實)。
在體系支撐上，Spark依然成氣候，數據的常規SQL分析，數據的內存處理、實時處理，以及數據的深度挖掘等，全部一起打包，好用的不得了，所以越來越得人心，也是木有辦法的事。
關於IP地理位置解析，這裏也可以分享一下。
IPIP.NET提供的IP庫實在是值得推薦的，沒錢的可以使用它提供的免費版，有錢的主可以考慮使用使用付費版。
其實免費版也沒有想象中那麼不堪，只是他提供的服務沒有這麼多，更新的頻次少點而已，大部分能解析到市一級，至於省份這一級，那是妥妥的沒問題的。
6 結語
這一章主要闡述如何從局部入手，拆解架構圖，進行階段性的任務執行，從這個角度講，上一章節的標題反倒是更適合這個了。
其中，詳細講解了部分核心重點，包括架構圖的拆解、機器資源的評估、Nginx的上報僞服務、以及基於Spark Streaming的數據清洗等。
但是，個人認爲，更重要的是期中闡述一些問題的思考方式、價值觀等。諸如拆解整體規劃的思考、擴展預留的思考、方案選擇的對比衡量等。
方法論遠比現成的方案有用！我一向的觀點是：授人以魚不如授人以漁。