數(shù)據(jù)量級(jí)

這一點(diǎn)在大數(shù)據(jù)領(lǐng)域尤其是一個(gè)重要的因素。不過從根本上講，數(shù)據(jù)量級(jí)本身也是一種業(yè)務(wù)場景的衡量。數(shù)據(jù)量級(jí)的不同往往也就昭示著業(yè)務(wù)場景的不同。

業(yè)務(wù)需求

經(jīng)驗(yàn)豐富的大數(shù)據(jù)架構(gòu)師能夠從紛繁的業(yè)務(wù)需求中提煉出核心技術(shù)點(diǎn)，根據(jù)抽象的技術(shù)點(diǎn)選擇合適的技術(shù)架構(gòu)。主要的業(yè)務(wù)需求可能包括：應(yīng)用實(shí)時(shí)性要求、查詢的維度和靈活程度、多租戶、安全審計(jì)需求等等。

維護(hù)成本

這一點(diǎn)上大數(shù)據(jù)架構(gòu)師一方面要能夠清楚的了解各種大數(shù)據(jù)技術(shù)棧的優(yōu)劣勢，在滿足業(yè)務(wù)需求的要求下，能夠充分的優(yōu)化架構(gòu)，合理的架構(gòu)能夠降低維護(hù)的成本，提升開發(fā)的效率。

另一方面， 大數(shù)據(jù)架構(gòu)師要能清楚的了解自己團(tuán)隊(duì)成員，能了解其他同學(xué)的技術(shù)專長和品位，能夠保證自己做的技術(shù)架構(gòu)可以得到認(rèn)可和理解，也能得到最好的維護(hù)和發(fā)展。

接下來我們會(huì)圍繞這幾個(gè)方面去看看，做一個(gè)最適合自己團(tuán)隊(duì)業(yè)務(wù)的架構(gòu)選型會(huì)如何受到這些因素的影響？

技術(shù)架構(gòu)選型

業(yè)務(wù)需求是五花八門的，往往影響我們做技術(shù)選型的不是種種需求的細(xì)節(jié)，而是經(jīng)過提煉后的一些具體的場景。就好比，業(yè)務(wù)需求提出我們要做一個(gè)日志分析系統(tǒng)，或者要做一個(gè)用戶行為分析系統(tǒng)，這些具體需求背后我們要關(guān)注哪些具體的點(diǎn)？這是一個(gè)很有趣的問題，我們在做大數(shù)據(jù)的過程中，常發(fā)現(xiàn)我們對(duì)這些需求的疑問很多時(shí)候會(huì)落在以下幾個(gè)問題上。

其中數(shù)據(jù)量級(jí)作為一個(gè)重要的因素影響著我們對(duì)于技術(shù)選型的決定，另外在數(shù)據(jù)量的變化之外各種業(yè)務(wù)場景的需要也會(huì)影響我們對(duì)技術(shù)組件的選擇。

數(shù)據(jù)量級(jí)

如同我們上文中提到的，數(shù)據(jù)量級(jí)這個(gè)指標(biāo)是一個(gè)特殊的業(yè)務(wù)場景的衡量，也是在大數(shù)據(jù)應(yīng)用中影響最大的一個(gè)因素。往往對(duì)應(yīng)不同的數(shù)據(jù)量級(jí)的業(yè)務(wù)，我們會(huì)有不同的考慮方式。

一般數(shù)據(jù)量級(jí)在 10GB 左右，數(shù)據(jù)總條數(shù)在千萬量級(jí)的數(shù)據(jù)，這種數(shù)據(jù)往往是業(yè)務(wù)最核心的數(shù)據(jù)，如用戶信息庫等。這種數(shù)據(jù)量由于其核心的業(yè)務(wù)價(jià)值，往往要求強(qiáng)一致性和實(shí)時(shí)性。在這種量級(jí)上，傳統(tǒng)關(guān)系型數(shù)據(jù)庫如 MySQL 等都能很好的解決各種業(yè)務(wù)需求。當(dāng)然如果面對(duì)關(guān)系型數(shù)據(jù)庫難以解決的問題，比如全文索引等的時(shí)候，架構(gòu)師還是需要根據(jù)業(yè)務(wù)需求選擇 Solr 或者 Elasticsearch 等搜索引擎解決此類問題。

如果數(shù)據(jù)量級(jí)增長到 1 億到 10 億級(jí)別的時(shí)候，一般來說這個(gè)階段就會(huì)面臨一個(gè)選擇，是采用傳統(tǒng)的 RDBMS+ 合理的索引+分庫分表等各種策略呢？還是應(yīng)該選擇一些諸如 SQL On Hadoop 或者 HTAP、OLAP 組件呢？這時(shí)候靈活性其實(shí)還是相對(duì)比較大的，一般我們經(jīng)驗(yàn)是，如果團(tuán)隊(duì)內(nèi)有數(shù)據(jù)庫及中間件方向的專家工程師，希望保持架構(gòu)簡單性，可以選擇繼續(xù)使用傳統(tǒng)關(guān)系型數(shù)據(jù)。但是如果為了對(duì)未來業(yè)務(wù)有更高的擴(kuò)展性，能夠在可見的時(shí)間內(nèi)支撐起更廣泛的業(yè)務(wù)需求，還是建議選擇使用大數(shù)據(jù)組件。

當(dāng)數(shù)據(jù)量已經(jīng)增長到 10 億到百億級(jí)別，特別是 10TB 以上了之后，往往我們傳統(tǒng)的關(guān)系型數(shù)據(jù)庫基本就已經(jīng)被我們排除在可選的技術(shù)架構(gòu)之外了。這時(shí)候常常要結(jié)合各種業(yè)務(wù)場景去選擇具體的場景的技術(shù)組件，比如我們要仔細(xì)審視，我們的業(yè)務(wù)場景是否是需要大量的更新操作？是否需要隨機(jī)讀寫能力？是否需要全文索引？

以上是一些主流的分析型引擎在各個(gè)數(shù)據(jù)量級(jí)下大致的表現(xiàn)結(jié)果，這個(gè)圖表中的數(shù)據(jù)僅僅是在大部分場景下的一般表現(xiàn)情況（并非精確測試結(jié)果，僅供參考）。不過值得注意的是，雖然看起來我們總是希望響應(yīng)時(shí)間越少越好，數(shù)據(jù)量級(jí)越高越好，但要知道大數(shù)據(jù)領(lǐng)域并沒有銀彈，能夠解決所有的問題。每個(gè)技術(shù)組件都是犧牲了部分場景，才能在自己的領(lǐng)域中保持優(yōu)勢。

實(shí)時(shí)性

實(shí)時(shí)性是一個(gè)如此重要的因素，所以我們在一開始就必須要重點(diǎn)的考慮業(yè)務(wù)需求中對(duì)實(shí)時(shí)性的要求。業(yè)務(wù)中的實(shí)時(shí)性往往包含兩方面的含義：

一方面，實(shí)時(shí)性體現(xiàn)在數(shù)據(jù)攝入的實(shí)時(shí)性上，數(shù)據(jù)攝入的實(shí)時(shí)性指的是當(dāng)業(yè)務(wù)數(shù)據(jù)發(fā)生變化時(shí)候，我們的大數(shù)據(jù)應(yīng)用能接受多少的延遲能看到這個(gè)數(shù)據(jù)？從理想情況上來說，當(dāng)然業(yè)務(wù)上無論如何都是希望系統(tǒng)越實(shí)時(shí)越好，但是從成本和技術(shù)上兩方面去考量這個(gè)問題，我們一般分為實(shí)時(shí)系統(tǒng)（毫秒延遲）、近實(shí)時(shí)系統(tǒng)（秒級(jí)延遲）、準(zhǔn)實(shí)時(shí)系統(tǒng)（分鐘級(jí)延遲）和離線系統(tǒng)（小時(shí)級(jí)或者天延遲）。一般延遲時(shí)間和吞吐能力，和計(jì)算能力都是反比的，吞吐越強(qiáng)，計(jì)算越精確，延遲時(shí)間會(huì)更長。

另一方面，實(shí)時(shí)性也體現(xiàn)在查詢的延遲上面，這個(gè)延遲計(jì)算的是，用戶發(fā)出查詢請求之后，要等待多長時(shí)間，服務(wù)端能夠返回計(jì)算結(jié)果。這個(gè)大部分情況下決定于產(chǎn)品的具體形態(tài)，如果這個(gè)產(chǎn)品是要給終端用戶進(jìn)行展示，比如風(fēng)云榜、熱搜榜、推薦商品等統(tǒng)計(jì)類產(chǎn)品，是要有很高的 QPS 需求的產(chǎn)品，必然會(huì)需要將延遲控制在亞秒級(jí)。在另一種場景下，如果一個(gè)產(chǎn)品是給數(shù)據(jù)分析師，或者運(yùn)營人員進(jìn)行數(shù)據(jù)探索使用，往往這時(shí)候會(huì)經(jīng)過大規(guī)模且不可控制的計(jì)算，這時(shí)候可能更適合于一種離線任務(wù)的模式，用戶的忍耐程度也會(huì)更高，支持分鐘級(jí)甚至小時(shí)級(jí)別的數(shù)據(jù)輸出。

可以從這個(gè)圖中看出，一般在實(shí)時(shí)領(lǐng)域會(huì)選擇 HBase，Cassandra 這種能支持事務(wù)同時(shí)支持高更新吞吐量的技術(shù)組件，或者也可以選擇 TiDB、Spanner、Kudu 等這種 HTAP 組件，同時(shí)支持事務(wù)和分析的分布式數(shù)據(jù)庫。

如果追求更高的分析性能，可以選擇專業(yè)的 OLAP（On-Line Analytical Processing）組件，如 Kylin  或者 Druid，他們屬于 MOLAP （Multi-dimensional OLAP），支持提前創(chuàng)建數(shù)據(jù)立方，對(duì)指標(biāo)進(jìn)行預(yù)聚合，雖然犧牲一定的查詢靈活程度，但是保證了查詢實(shí)時(shí)性。

而 Elastic Search 是相對(duì)最為靈活的一個(gè) NoSQL 查詢引擎，一方面它支持全文索引，這個(gè)是其他引擎所不具備的。另外它也支持少量的更新，支持聚合分析，也支持明細(xì)數(shù)據(jù)的搜索查詢，在近實(shí)時(shí)領(lǐng)域適用場景非常的多。不過由于 ES 是基于 Lucene 的存儲(chǔ)引擎，相對(duì)需要資源成本會(huì)更高，而且分析性能對(duì)比其他引擎不具備優(yōu)勢。

另外，如果我們的數(shù)據(jù)是離線或者追加的方式進(jìn)行歸檔，同時(shí)產(chǎn)品形態(tài)需要依賴大批量數(shù)據(jù)的運(yùn)算。這種產(chǎn)品往往可以忍受較高的查詢延遲，那么 Hadoop 生態(tài)的一系列產(chǎn)品會(huì)非常適合這個(gè)領(lǐng)域，比如新一代的 MapReduce 計(jì)算引擎 Spark，另外一系列 SQL On Hadoop 的組件，Drill，Impala，Presto 等各有各自的優(yōu)點(diǎn)，我們可以結(jié)合其他業(yè)務(wù)需求來選型。

計(jì)算維度/靈活度

計(jì)算維度和計(jì)算靈活度，這兩個(gè)因素是對(duì)計(jì)算選型很重要的因素。試想一下，如果我們的產(chǎn)品只產(chǎn)出固定的若干指標(biāo)項(xiàng)，我們完全可以使用 Spark 離線計(jì)算將數(shù)據(jù)結(jié)果導(dǎo)入到 MySQL 等業(yè)務(wù)數(shù)據(jù)庫中，作為結(jié)果集提供展示服務(wù)。

但當(dāng)如果我們的查詢是一個(gè)交互式的，如果用戶能夠自己選擇維度進(jìn)行數(shù)據(jù)聚合，我們無法將所有維度的排列組合都預(yù)計(jì)算出來，那這時(shí)候我們可能就需要的是一個(gè) OLAP 組件，需要能夠根據(jù)指定維度做指標(biāo)預(yù)聚合，這種選型能增強(qiáng)結(jié)果展示的靈活度，也能大大降低查詢的延遲。

更深一步，用戶如果不僅僅能夠?qū)?shù)據(jù)指標(biāo)進(jìn)行計(jì)算，同時(shí)要能夠查詢到原始的明細(xì)數(shù)據(jù)，這時(shí)候可能 OLAP 組件不再適用，那么可能就需要到 ES 或者 SQL On Hadoop 這樣更加靈活的組件。這時(shí)候如果有全文搜索需求，那么就選擇 ES，如果沒有就選擇 SQL On Hadoop。

多租戶

多租戶需求也是一個(gè)大數(shù)據(jù)架構(gòu)師經(jīng)常需要考慮到的問題，多租戶的需求往往是來源于許多不同的使用方，這種需求對(duì)于一個(gè)公司的基礎(chǔ)架構(gòu)部門非常常見。

多租戶要考慮哪些呢？

第一是資源的隔離性，從資源節(jié)省的角度來看，肯定是不同租戶之間資源可以共享的話，資源可以充分的利用起來。這也是我們一般做基礎(chǔ)架構(gòu)部門最希望做的工作。不過對(duì)于很多租戶來說，可能業(yè)務(wù)級(jí)別更高，或者數(shù)據(jù)量更加的龐大，如果和普通的租戶一起共享資源可能會(huì)造成資源爭搶。這時(shí)候就要考慮物理資源的隔離。

第二，就要考慮用戶安全。一方面是要做認(rèn)證，需要杜絕惡意或者越權(quán)訪問數(shù)據(jù)的事情發(fā)生。另一方面要做好安全審計(jì)，每次敏感操作要記錄審計(jì)日志，能夠追溯到每次行為的來源 IP 和操作用戶。

第三但也是最重要的一點(diǎn)，就是數(shù)據(jù)權(quán)限。多租戶系統(tǒng)并不僅僅意味著隔離，更加意味著資源能夠更加合理有效的得到共享和利用?，F(xiàn)在數(shù)據(jù)權(quán)限往往不能局限于一個(gè)文件、一個(gè)倉庫的讀寫權(quán)限。更多的時(shí)候我們可能要對(duì)某個(gè)數(shù)據(jù)子集，某些數(shù)據(jù)字段進(jìn)行數(shù)據(jù)授權(quán)，這樣每個(gè)數(shù)據(jù)所有者能夠?qū)⒆约旱馁Y源更加安全的分發(fā)給需要的租戶。將數(shù)據(jù)能夠更加高效的利用起來，這也是一個(gè)數(shù)據(jù)平臺(tái)/應(yīng)用重要的使命。

維護(hù)成本

對(duì)于架構(gòu)師而言大數(shù)據(jù)平臺(tái)的維護(hù)成本是一個(gè)至關(guān)重要的指標(biāo)，經(jīng)驗(yàn)豐富的架構(gòu)師能夠結(jié)合自身團(tuán)隊(duì)的特點(diǎn)選擇合適的技術(shù)方案。

從上圖可以看出大數(shù)據(jù)平臺(tái)可以根據(jù)服務(wù)依賴（是依賴云服務(wù)還是自建大數(shù)據(jù)平臺(tái)）和技術(shù)組件的復(fù)雜度分為四個(gè)象限。

· 使用成本和技術(shù)組件復(fù)雜度成正比，一般來說組件復(fù)雜度越高，組件數(shù)量越多，多種組件配合使用成本會(huì)越高。

· 維護(hù)成本和服務(wù)供應(yīng)商以及組件復(fù)雜度都有關(guān)系，一般來說，單一的技術(shù)組件要比復(fù)雜的技術(shù)組件維護(hù)成本低，云服務(wù)提供的技術(shù)組件要比自建大數(shù)據(jù)組件維護(hù)成本要更低。

· 團(tuán)隊(duì)要求來說，一般來說與使用成本趨同，都是技術(shù)組件越復(fù)雜，團(tuán)隊(duì)要求越高。不過另一方面團(tuán)隊(duì)要求與服務(wù)供應(yīng)商也存在關(guān)系，如果云服務(wù)廠商能夠承擔(dān)起組件的運(yùn)維工作，實(shí)際上是可以幫助業(yè)務(wù)團(tuán)隊(duì)從運(yùn)維工作中解放出更多的工程師，參與到大數(shù)據(jù)應(yīng)用的工作中。

所以一般來說，架構(gòu)師對(duì)于技術(shù)選型的偏好應(yīng)該是，在滿足業(yè)務(wù)需求和數(shù)據(jù)量需求的前提下，選擇技術(shù)架構(gòu)最簡單的，因?yàn)橥@種選型是最容易使用和維護(hù)的。在這個(gè)基礎(chǔ)上，如果有一支非常強(qiáng)大的技術(shù)開發(fā)和運(yùn)維團(tuán)隊(duì)，可以選擇自建大數(shù)據(jù)平臺(tái)；如果缺乏足夠的運(yùn)維、開發(fā)支撐，那么建議選擇云服務(wù)平臺(tái)來支撐業(yè)務(wù)。

七牛云是如何做架構(gòu)選型的

七牛云的大數(shù)據(jù)團(tuán)隊(duì)叫做 Pandora，這只團(tuán)隊(duì)的主要工作就是負(fù)責(zé)七牛云內(nèi)的大數(shù)據(jù)平臺(tái)需求的支撐工作，另外也負(fù)責(zé)將大數(shù)據(jù)平臺(tái)產(chǎn)品化，提供給外部客戶專業(yè)的大數(shù)據(jù)服務(wù)?？梢哉f七牛云就是 Pandora 的第一個(gè)客戶，我們很多技術(shù)選型經(jīng)驗(yàn)也是在承載公司內(nèi)部各種需求積累起來的。

七牛云的特色和業(yè)務(wù)挑戰(zhàn)

簡單的介紹下我們在七牛云場景下面臨的各種挑戰(zhàn)。七牛云除了 Pandora 之外還有六個(gè)產(chǎn)品團(tuán)隊(duì)，包括云存儲(chǔ)、直播云、CDN、智能多媒體 API 服務(wù)以及容器云團(tuán)隊(duì)。所有產(chǎn)品團(tuán)隊(duì)所產(chǎn)生的業(yè)務(wù)數(shù)據(jù)和日志數(shù)據(jù)都要通過 Pandora 自研的收集工具 logkit（專業(yè)版）收集到 Pandora 的統(tǒng)一日志存儲(chǔ)中來。而后各個(gè)部門都利用這部分的數(shù)據(jù)做各種數(shù)據(jù)應(yīng)用。

首先商業(yè)運(yùn)營部門是背負(fù)了七牛云整個(gè)營收和增長的重要使命的團(tuán)隊(duì)，需要各個(gè)團(tuán)隊(duì)收集起來的埋點(diǎn)和日志數(shù)據(jù)，制作統(tǒng)一的用戶視圖，基于此制作用戶畫像。為客戶提供更加貼身的運(yùn)營服務(wù)，提升客戶的滿意度。

另外 SRE 團(tuán)隊(duì)，需要對(duì)線上系統(tǒng)做深入的性能追蹤，這邊需要我們提供 OpenTracing 接口的支持，在七牛云技術(shù)棧相對(duì)統(tǒng)一的環(huán)境下，我們很方便地支持全鏈路監(jiān)控，由此 SRE 部門不依賴于研發(fā)團(tuán)隊(duì)埋點(diǎn)即可以對(duì)線上的服務(wù)性能進(jìn)行追蹤監(jiān)控，更易得知服務(wù)哪里出現(xiàn)問題。

產(chǎn)品研發(fā)這邊提出了需要全文索引的需求，在每日近百 TB 的日志中需要能夠根據(jù)關(guān)鍵詞快速定位日志數(shù)據(jù)，同時(shí)能夠查詢?nèi)罩旧舷挛?。不僅如此，還需要能夠解析出 APP 日志中的關(guān)鍵字段，比如用戶 id 和響應(yīng)時(shí)間、下載流量等，能夠做用戶級(jí)別的運(yùn)維指標(biāo)監(jiān)控，能夠更加精準(zhǔn)的為客戶服務(wù)。

當(dāng)然無論是哪一個(gè)業(yè)務(wù)部門提出的需求，他們都需要有優(yōu)秀靈活的報(bào)表展示系統(tǒng)，能夠支撐業(yè)務(wù)做分析、探索和決策?；诤侠淼募軜?gòu)要能支撐復(fù)雜的業(yè)務(wù)報(bào)表和 BI 需求。

在七牛云的架構(gòu)落地

綜合考慮了各方的產(chǎn)品需求，我們做了如下的產(chǎn)品設(shè)計(jì)：

我們首先自研了 logkit 專業(yè)版，用來專業(yè)收集、同步各種開源項(xiàng)目或者日志文件的數(shù)據(jù)。另外設(shè)計(jì)了一套數(shù)據(jù)總線 Pipeline，結(jié)合了七牛云的數(shù)據(jù)吞吐量超大，但延遲可以接受到秒級(jí)的延遲的特點(diǎn)。這里我們采用了多 Kafka 集群 + Spark Streaming，自研了流量調(diào)度系統(tǒng)，可以將數(shù)據(jù)高效的導(dǎo)出到下游的統(tǒng)一日志存儲(chǔ)產(chǎn)品中，同時(shí)使用 Spark Streaming 可以輕易的完成日志解析，字段提取等工作。

統(tǒng)一日志存儲(chǔ)這里我們支持了自研和各種第三方的圖表展示系統(tǒng)。后端數(shù)據(jù)系統(tǒng)我們采用的是混合架構(gòu)模式，這里主體包含了三個(gè)基礎(chǔ)產(chǎn)品。

日志分析平臺(tái)

基于七牛云定制版本的 ES，構(gòu)建日志存儲(chǔ)和索引系統(tǒng)，能夠在吞吐量 100w/s  的情況下集群依然保證十億級(jí)別數(shù)據(jù)搜索秒級(jí)返回。

數(shù)據(jù)立方

基于定制版 Druid 構(gòu)建了數(shù)據(jù)立方這一個(gè) OLAP 產(chǎn)品，面向多租戶的高性能查詢，為最大的客戶每日 30TB+ 原始數(shù)據(jù)提供毫秒級(jí)的聚合分析。

離線工作流

基于存儲(chǔ)和 Spark 工作流平臺(tái)提供離線數(shù)據(jù)計(jì)算的能力，可以處理 PB 級(jí)數(shù)據(jù)的大規(guī)模計(jì)算和分析加工。

架構(gòu)優(yōu)勢

在踐行了這些大數(shù)據(jù)實(shí)踐之后，Pandora 為內(nèi)外部用戶帶來了一個(gè)怎樣的產(chǎn)品呢。我們通過與業(yè)界優(yōu)秀的商業(yè)和開源產(chǎn)品做比對(duì)，得出七牛云有以下的幾個(gè)優(yōu)勢：

完善的多租戶支持

在多租戶資源隔離這塊，Pandora 做了多個(gè)級(jí)別的隔離支持。包括低級(jí)別的命名空間隔離，這時(shí)候我們會(huì)通過限制用戶使用 CPU、內(nèi)存等各種共享資源，保證所有客戶都能安全使用集群。更多地，為了滿足更多客戶定制化需求，我們也利用多集群動(dòng)態(tài)擴(kuò)容方式支持租戶之間的空間隔離，用戶可以使用獨(dú)立的資源。

另外，在多租戶場景中很重要的安全、權(quán)限和審計(jì)，我們也做了長足的工作。數(shù)據(jù)我們可以按照數(shù)據(jù)子集和字段的粒度做權(quán)限管理，將數(shù)據(jù)授權(quán)給其他租戶。同時(shí)我們會(huì)對(duì)數(shù)據(jù)的每一次操作記錄審計(jì)，精確到來源 IP 和操作人員，保證云服務(wù)的數(shù)據(jù)安全性。

支撐豐富的業(yè)務(wù)場景

在 Pandora 基于日志領(lǐng)域的大數(shù)據(jù)平臺(tái)上，我們支持實(shí)時(shí)和離線兩種計(jì)算模型，使用工作流界面可以簡潔方便的操作各種大數(shù)據(jù)流。使用日志分析和數(shù)據(jù)立方等產(chǎn)品和工具，可以支持各種業(yè)務(wù)場景。包括但不限于：

· 用戶行為分析

· 應(yīng)用性能監(jiān)控

· 系統(tǒng)設(shè)備性能監(jiān)控

· 非侵入式埋點(diǎn)，支持全鏈路追蹤系統(tǒng)，發(fā)現(xiàn)分布式系統(tǒng)應(yīng)用瓶頸

· IoT 設(shè)備數(shù)據(jù)分析和監(jiān)控

· 安全、審計(jì)和監(jiān)控

· 機(jī)器學(xué)習(xí)，自動(dòng)系統(tǒng)異常探測和歸因分析

公有云超大規(guī)模數(shù)據(jù)驗(yàn)證

我們在公有云已經(jīng)服務(wù)了超過 200 家指名客戶，每天有超過 250TB 的數(shù)據(jù)流入，每天約 3650 億條數(shù)據(jù)。每日參與計(jì)算和分析的數(shù)據(jù)量已經(jīng)超過 3.2PB。超大的公有云規(guī)模，驗(yàn)證 Pandora 大數(shù)據(jù)日志分析平臺(tái)可以為客戶提供穩(wěn)定的計(jì)算平臺(tái)，提供良好的業(yè)務(wù)支撐。

用戶享受最低運(yùn)維成本

Pandora 的產(chǎn)品的設(shè)計(jì)哲學(xué)認(rèn)為，云服務(wù)應(yīng)該是一個(gè)一體化的產(chǎn)品。所以對(duì)于客戶來說，Pandora 雖然適配了大量的應(yīng)用場景，但是仍然只是一個(gè)單一的產(chǎn)品組件，所以對(duì)于采用七牛云大數(shù)據(jù)服務(wù)的客戶來說運(yùn)維成本是最低的，僅僅需要一個(gè)開發(fā)團(tuán)隊(duì)就可以照顧到數(shù)據(jù)開發(fā)和運(yùn)維的方方面面，對(duì)于快速的業(yè)務(wù)迭代和增長來說提供了巨大的便利性。