以下內(nèi)容根據(jù)演講整理，未經(jīng)本人審定。

TalkingData研發(fā)副總裁閻志濤

主持人：首先自我介紹一下，我叫閻志濤，來自Talking Data，Talking Data負責技術(shù)相關(guān)的研發(fā)工作，我也是分會場的出品人。

非常高興來主持這個大會。2018中國存儲與數(shù)據(jù)峰會（DATA & STORAGE SUMMIT 2018）基本上偏向于硬件和存儲相關(guān)，今年增加了大數(shù)據(jù)叫做DT，我非常有幸參與到這里來。

前面我先講講自己的一些觀察，因為我自己是從2012年從事大數(shù)據(jù)相關(guān)的工作，基本上見證了中國大數(shù)據(jù)行業(yè)從起步到現(xiàn)在整個這個階段的發(fā)展。

大數(shù)據(jù)已經(jīng)不是很前衛(wèi)的詞了，有一段時間大數(shù)據(jù)是非常前衛(wèi)的?，F(xiàn)在大數(shù)據(jù)在國家戰(zhàn)略里還是很重要的一塊，大家聽說什么ABCD、AI、區(qū)塊鏈、大數(shù)據(jù)等等都在這里，還有云計算。

首先講幾個概念，流式計算和交互式分析，它跟現(xiàn)在大數(shù)據(jù)的關(guān)系。

流式計算，這個詞本身不是特別新的詞，它是基于數(shù)據(jù)流的計算，大家過去經(jīng)常性面對的計算，數(shù)據(jù)庫里提一個東西出一個結(jié)果，但是現(xiàn)在隨著互聯(lián)網(wǎng)場景的發(fā)生，數(shù)據(jù)在無時無刻的產(chǎn)生，比方說現(xiàn)在新的一個熱門的話題叫IOT、邊緣計算，實際上數(shù)據(jù)無時無刻不在產(chǎn)生，進到這里面就開始進行計算，數(shù)據(jù)流的計算，因為是流式計算，數(shù)據(jù)流的時候就有時間流的處理，正常是數(shù)據(jù)進來會有event，所以叫做響應(yīng)式編程。這幾個關(guān)鍵的詞，還有后面就是并行計算，數(shù)據(jù)量大的時候需要并行計算，這個構(gòu)成了流式計算的定義。

流式計算數(shù)據(jù)是流動的，原來我做大數(shù)據(jù)的時候是在做很多的IT業(yè)務(wù)系統(tǒng)，那時候的數(shù)據(jù)是怎么做的，一般的情況下ROTB是數(shù)據(jù)入庫，是為了保障交易的一致性，同時會有LOG產(chǎn)生，LOG到磁盤，LOG到磁盤之后是為了做事后分析，所以那個時候一般的有什么數(shù)倉，也就是說先有ROT就有了RVP，RVP是為了做報告，運行時的數(shù)據(jù)產(chǎn)生存到磁盤，為日后的消費去做業(yè)務(wù)洞察去做準備，這是過去一種方式。

隨著大數(shù)據(jù)時代的到來，越來越多的企業(yè)發(fā)現(xiàn)數(shù)據(jù)要能夠及時的去反映業(yè)務(wù)場景，這時候也就是數(shù)據(jù)在流動，寫到磁盤，過幾天再去算會帶來更多的好處。

另外，數(shù)據(jù)進來的時候是并行的，正常來講，流式出來有個問題，你要大規(guī)模的把數(shù)據(jù)計算出來的話，原來大家可能都知道并行計算，所有的流式計算都是并行計算的一種實現(xiàn)場景，就是說它一定是對進來的數(shù)據(jù)流進行并行的計算。

再一個是持續(xù)計算，數(shù)據(jù)流完之后，原來最典型的非流式計算之前，計算到數(shù)據(jù)那兒做，數(shù)據(jù)存在哪兒在哪兒做計算，持續(xù)計算是這樣的，數(shù)據(jù)在這個地方流動的時候開始做計算，里面有很大的區(qū)別，這是整個流式計算我個人抽象出來的幾個構(gòu)成點。

流式計算意味著什么呢？第一個它一定是快速的，就是說現(xiàn)在大家都講究Fast DATA，另外一個要快速的去用才能產(chǎn)生高價值，所以必須快速處理低延時，你的數(shù)據(jù)一直在流動，流動的東西如果不能低延時處理的話，整個系統(tǒng)的健壯性就出現(xiàn)很大的問題。

為什么選擇流式計算？流式計算的產(chǎn)生跟所有的技術(shù)演進一樣，都跟業(yè)務(wù)有關(guān)系，是業(yè)務(wù)驅(qū)動的結(jié)果。最早大數(shù)據(jù)就是所謂的小項，也就是在YAHOO、Google做實現(xiàn)的時候那些開源的東西基本上都是流式計算。能做什么呢？一般流式計算能做的第一個是看前一個小時發(fā)生了什么錯誤，一般的系統(tǒng)會用來統(tǒng)計上一個小時日值有多少錯誤，這個是離線計算的結(jié)果。原來在離線的時候，廣告投放之后都會看廣告效果，一般是把廣告日志點擊存下來，推廣的話把應(yīng)用安裝日志拿過來，第二天算歸因轉(zhuǎn)化的計算，形成昨天多少個渠道、每個渠道帶來了多少從點擊到激活的統(tǒng)計，這是對于廣告而言。欺詐也是，把用戶所有的行為日值存到磁盤進行離線分析，發(fā)現(xiàn)昨天有多少有可能是欺詐的，這在運營過程中是非常有價值的。對于數(shù)據(jù)來講，大家并不希望僅僅看到一個報告做分析，而是希望在數(shù)據(jù)使用過程中讓數(shù)據(jù)產(chǎn)生真正的價值，及時發(fā)現(xiàn)問題、及時去做問題的響應(yīng)，流式處理就產(chǎn)生了價值。

越來越多的企業(yè)會把自己的IT運維監(jiān)控變成流式的，可以實時統(tǒng)計系統(tǒng)的運行狀況有很多的公司，IT部門有一個大屏，大屏里面實時的看自己的信息，比方說網(wǎng)絡(luò)流量，對每一個業(yè)務(wù)系統(tǒng)進行錯誤的分析，如果達到閾值它會處罰警告，處罰警告有時候出現(xiàn)幾種情況，有時候自動的做處理，比如單列出現(xiàn)錯誤特別多，它會自動把這個點shut down，新的技術(shù)點去增加它的容量，更好的響應(yīng)IT系統(tǒng)的響應(yīng)狀況，這是實時帶來的非常大的好處。對于廣告更有價值，廣告行為，是廣告主掏錢獲取自己用戶的典型的用錢購買用戶的場景，原來離線統(tǒng)計是第二天做業(yè)務(wù)調(diào)整，比方說覺得某個渠道效果不好，只能第二天去做調(diào)配，而如果用事實的東西，比方說我們現(xiàn)在公司里做的東西，實時點擊到安裝的歸因，點擊日志和歸因日志來當場出結(jié)果，這樣對于廣告主和廣告運營團隊可以實時盯著自己多個渠道轉(zhuǎn)化的效果，動態(tài)調(diào)整自己的投放策略，將資源投放到更好的渠道，這是對于廣告帶來的好處。

在欺詐方面，前兩年P(guān)2P金融非?；穑芏喑隽吮瑐}等問題，很大的原因就是這里面有很多欺詐。如果做離線分析，損失造成了再追是非常難受的，通過實時的預(yù)測模式，比方說看到某個人的行為，一般實時預(yù)測會把他過去的畫像帶過來，把歷史的行為帶進來，如果基于分析發(fā)現(xiàn)行為有異常，可以不給他放貸，不給他放款，這樣的話，可以非常顯著的提高金融公司運營的效率，降低運營成本和風險。對于電信也一樣，詐騙電話基本上實時識別，降低詐騙的風險。這是流式處理帶來的顯著好處。

因此，大部分企業(yè)越來越傾向于把自己的數(shù)據(jù)，尤其是核心的業(yè)務(wù)做流式處理。

那么交互式分析是什么？為什么這兩個放在一起談？

流式處理的優(yōu)點是非常快速的能夠產(chǎn)生響應(yīng)，但是流式處理有一個問題，所有的流式處理一般的是預(yù)先跑的模型或者計算，計算已經(jīng)先預(yù)定下來，流式處理一定要非?？焖?，數(shù)據(jù)過的時候就要完成計算，這個時候很難完成交互式流式計算。

這個情況下，流式計算預(yù)定規(guī)則，可更好的發(fā)現(xiàn)異常情況，及時響應(yīng)，基于生成的日志做分析（因為很多情況下并不是預(yù)定的計算規(guī)則，數(shù)據(jù)已經(jīng)產(chǎn)生，流式已經(jīng)過來），如何在存儲里面去做這種更多維度的分析，與原來看到經(jīng)典的離線計算的時候確定好的模式，離線去做統(tǒng)計分析形成報表相比，如何據(jù)能夠及時的響應(yīng)，深入的分析，希望要多次迭代式，可能要看一看數(shù)據(jù)，最典型的這個字段或者這個方式跟我有關(guān)系，做統(tǒng)計分析，然后發(fā)現(xiàn)這里面跟我的關(guān)系沒這么大，我多拎幾個，這個時候變成再一個大規(guī)模尺度上。

現(xiàn)在這種流式分析都是基于日志類型，所有用戶行為的日志、操作日志一天是幾個G，加上歷史行為，可能多少個T甚至上P，用戶能在這上面完成類似于數(shù)據(jù)庫的交互式分析，這是現(xiàn)在越來越迫切的需求，它實質(zhì)上是希望用戶對于自己對數(shù)據(jù)的理解，利用提供給他的類cico，有可能是更簡潔的界面上，在海量的數(shù)據(jù)上多維度的分析，甚至建模，他還希望盡量延時低，達到更好的用戶體驗，因為越延時低，越能盡早的發(fā)現(xiàn)問題的根本原因。

前面的流式計算是及時的響應(yīng)，但是想做根本原因調(diào)查的時候，希望基于更多的數(shù)據(jù)和自己的理解，但是不希望等待。傳統(tǒng)的這種提交一個需求要等五六個小時，對用戶來講很難接受的，希望在大數(shù)據(jù)的場景下，實現(xiàn)一個低延時的交互式分析。它的優(yōu)點一個是快，二是靈活，這樣才能幫助用戶更好的去洞察數(shù)據(jù)蘊藏的價值，方便進一步迭代，出來新的流式的固定的模型，交給流式去做。

前面講了兩個概念，為什么選擇流式計算和交互式分析，后面我會帶一些技術(shù)進來，再就是技術(shù)選型的推薦。

應(yīng)該說，從2013年2014年開始，關(guān)于流式處理，或者說這種流式計算的框架越來越多，是這幾年在大數(shù)據(jù)里特別熱點的方向，是價值驅(qū)動，有價值驅(qū)動就有技術(shù)的發(fā)展。

目前流域流式計算有主要的幾個內(nèi)容，一個就是消息總線，數(shù)據(jù)進來再處理的時候，它一般會有一個event das，實際上在傳統(tǒng)的企業(yè)市場里也有消息總線的概念，大數(shù)據(jù)時代首先支持大量數(shù)據(jù)存儲，然后高吞吐率，因為高吞吐率意味著數(shù)據(jù)大量的進來，還會延時，會有低消費的消息總線的需求。

這里有兩個主要的產(chǎn)品：一個是Kafka，互聯(lián)網(wǎng)企業(yè)里它是標配的產(chǎn)品，基本上所有的公司都會用到Kafka存儲自己的日志，不管是流式處理也好，還是永久存儲也好，這個是是實時必備的消息總線。另外一個是Pulsor，如果2016年2017年的時候大家毋庸置疑會選擇Kafka，但是Kafka出來這么多年之后，有一些限制，比如說Kafka是典型的計算和存儲綁在一起的設(shè)計，對于Kafka的每一個節(jié)點，數(shù)據(jù)和它的計算節(jié)點是在一起。對于一個快速成長的企業(yè)來講，它經(jīng)常會存在，我一開始設(shè)計了一個Kafka的集群，規(guī)模比較小，隨著時間增加，數(shù)據(jù)規(guī)模變大，業(yè)務(wù)規(guī)模變大，數(shù)據(jù)增長，這個是Kafka節(jié)點增加就會存在一個重新blance數(shù)據(jù)的問題，這里有可能增長Kafka數(shù)據(jù)性能的問題。另外一個說現(xiàn)在越來越多的企業(yè)會把自己的數(shù)據(jù)團隊當做核心的服務(wù)型團隊給別人提供服務(wù)，企業(yè)內(nèi)部會多組互化或者云化，這個時候Kafka天然的弱點出來了，因為Kafka最早設(shè)計的時候不是為多組戶設(shè)計的，會有一些限制，正是因為這些限制，新的一個消息總線的產(chǎn)品Kafka，這個是Yahoo而開發(fā)的產(chǎn)品，Kafka是TP link的產(chǎn)品。

另外就是計算框架，在2012年我們剛開始創(chuàng)業(yè)的時候，沒有成熟的流式計算的框架。流式計算的框架就是希望基于非常簡潔的編程模式實現(xiàn)對數(shù)據(jù)流動，也就是說在數(shù)據(jù)上做流動的計算，而不是傳統(tǒng)的這種基于離線的文件在那兒，數(shù)據(jù)在那兒我有一個計算框架，那個時候我們只能自己寫自己的流式的引擎。隨著業(yè)務(wù)的演進就會發(fā)現(xiàn)，大家可能很多企業(yè)都有一種訴求，于是有的公司把公司內(nèi)部實現(xiàn)的東西開源，第一個想到的就是storm，這個是最早的流式計算的引擎，大概2013年前后在不同的企業(yè)里面從twitter出來之后在不同的企業(yè)里被大家使用，它是比如說我做一些流式數(shù)據(jù)的統(tǒng)計，用它非常方便的可以做。隨著技術(shù)的發(fā)展，越來越多的流式計算出來，比如說在大數(shù)據(jù)行業(yè)里非常非常熱的一個技術(shù)spark，它出來就有streaming，但是不是核心點，從2.0之后越來越重視streaming，現(xiàn)在叫spark streaming。
還有一個大家不所知的越來越熱的技術(shù)Flink，它在一開始大家基于離線計算的時候，F(xiàn)link默默無聞。從2016年開始，流式計算越來越多的變成趨勢的時候，F(xiàn)link變成了炙手可熱的計算框架，據(jù)我了解本來是想把阿里的人請來，因為國內(nèi)的話大數(shù)據(jù)的公司無非幾類，一類是BAT，然后一些是搞數(shù)據(jù)的公司，BAT里面阿里就是基于Flink做了自己的開源，把Flink進行深度的定制，針對阿里的業(yè)務(wù)做了Flink。另外一個在國內(nèi)游一定影響力的Apex。消息總線兩個主要的，但是計算框架我列了四個，實際上現(xiàn)在不僅僅四個。

我做一下技術(shù)比較，如果大家有技術(shù)選型的話可以參考一下這個東西。首先看Kafka和Pulsor的比較，Kafka消息的特定側(cè)重于高性能流式的消費，Pulsor相對Kafka有一點就是說，因為Kafka的消費類似于set的方式，但是Pulsor支持高性能流式消費以及傳統(tǒng)隊列式消費。如果大家做傳統(tǒng)的企業(yè)軟件都知道，有Q和topx，topx一對多，Q是一對一，只有一個消費者消費完了就完了，但是Kafka是topx的方式，Pulsor可以支持topx可以支持Q。另外一個Kafka存儲在Broker節(jié)點上，Pulsor存儲和服務(wù)分離，方便擴充存儲時擴充存儲，擴充計算時擴充計算。ACK也不一樣，Kafka的ACK我用了這么多年，它offset有它的好處，也有不好處，不好的就是它靈活性不好，Pulsor是用的Cursor的機制，可以靈活的做消息的控制，這里面比方說就是回到下面。對于Kafka來講，它是沒有辦法去做單個消息進行控制，TTL沒有辦法做單個消息的控制，對于Pulsor來講，它可以做單消息的生命周期的控制，這樣某些場景里就非常有意義，比如我的存儲里放的數(shù)據(jù)消費掉之后，我判斷它有問題，我不希望后面進行設(shè)計，我就設(shè)一個TTL被消亡掉，其它的數(shù)據(jù)保留更長的時間，這個是Pulsor的優(yōu)點。再就是多租戶的支持，想用Kafka做多租戶，我是一個公司希望提供云化的能力，對于Kafka只能用多個Topic來弄，但是Pulsor天然支持多租戶模型，它可以設(shè)置很多相關(guān)東西，所以這個好很多。從普及性來講，差別也蠻大的，Kafka可以變成實時的行業(yè)的標準產(chǎn)品了，所以說基本上所有的公司都有Kafka，但是Pulsor現(xiàn)在還在大力發(fā)展過程當中，所以說很多企業(yè)現(xiàn)在有的在嘗試，但是在國內(nèi)的我了解到的Pulsor真正落地的企業(yè)還沒有那么多，我們自己也在看這個產(chǎn)品。

流式計算的比較。

我是國內(nèi)最早做spark的人之一。Apex號稱比較高，因為Apex我沒有做過深入的調(diào)研，和他們的團隊溝通過，他們吞吐率也是比較高的。延時上講，sparkstreaming到目前來講雖然叫做持續(xù)計算，它的latency還不是最低延時，因為spark的技術(shù)模型設(shè)計基于HPV4的，再怎么著里面也得湊夠一批才做處理，它的延時相對高。Flink和 storm延時很低，是流式計算開源的產(chǎn)品了。另外就是一次性，消息產(chǎn)品這個還是很關(guān)鍵的，我不希望重復(fù)消費，或者沒有被消費到的，這里面這幾個產(chǎn)品都支持。再就是社區(qū)活躍度，社區(qū)活躍度高，意味著大家做計算機屬性的風險就低，因為用的人多，你出了問題找人更容易找到。國內(nèi)的工程師還存在一個問題，就是英文溝通并不是特別好，國外做技術(shù)選型的設(shè)計活躍度會參照，但是他們更喜歡觀察這個東西跟他自己的場景的完全的適配度，所以說在國外會有些技術(shù)會比較小眾的被選擇的。國內(nèi)的話，大家可能傾向于選擇人越多，越多的人選，是這樣的正反饋。現(xiàn)在來講spark毋庸置疑是活躍度最高的，也是選擇性最多的。Flink在國內(nèi)越來越多，下面會有一個嘉賓講到他們用Flink做流式計算的，他們在電商領(lǐng)域里，會詳細的介紹這個技術(shù)怎么用。Storm本身的社區(qū)活躍度一直比較高，因為它在傳統(tǒng)上很多迅速的拿storm做東西，只不過它很多的限制，在很多企業(yè)大數(shù)據(jù)規(guī)模上，規(guī)模大的storm有很多不適合的地方，所以越來越多的公司用spark或者 spark streaming來做。Apex影響力很低，就不說了。

交互式形式很多，可以說現(xiàn)在很多的新的計算框架都期望解決交互式式的性能問題。spark一出來就火，替代傳統(tǒng)，就是因為它提交性能處理更快。還有更適合做交互式的，像國內(nèi)的京東，還有好幾家公司都在做，京東在Presto上做了很多的改善的工作。還有Impala，它是一個開源的事件。當然Hive也能做，它的新的版本性能優(yōu)很大的提高，最早期的版本Hive是慢性的交互式分析。一個華人在美國開源的東西叫Druid，這個是計算引擎。這里面還有很多的設(shè)備保障它的低延時，就是存儲，怎么保障高校的交互式分析，一個非常重要的場景就是列存儲，列存儲可以精準的把我需要進行分析的列提出來，列里面很多的元素是重復(fù)性的，它存儲的代價很小，能夠保障高IO的把東西拉出來。列存儲很多，Praquet，傳統(tǒng)的Hive的Orcfile，小米投入很大精力的Kudu，它不僅僅是存儲還是分析殷勤。還有解決分布式異構(gòu)存儲的，以及內(nèi)存加速的華人公司做的Alluxo，也是最近這兩年非?；鸬?。

還有一個就是更經(jīng)典的在企業(yè)時代就存在的，然后逐漸的開始進一步往前走的MPP數(shù)據(jù)庫，像Greenplum，像惠普的Vertica，包括國內(nèi)一倍出來的團隊發(fā)展非常不錯的Kyligence。還有俄國人最近做的非常有特點的做MPP的交互式分析數(shù)據(jù)庫就是Clickhouse，國內(nèi)很多的在嘗試。

下面是一個常見的架構(gòu)。這應(yīng)該是大部分公司里采用的類似的架構(gòu)，前面是不同的數(shù)據(jù)來源，中間一定會有一個消息總線或者選Kafka或者選Pulsor，左側(cè)你可以根據(jù)自己的選擇，低延時用Flink，如果沒有特別在意延時，可以選擇spark streaming?；蛘哐訒r再高一些，能接受10分鐘級別的可以用spark，這個時候你的數(shù)據(jù)流式把它存在列存儲里，Presto，也可以存到MPP數(shù)據(jù)庫里，也可以放到云上S3上，緊接著用交互式分析的框架，做交互式分析，這樣企業(yè)大數(shù)據(jù)站能夠保證既實現(xiàn)流式實時統(tǒng)計的結(jié)果或者預(yù)警，也能夠支持你交互式的深入的洞察和分析。

趨勢是什么。人的欲望無窮的，總是想要的更多。這么多數(shù)據(jù)產(chǎn)生，希望這些數(shù)據(jù)更快的產(chǎn)生價值?，F(xiàn)在的趨勢是越來越實時，能夠更快速的處理，前面是分析的，現(xiàn)在的實時的機器學(xué)習越來越多，更快，還有就是更智能，期望更多的去把預(yù)測能力加到實時里去，幫助做決策，這樣的話人就可以真真正正的利用大數(shù)據(jù)帶來的價值去支撐自己的業(yè)務(wù)發(fā)展。

今天我這兒就差不多分享這么多，因為這里面很多細節(jié)的東西我沒有過，很多實踐的東西也沒有講，后面幾個嘉賓，網(wǎng)易的，蘇寧的，還有一個老朋友在網(wǎng)易梧桐待過做實時推薦的，他們對針對自己的業(yè)務(wù)場景來講怎么用流式計算和交互式分析解決業(yè)務(wù)的問題。我們公司也在做相關(guān)的東西，但是我希望讓嘉賓講的更透一些，我就沒有牽扯太多的細節(jié)。

我這么多年一直做技術(shù)，喜歡技術(shù)交流的，所以做這個出品人，也是希望有更多的同仁來去就技術(shù)進行交流，看看整個大數(shù)據(jù)行業(yè)里面發(fā)展的趨勢，以及我們自己怎么能夠在這個里面去跟上時代，貢獻自己的東西。

xiesc