實踐：大數據平臺1.0總結和2.0演化路線

從3月份到如今2個月過去了，整個數據平臺從0到1，算是有了一個基本的樣子，跌跌撞撞的勉強支撐起運營的一些基本業務，固然這僅僅是開始，下一步還要從零打造本身的UBS系統，想一想都興奮呢!接下來總結下本身這段時間的得失，以及下一階段的演化目標。

　　關於產品架構的原則能夠查看這裏，我分了兩篇來寫：

　　https://www.cnblogs.com/buoge/p/9093096.html

　　目前的架構方式是這樣的:

　　從使用Sqoop 定時從MySQL中同步數據，數據量大隻能小水管的去fetch每次5-10W條記錄，避免數據庫壓力過大

　　Flume tailagent 每彙總一小時而後傳遞logcenter,經過Python過濾後批量的Load到hive中

　　每日的報表在Hive的基礎上會跑一些 MR 的Job, 做爲每日的固化查詢。

　　目前的缺點和不足：

　　問題： 日誌讀取,Hive入庫和完成後刪除log日誌原始文件沒有作完整的事務控制，load失敗或是任務失敗，原始日誌已經刪除了，尷尬:sweat:，目前解決方式是保留15天的原始日誌

　　解決方案 ：後續引入Kafka的日誌回放功能，它有機制保證寫入一次後在返回

　　問題 ：各類crontab 飛起沒有統一的調度平臺，crontab 之間有依賴關係，可是crontab並無作先後的依賴檢查和重試

　　緣由 ：數據就我一我的，平臺架構和業務要同時搞，老闆在後面催沒有這麼多時間允許我慢慢的搞的這麼精細

　　解決方案 ：引入azkaban任務調度平臺，統一管理

　　問題： Hue還沒安裝，神器不解釋了，把各個集羣的指標彙總在一塊兒，HDFS，Yarn, MapReduce都能在一個頁面直觀的看到，並且還有個方便的功能就是Hive的web客戶端，不用每次都去終端敲ssh命令，公司網垃圾ssh總是斷浪費時間

　　問題： HDFS數據不能修改，只能刪除重建，這裏其實更適合日誌類的信息，像訂單分析和會員分析，須要作增量更新的記錄則不合適，就幾萬條記錄須要更新，可是把上億級別的表刪除在重建絕對是有問題的

　　問題： HDFS 同步有24小時的時間差，這期間線上的訂單和會員信息已經發生了百萬級別甚至更多的變化，而hadoop集羣卻無法及時的同步，從Hive出去的報表也不會包含這個空檔期間的數據，準確性和實時性有待提升