本作品采用知識共享署名-非商業(yè)性使用-相同方式共享 4.0 國際許可協(xié)議進(jìn)行許可。

本作品 (李兆龍 博文, 由 李兆龍 創(chuàng)作)，由 李兆龍 確認(rèn)，轉(zhuǎn)載請注明版權(quán)。

引言

春節(jié)假期回到家里斷然是不會有看紙質(zhì)書的時間的。造化弄人，二月三號早上十一點(diǎn)的飛機(jī)延誤到一點(diǎn)多，原本三小時不到的閱讀時間延長為五個小時，也給了我看完這本書的機(jī)會。

第一次了解到這本書是Tison在朋友圈發(fā)了他寫的書評[2]，開頭便是：

值得一讀，尤其是對開始開發(fā)流計算任務(wù)或系統(tǒng)一到兩年，初步實(shí)現(xiàn)過一些功能或作業(yè)，但是還沒有對流式系統(tǒng)建立起系統(tǒng)認(rèn)識的開發(fā)者。

Tison參與開源的起家項(xiàng)目就是Flink。而我對于流計算系統(tǒng)接觸起源于時序數(shù)據(jù)庫的流式計算（降采樣），時序數(shù)據(jù)的以目前使用的場景來看，絕大多數(shù)還是把分鐘/秒級別數(shù)據(jù)基于SQL規(guī)則降維度/不降維度（對應(yīng)group by tag/*）到小時/天級別，這樣的需求大多數(shù)決策者會在寫入鏈路上加一個Flink/Spark，將數(shù)據(jù)本身處理后寫入時序數(shù)據(jù)庫，這也導(dǎo)致業(yè)務(wù)成本上相當(dāng)一部分是在Flink/Spark上的。

我們可以看到TDengine的官網(wǎng)上將緩存、流計算，數(shù)據(jù)訂閱以及時序數(shù)據(jù)庫的功能閉環(huán)在TDengine內(nèi)部，并將此作為賣點(diǎn)之一，核心是為了降低系統(tǒng)設(shè)計復(fù)雜度和運(yùn)行成本，并標(biāo)榜自己為時序大數(shù)據(jù)處理平臺。

我對于流計算系統(tǒng)的淺薄了解便來自于這里。事實(shí)上TDengine包括我們的實(shí)現(xiàn)標(biāo)榜為流計算系統(tǒng)并不完全正確，準(zhǔn)確的說應(yīng)該窗口僅為時間，無狀態(tài)的，且非DAG的簡化批處理系統(tǒng)，但是這樣的場景對于目前絕大多數(shù)需求完全夠用，因?yàn)槟康氖菫榱思铀俨樵兌皇墙o業(yè)務(wù)賦能。

我參與了騰訊新一代時序數(shù)據(jù)庫從立項(xiàng)到上云的全過程，并實(shí)現(xiàn)了對于系統(tǒng)內(nèi)部簡化流計算能力的支持，所以非常符合“開始開發(fā)流計算任務(wù)或系統(tǒng)一到兩年，初步實(shí)現(xiàn)過一些功能或作業(yè)”的人的，這也是讀這本書的主要原因。

在開始書評之前，以TDengine這張圖為背景，我以我淺薄的知識評價下在決策者的角度我會怎樣使用時序數(shù)據(jù)庫。

1. 首先我認(rèn)為時序數(shù)據(jù)庫的流式計算能力是可以解決時序場景中的絕大多數(shù)分析需求的，所以我愿意嘗試這里的能力。但是對于是否降本我持懷疑態(tài)度，因?yàn)橄到y(tǒng)內(nèi)部執(zhí)行流計算系統(tǒng)需要大量的內(nèi)存，尤其是在流計算任務(wù)較多時（每個measurement一個，這個數(shù)字會極度膨脹），這個時候擴(kuò)容成了唯一的方法，如果只按照讀寫的能力去申請資源，加上流計算的資源消耗存在內(nèi)存風(fēng)險。但也并不是沒有顯而易見的好處，即數(shù)據(jù)庫自治，絕大多數(shù)情況只有數(shù)據(jù)庫自己知道該如何較優(yōu)構(gòu)建降采樣和流計算。
2. kafka的錢是省不了的，這是系統(tǒng)的最后兜底，假如我是一個CEO不可能把我身家性命放在“時序大數(shù)據(jù)處理平臺”的，而且業(yè)務(wù)數(shù)據(jù)還需要做更高級的分析需求（降維度，接入用戶內(nèi)部分析系統(tǒng)等），時序數(shù)據(jù)庫的流計算短期能很難看到超越專業(yè)流計算系統(tǒng)的可能，所以接受到業(yè)務(wù)數(shù)據(jù)后架一個kafka是必要的。
3. Cache功能完全可以集成到時序數(shù)據(jù)庫內(nèi)部，這里有兩個場景，1. 系統(tǒng)需要快速將最新數(shù)據(jù)返回給應(yīng)用程序 2. 相同sql數(shù)據(jù)緩存，實(shí)際查詢只查詢兩次sql的時間差值內(nèi)的數(shù)據(jù)，減少CPU/內(nèi)存消耗；時序數(shù)據(jù)庫集成這些功能是完全可行的，對于我們開發(fā)的多模數(shù)據(jù)庫，可以在用戶的資源內(nèi)起一個SSD Redis db，存儲大量數(shù)據(jù)在SSD中，在增加了存儲利用率的同時減少了用戶查詢時延。

內(nèi)容

若河床上沒有巖石，溪流就不會有歌聲

第一章闡述了應(yīng)用程序，后臺服務(wù)，批處理系統(tǒng)，流處理系統(tǒng)之間的區(qū)別，并討論多階段架構(gòu)，為后續(xù)引出DAG做鋪墊。

先解決問題，再編寫代碼

第二章引入收費(fèi)站的例子，指出基于Web服務(wù)構(gòu)建存在流量增加時請求延遲引發(fā)了系統(tǒng)遲滯，導(dǎo)致結(jié)果不準(zhǔn)確的問題，因而引出使用流系統(tǒng)，并指出流系統(tǒng)的核心概念由事件，作業(yè)，源，算子和流構(gòu)成，處理引擎由源執(zhí)行器，算子執(zhí)行器和作業(yè)啟動器構(gòu)成。

九個人不可能再一個月造出一個孩子

第三章介紹了并行化和數(shù)據(jù)分組，這可以解決分布式系統(tǒng)的一個根本挑戰(zhàn)，即如何擴(kuò)展系統(tǒng)以增加吞吐量，或者說如何在更短的時間處理更多的數(shù)據(jù)。并行化包含數(shù)據(jù)并行和任務(wù)并行，前者含義為將一個任務(wù)的不同子集交給不同的執(zhí)行單元，后者含義為在不同的數(shù)據(jù)上運(yùn)行相同的任務(wù)。章節(jié)的后續(xù)引入事件分發(fā)器，并提出分組概念，為了下游組件可以高效的并行處理上游事件，這和kafka中的partition概念基本一致。

糟糕的程序員擔(dān)心代碼，優(yōu)秀的程序員擔(dān)心數(shù)據(jù)結(jié)構(gòu)和它們之間的關(guān)系

第四章引入欺詐檢測的case，與之前不同，這時的流并不是一條直線，在數(shù)據(jù)源之后需要執(zhí)行多種檢測，這就引出了DAG，并解釋了算子的扇入扇出，同時指出扇出時發(fā)出的事件可以只被推送到某些輸出隊(duì)列中，此外不同的輸出隊(duì)列中可能擁有不同的數(shù)據(jù)。

人們從來沒有足夠的時間去做正確的事情，但總有足夠的時間去重做一遍

第五章介紹了送達(dá)語義，即至多一次（At-Most Once）、至少一次（At-Least Once）和恰好一次（Exactly Once），并指出Exactly Once需要重試和冪等來保證。在我們的時序系統(tǒng)中實(shí)現(xiàn)了kafka ingest，需要接受用戶寫入kafka的數(shù)據(jù)，并高效的寫入引擎，這里開始我們使用autoCommit，這就是經(jīng)典的至多一次，但是存在數(shù)據(jù)丟失風(fēng)險，后來我們使用手動管理offset，保證在實(shí)際寫入成功后再提交offset，但這依舊只能保證至少一次，真正的恰好一次是靠時序數(shù)據(jù)庫本身的冪等保證的。

技術(shù)使人們能夠控制除了技術(shù)以外的一切

第六章是對前五章的總結(jié)。

計算機(jī)能集中注意力的時間只和它的電源線一樣長

第七章討論了窗口計算和窗口水位；前者討論了固定窗口，滑動窗口和會話窗口，并指出可以使用外部系統(tǒng)來完善窗口算子；其次提到亂序數(shù)據(jù)的到達(dá)需要設(shè)置窗口水位，一般情況下維持多個窗口開銷較大，以目前的經(jīng)驗(yàn)用戶通?？梢越邮軄G棄這部分?jǐn)?shù)據(jù)。Tison提到The Dataflow Model 是 Google 流計算的經(jīng)典論文，Dataflow 模型的開山之作，簡單瀏覽了一下文章內(nèi)容，窗口水位部分對應(yīng)文章中：

1. When in processing time they are materialized ?
2. How earlier results relate to later refinements ?

這里我還想討論下目前公有云監(jiān)控的實(shí)時性問題，騰訊云上目前分鐘監(jiān)控在120s內(nèi)，秒監(jiān)控在12s以內(nèi)，這個值是怎么得到的呢？時序數(shù)據(jù)本質(zhì)上也可以看作一個有界的數(shù)據(jù)流，分鐘級別監(jiān)控可以認(rèn)為是窗口為時間的數(shù)據(jù)，在這種情況下首先存在一個攢數(shù)據(jù)的過程，因?yàn)椴淮_定數(shù)據(jù)實(shí)在一分鐘的哪一秒到達(dá)，這就60s了，在加上上報存在失敗，在最后1s失敗時允許重試，最后就是時序數(shù)據(jù)庫內(nèi)寫入的削峰，這些加起來產(chǎn)品給出了120s的保證。

一個SQL查詢來到酒吧，走到兩張桌子(table)前問道：我能加入(join)你們嗎

第八章討論JOIN。書中把join當(dāng)作一種特殊的扇入方式，并提出流必須轉(zhuǎn)化為表才可以執(zhí)行join，同時討論了雙流join中首先基于窗口物化流，其次再join。這一節(jié)的內(nèi)容在我們的流系統(tǒng)中無法使用，但是在流式查詢引擎中還是有理論指導(dǎo)意義的，首先基于窗口截取，其次再合并返回。

永遠(yuǎn)不要相信一臺你無法扔出窗口的計算機(jī)

第九章討論了流系統(tǒng)中廣泛支持的故障處理機(jī)制，即反壓，一種與數(shù)據(jù)流向相反的壓力。因?yàn)榱魇窃丛床粩嗟?#xff0c;如果存在某個模塊出現(xiàn)預(yù)期之外的情況，問題很快會傳播到其他組件，導(dǎo)致系統(tǒng)崩潰，反壓就是最后一道防線，
具體介紹了如何判斷繁忙狀態(tài)與如何執(zhí)行反壓，前者我認(rèn)為與系統(tǒng)相關(guān)，后者的處理是通用的，1. 停止數(shù)據(jù)源 2. 停止上游組件 并需要考慮如何解除反壓狀態(tài)讓系統(tǒng)恢復(fù)。

且反壓需要區(qū)分事件，比如實(shí)例宕機(jī)或者消費(fèi)能力不足，這兩者靠自身都是無法恢復(fù)的，需要拉起實(shí)例和增加資源，書中還提到一種特殊的case，即持續(xù)觸發(fā)反壓，這會造成整個系統(tǒng)的抖動。

這一章對我來說最大的意義在于從理論上確定了在流系統(tǒng)上思考極端情況是有理論基礎(chǔ)的，在我們的實(shí)現(xiàn)流計算過程中就遇到過類似的問題，比如WAL拉取導(dǎo)致計算節(jié)點(diǎn)CPU暴增處理包變慢，存儲節(jié)點(diǎn)累計大包，出現(xiàn)大范圍OOM；其次還有在均衡操作觸發(fā)時存在消費(fèi)老數(shù)據(jù)的情況，造成CPU激增，影響其他組件；這些其實(shí)都是沒有考慮反壓的情況。

對于如何判斷繁忙狀態(tài)與如何執(zhí)行反壓，前者可以通過統(tǒng)計CPU/內(nèi)存來做，后者可以選擇停止輸入和丟棄，工程上不同的場景在監(jiān)控上需要可以體現(xiàn)。

重啟試試

第十章討論了有狀態(tài)計算，這同時是Flink的最大價值，即而在于實(shí)現(xiàn)了帶狀態(tài)的流計算。這一章主要闡述狀態(tài)和檢查點(diǎn)，即何時持久化狀態(tài)，書中給出的方法是在數(shù)據(jù)流中加入檢查點(diǎn)，這可以理解為屏障（barrier）。其實(shí)以目前我們在時序數(shù)據(jù)庫中實(shí)現(xiàn)的流系統(tǒng)來看，最難的點(diǎn)其實(shí)在于調(diào)度，因?yàn)檎{(diào)度的復(fù)雜性，我們沒有選擇有狀態(tài)的流計算，在出現(xiàn)故障時，選擇重放幾個窗口的事件，并限制CPU/內(nèi)存使用。

成功不在于是否曾經(jīng)摔倒，而在于能否重新站起來

第十一章終章是對七到十章節(jié)的總結(jié)和展望。

總結(jié)

現(xiàn)有的時序數(shù)據(jù)庫只是實(shí)現(xiàn)了窗口僅為時間，無狀態(tài)的，且非DAG的簡化批處理系統(tǒng)，想以此替代流系統(tǒng)的全部份額基本不太現(xiàn)實(shí)，但是確實(shí)可以拿下其中部分收益，領(lǐng)域垂直公司需要故事去活下去，但是公有云需要關(guān)注業(yè)務(wù)上真正需要解決的問題，可見的未來我們的精力不會投入到完善時序的流計算系統(tǒng)中去。

參考：

1. 大圖書館 #8 流式系統(tǒng)閱讀指南
2. 大圖書館 #9 《流計算系統(tǒng)圖解》書評
3. 支持消息隊(duì)列和流式計算背后，TDengine 3.0 存儲引擎的優(yōu)化與升級
4. DolphinDB教程：流數(shù)據(jù)時序引擎
5. 一文學(xué)會如何使用 TDengine 3.0 中的流式計算
6. 支持消息隊(duì)列和流式計算背后，TDengine 3.0 存儲引擎的優(yōu)化與升級
7. Naiad：A Timely Dataflow System
8. 論文閱讀-Naiad：A Timely Dataflow System
9. The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing
10. 大數(shù)據(jù)理論篇 - 通俗易懂，揭秘谷歌《The Dataflow Model》的核心思想(一)