建站
咨詢
售后
建站咨詢
新聞中心
01 流之源
以終為始 – 源
了解流計算之源，我們需要看一些自然現(xiàn)象，我們從左往右看，第一個詞斗轉(zhuǎn)星移，描述的是地球繞太陽旋轉(zhuǎn)和地球自轉(zhuǎn)的自然現(xiàn)象。后面的改朝換代，生老病死，四季變化，日月交替也是被大家共識的客觀事實(shí)。這些詞語雖然不同，但這些現(xiàn)象都包括了很核心的幾個共性：
定制網(wǎng)站開發(fā)可以根據(jù)自己的需求進(jìn)行定制，成都網(wǎng)站制作、做網(wǎng)站構(gòu)思過程中功能建設(shè)理應(yīng)排到主要部位公司成都網(wǎng)站制作、做網(wǎng)站的運(yùn)用實(shí)際效果公司網(wǎng)站制作網(wǎng)站建立與制做的實(shí)際意義
那就是這里面都是有時間屬性，同時伴隨時間都會不斷的發(fā)生具體事件，同時在事件的作用下，整個環(huán)境也都發(fā)生著必然的變化?，F(xiàn)在我們聊一個大家都熟知、但卻充滿著 事件/計算/預(yù)測 等方面要素的事情。
我們在很多文字中都會看到 “一葉知秋”這個詞，比如《淮南子·說山訓(xùn)》:“見一葉落而知?dú)q之將暮”。這里是說憑借細(xì)微之處可以知道深遠(yuǎn)的東西，看到一片葉子落下，便知道一年將要到尾聲。還有 宋·唐庚《文錄》引唐人詩:“山僧不解數(shù)甲子，一葉落知天下秋?！笔钦f山里的和尚不知道怎么計算年月，從一片樹葉的凋落，就知道了秋天的到來。
這里一葉知秋也比喻通過個別的細(xì)微的跡象(事件），可以看到（分析）整個形勢的發(fā)展趨勢與結(jié)果。那么，這里葉落是事件，知秋是根據(jù)事件進(jìn)行分析得到的結(jié)果。那么我們追溯到這個詞語是怎么產(chǎn)生的時候，會自然的思考到底怎樣得出樹葉落下就要到秋天這個判斷的呢？我想那一定不是第一次看見落葉就能得到這個結(jié)論，而是有人（大腦）記錄了幾十次，上百次的現(xiàn)象（事件）觀察。因?yàn)槊看稳~落事件發(fā)生之后，都會規(guī)律的氣溫下降，進(jìn)入秋天的客觀事實(shí)作為依據(jù)，進(jìn)而得到“一葉知秋”的分析結(jié)果。這里面善于觀察總結(jié)的人類就是一臺流計算系統(tǒng)，輸入是隨時間產(chǎn)生的各種事件，這些事件包括葉落是事件，降溫入秋也是一個事件，人類的智慧通過分析找到了葉落這個事件和降溫入秋這個事件必然關(guān)系，這個關(guān)系就是分析的結(jié)果。就像我們每年進(jìn)入雙11大促，各個商家一定要補(bǔ)充庫存一樣，就像各個商家補(bǔ)充庫存，參加活動時候，每個電商系統(tǒng)背后的工程師就要進(jìn)行系統(tǒng)的擴(kuò)容，或者對技術(shù)體系進(jìn)行換代升級一樣，但是這里就沒有一葉知秋那么簡單了，比如要擴(kuò)容多少，性能提升多少能平穩(wěn)度過大促，這樣的數(shù)據(jù)可不是一個人腦能解決的，這樣就涉及到了計算機(jī)（電腦）了，當(dāng)然這也不是一臺計算機(jī)能解決的，而是一個計算機(jī)集群系統(tǒng)，這個大腦是一個集群，而流計算就是這個集群的思維方式之一。
其實(shí)，我們的生活中有很多這樣通過人類的智慧，對現(xiàn)實(shí)生活中大量的自然現(xiàn)象數(shù)據(jù)進(jìn)行分析推理，進(jìn)而得到的很多規(guī)律性認(rèn)知，比如：在四季分明的北方生活的朋友，一定知道“大雁南飛冬將至”。再比如我們對日月星云的分析總結(jié)相關(guān)的規(guī)律各說一個，如下：
日：紅日雨，白日風(fēng)，明星月朗大晴空。
月：月亮周圍有圓圈，刮風(fēng)就在明后天。
星：久雨見星光，明朝雨更狂
云：烏云接日頭，半夜雨不愁
風(fēng)：久晴西風(fēng)雨，久雨西風(fēng)晴
物：蟋蟀上房叫，莊稼挨水泡。
其實(shí)，我們生活在一個時間維度的現(xiàn)實(shí)世界，流計算只是將現(xiàn)實(shí)生活中的人類對自然數(shù)據(jù)分析能力的高度抽象與規(guī)模升級。既然，我們今天探究流計算之源，我們就再多說些和流計算相關(guān)的自然現(xiàn)象，供大家思考。
我們?nèi)祟愡@臺大的流計算系統(tǒng)，對自然界源源不斷輸入的客觀事件進(jìn)行分析沉淀，形成了很多客觀的規(guī)律數(shù)據(jù)，比如今天是2021年12月21日，也就是冬至日，針對冬至日的到來，人類也對冬至日之后的氣溫變化作出了精準(zhǔn)的預(yù)測：即，我們熟知的數(shù)九歌里面描述的，在冬至日之后的第一個9天和第二個9天，天氣變冷，外出必須帶上手套保暖。在第三個9天和第四個9天期間北方河流會河水成冰。一直到三個月左右就到了春耕的季節(jié)。這些其實(shí)都是根據(jù)歷史數(shù)據(jù)分析而得到的。
那么，像冬至這樣的節(jié)氣性總結(jié)，人類的智慧已經(jīng)總結(jié)出了24個節(jié)氣，這些都是成百上千年的迭代分析，才形成的分析結(jié)果。這些雖然只是人類無限智慧的冰山一角，但這些事實(shí)已經(jīng)證明了人類對自然現(xiàn)象強(qiáng)大的計算能力。
我們由一葉知秋，到冬至數(shù)九歌，到人類總結(jié)的24節(jié)氣，我們不難想象出人類本身就是一臺龐大的流計算系統(tǒng)，在隨著時間推移的歷史長河中，萬物變化的各類事件，經(jīng)過人類大腦不斷的進(jìn)行著學(xué)習(xí)計算，進(jìn)而人類具備了對萬事萬物未來發(fā)展的預(yù)測和判斷的能力。而這個過程中萬事萬物的變化事件就是輸入，人類對事件的認(rèn)知和對規(guī)律總結(jié)的利用來形成新的規(guī)律的過程就是計算分析。借助歷史沉淀的經(jīng)驗(yàn)對新事件進(jìn)行加工本身就是增量計算的體現(xiàn)，在這過程中，時間就是潛在存在的必要因素，而這些要素正是流計算產(chǎn)品所必備的核心要素。所以任何技術(shù)產(chǎn)品的原型都源于自然，流計算產(chǎn)品的源頭也是讓大家敬畏的宇宙自然。如果我們的技術(shù)體系完全能夠融合，完全的模擬和虛擬自然宇宙，我想元宇宙也就真的成為完整的現(xiàn)實(shí)虛擬了。
但這里我們也不難發(fā)現(xiàn)，人類這臺流計算系統(tǒng)最大的不足就是計算的周期太長了, 大數(shù)據(jù)時代我們需要流計算產(chǎn)品有更低的計算周期，更低的計算延遲，進(jìn)而最大程度的讓數(shù)據(jù)產(chǎn)生價值，為人類決策進(jìn)行有力支撐。
02 價值空間
以終為始 – 目標(biāo)（創(chuàng)造價值）
今天和大家分享的整體思維邏輯是“以終為始”，我們先知道我們最終要達(dá)成的目標(biāo)，再反向規(guī)劃流計算產(chǎn)品所應(yīng)該具有的未來。第一個點(diǎn)，我們思考流計算產(chǎn)品的最終目標(biāo)是什么？每個人思考的維度不同，視角不同，回答流計算產(chǎn)品的目標(biāo)就可能有不同的答案，但不論從哪個視角給出的流計算產(chǎn)品目標(biāo)，最終在持續(xù)挖掘，逐本溯源之后都會回到一個最簡單，甚至大家認(rèn)為是廢話的答案：“那就是流計算產(chǎn)品最終的目的是讓Data產(chǎn)生價值“。是讓Data經(jīng)過流計算產(chǎn)品的處理最終讓Data產(chǎn)生預(yù)期的價值。這個目標(biāo)看起來簡單，后面逐層的為大家分析如何才能達(dá)成這么一個簡單的目標(biāo)時候，大家就會發(fā)現(xiàn)，簡單的目標(biāo)蘊(yùn)含著巨大的挑戰(zhàn)。包括技術(shù)層面，產(chǎn)品層面，業(yè)務(wù)領(lǐng)域等各個維度都充滿著不同和挑戰(zhàn)。我們繼續(xù)往下聊...
以終為始 – 空間（1000億+市場）
這里我們說流計算產(chǎn)品有千億的價值空間，當(dāng)然，這個空間不是我個人空想出來的，我們有權(quán)威機(jī)構(gòu)統(tǒng)計數(shù)據(jù)。
這里我們會發(fā)現(xiàn)來自權(quán)威的市場分析報告，流分析從2020年有125億的市場空間，到2025年有386億的潛在市場，我們大概換成人民幣是從2020年800億到2025年2470億的增長，從這些數(shù)字我們看到每年增長率高達(dá)每年25.2%。這是一個流計算產(chǎn)品提供商流口水的數(shù)字，這是讓流計算產(chǎn)品工程師對未來充滿希望的數(shù)字。流計算產(chǎn)品有這么大的空間，那么在整個公有云的市場空間是怎樣的呢？
根據(jù)Gartner的最新預(yù)測，全球公共云服務(wù)的最終用戶支出預(yù)計將在2021增長23.1%至3323億美元，遠(yuǎn)高于2020年的2700億美元。相對公有云市場空間和全球流計算市場空間來看，這些數(shù)字在彰顯云計算市場空間之余，也證明著流計算產(chǎn)品在整個云計算產(chǎn)品生態(tài)體系里面的重要地位，流計算市場空間是公有云市場空間的近20%。這是我們在流計算產(chǎn)品持續(xù)精耕細(xì)作的巨大使命動力。那么，我們流計算產(chǎn)品應(yīng)該長成什么樣子呢？
03 核心場景
以終為始 – 場景（Integration + Analytics）
流計算產(chǎn)品長成什么樣子，完全取決于流計算產(chǎn)品所要解決的業(yè)務(wù)場景，不論流計算產(chǎn)品可以解決怎樣的業(yè)務(wù)場景，我們都知道巧女難做無米之炊，那么流計算產(chǎn)品發(fā)揮自身價值的前提是什么呢？最簡單的表達(dá)就是流計算產(chǎn)品首先要有Data作為輸入，當(dāng)然按照這樣的思考流計算最終輸出也是一系列的Data。那么輸入是Data，輸出也是Data的流計算產(chǎn)品，可以讓輸出Data和輸入Data有怎樣的不同，就是流計算產(chǎn)品所具備的產(chǎn)品能力。我們把這個能力宏觀展開一下看，到底流計算產(chǎn)品應(yīng)該具備支持怎樣業(yè)務(wù)場景的解決能力。
這里被大家熟知的有兩個比較宏觀的能力需求就是：“數(shù)據(jù)集成”和“數(shù)據(jù)分析”。我們將這兩種能力稍微展開一點(diǎn)來對每種能力進(jìn)行描述。
第一個就是數(shù)據(jù)集成場景能力，該類場景側(cè)重于解決數(shù)據(jù)到達(dá)時不需要立即進(jìn)行數(shù)據(jù)分析的業(yè)務(wù)情況，但這些場景需要在數(shù)據(jù)到達(dá)時立即進(jìn)行實(shí)時的數(shù)據(jù)接收，并有一定的數(shù)據(jù)過濾和數(shù)據(jù)變化需求。比如ETL(Extraction, Transformation, Loading )，CDC（Change data capture)等。最終數(shù)據(jù)會存儲到數(shù)據(jù)湖或者數(shù)據(jù)倉/庫等存儲系統(tǒng)，供以后對靜態(tài)數(shù)據(jù)進(jìn)行分析。也就是說，數(shù)據(jù)集成能力是要求流計算產(chǎn)品作為大數(shù)據(jù)產(chǎn)品生態(tài)體系的數(shù)據(jù)連接器，具備外部系統(tǒng)連接和數(shù)據(jù)輸出到外部系統(tǒng)的能力即可，這里強(qiáng)調(diào)需要一個實(shí)時性的需求。
那么第二個“數(shù)據(jù)分析”場景需要的能力具體一點(diǎn)如何描述呢？數(shù)據(jù)分析類場景，核心是對需要在數(shù)據(jù)到達(dá)時候，立即對數(shù)據(jù)進(jìn)行連續(xù)的動態(tài)分析，并需要精準(zhǔn)的分析結(jié)果供下游業(yè)務(wù)系統(tǒng)使用。比如對電商數(shù)據(jù)、傳感器數(shù)據(jù)和服務(wù)器日志數(shù)據(jù)等進(jìn)行實(shí)時性要求很強(qiáng)的聚合分析、數(shù)據(jù)預(yù)測、進(jìn)而達(dá)成監(jiān)控預(yù)警和智能決策等業(yè)務(wù)目的。數(shù)據(jù)分析類場景對流計算產(chǎn)品提出更高的能力要求。也就是說，這個場景能力需求，不但要求流計算產(chǎn)品有數(shù)據(jù)連接能力，還需要有對數(shù)據(jù)進(jìn)行復(fù)雜的聚合，預(yù)測甚至是決策等更高要求的能力滿足，并且特別要強(qiáng)調(diào)這些分析的能力是要求實(shí)時的，對處理的時效有很高的要求，當(dāng)然這也是流計算產(chǎn)品當(dāng)仁不讓的職責(zé)所在。
雖然我們對這兩點(diǎn)能力進(jìn)行了描述，但是對于在流計算產(chǎn)品投入時間較少的朋友來說，還是不清楚流計算產(chǎn)品到底需要進(jìn)行有怎樣的具體功能開發(fā)，那么我們再掰碎一點(diǎn)看看。
第一部分我看數(shù)據(jù)集成部分，顧名思義數(shù)據(jù)集成是對外部系統(tǒng)的集成能力，那么流計算產(chǎn)品要集成哪些類型的外部系統(tǒng)呢？
我們把外部系統(tǒng)的統(tǒng)稱為流數(shù)據(jù)的制造者，這些制造者包括物，包括人，包括系統(tǒng)，也就是 Things/Persons/Platforms。這些流數(shù)據(jù)的制造者產(chǎn)生的數(shù)據(jù)具備很明顯的特點(diǎn)，就是種類多，體量大，實(shí)效性比較強(qiáng)。那么面對這樣的數(shù)據(jù)特點(diǎn)，流計算產(chǎn)品支持?jǐn)?shù)據(jù)集成場景需要怎樣的能力呢？
首先在具備連接能力之外還需要對每種連接有豐富的數(shù)據(jù)format能力，其次對于無用的數(shù)據(jù)具備簡單實(shí)用的數(shù)據(jù)過濾能力，特別強(qiáng)調(diào)一點(diǎn)，出于成本和效率的思考，流計算產(chǎn)品針對不同外部鏈接過濾能力的下沉是非常重要的實(shí)現(xiàn)要點(diǎn)。除此之外還需要具備的簡單轉(zhuǎn)化能力，比如各種scalar的轉(zhuǎn)換能力等待。在這個場景中，數(shù)據(jù)的轉(zhuǎn)換能力要不高，但對流計算產(chǎn)品的吞吐能力和實(shí)時性有很高的要求。這個要求也充分體現(xiàn)了流計算產(chǎn)品，流本身的自然語義。
當(dāng)然，數(shù)據(jù)處理之后最終還是要流入其他下游系統(tǒng)，數(shù)據(jù)流出就需要對數(shù)據(jù)質(zhì)量（對于下游業(yè)務(wù)系統(tǒng)來說）有很高的要求，這是數(shù)據(jù)價值的第一層面體現(xiàn)。下游系統(tǒng)我們歸類稱之為是 流數(shù)據(jù)的消費(fèi)者。在數(shù)據(jù)集成場景中，流數(shù)據(jù)的消費(fèi)者往往具備數(shù)據(jù)分析的能力。如 數(shù)據(jù)倉庫，數(shù)據(jù)湖等。
那么如果流計算產(chǎn)品不但承擔(dān)數(shù)據(jù)集成職責(zé)還要具備數(shù)據(jù)分析能力的話，我們應(yīng)該在流計算產(chǎn)品上開發(fā)怎樣的能力呢？
最簡單的數(shù)據(jù)分析，可以進(jìn)行數(shù)據(jù)的reduce操作，我們也叫做聚合操作，當(dāng)然聚合操作面對無限的流數(shù)據(jù)場景，還會必然的有各種數(shù)據(jù)分組的能力的要求，也就是數(shù)據(jù)窗口的抽象能力，面對各種復(fù)雜的系統(tǒng)數(shù)據(jù)，數(shù)據(jù)之間的各種Join能力也是必不可少的，這里面由于有聚合函數(shù)的高度抽象和用戶自定義能力開放 ，在框架清晰、能力開放的流計算產(chǎn)品中，流計算產(chǎn)品可以讓用戶有無限的創(chuàng)作空間。
也正是因?yàn)榫邆鋽?shù)據(jù)分析能力的流計算產(chǎn)品可以幫助用戶做更多的數(shù)據(jù)處理，進(jìn)而下游的業(yè)務(wù)系統(tǒng)也會相對于只具備數(shù)據(jù)集成能力的流計算產(chǎn)品有很大的不同，下游系統(tǒng)距離終端用戶會越來越近，比如可以直接對BI系統(tǒng)，直接對接監(jiān)控報警系統(tǒng)。同時，具備數(shù)據(jù)分析能力的流計算產(chǎn)品除了具備實(shí)時性的挑戰(zhàn)之外，還需要有數(shù)據(jù)分析結(jié)果高精準(zhǔn)的要求。
實(shí)時性和數(shù)據(jù)分析精準(zhǔn)性分開來看待時候，相對容易達(dá)成，但是如果要求實(shí)時性和精準(zhǔn)性同時滿足的時候，對流計算產(chǎn)品是一個巨大的挑戰(zhàn)，后面我會和大家一起分析業(yè)界的現(xiàn)有解決手段，以及現(xiàn)有解決方案的不足，甚至和大家一起YY未來的可能的解決方向。
這里我們還要有一點(diǎn)注意那就是閉環(huán)問題，整個大數(shù)據(jù)產(chǎn)品生態(tài)體系，不僅僅只有流計算產(chǎn)品這是大家共識的，但流計算產(chǎn)品在整個大數(shù)據(jù)產(chǎn)品生態(tài)體系里面，讓數(shù)據(jù)產(chǎn)生業(yè)務(wù)價值的過程中，也并不是一條業(yè)務(wù)數(shù)據(jù)處理鏈路中只使用一次流計算產(chǎn)品，更多的可能是流計算產(chǎn)品流出的數(shù)據(jù)經(jīng)過其他領(lǐng)域性系統(tǒng)處理之后還會將數(shù)據(jù)再次流入流計算產(chǎn)品，這一客觀事實(shí)對流計算產(chǎn)品的數(shù)據(jù)結(jié)構(gòu)的設(shè)計和流計算各種語義設(shè)計提出了顯而易見的高要求，這里說一個例子，比如：Apache Flink中RowData的數(shù)據(jù)結(jié)構(gòu)設(shè)計和為了在流計算場景下解決數(shù)據(jù)計算精準(zhǔn)性問題撤回機(jī)制的設(shè)計等，都是需要考慮流計算流出的數(shù)據(jù)是有可能反復(fù)流入到流計算產(chǎn)品的。那么流計算產(chǎn)品面對這樣的業(yè)務(wù)場景和需要的功能抽象中，有哪些具體的技術(shù)難點(diǎn)挑戰(zhàn)呢？下面我們挑1-2個重點(diǎn)分析一下。
04 技術(shù)挑戰(zhàn)
以終為始 – 技術(shù)(Low-Latency)
對于流計算產(chǎn)品來說，不論是只具備數(shù)據(jù)集成能力，還是一并具備數(shù)據(jù)分析能力，實(shí)時性都是流計算產(chǎn)品至關(guān)重要的技術(shù)挑戰(zhàn)。那么怎樣的計算延時才算是具備實(shí)時性呢？是分鐘？秒？毫秒還是微妙？那么不論我們在技術(shù)上將實(shí)時性達(dá)到怎樣的級別，我們都要考慮哪些設(shè)計因素決定了流計算產(chǎn)品的計算實(shí)時性呢？
宏觀來看，流計算產(chǎn)品實(shí)時性有兩個非常重要的實(shí)時性設(shè)計因素，一個是待計算的數(shù)據(jù)，一個是計算的時鐘，我們前面說到流計算產(chǎn)品就是可以處理流事件的產(chǎn)品，流事件的核心是事件和時間，所以實(shí)時性設(shè)計和時間密不可分。那么這兩個核心因素會對計算實(shí)時性有怎樣的設(shè)計影響呢？
由這兩個因素激發(fā)了兩種不同的設(shè)計思維，一種是我們可以數(shù)據(jù)驅(qū)動的方式設(shè)計流計算產(chǎn)品的實(shí)時性機(jī)制，也就是我可以單位數(shù)據(jù)觸發(fā)計算一次，當(dāng)然單位數(shù)據(jù)可以是1條數(shù)據(jù)。另一種思考方向是我可以是單位時間觸發(fā)一次計算，比如每秒觸發(fā)一次，這種設(shè)計同樣在理論上也可以達(dá)到足夠的實(shí)時性。至于說哪個思維更好？我們需要結(jié)合工程實(shí)踐綜合來看。
對于第一種思維的設(shè)計模式我們簡單描述一下：“流更多的形容數(shù)據(jù)流，以數(shù)據(jù)流的自然狀態(tài)設(shè)計觸發(fā)計算的模型，我們稱之為流計算，單位數(shù)據(jù)為1條數(shù)據(jù)的時候，計算的觸發(fā)是最及時的，計算結(jié)果的延時也是理論最低的。當(dāng)數(shù)據(jù)單位由1條延展到多條時候，多條可以認(rèn)為是一個批次，進(jìn)而得到批是流的特例認(rèn)知?！?/p>
對于第二種思維的設(shè)計模式我們也文字描述一下：“單位時間所蓄積的數(shù)據(jù)，我們稱之為一批數(shù)據(jù)，以一批數(shù)據(jù)作為計算單元觸發(fā)計算的模型，我們稱之為批計算，極端情況下1毫秒積攢一批數(shù)據(jù)進(jìn)行觸發(fā)計算，也是該模型下是最及時的，計算結(jié)果的延時也是理論最低的。進(jìn)而得到流是批的特例認(rèn)知?！?/p>
很幸運(yùn)這兩種思考模式都有對應(yīng)的開源工程實(shí)現(xiàn)，青睞 “批是流的特例“ 的Apache Flink，和認(rèn)為 “流是批的特例” 的Apache Spark，兩個計算框架都是目前最優(yōu)秀的開源實(shí)現(xiàn)，這兩種實(shí)現(xiàn)，在一定的場景下也都實(shí)現(xiàn)了低延時的特定技術(shù)指標(biāo)。
也就是說，流計算模型和批計算模型都能在一定程度上達(dá)到了Low-Latency，那么理論指導(dǎo)工程實(shí)踐，工程實(shí)踐探知業(yè)務(wù)疾苦，有的時候我們不走極端，因?yàn)榇讼碎L，物極必反。后面我們會看到為啥在流計算產(chǎn)品的設(shè)計中也會有“此消彼長”的影子。
以終為始 – 技術(shù)(High-Accuracy)
除了實(shí)時性的關(guān)鍵技術(shù)指標(biāo)要求，流計算產(chǎn)品更需要滿足計算準(zhǔn)確性的現(xiàn)實(shí)要求，業(yè)務(wù)數(shù)據(jù)的分析計算就是需要有一個準(zhǔn)確的計算結(jié)果供下游業(yè)務(wù)使用，比如金融領(lǐng)域，數(shù)字準(zhǔn)確性至關(guān)重要，還有甚至是計算的結(jié)果數(shù)據(jù)可能作為企業(yè)重要的決策依據(jù)，種種應(yīng)用場景對數(shù)據(jù)分析的精準(zhǔn)性要求甚高。面對這樣的業(yè)務(wù)場景，流計算產(chǎn)品如何才能保證計算的準(zhǔn)確性呢？
我們還是要從關(guān)鍵因素切入思考，第一個很現(xiàn)實(shí)的情況是現(xiàn)實(shí)生活生產(chǎn)中的流數(shù)據(jù)由于種種原因會產(chǎn)生延時，數(shù)據(jù)延時情況也造成計算結(jié)果需要進(jìn)行更新，不但這種數(shù)據(jù)延時可以造成計算結(jié)果需要更新，某些特定的業(yè)務(wù)邏輯也會造成數(shù)據(jù)計算結(jié)果需要產(chǎn)生更新，簡單列舉幾個場景如下：
比如，物聯(lián)網(wǎng)領(lǐng)域很多弱網(wǎng)環(huán)境導(dǎo)致不同設(shè)備上送的數(shù)據(jù)的順序和數(shù)據(jù)在設(shè)備端產(chǎn)生的時間順序是不一致的，現(xiàn)實(shí)生活中也有，比如實(shí)時統(tǒng)計航班的售賣情況，但是有客戶今天購買了機(jī)票，明天有取消了機(jī)票，那計算結(jié)果是不是也涉及到了更新？很多現(xiàn)實(shí)業(yè)務(wù)都對流計算產(chǎn)品提出了要支持?jǐn)?shù)據(jù)延時和數(shù)據(jù)更新的能力。
當(dāng)然這些實(shí)際存在的問題都需要以某種技術(shù)手段來解決，當(dāng)然我們進(jìn)行技術(shù)抽象的目標(biāo)也是解決業(yè)務(wù)場景的實(shí)際訴求，比如監(jiān)控預(yù)警對實(shí)時性要求很高，流計算在處理源源不斷的流事件時候，不僅希望計算結(jié)果能夠快速產(chǎn)生，同時也期望雖然數(shù)據(jù)延時、數(shù)據(jù)更新都是一種客觀存在，但業(yè)務(wù)仍然期望延時和更新對后續(xù)計算結(jié)果的影響面縮小到最小，那么流計算產(chǎn)品如何最大程度達(dá)成這一目標(biāo)呢？
首先我們前面介紹了流計算產(chǎn)品在支撐數(shù)據(jù)分析場景時候所具備的一些能力，比如 聚合/窗口等等能力。
其中窗口劃分解決了數(shù)據(jù)分組問題，在滿足業(yè)務(wù)本身需要數(shù)據(jù)分組計算的同時，也能讓某條延時數(shù)據(jù)只影響其對應(yīng)的窗口計算結(jié)果，同時以Apache Flink 為例，對于無窗口聚合計算是每條數(shù)據(jù)都輸出計算結(jié)果到下游，達(dá)到了低延時的業(yè)務(wù)要求，同時也依托于retraction機(jī)制解決了數(shù)據(jù)更新帶來的計算精準(zhǔn)性問題（但這個case如果出現(xiàn)failover的框架級別錯誤時候，依然無法解決計算精準(zhǔn)性問題）。也就是說這些技術(shù)點(diǎn)只是在某一個計算分析能力下，某個特定的局部邊界線下作出的具體工程實(shí)現(xiàn)，解決了局部問題，那么在流計算產(chǎn)品中，有沒有更高層面的語義抽象，能夠覆蓋流計算產(chǎn)品所有場景的支持，也就是在流計算領(lǐng)域有沒有關(guān)于計算精準(zhǔn)性的語義抽象呢？
我們首先要說明一下需要達(dá)成的共識，那就是這里我們討論的數(shù)據(jù)計算的準(zhǔn)確性問題，不是由于業(yè)務(wù)邏輯bug導(dǎo)致的計算結(jié)果不準(zhǔn)確，而是流計算框架層面是否能保證預(yù)期參與計算的數(shù)據(jù)都能在任何異常情況下也按預(yù)期的要求參與計算。在這個共識下，流計算差評從數(shù)據(jù)參與計算的次數(shù)不同進(jìn)行了不同計算準(zhǔn)確性的語義抽象，那就是：Exactly-once, At-least-once, At-most-once三種核心的語義抽象。
這里我們也會發(fā)現(xiàn)，其實(shí)產(chǎn)品技術(shù)解決業(yè)務(wù)疾苦，業(yè)務(wù)疾苦會驅(qū)動產(chǎn)品技術(shù)發(fā)展，流計算的理論和概念的誕生都是為解決業(yè)務(wù)問題而進(jìn)行抽象定義的。接下來我們一起看看這個三個不同的語義抽象的含義。
首先我們看一下At-most-once，至多一次的計算語義是參與計算的數(shù)據(jù)，最多只參與一次計算，在系統(tǒng)異常情況會造成數(shù)據(jù)丟失。比如，計算SUM值，這種語義模式下計算結(jié)果 <= 真實(shí)值 （丟數(shù)據(jù)）
At-least-once，至少一次的計算語義是參與計算的數(shù)據(jù)，至少參與一次計算，在系統(tǒng)異常情況會造成數(shù)據(jù)多次參與計算。比如，計算SUM值，這種語義模式下計算結(jié)果 >= 真實(shí)值（重復(fù)計算）
Exactly-once，精準(zhǔn)一次的計算語義是參與計算的數(shù)據(jù)，參與且只參與一次計算，在系統(tǒng)異常情況計算框架保障數(shù)據(jù)不丟失，不重復(fù)，比如，計算SUM值，這種語義模式下計算結(jié)果 == 真實(shí)值（準(zhǔn)確性完美）。
從定義抽象上看，似乎Exactly-once是最好的業(yè)務(wù)需要，那么為什么不能直接就全部保持Exactly-once呢，也就是為啥還需要 At-least-once和At-most-once的語義抽象呢？這里就是我們之前提到的此消彼長的原因，完美的理論設(shè)計往往會對工程實(shí)踐帶來巨大的技術(shù)挑戰(zhàn)，當(dāng)然挑戰(zhàn)因素往往不在一個單一的產(chǎn)品層面就可以得到完美解決，可能涉及到網(wǎng)絡(luò)，存儲，計算等等各個層面的綜合演進(jìn)才能完成。對于我們目前討論的流計算數(shù)據(jù)分析精準(zhǔn)性語義抽象的工程實(shí)踐就涉及到了低延時和高精準(zhǔn)同時具備的工程實(shí)現(xiàn)的相互影響。以Apache flink為例，這里面涉及到的技術(shù)點(diǎn)有很多，包括Checkpoint機(jī)制，包括Statebackend技術(shù)，包括分布式存儲技術(shù)，扣到細(xì)節(jié)也會涉及到Flink內(nèi)部的網(wǎng)絡(luò)層面設(shè)計等等細(xì)分的技術(shù)點(diǎn)。這些技術(shù)點(diǎn)在Apache Flink知其然，知其所以然的課程里面會分章節(jié)進(jìn)行細(xì)致介紹，大家可以看完今天的宏觀介紹在去各個章節(jié)進(jìn)行細(xì)的知識點(diǎn)的了解，然后再回過頭來考慮這些知識點(diǎn)之間的聯(lián)系。那么我們今天還是從宏觀視角繼續(xù)看流計算領(lǐng)域如何在更高層面解決 低延時和高計算精準(zhǔn)性問題。
以終為始 – 技術(shù)(流批一體)
低延時要求流計算框架盡可能早的輸出計算結(jié)果，但是由于存在數(shù)據(jù)延時和現(xiàn)實(shí)業(yè)務(wù)數(shù)據(jù)更新的客戶情況，就會導(dǎo)致你前一秒計算的結(jié)果，因?yàn)橄乱幻雭砹艘粋€對上一秒已經(jīng)參與計算的那條數(shù)據(jù)的更新，進(jìn)而導(dǎo)致在下一秒時候上一秒的計算結(jié)果就是無效的了，那么流計算產(chǎn)品低延時需求導(dǎo)致流計算產(chǎn)品不可能無限制的等待延時數(shù)據(jù)的到來，這就一定會造成數(shù)據(jù)計算結(jié)果不精準(zhǔn)的問題。如果流計算產(chǎn)品想讓自己的計算結(jié)果更準(zhǔn)確，那就需要忍受對延時數(shù)據(jù)進(jìn)行更長時間的等待，那就意味著流計算產(chǎn)品的低延時無法達(dá)成，所以在流計算產(chǎn)品中魚和熊掌兼得是不那么容易的。
流計算產(chǎn)品無法達(dá)成，這并不代表從業(yè)務(wù)層面無法達(dá)成既要低延時又要計算結(jié)果高精準(zhǔn)的目標(biāo)。那就是我們可以跳出流計算單品，以大數(shù)據(jù)產(chǎn)品生態(tài)體系的視角再看看業(yè)務(wù)層面要求低延時+高精準(zhǔn)的目標(biāo)如何達(dá)成。
數(shù)據(jù)的計算精準(zhǔn)性問題是由于數(shù)據(jù)變化更新導(dǎo)致的，那么如果我們參與計算的數(shù)據(jù)都是不變化的，那么就意味著我們計算的結(jié)果一定是準(zhǔn)確的了，所以從業(yè)務(wù)層面我們可以利用批計算的方式修正流計算的結(jié)果。
也就是說，批計算的數(shù)據(jù)特點(diǎn)首先是沒有數(shù)據(jù)延時，也沒有數(shù)據(jù)更新，因?yàn)檫@里的批計算有一定的業(yè)務(wù)含義，這里我們說批計算一般是業(yè)務(wù)層面斷定參與計算的數(shù)據(jù)是不變化的，比如我們熟知的T+1的計算方式。今天只計算昨天的數(shù)據(jù)，從時間維度看，打上昨天標(biāo)簽的數(shù)據(jù)都是歷史數(shù)據(jù)，不會改變了。那么分析到這里我們是否可以發(fā)現(xiàn)流批計算中有一個本質(zhì)的數(shù)據(jù)特征？
從數(shù)據(jù)特征角度看流批計算的本質(zhì)區(qū)別，流計算所處理的數(shù)據(jù)是持續(xù)變化的，變化是一種常態(tài) - Dynamic Data，批計算所處理的數(shù)據(jù)保持靜止的，靜止是一種常態(tài) - Static Data。
這里的批計算和流計算與前面我們講的流計算模型和批計算模型并不是同一個維度的概念，這里的流計算更多的是說業(yè)務(wù)維度，使用流計算產(chǎn)品的實(shí)時計算模式，以Apache Flink來說就是PIPELINE模式，這里的批計算更強(qiáng)調(diào)參與計算的數(shù)據(jù)是歷史不變化的數(shù)據(jù)，我們可以認(rèn)為是數(shù)據(jù)不變的情況下批計算模式是對流計算模式的性能和數(shù)據(jù)精準(zhǔn)性的提升，以Apache Flink為例來說批計算就是就是BLOCK模式。這里分享一個觀點(diǎn)，在我看來：“流計算模式是批計算模式的低延時優(yōu)化，批計算模式是流計算模式的高性能和高精準(zhǔn)的優(yōu)化”。有了這個觀點(diǎn)之后，那么企業(yè)可以根據(jù)自己業(yè)務(wù)的實(shí)際特點(diǎn)判斷是低延時對自己業(yè)務(wù)價值影響更大，還是數(shù)據(jù)計算精準(zhǔn)性對其業(yè)務(wù)價值影響更大，還是兩者都有很大的影響，進(jìn)而判斷自己的業(yè)務(wù)是選擇流計算模式還是選擇批計算模式，甚至以增加計算成本搏取業(yè)務(wù)價值空間，選擇批計算模式和流計算模式相結(jié)合的計算方案。
以終為始 – 流批一體(Lambda 架構(gòu))
那么，目前業(yè)界有哪些流計算和批計算相結(jié)合的架構(gòu)可以滿足低延時和高精準(zhǔn)的既要又要的需求呢？
數(shù)據(jù)都是伴隨著時間產(chǎn)生的，并且拋棄業(yè)務(wù)賦予的其他屬性，只從時間維度去看，每一條數(shù)據(jù)都是唯一的，也就是在時間線上都是一條條append only的數(shù)據(jù)。所以對于我們認(rèn)為歷史數(shù)據(jù)是靜態(tài)數(shù)據(jù)，當(dāng)下數(shù)據(jù)是動態(tài)數(shù)據(jù)也是因?yàn)橘x予了數(shù)據(jù)業(yè)務(wù)特征之后才成立的說法。比如除了時間屬性我們再添加訂單號，那么就因?yàn)榫邆淞藰I(yè)務(wù)屬性，才導(dǎo)致不同時間點(diǎn)，相同訂單號的數(shù)據(jù)就具備了關(guān)聯(lián)性，也就是有數(shù)據(jù)更新的可能，那么在業(yè)務(wù)維度去劃分一定的有效窗口之后，比如1天的訂單變化都是影響業(yè)務(wù)數(shù)據(jù)統(tǒng)計的，那么1天以前前的數(shù)據(jù)就可以在這樣的業(yè)務(wù)規(guī)則下變成歷史數(shù)據(jù)了，從現(xiàn)在開始源源不斷產(chǎn)生的數(shù)據(jù)就都是動態(tài)數(shù)據(jù)了。這個思考有一點(diǎn)點(diǎn)繞，大家下來靜心思考一下是不是這個道理。
基于這樣的數(shù)據(jù)劃分思考，我們可以選擇處理這兩類數(shù)據(jù)的技術(shù)產(chǎn)品。我們將整個架構(gòu)體系里面既有流計算處理鏈路，又有批計算處理鏈路的計算架構(gòu)叫做流批一體架構(gòu)。我們當(dāng)前如圖顯示的架構(gòu)就是流批一體的Lambda架構(gòu)，這個架構(gòu)流計算和批計算最終是為了服務(wù)最終的Serving layer，也即是在查詢服務(wù)層可以實(shí)時的查詢當(dāng)下數(shù)據(jù)的計算結(jié)果。
但隨著時間的推移，批計算的精準(zhǔn)結(jié)果再修正流計算實(shí)時產(chǎn)有潛在偏差的結(jié)果，進(jìn)而保證低延時的同時也保證了計算結(jié)果的高精準(zhǔn)。這個架構(gòu)很好的一個特點(diǎn)就是，流計算只注重極致的實(shí)時性，在計算的優(yōu)化規(guī)則方面也根據(jù)流計算的特點(diǎn)進(jìn)行優(yōu)化選擇。在批計算的時候只注重數(shù)據(jù)的計算結(jié)果精準(zhǔn)性，同時優(yōu)化規(guī)則的選擇也結(jié)合批計算的特點(diǎn)選擇性能更好的規(guī)則。比如雖然流批都是JOIN的邏輯，但是批可以選擇sortedjoin，而流計算模式就不可以選擇了。
那么在現(xiàn)實(shí)生產(chǎn)系統(tǒng)里面大多的業(yè)務(wù)數(shù)據(jù)劃分歷史數(shù)據(jù)的方式一般以自然天或者業(yè)務(wù)天為單位進(jìn)行劃分，也即是我們經(jīng)常說的T+1.
這樣的相同數(shù)據(jù)分別由批計算模式計算一遍，在用流計算模式跑一遍的Lamdba架構(gòu)，有哪些不足呢？Lambda架構(gòu)核心是成本問題：多份數(shù)據(jù)存儲成本，多API開發(fā)成本，多引擎運(yùn)維成本等等。那么我們有沒有其他更優(yōu)化的方案呢？
以終為始 – 流批一體(Kappa 架構(gòu))
為了解決Lambda架構(gòu)多引擎的維護(hù)，一套業(yè)務(wù)多套API開發(fā)的不足，Kafka生態(tài)體系又提出了Kappa架構(gòu)，這個架構(gòu)一個非常大的優(yōu)點(diǎn)就是用戶一套業(yè)務(wù)只需用一套API開發(fā)，用戶只維護(hù)一份業(yè)務(wù)代碼，運(yùn)維一個引擎，這在實(shí)際的生產(chǎn)開發(fā)運(yùn)維中相比Lamdba有了很大的改善，但是Kappa架構(gòu)是如何做到實(shí)時性和精準(zhǔn)性的呢？
其實(shí)是利用了存儲系統(tǒng)的數(shù)據(jù)回放能力，也就是如果從流計算產(chǎn)生了計算結(jié)果精準(zhǔn)性問題，利用同一套只具有流計算模式的計算引擎全量回放一下歷史數(shù)據(jù)，由于是歷史數(shù)據(jù)，數(shù)據(jù)沒有延時，也沒有更新，進(jìn)而即便是流計算模式的計算引擎在進(jìn)行靜態(tài)數(shù)據(jù)計算時候，再加上采用精準(zhǔn)一次的計算語義模式下是可以達(dá)到數(shù)據(jù)計算結(jié)果的高精準(zhǔn)的。
這樣的架構(gòu)特點(diǎn)，大家也不難發(fā)現(xiàn)Kappa框架本身也有其潛在的弊端，比如都是流計算模式的引擎在算法優(yōu)化規(guī)則的選擇上有很大的局限性，進(jìn)而也造成資源的浪費(fèi)。同時以流的模式重放全量數(shù)據(jù)，在批計算和流計算并行進(jìn)行時候，會對存儲系統(tǒng)產(chǎn)生很大的IO壓力。
這里有一篇對Kappa架構(gòu)有很好的分析的文章推薦大家進(jìn)行延展閱讀。https://www.kai-waehner.de/blog/2021/09/23/real-time-kappa-architecture-mainstream-replacing-batch-lambda/
以終為始 – 流批一體(Enhanced generation)
目前流批一體的架構(gòu)體系還不夠完善，流批一體本身在概念層面業(yè)界還存在很大的不同認(rèn)知，那么從我的角度看流批一體應(yīng)該具備怎樣的特點(diǎn)呢？這里和大家分享幾點(diǎn)共同交流。
第一點(diǎn)，流批用戶無感，從用戶層面去看流批一體，從技術(shù)實(shí)現(xiàn)上應(yīng)該流批應(yīng)該對用戶是無感的，流計算和批計算在用戶視角看是業(yè)務(wù)計算的延遲上面有區(qū)別，用戶本身并不關(guān)心是流計算模式還是批計算模式。也就是如果你能達(dá)到計算準(zhǔn)確并且延時在業(yè)務(wù)接受的范圍內(nèi)，用戶本身不關(guān)心計算框架采用怎樣的計算模式。
第二點(diǎn)，流批一套API，從開發(fā)層面看，用戶既不關(guān)心引擎的計算模式，更不愿意為了達(dá)到計算準(zhǔn)確性和計算低延時而利用兩套API進(jìn)行相同業(yè)務(wù)開發(fā)，那么也就是流批一體首先應(yīng)該確保API層面對用戶流批透明，有一套統(tǒng)一的API對用戶可見。
第三點(diǎn)，單引擎運(yùn)維，從運(yùn)維層面看，用戶不想維護(hù)多套計算引擎，兩套計算引擎的維護(hù)，必然也會造成第二點(diǎn)提及的開發(fā)困擾，同時增加更多的運(yùn)維成本。
第四點(diǎn)，流批自動切換，技術(shù)角度去看，流批一體的計算引擎，流計算和批計算的模式，不是在作業(yè)啟動的時候進(jìn)行二選一的配置，而是根據(jù)作業(yè)算子的特點(diǎn)，業(yè)務(wù)延時要求的配置等等綜合因素進(jìn)行引擎內(nèi)部的自動選擇。也就是說，我更認(rèn)為批計算是流計算在性能和計算精準(zhǔn)性方面的優(yōu)化選擇，流計算是批計算在延時性方面的優(yōu)化選擇。流批一體的計算引擎應(yīng)該對用戶來說是黑盒子，有能力具備按照用戶的業(yè)務(wù)目標(biāo)自動化選擇流批計算模式。
第五點(diǎn)，客戶第一，其實(shí)不是技術(shù)特點(diǎn)，而是流計算產(chǎn)品必須要擔(dān)負(fù)的職責(zé)，為用戶節(jié)約成本，為用戶創(chuàng)造價值。這雖然是一句愿景的話，但這對流計算產(chǎn)品提出了巨大的挑戰(zhàn)，流批一體本身也是為了完成這一職責(zé)所產(chǎn)生的技術(shù)架構(gòu)。
那么，就流批一體的技術(shù)體系而言，在現(xiàn)有的架構(gòu)方案中，我們接下來從哪些維度可以在為用戶創(chuàng)造更大價值的同時，還能為用戶節(jié)約更多的成本呢？
這里拋磚引玉，我們是否可以在計算和存儲層面有更多的思考，讓存儲加速計算，并節(jié)約用戶成本，為用戶創(chuàng)造更大的價值呢？
以終為始 – 流批一體(存儲+計算)
其實(shí)以存儲換取計算速度的技術(shù)在傳統(tǒng)的數(shù)據(jù)庫里面已經(jīng)有了很好的技術(shù)抽象和落地實(shí)現(xiàn)了，比如，物化視圖，一般物化視圖有2種方式，一是ON DEMAND，一是ON COMMIT，其中ON COMMIT的方式有更好的實(shí)時性體體現(xiàn)。那么在流計算產(chǎn)品里面我們有哪些存儲加速計算的場景呢，其實(shí)在Apache Flink里面也有這樣的影子，比如試圖和SQL復(fù)用的技術(shù)實(shí)現(xiàn)都是將一部分公用的數(shù)據(jù)計算出來之后進(jìn)行局部存儲，然后供其他復(fù)雜的計算進(jìn)行計算結(jié)果的復(fù)用，進(jìn)而依托于存儲加速計算，也為用戶節(jié)約了計算成本。那么在流批一體層面上看，我們可以用怎樣的技術(shù)手段，優(yōu)化現(xiàn)有流批一體架構(gòu)呢？
首先計算實(shí)時性是業(yè)務(wù)價值最大化的強(qiáng)需求，那么在不損失業(yè)務(wù)實(shí)時性的前提下，如何改進(jìn)批計算環(huán)節(jié)的技術(shù)實(shí)現(xiàn)來完成計算成本優(yōu)化的目標(biāo)呢？
這里簡單假設(shè)一下，流計算產(chǎn)品一般都是有狀態(tài)的計算引擎，在持續(xù)計算的過程中我們都會將中間計算結(jié)果進(jìn)行持久化處理，以Apache Flink為例，在持續(xù)查詢的算子實(shí)現(xiàn)層面，會將中間計算結(jié)果進(jìn)行statebackend的持久化處理，當(dāng)然這些持久化處理是為了作業(yè)的恢復(fù)使用。但如果這些持久化數(shù)據(jù)除了用于作業(yè)恢復(fù)之外，再延伸思考一下，我們是否有契機(jī)將持久化數(shù)據(jù)應(yīng)用在高精準(zhǔn)批量計算的過程當(dāng)中呢？
我們知道流計算模式的計算結(jié)果之所以有失精準(zhǔn)性，那是因?yàn)橛行〔糠值臄?shù)據(jù)延時和更新造成的。比如我們在窗口計算中，延時的數(shù)據(jù)只會影響數(shù)據(jù)對應(yīng)的窗口計算結(jié)果，那么在精準(zhǔn)性批量計算中只需要對有問題的窗口數(shù)據(jù)進(jìn)行計算，并且我們即便是對有問題的窗口數(shù)據(jù)進(jìn)行計算，也沒有必要把整體窗口的所有數(shù)據(jù)都重新計算一遍，而是利用流計算的中間結(jié)果和出現(xiàn)問題的延時數(shù)據(jù)進(jìn)行修復(fù)計算即可。
如果這些構(gòu)想能夠細(xì)化落地，會涉及到statebackend能力延展，以及流計算中間計算結(jié)果的通用數(shù)據(jù)結(jié)構(gòu)抽象，并結(jié)合GAP數(shù)據(jù)和數(shù)據(jù)源建立血緣關(guān)系的方式，減少GAP數(shù)據(jù)在statebackend的存儲，進(jìn)而即便是GAP數(shù)據(jù)我們也可以從數(shù)據(jù)源拉取，而不進(jìn)行多余的持久化處理，這樣就可以極大程度的優(yōu)化流批一體化架構(gòu)實(shí)現(xiàn)。
如果再進(jìn)一步延展，也許我們可以將Statebackend獨(dú)立成StateDB子產(chǎn)品，這樣在 checkpoint/failover等機(jī)制中也可以得到優(yōu)化可能，比如在在Fast failover中將StateDB作為遠(yuǎn)程分布式的狀態(tài)數(shù)據(jù)庫，作業(yè)算子的狀態(tài)可以mappping到StateDB中的狀態(tài)記錄，進(jìn)而提速作業(yè)恢復(fù)。
上面的簡單構(gòu)思其實(shí)核心是想讓批計算可以復(fù)用流計算的計算狀態(tài)，那么其實(shí)在流批一體化技術(shù)體系和實(shí)際的業(yè)務(wù)場景中，也存在流計算復(fù)用批計算計算狀態(tài)的需求，我舉一個例子，我們在追數(shù)據(jù)的場景，我們可能利用批計算模式進(jìn)行歷史數(shù)據(jù)的追溯計算，在追上之后切換到流計算模式，那么批計算的計算結(jié)果如何在切換到流計算模式時候被新流入的數(shù)據(jù)計算過程進(jìn)行復(fù)用呢？這里面也是前面我們提到流批一體化技術(shù)體系需要解決流批系統(tǒng)自動切換的前提能力之一。
總之，在我看來，延展計算存儲，利用存儲加速計算是后續(xù)我們需要持續(xù)研究和不斷技術(shù)演進(jìn)的重點(diǎn)方向之一。
不論如何，這些方向的思考和技術(shù)的研究在默默的發(fā)生著，我們靜觀其變，其實(shí)，除了流批一體之外流計算產(chǎn)品還有很多重要的技術(shù)挑戰(zhàn)需要持續(xù)投入，比如，秒級收縮容，狀態(tài)數(shù)據(jù)的冷熱分層，云原生的邁進(jìn)，流計算產(chǎn)品的低代碼化等等。今天內(nèi)容主題是流計算產(chǎn)品的綜合洞察，所以不針對每一個技術(shù)細(xì)節(jié)進(jìn)行展開，后續(xù)課程我們慢慢再聊。
05 用戶取向
以終為始 – 用戶視角（商業(yè)價值）
OK，現(xiàn)在我們換個思維方向，我們說流計算產(chǎn)品的核心目標(biāo)是讓數(shù)據(jù)產(chǎn)生價值。
首先我們的目標(biāo)是讓企業(yè)適用商業(yè)趨勢進(jìn)而助力企業(yè)創(chuàng)造最大業(yè)務(wù)價值，那么企業(yè)是以這樣的方式達(dá)成適應(yīng)商業(yè)趨勢呢？當(dāng)然依靠的是企業(yè)管理層一個又一個的企業(yè)決策。再去思考，這些決策的依據(jù)又是什么呢？當(dāng)然是靠精準(zhǔn)的數(shù)據(jù)作為決策支撐。那么精準(zhǔn)的數(shù)據(jù)又是從哪里來的呢？不能排除有一部分實(shí)時精準(zhǔn)的數(shù)據(jù)就來自于我們的流計算產(chǎn)品。那么這些精準(zhǔn)有效的數(shù)據(jù)又來自于哪里呢？其實(shí)原始數(shù)據(jù)還是來源于商業(yè)本身。
那么在這樣的數(shù)據(jù)和數(shù)據(jù)利用閉環(huán)體系中，怎樣的計算產(chǎn)品才是對用戶是最有效的呢？這個問題是流計算產(chǎn)品需要持續(xù)思考的問題。
以終為始 – 用戶視角（做我所長）
怎樣的流計算產(chǎn)品才是對用戶最有效的？這個問題，如果我們從用戶視角去思考的話，我想，如果一個流計算產(chǎn)品可以為用戶創(chuàng)造一個用戶可以只 “做其所長”的平臺環(huán)境，那么將是對用戶最有效的流計算產(chǎn)品。
那么怎樣衡量一個流計算產(chǎn)品是否做到了可以讓用戶能夠精力集中到“做其所長”呢？我們可以從產(chǎn)品能力和產(chǎn)品形態(tài)兩個維度進(jìn)行思考。
首先從產(chǎn)品能力上看，流計算產(chǎn)品首先需要具備數(shù)據(jù)集成能力，然后是數(shù)據(jù)分析能力，在具備了集成分析能力之后，我們更需要在領(lǐng)域上深耕，增加更多的行業(yè)分析能力，比如物聯(lián)網(wǎng)領(lǐng)域，金融風(fēng)控領(lǐng)域等領(lǐng)域性較強(qiáng)的分析能力。
不論我們進(jìn)行什么行業(yè)的分析，用戶最終還是期望依托于數(shù)據(jù)進(jìn)行商業(yè)決策的，那么如果流計算產(chǎn)品本身囊括了商業(yè)決策所需平臺能力，那么將會極大的減輕用戶的決策成本。
最后，如果我們的流計算產(chǎn)品可以智能的學(xué)習(xí)企業(yè)商業(yè)決策所需要的決策模型，并自動化的助力企業(yè)進(jìn)行商業(yè)決策，那么用戶就真的是只思考商業(yè)模式和做自己最擅長的業(yè)務(wù)工作去了，那么也必然能達(dá)成了”做其所長“的最佳狀態(tài)。但是我們知道，流計算產(chǎn)品能力不僅僅是技術(shù)層面的功能性，還需要有交付到用戶手里的產(chǎn)品形態(tài)，那么怎樣的產(chǎn)品形態(tài)才是最便利用戶的呢？
第一種，我們可以將產(chǎn)品能力齊全的項(xiàng)目發(fā)布代碼交付給客戶，客戶自己本地部署，也就是On-premise交付形態(tài)。這種本地部署其實(shí)對用戶提出了很高的要求，包機(jī)房，網(wǎng)絡(luò)環(huán)境等等都需要用戶自己準(zhǔn)備
第二種，半托管模式，也就是基于IaaS交付模式，用戶可以托管服務(wù)器，網(wǎng)絡(luò)環(huán)境等基礎(chǔ)設(shè)置，用戶只是依賴的中間件產(chǎn)品和流計算產(chǎn)品自己部署到安全的基礎(chǔ)設(shè)施里面，但是這里面用戶仍然要維護(hù)流計算產(chǎn)品的應(yīng)用
第三種，全托管模式，也就是PaaS交付模式，為用戶提供一個流計算產(chǎn)品平臺，比如：用戶只需通過web 瀏覽器就可以進(jìn)行業(yè)務(wù)開發(fā)，用戶只關(guān)心自己的業(yè)務(wù)應(yīng)用代碼維護(hù)
第四種，是更便利的服務(wù)模式，SaaS交付模式，用戶只需要進(jìn)行服務(wù)直接調(diào)用或者簡單的業(yè)務(wù)流程編排就完成了自己的業(yè)務(wù)需要。
第五種，其實(shí)這一種更多的是云原生架構(gòu)的體現(xiàn)形式，一切皆服務(wù)，數(shù)據(jù)庫可以是服務(wù)，人工智能可以服務(wù)，業(yè)務(wù)流程也可以是服務(wù)，XaaS交付模式會對服務(wù)直接的依賴復(fù)用提出更多的技術(shù)挑戰(zhàn)。
那么不論產(chǎn)品具備怎樣的產(chǎn)品能力，以怎樣的產(chǎn)品形態(tài)進(jìn)行交付，流計算產(chǎn)品都需要考慮用戶數(shù)據(jù)處理的實(shí)時性要求。
最后，要時刻意識到流計算產(chǎn)品需要解決以數(shù)據(jù)處理的實(shí)時性，以達(dá)到將業(yè)務(wù)數(shù)據(jù)的價值最大化的目標(biāo)。
06 產(chǎn)品能力
以終為始 – 產(chǎn)品能力（數(shù)據(jù)集成）
那么用戶要達(dá)成自己的商業(yè)決策需求，根據(jù)流計算產(chǎn)品提供的不同層面的產(chǎn)品能力，可以解決怎樣的業(yè)務(wù)問題，都適用怎樣的業(yè)務(wù)場景呢？
首先我們看看具備數(shù)據(jù)集成能力的流計算產(chǎn)品在用戶整個業(yè)務(wù)處理鏈條中的位置。
流計算產(chǎn)品具備數(shù)據(jù)集成能力是最基礎(chǔ)的能力，核心解決企業(yè)各個業(yè)務(wù)系統(tǒng)由于數(shù)據(jù)分散存儲而造成的數(shù)據(jù)價值碎片問題。數(shù)據(jù)集成可以將分散數(shù)據(jù)進(jìn)行匯聚，供后續(xù)業(yè)務(wù)進(jìn)行綜合分析。
如圖，只具備數(shù)據(jù)集成能力的流計算產(chǎn)品將多數(shù)據(jù)源數(shù)據(jù)匯聚集成，但不進(jìn)行聚合加工，集成后的數(shù)據(jù)直接輸出到其他的具備分析能力的數(shù)據(jù)產(chǎn)品。
從用戶視角看，用戶只能通過具備數(shù)據(jù)集成能力的流計算產(chǎn)品完成業(yè)務(wù)數(shù)據(jù)的實(shí)時集成需求，要完成全部的商業(yè)決策還需要面對其他大數(shù)據(jù)生態(tài)產(chǎn)品，比如數(shù)據(jù)湖，數(shù)據(jù)倉庫等。
以終為始 – 產(chǎn)品能力（數(shù)據(jù)分析）
那么具備數(shù)據(jù)分析能力的流計算產(chǎn)品應(yīng)該增加怎樣的功能和解決怎樣的業(yè)務(wù)問題呢？
首先流計算產(chǎn)品具備數(shù)據(jù)分析能力是在數(shù)據(jù)集成能力基礎(chǔ)之上的能力增強(qiáng)，核心會增加滿足基礎(chǔ)的分析算子能力，如：數(shù)據(jù)窗口劃分，通用聚合函數(shù)，各種數(shù)據(jù)流的JOIN等，對數(shù)據(jù)進(jìn)行通用分析。
從用戶視角來看，用戶可以通過具備數(shù)據(jù)分析能力的流計算產(chǎn)品可以滿足常見的業(yè)務(wù)端到端需求，比如實(shí)時監(jiān)控等業(yè)務(wù)需求。但是復(fù)雜的領(lǐng)域性復(fù)雜分析，還需要借助其他大數(shù)據(jù)生態(tài)產(chǎn)品，比如數(shù)據(jù)湖，數(shù)據(jù)倉庫等。這里我們注意，分析后的數(shù)據(jù)除了流入其他具備領(lǐng)域性分析能力的產(chǎn)品外，也可以直接提供給監(jiān)控預(yù)警場景的終端用戶，也意味著具備數(shù)據(jù)分析能力的流計算產(chǎn)品可以端到端的獨(dú)立解決某些業(yè)務(wù)場景了。
以終為始 – 產(chǎn)品能力（行業(yè)分析）
流計算產(chǎn)品發(fā)展到第三個能力層次就是具備行業(yè)分析能力，行業(yè)分析能力可以橫向拓展，就像在堅(jiān)實(shí)的地基上高樓林立，每一座高樓都代表一個行業(yè)，而你可以不斷的新建新的、各具特色的大樓。
流計算產(chǎn)品增加行業(yè)分析能力，是根據(jù)不同行業(yè)的領(lǐng)域問題來增加領(lǐng)域性較強(qiáng)的垂直功能，比如電商行業(yè)需要的機(jī)器學(xué)習(xí)能力，進(jìn)而完成搜索推薦，游戲行業(yè)需要對玩家各種游戲打斗和道具應(yīng)用進(jìn)行復(fù)雜的事件分析，進(jìn)而需要增加CEP能力，或者IoT領(lǐng)域需要對設(shè)備實(shí)時管理，就有可能需要增加位置數(shù)據(jù)處理能力和時序數(shù)據(jù)處理能力等等。
用戶視角：用戶可以通過具備行業(yè)分析能力的流計算產(chǎn)品，開發(fā)滿足特定行業(yè)屬性的端到端需求，比如電商的商品推薦，IoT領(lǐng)域的設(shè)備管理和控制，游戲行業(yè)的復(fù)雜事件分析等，沒有被流計算產(chǎn)品覆蓋的行業(yè)需求，還是需要借助其他大數(shù)據(jù)生態(tài)產(chǎn)品，比如數(shù)據(jù)湖，數(shù)據(jù)倉庫等。
以終為始 – 產(chǎn)品能力（商業(yè)決策）
流計算產(chǎn)品發(fā)展到具備了商業(yè)決策能力，那么從用戶視角看，流計算產(chǎn)品基本完成了除了企業(yè)自身業(yè)務(wù)工作之外的所有工作了，流計算產(chǎn)品就可以做企業(yè)的軍師了，不用給流計算產(chǎn)品太多輸入，流計算產(chǎn)品就可以告訴企業(yè)如何進(jìn)業(yè)務(wù)拓展，如何進(jìn)行客戶拓展。
流計算產(chǎn)品具備商業(yè)決策能力，需要增加對商業(yè)決策模型進(jìn)行配置的能力，并具備根據(jù)決策流程配置生成商業(yè)決策的能力。同時此時的流計算產(chǎn)品應(yīng)該囊括了其他分析類產(chǎn)品的能力，即，比如流程定制，湖倉分析等等都是對用戶透明的。
從用戶視角看，用戶可以通過具備商業(yè)決策能力的流計算產(chǎn)品進(jìn)行商業(yè)方面的實(shí)時決策，用戶只需要對企業(yè)決策規(guī)則進(jìn)行配置，對決策流程進(jìn)行配置，并配置決策方案的打分機(jī)制，進(jìn)而通過流計算產(chǎn)品完成端到端的全鏈路的商業(yè)決策。
具備這樣能力的流計算產(chǎn)品已經(jīng)是廣義的流計算概念了，這樣的流計算產(chǎn)品可以端到端的處理現(xiàn)實(shí)世界中隨時間而產(chǎn)生的任何數(shù)據(jù)，真正達(dá)成全面的實(shí)時化分析決策。具備這個能力的流計算產(chǎn)品已經(jīng)是一個現(xiàn)實(shí)事件實(shí)時化分析處理的流計算產(chǎn)品套件了。
以終為始 – 產(chǎn)品能力（智能學(xué)習(xí)）
最后，如果讓這個流計算產(chǎn)品更智能化，如果產(chǎn)品具備智能學(xué)習(xí)的能力，那就是最完美的流計算產(chǎn)品了。
流計算產(chǎn)品具備智能學(xué)習(xí)能力，是在具備商業(yè)決策能力的基礎(chǔ)上對決策的規(guī)則，決策模型等人工配置部分自動化掉，就是依托于內(nèi)置的數(shù)據(jù)分析，行業(yè)分析，機(jī)器學(xué)習(xí)，模型訓(xùn)練和數(shù)據(jù)預(yù)測等能力進(jìn)行智能的自動更新。
從用戶視角來看，用戶可以利用具備智能學(xué)習(xí)能力的流計算產(chǎn)品，只需要進(jìn)行商業(yè)目標(biāo)的設(shè)定和用戶增長所需的業(yè)務(wù)參數(shù)配置，即可完成商業(yè)價值的締造。
這里也做一個簡單的說明，前面和大家分享的流計算產(chǎn)品這五個層面的產(chǎn)品能力，是從達(dá)成用戶利用數(shù)據(jù)創(chuàng)造價值的目標(biāo)過程中，如何簡化用戶非擅長的工作的視角進(jìn)行思考的，流計算產(chǎn)品的發(fā)展可以從不同的視角進(jìn)行切入規(guī)劃，如有不妥的認(rèn)知，歡迎大家指正，也期待聽到你的思考分享！
那么接下來讓我們來看看當(dāng)前行業(yè)中的流計算產(chǎn)品有哪些？
07 業(yè)界產(chǎn)品
以終為始 – 開源產(chǎn)品
首先我們看看開源領(lǐng)域的流計算項(xiàng)目。
第一個[Apache Flink](https://flink.apache.org/zh/flink-architecture.html)是一個分布式處理引擎，用于在無邊界和有邊界數(shù)據(jù)流上進(jìn)行有狀態(tài)的計算。Flink 能在所有常見集群環(huán)境中運(yùn)行，并能以內(nèi)存速度和任意規(guī)模進(jìn)行計算。
第二個[Apache Spark](https://spark.apache.org/) 是一個多語言引擎，用于在單節(jié)點(diǎn)機(jī)器或集群上執(zhí)行數(shù)據(jù)工程、數(shù)據(jù)科學(xué)和機(jī)器學(xué)習(xí)。
第三個[Apache Storm](https://storm.apache.org/) 可以輕松可靠地處理無限的數(shù)據(jù)流，實(shí)現(xiàn)Hadoop對批處理的實(shí)時處理。
第四個[Esper](https://www.espertech.com/) 是一種用于復(fù)雜事件處理（CEP）和流式分析的產(chǎn)品
第五個[Hazelcast](https://hazelcast.com/)是一個流式和內(nèi)存優(yōu)先的應(yīng)用平臺，用于在本地、邊緣或作為完全管理的云服務(wù)實(shí)現(xiàn)快速、有狀態(tài)、數(shù)據(jù)密集型的工作負(fù)載。
第六個[Apache Samza](https://samza.apache.org/) 允許您構(gòu)建有狀態(tài)應(yīng)用程序，實(shí)時處理來自多個源的數(shù)據(jù)。
第七/八兩個都是基于[Kafka](https://kafka.apache.org/documentation/streams/)的延展流計算產(chǎn)品,其中[ksqlDB](https://ksqldb.io/)是為流處理應(yīng)用程序?qū)ｉT構(gòu)建的數(shù)據(jù)庫。
第九個[MegFlow](https://github.com/MegEngine/MegFlow) 提供快速視覺應(yīng)用落地流程，最快 15 分鐘搭建起視頻分析服務(wù),雖然和流計算產(chǎn)品有一定的差異，但是也很值得我們感興趣的同學(xué)去體驗(yàn)一下。
第十個[Apache Heron](https://heron.apache.org/)是一種實(shí)時、分布式、容錯的流處理引擎
這些開源流計算引擎大家都可以作業(yè)流計算理論學(xué)習(xí)的實(shí)現(xiàn)工程參考。如果大家對哪一個特別感興趣，我們也可線下聚焦討論，一起學(xué)習(xí)。
以終為始 – 商業(yè)產(chǎn)品（基于開源）
除了前面的開源產(chǎn)品還有一些大家熟知的基于開源打造的商業(yè)化平臺產(chǎn)品，簡單了解如下幾個：
第一個是阿里巴巴旗下實(shí)時計算商業(yè)品牌
[Ververica](https://www.aliyun.com/product/bigdata/sc)，是阿里云基于 Apache Flink 構(gòu)建的企業(yè)級、高性能實(shí)時大數(shù)據(jù)處理系統(tǒng)，由 Apache Flink 創(chuàng)始團(tuán)隊(duì)官方出品，擁有全球統(tǒng)一商業(yè)化品牌，完全兼容開源 Flink API，提供豐富的企業(yè)級增值功能。
第二個是騰訊云的流計算品牌
[流計算Oceanus](https://cloud.tencent.com/product/oceanus)，是大數(shù)據(jù)產(chǎn)品生態(tài)體系的實(shí)時化分析利器，是基于 Apache Flink 構(gòu)建的企業(yè)級實(shí)時大數(shù)據(jù)分析平臺，具備一站開發(fā)、無縫連接、亞秒延時、低廉成本、安全穩(wěn)定等特點(diǎn)。流計算 Oceanus 以實(shí)現(xiàn)企業(yè)數(shù)據(jù)價值最大化為目標(biāo)，加速企業(yè)實(shí)時化數(shù)字化的建設(shè)進(jìn)程。
第三個是 AWS的流計算品牌
[Kinesis](https://aws.amazon.com/cn/kinesis/data-analytics/)，使用無服務(wù)器的完全托管式 Apache Flink 從串流數(shù)據(jù)中獲得可行建議。
第四個是Confluent產(chǎn)品
[Confluent](https://www.confluent.io/)的KsqlDB是專門為流處理應(yīng)用程序構(gòu)建的數(shù)據(jù)庫，能夠利用它進(jìn)行流處理使您能夠從數(shù)據(jù)流中獲得即時見解。
第五個Esper產(chǎn)品
[Esper](https://www.espertech.com/)企業(yè)版是一種用于復(fù)雜事件處理（CEP）和流式分析的產(chǎn)品
第六個是谷歌產(chǎn)品
[Dataflow](https://cloud.google.com/dataflow)，無服務(wù)器、快速且經(jīng)濟(jì)高效的統(tǒng)一流式數(shù)據(jù)處理和批量數(shù)據(jù)處理。
最后兩個大家感興趣也可以到其官網(wǎng)進(jìn)行簡單了解。
以終為始 – 商業(yè)產(chǎn)品（完全自研）
對于流計算產(chǎn)品提供商而言，一種是基于開源進(jìn)行商業(yè)化，一種是完全自研進(jìn)行商業(yè)化，自研產(chǎn)品對企業(yè)研發(fā)力量的要求還是很高的，但是投入產(chǎn)出比也是也是不錯的，我們看到如圖的這些自研產(chǎn)品，不論是Oracle，SAS，還是TIBCO，IBM他們自研的流計算產(chǎn)品都是在Forrester測評的領(lǐng)導(dǎo)者象限的。所以在目前業(yè)界擁抱開源的大環(huán)境下，自研產(chǎn)品的生命力并不會減弱，因?yàn)檫@些自研產(chǎn)品的東家都具備一流的產(chǎn)研能力，都舍得在研發(fā)上長期投入，這是很多處于探尋商業(yè)生存空間的中小企業(yè)無法比擬的。
以終為始 – 商業(yè)產(chǎn)品（組合套件）
跳出流計算產(chǎn)品的單品，在整個大數(shù)據(jù)產(chǎn)品體系中，要端到端的解決企業(yè)業(yè)務(wù)問題，僅僅一個流計算核心產(chǎn)品是遠(yuǎn)遠(yuǎn)不夠的，所以很多企業(yè)打造了大數(shù)據(jù)流計算體系的產(chǎn)品套件，企業(yè)在這個套件中可以閉環(huán)的完成所有的企業(yè)大數(shù)據(jù)流計算需求，大家如果感興趣可以對如圖產(chǎn)品進(jìn)行逐一了解，比如第一個九很有意思，低代碼的流計算分析產(chǎn)品。坦白說我也非常贊同流計算產(chǎn)品都盡可能的走到低代碼行列。
08 交付模式
以終為始 – 價值空間
OK，到這里我們簡單了解了從純開源，到基于開源的商業(yè)化產(chǎn)品，到完全自研的產(chǎn)品，再到流計算體系的產(chǎn)品套件等業(yè)界現(xiàn)有的流計算產(chǎn)品。那么這些產(chǎn)品在交付選擇上有怎樣的區(qū)別，這些不同的交互模式下有怎樣的本質(zhì)區(qū)別呢？我們這里可以有一個共識，這些產(chǎn)品都是toB的產(chǎn)品，不同的交付模式完全是流計算產(chǎn)品提供商和B端企業(yè)的分工問題。
但這些分工有一個本質(zhì)的內(nèi)因，就是不同的交付模式?jīng)Q定了彼此的價值空間。但這里一方價值空間的增加并不是以犧牲對方的價值空間為基礎(chǔ)的，而是一種因地制宜，按需索取的雙贏模式。為什么要這么說呢？我們可以根據(jù)不同的交付模式簡單分析一下。
以終為始 – 交付模式（toB）
其實(shí)流計算產(chǎn)品面向B端企業(yè)，B端產(chǎn)品最終也是面向C端用戶的，那么云上流計算產(chǎn)品的交付模式對于C端用戶有什么影響嗎？這一點(diǎn)我們是確認(rèn)的，就是不論流計算產(chǎn)品怎么交付到B端用戶，C端用戶都是不受影響的。那么B端用戶就需要根據(jù)自己的企業(yè)特點(diǎn)選擇不同的流計算產(chǎn)品交付模式。
那么，到底有幾種流計算產(chǎn)品交付模式，可以供B端企業(yè)進(jìn)行選擇呢？常見的有4種可選的交付模式，即：On-premise，IaaS，PaaS和SaaS。
那么這幾種交付模式的不同完全是在產(chǎn)品在面向C端用戶之前所需要的工作分工進(jìn)行區(qū)別的，那么我們要想一
網(wǎng)頁名稱：No.0 - 流計算產(chǎn)品綜合洞察@以終為始
分享地址：http://m.fisionsoft.com.cn/article/cdpsojj.html
