隨著資料已經逐步成為一個公司寶貴的財富，大資料團隊在公司往往會承擔更加重要的角色。大資料團隊往往要承擔資料平臺維護、資料產品開發、從資料產品中挖掘業務價值等重要的職責。所以對於很多大資料工程師，如何根據業務需求去選擇合適的大資料元件，做合適的大資料架構工作就是日常工作中最常遇到的問題。在這裡根據七牛雲在日增千億級的日誌分析工作，和大家分享一下大資料技術架構選型的一些經驗。
大資料架構師在關注什麼
在一個大資料團隊中，大資料架構師主要關注的核心問題就是技術架構選型問題。架構選型問題一般會受到哪些因素的影響呢？在我們的實踐中，一般大資料領域架構選型最受以下幾個因素影響：

資料量級 這一點在大資料領域尤其是一個重要的因素。不過從根本上講，資料量級本身也是一種業務場景的衡量。資料量級的不同往往也就昭示著業務場景的不同。
業務需求 經驗豐富的大資料架構師能夠從紛繁的業務需求中提煉出核心技術點，根據抽象的技術點選擇合適的技術架構。主要的業務需求可能包括：應用實時性要求、查詢的維度和靈活程度、多租戶、安全審計需求等等。
維護成本 這一點上大資料架構師一方面要能夠清楚的瞭解各種大資料技術棧的優劣勢，在滿足業務需求的要求下，能夠充分的優化架構，合理的架構能夠降低維護的成本，提升開發的效率。
另一方面， 大資料架構師要能清楚的瞭解自己團隊成員，能瞭解其他同學的技術專長和品位，能夠保證自己做的技術架構可以得到認可和理解，也能得到最好的維護和發展。
接下來我們會圍繞這幾個方面去看看，做一個最適合自己團隊業務的架構選型會如何受到這些因素的影響？
技術架構選型
業務需求是五花八門的，往往影響我們做技術選型的不是種種需求的細節，而是經過提煉後的一些具體的場景。就好比，業務需求提出我們要做一個日誌分析系統，或者要做一個使用者行為分析系統，這些具體需求背後我們要關注哪些具體的點？這是一個很有趣的問題，我們在做大資料的過程中，常發現我們對這些需求的疑問很多時候會落在以下幾個問題上。
其中資料量級作為一個重要的因素影響著我們對於技術選型的決定，另外在資料量的變化之外各種業務場景的需要也會影響我們對技術元件的選擇。
資料量級 如同我們上文中提到的，資料量級這個指標是一個特殊的業務場景的衡量，也是在大資料應用中影響最大的一個因素。往往對應不同的資料量級的業務，我們會有不同的考慮方式。
一般資料量級在 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 萬次/月
歡迎大家註冊體驗。
文件站地址： pandora-docs.qiniu.com
牛人說
「牛人說」專欄致力於技術人思想的發現，其中包括技術實踐、技術乾貨、技術見解、成長心得，還有一切值得被發現的內容。我們希望集合最優秀的技術人，挖掘獨到、犀利、具有時代感的聲音。
    點選「閱讀原文」 免費開通七牛雲智慧日誌管理平臺