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

?
?

隨著數據已經逐步成為一個公司寶貴的財富，大數據團隊在公司往往會承擔更加重要的角色。大數據團隊往往要承擔數據平臺維護、數據產品開發、從數據產品中挖掘業務價值等重要的職責。所以對于很多大數據工程師，如何根據業務需求去選擇合適的大數據組件，做合適的大數據架構工作就是日常工作中最常遇到的問題。在這里根據七牛云在日增千億級的日志分析工作，和大家分享一下大數據技術架構選型的一些經驗。
?

大數據架構師在關注什么

?
在一個大數據團隊中，大數據架構師主要關注的核心問題就是技術架構選型問題。架構選型問題一般會受到哪些因素的影響呢？在我們的實踐中，一般大數據領域架構選型最受以下幾個因素影響：?
?
?
?
?
?
數據量級
這一點在大數據領域尤其是一個重要的因素。不過從根本上講，數據量級本身也是一種業務場景的衡量。數據量級的不同往往也就昭示著業務場景的不同。
?
?
業務需求
經驗豐富的大數據架構師能夠從紛繁的業務需求中提煉出核心技術點，根據抽象的技術點選擇合適的技術架構。主要的業務需求可能包括：應用實時性要求、查詢的維度和靈活程度、多租戶、安全審計需求等等。
?
?
維護成本
這一點上大數據架構師一方面要能夠清楚的了解各種大數據技術棧的優劣勢，在滿足業務需求的要求下，能夠充分的優化架構，合理的架構能夠降低維護的成本，提升開發的效率。
?
另一方面， 大數據架構師要能清楚的了解自己團隊成員，能了解其他同學的技術專長和品位，能夠保證自己做的技術架構可以得到認可和理解，也能得到最好的維護和發展。
?
接下來我們會圍繞這幾個方面去看看，做一個最適合自己團隊業務的架構選型會如何受到這些因素的影響？
?

技術架構選型

?
業務需求是五花八門的，往往影響我們做技術選型的不是種種需求的細節，而是經過提煉后的一些具體的場景。就好比，業務需求提出我們要做一個日志分析系統，或者要做一個用戶行為分析系統，這些具體需求背后我們要關注哪些具體的點？這是一個很有趣的問題，我們在做大數據的過程中，常發現我們對這些需求的疑問很多時候會落在以下幾個問題上。?
?
?
?
其中數據量級作為一個重要的因素影響著我們對于技術選型的決定，另外在數據量的變化之外各種業務場景的需要也會影響我們對技術組件的選擇。?
?
?
數據量級
?
如同我們上文中提到的，數據量級這個指標是一個特殊的業務場景的衡量，也是在大數據應用中影響最大的一個因素。往往對應不同的數據量級的業務，我們會有不同的考慮方式。
?
一般數據量級在 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 的實踐和大家分享的一些經驗。

牛人說?

?
「牛人說」專欄致力于技術人思想的發現，其中包括技術實踐、技術干貨、技術見解、成長心得，還有一切值得被發現的內容。我們希望集合最優秀的技術人，挖掘獨到、犀利、具有時代感的聲音。
?

?
?