從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失敗或是任務失敗，原始日誌已經刪除了，尷尬??，目前解決方式是保留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架構：

　　　　　　　　　　 圖片來源：https://blog.csdn.net/Post_Yuan/article/details/52241252

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

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

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

參考：Lambda架構已死，去ETL化的IOTA才是未來 https://www.analysys.cn/analysis/133/detail/1001275/

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