文·blogchong
接這個系列的上一篇《從0到1構建數據生態系列之四：與研發的愛恨情仇》。
好像間隔的時間有點長了，中間插了好幾篇其他主題的文章，我們再回歸到這個系列。
從早期的數據遷移、數據上報體系的建立，再到數據多維分析BI體系的建立，再到后續的各種不同數據應用服務，諸如各種推薦服務、搜索服務、各種榜單數據的推送服務，整個數據生態已經逐漸豐滿了。
隨著內部數據業務的逐漸增多，我們對于這些業務服務的把控能力就越低，那么這個時候提升效率將是我們重點關注的問題。
例如：
數據分析BI業務從之前的簡單幾個統計報表，逐漸增加，越來越復雜，依賴的基礎計算數據也越來越多，報表生成出錯難以追蹤來源，無法很好的建立不同層級的中間數據依賴關系。
數據上報是否正常，有沒有異常波動的上報點位，是屬于正常情況還是上報異常，比如重放攻擊，機器點擊。
上一篇提到的，如何提升埋點測試的效率以及準確性，進一步釋放人力，減少這種重復性、建設性較低的勞動量。
業務部門大量的數據分析需求，數據提取需求，如何進一步降低這種重復性，建設性比較低BI分析工作，釋放BI人員的人力。
各種五花八門的數據服務，如何能有效的監控起來，隨時感知服務的故障，并且及時投入人力進行處理。
任務調度系統
在數據上報體系搭建的同時，我們同步開始進行各個業務團隊的BI體系的搭建。
我們需要為運營、內容、電商、市場以及產品等各個業務團隊提供天、月以及季度等維度的BI報表，以便各個業務團隊進行數據化運營、決策。
單純每天的BI報表多達數十個，每個報表內可能又包含N個維度的數據。
這些BI報表的基礎數據來源為：上報體系提供的上報數據，業務方產生的業務數據，各種服務產生的服務數據。
先不說一些實時性的數據分析業務，單論上述的周期性的BI報表業務，我們來看一下整個業務體系的復雜程度：
數十個近百的業務表需要將數據進行周期通過sqoop遷移到大數據中心，進行統一計算。
而對于業務服務產生的服務log，我們需要進行log文件的周期遷移，遷移之后進行數據清洗規整入庫，加入到數據中心的原始數據集中。
對于上報體系的數據，由于量大，我們同樣需要周期性進行切分，規整合并，以減少HDFS的IO資源消耗。
計算方面，我們進行分層級計算，每個層級之間會有依賴關系。
對于最上層的BI報表，我們有詳細的詳情業務分析報表，也有匯總的概覽報表，他們之間也有依賴關系。
對于涉及的業務類型，有shell腳本、python腳本、java服務、MySQL表操作、Sqoop遷移操作、MR計算任務、Spark計算任務，以及涉及最多的Hive計算。
...
單純的BI分析業務就涉及到各種復雜的任務依賴關系，一旦前面的環出現問題，后續的其他環節容易受到影響，甚至需要花費巨大的代價去追蹤哪些數據是錯誤的，哪些數據是不受影響的。
對于各個任務的管理也是巨大的問題，他們執行結果的跟蹤，依賴網絡關系的管理等等。
所以，一方面提升整個業務體系的健壯性，另一方面提升業務體系的效率，有必要引入調度系統進行整個業務體系的調度。
簡單服務內部級別的時間調度Timer，再高級點的ScheduledExecutorService，JCronTab等，當然也有系統級別的略微重度的Quartz。
但他們都是基于時間維度的調度框架，對于我們的需求來說，依然太過于輕量級，無法滿足需求。
我們需要的是一個系統級別，能夠進行任務進行調度，對任務依賴關系進行管理，對任務執行進行追蹤等，具備這些復雜功能的調度系統。
我們曾一度調研過早期阿里開源出來的Zeus，并且在之前的工作經歷中也曾一度使用過它。
首先宙斯出自于淘寶，品質相對有保障，應用于hadoop作業調度而生，對整個生態契合度高，支持MR、Shell、Hive等各種界面化調度，并且各種配置可視化，使用成本相對較低。
更多的優點就不多說了，感興趣的可以查找一些資料了解，它還曾一度獲得過熱門開源項目的頭銜。
但結合實際，我們最終還是舍棄了它，一方面我們整個集群使用的是CDH體系，想要嵌入宙斯需要改動的東西很多，二次開發的成本略大，并且實際部署略微復雜，BUG還不少，就目前這個狀態，我們并沒有太多的時間去折騰。
并且，整個項目好像維護的并不是很好，這意味著一旦上線了，風險還是蠻大的。
最終我們選擇了oozie+Hue的方案。
CDH對他天然支持，能夠與我們目前的集群體系無縫對接，省卻了所有的部署成本，暫時階段只需要把精力放到學習使用上即可。
通過oozie的工作流機制，加上hue的可視化配置，基本可以滿足我們上述的那些問題。
使用oozie+hue的方案，進行各種服務的管理，hive依賴任務的調度，錯誤的報警，錯誤日志的追蹤等，一站式解決問題。
不過，我們在使用的過程，依然遇到了一些坑，以及解決了一些坑。
例如中文編碼的問題，又例如如何處理日漸壯大的依賴樹，一旦底層依賴出現故障會造成大片上層依賴任務的中斷等等。
我們把部分的依賴判斷回歸到程序中，而不是統統交給oozie的依賴樹來管理，避免部分底層依賴錯誤造成大面積上層任務中斷，這樣可以做到部分任務可以繼續執行，進行依賴分拆，減少大范圍任務重跑的風險。
數據上報體系的監控
這里其實有個故事。
曾有一天，業務人員反饋BI分析報表數據好像有問題，整個數據對不上。
數據測馬上啟動了對問題的排查，通過一頓的各種數據查詢，匯總計算，才發現早在三四天前數據就開始異常了，再進行跟蹤，發現那天剛好更新了新版本。
再跟蹤問題，發現客戶端很多模塊進行重構，而之前的相關埋點點位受到了影響，客戶端方面沒有進行知會， 在測試時又沒有進行這部分抽查回歸測試。
于是，隨著版本的更新覆蓋，丟失了很多基礎數據。
這是一個慘痛的教訓，隨后，我們一方面制定埋點測試的方案、進行埋點完整性質保方面的梳理，另一方面數據測啟動了對數據上報體系的監控。
于是就有了如圖，我們對每天，一些重要維度的上報進行了數據統計可視化，檢測點位的數據量波動，每天可以隨時查看上報情況，此外，根據實際情況建立異常報警模型，一旦發生上報異常進行主動郵件預警，及時跟進。
趨勢圖是使用echarts畫的，頁面是spring boot+jsp框架，數據部門從此又多了前端技能，哈哈。
整個檢測體系很簡單，很粗暴，但是確實有效，對于內部使用，實時掌握上報動態，足夠了。
此外，我們還簡單的通過守護腳本進程，替代了ganglia+nagios的系統性方案，對各個節點的服務進行監控，進行圖表可視化監控，主動預警等。
足夠的節省人力，足夠的敏捷，以有限的人力解決階段性的需求為出發點。當然，在一定的階段之后，必然還是會回歸到系統性監控方案中去的。
數據上報完整性測試的痛點
在上一篇中，我們描述過數據上報完整性測試的痛處。
我們需要花費巨大的人力去保證整個上報體系的健壯，因為對于H5頁面還好，但對于客戶端埋點，客戶端一旦發布，出現故障只能通過發布緊急修復版本進行解決，但一樣會耽誤很多時間，因為整個發布周期至少都是好幾天的。
出現如上故事之后，我們著手進行埋點完整性測試機制的搭建。
我們通過測試賬號注冊的機制，來分離正常賬號的流量以及測試賬號的流量，通過時間將點位軌跡進行串聯，再打通整個實時流程，并且進行點位訪問軌跡界面化展示。
基本實現一邊點擊點位，一邊看到上報軌跡，完全同步，一改往日通過日志攔截的方式進行點位測試，根據埋點的編碼表，普通的測試人員都可以介入。
數據上報測試機制的完善，大大降低了埋點故障率，確保了上層BI分析業務的健壯性。
開放自助查詢體系
即使我們每天為業務部門提供了數十個BI分析的報表，但依然避免不了，我們的BI童鞋每天為各種BI需求奔走。
諸如，電商活動的各種數據調研，產品端各種調研性的數據提取，運營方不同運營位不同運營活動的跟蹤等等，這些都是很難做到常規化BI的數據分析提取需求。
但是很多又確確實實是重復性工作，只是因為變量太多，無法做到自動化。
于是，我們開始著手嘗試，是否能將部分查詢分析的工作轉移到業務人員身上，讓他們自己去獲取自己需要的數據，降低數據團隊的壓力呢？
我們開始逐漸完善以HUE為核心的自助查詢系統，健全自助數據分析體系。
我們對一些Hive的表權限進行隔離，對不同的業務方定制查詢模板，模板上注明詳細的使用方式，讓不懂SQL的業務人員也能根據模板進行一些數據的查詢提取等。
例如，運營人員根據查詢模板就可以很愉快的改改URL變量，改改時間變量等，拿到他們所需要的對應運營位的各種活動數據，對于我們數據的依賴程度大大降低。
不過，講真。HUE的整個體系對于那些一點SQL基礎的業務人員還是有些使用成本，所以在時機成熟的情況下，還是有必要封裝一套高度界面化的自助查詢分析系統。
此外，就是我們需要對權限進行嚴格的隔離，對使用頻度進行限制，不然大批量錯誤的查詢會讓我們的機器資源過度浪費。
不管怎么樣，開放自助查詢定然是一個需要去做的事情，將數據童鞋的人力進一步釋放出來，放到更有意義的方向上去。
結語
在數據時代，效率至上，所謂效率，不單純是整體業務的效率，同樣也是對應于內部效率的提升。
所以，在不同的階段下，我們都需要隨時反思如何能夠進一步的提升效率，結合階段性的成本投入，進行靈活的健全自己的數據生態效率體系。
不需要說足夠完整，在有限的資源下，能夠有限解決當前的問題，能夠提升一定程度的效率，就是可執行的方案。
擴展閱讀：
從0到1構建數據生態系列：
《從0到1構建數據生態系列之六：數據價值體現》
