2017 年 1 月 14、15日，為期 2 天的 ECUG Con 十周年大會在深圳圓滿結(jié)束，會上七牛云 CEO?許式偉做了題為《七牛大數(shù)據(jù)平臺建設(shè)實(shí)踐》的演講，首次披露七牛云在大數(shù)據(jù)方向的產(chǎn)品思路，以下是對他本次的演講實(shí)錄。

從連接到智能

我們都說現(xiàn)在是移動互聯(lián)網(wǎng)時(shí)代，移動互聯(lián)網(wǎng)時(shí)代我們隨時(shí)隨地能夠上網(wǎng)，面向連接的革命誕生了很多有意思的應(yīng)用，包括滴滴打車、外賣，這些都是在連接的時(shí)效性基礎(chǔ)上做的應(yīng)用。在有關(guān)于連接的革命以后，下一個階段就是面向智能的革命。滴滴打車這樣的場景未來會越來越智能,當(dāng)然百度外賣號稱現(xiàn)在在怎么送外賣這個事情上已經(jīng)有一些智能，但這些只是開始。每一個應(yīng)用會沉淀越來越多的數(shù)據(jù)，它成為這些數(shù)據(jù)唯一的?Owner。大家應(yīng)該意識到一點(diǎn)，圍繞著數(shù)據(jù)的深度應(yīng)用讓 App?變得智能，這件事有非常大的空間，無論你在什么領(lǐng)域。在我看來，這個智能不是云計(jì)算廠商或者大廠玩智能，未來所有的 App 都會玩智能。

在十年前，大家聽到「云計(jì)算」，大部分人覺得是不靠譜的，全球第一個云服務(wù)也就是 AWS 對象存儲，07 年剛剛發(fā)布，國內(nèi)沒有人知道，那時(shí)候的「云計(jì)算」概念雖然已經(jīng)產(chǎn)生了，但是大家對云計(jì)算的認(rèn)知非常不清楚。當(dāng)時(shí)很多人會把它和網(wǎng)格計(jì)算的概念關(guān)聯(lián)起來，而網(wǎng)格計(jì)算的概念曇花一現(xiàn)，最后消失了，大家認(rèn)為云計(jì)算是新瓶裝舊酒，是網(wǎng)格計(jì)算。但在今天看來，云計(jì)算本質(zhì)上是一個 IT 的革命，把 IT 的交付方式由軟件變成了服務(wù)，這是一個非常巨大的變革。這個變革背后的推動力其實(shí)是與移動互聯(lián)網(wǎng)的興起有關(guān)的。移動互聯(lián)網(wǎng)的興起意味著大量新興機(jī)會的涌現(xiàn)，大家拼命地都要跑得更快。這些新興的公司選擇合作伙伴更希望是服務(wù)的合作伙伴，而不是軟件合作伙伴。軟件外包失敗的概率是很大的，但是云計(jì)算解決了底層基礎(chǔ)的 IT 技術(shù)外包成功率的問題，這也是云計(jì)算興起的根源。

今天我們聽到很多公司談智能，忽悠的成分可能多于實(shí)際。而大部分公司認(rèn)為智能跟自己沒有關(guān)系，但是我認(rèn)為接下來十年智能是非常重要的事情。

智能為什么會興起？大部分的公司接下來十年都會開始充分利用互聯(lián)網(wǎng)這個生產(chǎn)力工具，把他們的業(yè)務(wù)從線下搬上了線上，這意味著他和客戶的連接其實(shí)是越來越數(shù)字化的。所謂的數(shù)字化，是指所有的溝通過程都會被記錄，這種被記錄的過程其實(shí)是很可怕的，因?yàn)槟銓τ脩羟八从械亓私狻５侨绻屵@些數(shù)據(jù)躺在你的計(jì)算機(jī)里或者刪掉，意味著你相比以前純粹地把業(yè)務(wù)跑在線下沒有本質(zhì)的進(jìn)步。將來各行各業(yè)的競爭一定是面向數(shù)據(jù)的競爭，數(shù)據(jù)累計(jì)得越多，你對用戶越了解，你對用戶行為的挖掘，通過智能的提取，你會讓 App?越來越具有獨(dú)特性。前面李玥介紹了?Linkedin?如何使用數(shù)據(jù)，那是非常好的一個案例。Linkedin 本質(zhì)上來講是一個獵頭公司，雖然它比很多大家認(rèn)知的獵頭公司要牛多了。但在本質(zhì)上來講，它是顛覆獵頭行業(yè)的，新的獵頭和老的獵頭效率差距無比巨大。Linkedin 僅數(shù)據(jù)產(chǎn)品相關(guān)的團(tuán)隊(duì)就有 150 人，這是很恐怖的數(shù)字，可以看出硅谷公司是怎樣的重視數(shù)據(jù)。

企業(yè)面臨的挑戰(zhàn)

觀念帶來的挑戰(zhàn)。 我們作為一個云計(jì)算廠商來看，多數(shù)公司的數(shù)據(jù)都不愿意存，認(rèn)為數(shù)據(jù)是負(fù)擔(dān)、是成本。但是在未來十年面向智能的時(shí)候，你應(yīng)該認(rèn)為數(shù)據(jù)是資本、是財(cái)產(chǎn)。這個觀念的轉(zhuǎn)念是非常巨大的。中國公司數(shù)據(jù)倉庫存數(shù)十 PB，會覺得每個月要花掉好多錢。多數(shù)公司認(rèn)為數(shù)據(jù)是成本，這是觀念的挑戰(zhàn)，可能也是未來最大的挑戰(zhàn)。

數(shù)據(jù)產(chǎn)生價(jià)值鏈條長。 不知道數(shù)據(jù)怎么用，或者沒有支撐的數(shù)據(jù)平臺。對于很多公司來說，把數(shù)據(jù)變成數(shù)據(jù)產(chǎn)品的鏈條是非常長的。整個數(shù)據(jù)從埋點(diǎn)、采集、分析、形成一系列產(chǎn)品，整個鏈條涉及的部門和工種非常多。涉及到業(yè)務(wù)部門、數(shù)據(jù)平臺部門、數(shù)據(jù)分析與數(shù)據(jù)產(chǎn)品部門，而后又回到業(yè)務(wù)部門作用到線上，這個周期非常長。這決定了要讓數(shù)據(jù)產(chǎn)生價(jià)值很困難。

多元化的場景。 不同的公司業(yè)務(wù)場景不同，導(dǎo)致我們的數(shù)據(jù)產(chǎn)品很難用統(tǒng)一的模式產(chǎn)生。這與七牛的非結(jié)構(gòu)化數(shù)據(jù)相比非常明顯。七牛的數(shù)據(jù)是圖片、音頻、視頻，圍繞這些富媒體為存儲的核心對象來構(gòu)建場景，它的應(yīng)用場景非常集中。非常集中就是說可預(yù)測性非常強(qiáng)，雖然我未必知道你的 App 是做什么的，但是我很清楚你的圖片是用來做什么、你的視頻用來做什么，業(yè)務(wù)場景比較容易清晰地呈現(xiàn)。但是大數(shù)據(jù)產(chǎn)品的業(yè)務(wù)場景非常是多元化的，不同的數(shù)據(jù)產(chǎn)品，面向的場景很不一樣。

七牛大數(shù)據(jù)平臺 -?Pandora

Pandora 是什么

Pandora 是一套數(shù)據(jù)采集、存儲和分析為一體的 PaaS 平臺，圍繞著富媒體的業(yè)務(wù)場景構(gòu)建，用戶的各種業(yè)務(wù)場景我們都能夠直接找到對應(yīng)的解決方案。我們對 Pandora 的定位是希望它是一站式的數(shù)據(jù)處理服務(wù)，能夠開放性地為七牛的客戶解決他希望的大數(shù)據(jù)相關(guān)的業(yè)務(wù)場景。

Pandora 有什么

圖 1

如圖 1 所示，第一部分是 Pipeline，其他部分是圍繞 Pipeline 協(xié)同的。另外，有很多和 Pipeline 相連的部分，包括前面演講介紹的?Kylin 也可以是其中之一。我們現(xiàn)在內(nèi)建支持的東西包括七牛自己的時(shí)序數(shù)據(jù)庫 TSDB、日志搜索引擎 LogDB、對象存儲服務(wù)、關(guān)系型數(shù)據(jù)庫、離線計(jì)算服務(wù)等。

Pandora 產(chǎn)品架構(gòu)圖

圖 2

圖 2 是?Pandora 的產(chǎn)品架構(gòu)圖。其中?Pipeline 是一個數(shù)據(jù)總線的概念，數(shù)據(jù)通過 Pipeline 進(jìn)來，打造一個臨時(shí)儲存數(shù)據(jù)的空間，比如我可以定義 7 天，即原始數(shù)據(jù)點(diǎn)可以在 Pipeline 里面存 7 天，然后數(shù)據(jù)經(jīng)過變換，比如聚合成 1 分鐘或者 1 天的數(shù)據(jù)，對它變換以后進(jìn)入到另外一個?Pipeline?的空間。為什么叫 Pipeline？它把建立數(shù)據(jù)和數(shù)據(jù)變換進(jìn)行串聯(lián)，這個串聯(lián)可以是任意級別的。數(shù)據(jù)在 Pipeline 里流轉(zhuǎn)以后，適當(dāng)?shù)臅r(shí)候會導(dǎo)入到分析引擎，這些分析引擎是多樣化的，同時(shí)還可以導(dǎo)出到?Kodo + XSpark（七牛對象存儲 + 離線分析引擎）、LogDB（類似ElasticSearch，日志搜索引擎）、TSDB（時(shí)間序列數(shù)據(jù)庫），以及其他服務(wù)等。

Pipeline——數(shù)據(jù)總線

什么是數(shù)據(jù)總線？企業(yè)內(nèi)部的數(shù)據(jù)都經(jīng)過數(shù)據(jù)總線，數(shù)據(jù)總線的數(shù)據(jù)想流動到哪里都可以。數(shù)據(jù)接入，數(shù)據(jù)來源可以多樣化，可以來自業(yè)務(wù)，可以來自日志數(shù)據(jù)、監(jiān)控?cái)?shù)據(jù)、實(shí)時(shí)數(shù)據(jù)等。這些數(shù)據(jù)進(jìn)來以后，最后會通過數(shù)據(jù)的變換，Pipeline 可以認(rèn)為是一個實(shí)時(shí)計(jì)算，它可以定義一些數(shù)據(jù)的變換，再去把一個 Pipeline 或者多個 Pipeline 里面的東西去聚合。最后，這些數(shù)據(jù)導(dǎo)出到 TSDB、LogDB、Kodo、MySQL/MongoDB 等。分析引擎在我們看來是非常多樣化的，會跟你的需求密切相關(guān)。我們認(rèn)為，你要抽象一個大數(shù)據(jù)的產(chǎn)品，最重要的是要抽象出數(shù)據(jù)總線。

Kodo+XSpark——離線計(jì)算

圖 3

為什么是 Kodo （七牛對象存儲）而不是?Hadoop?HDFS？這是因?yàn)槲覀冋J(rèn)為?Kodo 比 HDFS 做得更好。首先，Kodo 對元數(shù)據(jù)的支持比 HDFS 要好的多，七牛的?Kodo?對象存儲支持那么多的客戶，我們很多客戶一天就是幾億個文件進(jìn)來，Kodo 對象存儲的規(guī)模絕對不是 HDFS 能夠搞定的。另外，七牛的對象存儲能夠支持小到只有 1 個字節(jié)、大到單文件近?TB 級別的規(guī)模。其次，Kodo 比 HDFS 的成本低得多，HDFS 默認(rèn)會有 3 份數(shù)據(jù)，而 Kodo 將存儲冗余度從 3 副本降低至 1.14 副本。所以站在七牛的角度來講，我們沒有必要再去基于 HDFS，而是讓?Spark?去支持七牛的 Kodo 對象存儲。

TSDB——時(shí)序數(shù)據(jù)庫

圖 4

LogDB——日志搜索引擎

LogoDB?除了能夠提供海量日志的存儲與搜索，同時(shí)還支持對日志索引進(jìn)行時(shí)限的限制（retention）。LogDB?對運(yùn)維人員定位問題是非常有好處的,如果沒有這種數(shù)據(jù)平臺的話，我們可能要用?awk?或者?grep?這樣原始的指令來查找問題，但是用 LogDB 可以協(xié)助快速地定位和解決問題。?大部分日志數(shù)據(jù)的搜索場景，基本上是短期的目的，無論是出于運(yùn)維的考慮還是客服的目的，基本上把日志索引建到一個星期左右就差不多了。但是開源的搜索引擎不是面向這種場景，它需要你自己去做一些日志索引的改造。

Pandora 的基礎(chǔ)邏輯

沒有一個數(shù)據(jù)分析引擎可以解決所有的數(shù)據(jù)分析需求，能夠統(tǒng)一實(shí)現(xiàn)的是數(shù)據(jù)總線（Pipeline），管理數(shù)據(jù)的流動過程。

每個數(shù)據(jù)分析系統(tǒng)做好它關(guān)注的一件事情（而不是做越來越多的事情），如果輸出還需要進(jìn)一步處理，盡可能讓它再重新流入到?Pipeline。

每一個分析系統(tǒng)分析的場景不一樣，它背后的分析結(jié)構(gòu)是不一樣的，我們需要每一個系統(tǒng)只關(guān)注一小塊，這樣可以足夠的解耦。整個系統(tǒng)最核心的就是 Pipeline，把大數(shù)據(jù)的各種系統(tǒng)進(jìn)行串聯(lián)。

基于 Pandora 的應(yīng)用場景

場景：視頻直播的質(zhì)量運(yùn)營

我們關(guān)心的維度： 直播質(zhì)量的實(shí)時(shí)報(bào)表、日志搜索、各 CDN 廠商的質(zhì)量評估、異常情況的告警。很多直播的平臺都是請了主播，這些主播特別貴，一旦出問題就是大問題。大家可能會覺得這只是萬分之一的概率，但是萬分之一到他請的主播上就是大事，所以他會有很多面向個體分析的場景，所以需要日志搜索。站在更高的維度來講，每個直播的需求方都會有多個 CDN 廠商同時(shí)提供服務(wù)，直播平臺希望這個時(shí)候能對 CDN 廠商進(jìn)行質(zhì)量評估，也會有一些人提出更高級的需求，比如對異常情況預(yù)警、自動觸發(fā)流量調(diào)度等。

直播質(zhì)量的實(shí)時(shí)報(bào)告

圖 5

直播特別關(guān)心用戶看到的第一屏的時(shí)間，用戶發(fā)起直播到看到第一屏的時(shí)間我們叫首開時(shí)間，這些我們會產(chǎn)生一些相關(guān)的報(bào)表，并且是實(shí)時(shí)的。如果出現(xiàn)問題了，我們會看到針對不同的直播 CDN 供應(yīng)商的質(zhì)量考量，如圖 5 所示。

圖 6

卡頓率也是直播質(zhì)量考量的一個維度，如圖 6 所示，我們可以看到關(guān)于卡頓率的熱點(diǎn)圖。站在全國的維度來看卡頓率，圖中越紅的地方表示卡頓率越高，質(zhì)量越差。

日志搜索

圖 7

日志搜索主要是面向客服的場景，比如說某一個主播有卡頓，我們需要找到這個主播相關(guān)的條件去搜索，最后把服務(wù)端甚至客戶端即 SDK 端報(bào)上來的數(shù)據(jù)整合，來看問題到底發(fā)生在哪里。

我們用了什么

基本上把 Pandora 的服務(wù)都用了:

Pipeline: 數(shù)據(jù)總線、對數(shù)據(jù)做基礎(chǔ)的聚合（1 min,1 day）；

TSDB：實(shí)時(shí)數(shù)據(jù)分析；

LogDB：日志搜索；

XSpark：高級離線數(shù)據(jù)分析（各廠商的質(zhì)量評估）。

以上是我演講的內(nèi)容，整個 Pandora 的定位是一站式、開放式的大數(shù)據(jù)平臺。謝謝！

Q

數(shù)據(jù)類型有很多種，我們公司目前僅僅是做日志分析。在收集數(shù)據(jù)的時(shí)候，可能會關(guān)注哪一部分的數(shù)據(jù)？

許式偉： 這和需求有密切關(guān)系。你的分析一定是跟需求相關(guān)的，比如說游戲，你希望分析道具相關(guān)的，你就需要把道具相關(guān)的數(shù)據(jù)導(dǎo)到平臺里面。

Q

數(shù)據(jù)來源可以是多方面？

許式偉： 對。埋點(diǎn)部分是沒有辦法解決的，這是要到業(yè)務(wù)系統(tǒng)中去做的事情。

Q

這個產(chǎn)品的定位，會考慮部署到企業(yè)內(nèi)部？因?yàn)檫@個數(shù)據(jù)很多用戶可能對數(shù)據(jù)比較敏感，希望用你這個產(chǎn)品功能，但是不需要把數(shù)據(jù)放到上面？

許式偉： 這個我們私下聊吧。我們是可以支持部署到客戶?IDC?的，但是是有條件的。我們認(rèn)為云計(jì)算最大的變化是由軟件變成服務(wù)，所以我們希望 Pandora 的發(fā)布形態(tài)不是個軟件。在這個前提下更多細(xì)節(jié)可以再討論。