前言

3年前的時(shí)候?qū)戇^(guò)關(guān)于一些大數(shù)據(jù)入門基礎(chǔ)的文章， 當(dāng)時(shí)學(xué)習(xí)的是spark。文章鏈接如下：
大數(shù)據(jù)介紹：https://testerhome.com/topics/7988
spark基礎(chǔ)操作：https://testerhome.com/topics/8040
shuffle和性能測(cè)試：https://testerhome.com/topics/8120
離線大數(shù)據(jù)作業(yè)的測(cè)試方法：https://testerhome.com/topics/17092

這一篇算是彌補(bǔ)了之前對(duì)于流計(jì)算的缺失吧。由于我們產(chǎn)品在今年加入了流計(jì)算的能力， 并且Flink貌似也有要在流計(jì)算領(lǐng)域中一統(tǒng)江山的架勢(shì)，所以我前段時(shí)間借著調(diào)研混沌工程方案的契機(jī)，也開(kāi)始學(xué)習(xí)了Flink并了解我們產(chǎn)品對(duì)于流計(jì)算的應(yīng)用場(chǎng)景(PS：混沌工程是流計(jì)算中一個(gè)比較重要的測(cè)試手段)。今天把學(xué)習(xí)和實(shí)踐的一些總結(jié)分享出來(lái)。

什么場(chǎng)景需要流計(jì)算

流計(jì)算一般都是在一些數(shù)據(jù)計(jì)算的實(shí)時(shí)性要求很高的場(chǎng)景中出現(xiàn)， 之前在講spark的時(shí)候都是基于離線的批處理計(jì)算的， 這種計(jì)算方式無(wú)法滿足產(chǎn)品對(duì)實(shí)時(shí)性的要求。比如如果我們要在大看板上計(jì)算PV和UV的數(shù)據(jù)， 一般都是希望能夠?qū)崟r(shí)的觀看到這些數(shù)據(jù)的變化。而計(jì)算PV和UV的操作又不好嵌入到業(yè)務(wù)系統(tǒng)中， 因?yàn)閷?duì)業(yè)務(wù)侵入性太強(qiáng)并且會(huì)影響性能。所以一般的架構(gòu)可能是如下的樣子：

業(yè)務(wù)系統(tǒng)會(huì)將用戶行為數(shù)據(jù)push到消息中間件(kafka)中， 這樣達(dá)到了解耦和降低性能開(kāi)銷的目的。而flink streaming 服務(wù)會(huì)訂閱kafka的topic進(jìn)行流處理， 也就是一旦有數(shù)據(jù)從kafka中發(fā)送過(guò)來(lái)，滿足一定條件后就會(huì)觸發(fā)flink的一系列算子進(jìn)行計(jì)算， 數(shù)據(jù)在flink中的這些算子中進(jìn)行傳遞，聚合，計(jì)算等操作后， 將經(jīng)過(guò)處理的數(shù)據(jù)推送給外部的存儲(chǔ)系統(tǒng)或者業(yè)務(wù)系統(tǒng)， 這些系統(tǒng)會(huì)將數(shù)據(jù)做進(jìn)一步保存和處理后展示在大屏上--這就是一種計(jì)算PV和UV的簡(jiǎn)單的場(chǎng)景了。整個(gè)過(guò)程之所以叫流，就是因?yàn)閿?shù)據(jù)并不是像傳統(tǒng)的方式保存到文件系統(tǒng)中，在保存到了一定的量或者利用定時(shí)任務(wù)觸發(fā)批處理計(jì)算的方式執(zhí)行。而是數(shù)據(jù)就像一條pipeline(流水線)一樣，來(lái)一個(gè)(或者一小批，可以規(guī)定時(shí)間窗口，可以規(guī)定數(shù)據(jù)個(gè)數(shù))就處理一個(gè)，并把處理結(jié)果傳到pipeline的下一個(gè)算子上繼續(xù)處理，這種方式是不是有點(diǎn)像jenkins的piepline~ 實(shí)際上很多AI系統(tǒng)，比如推薦系統(tǒng)，反欺詐系統(tǒng)這些對(duì)實(shí)時(shí)性要求比較高的場(chǎng)景都要利用流計(jì)算來(lái)實(shí)時(shí)的進(jìn)行處理。如果要展開(kāi)它的內(nèi)部處理過(guò)程大概是下面這個(gè)圖：

重點(diǎn)說(shuō)明一下上圖中的task， 這個(gè)task就可以理解為Flink中的算子了， 也叫operator。在Flink中可以定義當(dāng)數(shù)據(jù)到來(lái)的時(shí)候， 都經(jīng)過(guò)哪些算子，按照什么順序進(jìn)行計(jì)算。比如可以先使用filter算子把沒(méi)用的數(shù)據(jù)進(jìn)行過(guò)濾， 再使用map算子對(duì)原始數(shù)據(jù)做一些轉(zhuǎn)換， 后面再使用sum算子進(jìn)行累加計(jì)算出PV。當(dāng)然這些task是可以并行計(jì)算的，Flink可以合并計(jì)算結(jié)果。要是寫(xiě)代碼的話，大概是下面這個(gè)樣子：

上面是大數(shù)據(jù)領(lǐng)域經(jīng)典demo workcount， 計(jì)算文件中的詞頻。上面我用紅色框起來(lái)的部分就是算子， 先是flatmap做一些處理， 再使用keyBy算子把數(shù)據(jù)分類， 把有相同的key的數(shù)據(jù)分到一個(gè)組里，然后進(jìn)行sum的累加計(jì)算， 這樣就能計(jì)算出每個(gè)key(單詞)的詞頻了(這個(gè)單詞出現(xiàn)多少次)。PS：代碼里的keyBy(0)中的0是數(shù)據(jù)的第幾列， 意思是按第幾列進(jìn)行分組。

OK， 上面就是簡(jiǎn)單講講什么是流計(jì)算以及什么場(chǎng)景需要流計(jì)算。flink的算子和運(yùn)行模式跟spark是很像的，對(duì)flink的使用還有疑問(wèn)的同學(xué)可以看看我之前寫(xiě)的spark基礎(chǔ)。下面要開(kāi)始講測(cè)試點(diǎn)了。

從消息中間件說(shuō)起

好像現(xiàn)在業(yè)界主流的能支持流計(jì)算的消息中間件也就只有kafka了，所以我下面都用kafka來(lái)舉例(實(shí)際上我也只用過(guò)kafka，請(qǐng)?jiān)徫抑R(shí)上的匱乏)，這里我要講一下kafka的精準(zhǔn)一次性語(yǔ)義， 之所以講這個(gè)是要開(kāi)始講述流計(jì)算中最重要最難以驗(yàn)證的一個(gè)場(chǎng)景(對(duì)，我就是想先講難的，重要的) ---- 數(shù)據(jù)一致性。什么是數(shù)據(jù)一致性呢，就是不論在任何情況下數(shù)據(jù)被處理的結(jié)果都是一致的。這里說(shuō)的任何情況包括但不限于：

• 計(jì)算任務(wù)異常重啟后導(dǎo)致之前已經(jīng)計(jì)算過(guò)的數(shù)據(jù)丟失

• 計(jì)算任務(wù)異常重啟后導(dǎo)致之前已經(jīng)計(jì)算過(guò)的數(shù)據(jù)在本次任務(wù)進(jìn)行重試的時(shí)候造成的數(shù)據(jù)重復(fù)計(jì)算

• 計(jì)算任務(wù)不能因?yàn)榫W(wǎng)絡(luò)延遲，異常等因素導(dǎo)致數(shù)據(jù)傳遞給下游系統(tǒng)失敗后導(dǎo)致的數(shù)據(jù)丟失

那么我們看kafka是怎么處理這種情況的， 當(dāng)我們使用kafka的producer向broker推送消息的時(shí)候，怎么能保證本次推送的消息不會(huì)因?yàn)楦鞣N異常導(dǎo)致數(shù)據(jù)丟失呢？很多小伙伴可能已經(jīng)想到了重試， 如果因?yàn)榫W(wǎng)絡(luò)異常等原因?qū)е聀ush請(qǐng)求異常的話，那么我們重試幾次就好了，畢竟kafka開(kāi)了高可用模式，集群上會(huì)有其他的broker提供服務(wù)，就算當(dāng)前的broker徹底跪了數(shù)據(jù)也不會(huì)丟失的。但是我們是否想過(guò)一個(gè)問(wèn)題，重試請(qǐng)求是可以隨便執(zhí)行的么？或者說(shuō)程序怎么能確定本次失敗的推送請(qǐng)求就是真的失敗了，也就是數(shù)據(jù)沒(méi)有保存到kafka上。在kafka中確認(rèn)消息是否推送成功是需要producer和broker互相交換ACK的， 也就是producer在把消息推送給broker后，broker在保存成功后要給producer回一個(gè)ACK讓 客戶端知道消息已經(jīng)保存成功了。那么如果我們的異常是發(fā)生在broker已經(jīng)保存好數(shù)據(jù)和把ACK發(fā)送到客戶端之間呢？也就是數(shù)據(jù)已經(jīng)保存好了， 只是沒(méi)有給客戶端返回ACK，所以客戶端認(rèn)為這個(gè)推送消息的請(qǐng)求是失敗的。那么這個(gè)時(shí)候如果我們執(zhí)行了retry的邏輯，實(shí)際上數(shù)據(jù)就出現(xiàn)了重復(fù)的場(chǎng)景。

這么解釋大家是不是就明白了retry的邏輯不是能隨隨便便加的，它有一個(gè)前提條件， 就是它要retry的那個(gè)接口必須是冪等的。這個(gè)我再當(dāng)初講混沌工程的時(shí)候也提過(guò)， 一個(gè)高可用的系統(tǒng)，它的接口必須是冪等的， 因?yàn)楦呖捎玫哪Ｊ秸f(shuō)白了就是上游系統(tǒng)retry，下游系統(tǒng)多副本負(fù)載均衡+冪等。只有下游系統(tǒng)有冪等的能力，上游系統(tǒng)才敢執(zhí)行重試操作， 否則的話就是數(shù)據(jù)重復(fù)寫(xiě)。那么冪等是什么意思呢， 大白話就是接口自己能判斷出當(dāng)前的請(qǐng)求是不是之前已經(jīng)發(fā)送過(guò)的重復(fù)數(shù)據(jù)了，如果是重復(fù)數(shù)據(jù)它是不處理的。行話就是同樣的數(shù)據(jù)不論計(jì)算多少次都不對(duì)結(jié)果造成影響，此為冪等。

而kafka的精準(zhǔn)一次性語(yǔ)義中定義了幾個(gè)級(jí)別的模式， 其中有一個(gè)叫exactly once(精準(zhǔn)一次性語(yǔ)義，意思是我保證針對(duì)一個(gè)數(shù)據(jù)不管你重復(fù)發(fā)送多少次，服務(wù)端都只計(jì)算一次)這種模式就可以解決這個(gè)問(wèn)題。在producer中可以設(shè)置冪等和分布式事務(wù)相關(guān)的參數(shù)和代碼， 一旦這樣設(shè)置了，那么就擁有了冪等屬性， kafka內(nèi)部會(huì)根據(jù)算法計(jì)算出消息的唯一id，broker只要查詢消息的id在之前是否有保存過(guò)就可以判斷出當(dāng)前消息是否是重復(fù)數(shù)據(jù)了(大概是這樣，細(xì)節(jié)沒(méi)研究過(guò))。這樣客戶端就可以肆無(wú)忌憚的進(jìn)行重試而不必?fù)?dān)心數(shù)據(jù)重復(fù)計(jì)算。

再談Flink的exactly once

通過(guò)講述Kafka的精準(zhǔn)一次性語(yǔ)義也就是exactly once 是為了跟大家講述什么是數(shù)據(jù)一致性以及保證數(shù)據(jù)一致的方法和重要性。由于kafka本身提供了這種特性所以要保證消息傳送到kafka的數(shù)據(jù)一致性是比較容易的， 正因?yàn)楹苋菀滓话悴蝗菀壮鲥e(cuò)所以很多團(tuán)隊(duì)都忘了去測(cè)試這個(gè)場(chǎng)景(有時(shí)候研發(fā)會(huì)忘了設(shè)置這個(gè)參數(shù)導(dǎo)致出現(xiàn)bug，所以最好還是需要測(cè)一下)。當(dāng)時(shí)光保證kafka的精準(zhǔn)一次性是不行， 我們是一個(gè)業(yè)務(wù)場(chǎng)景， 我們需要的是端到端的一致性， 得是全鏈路的一致性。所以現(xiàn)在我們來(lái)看看Flink這一層怎么做的exactly once。

Checkpoint

講到這里就必須要說(shuō)明一下大名鼎鼎的checkpoint了， 基本上checkpoint是所有分布式框架都要有的機(jī)制，spark如此flink亦如此。checkpoint就是一種保存我們?cè)谟?jì)算過(guò)程中的數(shù)據(jù)的方式， 它會(huì)根據(jù)設(shè)置周期性的觸發(fā)checkpoint來(lái)保存我們計(jì)算的中間結(jié)果。我們還是用PV的案例說(shuō)明：
我們從Kafka讀取到一條條的消息，從消息中解析出app_id，然后將統(tǒng)計(jì)的結(jié)果放到內(nèi)存中一個(gè)Map集合，app_id做為key，對(duì)應(yīng)的pv做為value，每次只需要將相應(yīng)app_id 的pv值+1后put到Map中即可。

這里簡(jiǎn)要說(shuō)明一下kafka的offset， 這個(gè)是消費(fèi)消息的客戶端也就是consumer要使用offset來(lái)記錄我已經(jīng)讀取到了消息隊(duì)列中的哪一條數(shù)據(jù)， 根據(jù)這個(gè)offset我可以知道下一次我要讀取的消息的位置。即便是程序崩潰了， 只要offset能夠保存下來(lái)就知道恢復(fù)后應(yīng)該從哪個(gè)消息開(kāi)始讀取了。所以在這個(gè)機(jī)制下，flink的Source task記錄了當(dāng)前消費(fèi)到kafka test topic的所有partition的offset。所以flink會(huì)根據(jù)策略周期性的觸發(fā)checkpoint事件以流的方式傳遞給所有的算子， 算子收到checkpoint命令后就會(huì)把中間狀態(tài)保存起來(lái)， 比如在我們的案例里保存的就是kafka的offset， 比如我們?cè)O(shè)置每30s觸發(fā)一次checkpoint， 那么30s后checkpoint觸發(fā)，保存的數(shù)據(jù)為：
chk-100
offset：(0，1000)
pv：(app1，50000)(app2，10000)
該狀態(tài)信息表示第100次CheckPoint的時(shí)候， partition 0 offset消費(fèi)到了1000，pv統(tǒng)計(jì)結(jié)果為(app1，50000)(app2，10000)。那么如果任務(wù)掛了，這時(shí)候怎么辦？比如：

• 假如我們?cè)O(shè)置了三分鐘進(jìn)行一次CheckPoint，保存了上述所說(shuō)的 chk-100 的CheckPoint狀態(tài)后，過(guò)了十秒鐘，offset已經(jīng)消費(fèi)到 (0，1100)，pv統(tǒng)計(jì)結(jié)果變成了(app1，50080)(app2，10020)，但是突然任務(wù)掛了，怎么辦？

• flink只需要從最近一次成功的CheckPoint保存的offset(0，1000)處接著消費(fèi)即可，當(dāng)然pv值也要按照狀態(tài)里的pv值(app1，50000)(app2，10000)進(jìn)行累加，不能從(app1，50080)(app2，10020)處進(jìn)行累加，因?yàn)?partition 0 offset消費(fèi)到 1000時(shí)，pv統(tǒng)計(jì)結(jié)果為(app1，50000)(app2，10000)。

上面講的并行度為1的情況， 那么如果并行度是N的情況，checkpoint會(huì)在并行的算子里觸發(fā)，這個(gè)時(shí)候Flink會(huì)選擇是保持多個(gè)checkpoint一起執(zhí)行完后在統(tǒng)一往后運(yùn)算(exactly once)， 還是選擇不去協(xié)調(diào)，任意一個(gè)算子運(yùn)行完checkpoint后就當(dāng)前線程就繼續(xù)往下運(yùn)算(at least once)，因?yàn)閍t least once模式會(huì)造成并行的算子的checkpoint不是同時(shí)觸發(fā)和結(jié)束， 所以他們保存的中間態(tài)數(shù)據(jù)有偏差，也就是數(shù)據(jù)是會(huì)不一致。所以如果業(yè)務(wù)場(chǎng)景有數(shù)據(jù)強(qiáng)一致性的需求，那么需要將checkpoint模式設(shè)置為exactly once。這里大家能明白了么？我們通過(guò)把kafka的offset和我們已經(jīng)計(jì)算好的結(jié)果都通過(guò)checkpoint進(jìn)行保存來(lái)防止數(shù)據(jù)丟失或重復(fù)計(jì)算的情況。代碼差不多如下：

當(dāng)然上面是checkpoint策略， 在實(shí)際開(kāi)發(fā)算子任務(wù)的時(shí)候，要把什么數(shù)據(jù)通過(guò)checkpoint保存到flink的state backend是需要先調(diào)用對(duì)應(yīng)的state 方法來(lái)執(zhí)行的。

貼一個(gè)checkpoint的圖：

說(shuō)回?cái)?shù)據(jù)一致性

好了上面說(shuō)了那么多東西， 但是好像kafka和Flink 都已經(jīng)把數(shù)據(jù)一致性保證好了， 那還需要我們測(cè)試什么一致性么？那不是變成了在測(cè)試kafka或者flink么？我想一定會(huì)有同學(xué)這么問(wèn)， 那么我在這里解釋下：

• 即便kafka和flink有exactly once 語(yǔ)義， 但是開(kāi)啟這些語(yǔ)義需要對(duì)應(yīng)的參數(shù)調(diào)整， 并且需要編碼的時(shí)候進(jìn)行處理， 比如kafka里在開(kāi)啟了exactly once 語(yǔ)義后， 也需要研發(fā)在代碼里顯示調(diào)用分布式事務(wù)進(jìn)行數(shù)據(jù)計(jì)算， flink里對(duì)于kafka的offset和計(jì)算結(jié)果的保存也需要顯示在代碼里調(diào)用類似valueState來(lái)進(jìn)行保存和處理。也就是你們的產(chǎn)品研發(fā)同學(xué)是否編碼正確決定了數(shù)據(jù)一致性。

• 在我們的流計(jì)算里， flink上下游都會(huì)對(duì)接不同的系統(tǒng)， 上游可以是kafka，也可以是業(yè)務(wù)系統(tǒng)暴露出來(lái)的socket服務(wù)，也可以其他的源。所以你在使用非kafka也就是沒(méi)有exactly once語(yǔ)義支持的系統(tǒng)的時(shí)候，就需要研發(fā)去開(kāi)發(fā)相應(yīng)的方案來(lái)解決這個(gè)問(wèn)題。同理輸出方， 流是有數(shù)據(jù)的源，也有在經(jīng)過(guò)flink計(jì)算之后輸出的系統(tǒng)，這個(gè)系統(tǒng)可以是另外一個(gè)kafka，也可以是mysql， 也可以是業(yè)務(wù)系統(tǒng)的接口。那么輸出方是否有exactly once語(yǔ)義支持呢？非kafka的場(chǎng)景下，基本上也是沒(méi)有的， 也需要研發(fā)來(lái)開(kāi)發(fā)對(duì)應(yīng)的方案。也就是說(shuō)我程序中Flink的CheckPoint語(yǔ)義設(shè)置了 Exactly Once，但是我在計(jì)算的過(guò)程中需要實(shí)時(shí)的把計(jì)算結(jié)果保存到mysql里，那異常出現(xiàn)的時(shí)候根據(jù)checkpoint機(jī)制，我們從上一個(gè)checkpoint記錄中保存的offset去重新讀取并計(jì)算消息， 這時(shí)候我的mysql中看到豈不是看到了數(shù)據(jù)重復(fù)了？比如程序中設(shè)置了1分鐘1次CheckPoint，但是5秒向mysql寫(xiě)一次數(shù)據(jù)，并commit。所以我們要求的是Flink的end to end的精確一次都必須實(shí)現(xiàn)。如果你的chk-100成功了，過(guò)了30秒，由于5秒commit一次數(shù)據(jù)庫(kù)，所以實(shí)際上已經(jīng)寫(xiě)入了6批數(shù)據(jù)進(jìn)入mysql，但是突然程序掛了，從chk100處恢復(fù)，這樣的話，之前提交的6批數(shù)據(jù)就會(huì)重復(fù)寫(xiě)入，所以出現(xiàn)了重復(fù)消費(fèi)。Flink的精確一次有兩種情況，一個(gè)是Flink內(nèi)部的精確一次，一個(gè)是端對(duì)端的精確一次。這里面有點(diǎn)繞，我解釋的有點(diǎn)啰嗦。

所以根據(jù)上面說(shuō)的，雖然flink提供了exactly once 語(yǔ)義， 但是它的exactly once 語(yǔ)義只保證flink自己的數(shù)據(jù)計(jì)算過(guò)程，而不是端到端的。想要保證數(shù)據(jù)一致性，還是需要研發(fā)同學(xué)針對(duì)業(yè)務(wù)場(chǎng)景進(jìn)行特殊的設(shè)計(jì)。也就是開(kāi)發(fā)自己產(chǎn)品的exactly once 語(yǔ)義。所以我們還是要針對(duì)端到端的場(chǎng)景進(jìn)行測(cè)試。

測(cè)試的注意事項(xiàng)

• 首先弄清楚產(chǎn)品中流計(jì)算的架構(gòu)，都有哪些數(shù)據(jù)源，數(shù)據(jù)又發(fā)送到哪些地方。這一步至關(guān)重要， 因?yàn)槎说蕉说臄?shù)據(jù)一致性場(chǎng)景，在這一條流式鏈條里，任何一個(gè)點(diǎn)沒(méi)有做到精準(zhǔn)一次性語(yǔ)義都會(huì)導(dǎo)致數(shù)據(jù)不一致，所以我們要測(cè)試所有的點(diǎn)。

• 完成第一步后在每一個(gè)點(diǎn)進(jìn)行故障注入，故意讓任務(wù)失敗，讓服務(wù)掛掉， 屬于混沌工程式的測(cè)試方法， 就是想盡辦法讓這個(gè)流式的鏈條中的服務(wù)出故障來(lái)驗(yàn)證數(shù)據(jù)一致性。沒(méi)有測(cè)試工具的同學(xué)可以去看一下阿里開(kāi)源的chaos blade。注意：一個(gè)場(chǎng)景的故障注入要反復(fù)進(jìn)行，比如30分鐘內(nèi)每隔3分鐘都隨機(jī)找到一個(gè)flink task manager進(jìn)行kill來(lái)注入故障， 有些時(shí)候只注入一次故障是發(fā)現(xiàn)不了bug的，因?yàn)槲覀兪怯袪顟B(tài)計(jì)算，有狀態(tài)計(jì)算的場(chǎng)景很多是在特殊的狀態(tài)下發(fā)生故障才會(huì)出錯(cuò)。所以要反復(fù)注入故障來(lái)最大概率的觸發(fā)bug。

• 自動(dòng)化測(cè)試中case要驗(yàn)證數(shù)據(jù)一致性的點(diǎn)，比如在kafka->flink-mysql 的這個(gè)場(chǎng)景里，你往數(shù)據(jù)源kafka里灌入了1000個(gè)消息，如果正確的邏輯是經(jīng)過(guò)計(jì)算后要往mysql存入10條記錄， 那么你要去驗(yàn)證這10條記錄的正確性。是否有數(shù)據(jù)丟失或者重復(fù)的結(jié)算結(jié)果出現(xiàn)。

注意：做這個(gè)測(cè)試前， 先確定你們是否有數(shù)據(jù)一致性的強(qiáng)需求。有些場(chǎng)景真的會(huì)覺(jué)得數(shù)據(jù)丟了就丟了。。。。。

結(jié)尾

好了寫(xiě)這么多， 今天羅里吧嗦的寫(xiě)了一大堆好像就說(shuō)了一個(gè)數(shù)據(jù)一致性的測(cè)試。之前在社區(qū)跟人討論的時(shí)候，有很多同學(xué)其實(shí)不贊同這種深入研發(fā)架構(gòu)的測(cè)試方式。而我前兩天刷脈脈的時(shí)候也在匿名區(qū)看到有人發(fā)消息， 討論區(qū)里對(duì)qa是否要測(cè)試這種場(chǎng)景有很大的爭(zhēng)議。所以我花了很大的篇幅解釋一下做這種測(cè)試的必要性。下次我們將其他的測(cè)試方法。

打下廣告，社區(qū)線上沙龍，12月27日，就是本周日下午，WeTest，微信，網(wǎng)易和大家一起探討 devops下的質(zhì)量保障！由于社區(qū)小助手失聯(lián)了。請(qǐng)大家加下面兩位同學(xué)的微信，給大家拉到討論群中去~

xiaozhao129540

oscarx1982

總結(jié)

以上是生活随笔為你收集整理的webform计算某几列结果_大数据测试场景科普 流计算篇 (上)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。