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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

流式計(jì)算的比較。

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

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

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

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

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

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

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

xiesc