文·blogchong
接上一篇《從0到1構建數據生態系列之二：拓荒》，這篇我們來好好拆解一下我們的藍圖。
1 寫在之前
之前有朋友在后臺留言說，從第二篇中(即上一篇：拓荒)，可以看出文章略顯匆忙，并沒有把拓荒的一些過程細節給描繪出來。
這里檢討一下，我坦白、我認罪。
當時那個話題一寫開來的時候，突然就發現這是一個巨大的話題，隨便發散下去又一大篇了，所以我還是在這一張穿插著把上一張的部分內容補充完整。
當然，至今為止，我已經把未來三章的內容規劃出來了，這樣更容易把控這個系列的質量。
所以，請期待，請不要放棄治療。
回歸話題，這一部分我將結合架構圖中的東西，講述我們是如何拆解完整的數據規劃到執行的過程，并且期間一些思考方式也會一起分享出來(感覺這更是重點)。
2 ?結合業務需求拆解架構圖
這里，我們把之前一章已經上過的架構圖再貼一次：
先簡單的從整體上說一下這個架構圖。
從架構圖中，我們可以看出來，我們整個數據架構中，需要做的事情很多。
隨著數據的流向，從下到上，主要分三層：
(1) 第一層是數據收集層，負責基礎數據的收集工作；
(2) 第二層是數據存儲以及處理層，負責數據存儲，以及對數據進行深度處理，數據的轉換，價值的挖掘等；
(3) 最上層是應用層，基于下面的數據處理，進行價值轉換；當然還有貫穿整個過程的監控以及任務調度相關的工作。
第一層中，主要有四個數據來源：用戶行為埋點上報數據、服務日志的數據、后端的業務數據、互聯網的公開數據。
第二層中，我們主要的核心框架是hadoop的核心生態，基于HDFS的存儲(本質上hive的存儲也是基于HDFS)，以及基于spark的部分實時處理的需求場景，主要是平臺級的架構。
當然，至于說具體的處理以及數據的加工、挖掘詳細數據業務，后續其他章節再詳述。
第三層中，我們直接面向的是業務方。
一方面是數據生態中最基礎最常見的的數據智能商業化分析，我們以EXCEL封裝成郵件日報周報的形式提供另一方面是平臺化的BI系統，以及高度自助性的數據自助查詢系統。
在深度挖掘方面，推薦是一個大方向，基于數據的當代搜索也是數據生態的重要組成部分，以及業務畫像、用戶畫像(絕對核心價值所在)等。
當然，除了以上這些，還有一些基于數據的推送服務啊、榜單數據啊、精準營銷系統啊，都是數據進一步有效應用，以及數據化價值的直接體現。
收回話題，在時間有限，人力有限，并且基礎是0的前提下，事情解決的順序就顯得尤為重要了。
當前的業務需求。
想要使用數據，前提是有數據。所以，我們第一個需要解決的問題是數據源，但是核心的驅動價值因素是我們的業務需求。
我們第一個業務需求就是從數據上洞察產品的運營效果，電商的各種數據運營需求，指導內容數據化運營、電商數據化運營以及通過數據改進產品。
跟業務強相關的基礎數據是產品的業務數據庫，這個是現成的，只要打通數據流通即可。
與用戶行為強相關的則是最直接的用戶行為埋點上報數據，以及用戶使用服務，在應用服務中留下的訪問LOG。
基于服務日志LOG解析數據，一方面如果需要從服務LOG中清洗出有用數據，前提是服務中已經有意識的進行相關信息的LOG落地，這一點，很遺憾，當時并沒有這個前瞻性。
其次，從服務LOG中清洗數據的代價略高，且信息量有限。
所以，在這個階段中，我們并沒有打算直接從服務LOG中清洗數據，因為在服務LOG中埋入數據收集點位，也是一個巨大的改造工程，但效果并不一定好。
我們將最快限度的打通業務數據庫與數據中心的通道，然后以最快速度的對業務方提供可參考性的數據化日報。
打通行為數據到數據應用的鏈路，結合用戶行為數據，進一步優化數據化運營體系，以及為產品優化迭代提供數據支撐。
構造最基礎的數據中心平臺，打通數據收集到數據分析應用的鏈路，為業務方、決策層提供數據化運營決策方案，為產品迭代提供最真實的數據反饋支撐。
這就是我們數據部門第一個戰略目標，什么深度挖掘，什么推薦系統，這些在這個時候統統都不要想太多啦，飯需要一口一口的吃！
我們之所以需要拆分階段目標，依然是投入與產出比的問題！
當我們有一個大目標時，我們需要把目標進行拆分，進一步拆分為階段可實施、成果可見的階段性目標，在這里同樣適用。
并且，記住，你的老板是不懂技術的，他才不會管你的平臺又建設到什么什么程度，集群又搭建了多少臺，他只會問，這都一兩個月了，你們數據怎么還沒有給公司帶來價值啊？！(哈哈，有點黑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大生態中，已經形成一個比較完整的子生態:
(1) 包括與數據查詢分析關聯的Spark SQL；
(2) 實時處理領域的Spark Streaming；
(3) 正常內存處理可以替代MapReduce的離線批量；
(4) 還有集成大量機器學習包的MLlib；
(5) 以及還有什么圖形處理的什么鬼(好吧，那個不是我擅長的)。
在效率至上的數據時代，MapReduce說拋棄就被拋棄了(哈哈，其實也沒有這么嚴重，只是越來越多人棄用MapReduce，這肯定是事實)。
在體系支撐上，Spark依然成氣候，數據的常規SQL分析，數據的內存處理、實時處理，以及數據的深度挖掘等，全部一起打包，好用的不得了，所以越來越得人心，也是木有辦法的事。
關于IP地理位置解析，這里也可以分享一下。
IPIP.NET提供的IP庫實在是值得推薦的，沒錢的可以使用它提供的免費版，有錢的主可以考慮使用使用付費版。
其實免費版也沒有想象中那么不堪，只是他提供的服務沒有這么多，更新的頻次少點而已，大部分能解析到市一級，至于省份這一級，那是妥妥的沒問題的。
6 結語
這一章主要闡述如何從局部入手，拆解架構圖，進行階段性的任務執行，從這個角度講，上一章節的標題反倒是更適合這個了。
其中，詳細講解了部分核心重點，包括架構圖的拆解、機器資源的評估、Nginx的上報偽服務、以及基于Spark Streaming的數據清洗等。
但是，個人認為，更重要的是期中闡述一些問題的思考方式、價值觀等。諸如拆解整體規劃的思考、擴展預留的思考、方案選擇的對比衡量等。
方法論遠比現成的方案有用！我一向的觀點是：授人以魚不如授人以漁。
OK，到這里，本章節打完收工。
下一章節將很有意思，內容就不過多暴露了，標題已定《從0到1構建數據生態之二：與研發團隊的愛恨情仇》。
7 致謝
PS：在數據生態構建的初期，也咨詢過很多業內的同行朋友，他們也給了很多真心的建議，所以，這里給這些大神們致謝，雖然他們不一定能看的見！
哈哈，所謂的排名不分先后，都一律謝過：
@樂視云的祝威廉大神
@樂視云的一斐大神
@極客學院的馬健大神
@百度的二鐵兄
@前百度現GrowingIO的何健大神
@其他Storm-Hadoop-大數據群里，給過意見或建議的盆友
從0到1構建數據生態系列：
《從0到1構建數據生態系列之四：與研發團隊的愛恨情仇》
《持續未完~~》
