真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

如何理解Flink實(shí)時(shí)應(yīng)用的確定性

這篇文章給大家介紹如何理解Flink實(shí)時(shí)應(yīng)用的確定性,內(nèi)容非常詳細(xì),感興趣的小伙伴們可以參考借鑒,希望對(duì)大家能有所幫助。

創(chuàng)新互聯(lián)從2013年創(chuàng)立,是專(zhuān)業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項(xiàng)目網(wǎng)站設(shè)計(jì)制作、網(wǎng)站設(shè)計(jì)網(wǎng)站策劃,項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命,1280元霍爾果斯做網(wǎng)站,已為上家服務(wù),為霍爾果斯各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:13518219792

確定性(Determinism)是計(jì)算機(jī)科學(xué)中十分重要的特性,確定性的算法保證對(duì)于給定相同的輸入總是產(chǎn)生相同的輸出。在分布式實(shí)時(shí)計(jì)算領(lǐng)域,確定性是業(yè)界一直難以解決的課題,由此導(dǎo)致用離線計(jì)算修正實(shí)時(shí)計(jì)算結(jié)果的 Lambda 架構(gòu)成為大數(shù)據(jù)領(lǐng)域過(guò)去近十年的主流架構(gòu)。

而在最近幾年隨著 Google The Dataflow Model 的提出,實(shí)時(shí)計(jì)算和離線計(jì)算的關(guān)系逐漸清晰,在實(shí)時(shí)計(jì)算中提供與離線計(jì)算一致的確定性成為可能。本文將基于流行實(shí)時(shí)計(jì)算引擎 Apache Flink,梳理構(gòu)建一個(gè)確定性的實(shí)時(shí)應(yīng)用要滿足什么條件。

確定性與準(zhǔn)確性

比起確定性,準(zhǔn)確性(Accuracy)可能是我們接觸更多的近義詞,大多數(shù)場(chǎng)景下兩者可以混用,但其實(shí)它們稍有不同: 準(zhǔn)確的東西一定是確定的,但確定性的東西未必百分百準(zhǔn)確。在大數(shù)據(jù)領(lǐng)域,不少算法可以根據(jù)需求調(diào)整成本和準(zhǔn)確性的平衡,比如 HyperLogLog 去重統(tǒng)計(jì)算法給出的結(jié)果是有一定誤差的(因此不是準(zhǔn)確的),但卻同時(shí)是確定性的(重算可以得到相同結(jié)果)。

要分區(qū)確定性和準(zhǔn)確性的緣故是,準(zhǔn)確性與具體的業(yè)務(wù)邏輯緊密耦合難以評(píng)估,而確定性則是通用的需求(除去少數(shù)場(chǎng)景用戶故意使用非確定性的算法)。當(dāng)一個(gè) Flink 實(shí)時(shí)應(yīng)用提供確定性,意味著它在異常場(chǎng)景的自動(dòng)重試或者手動(dòng)重流數(shù)據(jù)的情況下,都能像離線作業(yè)一般產(chǎn)出相同的結(jié)果,這將很大程度上提高用戶的信任度。

影響 Flink 應(yīng)用確定性的因素

投遞語(yǔ)義


常見(jiàn)的投遞語(yǔ)義有 At-Most-Once、At-Least-Once 和 Exactly-Once 三種。嚴(yán)格來(lái)說(shuō)只有 Exactly-Once滿足確定性的要求,但如果整個(gè)業(yè)務(wù)邏輯是冪等的, 基于At-Least-Once 也可以達(dá)到結(jié)果的確定性。

實(shí)時(shí)計(jì)算的 Exactly-Once 通常指端到端的 Exactly-Once,保證輸出到下游系統(tǒng)的數(shù)據(jù)和上游的數(shù)據(jù)是一致的,沒(méi)有重復(fù)計(jì)算或者數(shù)據(jù)丟失。要達(dá)到這點(diǎn),需要分別實(shí)現(xiàn)讀取數(shù)據(jù)源(Source 端)的 Exactly-Once、計(jì)算的 Exactly-Once 和輸出到下游系統(tǒng)(Sink 端)的 Exactly-Once。

其中前面兩個(gè)都比較好保證,因?yàn)?Flink 應(yīng)用出現(xiàn)異常會(huì)自動(dòng)恢復(fù)至最近一個(gè)成功 checkpoint,Pull-Based 的 Source 的狀態(tài)和 Flink 內(nèi)部計(jì)算的狀態(tài)都會(huì)自動(dòng)回滾到快照時(shí)間點(diǎn),而問(wèn)題在于 Push-Based 的 Sink 端。Sink 端是否能順利回滾依賴(lài)于外部系統(tǒng)的特性,通常來(lái)說(shuō)需要外部系統(tǒng)支持事務(wù),然而不少大數(shù)據(jù)組件對(duì)事務(wù)的支持并不是很好,即使是實(shí)時(shí)計(jì)算最常用的 Kafka 也直到 2017 年的 0.11 版本才支持事務(wù),更多的組件需要依賴(lài)各種 trick 來(lái)達(dá)到某種場(chǎng)景下的 Exactly-Once。

總體來(lái)說(shuō)這些 trick 可以分為兩大類(lèi):

  • 依賴(lài)寫(xiě)操作的冪等性。比如 HBase 等 KV 存儲(chǔ)雖然沒(méi)有提供跨行事務(wù),但可以通過(guò)冪等寫(xiě)操作配合基于主鍵的 Upsert 操作達(dá)到 Exactly-Once。不過(guò)由于 Upsert 不能表達(dá) Delete 操作,這種模式不適合有 Delete 的業(yè)務(wù)場(chǎng)景。
  • 預(yù)寫(xiě)日志(WAL,Write-Ahead-Log)。預(yù)寫(xiě)日志是廣泛應(yīng)用于事物機(jī)制的技術(shù),包括 MySQL、PostgreSQL 等成熟關(guān)系型數(shù)據(jù)庫(kù)的事物都基于預(yù)寫(xiě)日志。預(yù)寫(xiě)日志的基本原理先將變更寫(xiě)入緩存區(qū),等事務(wù)提交的時(shí)候再一次全部應(yīng)用。比如 HDFS/S3 等文件系統(tǒng)本身并不提供事務(wù),因此實(shí)現(xiàn)預(yù)寫(xiě)日志的重?fù)?dān)落到了它們的用戶(比如 Flink)身上。通過(guò)先寫(xiě)臨時(shí)的文件/對(duì)象,等 Flink Checkpoint 成功后再提交,F(xiàn)link 的 FileSystem Connector 實(shí)現(xiàn)了 Exactly-Once。然而,預(yù)寫(xiě)日志只能保證事務(wù)的原子性和持久性,不能保證一致性和隔離性。為此 FileSystem Connector 通過(guò)將預(yù)寫(xiě)日志設(shè)為隱藏文件的方式提供了隔離性,至于一致性(比如臨時(shí)文件的清理)則無(wú)法保證。

為了保證 Flink 應(yīng)用的確定性,在選用官方 Connector,特別是 Sink Connector 時(shí),用戶應(yīng)該留意官方文檔關(guān)于 Connector 投遞語(yǔ)義的說(shuō)明[3]。此外,在實(shí)現(xiàn)定制化的 Sink Connector 時(shí)也需要明確達(dá)到何種投遞語(yǔ)義,可以參考利用外部系統(tǒng)的事務(wù)、寫(xiě)操作的冪等性或預(yù)寫(xiě)日志三種方式達(dá)到 Exactly-Once 語(yǔ)義。

函數(shù)副作用

函數(shù)副作用是指用戶函數(shù)對(duì)外界造成了計(jì)算框架意料之外的影響。比如典型的是在一個(gè) Map 函數(shù)里將中間結(jié)果寫(xiě)到數(shù)據(jù)庫(kù),如果 Flink 作業(yè)異常自動(dòng)重啟,那么數(shù)據(jù)可能被寫(xiě)兩遍,導(dǎo)致不確定性。對(duì)于這種情況,F(xiàn)link 提供了基于 Checkpoint 的兩階段提交的鉤子(CheckpointedFunction 和 CheckpointListener),用戶可以用它來(lái)實(shí)現(xiàn)事務(wù),以消除副作用的不確定性。另外還有一種常見(jiàn)的情況是,用戶使用本地文件來(lái)保存臨時(shí)數(shù)據(jù),這些數(shù)據(jù)在 Task 重新調(diào)度的時(shí)候很可能丟失。其他的場(chǎng)景或許還有很多,總而言之,如果需要在用戶函數(shù)里改變外部系統(tǒng)的狀態(tài),請(qǐng)確保 Flink 對(duì)這些操作是知情的(比如用 State API 記錄狀態(tài),設(shè)置 Checkpoint 鉤子)。

Processing Time

在算法中引入當(dāng)前時(shí)間作為參數(shù)是常見(jiàn)的操作,但在實(shí)時(shí)計(jì)算中引入當(dāng)前系統(tǒng)時(shí)間,即 Processing Time,是造成不確定性的最常見(jiàn)也最難避免的原因。對(duì) Processing 的引用可以是很明顯、有完善文檔標(biāo)注的,比如 Flink 的 Time Characteristic,但也可能是完全出乎用戶意料的,比如來(lái)源于緩存等常用的技術(shù)。為此,筆者總結(jié)了幾類(lèi)常見(jiàn)的 Processing Time 引用:

  • Flink 提供的 Time Characteristic。Time Characteristic 會(huì)影響所有使用與時(shí)間相關(guān)的算子,比如 Processing Time 會(huì)讓窗口聚合使用當(dāng)前系統(tǒng)時(shí)間來(lái)分配窗口和觸發(fā)計(jì)算,造成不確定性。另外,Processing Timer 也有類(lèi)似的影響。
  • 直接在函數(shù)里訪問(wèn)外部存儲(chǔ)。因?yàn)檫@種訪問(wèn)是基于外部存儲(chǔ)某個(gè) Processing Time 時(shí)間點(diǎn)的狀態(tài),這個(gè)狀態(tài)很可能在下次訪問(wèn)時(shí)就發(fā)生了變化,導(dǎo)致不確定性。要獲得確定性的結(jié)果,比起簡(jiǎn)單查詢(xún)外部存儲(chǔ)的某個(gè)時(shí)間點(diǎn)的狀態(tài),我們應(yīng)該獲取它狀態(tài)變更的歷史,然后根據(jù)當(dāng)前 Event Time 去查詢(xún)對(duì)應(yīng)的狀態(tài)。這也是 Flink SQL 中 Temporary Table Join 的實(shí)現(xiàn)原理[1]。
  • 對(duì)外部數(shù)據(jù)的緩存。在計(jì)算流量很大的數(shù)據(jù)時(shí),很多情況下用戶會(huì)選擇用緩存來(lái)減輕外部存儲(chǔ)的負(fù)載,但這可能會(huì)造成查詢(xún)結(jié)果的不一致,而且這種不一致是不確定的。無(wú)論是使用超時(shí)閾值、LRU(Least Recently Used)等直接和系統(tǒng)時(shí)間相關(guān)的緩存剔除策略,還是 FIFO(First In First Out)、LFU(Less Frequently Used)等沒(méi)有直接關(guān)聯(lián)時(shí)間的剔除策略,訪問(wèn)緩存得到的結(jié)果通常和消息的到達(dá)順序相關(guān),而在上游經(jīng)過(guò) shuffle 的算子里面這是難以保證的(沒(méi)有 shuffle 的 Embarrassingly Parallel 作業(yè)是例外)。
  • Flink 的 StateTTL。StateTTL 是 Flink 內(nèi)置的根據(jù)時(shí)間自動(dòng)清理 State 的機(jī)制,而這里的時(shí)間目前只提供 Processing Time,無(wú)論 Flink 本身使用的是 Processing Time 還是 Event Time 作為 Time Characteristic。BTW,StateTTL 對(duì) Event Time 的支持可以關(guān)注 FLINK-12005[2]。

綜合來(lái)講,要完全避免 Processing Time 造成的影響是非常困難的,不過(guò)輕微的不確定性對(duì)于業(yè)務(wù)來(lái)說(shuō)通常是可以接受的,我們要做的更多是提前預(yù)料到可能的影響,保證不確定性在可控范圍內(nèi)。

Watermark

Watermark 作為計(jì)算 Event Time 的機(jī)制,其中一個(gè)很重要的用途是決定實(shí)時(shí)計(jì)算何時(shí)要輸出計(jì)算結(jié)果,類(lèi)似文件結(jié)束標(biāo)志符(EOF)在離線批計(jì)算中達(dá)到的效果。然而,在輸出結(jié)果之后可能還會(huì)有遲到的數(shù)據(jù)到達(dá),這稱(chēng)為窗口完整性問(wèn)題(Window Completeness)。

窗口完整性問(wèn)題無(wú)法避免,應(yīng)對(duì)辦法是要么更新計(jì)算結(jié)果,要么丟棄這部分?jǐn)?shù)據(jù)。因?yàn)殡x線場(chǎng)景延遲容忍度較大,離線作業(yè)可以推遲一定時(shí)間開(kāi)始,盡可能地將延遲數(shù)據(jù)納入計(jì)算。而實(shí)時(shí)場(chǎng)景對(duì)延遲有比較高的要求,因此一般是輸出結(jié)果后讓狀態(tài)保存一段時(shí)間,在這段時(shí)間內(nèi)根據(jù)遲到數(shù)據(jù)持續(xù)更新結(jié)果(即 Allowed Lateness),此后將數(shù)據(jù)丟棄。因?yàn)槎ㄎ?,?shí)時(shí)計(jì)算天然可能出現(xiàn)更多被丟棄的遲到數(shù)據(jù),這將和 Watermark 的生成算法緊密相關(guān)。

雖然 Watermark 的生成是流式的,但 Watermark 的下發(fā)是斷點(diǎn)式的。Flink 的 Watermark 下發(fā)策略有 Periodic 和 Punctuated 兩種,前者基于 Processing Time 定時(shí)觸發(fā),后者根據(jù)數(shù)據(jù)流中的特殊消息觸發(fā)。

如何理解Flink實(shí)時(shí)應(yīng)用的確定性
圖1. Periodic Watermark 正常狀態(tài)與重放追數(shù)據(jù)狀態(tài)  

基于 Processing Time 的 Periodic Watermark 具有不確定。在平時(shí)流量平穩(wěn)的時(shí)候 Watermark 的提升可能是階梯式的(見(jiàn)圖1(a));然而在重放歷史數(shù)據(jù)的情況下,相同長(zhǎng)度的系統(tǒng)時(shí)間內(nèi)處理的數(shù)據(jù)量可能會(huì)大很多(見(jiàn)圖1(b)),并且伴有 Event Time 傾斜(即有的 Source 的 Event Time 明顯比其他要快或慢,導(dǎo)致取最小值的總體 Watermark 被慢 Watermark 拖慢),導(dǎo)致本來(lái)丟棄的遲到數(shù)據(jù),現(xiàn)在變?yōu)?Allowed Lateness 之內(nèi)的數(shù)據(jù)(見(jiàn)圖1中紅色元素)。

如何理解Flink實(shí)時(shí)應(yīng)用的確定性  
圖2. Punctuated Watermark 正常狀態(tài)與重放追數(shù)據(jù)狀態(tài)  

相比之下 Punctuated Watermark 更為穩(wěn)定,無(wú)論在正常情況(見(jiàn)圖2(a))還是在重放數(shù)據(jù)的情況(見(jiàn)圖2(b))下,下發(fā)的 Watermark 都是一致的,不過(guò)依然有 Event Time 傾斜的風(fēng)險(xiǎn)。對(duì)于這點(diǎn),F(xiàn)link 社區(qū)起草了 FLIP-27 來(lái)處理[4]?;驹硎?Source 節(jié)點(diǎn)會(huì)選擇性地消費(fèi)或阻塞某個(gè) partition/shard,讓總體的 Event Time 保持接近。

除了 Watermark 的下發(fā)有不確定之外,還有個(gè)問(wèn)題是現(xiàn)在 Watermark 并沒(méi)有被納入 Checkpoint 快照中。這意味著在作業(yè)從 Checkpoint 恢復(fù)之后,Watermark 會(huì)重新開(kāi)始算,導(dǎo)致 Watermark 的不確定。這個(gè)問(wèn)題在 FLINK-5601[5] 有記錄,但目前只體現(xiàn)了 Window 算子的 Watermark,而在 StateTTL 支持 Event Time 后,或許每個(gè)算子都要記錄自己的 Watermark。

綜上所述,Watermark 目前是很難做到非常確定的,但因?yàn)?Watermark 的不確定性是通過(guò)丟棄遲到數(shù)據(jù)導(dǎo)致計(jì)算結(jié)果的不確定性的,只要沒(méi)有丟棄遲到數(shù)據(jù),無(wú)論中間 Watermark 的變化如何,最終的結(jié)果都是相同的。

確定性不足是阻礙實(shí)時(shí)計(jì)算在關(guān)鍵業(yè)務(wù)應(yīng)用的主要因素,不過(guò)當(dāng)前業(yè)界已經(jīng)具備了解決問(wèn)題的理論基礎(chǔ),剩下的更多是計(jì)算框架后續(xù)迭代和工程實(shí)踐上的問(wèn)題。就目前開(kāi)發(fā) Flink 實(shí)時(shí)應(yīng)用而言,需要注意投遞語(yǔ)義、函數(shù)副作用、Processing Time 和 Watermark 這幾點(diǎn)造成的不確定性。

關(guān)于如何理解Flink實(shí)時(shí)應(yīng)用的確定性就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò),可以把它分享出去讓更多的人看到。


名稱(chēng)欄目:如何理解Flink實(shí)時(shí)應(yīng)用的確定性
文章分享:http://weahome.cn/article/iicdoi.html

其他資訊

在線咨詢(xún)

微信咨詢(xún)

電話咨詢(xún)

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部