千億級數量下日誌分析系統的技術架構選型

隨着數據已經逐步成爲一個公司寶貴的財富，大數據團隊在公司每每會承擔更加劇要的角色。大數據團隊每每要承擔數據平臺維護、數據產品開發、從數據產品中挖掘業務價值等重要的職責。因此對於不少大數據工程師，如何根據業務需求去選擇合適的大數據組件，作合適的大數據架構工做就是平常工做中最常遇到的問題。在這裏根據七牛雲在日增千億級的日誌分析工做，和你們分享一下大數據技術架構選型的一些經驗。

大數據架構師在關注什麼

在一個大數據團隊中，大數據架構師主要關注的核心問題就是技術架構選型問題。架構選型問題通常會受到哪些因素的影響呢？在咱們的實踐中，通常大數據領域架構選型最受如下幾個因素影響：

數據量級

這一點在大數據領域尤爲是一個重要的因素。不過從根本上講，數據量級自己也是一種業務場景的衡量。數據量級的不一樣每每也就昭示着業務場景的不一樣。

業務需求

經驗豐富的大數據架構師可以從紛繁的業務需求中提煉出核心技術點，根據抽象的技術點選擇合適的技術架構。主要的業務需求可能包括：應用實時性要求、查詢的維度和靈活程度、多租戶、安全審計需求等等。

維護成本

這一點上大數據架構師一方面要可以清楚的瞭解各類大數據技術棧的優劣勢，在知足業務需求的要求下，可以充分的優化架構，合理的架構可以下降維護的成本，提高開發的效率。

另外一方面， 大數據架構師要能清楚的瞭解本身團隊成員，能瞭解其餘同窗的技術專長和品位，可以保證本身作的技術架構能夠獲得承認和理解，也能獲得最好的維護和發展。

接下來咱們會圍繞這幾個方面去看看，作一個最適合本身團隊業務的架構選型會如何受到這些因素的影響？

技術架構選型

業務需求是五花八門的，每每影響咱們作技術選型的不是種種需求的細節，而是通過提煉後的一些具體的場景。就比如，業務需求提出咱們要作一個日誌分析系統，或者要作一個用戶行爲分析系統，這些具體需求背後咱們要關注哪些具體的點？這是一個頗有趣的問題，咱們在作大數據的過程當中，常發現咱們對這些需求的疑問不少時候會落在如下幾個問題上。

其中數據量級做爲一個重要的因素影響着咱們對於技術選型的決定，另外在數據量的變化以外各類業務場景的須要也會影響咱們對技術組件的選擇。

數據量級

如同咱們上文中提到的，數據量級這個指標是一個特殊的業務場景的衡量，也是在大數據應用中影響最大的一個因素。每每對應不一樣的數據量級的業務，咱們會有不一樣的考慮方式。

通常數據量級在 10GB 左右，數據總條數在千萬量級的數據，這種數據每每是業務最核心的數據，如用戶信息庫等。這種數據量因爲其核心的業務價值，每每要求強一致性和實時性。在這種量級上，傳統關係型數據庫如 MySQL 等都能很好的解決各類業務需求。固然若是面對關係型數據庫難以解決的問題，好比全文索引等的時候，架構師仍是須要根據業務需求選擇 Solr 或者 Elasticsearch 等搜索引擎解決此類問題。

若是數據量級增加到 1 億到 10 億級別的時候，通常來講這個階段就會面臨一個選擇，是採用傳統的 RDBMS+ 合理的索引+分庫分表等各類策略呢？仍是應該選擇一些諸如 SQL On Hadoop 或者 HTAP、OLAP 組件呢？這時候靈活性其實仍是相對比較大的，通常咱們經驗是，若是團隊內有數據庫及中間件方向的專家工程師，但願保持架構簡單性，能夠選擇繼續使用傳統關係型數據。可是若是爲了對將來業務有更高的擴展性，可以在可見的時間內支撐起更普遍的業務需求，仍是建議選擇使用大數據組件。

當數據量已經增加到 10 億到百億級別，特別是 10TB 以上了以後，每每咱們傳統的關係型數據庫基本就已經被咱們排除在可選的技術架構以外了。這時候經常要結合各類業務場景去選擇具體的場景的技術組件，好比咱們要仔細審視，咱們的業務場景是不是須要大量的更新操做？是否須要隨機讀寫能力？是否須要全文索引？

以上是一些主流的分析型引擎在各個數據量級下大體的表現結果，這個圖表中的數據僅僅是在大部分場景下的通常表現狀況（並不是精確測試結果，僅供參考）。不過值得注意的是，雖然看起來咱們老是但願響應時間越少越好，數據量級越高越好，但要知道大數據領域並無銀彈，可以解決全部的問題。每一個技術組件都是犧牲了部分場景，才能在本身的領域中保持優點。

實時性

實時性是一個如此重要的因素，因此咱們在一開始就必需要重點的考慮業務需求中對實時性的要求。業務中的實時性每每包含兩方面的含義：

一方面，實時性體如今數據攝入的實時性上，數據攝入的實時性指的是當業務數據發生變化時候，咱們的大數據應用能接受多少的延遲能看到這個數據？從理想狀況上來講，固然業務上不管如何都是但願系統越實時越好，可是從成本和技術上兩方面去考量這個問題，咱們通常分爲實時系統（毫秒延遲）、近實時系統（秒級延遲）、準實時系統（分鐘級延遲）和離線系統（小時級或者天延遲）。通常延遲時間和吞吐能力，和計算能力都是反比的，吞吐越強，計算越精確，延遲時間會更長。

另外一方面，實時性也體如今查詢的延遲上面，這個延遲計算的是，用戶發出查詢請求以後，要等待多長時間，服務端可以返回計算結果。這個大部分狀況下決定於產品的具體形態，若是這個產品是要給終端用戶進行展現，好比風雲榜、熱搜榜、推薦商品等統計類產品，是要有很高的 QPS 需求的產品，必然會須要將延遲控制在亞秒級。在另外一種場景下，若是一個產品是給數據分析師，或者運營人員進行數據探索使用，每每這時候會通過大規模且不可控制的計算，這時候可能更適合於一種離線任務的模式，用戶的忍耐程度也會更高，支持分鐘級甚至小時級別的數據輸出。

能夠從這個圖中看出，通常在實時領域會選擇 HBase，Cassandra 這種能支持事務同時支持高更新吞吐量的技術組件，或者也能夠選擇 TiDB、Spanner、Kudu 等這種 HTAP 組件，同時支持事務和分析的分佈式數據庫。

若是追求更高的分析性能，能夠選擇專業的 OLAP（On-Line Analytical Processing）組件，如 Kylin  或者 Druid，他們屬於 MOLAP （Multi-dimensional OLAP），支持提早建立數據立方，對指標進行預聚合，雖然犧牲必定的查詢靈活程度，可是保證了查詢實時性。

而 Elastic Search 是相對最爲靈活的一個 NoSQL 查詢引擎，一方面它支持全文索引，這個是其餘引擎所不具有的。另外它也支持少許的更新，支持聚合分析，也支持明細數據的搜索查詢，在近實時領域適用場景很是的多。不過因爲 ES 是基於 Lucene 的存儲引擎，相對須要資源成本會更高，並且分析性能對比其餘引擎不具有優點。

另外，若是咱們的數據是離線或者追加的方式進行歸檔，同時產品形態須要依賴大批量數據的運算。這種產品每每能夠忍受較高的查詢延遲，那麼 Hadoop 生態的一系列產品會很是適合這個領域，好比新一代的 MapReduce 計算引擎 Spark，另一系列 SQL On Hadoop 的組件，Drill，Impala，Presto 等各有各自的優勢，咱們能夠結合其餘業務需求來選型。

計算維度/靈活度

計算維度和計算靈活度，這兩個因素是對計算選型很重要的因素。試想一下，若是咱們的產品只產出固定的若干指標項，咱們徹底可使用 Spark 離線計算將數據結果導入到 MySQL 等業務數據庫中，做爲結果集提供展現服務。

但當若是咱們的查詢是一個交互式的，若是用戶可以本身選擇維度進行數據聚合，咱們沒法將全部維度的排列組合都預計算出來，那這時候咱們可能就須要的是一個 OLAP 組件，須要可以根據指定維度作指標預聚合，這種選型能加強結果展現的靈活度，也能大大下降查詢的延遲。

更深一步，用戶若是不只僅可以對數據指標進行計算，同時要可以查詢到原始的明細數據，這時候可能 OLAP 組件再也不適用，那麼可能就須要到 ES 或者 SQL On Hadoop 這樣更加靈活的組件。這時候若是有全文搜索需求，那麼就選擇 ES，若是沒有就選擇 SQL On Hadoop。

多租戶

多租戶需求也是一個大數據架構師常常須要考慮到的問題，多租戶的需求每每是來源於許多不一樣的使用方，這種需求對於一個公司的基礎架構部門很是常見。

多租戶要考慮哪些呢？

第一是資源的隔離性，從資源節省的角度來看，確定是不一樣租戶之間資源能夠共享的話，資源能夠充分的利用起來。這也是咱們通常作基礎架構部門最但願作的工做。不過對於不少租戶來講，可能業務級別更高，或者數據量更加的龐大，若是和普通的租戶一塊兒共享資源可能會形成資源爭搶。這時候就要考慮物理資源的隔離。

第二，就要考慮用戶安全。一方面是要作認證，須要杜絕惡意或者越權訪問數據的事情發生。另外一方面要作好安全審計，每次敏感操做要記錄審計日誌，可以追溯到每次行爲的來源 IP 和操做用戶。

第三但也是最重要的一點，就是數據權限。多租戶系統並不只僅意味着隔離，更加意味着資源可以更加合理有效的獲得共享和利用。如今數據權限每每不能侷限於一個文件、一個倉庫的讀寫權限。更多的時候咱們可能要對某個數據子集，某些數據字段進行數據受權，這樣每一個數據全部者可以將本身的資源更加安全的分發給須要的租戶。將數據可以更加高效的利用起來，這也是一個數據平臺/應用重要的使命。

維護成本

對於架構師而言大數據平臺的維護成本是一個相當重要的指標，經驗豐富的架構師可以結合自身團隊的特色選擇合適的技術方案。

從上圖能夠看出大數據平臺能夠根據服務依賴（是依賴雲服務仍是自建大數據平臺）和技術組件的複雜度分爲四個象限。

• 使用成本和技術組件複雜度成正比，通常來講組件複雜度越高，組件數量越多，多種組件配合使用成本會越高。

• 維護成本和服務供應商以及組件複雜度都有關係，通常來講，單一的技術組件要比複雜的技術組件維護成本低，雲服務提供的技術組件要比自建大數據組件維護成本要更低。

• 團隊要求來講，通常來講與使用成本趨同，都是技術組件越複雜，團隊要求越高。不過另外一方面團隊要求與服務供應商也存在關係，若是雲服務廠商可以承擔起組件的運維工做，其實是能夠幫助業務團隊從運維工做中解放出更多的工程師，參與到大數據應用的工做中。

因此通常來講，架構師對於技術選型的偏好應該是，在知足業務需求和數據量需求的前提下，選擇技術架構最簡單的，由於每每這種選型是最容易使用和維護的。在這個基礎上，若是有一支很是強大的技術開發和運維團隊，能夠選擇自建大數據平臺；若是缺少足夠的運維、開發支撐，那麼建議選擇雲服務平臺來支撐業務。

七牛雲是如何作架構選型的

七牛雲的大數據團隊叫作 Pandora，這隻團隊的主要工做就是負責七牛雲內的大數據平臺需求的支撐工做，另外也負責將大數據平臺產品化，提供給外部客戶專業的大數據服務。能夠說七牛雲就是 Pandora 的第一個客戶，咱們不少技術選型經驗也是在承載公司內部各類需求積累起來的。

七牛雲的特點和業務挑戰

簡單的介紹下咱們在七牛雲場景下面臨的各類挑戰。七牛雲除了 Pandora 以外還有六個產品團隊，包括雲存儲、直播雲、CDN、智能多媒體 API 服務以及容器雲團隊。全部產品團隊所產生的業務數據和日誌數據都要經過 Pandora 自研的收集工具 logkit（專業版）收集到 Pandora 的統一日誌存儲中來。然後各個部門都利用這部分的數據作各類數據應用。

首先商業運營部門是揹負了七牛雲整個營收和增加的重要使命的團隊，須要各個團隊收集起來的埋點和日誌數據，製做統一的用戶視圖，基於此製做用戶畫像。爲客戶提供更加貼身的運營服務，提高客戶的滿意度。

另外 SRE 團隊，須要對線上系統作深刻的性能追蹤，這邊須要咱們提供 OpenTracing 接口的支持，在七牛雲技術棧相對統一的環境下，咱們很方便地支持全鏈路監控，由此 SRE 部門不依賴於研發團隊埋點便可以對線上的服務性能進行追蹤監控，更易得知服務哪裏出現問題。

產品研發這邊提出了須要全文索引的需求，在每日近百 TB 的日誌中須要可以根據關鍵詞快速定位日誌數據，同時可以查詢日誌上下文。不只如此，還須要可以解析出 APP 日誌中的關鍵字段，好比用戶 id 和響應時間、下載流量等，可以作用戶級別的運維指標監控，可以更加精準的爲客戶服務。

固然不管是哪個業務部門提出的需求，他們都須要有優秀靈活的報表展現系統，可以支撐業務作分析、探索和決策。基於合理的架構要能支撐複雜的業務報表和 BI 需求。

在七牛雲的架構落地

綜合考慮了各方的產品需求，咱們作了以下的產品設計：

咱們首先自研了 logkit 專業版，用來專業收集、同步各類開源項目或者日誌文件的數據。另外設計了一套數據總線 Pipeline，結合了七牛雲的數據吞吐量超大，但延遲能夠接受到秒級的延遲的特色。這裏咱們採用了多 Kafka 集羣 + Spark Streaming，自研了流量調度系統，能夠將數據高效的導出到下游的統一日誌存儲產品中，同時使用 Spark Streaming 能夠輕易的完成日誌解析，字段提取等工做。

統一日誌存儲這裏咱們支持了自研和各類第三方的圖表展現系統。後端數據系統咱們採用的是混合架構模式，這裏主體包含了三個基礎產品。

日誌分析平臺

基於七牛雲定製版本的 ES，構建日誌存儲和索引系統，可以在吞吐量 100w/s  的狀況下集羣依然保證十億級別數據搜索秒級返回。

數據立方

基於定製版 Druid 構建了數據立方這一個 OLAP 產品，面向多租戶的高性能查詢，爲最大的客戶每日 30TB+ 原始數據提供毫秒級的聚合分析。

離線工做流

基於存儲和 Spark 工做流平臺提供離線數據計算的能力，能夠處理 PB 級數據的大規模計算和分析加工。

架構優點

在踐行了這些大數據實踐以後，Pandora 爲內外部用戶帶來了一個怎樣的產品呢。咱們經過與業界優秀的商業和開源產品作比對，得出七牛雲有如下的幾個優點：

完善的多租戶支持

在多租戶資源隔離這塊，Pandora 作了多個級別的隔離支持。包括低級別的命名空間隔離，這時候咱們會經過限制用戶使用 CPU、內存等各類共享資源，保證全部客戶都能安全使用集羣。更多地，爲了知足更多客戶定製化需求，咱們也利用多集羣動態擴容方式支持租戶之間的空間隔離，用戶可使用獨立的資源。

另外，在多租戶場景中很重要的安全、權限和審計，咱們也作了長足的工做。數據咱們能夠按照數據子集和字段的粒度作權限管理，將數據受權給其餘租戶。同時咱們會對數據的每一次操做記錄審計，精確到來源 IP 和操做人員，保證雲服務的數據安全性。

支撐豐富的業務場景

在 Pandora 基於日誌領域的大數據平臺上，咱們支持實時和離線兩種計算模型，使用工做流界面能夠簡潔方便的操做各類大數據流。使用日誌分析和數據立方等產品和工具，能夠支持各類業務場景。包括但不限於：

• 用戶行爲分析

• 應用性能監控

• 系統設備性能監控

• 非侵入式埋點，支持全鏈路追蹤系統，發現分佈式系統應用瓶頸

• IoT 設備數據分析和監控

• 安全、審計和監控

• 機器學習，自動系統異常探測和歸因分析

公有云超大規模數據驗證

咱們在公有云已經服務了超過 200 家指名客戶，天天有超過 250TB 的數據流入，天天約 3650 億條數據。每日參與計算和分析的數據量已經超過 3.2PB。超大的公有云規模，驗證 Pandora 大數據日誌分析平臺能夠爲客戶提供穩定的計算平臺，提供良好的業務支撐。

用戶享受最低運維成本

Pandora 的產品的設計哲學認爲，雲服務應該是一個一體化的產品。因此對於客戶來講，Pandora 雖然適配了大量的應用場景，可是仍然只是一個單一的產品組件，因此對於採用七牛雲大數據服務的客戶來講運維成本是最低的，僅僅須要一個開發團隊就能夠照顧到數據開發和運維的方方面面，對於快速的業務迭代和增加來講提供了巨大的便利性。

以上就是結合 Pandora 的實踐和你們分享的一些經驗。七牛雲智能日誌管理平臺致力於下降用戶的心智負擔，幫助客戶數字化升級。歡迎點擊「閱讀原文」即刻了解產品詳情和免費額度政策：

• 新增日誌數據 1 GB/月

• 存量日誌數據 1 GB/月

• 日誌倉庫 1 個/月

• API 調用次數 100 萬次/月

歡迎你們註冊體驗。

 文檔站地址：

https://pandora-docs.qiniu.com

牛人說

「牛人說」專欄致力於技術人思想的發現，其中包括技術實踐、技術乾貨、技術看法、成長心得，還有一切值得被發現的內容。咱們但願集合最優秀的技術人，挖掘獨到、犀利、具備時代感的聲音。