如何快速落地數據分析平台 大數據在他趣的應用實踐

張嵩，廈門大學計算機碩士畢業，現於他趣任首席架構師，主要負責微服務體系健全及持續交付體系建設。Go語言愛好者及contributor，近期專註於k8s在他趣的第二版落地及探尋 Machine Learning 在社區的應用。

在各種 RDB 的支撐下，通過埋點等我們已經能夠實現各種業務統計、監控、分析等方面的需求，但是我們會最先觸碰到哪些瓶頸呢？而碰到瓶頸後又要如何通過大數據應用來解決呢？這是本文想要著重探討的地方。

探索三步曲 步步簡化

圖 1 是一個常見的情況，在每一台伺服器日誌上去部署一些數據分析，簡單分析後會上報到RDB Redis上，之後會進行二次運算，緊接著到達展示層；在這個過程中，查詢日誌可以在ELK上進行。這算是比較簡單的一個方案，基本可以滿足大家的需求。但是這樣做也會產生一些問題：

• 新增不易；

• 直接統計出結果數據集過於龐大，二次運算的複雜度取決於空間的維度；

• 可接受的時間複雜度

• 集群維護複雜度

鑒於這幾個問題，我們將需求重新整理，如圖 2 所示，最開始（從左至右）是數據源，數據源包含很多，比如日誌；第二步是數據處理清洗，主要的目的是將一些不需要的數據清除掉；第三步是落存儲，有很多方法，比如HBase；最後一步就是數據應用，比如做一些統計報表、進行報警之類的應用。

圖 5 是一代的流程圖。從數據源，也就是伺服器上日誌開始，數據流經 Flume，到達 Kafka後，分成兩路流（實時流與非實時流），一路推入HDFS、一路經過 Storm 進行處理；非實時流主要是用 MR 和 Spark，進行清洗加工後將數據存儲到 HBase；實時流則經過 Spark Streaming 、Storm處理，最終也是存儲到 HBase。這些是早期比較常見的結構。

這種結構下，組件之間兼容問題很多；人力成本消耗大；batchjob、streaming資源、核心非核心資源的競爭難以隔離；由於作業之間依賴關係會導致作業管理複雜；

圖 7 是二代的流程圖。我們使用了阿里的 EMR、MAXComputer 等產品，此時，伺服器則使用的是 LogStash，日誌服務則使用 LogHub，存儲則採用OSS。這裡也產生一些新的問題。首先，日誌服務相對自己搭建ELK要簡易很多，但是索引按照欄位大小收費，價格較高；其次，不同組件間集成異常繁瑣；第三雖然擴容方便，但是人力並未得到釋放；第四內存型計算服務可以實現准實時分析出數據，但是價格偏高；第五是資源競爭問題難以隔離的問題依然存在；第六就是產品變更太快，有時候產品會突然下線或者功能遷移到新的產品中。

圖 8 是我們最新的結構圖。在第三代中我們採用了七牛雲的大數據產品，他們會把一些不屬於我們應該做的操作直接放在他們自己的平台上，由他們進行維護，這個產品就是他們的大數據產品Pandora。

圖 9 也是我們最新的一個流程圖。最開始還是伺服器，然後是Logkit，當搜集到數據源之後，將非實時數據打到對象存儲上，利用離線計算去處理這些工作流，經過離線計算的工作流，如果需要做二次計算或存儲就再次返回到對象存儲，如果需要直接計算出結果的話，就直接寫入到J16組件上，J16是我們自己寫的接收http結果的組件，實心箭頭代表現在這塊還未完善，我們是通過額外的腳本進行結果收集到J16的操作；實時數據也採用類似於離線處理的方式，後面步驟與離線計算一致，處理之後的數據，可以用於展示報表和數據挖掘。

類似於saas的最後一種流程，可以讓我們的人力接近完全解放。同時組件不存在集成與兼容的問題。因為上面設計的離線工作流和在線工作流是完全分離的，所以資源可以完全隔離。

實戰分享 少走彎路

【數據方面】

【業務】

如圖 10 所示，我們的業務和數據處理之間其實是相互交叉的。

為了減少大家在實際過程中碰到的彎路，所以我會分享一些實踐上的經驗，供大家參考。

從數據源開始，數據源常見的是nginx、tomcat、fpm、網關、業務、資料庫日誌、上報異常、Sla日誌等客戶端統計數據。

圖 11 是 nginx 的日誌，涵蓋的內容很多，比如設備號、跟蹤IP、UA頭；微服務存在一個很大的問題，就是如何處理用戶日誌追蹤；處理方式就是當客戶端進行訪問時，帶一個唯一的ID號，最終通過這個ID號可以直接抓出這次所有落在不同服務的請求數據。

• 圖 13 是日誌查詢界面，為服務端人員提供查詢功能。可以通過設備號，唯一請求ID等，得到客戶端的請求日誌，也可以支持高級的自定義查詢功能。

圖 14 是時序圖，通過這張圖，可以判斷到底是自己調用其他系統服務時耗費時間長還是自己進行查詢時耗費時間長，以及慢查詢發生在何處，是因為查詢資料庫慢了還是其它的原因。

圖 16 是業務在伺服器上運行的時間，這邊可以反映出代碼的質量問題。比如兩秒以上的介面幾乎都是比較複雜的介面，例如下單操作或者調用第三方介面。

圖 17 是微服務帶來的問題，微服務有一個版本控制，比如微博介面也從V1、V2、V3一路升上來，就很難確定說什麼時候可以下掉這些舊版本，比如我已經升級到V4版本，但是我的V2版本由於舊版本客戶端的原因，需要還能夠使用。這樣子的話一旦出現bug，就必須V2、V3、V4都打一個補丁過去，對開發人員來說是一個很大的負擔。

有分析的話，就可以統計處哪些版本訪問量對高，哪些版本訪問量最低，這樣我們就可以不斷地根據訪問情況下掉舊版本的系統，少維護一些系統。然後也可以知道使用這些API的客戶端到底是哪些版本，有沒有包括當前最新的版本，有的話就不能下架，需要安排逐步修改。例如今年我們就下掉了六七個版本。

也可以通過歷史數據來做一些運維方面的自動化，例如通過前一七天帶寬等的分析來做到帶寬的自動增減，以及類似推送高峰期前自動擴容等的各種操作。

我們每天都要應對不同的攻擊，例如CC攻擊這一塊，我們有做一些WAF的防禦，還有網關的限流，但是因為閾值的關係，也很難說完全限制住。這個時候我們可以實時的統計當前有哪些客戶端訪問的數目是異常偏高的，例如圖18，我們看最高都是在上面那五條線，每秒鐘可能都有幾十萬人訪問，這五個設備訪問頻率在裡面出現次數最高，就說明有異常。這種就可以做一些特殊處理，針對異常設備進行限流。因為你很難說對所有的設備進行限流，有時候客戶端的訪問確實會很高，比如搶紅包之類的。

七牛雲技術總監陳超、鏈家網大數據部負責人呂毅聯袂出品，精選乾貨內容：

• 鏈家網資深大數據研發工程師鄧鈁元，分享如何運用「開源＋自身業務定製」解決大數據多維分析痛點

• 七牛雲大數據高級工程師黨合萱，全面揭秘七牛自主研發千億級大數據平台的實踐之路

• 螞蜂窩大數據平台負責人汪木鈴帶來螞蜂窩作為國內最早一批使用 Druid 的公司，在實戰過程中踩過的「坑」和優化經驗

• 前新浪微博技術專家、三好網 CTO 衛向軍，講解如何利用大數據技術方案在實際業務應用中增值

高可用架構粉絲福利：

點擊「閱讀原文」即可享免費報名

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！