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

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

引言

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

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

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

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

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

我對于流計算系統(tǒng)的淺薄了解便來自于這里。事實上TDengine包括我們的實現(xiàn)標榜為流計算系統(tǒng)并不完全正確，準確的說應該窗口僅為時間，無狀態(tài)的，且非DAG的簡化批處理系統(tǒng)，但是這樣的場景對于目前絕大多數(shù)需求完全夠用，因為目的是為了加速查詢而不是給業(yè)務賦能。

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

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

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

內(nèi)容

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

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

先解決問題，再編寫代碼

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

永遠不要相信一臺你無法扔出窗口的計算機

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

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

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

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

重啟試試

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

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

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

總結(jié)

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

參考：

1. 大圖書館 #8 流式系統(tǒng)閱讀指南
2. 大圖書館 #9 《流計算系統(tǒng)圖解》書評
3. 支持消息隊列和流式計算背后，TDengine 3.0 存儲引擎的優(yōu)化與升級
4. DolphinDB教程：流數(shù)據(jù)時序引擎
5. 一文學會如何使用 TDengine 3.0 中的流式計算
6. 支持消息隊列和流式計算背后，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》的核心思想(一)