實踐：大資料平臺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出去的報表也不會包含這個空檔期間的資料，準確性和實時性有待提高

　　解決方案 引入Tidb 分散式NewSql解決方案，或是Hbase這類讀寫和更新更有好的分散式方案，下一步準備先接入Tidb

　　問題： hive 查詢慢，rest api 查詢不友好，根據我之前提過的架構原則，適合和簡單原則，hive查詢慢並不是阻礙我實現業務的主要障礙，慢一些不會有太大關係，但是之前說的資料的增量更新和熱資料的實時查詢，並配合後續的實時資料流模組，作為流方案的資料落地方案

　　資料平臺2.0Lambda架構，離線批處理和實時流方案結合：

　　關於大資料3中架構模式的補充

　　Lambda架構：

　　Kappa架構：

　　未來的展望，去ETL化的IOTA ：

　　核心是邊緣計算，前兩個沒啥好讓人興奮的反而是邊緣計算，讓人興奮，流量劇增，單靠資料局中心肯定會不是一個明智的決定，資料中心的壓力會越來越大，期間的高可用，彈性，容錯，一致性要求更高，屆時資料的規模會倒逼架構走邊緣計算的模式，而當下分散式去中心話的計算也是顛覆性的勢頭

　　原來由資料中心完成的ETL任務交由業務終端完成，資料中心接受統一格式的CommonModel,大幅度減輕資料中心的ETL, 這種方式固然美好，但是我們們的產品，使用者，市場策略是不斷變化的，你不知道突然之間要不要換一種什麼策略去度量整個產品資料，儘可能的完全的收集，儘可能多的收集沒毛病，就像當初的google爬去網頁建立自己的索引，後續不斷優化自己的搜尋演算法，而雅虎只是實時爬去後沒有儲存快照，整個演算法調整沒有資料的支撐是很難的，當然也是我自己的臆測，到底有去ETL化我不敢肯定，但是去中心化的邊緣計算要給1024個贊!

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2155681/，如需轉載，請註明出處，否則將追究法律責任。