從3月份到現在2個月過去了，整個數據平台從0到1，算是有了一個基本的樣子，跌跌撞撞的勉強支撐起運營的一些基本業務，當然這僅僅是開始，接下來總結下自己這段時間的得失，以及下一階段的演化目標
關於產品架構的原則可以查看這里，我分了兩篇來寫：
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/