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

從連接到智能

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

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

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

智能為什么會興起？大部分的公司接下來十年都會開始充分利用互聯網這個生產力工具，把他們的業務從線下搬上了線上，這意味著他和客戶的連接其實是越來越數字化的。所謂的數字化，是指所有的溝通過程都會被記錄，這種被記錄的過程其實是很可怕的，因為你對用戶前所未有地了解。但是如果讓這些數據躺在你的計算機里或者刪掉，意味著你相比以前純粹地把業務跑在線下沒有本質的進步。將來各行各業的競爭一定是面向數據的競爭，數據累計得越多，你對用戶越了解，你對用戶行為的挖掘，通過智能的提取，你會讓 App?越來越具有獨特性。前面李玥介紹了?Linkedin?如何使用數據，那是非常好的一個案例。Linkedin 本質上來講是一個獵頭公司，雖然它比很多大家認知的獵頭公司要牛多了。但在本質上來講，它是顛覆獵頭行業的，新的獵頭和老的獵頭效率差距無比巨大。Linkedin 僅數據產品相關的團隊就有 150 人，這是很恐怖的數字，可以看出硅谷公司是怎樣的重視數據。

企業面臨的挑戰

觀念帶來的挑戰。 我們作為一個云計算廠商來看，多數公司的數據都不愿意存，認為數據是負擔、是成本。但是在未來十年面向智能的時候，你應該認為數據是資本、是財產。這個觀念的轉念是非常巨大的。中國公司數據倉庫存數十 PB，會覺得每個月要花掉好多錢。多數公司認為數據是成本，這是觀念的挑戰，可能也是未來最大的挑戰。

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

多元化的場景。 不同的公司業務場景不同，導致我們的數據產品很難用統一的模式產生。這與七牛的非結構化數據相比非常明顯。七牛的數據是圖片、音頻、視頻，圍繞這些富媒體為存儲的核心對象來構建場景，它的應用場景非常集中。非常集中就是說可預測性非常強，雖然我未必知道你的 App 是做什么的，但是我很清楚你的圖片是用來做什么、你的視頻用來做什么，業務場景比較容易清晰地呈現。但是大數據產品的業務場景非常是多元化的，不同的數據產品，面向的場景很不一樣。

七牛大數據平臺 -?Pandora

Pandora 是什么

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

Pandora 有什么

圖 1

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

Pandora 產品架構圖

圖 2

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

Pipeline——數據總線

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

Kodo+XSpark——離線計算

圖 3

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

TSDB——時序數據庫

圖 4

LogDB——日志搜索引擎

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

Pandora 的基礎邏輯

沒有一個數據分析引擎可以解決所有的數據分析需求，能夠統一實現的是數據總線（Pipeline），管理數據的流動過程。

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

每一個分析系統分析的場景不一樣，它背后的分析結構是不一樣的，我們需要每一個系統只關注一小塊，這樣可以足夠的解耦。整個系統最核心的就是 Pipeline，把大數據的各種系統進行串聯。

基于 Pandora 的應用場景

場景：視頻直播的質量運營

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

直播質量的實時報告

圖 5

直播特別關心用戶看到的第一屏的時間，用戶發起直播到看到第一屏的時間我們叫首開時間，這些我們會產生一些相關的報表，并且是實時的。如果出現問題了，我們會看到針對不同的直播 CDN 供應商的質量考量，如圖 5 所示。

圖 6

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

日志搜索

圖 7

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

我們用了什么

基本上把 Pandora 的服務都用了:

Pipeline: 數據總線、對數據做基礎的聚合（1 min,1 day）；

TSDB：實時數據分析；

LogDB：日志搜索；

XSpark：高級離線數據分析（各廠商的質量評估）。

以上是我演講的內容，整個 Pandora 的定位是一站式、開放式的大數據平臺。謝謝！

Q

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

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

Q

數據來源可以是多方面？

許式偉： 對。埋點部分是沒有辦法解決的，這是要到業務系統中去做的事情。

Q

這個產品的定位，會考慮部署到企業內部？因為這個數據很多用戶可能對數據比較敏感，希望用你這個產品功能，但是不需要把數據放到上面？

許式偉： 這個我們私下聊吧。我們是可以支持部署到客戶?IDC?的，但是是有條件的。我們認為云計算最大的變化是由軟件變成服務，所以我們希望 Pandora 的發布形態不是個軟件。在這個前提下更多細節可以再討論。