352
瑞小博的大數據平台技術選型及架構實踐
前言
瑞小博成立於2014年，是一家專注於“商用WI-FI覆蓋”產品研發與運營模式創新的科技公司。
公司創立之初，基於成本、效率等考量，我們選擇了阿裏雲，至今已3個年頭。這3年多裏，我們使用了覆蓋 彈性計算、網絡、存儲、數據庫、大數據、安全、應用服務等多項領域的多款阿裏雲產品。
下麵，給大家分享我們在不同階段使用MaxCompute（原ODPS）的一些實踐，以供參考。
低廉的存儲&高效的運算
我們使用ODPS的首要原因，就是因為它低廉的存儲和高效的運算。
公司剛成立時，業務量很小，數據存儲和計算都在阿裏雲RDS中，簡單直接。但兩個月後，業務快速發展，RDS存儲的費用直線上升，而且任務計算耗時越來越長，已經影響到業務的發展。
彼時，開源大數據存儲計算框架Hadoop如火如荼，Spark冉冉興起，分布式數據庫Greenplum也是逐步成熟，看起來有很多的選擇，我們也就此做了調研和前期嚐試。但實際操作起來就會發現，這些平台在搭建初期的硬件成本、運維成本、時間成本遠遠超出一家創業公司的承受範圍，而且這些平台並不是公司的主營業務。自建平台的方案被PASS掉。
隻是想喝一杯牛奶，為什麼一定要建一個牧場呢？
我們轉而考察商業大數據產品，自然也就分析了ODPS。
實事求是的講，我們當時的需求其實很基礎，稍微像點樣子的大數據產品基本都能滿足我們的需求。而我們選擇ODPS的原因，一方麵是因為我們的業務數據本身就在阿裏雲內部，ODPS更方便數據同步，但更重要的還是因為ODPS的價格很便宜。當時，存儲冷數據及計算周期性任務的RDS節點一個月需要1200元，而切換到ODPS後每天存儲隻需要7塊錢，計算僅需要4塊錢，比之前便宜了近70%。
另外，切換以後，ODPS的分布式計算使得周期性任務執行的更快，業務表現更好。
所以，基於ODPS低廉的存儲和高效的運算，2014年9月我們將曆史數據存儲和周期性任務計算切換到ODPS，性能提升的同時成本也有所降低，支撐了當時業務的快速發展。
附：第一階段數據處理流程圖
完整的大數據開發框架
獨木不成林。如果隻有大數據存儲和後分析處理，數據是割裂的，功能也是殘缺的。
所幸，阿裏雲逐步開放了一套完整的大數據開發框架，以ODPS為核心將一個個獨立的功能點連成了線，也吸引我們長期成為阿裏雲大數據產品的忠實用戶。
2015年，公司的業務飛速發展，數據量陡增，每天會產生上億條業務記錄。按照之前的數據處理架構，業務數據入RDS再同步到ODPS的做法，即使是高配RDS的IO性能也根本撐不住。而且一個高配RDS每月需要2000多塊，成本比較高。
本來，最初公司的技術演進roadmap中，雖然也覺得RDS作為數據采集模塊會有瓶頸，但考慮到數據量不大，預計這套數據處理架構能使用一到兩年。
而隨著業務量陡增，我們隻有提前做出改變。技術方案是：以日誌文件係統，部分代替關係型數據庫作為數據采集模塊。
業務上看，大數據量、低可靠性要求的數據通過日誌文件係統采集，小數據量、高可靠性要求的數據依然通過關係型數據庫采集。
有了之前的經驗，技術方案確定後，我們沒有考慮立即去搭建fluentd/flume，而是看看阿裏雲上有沒有類似的產品，然後發現了SLS。
SLS以正則匹配近實時（5分鍾時延）采集ECS上的日誌文件，不僅存儲到日誌文件中，還提供類Elasticsearch的文本搜索服務，完全滿足我們的業務訴求。
更為關鍵的是，SLS與ODPS是完全打通的，不需要業務係統介入，簡單配置就可以將SLS采集的日誌數據自動同步到ODPS。另外，當時SLS還是完全免費的（2016年11月開始SLS不再免費，但如果不使用搜索服務，費用還是比較低廉的）。
最終，通過引入SLS，很好的解決了我們數據采集的性能問題，而且還減少了兩個高配的RDS節點，每年節約了近6萬的成本，此架構也一直沿用至今。
附：第二階段數據處理流程圖
當然，也不是每次探索都是成功的。這個階段，由於實時計算的需求我們研究了Stream SQL（目前已下線），由於BI報表的需求我們研究了AnalyticDB，都不太符合我們的業務場景，隻能通過自建或其他方案實現。
我們一直認為，獨立割裂的數據價值是很低的，數據開發框架也是如此。而阿裏雲大數據產品這幾年一步步的完善，尤其是將一個個獨立的功能點連成了線，產品之間打通促進數據之間打通，吸引我們與之共同成長和進步。
發揮主觀能動性
阿裏雲數據產品目前還處在完善階段，不可能所有需求都能夠立即滿足。所以，我們還需要發揮主觀能動性，解決業務問題。下麵分享我們自建數據倉庫和BI報表係統的實踐。
2015年底，公司業務開始進入正軌，運營、市場等各方麵的數據訴求越來越多，現有機製和人力開始捉襟見肘。因此，我們考慮開發數據倉庫和BI報表係統。
當時，阿裏雲沒有一款獨立的BI產品，部分產品中零散的有點類似BI報表的功能（如DPC的“數據分析”）也相對較局限，不能滿足我們的需求，隻能自建。
因此，我們在業務上構建了維度體係和指標模型，統一業務語言。數據處理架構上，將詳單事實表和維度表同步到ODPS後，在ODPS中進行匯聚運算，輸出統計事實表到RDS。同時，開發了 DashBoard、即席查詢、查詢報表 三個應用，滿足我們的業務需求。
其間的過程不再贅述，開發的應用如圖所示。
DashBoard
即席查詢
現在，阿裏雲的QuickBI已經發布，能很好的滿足BI報表的需求。好的產品，可能會遲到，但不會缺席。
數加，新的紀元
數加的發布，是最近一年多的事，我們也還在摸索與嚐試。
目前來說，比較大的感受是機器學習平台的組件化和數據模型化做的很好。在數加發布之前，我們也會自己寫一些算法做業務分析，包括統計分析中的各種檢驗、機器學習中的分類聚類、時間序列分析等。但相對都比較散，輸入輸出數據模型不統一，組合比較麻煩。數加的組件化設計，能比較好的解決這個問題。
另外，數加的公開數據集也比較不錯，測試驗證算法很方便。
結語
三年多來，ODPS一直穩定的支持著我們的存儲和計算，是我們的核心基礎平台。
我們希望，在數加時代ODPS能一如既往的穩定，並提供更多的數據產品，幫助我們在數據的海洋裏繼續遨遊。
最後更新：2017-08-13 22:36:19