原文地址：http://www.infoq.com/cn/articles/qiniu-big-data-platform-evolution-and-analysis?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage

七牛大數據平臺的演進與大數據分析實踐

(點擊放大圖像)

圖 1 大數據生態體系

看著圖 1 大家可能會感到熟悉，又或者會覺得部分有些陌生，這是一張匯集了目前大數據生態下大多數成熟組件的架構圖。眾所周知，大數據生態很復雜，對于個人來說，要全部學會可能要花費好幾年時間。而對于企業來說，要最大程度發揮其價值，構建一個成熟穩定、功能多樣的大數據平臺，期間花費的時間以及人力成本著實難以估量，更何況還需要考慮持續維護的問題。這就是七牛的Pandora大數據平臺靈感的來源，我們構建一個大數據平臺，作為產品提供給用戶，快速幫助用戶挖掘數據價值。

1. Pandora的背景和解決的問題

七牛是以云存儲起家的公司，平臺上有著大量的數據、業務日志以及運維監控數據，基于對這些數據的管理以及分析的需求，Pandora誕生了。我們搭建了一個可靠的大數據平臺，將大數據生態中的各個組件配套成一個體系發揮作用，用來解決實際業務中碰到的繁瑣、復雜、多樣化的問題。這個大數據平臺的工作從數據的采集便已開始，通過一條數據總線，再根據業務需求分流到不同的下游產品，從存儲到數據可視化，從實時的數據變換到離線的算法分析，我們構建一個全棧的大數據分析產品。

與此同時，我們在大數據平臺之上構建了業務工作流的概念，讓用戶只需關心構建符合他們業務模型的工作流，而無需具備大數據技術背景。不僅大大降低了用戶挖掘大數據價值的成本，更為重要的是去除了大數據技術門檻，使得各行各業的專家可以更好的施展自己對業務的深度理解。

在工作流上，用戶不僅可以清晰的監控自己的數據流動，輕松構建各類實時、離線的數據變化與自定義計算，還可以按需彈性擴容、快速調度云端資源，降低了運維的成本。與此同時，我們集成了社區中大量的優秀開源軟件，對其進行優化及定制，一方面以便發揮其更強大的功能，另一方面，也讓熟悉使用這類開源軟件的用戶可以做到快速遷移，無縫切換使用。

2. Pandora的功能特點與應用場景

那么，Pandora到底是一個怎樣的平臺呢？工作流又是怎樣的呢？讓我們首先來直觀的看一下工作流的使用形態，如圖 2 所示。

(點擊放大圖像)

圖 2 工作流形態

最左邊的數據源是工作流的起點，數據源可以是一個，也可以是多個。在實時計算的工作流中，我們只能有一個數據源，這個數據源就是數據收集匯聚的中心，也可以理解為數據總線，所有不同終端的數據打向數據源，再通過數據源根據業務需求分發到不同下游；在離線工作流中，我們可以有多個數據源，不同的數據源代表的是存儲在不同地方的離線數據，可以是七牛云存儲中的不同文件，又或是HDFS等不同類型的數據倉庫。

不管是實時還是離線，從數據源開始，你就可以根據需要做不同類型的處理。

最基本的處理是對數據進行一些定制化的計算，比如你可能需要對每天海量的數據進行一個定時分析匯聚的功能，計算每分鐘有多少條數據、每小時有多少條數據，從而縮減數據規模節約存儲成本，或者從中生成一份數據日報、周報等等；又比如在這個信息爆炸的時代，你從網上抓取了海量的數據，需要對數據進行一些清洗、過濾、刪選，以此分析社會熱點或其他有價值的信息；又比如你想對數據做一個延伸或擴展，最常見的就是對一個IP獲取它的運營商、所在區域等信息。那么你就可以創建一個計算任務，最簡單的編寫一些SQL語句就可以做數據變換；進階一些的使用方式就是編寫一些UDF(用戶自定義的函數)，做一些較為復雜的變化；更高階的就是直接編寫一類插件，直接使用大量Java的類庫對數據進行操作。當然，在離線計算中，除了單個數據源的計算任務以外，你還可以對兩個數據源，亦或是兩個計算任務的結果進行聚合，然后再進行計算等等。計算任務可以滿足你對于整個工作流的完整數據處理需求。

在進行過一個基本的計算以后，可能最常見的一個需求就是對這些計算后的數據進行檢索，直白的說就可以查詢你的數據。那么你可以創建一個導出到日志檢索，在這里你就可以搜索你的計算結果。當然，你的數據在數據源中也完全可以不經過任何計算任務，直接導向日志檢索。又或者你希望對數據進行更完善的實時監控和數據可視化處理，那么就可以導出到時序數據庫，針對帶有時間戳的數據做高性能數據寫入和查詢優化，滿足你針對實時海量數據的即席查詢需求。

另一方面，你工作流計算后的結果，可以直接再次導出到七牛云存儲進行永久保存，或者與后續的數據結合進行分析。你也可以理解為通過大數據服務，七牛的云存儲變成了一個數據倉庫為客戶提供服務。之前已經存儲在七牛云上的數據(如CDN日志等)，完全可以直接使用我們的大數據平臺進行計算，無需任何接入過程。

為了方便用戶充分利用自己的數據，我們甚至提供了導出到 HTTP 服務，用戶可以構建自己的 HTTP 服務器來接受經過Pandora大數據平臺計算后的數據。

3. Pandora的系統架構與變遷

(點擊放大圖像)

圖 3 產品架構圖

圖 3 是 Pandora的產品架構圖，基本的功能在第 2 節中均已介紹，在此不再贅述，在講解系統架構之前，讓我們對照產品架構進行一些基本的系統組件技術名稱的對照說明，以便下文描述簡潔便于理解。數據通過我們提供的數據上報工具logkit、各類SDK或者用戶直接調用開放API接入，數據進入后無論是數據源本身還是經過計算任務后的臨時數據存儲節點，我們都一稱作消息隊列，技術上稱之為Pipeline，像不同下游提供導出服務的組件我們稱之為Export，在Pipeline中承擔各類計算任務處理的組件我們稱之為Transform，下游的時序數據庫服務我們稱之為TSDB，下游的日志檢索服務我們稱之為LogDB。

(點擊放大圖像)

圖 4 Pandora系統架構圖

有了這些基本概念后，讓我們對照圖 4 Panora系統架構圖，開啟我們的Pandora架構演進之旅。

3.1 數據上報

最左側的組件是數據收集的部分，數據來源于客戶各種各樣的系統。相信大部分用戶在接入大數據平臺時，都會面臨數據收集這一難題，一方面希望數據不重不漏全部收集上來，一方面又要數據收集盡可能高效且不太消耗機器的各類資源，同時還要滿足場景各異的不同情況下的數據收集需求。熟悉這塊的朋友可能也早已了解，社區已經有很多不同類型的開源數據收集工具，知名的包括flume、logstash、fluentd、telegraf等等，他們各有利弊，功能上大都滿足需求，但是在性能上和一些非通用需求的場景上不盡如人意。為了更好的滿足用戶不同類型的需求，我們自主研發了一個可以收集各種各樣數據源數據的工具logkit，圖 5 是logkit的功能架構示意圖。logkit使用go語言編寫，以插件的形式定制不同的數據收集解析需求，處理高效、性能損耗低，同時也已經開源，我們非常歡迎大家一起參與到logkit的使用和代碼開發定制中來，為logkit 提提PR，當然，也非常樂意接受您關于logkit的任何意見或建議，只需在github提issues即可。

(點擊放大圖像)

圖 5 logkit功能架構示意圖

有了這樣一款數據收集工具，幾乎 90% 的數據收集場景我們已經解決了，但是還會有諸如ios、android客戶端數據直接上報、頁面請求點擊數據直接上報等需求，為此我們提供了各類語言的SDK方便用戶使用，以彌補logkit功能上無法滿足的需求。

3.2 大數據總線Pipline

數據收集上來后，就正式進入我們的Pandora大數據平臺了。所有上報的數據無論最終是否計算或存儲，都會統一暫存進入我們的大數據總線Pipeline。相信經過上面的介紹，很多讀者早已發現，Pandora幫助用戶根據不同場景選擇最適合的大數據分析方式。而這套模式的核心，毋庸置疑，就是處理數據在不同大數據產品間的流轉。

Pipeline就是這樣一條數據總線，在數據總線的基礎上我們打通一條條管，根據所需的場景導出到后端相應的存儲服務上。同時據此來進行資源分配和任務管理。這樣一來，就可以避免用戶技術選型及技術架構與使用姿勢和業務場景不匹配的情況，同時也可以利用云計算的優勢，按需分配、快速擴容。

3.2.1 基于confluent的初版

(點擊放大圖像)

圖 6 Pipeline第一版

如圖 6 所示是我們的第一版架構，實現上我們通過定制開源版本的confluent，并把它作為我們這個架構系統的核心。數據要流入系統，我們首先構建了一個 Points Gate（API 服務器），Points Gate 解析校驗用戶的數據格式并調用confluent中kafka-Rest提供的rest API 將數據寫入到kafka，利用schema-registry完成數據格式的校驗以及數據解析，通過kafka獲得數據管道的能力。

在進行元數據創建時，我們的調度器在元數據服務器上創建一個用戶元數據存儲在MongoDB當中。對于MongoDB的元數據訪問，我們構建了一個二級緩存系統（即圖中qconf），數據在進入或者導出時都會通過二級緩存訪問元數據，這樣數據就可以快速得到校驗，扛住海量的數據吞吐。Kafka本身包含了Zookeeper組件，我們也借此來保證整體系統組件的服務發現以及數據一致性這兩個問題。

然而，隨著應用的增加，數據量越來越大，這樣，單個定制版的 Confluent 并不能滿足這些數據量增長的業務壓力，以及用戶不斷增加的場景需求。kafka topic(partition)不斷增長導致整體響應變慢，無法快速切換災備等待問題日益凸顯。在這個基礎上，我們對原本的系統架構進行了調整。

3.2.2 Pipeline的升級

(點擊放大圖像)

圖 7 pipeline的升級

如圖 7 所示，我們對Pipeline的第一次整體升級包含了大量的組件基礎架構的調整。首先我們構建了Confluent的多集群系統，將單個Confluent集群規模控制在100臺機器以內，分區數量控制在1萬以內，根據需求對集群進行路由。

可見通過多集群系統，我們可以合理控制每個confluent集群的規模，同時根據我們的調度器按照需要切換用戶到不同的集群上，實現快速切換、擴容、容災、隔離等調度需求。

其次我們對Points Gate、Transform、Export中無狀態組件進行了容器化處理，利用我們七牛內部的容器云平臺，實現了無狀態服務的快速部署、擴容以及灰度發布等需求。

這次架構的調整效果顯著，我們成功抗住了每天上百TB，千億級數據點的數據增量。

不止于此，為了更高的性能提升以及節約成本，我們在上述升級之后進行了第二次的架構升級。這次升級主要體現在對Confluent的進一步定制（或者說替換），我們不再使用kafka-rest，同時對打點的數據格式進一步優化，又一次節約了近一半的機器成本。

3.3 數據導出服務Export

在解決了數據總線問題以后，問題的重中之重自然是如何處理數據導出的問題。眾所周知，數據導出其實就是從一個上游系統拉取數據，然后將數據再發送到下游系統的過程。但這里面涉及的難點和調整可能大多數都是不為人知的了。在介紹我們的導出服務架構之前，非常有必要描述一下針對海量數據導出，到底有哪些挑戰？

3.3.1 數據導出的挑戰

首先面對的第一大挑戰自然是高吞吐量的問題，海量數據不斷涌入帶來的必然問題就是網卡和CPU分配的問題，一旦流量分配不均，就會出現大量因網卡、CPU負載過高帶來的延遲，嚴重影響服務可用性。

顯然，保證低延遲就是第二個挑戰，一旦各個鏈路有一個環節配合不均衡，就會帶來大量延遲，如何保證導出的上下游始終保持較高的吞吐量，從而保證較低的延遲，是一個非常大的調整。

為了保證低延遲，就要更好地適配多種下游，使其始終保證高吞吐，了解下游不同服務的特性，并針對這些特性動態的調整資源，亦是一個很大的挑戰。

除此之外還有分布式系統的常見問題，需要保證服務高可用，以及水平擴展的能力。保證任務單元標準化，任務粒度可以切分擴展；保證調度任務節點故障不影響其他節點的正常導出等等。

最為重要的是自動化運維，當導出的任務涵蓋數十上百臺機器后，人力已經無法精細化處理每臺機器的任務分配，資源必須可以自動調度、調整以及構建統一的任務監控。

3.3.2 導出服務功能介紹及架構演進

(點擊放大圖像)

圖 8 導出服務功能架構圖

讓我們來看一下導出服務的功能架構圖，如圖 8 所示。我們的導出服務主要涉及三個層級，一個是元數據管理，在這一層保證任務的分配以及監控展示；第二層則是任務管理層，除了基本的任務切分、并發管理以及通信協議之外，還包含了壓力預估模塊，根據之前的數據量預估下一階段的數據流量，從而調整資源分配；再下一層則是數據處理層，在這一層完成諸如數據預取、數據校驗、壓縮以及推送到下游等任務。

在最初的版本中，我們會在 zookeeper 上面創建一個任務(task) ，Export 通過分布式鎖對task進行爭搶，被搶到的任務則開始直接導出，如圖 9 所示。

(點擊放大圖像)

圖 9 初版導出服務架構

在這樣一個初步架構中，我們基本完成了水平擴展以及高可用的需求，同時做了諸如數據預取，延遲報警、數據監控等多種功能和優化。但是流量上來以后，很容易出現某個機器爭取的任務流量變大，導致大量數據打到同一臺機器上，導致網卡和CPU負載過高，延遲急劇升高。本質上就是流量分布不均勻，導致導出性能低下，機器資源的平均利用率也低。

(點擊放大圖像)

圖 10 第一次導出服務架構升級

此時，我們對該方案進行第一次架構升級，如圖 10 所示。我們將原來topic級別的任務按照parition進行分布式消費。為了使得每個partition粒度的任務大體是均等的，我們將partition承載的數據量按照標準化處理，并根據歷史流量進行預測，預測結果超過當前我們定制的標準符合的對應容量即觸發擴容，這樣的標準化有效簡化了調度的難度。

同時我們將原來純粹的export改為master/worker結構，Master對收集到的任務進行主動權衡分配，根據任務的歷史流量進行流量預測、對任務的partition數量、每個export worker的機器資源剩余情況，進行綜合調度。對于一些特殊任務做機器黑白名單綁定等功能。

(點擊放大圖像)

圖 11 第二次架構升級的導出服務

在做了上述工作以后，我們機器的整體利用率有了很大的提升，但是由于下游系統的不同，寫入吞吐量始終參差不齊，無法始終保持在一個較高的水平。為了解決該問題，我們再次對架構進行小范圍升級，如圖 11 所示，我們在導出的export worker端增加了一套對下游系統的適配加速模塊。其核心思路就是按照下游的吞吐能力進行自動調節請求體大小以及并發度。這個主要是為了解決上下游傳輸數據速度不匹配，以及下游吞吐量不穩定的問題。

類似于Flume的思想，我們構建了一個內存隊列，以事務的形式從隊列中獲取數據（或者失敗回滾），根據下游的情況調整單次數據請求的大小和并發度，以及調整出錯等待時間等。這樣一來，整個導出的吞吐量就可以很有效的進行控制，去除了毛刺，極大的提高了機器資源的使用率以及導出效率。

解決了數據的導出問題，基本上絕大部分數據流轉的問題也都解決了。下面我們開始關注Pandora下游的一系列服務。

3.4 時序數據庫服務TSDB

TSDB是七牛完全自主研發的分布式時序數據庫服務。TSDB針對時序數據定制存儲引擎，根據時序數據帶有時間戳的特性，我們針對時間戳做特殊的索引，實現數據高速匯入和實時查詢獲取的能力；同時構建了簡單且高性能的HTTP寫點和查詢接口，為查詢聚合數據量身定制了類SQL語言，完全兼容開源社區InfluxDB的API，支持無縫對接到Grafana，對數據進行高比例壓縮，實現低成本存儲。除此之外，TSDB擁有開源社區版本的InfluxDB所沒有的分布式、多集群、高可用，水平擴容、以及分庫分表能力。

(點擊放大圖像)

圖 12 TSDB 基本結構示意圖

如圖 12 所示，TSDB是我們基于tsm構建的分布式時序數據庫，擁有每秒60萬條記錄的寫入性能以及實時查詢聚合分析的能力。在分布式方面，除了基本的多集群、多租戶隔離的概念以外，我們還針對性的做了兩個強大的擴容功能，一個是根據時序進行縱向集群切割，解決海量數據寫入時磁盤的快速擴容問題；另一個則是根據用戶的標簽進行數據庫表橫向切割，類似傳統數據的分庫分表能力。在進行了這兩大擴展能力變換后，數據的寫入和查詢依舊高效，甚至查詢速度在分庫分表后性能有所提升。

為了實現這樣的擴容功能，我們基于此構建了一個分布式計算引擎，解析用戶的SQL并變成一個個執行計劃，將執行計劃下推至不同的TSM計算引擎實例中進行計算，最后再進行數據reduce計算反饋給用戶。

除了數據寫入性能高以外，還支持數據即時查詢，數據寫入成功即可查詢，數據零延遲；同時支持InfluxDB的持續聚合功能，類似于定時任務一樣將持續寫入的數據不斷進行聚合計算；當單個用戶數據量過大時，擁有橫向拓展能力，集群擴展后寫入性能不打折，查詢效率更高。針對時序數據的特性，我們將數據進行冷熱分離，對數據按照時間分片，使最近的數據查詢性能更高。

3.5 日志檢索服務LogDB

在了解完我們的時序數據庫以后，讓我們來看一下下游的另一大服務，日志檢索服務，又稱LogDB。日志搜索其實是幾乎所有技術開發人員都會需要的服務，傳統解決方案(ELK，Elasticsearch、Logstash、Kibana) 針對小數據量不會出現任何問題。但是當數據量過于龐大時，這些方案也就不那么適用了。

我們LogDB的底層可以通過插件的形式接入不同類型的搜索引擎，包括Solr、Elasticsearch（簡稱ES）等，目前承載海量數據搜索任務的底層引擎主要使用的是ES。與單純的使用ES不同，LogDB本身是一套分布式系統，管理的單元可以是一個ES節點，也可以是一個ES集群，所以我們構建了大量的ES集群，不同的集群用以適配不同的用戶以及不同的搜索需求。

大體上我們將搜索的需求分為兩類，一類是ELK類需求，針對如程序運行日志、業務訪問日志等收集索引，這類需求的普遍特點是數據量大，時效性高，帶有時間戳，無需存儲太長時間，無需更新；另一類需求類似于搜索引擎，數據存在更新需要，且強依賴于不同類型的分詞器，數據冷熱不明顯，不帶有明顯的時間屬性，我們稱之為通用檢索需求。這兩類需求，LogDB都是完全支持的，但是針對這兩類需求，我們做的優化不同。

(點擊放大圖像)

圖 13 LogDB架構圖

在我們討論具體的優化之前，讓我們先來看一下LogDB的架構圖，如圖 13 所示。首先是數據的寫入，LogDB是Pandora平臺下游服務，上游主要是之前提到的Pipeline以及Export。Export導出的數據通過apisever將數據導入到不同的ES集群當中，根據不同用戶的需求給他們提供不同的集群服務，集群之間也可以相互進行切換。

那么如何確認數據到底數據哪個集群呢？為了使得海量的數據快速確認，我們對元數據進行了多級緩存，包括MongoDB的實際存儲、memcached的二級緩存，以及本地的緩存，極大提高了數據校驗的速度。除此之外，LogDB本身也是Pandora的用戶，使用了TSDB對自身數據進行監控，使用七牛云存儲進行數據快照與備份。同時將計費數據導出到云存儲，利用我們的XSpark機器進行離線計算。

架構中剩下的部分都是我們針對不同索引做的優化。簡而言之，我們首先構建了一個高性能隊列，可以讓外部的數據持續高吞吐寫入；同時我們還會根據歷史流量進行動態索引平衡、不同集群的索引跨集群平衡、索引定時清理、VIP集群隔離等功能；并且會對 ES 的搜索進行分步搜索控制，緩存歷史搜索，優化用戶搜索的效率和體驗等等。關于這一塊的詳細內容，我們團隊在之前已經分享過，可以閱讀這篇《基于Elasticsearch構建千億流量日志搜索平臺實戰》公眾號文章了解更詳細的內容。

3.6 XSpark

最后有讀者看到這里，也許會忍不住想問，如果只是純粹的想使用一個高度靈活的Spark集群，不希望經過Pandora各類復雜的計算、導出，甚至數據都沒存儲在七牛，可不可以享受七牛的Spark大數據服務呢？是的，完全可以，這就是我們的XSpark！

XSpark不僅與Pandora整體完全打通，可以把七牛云存儲當成一個數據倉庫使用，又完全可以獨立使用。即用戶除了在Pipeline里面做離線計算之外，你還可以選擇直接一鍵生成一個基于容器云的個人專屬Spark集群，直接讀取你自己的數據源，只要Spark支持的數據格式，XSpark都支持。如果你的數據已經存儲在七牛云存儲上，XSpark可以直接高效讀取并計算，XSpark是Pandora提供給大數據高端用戶的一個高度靈活的離線計算產品。

顯然，容器云所具有的優勢XSpark全都具備，你完全可以根據需要動態伸縮的XSpark資源數量與規格，按需啟停等等。

(點擊放大圖像)

圖 14 XSpark 架構圖

圖 14 是 XSpark 的架構圖。我們將Spark的master和worker分為不同的容器，首先啟動Spark的master容器，獲取master地址，然后再根據用戶的配置，啟動相應數量的worker容器，worker容器自動向master注冊。同時容器云的支撐使得我們的XSpark可以在運行過程中進行縮容擴容。

同時XSpark也開放了完整的Spark監控以及管理控制頁面，完全兼容開源社區的Zepplin使用方式。

4 基于Pandora的大數據實戰

那么我們這樣的一套系統，用戶體驗到底是怎么樣的呢？下面我們以收集最常見的nginx日志為例來看下實際體驗。

首先，為了讓用戶最舒適的將數據上傳到我們平臺，用戶可以直接部署我們的 logkit 工具，然后打開logkit配置頁面，如圖15所示。

(點擊放大圖像)

圖 15 logkit 配置頁面

根據需要一步步選擇數據源、配置解析方式、發送方式最后確認并添加。當然，在配置解析方式的頁面，你還可以通過頁面預先嘗試解析器配置是否正確，如圖16所示。

(點擊放大圖像)

圖 16 logkit 配置解析器

通過簡單的幾步配置后，你的數據便已經上傳到Pandora平臺，并自動生成了工作流，并且創建好了導出到日志檢索服務，如圖 17 所示。

(點擊放大圖像)

圖 17 自動創建的實時工作流

在工作流中，你還可以創建一些計算任務做一些分析計算，導出到云存儲作為數據計算，導出到時序數據庫進行復雜的SQL查詢。之后的大數據分析工作也就會相對容易一些。有了這些準備工作，我們就可以開始進行日志檢索查詢（圖 18 所示）、數據可視化（如圖 19 所示）、離線分析（如圖 20 所示）等工作。

(點擊放大圖像)

圖18 日志檢索示意圖

(點擊放大圖像)

圖 19 Grafana數據可視化

(點擊放大圖像)

圖 20 使用XSpark離線分析

4.1 實時數據分析實戰

在我們這僅僅兩三步簡單的操作以后，就可以看到哪些十分有價值的數據呢？

實時總用戶訪問量(請求數統計)，如圖 21 所示

(點擊放大圖像)

圖 21 實時總用戶訪問量

機器請求數隨時間變化趨勢，如圖 22 所示

(點擊放大圖像)

圖 22 機器請求數隨時間變化趨勢

實時請求狀態碼占比，如圖 23 所示

(點擊放大圖像)

圖 23 實時請求狀態碼占比

實時請求TOP排名，如圖 24 所示

(點擊放大圖像)

圖 24 實時請求TOP排名

實時請求來源IP TOP排名，如圖 25 所示

(點擊放大圖像)

圖 25 實時請求來源IP TOP排名

響應時間隨時間變化趨勢圖，如圖 26 所示

(點擊放大圖像)

圖 26 響應時間隨時間變化趨勢圖

實時用戶請求的客戶端TOP排名，如圖 27 所示

(點擊放大圖像)

圖 27 實時用戶請求的客戶端TOP排名

實時根據不同情況進行具體數據的查詢，包括狀態碼、響應時間范圍進行篩選等，如圖 28 所示

(點擊放大圖像)

圖 28 實時根據不同情況進行具體數據的查詢

其他更多自定義配置...

自定義的 Grafana DashBoard 配置示例，如圖 29 所示

(點擊放大圖像)

圖 29 Grafana DashBoard配置示例

可見，僅僅幾步簡單的操作，你就借助Pandora實現了海量日志的實時監控，通過 nginx日志完整而詳盡的了解業務的流量入口的各類情況。

4.2 實時數據報警

有了實時的數據監控，怎么能少得了報警呢，我們還提供了包括 Slack， Email郵箱，Webhook等十來種報警方式。

比如說如圖 30 ，我們設置了一個響應時間大于1000ms的報警

(點擊放大圖像)

圖 30 響應時間大于1000ms報警

LogDB采用的是基于Elasticsearch協議的報警，這個基于Elasticsearch協議的Grafana報警功能是七牛獨家哦！TSDB是基于InfluDB協議，使用TSDB更是同樣具備上述功能。

那么您可以看到報警形式是怎么樣的呢？

(點擊放大圖像)

圖 31 Slack報警示意圖

看到圖 31 Slack上的報警了嗎？除了基本的文字，還會帶上酷炫的報警圖片！圖片都會被存儲到您七牛云存儲的bucket里面！

(點擊放大圖像)

圖 32 郵件報警示意圖

如圖 32 所示，常規的郵件報警內容也一樣酷炫！

4.3 離線分析

如果你使用離線分析，那么可以獲得的內容就更多了，只要你數據擁有的維度，就可以統計出來，比如我們以CDN日志為例。

用戶地區分布，如圖 33 所示

(點擊放大圖像)

圖 33 用戶地區分布

用戶機型分布，如圖 34 所示

(點擊放大圖像)

圖 34 用戶機型分布述

活躍用戶數隨時間變化趨勢，如圖 35 所示

(點擊放大圖像)

圖 35 活躍用戶數隨時間變化趨勢

各類手機圖片下載數，如圖 36 所示

(點擊放大圖像)

圖 36 各類手機圖片下載數

不同時間平均下載速度，如圖 37 所示

(點擊放大圖像)

圖 37 不同時間平均下載速度

不同時間正常響應比重，如圖 38 所示

(點擊放大圖像)

圖 38 不同時間正常響應比重

查詢用戶系統分布，如圖 39 所示

(點擊放大圖像)

圖 39 查詢用戶系統分布

除了上述這些，還支持更細粒度的下鉆功能，可以全方位無死角分析你的海量數據。

5 總結

至此，本次的Pandora大數據平臺的架構演進與使用實戰算是介紹完了，但是我們Pandora大數據產品的迭代還在不斷向前，還有大量大數據平臺建設的細節等待我們去完善。歡迎廣大朋友來使用我們Pandora的大數據產品，同時也歡迎給我們提提建議，我們非常愿意傾聽您的觀點！